Here are my raw speaker notes for my Web Directions Code Leaders talk, titled “Hiring Juniors”. The video will be online later.
The slides for this talk are available here on Speakerdeck
Intro
[slide]
Hi, I’m Ryan. You know that part already. What you might not know is that I’ve been mentoring juniors on-and-off for close to a decade now and I’ve had varying rates of success.
I’ve mentored juniors who have gone on to become lead developers at tech companies you’d probably know about.
But, at the same time, I’ve also mentored juniors that have quit the industry altogether.
Recently, I’ve spent about the past 10 months recruiting, hiring and training up juniors as a part of the Culture Amp Junior Engineering Program and today I’ve got some things about that process to share with you.
Today I’m going to tell you a little bit about our Junior Engineering Program, why I think hiring juniors is the right move – by the way of a short story – and finish up by sharing some tips about what you can do with the juniors that you’re going to hire soon.
[slide]
You’ll be pleased to know that there is absolutely no subliminal messaging in this talk at all. It’ll be just some plain speaking from yours truly.
Mentoring juniors is something that I am really passionate about and I’m hoping today some of that passion will rub off on you. My goal for the end of the talk is to convince you to hire and mentor juniors at your own companies.
Culture Amp’s Junior Engineering Program
[slide]
So let’s start with Culture Amp’s Junior Engineering Program.
At Culture Amp, we decided we would run a structured program for juniors as a way of teaching juniors skills that are relevant to our industry today. This is kind of like the antithesis of a university computer science course. Not a line of C or Java in sight.
The idea behind the program is that, over time, we would be able to bolster our best and brightest with some new faces who could help us out.
We ran our very first Junior Engineering Program recently, for 6 months – from November last year until June this year.
[slide]
Before we started this program, we had 5 juniors already working at Culture Amp, and then we hired another 5 on top of that for a total of 10 juniors across the company. We put all of our juniors through this program.
These are a mixed bunch of fresh faces all with varying backgrounds. Not all of them have CS degrees, or have even worked in IT, for instance.
Just as a comparison to how fresh their faces are, all of them have a much fresher face than what I had as a junior developer.
[slide]
In the Junior Engineering Program, we taught these 10 developers the foundational skills that they needed to be confident and capable developers within our tech stack. We taught them Ruby, Rails, two different kinds of databases and a whole suite of JavaScript tools, all within 6 months. They know these things and a lot more now.
[slide]
During the program, the juniors worked part of the time with me working on learning this tech stack, and part of the time with one of our development teams, fixing bugs and delivering features. This split was designed to give the juniors the opportunity to be taught these skills, as well as a chance to get some real-world workplace experience. The best of both worlds. On one hand: they need the training, but on the other they also need the real-world job experience in order to be truly effective people.
We chose to run a structured program because it would allow us to train up a bunch of people all at the same time, on all the same skills. This would also mean that they could support each other throughout the process. If we brought on only a single junior it would be a “The Junior vs The World” type scenario, which can feel quite intimidating and disheartening. This is not the experience we want for any one, junior or not, to have at Culture Amp.
During this program really encouraged the juniors to succeed and to grow their skills together as a group, despite whatever struggles they might encounter. This “shared pain” aspect of the struggle is important: it makes juniors feel comfortable about being in a position where they don’t know all the answers, and someone else also doesn’t know the answer with them. They then could puzzle it out together. If they got stuck, there was still a support net of knowledgeable people who could help them out.
Hiring a bunch of juniors and running them through the Culture Amp Junior Engineering Program worked extremely well. The juniors that we hired in November are now confident and capable members of our teams who have helped ship real software that thousands of people use. We are very proud of what our juniors have been able to accomplish in just half a year.
[slide]
In fact, the program was so successful that we’re going to be running it for a second time… real soon now.
Juniors makes your team better
Now that’s just how we’ve chosen to do it at Culture Amp but a structured program that hires cohorts of junior developers every 6 months isn’t the only way to train juniors at a company.
You don’t need to be a large established organisation, and you don’t need to run a structured program to be able to hire and support a junior.
[slide]
I reckon if you’ve got at least 4 senior developers within your organisation, your next hire should be a junior. As long as you’ve got someone within that group who can dedicate some time to supporting a junior, you can do it.
And it’s not like it’s hard to hire a junior at the moment, either.
[slide]
But why would you want to hire a junior? Won’t juniors slow your team down dramatically, leading to precious productivity losses? Yes, that is unavoidably true. On the you day you hire them, they will do that. And the day after that too. And the next week. But over time, and with mentoring, they will improve and productivity will be even better than before.
I admit that that point isn’t a great one with a lot of evidence to back it up. So I have a greater one to make.
[slide]
One great side-effect of hiring and working with juniors is that everyone else will get better at what they’re doing because they’re now working with a junior. And it will be almost instantaneous. Well, it will take a week or two, but they will get better.
This is because mentoring junior developers forces the people doing the mentoring to slow down and methodically explain their thought process.
It makes them think of things and explain them in different and, usually, better ways. They have to practice really understanding something and being able to explain it to someone who doesn’t know it.
Sometimes, they might even find out that they thought they knew something when, in fact, they didn’t know it very well at all.
Mentoring juniors can be quite humbling in that regard.
The Junior, the Monolith and the Microservice
[slide]
One of my favourite stories around this point is about what happened on a team of mine when we hired a junior, back when I was a senior developer at Culture Amp. Long before the Junior Engineering Program.
At the time, we were building a new micro service, as was, and still is, the cool thing to do. For extra street cred: this micro service is even event sourced and written in Ruby on Erlang, oops I mean Elixir.
My team would often talk about the Elixir microservice in high-level terms because the team was quite senior-heavy. Us senior developers knew what we were talking about, or at least pretended to – after all, we all have big senior developer egos to protect.
When this junior joined, they asked a lot of questions about the microservice. We tried our best to answer these questions. We tried explaining things to them using the jargon that we had all collectively built up. It didn’t work. We tried again using different jargon. It still didn’t work. The junior was still terribly confused.
So I ended up drawing up a diagram of the two systems, our monolith and the microservice, indicating the different parts that were involved. It was this little thing.
I stuck it on a wall in our team area and gave the junior a copy too. This worked! The junior wasn’t confused anymore. The junior was able to look at the diagram and figure out how the two systems worked together. They understood what our jargon meant because it was labeled clearly on the diagram.
But then a really funny thing happened. The seniors started using the diagram more, and more, and more. We talked about the micro service a lot, but when we did we involved the diagram in a lot of those discussions. We used terms listed on the diagram rather than our own words for it. We even re-drew the diagram a few times. We, the seniors, ended up using the diagram more than the junior did!
By having this junior join our team we soon realised that one of our blindspots was how we communicated about this microservice. The junior’s joining led to this creation of “The Diagram” and led to us all communicating more effectively about this microservice. Ultimately: It made us a better team.
This is a small example, but quite a good example of the kind of benefit that adding a junior brought to team that I was a part of.
[slide]
Now wouldn’t you like that kind of thing in your teams? The one simple trick that I have to share today to make your teams better is to introduce a junior into that team and then to have the team mentor them. I’ve seen this improve teams again, and again. It’ll work for you too. You have my money back guarantee.
[slide]
I want you to hire at least one junior because I know from my experience and the experience of teams at Culture Amp that it has most certainly made our teams better. It will make your teams better too.
My three tips
[slide]
Now that I’ve utterly convinced you 100% to hire a junior, I want to talk about what to do with them once you have them. This is the scariest part, but I have three easy tips that can help you.
Mentorship
First tip: Assign a mentor.
In order for juniors to grow into amazing superstar developers, you must provide them with the mentorship and direction that will get them there.
Juniors are going to need a lot of love and attention. You can’t just put them in the corner and expect them to thrive. It won’t work!
[slide]
Think more of them like a puppy than a cactus: the puppy needs love and attention and some training, but the cactus needs only sunshine and some water. The cactus is indifferent to your love, your attention or the intensity of the training you provide. Cacti are going to Cacti.
Junior developers don’t grow into senior developers with just sunshine and water. And they don’t do it just by practicing development by themselves, either. They need mentorship and thrive on direction! So give it to them!
[slide]
At Culture Amp, we provide this mentorship by pairing each junior up with a mentor within Culture Amp from day one. This is someone who has been at the company a while and can show them the ropes. The mentor’s job is to work with the junior to grow their skill set. They do this by setting goals together, reviewing feedback they’ve received and other activities during weekly 1-on-1s.
While a junior is on a development team, the team supports them by pairing them up with a senior developer who then could help them work effectively on that team and skill them up in what the team needed.
We assigned people this mentor and paired them up within teams as we wanted the juniors to feel super-supported at Culture Amp. We want their experience to be one of overwhelming positivity because being a junior is already hard enough.
I want you to do this in your organisation too. A single point of contact. Someone who can be around for the junior. I want you to have weekly check-ins with the junior and set professional goals with them. Actively seek out feedback about how they’re going and work with the junior on things within that feedback. Support them as much as possible.
[slide]
The junior is going to need this support. Remember: puppy, not cactus.
It is always ok to ask questions
[slide]
My second tip is this: tell your juniors that it is always OK to ask questions. Repeat this as much as possible.
Or, if you have a junior at your organisation who rarely asks questions, really re-enforce with them that it’s OK to be asking questions. If a junior is asking questions it means that they’re looking for answers, and if they’re looking for answers it means they want to know something! So take the opportunity to teach them!
Alongside this, pay attention to what juniors are doing. Ask them if they need assistance at all. Maybe see if they’re looking uncomfortable, sad or angry. Sometimes, juniors can be too afraid to ask questions because they think they’re “stupid” questions. Asking juniors if they have any questions gets them to open up, and helps them feel supported.
Small wins matter
Third tip: Small wins matter.
When the junior joins your organisation, they’re going to have a large dose of Imposter Syndrome. A lot of “why did they hire me? I know nothing!”. You need to start chipping away at this right away and the best way to do that is to give them wins on the board. These things act as opposites to the feelings of imposter syndrome. Imposter syndrome is saying “you’re not good enough” and these wins are saying “you are good enough”.
Get them to fix typos, investigate bugs, dive into the source to figure out things. Encourage them to drive this effort as much as possible. They’ll feel better about things they were able to accomplish on their own.
Cushion them when they fall, but celebrate with them when they succeed. Chip away at that imposter syndrome piece by piece, and day by day by providing them with small wins. You can work them up to bigger and bigger wins later on. For the early stages, small wins are absolutely critical.
Feeling Welcome
[slide]
Ultimately, your mentorship should be about making the junior feel welcome and safe within your organisation. You’ve probably sensed this as a theme to my points already, but I want to take the last few minutes of this talk to really drive this point home: In fact, this should be what’s happening with everyone in your team.
[slide]
Don’t just take my word for it. Google ran a study called “Project Aristotle” wherein they attempted to find how to build effective teams. They interviewed hundreds of their own employees and they came up with 5 things that effective teams had consistently:
[slide]
[image:EEF8C544-A631-4F6F-8796-09A3F95F045D-94246-0000594A81D4A05E/eQ_WsRq5-q-m_41eEI6GLEObqpxBYJd1pm96gIa-eRSn-QXlPjwO5K6O-DHU8sxny3ChnIQE0mjpnXaaW7QAhQ=s0.png]
The #1 item on this list isn’t “Feeling welcome”, but “Psychological safety”. Same thing. The text underneath says: “Team members feel safe to take risks and be vulnerable in front of each other.” This is the #1 thing you should be encouraging your juniors to do. Take risks and be vulnerable. It is the way they will grow.
Juniors should ultimately feel safe to take risks and to be vulnerable in our teams. Juniors will make mistakes. This is the nature of taking risks. They will mess up from time to time. Give them space to make mistakes. It is how they will learn best.
The remainder of this list is not to be discounted. Dependability, Structure & Clarity, Meaning and Impact are all vital to junior developers progressions.
A junior must be able to depend on the people around them for support. They must be reminded that it’s always OK to ask questions. They must have people around them for that support who they can turn to and ask questions of.
They must have clarity on what their direction is and you can provide that with some solid mentoring and weekly 1-on-1s. Work together to set some goals for them during these 1-on-1s and help them work towards the goals. Gather up some feedback from their peers and talk about it with them.
The juniors must feel like they’re contributing back to a greater whole to keep them motivated and enthusiastic about what they’re doing. Give them meaningful work to accomplish and celebrate with them when they finish it. You can start with small wins, but work them up from there. Chip away at their imposter syndrome. Be their champion.
When you hire a junior developer, keep these things in mind and ask yourself regularly if you’re following along with them. These things should underpin everything you do with everyone in your organisations, but especially junior developers.
With a concerted effort to make the junior feel psychologically safe, and some semi-structured mentoring in place, they can grow into the future’s most brilliant developers.
Let’s hire and mentor juniors at all of our companies so that they become the next generation of amazing developers.