When it comes to hiring engineers, it seems to me that most companies subscribe to the "conventional wisdom" of hiring experienced (a.k.a senior) engineers. They want people that "have been there", "done that" and who can "hit the ground running".
While there is nothing wrong with hiring senior engineers, the fact remains that there are more job openings than there are senior engineers to fill them. This scarcity leads companies to "cannibalize" on each other's resources while overlooking a perfectly legitimate pool of high quality resources.
In the past couple of years I was fortunate to work with some really bright "junior" engineers and I decided to sit down and summarize that experience and why I believe that hiring up-and-coming engineers is not only a viable alternative but in fact an advantage.
Remember those 12 legacy systems you have that don't really talk well to each other? Yea, so they're gonna have to understand how they work. Remember that huge monolith code base that is severely lacking in documentation? Right. So they're gonna have to spend a fair bit of time wrapping their heads around that one. That's where the real learning curve is!
Likewise, motivated people will compensate for what they may lack in knowledge with sheer determination in order to achieve results. I'll hire that kind of person over any senior engineer you put in front of me with indifferent attitude any day.
My approach was simple but effective: treat them as professional adults, give them just enough to get going on the task at hand and check up on them every now and then to see if they need any help. That's it.
The "overhead" in training them (which added up to maybe a couple of hours per week) paid itself many times over as these fledgling engineers became more and more productive and were able to tackle bigger and bigger tasks.
If your company has policies that forbid hiring junior engineers, it may be time to revisit these policies. Be as picky as you like in your hiring process but don't let past experience be the main drive behind your hiring decisions. Look for bright, promising candidates who can compensate with their attitude for what they lack in experience.
I think it is important to have at least one experienced person on the team -- to point out traps that junior engineers can avoid, and guide technical quality. But hiring all senior engineers doesn't seem very cost effective considering the limited availability of resources. It is also really fun to be part of the journey that new devs go through. So many discoveries and "ah ha" moments.
Thanks for this article. I hadn't seen it before. I must say I agree with it wholeheartedly. When I started, I self-learned a language or two, but I had no mentor to teach me good programming practices. I had to learn everything the hard way. I still have to maintain systems from those early days with enormous technical debt. I am happy to mentor juniors to save them (and their users) from those same mistakes.
If I were one of those super guru consultants paid to advise companies on how to plan their future I would yell to the CEOs: hire junior devs alongside your senior devs. Fortunately, for the yelling part, I'm not.
I think it's a serious mistake having only super experienced developers in the long term. It makes sense when you're starting up but in the long run you run the risk of having a few super experienced devs which individually know a lot of the business and when (note I didn't say if) one of them leaves (because they are sought after more than the junior devs or because of burnout) you find yourself in a bad situation because they take away with them not only their own expertise but the knowledge of your business domain. If the company bothered to train juniors it would have lessen the impact.
Yeah, I love this. Get someone who is creative and can attack a problem from different angles. Sometimes, even an experienced person will do the same thing over and over because of that experience. It's through experimentation that makes code better.
Agreed. Love this: "motivated people will compensate for what they may lack in knowledge with sheer determination in order to achieve results." Amen.
Why I love hiring Junior _________.
What you've said is also often true in other industries and professions.
Junior Engineers are great. They are usually young, enthusiastic and super motivated. It's easy to see the progress curve of a junior engineer. However, since the quantity of them is too high, we also need someone like you who is ready to give a different perspective to each individual candidate.
Completely agree, this has been my experience with hiring as well. A solid junior (good CS fundamentals, problem-solving mindset and lots of motivation) would catch up with or even surpass a medior/senior in no time.
Junior level engineers are going to remember quite well those companies that turned them down. And when those companies need new seniors, because their fleet has moved on/retired, they'll be wishing they'd played smarter.
Brilliantly written post. Thanks for sharing this, Arik.
Having only Juniors will fail because of lack of experience of troublesome situations and because they will most likely build something unnecessarily complex.
Having only seniors will most probably lead to a lot of personal issues because each of them has a very fixed opinion about how to do it right. The storming phase will be long and norming hard.
So, I'd like to have one or two seniors and a mix of juniors and intermediates.
I am a junior web developer and it's been three months since I started searching for a job in web development filed. 80% of job posting says 'Senior/10years of experience/etc' and they don't even want to consider junior candidates. I have been coding for fun for three years, I also have a college Diploma, portfolio, I know React/Redux, Node, PHP, the only thing I lack is a professional experience. And that's a real problem for me. Hope one day this attitude will change. Thank you for your article!
I have no doubt that you will eventually find a company that deserves your services. Just keep putting those communications out there. It may be frustrating at times but it just makes getting that first job experience that much sweeter.
I disagree with the conclusions even though I've observed the same thing.
I'm not saying don't hire Juniors, but rather more carefully evaluate what it means for your business if there is such a benefit to Juniors or lack of benefit in hiring senior practitioners.
The whole point of hiring Juniors is that while they learn they are supported by ever improving seniors, who they may overtake. This read a bit too Junior friendly.
Of course you should hire both, but if one of the reasons is motivation, what is de-motivating your engineers? Are your expectations reasonable, or are you just waiting to become a movie meme waiting for TPS reports needing people to come in on Saturdays?
About a month or so ago, I switched from QA to development and some of the more senior level engineers on my team have expressed how great it is to have juniors asking lots of questions during code reviews to bring up discussions and making the code base better overall.
Some of these discussions would either never happen or things would probably go unnoticed without this kind of engagement.
Having a successful team isn't always a group of "cowboy/girl coders" but getting a rag-tag group of average people who can self-police and learn from their mistakes. I agree that it helps to have someone experienced on the team, but if you have complimentary experience, everyone gets to grow.
I completely agree, my hiring experience is the same. My best performing team members were hired as Juniors and came up to speed incredibly quick. They are so eager to learn that they are also flexible about the tasks you give them. Some Seniors can be very picky about that.
One other aspect is that Juniors emerse fully in the company culture and tend to be the driver behind positive change. You just have to encourage them to speak their mind and to be on the lookout for improvements.
This is rich: "Someone who is a quick learner. Someone that can get the ball rolling without you having to sit there and hold their hand."
Uhm, you mean like an experienced developer?
You also appear to be implying that experienced developers are unmotivated. Did I get that right?
I'm thinking a proven developer is more valuable than an unproven one.
Junior developers are great -- if they work out. If they don't, they are a huge time sink.
My experience with juniors is mixed. There were some who have learned quickly and eagerly, but there was also a fair number of those who didn't yet know what they don't know, so they thought they knew everything.
If you work with other experienced people you can in most cases rely on them not to do very stupid things. With juniors you don't have that luxury, and it takes more time to explain to them why what they did was wrong. It takes all kinds, I'm sure, but if what you're doing matters, I think the ratio should be something like one junior per two seniors.
Honestly, the name itself, senior programmers, is silly. I just call them programmers. You don't go to a senior doctor or a senior hairdresser, do you?
Agreed, I might be bias as a junior data scientist though :) BTW, if anyone is hiring and looking for a dedicated data scientist I'm available.