The best approach I've seen for hiring junior engineers
rubick.com
rubick.com
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.
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”
(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.
(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.
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.
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.
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.
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.