This post (and talk) is an updated version of my 2018 “Hiring Juniors” talk at RubyConf AU. This version of the talk was given at RubyConf Indonesia 2019 as the closing keynote. You can view the slides for this talk on Speakerdeck
Intro
Who’s hiring right now?
And who’s finding it easy to hire developers at the moment?
If you said it was easy to hire developers at the moment, you’re either very lucky or lying.
I work at a company back in Australia called Culture Amp and for the three years I’ve worked there I’ve never known hiring developers to be an easy task. There just isn’t anyone out there to hire! Everyone’s already working somewhere else. I hear this story from everyone I speak to.
It feels a bit like this.
But the industry is booming! Us developer folk are in a golden era of profitability and growth. To keep pace with that growth, we keep trying to hire more developers, but we have a really hard time with that.
We need to try something different. But what?
Hiring more mids and seniors doesn’t work, and so we need to look elsewhere.
The solution to this problem is to hire junior developers. That’s a scary concept, isn’t it? “Junior developer” evokes images of frustration, lost productivity and accidentally dropped production databases. But it doesn’t need to be scary. In fact, it can be the opposite.
I run a program at Culture Amp called the Junior Engineering Program where we have successfully hired and trained 18 junior developers to be the next generation of amazing talent at our company. And I’m so proud of them all.
You can do it too and I’ll tell you how.
“But Ryan, we only hire senior Ruby developers!” – ahh the classic ActiveMantra in the Rails community: “Hiring seniors. Hiring seniors. Hiring seniors.”. Maybe if we say it enough and click our heels together three times our dreams might come true.
But how’s that working out for you at the moment? Probably not so great. It’s well known that there are only three hard problems in computer science: cache invalidation, naming things and hiring more seniors.
We have drained the talent pool dry. And yet our obsession and our Active Mantra continues. We only want to hire seniors. But why do we have this obsession?
Well, we want a senior developer – but we might be happy to take a mid too – because they have the skills to instantly dive straight into our application with little-to-no guidance and they can start shipping code. That old expression: “they can hit the ground running”.
This is because our code is so brilliantly well-structured and organized according to the Rails best practices. Nobody will have to upskill on any single parts of the codebase at all because we follow the Laws of Sandi and Commandments of Avdi to the letter.
There is no legacy code with their legacy decisions that meta-programs the constants from Java, written in a hurry because we needed to ship that thing fast.
You may think that you need to hire only these best-of-the-best badasses because your application is a large unmaintable collection of event-sourced microservices written in obscure languages surrounding a ginormous monolith and only the badasses can understand it. That you need seniors to navigate the spaghetti that is your legacy code. Maybe you use technologies that only true geniuses can understand, like Node or Go. Or Webpack.
That may indeed be the case. After all, if our code was simple, elegant and only written in a single Ruby monolith, would as many of us still be employed?
Companies spend thousands of dollars hunting the elusive 10x Developer Rockstar Unicorns (note: term used ironically), but the Unicorns are no longer out grazing in the sunny meadows, readily available for capture. They’re already working somewhere else and the conditions of where they work are extremely competitive. The stables in which these Unicorns are now kept are filled with energy drinks, ping pong tables, lucrative salary bonuses and other extremely good perks. You will have a hard time luring these Unicorns away.
We’re out of freely available Rockstar Unicorns because they’re already employed elsewhere. Attempting to hire them is an exercise in futility. And so it’s time that we started to grow our own. It’s time that we started to hire and train our own 10x Developer Rockstar Unicorns.
But where do we find these developers? Well, to start with we need to lower our bar for engineering talent and not be so caught up on hiring the best-of-the-best now, but instead we should be investing more in people’s future potential. We should be hiring junior developers and training them up.
A very smart person once said this:
Your next Rockstar Unicorn isn’t within today’s top 5-10% of all developers. The top 5-10% already works elsewhere. Your Next Rockstar Unicorn is hanging out with the rest of their peers in the other part of this totally scientific picture that I made up. These people need some mentoring in order to grow into the next generation of brilliant people.
They’re not brilliant today, but if you give them time and care, they will become brilliant.
It’s imperative that we do this because there isn’t an endless supply of brilliant people – sorry, I mean Developer Rockstar Unicorns – that we can just keep harvesting today. This talent pool of amazingly gifted developers, as we’re painfully finding out, is not limitless.
The best time to train a senior developer was 10 years ago, but the second best time is now.
We must lower the bar for our hiring, and hire outside of the top 5-10%. We must hire juniors. We must then train these juniors up to be our next generation of brilliant minds.
It is very, very difficult to hire a senior developer today in Rubyland. And so we must grow our own senior developers. This is a process that will take time.
There’s no packet mix where you “just add water” and blammo you’ve got a senior developer.
I’m talking about years of hard work. But these are vital years of hard work to ensure that our companies and this community continues to thrive and grow. This is necessary work to ensure that we have well-trained developers working at our companies. We will know they’re well-trained because we did the training ourselves.
We need to be developers developing developers.
At Culture Amp, we hired and trained 18 juniors. We are not frustrated by them. Our productivity is the highest it has ever been. And right before I got on stage I checked: our production database is still up.
These are 18 developers that we did not have two-and-a-half years ago. But now we do. They’re about 25% of our engineering staff right now. We invested time and energy into training these people up and now we have 18 excellent developers. And that’s on top of the other developers that we’ve hired during that time too! We didn’t stop hiring mids and seniors. We kept hiring them too! It’s just that we supplemented them by hiring and training some juniors too.
I want to spend the next 20 minutes giving you some reasons why you would want to do this yourself, and some tips about how you can go about doing it too. I want you to leave here today as enthusiastic about hiring juniors as I am.
Why?
So let’s start off with the why. Why would you want to hire juniors? I told you already: we can hire juniors to boost the number of developers at our companies. But we’re going to need a better reason.
I have one major killer reason: juniors make your teams better. You want your teams to be better, right?
But wait: what do I mean by “better”? Better is a pretty subjective term! So let’s be more exact. I mean that your team will be more productive as a result of having at least one junior on it. I have seen this work out at Culture Amp many times over, and I’ve seen it happen at other companies too. Teams that have juniors on them are better than teams that do not.
Why?
When you have a junior, you have to break down explanations into simpler forms. This helps the junior understand things about your business, code and practices. It has the side-effect of easing the understanding of other members of the team too because they get into the habit of explaining things in a clearer way as well. There’s no better way for you to test your own knowledge of something than having to explain that knowledge to someone else.
Along that point, when you have a junior in your team communication becomes explicit. I reckon some of you might have experienced the opposite of this. Here’s the situation I’m thinking of: You’re on a senior-heavy team and you want to ask a question, but you don’t want to be seen as not knowing as much as the rest of the people around you. You have to figure it out yourself. It’s implicit. Communication is implicit. All in your heads.
Now what happens if you put a junior on that team? They’re going to need some explanations. Their intuition isn’t as well-crafted as yours is. So communication comes out into the open, which makes it explicit. This then creates a culture of asking questions and other team members feel safe to do that as well. We talk about things in the open more often and contribute to a shared pool of understanding. This improves the understanding of the entire team and therefore makes the team more effective.
My last point around “why?” is that diversity out-performs sameness. There has been many studies done on what makes a good team, and universally having a team that is not all the same as each other leads to the greatest benefit. I mean diversity in all aspects: gender, race, age, and so on. But I’d also like to give a special mention to skill diversity too. Having people who aren’t all experts on your team makes the team better.
So to answer the why question: not only will we get more developers if we hire juniors, but our teams will be better for it. We want more developers and better teams, right? The way we can get both is to hire juniors.
So now that I’ve answered why, let’s talk about the practicalities of doing this. The rest of this talk is all tips on what you can do to make hiring juniors into your companies really successful.
Part 1: Before
The first thing we need is some support structures in place.
First, we need the company to support the initiative of hiring junior developers. They need to recognise that taking on a junior will require some upfront investment of time and energy to train them up, but it will pay off in the long term. Juniors who are well looked after turn into mids soon enough.
Second, we need the team or teams that take on the juniors to support this initiative as well. These teams are going to be the people doing the majority of the training and development, and it’s their job to make the junior feel at home. A good team environment will help the junior developer grow in the best way possible.
Lastly, we need a champion who supports the juniors. Someone they can always turn to for support, who exists outside of their team structure. At Culture Amp, I’m this person and my role is mostly 1-on-1 developer mentoring and (sometimes) emotional support.
Once you’ve got those support structures in place, organise together to work out a plan for the people that you’re hiring. What are they going to do on their first day? How can you help ease them into what might be their first ever development job? What do you need to teach them for them to be productive at your company?
Having a plan for how to deal with the initial onboarding of a junior on your team can take a lot of that early-stage pressure out of the process. I suggest you spend a bit of time coming up with one. Every company is different and you’ll all come up with different ways that suit your own companies.
Part 2: Recruit
With your plan in hand, it’s time to start recruiting a junior developer.
Where on earth do you find one of these people? Fortunately for all us, they’re everywhere. They come out of universities and coding schools by the hundreds or even thousands. On top of that, there are a bunch of people who teach themselves programming. These people are usually career-changers who have worked somewhere previously, and are now looking to get into development. All of these are great candidate pools to source your junior developers from.
To find juniors, reach out to universities and coding schools and ask them when they’re next graduating a cohort, and ask if you can come in to speak to the cohort. Building those connections will help you source some amazing developers.
Now that you know where to find them, you’ll want to know how to find the best ones. For that purpose, I want to talk about how you should interview your junior developers.
Interviewing
I think a good interview process takes the shape of two stages: a take home coding test, and a second stage comprising of two interviews: a social interview and a tech interview.
Here’s how we’ve done it at Culture Amp. We sent anyone who applied a coding challenge written in Ruby, involving some basic Ruby tests for things like Arrays and Hashes. It also contained a test suite they had to extend and pass. They had two weeks to complete it.
When we received the coding test back from them, we scored it according to a bunch of yes or questions like “did they use an attr_reader here?”. The people with the highest grade then got through to the next stage, our social and tech interview stage.
In this second stage, juniors bring their coding tests in, and we interview them about their knowledge of tech during the tech interview. At the half-way point of the interview, we switch to a pairing mode where the juniors expand on their coding test. All of this is done with with two Culture Amp employees in the room – usually a mixed gender pair. We interview in pairs to eliminate bias that may arise during a 1-on-1 interview.
The junior drives the development of the code and can ask us any questions they wish – even down to what Ruby method they could use to solve a problem. We give them some direction and observe them go through this exercise.
This tech interview is designed to assess how well the juniors can work with other people – not to gauge how well they can code. This is because a junior developer will spend most of their time working with other people, listening to them and collaborating, rather than doing development themselves. It also helps us gauge how open they are to asking questions, or knowing when they’re stuck. These are important things to check because they’ll be doing a lot of that kind of thing when they come to work with us.
The social interview is the 2nd interview stage, and in this one we assess their social abilities by asking them a bunch of open ended questions like “What kind of projects have you worked on with other people?”. We value this interview slightly higher than the coding test.
What we look for in this interview is how friendly or outgoing the junior developer is, as well as any particular red flags. If someone champions their own efforts while diminishing the work of others, that’s a huge red flag. If they prefer to work alone instead of in a group, that’s another.
That’s a quick run-through of how we’ve ran our interview process, and from the almost 250 interviews we’ve done, I can give you three big tips for when you’re interviewing juniors.
Tip #1: Treat them gently
The first is to treat them gently. For some people you interview, this will be one of their very first interviews. If you’re both lucky, it’ll be their very first. You might be working with this person in the near future, so treat the interview like a collaboration rather than an interrogation. Treat them gently.
Here’s a quick image showing the regular job application process for junior developers these days. Juniors try to make the leap from learning how to program to getting paid to program and then they get rejected a bunch of times. This can feel a lot like leaping across a chasm and smashing into a cliff face repeatedly, hence the illustration.
We do not need to interview these juniors harshly or impersonally. We can treat them gently.
Tip #2: Social over Technical
My second tip is to value the social interview over the technical interview.
I would explain why in my own words, but Brian Hogan has done it on Twitter much better than I could:
https://twitter.com/bphogan/status/1173301278040035335?s=20
It’s true. I can teach an easy-going, well-humoured person programming easily. They’re fun to work with! But if you’re a grumpy, self-centered narcissist, we’re going to have a bad time.
All of the juniors that we have hired have scored good-to-excellent on the tech interview, but they’ve all scored excellent on the social interview and we’ve seen it work out really well as a result.
So my tip here is to value social skills over tech skills. You can teach tech easily. You can’t teach nice as easily.
Tip #3: Give them feedback
My third and final interviewing tip is to give all your junior candidates feedback on the process. Yup, that means everyone.
That coding test that we gave to our junior developers went out to about 70 people. 55 of those people sent it back. In response, we wrote 25,000 words of feedback, which is about 500 words per person. That may seem like a lot, but it’s really about a page to page and a half per person, depending on your font size.
We give out feedback to all our candidates because we want them to have a good impression of our company, even if we reject them. We want them to be able to look at the coding test and see what they could improve, and to have some resources they could follow up on to get better.
Being rejected is hard and a flat “no” with nothing further to follow up on is something the juniors are going to get a lot of. Remember the cliff face? So we should all be more gentle with them by giving them this feedback.
This feedback has paid off for us at Culture Amp. During the most recent Culture Amp junior hiring round, we had two candidates apply who also applied in the first round two years ago, but didn’t get through. By studying hard for a year, they were able to skill themselves up and they both made it in this time around.
So my third and final interviewing tip is to give feedback to juniors because it gives them a direction to go in, even if you reject them. And it has a good chance of paying off in the future.
A new junior appeared
Ok, so now you’ve gone through the hiring process, sent out all your feedback and decided to hire a junior. What do you do now?
Part 3: Belonging
You make them feel like they belong.
If you thought being a junior during the hiring process was hard enough, try working as one! It’s terrifying.
During the interview, juniors can feel like they need to prove themselves for, at most, 2 hours.
But then when they get down to working, they can feel that need to prove themselves for days or weeks at a time. That’s exhausting!
If you remember anything from this talk let it be this next slide.
How do you treat a junior developer? Like an adorable puppy, and not like a spiky cactus.
With the cactus, you can leave it for months in the corner without giving it attention and it will still thrive. Somehow. Science can’t explain it.
But a puppy! A puppy needs attention, love, and care. And to be trained!
Juniors need to feel like they belong in their companies, their teams and their jobs. With those support structures I mentioned before, the company, the team and the champions can all help with that sense of belonging.
I have some ground rules that can majorly help with that feeling of belonging.
One ground rule that I like to set at the very beginning is this one: it’s always okay to ask questions. Whenever you have a question it’s okay to ask it. Asking questions is how we learn. Asking questions means that you want to know something. It means you’re thinking. So ask away!
Another ground rule that I like to set is that juniors should pair with a more senior developer most of the time. Being introduced to a big scary company, codebase and team that you’ve never seen before is terrifying and exhausting. You need someone who can be the Gandalf senior to the junior’s Hobbit. You need someone who can help the junior integrate with your teams.
My third ground rule is one that can sometimes be the hardest one to follow. Smile more! When someone asks for your help, dive in with eagerness and joy. Someone wants you to help them! Don’t get frustrated with them!
And this also applies to text as well, where emotional meaning goes missing. A simple phrase like “why are you doing this?” can be interpreted majorly differently depending on the mood the recipient is in. “Smile more” with your juniors over text too.
If you feel like they’re still having a rough time, go around to your juniors and speak to them in person – or over a quick video call if they’re remote. I call this “escalating in fidelity” and it’s a technique I employ when I think I’m being misinterpreted.
Project Aristotle
I’d like to back up all this belonging chatter with one final thing. A company you might’ve heard of, one not far from here, called Google… ran this study called Project Aristotle. They wanted to know what made teams the most productive. They tried a bunch of things. Small teams. Big teams. Senior teams. Junior teams. Teams in the same room, or teams working remotely. None of it made as big an impact on team productivity as these five things.
These five things are the pillars of making teams at Google the most productive. And this does not just apply at Google. It’s universal. And I can think of nowhere else they apply more than helping juniors feel like they belong in our teams. The first one is the biggest: team members feel safe to take risks and be vulnerable in front of each other.
This diagram might look familiar to you. If you flip it up the other way and rename the layers, it is Maslow’s Hierarchy of Needs – Maslow’s take on how humans partake in behavioural motivation – how we get motivated to do the things we do. You’ll notice here that the bottom two layers on the right are remarkably close to the top layer in Google’s document.
When we hire juniors, we need to keep these five things in mind. We must put a strong focus on psychological safety so that they feel like they belong in our teams and that they can take risks as small as asking a “dumb” question or as large as merging a major pull request. And we must also provide Dependability, Structure & Clarity, Meaning and Impact too. But we can do none of those if the junior does not first feel safe – feel like they belong in our teams.
Summary
And so to summarise:
Hiring experienced developers is hard to do at the moment. To work around this current lack of talent, we must focus on hiring and training junior developers to be the next generation of experienced developers that we need.
We have done this at Culture Amp successfully. Plenty of other companies are also training developers. We need more companies doing it too. It is important work to ensure that we can grow our companies and this wonderful community of ours. Hiring juniors is a worthwhile investment for your company and for the future of this community. It’s in our collective best interests to hire juniors.
Putting at least one junior developer into a team makes that team better. Communication is explicit. The team works more effectively as a result.
When we get these juniors, we must remember the puppy-not-cactus rule. We have to make them feel like they belong in our teams – because they have as much right to be there as everyone else does. When we do this, we’ll supercharge the development of this junior and before we know it we’ll have a set of amazing developers who are helping our teams be the best version of themselves.
We can do this. Hiring juniors is the right thing to do.
We can be developers developing developers.