My employer follows a similar approach and it works wonders.
Early on we didn't have a program like this and this went poorly. We had juniors and even novices joining us without any direction or goals. They were unproductive, disconnected, and discontent. Many would eventually quit hoping for something better.
Since then, we have iteratively built up an onboarding process similar to this. Today, we have people dedicated to the first weeks of a person's employment. We have a curriculum that we follow to ensure nothing is missed. We have several mentors in each team. Depending on the employee's interested and the company's needs, they will have the opportunity to try different roles on different teams. Along the way we continually check in with them to see how things are going and if there's anything we missed it that they would like to change. We take those requests seriously and act on them promptly.
The results have been astounding! Our new hires are happy and productive. They recommend us to their friends, helping us to find excellent talent faster and cheaper than online job postings or career fairs. The feedback they give us helps is to improve the process to the point where we typically have few if any minor issues and no major issues.
I highly recommend taking a similar approach if you find yourself in a similar approach as a hiring manager, mentor, or team lead.
The comparison is to companies which just kind of throw juniors into the role like someone mid career and they’re expected to figure everything out themselves. This is sadly the norm.
Better than just giving a junior task and some guard rails to “figure it out”, I’m sure. Even just the first bit about structured (rather than ad box) intro to internal tools and processes would have been huge when I started me first job.
At my last role, and I’m sure others at large companies, up to a week of time was wasted doing training modules on the intranet, no real work.
> At my last role, and I’m sure others at large companies, up to a week of time was wasted doing training modules on the intranet, no real work.
I mean that sounds like what the article's approach would amount to in practice? What's the distinction you see between "structured (rather than ad box) intro to internal tools" and "a week of time was wasted doing training modules on the intranet, no real work"?
"just giving a junior task and some guard rails to “figure it out”" worked great for me - a lot better than every structured training programme I've seen since. Shrug.
Certainly it depends on the program. I've seen some truly horrible training programs. Cheesy videos from the 80s, pointless multiple choice tests, no mentorship or assistance after the initial round of intensive training. These aren't what we are talking about.
An example of the structure is that we have a curriculum figured out. We know what tools, techniques, and domain knowledge our new employees need within each team. An ad hoc approach like we used to follow would have individual managers or mentors giving an overview off the top of their head, then answering questions as they come up. This is a good start, but lots of important things get missed and new employees don't know to ask for information that they don't know exists.
Another example would be with mentorship. In many situations, new employees aren't given a single point of contact with someone whose duties including supporting them. In other circumstances, they will be told to ask anyone about anything, or to ask their manager or team lead, but often new employees are too timid to ask, or don't know who to ask, or the assigned person may be too busy or otherwise unapproachable. Having a plan and making sure everyone is onboard with it is important, but it's not always considered.
> Certainly it depends on the program. I've seen some truly horrible training programs. Cheesy videos from the 80s, pointless multiple choice tests, no mentorship or assistance after the initial round of intensive training. These aren't what we are talking about.
So how do you make sure your programme doesn't turn into that? Is it just a case of "have a good training programme, don't have a bad training programme"? Again it's weird to have the article use so many comparative terms and not talk about what you're comparing against and what the critical differences are.
> An example of the structure is that we have a curriculum figured out. We know what tools, techniques, and domain knowledge our new employees need within each team.
So how do you know it's right, and especially how do you keep it up to date? A lot of those terrible training programmes suffer a lot from having what was originally thought to be a good curriculum at the time.
> Another example would be with mentorship. In many situations, new employees aren't given a single point of contact with someone whose duties including supporting them. In other circumstances, they will be told to ask anyone about anything, or to ask their manager or team lead, but often new employees are too timid to ask, or don't know who to ask, or the assigned person may be too busy or otherwise unapproachable. Having a plan and making sure everyone is onboard with it is important, but it's not always considered.
Making a single point of contact mentor work sounds like something concrete that many companies don't do or do badly. How do you make sure people are properly incentivised/rewarded for mentoring well? Do new joiners have any way to recover if they end up with a bad mentor (given that having the mentor be their single point of contact/responsibility cuts both ways)?
or junior could start doing more ops and less dev. In Finland, there appears to be a culture that values seniors way more and companies don't even hire juniors. This often results situations where seniors being saddled with time-consuming tasks that involve running long scripts that keep every day business working.
This is very common in Canada and the United States too. We regularly hear companies saying they can't hire good talent, while candidates say they can't find anyone willing to hire people without multiple years of experience. It happens a lot in the trades too, not just software development.
Part of the call to action is to spend the time to hire and train juniors instead of just looking for ready-to-go seniors. It provides the employer with a larger pool of talent at lower cost, an ability to shape their skills and practices early on, and helps the entire industry grow.
I've always wondered why companies don't take a kind of staircase approach to compensation with younger engineers. E.g., if the salary is $1000/week with a 4 week staircase, then week 1 would be $250, week 2 would be $500, week 3 would be $750, and weeks 4 and onward would be at the usual salary.
If the primary cost of younger engineers comes from helping them get on board with how things are done at a given shop, this seems like it offsets the initial learning curve quite well. You could argue that the learning curve takes a lot longer, but surely there's an 80/20 rule at play here where the most important 80% can be learned in the first 20% of one's tenure at a company.
It's less about savings and more about incentivizing the hiring of juniors in the first place. Many early career engineers find it much more difficult to get that first job than the second one, because they are seen as a risk. If however you make it cheaper to take a risk, then firms will take more risks on net, and the end result will be more juniors being able to enter their careers sooner (and more junior figuring out quickly that such a career is not for them, which is also a good thing).
This is just not reasonable though. The primary cost of hiring is the long onboarding process regardless of level. Especially the time cost of existing engineers.
Underpaying a new engineer doesn't solve anything. It's honestly just shortsighted laziness or already having a staff of engineers who aren't good enough at their craft or communication to be good teachers.
If you're paying someone $1000/week you're paying them $50k per year and by your staircase approach you save.... one weeks worth of salary or 2% of the first year which ends up just being an insult to the new engineer and unnecessarily making their lives harder taking money out of their pocket when they need it most (getting a new job having not had a job or having to switch with the gap in income)
>The primary cost of hitting is the long onboarding process regardless of level.
Sure, but you would imagine the Nth week of onboarding to be more important to improving an engineer's productivity on average than the N+1th week. It may not always hold, but it's certainly what my personal experience has been.
>Underpaying a new engineer doesn't solve anything.
You could always take the money you would "save" during the staircase and offer it as an end of year bonus or some such to those who remain onboard. There's no law saying this has to result in lower pay over the long term.
>unnecessarily making their lives harder taking money out of their pocket when they need it most
It's true that such a plan incentivizes people to have some cash saved up so they can weather the first few weeks better, but even if they don't one would imagine a quality hire would be able to get a short term loan at a very good rate, considering the high likelihood that they would be able to pay it back quickly.
Unicorns aren't who benefit from such a structure. The marginal quality hire is - the person who would be good enough if they were offered the job, but who, for one reason or another, are deemed too risky to hire at current market prices.
One only has to browse a place like r/cscareerquestions to get a sense that many people, early career especially, find themselves in this situation - stuck perhaps in the dreaded "can't get hired without experience, can't get experience without getting hired" catch 22.
Paying poorly would bias you to candidates who will accept poor wages. Good candidates, even if they are young and inexperienced, can have a high market rate.
This isn't paying poorly for the long term. Firms would be willing to try out riskier hires on the margin, because there's less downside if someone turns out to be a bad fit and gets let go after a couple of weeks.
Percieved risk is higher for people with less industry experience. So if you believe, as I do, that people systematically overestimate the risk they take on bringing juniors on board, and hence systematically underhire them, then this would likely end up being good on net for juniors, as more of them would then be offered a chance to prove the bias wrong.
The main cost of juniors is the time it takes other people to get them going. Good onboarding and mentoring of juniors takes a ton of time creating structure and training material, then working with them once they’re on. If any of that’s messed up or gets derailed by execs pushing for MORE PRODUCTIVITY RIGHT NOW, and taking away time folks were using to train juniors, your onboarding will suck and more juniors will founder. Either way, we’re talking a few months, not weeks, and the junior’s salary isn’t the cost companies with any amount of sense are worried about.
My favorite onboarding experience was changing every old value of one string to the new value. It doesn’t take deep skills or wisdom about the codebase, but it introduced me to the entire project, I learned how to build, test, and deploy, and I ended up producing something valuable to the whole team.
I think you've just reinvented "hiring interns." The approach you describe here looks pretty much exactly like other intern-onboarding programs I've seen at other engineering companies, big and small.
(Which is to say, it's a great idea, which is why it's already an industry standard.)
In my experience, it's not all that standard. There are still many companies advertising exclusively for 2+ years experience, even in very niche areas where few people would already have relevant experience.
I think there might also be a different between interns and juniors. Where I'm from, interns are people who are hired specifically for a short period of time, often people still in their education. This is in comparison to juniors who are expecting permanent, full time employment. The amount of training and responsibilities given to juniors is much greater than that given interns because there is a much greater return expected.
There's a huge difference between interns and juniors. For one thing, junior engineers are full time employees with full benefits and regular expectations. For the most part, intern expectations are very low as far as any actual work goes, because they aren't there for long enough to really contribute to anything meaningfully. It's mostly a social thing and a game being played on both sides about whether or not to hook up after graduation. Companies don't actually expect to get any work product out of interns at all, that isn't the purpose of the programs, but junior engineers definitely will have real deliverables to take care of.
Problem is, in the real world this is only true for "hiring interns". When it comes to hiring junior developers you're not considered an intern anymore (especially when you didn't had a CS education that funnels you to an internship position), so the norm is "let's kick you in the deep cold water and see if you're talented enough to swim".
Our company abandoned the developer rotational program as we found many candidates did not want uncertainty around where they would end up within the company.
My onboarding experience (from 20 years ago) involved all the new hires (engineers) being placed in a classroom environment for two weeks. A senior engineer gave us a primer on the libraries the company uses (C++) and then had each one of us individually develop a mini version of the system (a trading system). Each day he would visit the classroom for a couple of hours to unblock us and answer questions. At the end of the period, our code was reviewed and we were placed into teams based on how well we did. It was certainly better than the "throw them into the deep end and let them sink or swim" approach.
This sounds like it can work great at HP or IBM, but how do you translate this to a single-digit startup (both size of staff & amount of years in existence)? Or do you just not hire juniors in a startup?
Does anyone else find this article extremely odd? There's only 3 sentences that explain the title, "best approach I've seen for hiring junior engineers," and the remaining 95% of the article is an overly verbose argument for why having good employees is good for your company. The points are so obvious that it's not even clear who or what he's arguing against. Was this entire article written by ChatGPT?
I found a dead giveaway is standalone titles that make sense, but content that doesn't. As if the author only wrote titles as a guideline and then let AI fill in the gaps. Usually it's many titles with ads in between every section.
Yes, something's wrong with the article. It seems to be the equivalent of a "repost" done poorly, since the actual content it highlights from the original article is about onboarding, whereas the title was about hiring.
Yes, calling it “Ignite” was a tip off. Similar to the use of “unleash.” My guess is 80% written by chatGPT, edited down. Alternatively, ChatGPT learned from this guy?
Still it missed “how should I fire new junior engineers”
It's an odd article, and the premise is also extremely odd. It sounds an awful lot like rushing a frat, which I'm not sure would have been all that helpful for me as a junior engineer.
No, it's real. It's commenting on the article by John, on old coworker of mine. I applied for Ignite but was not accepted and ended up getting into SE a different way. Anyway, I recommend reading the post by John and then reading this for the additional commentary.
i wonder if there's a perceptual self defeating symptom in even considering terms like junior or senior, in the sense that each individual hire is a multidimensional talent with maybe widely varying capabilities in different dimensions.
maybe part of the assessment process isn't delineating junior vs senior, or feigning some total order, but rather embracing that there is not, in general, a total order on talent among people.
it might be like seeing how well the hiring company can exploit the major eigenvectors of talent in each individual.
perhaps that's a wordy version of the rotating folks through different tasks idea?
Senior vs. Junior is not about raw talent we’re born with. Or about worthiness.
It’s about this person with a decade of experience at professional scale needs a lot less handholding than this one fresh off the turnip truck, aka bootcamp.
Personal preference: Don't outsource recruitment to HR people. Team leaders should do the recruiting. HR people have no idea what is required, and don't know about any of the technical stuff. The team leaders know what is required, and should be able to speak the same language as the candidates.
Some additional context for anyone who bothered to read the post. New Relic ended the Ignite Program and laid off John in June, a couple weeks before announcing the board had approved a private acquisition by TPG and Francisco Partners.
I'm sure these long term strategies can work in places where you can hire and fire as you please, not so much in countries with strong worker protection laws. There you really need to see how good the prospective employee is until probation is up, otherwise you're stuck with them forever.
I'd leave if I got a job as a junior at this place:
Look at how hard they are trying to bore the new developers to death:
>>> They go through a project-based onboarding for two weeks. The project is designed to introduce the basics of working with internal systems: Git, JIRA, standups, code reviews, retros, and so on.
These are all the most boring aspects of software development - those things that suck the soul out of the fascinating craft of programming.
I wouldn't be surprised if those junior developers left and never went back to software development.
52 comments
[ 3.3 ms ] story [ 88.2 ms ] threadEarly on we didn't have a program like this and this went poorly. We had juniors and even novices joining us without any direction or goals. They were unproductive, disconnected, and discontent. Many would eventually quit hoping for something better.
Since then, we have iteratively built up an onboarding process similar to this. Today, we have people dedicated to the first weeks of a person's employment. We have a curriculum that we follow to ensure nothing is missed. We have several mentors in each team. Depending on the employee's interested and the company's needs, they will have the opportunity to try different roles on different teams. Along the way we continually check in with them to see how things are going and if there's anything we missed it that they would like to change. We take those requests seriously and act on them promptly.
The results have been astounding! Our new hires are happy and productive. They recommend us to their friends, helping us to find excellent talent faster and cheaper than online job postings or career fairs. The feedback they give us helps is to improve the process to the point where we typically have few if any minor issues and no major issues.
I highly recommend taking a similar approach if you find yourself in a similar approach as a hiring manager, mentor, or team lead.
(Personally I'd've hated spending two weeks before doing anything productive)
At my last role, and I’m sure others at large companies, up to a week of time was wasted doing training modules on the intranet, no real work.
I mean that sounds like what the article's approach would amount to in practice? What's the distinction you see between "structured (rather than ad box) intro to internal tools" and "a week of time was wasted doing training modules on the intranet, no real work"?
"just giving a junior task and some guard rails to “figure it out”" worked great for me - a lot better than every structured training programme I've seen since. Shrug.
An example of the structure is that we have a curriculum figured out. We know what tools, techniques, and domain knowledge our new employees need within each team. An ad hoc approach like we used to follow would have individual managers or mentors giving an overview off the top of their head, then answering questions as they come up. This is a good start, but lots of important things get missed and new employees don't know to ask for information that they don't know exists.
Another example would be with mentorship. In many situations, new employees aren't given a single point of contact with someone whose duties including supporting them. In other circumstances, they will be told to ask anyone about anything, or to ask their manager or team lead, but often new employees are too timid to ask, or don't know who to ask, or the assigned person may be too busy or otherwise unapproachable. Having a plan and making sure everyone is onboard with it is important, but it's not always considered.
So how do you make sure your programme doesn't turn into that? Is it just a case of "have a good training programme, don't have a bad training programme"? Again it's weird to have the article use so many comparative terms and not talk about what you're comparing against and what the critical differences are.
> An example of the structure is that we have a curriculum figured out. We know what tools, techniques, and domain knowledge our new employees need within each team.
So how do you know it's right, and especially how do you keep it up to date? A lot of those terrible training programmes suffer a lot from having what was originally thought to be a good curriculum at the time.
> Another example would be with mentorship. In many situations, new employees aren't given a single point of contact with someone whose duties including supporting them. In other circumstances, they will be told to ask anyone about anything, or to ask their manager or team lead, but often new employees are too timid to ask, or don't know who to ask, or the assigned person may be too busy or otherwise unapproachable. Having a plan and making sure everyone is onboard with it is important, but it's not always considered.
Making a single point of contact mentor work sounds like something concrete that many companies don't do or do badly. How do you make sure people are properly incentivised/rewarded for mentoring well? Do new joiners have any way to recover if they end up with a bad mentor (given that having the mentor be their single point of contact/responsibility cuts both ways)?
Part of the call to action is to spend the time to hire and train juniors instead of just looking for ready-to-go seniors. It provides the employer with a larger pool of talent at lower cost, an ability to shape their skills and practices early on, and helps the entire industry grow.
If only a week. I spent a month on this at my current company.
If the primary cost of younger engineers comes from helping them get on board with how things are done at a given shop, this seems like it offsets the initial learning curve quite well. You could argue that the learning curve takes a lot longer, but surely there's an 80/20 rule at play here where the most important 80% can be learned in the first 20% of one's tenure at a company.
Underpaying a new engineer doesn't solve anything. It's honestly just shortsighted laziness or already having a staff of engineers who aren't good enough at their craft or communication to be good teachers.
If you're paying someone $1000/week you're paying them $50k per year and by your staircase approach you save.... one weeks worth of salary or 2% of the first year which ends up just being an insult to the new engineer and unnecessarily making their lives harder taking money out of their pocket when they need it most (getting a new job having not had a job or having to switch with the gap in income)
Sure, but you would imagine the Nth week of onboarding to be more important to improving an engineer's productivity on average than the N+1th week. It may not always hold, but it's certainly what my personal experience has been.
>Underpaying a new engineer doesn't solve anything.
You could always take the money you would "save" during the staircase and offer it as an end of year bonus or some such to those who remain onboard. There's no law saying this has to result in lower pay over the long term.
>unnecessarily making their lives harder taking money out of their pocket when they need it most
It's true that such a plan incentivizes people to have some cash saved up so they can weather the first few weeks better, but even if they don't one would imagine a quality hire would be able to get a short term loan at a very good rate, considering the high likelihood that they would be able to pay it back quickly.
Instead of just accepting a job that doesn't have weird staircase salary structures? Good luck finding this unicorn quality hire.
One only has to browse a place like r/cscareerquestions to get a sense that many people, early career especially, find themselves in this situation - stuck perhaps in the dreaded "can't get hired without experience, can't get experience without getting hired" catch 22.
Percieved risk is higher for people with less industry experience. So if you believe, as I do, that people systematically overestimate the risk they take on bringing juniors on board, and hence systematically underhire them, then this would likely end up being good on net for juniors, as more of them would then be offered a chance to prove the bias wrong.
Considering the above is given, I have seen this method applied successfully before because it is at the intersection of easy, exploratory and boring.
Easy builds up the confidence, exploratory creates the excitement, boring brings the thirst for more.
(Which is to say, it's a great idea, which is why it's already an industry standard.)
I think there might also be a different between interns and juniors. Where I'm from, interns are people who are hired specifically for a short period of time, often people still in their education. This is in comparison to juniors who are expecting permanent, full time employment. The amount of training and responsibilities given to juniors is much greater than that given interns because there is a much greater return expected.
The trick is to find the most productive trade of time. Not too much obviously, but very likely not zero.
Doing nothing is a big opportunity cost.
Im this case I don't feel like it's AI.
The original article in question (part of a series): https://djspinmonkey.github.io/2023/07/10/ignite-hiring/
Still it missed “how should I fire new junior engineers”
https://djspinmonkey.github.io/2023/07/10/ignite-hiring/
maybe part of the assessment process isn't delineating junior vs senior, or feigning some total order, but rather embracing that there is not, in general, a total order on talent among people.
it might be like seeing how well the hiring company can exploit the major eigenvectors of talent in each individual.
perhaps that's a wordy version of the rotating folks through different tasks idea?
It’s about this person with a decade of experience at professional scale needs a lot less handholding than this one fresh off the turnip truck, aka bootcamp.
Look at how hard they are trying to bore the new developers to death:
>>> They go through a project-based onboarding for two weeks. The project is designed to introduce the basics of working with internal systems: Git, JIRA, standups, code reviews, retros, and so on.
These are all the most boring aspects of software development - those things that suck the soul out of the fascinating craft of programming.
I wouldn't be surprised if those junior developers left and never went back to software development.