A live coding interview is a lot of pressure for the candidate, but what no one mentions is that it’s also a lot of pressure for the interviewer! You need to come up with interview questions, you want to make sure the candidate has a good experience and impression of your team, and meanwhile you’re trying to accurately assess their technical skillset.
To help technical interviewers do their best, our engineering and assessment development teams at CodeSignal have some expert advice to share. This post will walk you through tips for becoming a better interviewer in two key areas:
How to create a good interview question
You know that dopamine rush from completing a puzzle that felt challenging, but fair and doable? That’s what you want candidates to experience. To achieve this, picking the right question is key.
1. Make it open-ended
As a human conducting the interview, you have the advantage of being able to ask questions that are more open-ended than those you might build into a screening test. Whereas a test has clear test cases and requirements that the candidate is implementing towards, in a live coding interview you have more flexibility. Try creating less prescriptive scenarios where, like the real world, there are a myriad of ways to approach the problem — and the candidate needs to do a little exploring and information-gathering to even define what the problem is.
For example, you might tell the candidate to imagine that they’re working on a certain type of application and encounter a certain type of common problem. Their open-ended task is to design an interface to help solve this problem. If they have some experience in the domain space, it gives them a starting point — but even if not, they should be able to find their way by asking clarifying questions.
Open-ended questions have several benefits. First, they can be realistic and relevant to the job that the candidate is going to actually do. This is not only more fun for the candidate to solve, but it will provide you with a better understanding of how they approach everyday problems. Are they encapsulating their code? Are they thinking about how it will look to a consumer? Are they considering edge-cases and error handling?
Secondly, open-ended questions involve communication and back-and-forth between you and the candidate, which is a way to establish rapport and put the candidate at ease, as well as understand what it might be like to work with this person.
2. Build-in layers of complexity
You don’t want your question to require an initial information-dump, which can be intimidating and take up valuable time. Instead, it’s a good idea to create questions that gradually progress in complexity as the candidate solves each simpler piece.
For example, you might first ask the candidate to build an interface for a basic use case. Once they’ve succeeded at that, you can give them a new, more complicated use case and see how they would approach solving that problem. If it involves extending or modifying their original solution, you’re able to test a realistic software engineering skill: how the candidate ties together different pieces of code and makes connections to reuse functionality.
By revealing the complexity a piece at a time, you can help the candidate feel like they’re solving progressively more difficult coding interview challenges — this creates a genuinely satisfying candidate experience. You’ll also be able to use the same interview question across a range of experience or skill levels, expanding based on how far someone gets. It’s less stressful for the candidate, too, as they won’t be thinking about falling behind or making it through the rest of the questions.
3. Draw from your experience
It’s really easy to take inspiration from a question bank online, but then you end up with a question that’s the same as what everyone else is asking. Or, your team could end up with five interviews where everyone asks a similar algorithmic graph question!
If you create a question that’s relevant to the work you do, it’s much more likely to be both unique and interesting. Simply start by thinking about what you do. Is there a toy version of a problem that you’ve seen in your real work that you can extract and turn into something fun and interesting?
And keep in mind that although it’s great to make your question unique, it needn’t be obscure and unheard-of. If someone has worked on a similar problem before and they recognize it, that’s OK. You’ll be prepared with your progressively more complex follow-up questions, so you can see where the candidate is able to get from there.
How to run a live coding interview
As the interviewer, you have a lot of influence over whether a candidate ends up taking a position with your team — and what impression of your organization they walk away with. It’s important to make a candidate feel comfortable in the interview, as that’s how they’ll do their best work and come away with the best impression of the team.
1. Practice with mock interviews and shadow interviews
One of the best ways to get comfortable with interviewing is to interview your teammates. When introducing a new engineer into the hiring pool of interviewers, it’s a good idea to start by conducting a mock interview session. Ideally, there are three people in the session: one person to simply observe, the trainee who conducts the interview, and an experienced interviewer who roleplays as the candidate. After the session, teammates can provide feedback on where the new interviewer might have done better at helping the candidate along or using clearer phrasing.
Mock interviews are also a great way to do what too often gets overlooked by interviewers: preparation. Preparing for an interview by knowing which core tasks and questions you plan to use is important for staying consistent across interviews.
Another helpful practice strategy is live shadowing. A new interviewer can start by watching an experienced interviewer and learning how they interact with a candidate. Then, they can conduct an interview themselves and have an experienced teammate shadow and provide feedback afterward.
2. Be helpful, but don’t give too much away
Candidates will ask you clarifying questions during the interview, and this is a good thing. But it can also create a balancing act for you — you want to be helpful, but you don’t want to reveal the solution or make the problem too easy.
A good rule of thumb is to put the question back to the candidate. If they ask you if their function should be throwing an error for a certain edge case, respond by asking them what they think should happen. Put them at ease by explaining that it’s up to them: you want to figure out how they would approach this design decision, and there’s not necessarily a right or wrong answer. (Never go silent, which can be very intimidating!)
It’s also important to try to be aware of when your human bias might be causing you to interact differently with this candidate or offer them more help. Feeling a sense of rapport with someone is a good thing and a natural human tendency — but it’s not a good thing if that influences the kind of guidance you provide in the interview.
3. Use a realistic coding environment
Okay, as the makers of a cloud IDE for technical interviews, we’re a bit biased here. But as engineers who have been through our share of interviews, we’ve also struggled with minimal tooling — like having to verbally describe an algorithmic process during a phone screen, or being asked to implement an LRU cache in Google Docs. It’s not impossible — but it’s not fun, either.
We recommend using an interview platform where the candidate can write and run real code. They’ll be more comfortable, and you’ll see how they actually use practical, on-the-job software engineering tools.
CodeSignal is designed to save engineering teams time and hire faster by helping them conduct their technical interview process with one easy-to-use cloud platform. Interested in learning more about CodeSignal? You can request a free demo here.