Last week, we saw that your available hiring pool is inexperienced, and that you have to prepare your junior developers. If you’re going to hire junior developers, you’re going to have to take their interviewing and preparation seriously. This week, we’ll see how to do just that with 3 tips for interviewing and mentoring junior developers.
First, your mentors have to love mentoring junior developers. A mentor who is passionate about this work will actively recognize skill gaps and seek to course correct throughout the junior developer’s hour by hour and minute by minute activities. A mentor who is passionate about this work will be a trusted confidant, allowing the junior developer to feel comfortable asking for guidance and comfortable to admit they need help. A mentor who is passionate about this work will stop at nothing to ensure that no mentee gets left behind.
Contrast such a mentor with the assigned uninvolved instructor. The assigned instructor probably has a lot on their plate already, and they don’t necessarily take absolute joy in working closely with junior developers. They may mean well, but their instruction will be limited. They may forget just how little they really knew when they got started. They won’t actively seek out the skill gaps. They won’t carefully navigate a junior developer’s Imposter Syndrome, and won’t actively encourage them in order to neutralize it. They won’t stop to explain in great detail the things they’ve come to take for granted. They’ll be a mentor in name only. You’ll wind up with a false sense of accomplishment with your mentorship program, while completely missing 1000 pivotal teachable moments.
Second, mentorship needs to be an official, recognized, respected part of your mentors’ time commitments. For a while, this is their job. Otherwise, their instruction will be one sided as their other full time job will take precedence over and over. Your mentors cannot simply do this as a side interest. It has to be a fully recognized part of their responsibilities.
Third, put your mentors in the driver’s seat during the interview process.
In a senior-level interview, I’m looking for signs that a person is already prepared: their work speaks volumes about their real-world experience, they already show signs of leadership, they have developed habits that give an impression of carefulness, and they’ll barely need any onboarding before they mesh well with your team. You’re confident you can point them at a tough problem right away, and that they’ll take complete ownership of it from inception to delivery.
In a junior-level interview, you’re looking for something completely different.
Leave your favorite brain teaser at the door; that was all about you anyway. You’ll have relatively little job experience to dig into. Instead, create a miniature mentorship experience between the interviewer and the candidate. We have a coding exercise in which a candidate submits a solution in advance, and we pair on that solution during the interview. The problem is complex enough that we see several different solutions and several different missteps across candidates. For each candidate, we go into the interview knowing which missteps they took on their own, and what we would want to teach them had they made the same missteps on a real project. Over the course of an hour, we work closely with them on their solution, driving it toward one improvement or another. We keep it as Socratic as possible, guiding them by asking questions rather than providing answers.
In this exchange, we look for a productive back and forth between mentor and mentee, paying special attention to whether the candidate makes connections between important ideas, whether they retain and then use our advice later on, and whether they have those delightful, excited “AHA!” moments as they learn something new. A candidate who exhibits those qualities is an instant hire in my book. Given that we take our mentorship time seriously, we will surely set up such a candidate for success by the time we put them onto a client’s project.
The interviewer should walk away from the interview with a clear understanding of the candidate’s strengths as well as at least one habit or skill gap worth focusing on during onboarding. Otherwise, the exercise didn’t dig deeply enough.
When I think of the junior developers we’ve both hired and prepared here, I can say with all confidence: you want them to work on your project. They are every bit as effective, professional, serious, conscientious, deliberate, and intelligent as their senior peers, and they got there in 1/10th the time. What took me 20 years, they accomplished in 2, and all we had to do was take their development seriously for a few weeks.