The Technical Interview Question (A Hiring Manager Shares on Reddit)

For the original post click here. 

Sharing a hiring manager’s perspective

I’ve been wanting to write a post like this for a while, but didn’t have much time to sit down and organize my thoughts. However, I realized we’re entering new grad / intern recruiting season, so I thought this might be helpful to some people in the near future. I also hit a milestone at work recently of having assessed 100 candidates — primarily SWE and PM, but some other roles too — and thought this might be a good way to commemorate it in a small way.

This post is aimed at SWEs, specifically coding, for new grad / junior / similar roles. However if there’s enough interest I can do a similar one for system design, PM, and maybe even TPM roles.

By no means is this a definitive guide or guaranteed in any way, it’s just my own anecdotal experience

Good luck!

1. Do NOT jump directly into writing code or answering the question exactly the way it was asked

In my opinion, the single biggest and most common mistake that candidates make is answering the question immediately. A lot of the time, the questions are worded ambiguously, and even if they seem completely defined, they’re not. Usually the assessor wants to know more about the way you think rather than how you write code on a whiteboard/doc. Before writing any code, spend some time demonstrating that you’re thinking about the problem holistically. Asking the right question sometimes demonstrates more about your technical knowledge than implementing the algorithm correctly, as strange as that sounds at first.

At a minimum, make sure you define the following before you write any code. You can ask outright or you can make a reasonable assumption (but make sure to explain them):

  • Inputs and outputs

  • How much validation or error handling you need to do on the input value

  • Expected size of input. This informs runtime, so you can defend your choice of implementation.

  • Whether there are any major constraints to space, time, etc.

  • Test cases. Include some standard items, but also try to capture things you know might be edge cases (ex. size = 0 or 1 for an array, empty string, nullptr, etc.) and explain why you chose them. This is a huge differentiator.

  • Any helper classes you need to solve the problem. For example, if it’s a Tree/Graph/Linked-List problem, quickly sketch out the important methods/variables of the Node class you’ll use.

Don’t spend a ton of time here, maybe 2-3 minutes of discussion. Enough to show that you’re competent, but not too much that it seems like you’re trying to avoid getting to the coding portion.

2. (Depending on problem complexity) diagram or pseudocode before you jump into actual implementation

The average programming question is about 15-30 minutes depending on the difficulty. For more complex questions, it can be helpful to draw out the data flow or algorithm or even write pseudocode before moving to the actual class/function/program implementation. This helps to quickly convey your knowledge of the problem and confirm your logic with the test cases without also having to worry about the specific implementation syntax. There’s nothing more frustrating to a candidate than getting 75% through a verbose Java function and realizing their fundamental logic was wrong.

Believe it or not, we don’t want to come across as antagonistic or purely judgemental. We can’t help you course correct early if you don’t tell us where you’re going and just start writing code without a clear plan. Also, in the case where you’re not able to finish the final implementation, having diagrams or pseudocode will help me decide whether I think you could have gotten to the correct answer given more time, or whether you were completely lost.

Again, this should be maybe 2-3 minutes max. If the problem is simple enough, like a warmup exercise or initial technical screen, you may be able to skip this step. Use your judgement.

3. Think out loud

Another common mistake candidates make is silently facing the whiteboard while they write code for 5-15 minutes straight. I personally will never let it actually go on that long and will ask questions while the candidate is “programming” if they don’t talk out loud, however some people will keep the awkward silence.

Benefits of talking through the code:

  • You explain what you’re trying to do as you write it, so the I know if you’re on the right track and/or can course correct in real time

  • You can explain tradeoffs and alternatives, demonstrating how deeply you’re thinking about the problem. Ex: “I’m using a for loop here, but you could also do…”. Or: “I assume this is a single-threaded solution, but if we were to parallelize it, here is where you’d include the main concurrency logic.” This is a huge differentiator.

  • In most cases we talk faster than we write, so I can get a lot more information from a candidate if they talk.

4. When coding, syntax matters a bit, but other things matter more

At all of the places I’ve worked, the candidate gets to pick their programming language. In this case, make sure you know the basic elements like where parenthesis and brackets go, what should/shouldn’t be capitalized, where punctuation goes, etc. However, I don’t really care if you miss a semicolon, forget to capitalize True/False in Python, swap null vs None, etc. UNLESS it’s a pervasive issue to the point where I’m not convinced you know what you’re doing. Knowing syntax perfectly is great, but I also know in any real-world situation your IDE/interpreter/compiler/etc. will catch this, so it’s a relatively minor mistake.

In the grand scheme of things, the actual code is not the main focus. I care significantly more about you knowing the fundamental mechanics rather than formatting. Some common aspects that are more important than syntax, and are common mistakes as well:

  • Do you know if strings are immutable or not?

  • Do you know the limitations of ints, doubles, floats, etc.?

  • Do you know how division works (int division vs. float division)?

  • Do you know how to use data structures and pick the right one?

  • Do you understand pointers/references and how they work?

  • Do you understand types and typecasting?

  • Do you know the difference between shallow and deep copy?

5. Sanity check your answer after finishing implementation

Remember the inputs/outputs and test cases defined in Step #1? Now is the time to revisit them and run through your implementation to make sure it works. This shows good testing/debugging practice to start doing it yourself. It’s also a good way to catch some simple bugs yourself, which is also a positive outcome. Again, my primary goal is not to watch you write perfect working code on a whiteboard, it’s to assess your knowledge, process, design, and finally code quality.

6. (Optional) Discuss extensions

If there is time, and you’re not redirected to another question, you can discuss potential extensions to the work you just did. For example:

  • How can you improve performance?

  • How can you make the error handling more robust?

  • How can you reduce complexity and space usage?

  • How else might you have implemented this and what the tradeoffs might have been?

However, use judgement for this one. It’s not always the best idea if you need to move on to the next question or you’re approaching time.

By CJ Sanchez (He/Him)
CJ Sanchez (He/Him) Career Coach CJ Sanchez (He/Him)