Data Structures and Algorithms: The Complete Interviewer Guide

The purpose of data structures and algorithms (DS&A) interview is to assess a candidate’s ability to go from high-level requirements to the optimal implementation of an algorithm that solves the problem.

A good candidate will be able to provide a working solution, adapt to requirements, and defend their choices with valid explanations.

As a Pramp interviewer, you’ll often be given a question you’ve already seen before to use to interview your peer. This is intentional. Interviewing your peer using a question you’ve seen before will make you a better interviewer — one who is more experienced, knows what to expect, and is able to give hints and feedback from a wider perspective.

As the interviewer, your primary objective is to assume the role of a hiring manager and simulate a real interview for your peer. It’s important to let your peer struggle with the problem and not offer hints preemptively. When in doubt, stay silent a bit longer before offering a hint.

The best way to help your peer is by giving them honest and detailed feedback on their strengths and weaknesses following the interview.

Consider the following key points to allow for a successful interview:

• Keep track of time to make sure you cover all key points
• Make sure you have a good enough understanding of the question you’re about to ask
• Encourage your peer to verbally communicate their thought process and approach
• Make sure you’re not giving hints preemptively, but only offering enough of a hint to lead the interviewee to figure it out on their own
• It’s okay if your peer is unable to get to a working solution. If you spoon feed your peer a solution, it may prove difficult for you to accurately assess their abilities
• Remember that the worst outcome from an interview is to decide that the person needs an additional interview before a decision can be made

Pre-Interview Preparation

Make sure you’re in a quiet environment with headphones. You may want to avoid using speakers as the feedback could be bad, thus making communication more difficult. Given the time constraints of an interview, having to repeat yourself due to poor communication will disadvantage your peer.

You may want to have paper and a writing utensil or open up a text editor on your computer to write notes about your peer’s performance. The best way to cure personal bias and assist your peer is to take notes on their performance throughout the interview so that you’re able to provide them with concrete and thorough feedback afterward.

Interview Structure

Begin by introducing yourself and ask your peer whether they’d like you to briefly explain the interview process to them. You’ll be given content to interview your peer and will spend around 30 minutes interviewing them over Pramp’s video and collaborative coding environment. Emphasize that you’re there to help them practice and that you’ll provide constructive written feedback following the interview.

We recommend the following interview structure:

Ideation (5–10 minutes)

Your peer will be able to see the question in the content pane as soon as your interview begins. Many candidates are either completely silent or try to jump straight into coding, both of which often lead to critical errors later in the interview.

Encourage your peer to read through the question on their own and then spend the first few minutes thinking through the problem with you. Make sure that you and your peer are both clear on any ambiguities or assumptions being made about the problem. You want to ensure that your peer has a clear understanding of the problem and possible solutions before starting to code.

Ask your peer to explain what they intend to do and consider reducing their problem-solving score if they don’t have a clear approach to tackling the problem. It’s important to have your peer explain their thought process to you out loud. Talking through the problem with the interviewee will help you assess their problem solving and communication skills.

After defining the scope of the problem, make sure that your peer at least talks through a naive solution before adding additional complexity. Candidates often skip even discussing the brute-force solution because they assume it’s too obvious or not what the interviewer wants.

This is a mistake and one that often leads to candidates overcomplicating the problem early and later failing to write any actual code or produce a working solution. As an interviewer, this outcome will give a negative signal about a candidate’s problem-solving abilities, but may not give you enough signal to assess the candidate’s coding abilities.

Even if they’re only talking about a brute-force solution, prompt them to explain the time and space complexity of their naive solution and why it’s suboptimal if they don’t do so on their own.

Make sure that your peer doesn’t start coding until you think they sufficiently understand the problem and its underlying constraints, identified their assumptions, and have a clear approach.

Optimization

If your peer had a solid grasp of the brute-force solution, you should encourage them to identify a better solution. When optimizing, some of their original assumptions may change, so it’s important to ask them to clarify if you suspect a change.

If your peer gets horribly stuck while talking through optimizing their naive solution, you should encourage them to code their naive solution, and if time remains, discuss optimization afterward. Remember that some problems are very specific and not finding the optimal solution doesn’t imply that the candidate isn’t skilled or couldn’t have eventually found a better solution later on.

Coding (20 minutes)

After creating a plan for how to approach the problem with your peer, it’s important that they don’t leave you in the dark and go code something for 20 minutes. Your peer should be talking aloud and explaining what they’re coding as they go along.

You should understand what your peer is doing and their logic for doing it in real-time. If your peer takes a wrong turn, we’d suggest not offering a hint too soon, as it may lead you to force feed the candidate a solution. It’s important to let the candidate struggle and even fail. It’s not your responsibility to ensure that they can come up with a working solution.

If your peer acts on hints they wouldn’t receive in a real interview, it’ll hurt your ability to help them properly assess their true abilities.

Testing (5 minutes)

Once your peer finishes coding, there’s a high chance you’ll notice that they missed a bug or syntax error. Don’t immediately point out any errors you find. Instead, ask them to have a look at their code to attempt to see if they made any mistakes. While they do so, you should also examine their code from start to finish looking for any additional errors.

Don’t be too quick with running the test cases. Ask your peer:

• Do you believe this is correct?
• What cases should we consider?
• How would you test this given more time?

Evaluation

After the interview, it’s important to promptly write down your evaluation while it’s still fresh in your mind. Following the Pramp interview, you’ll be answering the following questions (the bullets below will help inform your answers):

Do you think this person would be easy to work with? (Yes / No)

• Are they open to hints/suggestions? Are they coachable?
• Are they friendly and respectful? :)

Would you hire this person? (Yes / No)

• Is this person someone you could see yourself working with? Would they be a good teammate?

Problem Solving Skills (1–4)

• Was the person able to understand what the question was asking?
• Were they able to find the brute force solution? Were they able to find a better solution or the optimal one?
• Did they consider the tradeoffs of a certain approach? Did they consider edge cases?

Communication Skills (1–4)

• Were they able to clearly articulate their thoughts?
• Were you always able to understand their proposed solution, and where they were struggling?
• Were they open to feedback and hints?

Coding Skills (1–4)

• How successful were they at translating their ideas into workable code?
• Was their code readable and well-structured? Was their code idiomatic?
• Were they concerned about the quality of code in their solution?
• Did they pay close attention to detail?

What did the candidate do well? (Free text)

What could the candidate do better? (Free text)

Interviewer Self-Checklist

• Were you aware of any biases you had that might impact your assessment?
• Were there any behaviors from your peer that made you uncomfortable?
• Was the candidate overly nervous despite your best efforts to keep them calm? What parts of your assessment were affected most by the candidate’s nervousness?
• Did you do anything that you feel may have adversely affected the dynamic of the interview or the candidate’s performance?
• Do you have a good sense of the candidate’s collaboration and problem-solving skills based on their answers to your questions during the interview?
• Did they provide various solutions to the subproblems encountered throughout the problem? Did they need a lot of help or hand-holding during the interview?
• Were they able to justify their decisions, or did you feel that they were just guessing the whole time?
• What would you have wanted to dig deeper into if you had more time with the candidate?

Additional Resources

• How to Conduct a Good Programming Interview — An interviewer guide for DS&A interviews, written by Li Haoyi, a former software engineer at Fluent Technologies and Dropbox.
• Engineering interviews: grading rubric — An article in which Medium shares how they assess the qualities they’re seeking in engineering candidates