Preparing for a junior developer interview
I recently gave advice to a friend on how to approach technical interviews, and thought I should share it here.
If you’re anything like me, you probably hate being watched while trying to solve a problem. Don’t us introverts work with computers for a living so we don’t have to interact with people?
Live challenges can be flawed in many ways (aren’t all interview strategies?), but they remain a reality for most software positions. And like them or not, they do serve a purpose: to expose your real-time thought process.
Chances are you will be asked a lot of hard questions at your job, often in front of other people, and you won’t have an answer to everything right away. But creating structure out of a structureless moment is an essential part of a developer’s job, and good tech interviews should give insight into how a person does that.
Recent bootcamp graduates, and other junior developers I’ve known, put a lot of focus on the content factor for these interviews. They believe preparation involves guessing what topics the interviewer might ask them, then reading up on those topics. Of course this is a necessary thing to do, but if your only preparation is to read or code on your own, you are not practicing the most essential thing you’ll be doing in the interview: talking to people.
Getting good at live interviews is learning how not to freak out in that moment when you’re asked a question and you have no idea what to do next.
So how do you get more comfortable in that moment?
The first step is to discover—and refine—your mental process for solving problems. The second is to practice verbalizing that process in front of other people. Focus on process as much as content.
For most junior interviews, how you articulate your thought process is just as important as getting the answer right. Interview questions are meant to be hard, maybe even unsolvable in the amount of time given. An interviewer is trying to get a sense of how you think, not just what you know.
When I don’t know how to solve a problem, I use this strategy: I try to think of the simplest solution first. I make it known to the interviewer that this may not be the correct solution, it’s just the simplest one. Then, I explain the benefits and drawbacks of that solution. I then evaluate (out loud) whether the benefits outweigh the drawbacks. If the drawbacks are too consequential, I’ll try to think of a solution that will solve for these drawbacks, and restart the same process. This may not get me to the correct answer all the time, but the method is a solid one, and over time I’ve learned how to evaluate solutions more quickly and thoroughly.
Many junior devs skip this process, or try to do it only in their head. To me, that’s a missed opportunity to have a meaningful discussion with the interviewer. Being able to recognize the relevant benefits and drawbacks of a solution is a sign of good judgement, knowledge, and experience. I wouldn’t want that to be missed.
The single best thing you can do to prepare for an interview is to do mock interviews. Ask what the format of your next interview will be—remote or in-person? In a group setting or one person at a time? Format your mock interviews accordingly. Ask a mentor, friend, or former teacher if they’d be your mock interviewer. All the times I’ve prepared for an interview this way, I’ve never regretted it.
