As a company who mainly hires devs with no prior experience and trains them, I will say there is another factor. And that is that companies often paint themselves into a corner with their tech. Then they feel like they must hire a seasoned person to tame or even make sense of it. Accidental complexity. Hiring experienced devs is a quick fix to keep things from grinding to a halt. They can avoid stopping the feature train to pay technical debt which has accumulated to eye-watering levels.
I'd love to talk more about this. What kind of mentorship structure do you have? If you continually have to hire a seasoned person, are the jrs who level up not staying on?
For the painted into a corner scenario, I wasn't talking about my current work situation. Although I have previously tended to get hired as an experienced dev to plug into those scenarios. So I can't really answer your second question.
For mentorship structure, we are pretty small so it is mostly informal unfortunately. We have some resources and exercises that we tend to give the new hire. HTML and CSS first since we mainly do web. Then we teach them basic functional programming. It depends on the person, but it tends to be a few weeks of learning at their own pace before they get started working on a new UI app -- a real product that we are beginning. It starts as an empty app so they get to grow with it. The UI is convenient place to start because we use MVU, and it tends to reinforce the simple functional programming that we do. And it is easy to correct those inevitable early mistakes. It also has a quick and visual feedback loop, important for learners. When they decide they are ready, we introduce them to back-end stuff. Eventually they will implement features end-to-end. We've done this for a couple of products now, so we have also iterated on organization strategies for front and back that makes it easier to plug into.
Our initial reason for hiring devs with no experience is budgetary since we are a not-for-profit organization. However, even if that changes I intend to continue in this strategy because it has been quite rewarding. And because bringing in new people is a great way to test / improve the resilience of your development process / tools / paradigms.
Our company sees itself as an ever learning organization where people need to grow.
We give courses in high schools, then give scholarships in the University (we're not in the US so it's no so expensive), then we recruit university students and graduates and train them for several months (free).
After all that process we hire the best.
We've found that "growing" our own human resources has been very effective. We also hire people with experience elsewhere so that we get some cross-pollination, but incorporating training in your corporate mindset makes for an ever improving organization.
@aminmansuri This is taking what I advise my clients ("Don't waste your time chasing unicorns; invest in creating your own") to a whole other level. Great job.
This is 100% the case with most companies that hyperfocus of hiring senior talent. And the complexity isn't always accidental either. Lots of resume-driven-development out there 🙄
RDD is definitely what keeps the Houston talent pool mired in .NET and Angular (in far too many cases STILL stuck on AngularJS 1.5, because migration is such a beast), particularly because it's dominated by two industries that leverage them heavily (O&G and medical).
Houston is also extremely cheap when it comes to tech salaries, which is one of many reasons I opted for remote a decade ago and seldom can help but laugh when someone approaches me for an onsite in Houston outside of those stacks (especially how little they're willing to pay one of the few people in Houston with 10+ years of Drupal, even if I rarely use it anymore).
THIS. I gave a talk about avoiding and eliminating unnecessary complexity (at a con dedicated to a very specific stack, in which I said "and you might not even need this stack at all").
I've made it a point in recent years to architect with as much simplicity as possible for not only managing costs and minimizing infrastructure, but also so that I can plug in any junior dev and very rapidly bring them up to speed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a company who mainly hires devs with no prior experience and trains them, I will say there is another factor. And that is that companies often paint themselves into a corner with their tech. Then they feel like they must hire a seasoned person to tame or even make sense of it. Accidental complexity. Hiring experienced devs is a quick fix to keep things from grinding to a halt. They can avoid stopping the feature train to pay technical debt which has accumulated to eye-watering levels.
I'd love to talk more about this. What kind of mentorship structure do you have? If you continually have to hire a seasoned person, are the jrs who level up not staying on?
For the painted into a corner scenario, I wasn't talking about my current work situation. Although I have previously tended to get hired as an experienced dev to plug into those scenarios. So I can't really answer your second question.
For mentorship structure, we are pretty small so it is mostly informal unfortunately. We have some resources and exercises that we tend to give the new hire. HTML and CSS first since we mainly do web. Then we teach them basic functional programming. It depends on the person, but it tends to be a few weeks of learning at their own pace before they get started working on a new UI app -- a real product that we are beginning. It starts as an empty app so they get to grow with it. The UI is convenient place to start because we use MVU, and it tends to reinforce the simple functional programming that we do. And it is easy to correct those inevitable early mistakes. It also has a quick and visual feedback loop, important for learners. When they decide they are ready, we introduce them to back-end stuff. Eventually they will implement features end-to-end. We've done this for a couple of products now, so we have also iterated on organization strategies for front and back that makes it easier to plug into.
Our initial reason for hiring devs with no experience is budgetary since we are a not-for-profit organization. However, even if that changes I intend to continue in this strategy because it has been quite rewarding. And because bringing in new people is a great way to test / improve the resilience of your development process / tools / paradigms.
Our company sees itself as an ever learning organization where people need to grow.
We give courses in high schools, then give scholarships in the University (we're not in the US so it's no so expensive), then we recruit university students and graduates and train them for several months (free).
After all that process we hire the best.
We've found that "growing" our own human resources has been very effective. We also hire people with experience elsewhere so that we get some cross-pollination, but incorporating training in your corporate mindset makes for an ever improving organization.
We also have very very low attrition.
@aminmansuri This is taking what I advise my clients ("Don't waste your time chasing unicorns; invest in creating your own") to a whole other level. Great job.
This is 100% the case with most companies that hyperfocus of hiring senior talent. And the complexity isn't always accidental either. Lots of resume-driven-development out there 🙄
RDD is definitely what keeps the Houston talent pool mired in .NET and Angular (in far too many cases STILL stuck on AngularJS 1.5, because migration is such a beast), particularly because it's dominated by two industries that leverage them heavily (O&G and medical).
Houston is also extremely cheap when it comes to tech salaries, which is one of many reasons I opted for remote a decade ago and seldom can help but laugh when someone approaches me for an onsite in Houston outside of those stacks (especially how little they're willing to pay one of the few people in Houston with 10+ years of Drupal, even if I rarely use it anymore).
THIS. I gave a talk about avoiding and eliminating unnecessary complexity (at a con dedicated to a very specific stack, in which I said "and you might not even need this stack at all").
I've made it a point in recent years to architect with as much simplicity as possible for not only managing costs and minimizing infrastructure, but also so that I can plug in any junior dev and very rapidly bring them up to speed.