Algorithms: What does an interviewer want to know?
And what are candidates' most common mistakes?
Hi, everyone, I’m Timur, a software engineer, mentor, and interview enthusiast. Welcome to BigTechDream newsletter. Every week, I craft a newsletter article focusing on tips for interviews, system design topics, and career growth advice.
As I mentioned, I like to sit on different sides of the table, being an interviewer and an interviewee. I do not have precise numbers, but I have conducted more than 100 technical interviews on algorithms and data structures; I need to start counting.
As an interviewee, it is much less. Considering each company has 2-3 algorithmic interviews per process, my rough estimation is that I was interviewed for algo/DS approximately 20-25 times.
Observing this interview type from different perspectives allowed me to learn some insights.
Misconceptions
Let’s start with misconceptions that people are having towards algorithms and data structures interviews. I noticed engineers having them regardless of their experience, seniority and speciality.
They are not necessarily a bad thing. However, misconceptions steal focus and don’t allow understanding of the real meaning of this interview type.
“I can pass this interview by solving Leetcode problems”
Algorithmic interviews are not about just solving Leetcode-style problems. I guarantee that if you write the perfect and the most efficient code but during the interview, you do not say any word or ask any questions, you will receive a sad email afterwards.
Interviews are miniature representations of real work tickets. When an engineer is assigned with ticket on their job, first of all, they try to gather some information “Why do we need to do it?“, “What are deadlines?“, “What are user stories?“, etc. After that, the engineer would propose different approaches by providing pluses and minuses of each one, especially if it is a complex feature. Only after this stage can the engineer start implementing it. In the end, the engineer has to perform a series of tests to ensure everything works properly.
More complicated than just clicking the “Submit“ button, right? Treat algo/DS interviews like a real work problem.
“I can pass this interview by remembering solutions for all leaked problems”
It is a good idea to try to solve all leaked questions before having a real interview. You can be lucky and get questions you are prepared for, but it can be a completely new problem.
An interviewer intentionally wants to put a candidate in an ambiguous situation and see how a candidate navigates uncertainty.
I have seen candidates who solved similar problems before but couldn’t recall the exact solution. They remembered some parts and tried to insert them into the current idea, and it looked like a guessing game.
Preparation is important, but relying on your problem-solving skills rather than your memory is better.
“I must solve a problem as fast as possible“
There is indeed a time constraint during this interview. You will have only 45-60 to demonstrate your skills.
But usually, a candidate is not rewarded if they solve faster. Or, let me rephrase it, speed is not a signal that provides a lot of useful information about a candidate.
When a candidate is focused on speed, they tend to make some obvious mistakes. They usually underestimate the impact of typos, missed edge cases, and bugs.
Have a game plan before the interview, distribute time and use it efficiently.
“I will pass an interview because I am an experienced engineer“
“Man, I am a senior engineer with 10 years of experience who manages a team of 5 engineers; why do I need to solve these problems? I have no time for this“
Many people believe that if they are professionals, an interviewer will notice it, even if they fail algorithmic interviews.
The other part is that solving algorithms and data structures is not something that is expected from employees daily - and it frustrates many high-level engineers.
Unfortunately, it doesn’t work that way. Interviewing is a completely different game with its own rules and fines. We can disagree with it, ignore it, or be angry with it, but it doesn’t matter.
If you want to pass this interview, you must prepare for it and know the rules.
What does an interviewer want to know?
Those are not golden rules, and each company can have its specifics. However, I have noticed that, in general, everyone uses similar categories to evaluate a candidate.
Communication
It is quite important to understand if a person can communicate professionally but be friendly at the same time. At the end of the day, it is your potential future teammate. Nobody likes toxic or aggressive people around.
When a candidate explains their solution, their brain uses the same part to structure the logic as when writing the code. A simple, straightforward, and coherent explanation implies that the code will also be easy to read and maintain. Not so obvious, right?
Thinking loudly and commenting on your actions also contributes to this pillar. First, it helps an interviewer be on the same page with a candidate and understand what is going on. It also provides an opportunity for an interviewer to nudge a candidate to get a little off track.
Also, use appropriate terminology and not overuse buzzwords.
Solution-oriented
As I mentioned, a candidate is expected to try to gather some information about the problem before jumping into solving it. Sometimes, an interviewer intentionally gives a vague description without any constraint to see if any questions will be asked.
Questions matter a lot!
An interviewer wants to know if a candidate is familiar with algorithms and data structures fundamental theories. Each technology, each language, and each framework is either built on top or uses internally these fundamentals.
Quite often, a given problem doesn’t have only one right answer. So, an interviewer is interested in knowing if a candidate is capable of coming up with different solutions. Each approach will have its benefits and drawbacks, and a candidate is also expected to highlight them. Remember time and space complexity?
Finally, can a candidate find the most efficient solution given the requirements and constraints?
Autonomy
Again, it reflects real work situations. Each employer, tech lead, and teammate wants their colleague to be autonomous in solving engineering problems.
An interviewer tries to understand how long a helping hand should be provided for a candidate to overcome a chasm.
Receiving a hint from an interviewer doesn’t lead to immediate interview failure. However, receiving significant help can be considered a red flag.
Coding
Can a candidate transform their thinking into a working solution? How clean and straightforward is written code? Is it messy and buggy?
Usually, problems have several edge cases, and it is nice not to forget to address them in your solution.
I would also add validating and testing your solution to this category. Seeing how a candidate debugs their code and finds the root cause is quite insightful. Remember, it is a mini working task.
The most common mistakes
Jump into coding without asking clarifying questions
Trying to come up with the most efficient solution from the scratch
Be silent or/and not be able to code while you talk
Giving up too early and asking for help
Saying your code is ready without double-checking it
Focusing too much on one approach
Practicing with Leetcode
A general piece of advice is to treat the Leetcode problem as an interviewing problem.
Do not rush into coding. Spend some time thinking and discussing the problem with yourself.
Explain the problem in your own words
Try to come up with 3-5 different questions, you would ask an interviewer during the interview
Start with the most non-efficient solution that solves the problem. Understand its cons and pros, then try to come up with a better solution. Always justify why the new one is better than the previous one.
What is the time and space complexity?
How can I decrease time/space complexity?
Can I find a more efficient solution?
Practice thinking aloud, comment on your actions while you think or write code
Be creative, allow yourself even the most obscure ideas
What if I treat letters as graph nodes? Can I solve the problem using DFS?
If you feel you lack theory, don’t wait, start googling
I need a data structure that finds a minimum in O(1) time
Reading someone’s solution should be a last resort. Your goal is to prevent your brain from giving up too early.
Try everything you can before jumping into the discussion section
Thanks for reading
Press like and share the newsletter if you find it interesting.
See you next week!
- Timur