The interview game has changed a lot over the years for software engineers, mostly with engineers now being given much more complex problems and being expected to know many more algorithms. The bar for the speed at which we should be able to solve problems has increased pretty rapidly as well.
I think as these expectations have grown, people have lost sight of what these interviews are supposed to test for. This has left many people with the question: what makes a good software engineer interviewer?
I’d like to start with what does not by covering some common mistakes I see from interviewers.
A good interviewer should not expect you to come up with the idea for the most optimal solution to a problem by yourself. You may even struggle to get to the initial solution, but they should still be guiding you this whole way. Sometimes, even to the point of straight up telling you the answer.
What? Tell me the answer? Why would they do that?
Because the hardest part of being a software engineer is not – as many people have been tricked into thinking – memorizing a huge set of algorithms and looking for places to apply them at work. There’s a reason we all need to constantly refresh ourselves on leetcode whenever we start job hunting, and why cheating is rampant on OAs even among experienced engineers.
While it’s important to have the ability to apply patterns that you’ve seen before to a problem in front of you, that’s a skill that’s more accurately assesed in a system design interview.
What interviewers should be focusing on with their candidates, primarily those that are more junior, is their ability to understand ideas that have been presented to them, and translate those into code. It’s okay if they didn’t recognize that a binary search was the tool to use, and it’s okay if they struggled to see how. But did they understand how it worked when you gave a high level overview, could they walk through a new example, and could they translate their newfound understanding into code?
This may sound very obvious to some, but I can tell you from my experience as an interviewee that it is not obvious to most.
For some reason, candidates that know their algorithms, see exactly where to apply them, and can immediately code up a solution are the most desired. But often times, these interviews tell you very little as an interviewer.
So what does a proper assessment look like in practice?
Let’s say that as an interviewer, I give the candidate a problem where they have to validate a binary search tree
I would hope that they’re at least familiar enough with recursion and tree traversals to talk about a basic solution, even if it has the worst runtime in the world.
- Are they able to point out the runtime of their solution and recognize there might be something better?
- It’s fine if they don’t understand how to come to a more optimal solution. But when I explain the algorithm behind the optimal solution, are they able to understand it and walk me through a new example?
- Can they translate their newfound understanding into code?
A good interviewer will make them aware that it’s okay to ask questions, and emphasize that it’s about the journey and not the destination!
Now lets say they initially struggle to come to something more optimal than the brute force, we could ask some helpful questions like:
- “What if you used recursion?”
- “What if you kept track of a min and a max?”
If that isn’t enough information, I would draw out a call stack with the min and max values at the first node.
- Does this make sense?
- What would happen at the next node on the left, what about the right?
Ideally at this point, they would have enough information to code up the optimal solution.
In the absolute worst case scenario, if they didn’t understand the most optimal way, I would allow them to write up their suboptimal approach just to make sure they can code.
I personally believe that leaving the interview with working code is important. Even if it’s not getting the right answer for a set of edge cases, it’s absolutely crucial to see how they formalize their ideation process into actually creating code.
Some final notes
This piece was really just to address the fact that many people think they have to perform at a ridiculously high level in these interviews. I just really wanted to emphasize that it’s more about being able to communicate, come to a solution together, and accept feedback from others.
Do make sure that you’re at least familiar with your basic data structures and algorithms, but do not feel the need cheat, do not feel like you have to get the best possible answer. And the next time you get an interviewer who’s completely silent and obviously not paying attention, and they pop back into the conversation at the end – hoping for a fully fleshed out solution – just know that it’s genuinely not you.