What I look for in a technical interview as a software engineer interviewer
Introduction
I've seen a lot of resources out there regarding how to prepare for a technical interview, but not a lot of resources on the other side of the equation.
As a senior software engineer, who has done a fair amount of interviews, I'd like to share a perspective from the interviewer side.
This is targeted at those who are preparing for technical interviews.
Interview rounds
For FAANG companies, it is very common to have 2 rounds consisted of a phone screen and an onsite round.
After passing the phone screen, you will usually be brought onsite for a whole day worth of grilling interviews. One example could consist of having 2-3 algorithm, 1-2 system design, 1 behavioral, and 1 hiring manager rounds. Coding and algorithms.
My experience will be mostly reflected on the coding rounds (algorithms, system design).
Think before coding
Technical interview is not a coding competition, where you're striving for the fastest submission speed and the most optimal solution.
If you jump into a question right away without thinking before you code, you could end up in a mess that even I can't get you out of.
You could have have misinterpreted the question or made false assumptions about the question, which would be a waste of time.
As an interviewer, I appreciate it when a candidate spend the first few minutes asking clarifying questions on the problem, walking through scenarios, and ultimately communicating with me before diving into the code. You want me to be on the same page as you.
Communication
Even if you managed to come up with the most optimal solution, I will give you a strong no hire if you barely talked with me.
You can not assume that I will understand your intentions from just your code. For what it is worth, you could have been coding in a language that I'm unfamiliar with.
Some candidates might also like to think too quietly. While that is totally fine, you want to verbally communicate with me on your thought process every so often. You don't want to go on for more than 5 minutes without talking.
If I'm able to understand your logic and ask follow up questions comfortably, this is a great sign for your communication skills.
Correctness and optimality
You do not need to have the most optimal solution.
Sure it looks great if you can get to the most optimal solution from the get-go, but I'm not a leetcode solution bot. If you can not clearly explain to me along the way on how you got to your solution, this is a big red flag.
In more cases than not, the optimal solution is often built upon the ideas from the less optimal solutions.
If I can see that you are continuously converging toward the most optimal solution from a less optimal implementation, this is a plus in my eyes. It is a bigger plus if you actually implemented the most optimal solution.
Obviously correctness plays a cruical part in optimality. How can you have the optimal solution if it does not work?
It is a big plus if you are able to come up with your own test cases and run it through your code. What you want to avoid is having me come up with too many scenarios that would break your code. If the bugs are severe, then it would be a red flag
I also expect you to explain the time and sapce complexity correctly. This should be natural because they are the reason why we want the most optimal solution.
Asking for hints
I am getting the idea that people think asking hints from the interviewer is a taboo. I would like to address that.
A few small hints here and there from me are not going to reflect negatively on your interview performance.
However, if I felt like I needed to give you a huge hint for you to even start somewhere, then that is a red flag
Let me give an example, let's say the problem was to implement a recursive tree traversal.
It is ok for me to give hints if you had a small bug in a conditional statement that caused you to fail an edge case. In this case, I could give you a hint on the edge case for you to figure out what the edge case.
It would be bad if I had to give you hints on how to implement a recursive function because you don't know recursion and we are not getting anywhere in your iterative approach.
You can't to rely on the interviewer to have your back.
Just keep trying
I used to be in the same spot as you, going through rigorous interview preparations and getting grilled during interviews.
Unfortunately, you have to realize that there are a lot of external factors that you can not control as an applicant:
- Getting bad interviewer(s)
- Getting bad question(s)
- Just not in your best condition
However, I encourage you to not give up and just keep trying. One day, all the stars will align.