In Stage 4, we introduced the core tech foundations that are critical for interviews, along with how to approach them strategically. From arrays, hash tables, stacks, and trees to recursion, dynamic programming, and backtracking, we looked at practical ways to improve, such as recognising problem patterns, keeping error logs, explaining solutions, thinking aloud, and practicing under time pressure. In Stage 5, it’s all about putting those skills into action while tackling algorithm questions.
An algorithm is simply a set of steps you use to break a problem down and solve it. The interviewer, however, isn’t just judging your code. They want to see how you approach the problem, why you choose a particular solution, and whether you can explain your reasoning. And no, you don’t always need to jump straight to the most sophisticated solution. Sometimes, starting simple and building towards a better solution is exactly what the interviewer expects.
Common algorithm approaches you should know
Beneath the complicated code, and underneath all that syntax, algorithms are basically different ways of saying, ‘Okay, here’s how we’re going to tackle this problem. Think of it like different routes to the same destination. Interviewers want to see how you choose the route that makes the most sense.
Take a look at some of the common algorithm approaches you should be well-versed in before an interview –
1. Divide and Conquer
Divide and Conquer means breaking a large problem into smaller, independent parts, solving each part, and then combining the results. A classic example is Merge Sort, where you split an array in half, sort each half separately, and then merge the two sorted halves into one sorted array. What you bring to the table already is key information and real-world applications of Merge Sort, like sorting large datasets, external sorting, and scenarios where large volumes of data need to be processed efficiently. What the interviewers seek is your ability to explain the thinking behind it. Instead of providing definitions, interviewers expect you to say, ‘I’ll split the problem into smaller parts, solve them, then merge the results. This tells the interviewer that you know what you’re doing by breaking a complex problem into manageable pieces rather than replaying a rehearsed problem.
2. Greedy Algorithms
A greedy algorithm makes the best choice at each step, which is often called the ‘Best Now’ choice, with the expectation that it will lead to the best overall result. However, there’s an important condition you need to be able to explain – why those local choices produce an optimal overall result. Interviewers want to know where the greedy algorithm applies and where it doesn’t. Take a meeting-scheduling problem as an example. If your goal is to fit as many meetings as possible into a schedule, you need to choose the meeting that ends earliest, then select the next meeting that starts after the previous one ends.
Your interview explanation could be:
“I’ll choose the meeting that ends earliest each time. That leaves the highest chance to fit more meetings after.”
By this, you’re not just applying a rule. You’re explaining why that rule makes sense for the problem.
3. Recursion
Recursion solves a problem by solving a smaller version of the same problem repeatedly until it reaches a base case, the condition that tells the function to stop.
Factorial is a simple example:
n! = n × (n−1)!
The base case is:
0! = 1
So:
And 4! can be broken down further until the calculation reaches 0!. In an interview, you could explain it like this: “My base case is 0! = 1. Each step reduces n by 1, and I return n × factorial(n−1).” Again, you’re showing the interviewer that you understand both the mechanism and the reason the recursion terminates.
4. Dynamic Programming
Dynamic Programming (DP) breaks complex problems into smaller, overlapping subproblems to optimize plain recursion. It solves each subproblem only once and stores the results so they can be reused instead of recalculating them repeatedly. The Fibonacci sequence is a classic example. A straightforward recursive approach can repeatedly calculate the same values. With dynamic programming, you store previous results and reuse them.
In an interview, you could say:
“I will store each sub-result in a memo or table and reuse it to avoid unnecessary repeated work.”
The key idea is simple — don’t do the same work twice if you can save the answer and reuse it.
5. Backtracking
Backtracking involves exploring choices step by step. When a choice leads to a dead end, you undo that choice and continue with another option. Take generating permutations as an example. Here you choose a number, continue building the permutation, and if that path doesn’t work or you’ve reached a dead end for that possibility, you undo the choice and try another number.
In an interview, your explanation can be:
“I will search through the options, and if it fails, I will backtrack and try the next.”
The interviewer is looking for that logical progression: choose → explore → undo if necessary → try another choice.
What Are Interviewers Really Looking For?
When approaching the algorithm stage in a tech interview, candidates often assume the interviewer is looking for the cleverest or most sophisticated, quick, out-of-the-box solution. In reality, what interviewers want to see is whether you can arrive at a correct, applicable, straightforward solution to the problem at hand, and then explain it coherently. Simply put, a simple solution that works and that you can explain clearly can make a stronger impression than a complex solution that you cannot finish, explain, or debug. So, get comfortable with starting with a straightforward approach and then improving on it to demonstrate stronger problem-solving skills.
Candidate A vs Candidate B
Imagine two candidates receive exactly the same algorithm problem.
Candidate A immediately jumps into a complex solution because they believe it will get them to the answer faster.
- They get stuck halfway.
- The code doesn’t run.
- Time runs out before they can finish.
Result: Candidate A doesn’t progress to the next stage of the interview.
Now consider Candidate B.
Candidate B starts with a simpler, slower solution. They explain their approach step by step and communicate their reasoning confidently. Once the basic solution works, they recognise that a hash map can improve the solution. They explain the trade-off, make the change, and improve the approach.
Result: Candidate B progresses to the next stage.
So, why did Candidate B make the cut? It’s not just because their solution was seamless, but because they demonstrated:
- Clear understanding of the problem
- Coherent and confident explanation of trade-offs
- The ability to improve a solution step by step when asked
- Good communication throughout the process
That’s exactly what an algorithm interview is designed to reveal. The interviewer isn’t only asking for the right answer. They’re asking whether ‘you can reason your way towards the answer.’
How to Approach Algorithm Problems in an Interview
Knowing algorithmic approaches is one thing. Knowing how to use them under interview pressure is another. Here, a simple four-step process can help.
Step 1: Start simple
Your first goal should be to get to a working solution, even if it isn’t the most efficient one. Start by making sure your approach handles the basic test cases correctly. For example, if your initial solution checks every possible pair in an array, it is fine if it gives you a correct starting point. You can then assess if there is any other way to make it faster. It is something like creating a structure first, followed by fine-tuning until the best version is reached.
Step 2: Explain your thinking clearly and coherently
Talk through what you’re doing. Think out loud.
For example: “This solution is O(n²) because we check every pair.”
Or,
“I’m using extra memory to speed up the solution.”
Or,
“I chose a hash map because we need fast searches.”
These explanations give the interviewer insight into your decisions.
They also make it easier for you to identify lapses in your performance. Sometimes, saying an approach out loud makes a flaw obvious before you’ve written ten lines of code around it.
Step 3: Optimize if there is time
Once you have a correct solution, look for ways to improve it. Interviewers welcome improvement suggestions, especially when you say them out loud like a conversation while implementing it. For example, you can say –
“I think we can improve this by…” Then explain what you would change and why. If the interviewer agrees, implement the optimisation step by step. This approach is safer and more believable than trying to produce the perfect solution immediately. It also shows that you understand trade-offs, like a situation where using additional memory can reduce execution time.
Step 4: Stay calm under pressure
Got stuck? No problem. That happens all the time. What matters is how you respond. Instead of going silent or fumbling with different approaches, communicate where your thinking is.
You could say:
“I’m thinking about which data structure fits best here.”
Or ask:
“Would you like a correct first version, then work towards improvements?”
That doesn’t make you look unprepared. It shows that you’re trying to structure the problem rather than panic your way through it.
Common mistakes to avoid in algorithm interviews
Knowing what to do is half the battle. Knowing what NOT to do can save you from losing the other half.
Here are some common mistakes that candidates often make in tech interviews that often sink their ships when they are only inches from the shore –
a. Letting your code do all the talking – coding without explaining
Interviewers need to understand your reasoning. Therefore, coding in silence proves counterproductive. Avoid it by speaking your thoughts as you work. Explain what you’re trying to do, why you’re choosing an approach, and what you’re considering.
b. Making it clever before making it work – trying to optimize too early
Jumping straight to optimization even before you have the solution working would only overcomplicate the problem. Avoid it by correcting the solution first and then optimizing it. The idea is to make the basic solution functional and improve on it thereafter.
c. Debugging the interviewer instead of the solution – getting defensive at feedback
Feedback may not always be flattering. But arguing with the interviewer or defending your solution too strongly can affect how your collaboration and communication skills are perceived. Avoid it by staying in control of your tone and language. Acknowledge the feedback, consider the suggestion, and explain how you can adjust your solution or why another approach may still be more suitable.
Key takeaway – think first, code next, improve later and speak your process
Technical interviews are seldom about what you memorized or how many definitions you know to perfection. It is not about your past feats or the university degrees that adorn your accomplishments. At any stage, interviewers want to know: Can you understand the problem? Can you break it down? Can you explain your choices? Can you recognise trade-offs? Can you respond to feedback? And can you improve your solution without losing sight of correctness? If you can demonstrate those skills while writing code, you give the interviewer stronger evidence that you can think clearly, communicate well, and solve problems under pressure.
If you’re a candidate ready for a tech interview, here’s your winning strategy –
- Take time and build a correct solution first. Improve it later
- Logical reasoning and straightforward communication are just as important as coding skills
- Even a brute-force solution can demonstrate strength if you can explain your reasoning in a well-structured manner, discuss trade-offs, and identify how you could improve it.
- A slow start isn’t a bad start. It’s ok to start with a slower solution and then move towards a more efficient one using a hash map, dynamic programming, or another appropriate technique.
The idea is to convince the interviewers that you have much more than textbook knowledge of algorithms. You actually know how to solve problems.