Surviving the Technical Interview

The technical interview is where a lot of otherwise capable people fall apart. You can build real software, you have finished projects, you know your stuff - and then someone puts you in a room, or on a video call, hands you a puzzle, and asks you to solve it while they watch and you narrate your thoughts out loud. It is artificial, it is stressful, and it resembles the actual daily job of a developer only faintly.

Here is the reframe that changes everything: precisely because it is an artificial, specific skill that barely resembles the real work, you can prepare for it and get good at it. Interviewing well is a learnable skill, separate from being a good developer, and the people who ace interviews are usually not the best programmers - they are the ones who practised interviewing. Let us make you one of them.

Understand what they are actually testing

The interviewer is rarely just checking whether you arrive at the correct answer. They are watching how you think. When they hand you a problem, they want to see whether you ask clarifying questions before charging in, whether you can break a big fuzzy problem into small concrete pieces, whether you can reason out loud so they can follow your mind at work, and how you behave when you get stuck - do you panic and freeze, or stay methodical and keep making progress?

This is genuinely good news, because it means you do not have to be flawless. A candidate who gets stuck but works through it calmly, thinking clearly and communicating the whole way, often beats a candidate who silently produces a perfect answer with no visible reasoning. They are hiring a colleague they will have to think alongside for years, not a human search engine. Show them a good colleague.

Think out loud, even when it feels weird

The single most important interview habit, and the one beginners most often get wrong, is to narrate your thinking. Say what you are considering. Say what approach you are weighing and why. Say "I am not sure about this part yet, let me think it through." Silence is your enemy in an interview, because a silent candidate gives the interviewer nothing to evaluate but the final answer, and if the final answer is wrong or slow to arrive, there is nothing else to credit you for.

Yes, thinking out loud feels deeply unnatural at first - we are trained to speak only once we have the polished answer. But the interviewer literally cannot read your mind, and your reasoning is the main thing they are there to assess. A candidate who talks through a problem they do not fully solve frequently outscores a candidate who solves it in silence. Practise narrating until it stops feeling strange, because it will feel very strange the first several times.

On the algorithm puzzles

Many technical interviews, especially at larger companies, involve puzzles about data structures and algorithms - the classic "reverse this list," "find the duplicate," "traverse this tree" genre. There is a long, tired debate about whether these are a fair test of real ability. Mostly they are not a great proxy for the daily job. But here is the pragmatic truth that debate ignores: many companies use them anyway, so if you want those jobs, you prepare for them. Fairness is a separate argument from strategy, and you are optimising for getting hired.

The good news is that this is the most studyable part of the whole process. There is a well-known, finite set of patterns that recur constantly, and dedicated practice on them genuinely works. Spend real time on it if you are targeting the kinds of companies that ask - steady, deliberate practice over weeks, not a panicked cram the night before. This is a skill you build, like a musician drilling scales. Nobody is born able to reverse a linked list under pressure; they practised it until it was boring.

Take-home projects and practical tasks

Many companies, mercifully, use more realistic assessments instead of or alongside the puzzles - a take-home project, or building a small feature live. These play far more to your strengths if you have actually built things, because they resemble real work. Treat a take-home with genuine care: make it work, make it clean, write a clear README, add a test or two, and do not over-engineer it into next week. It is a direct sample of what you would be like to work with, so make the sample represent your best ordinary self, not a frantic all-nighter.

The behavioural questions are not filler

Somewhere in the process, someone will ask the "soft" questions: tell me about a time you faced a hard bug, or disagreed with a teammate, or a project you are proud of. Beginners dismiss these as filler and wing them. Do not. Companies genuinely care whether you can communicate, take feedback, and be a decent human to work beside eight hours a day, because a technically strong colleague who is impossible to work with is a net negative and everyone knows it. Prepare a few honest stories from your own projects and learning in advance. Being able to talk clearly about your work, your struggles, and what you learned from them is a real and evaluated skill.

Manage the nerves like a professional

Interview anxiety is universal - even senior developers get nervous - so do not add "I feel nervous" to your list of problems as though it disqualifies you. A few practical things genuinely help. Do mock interviews with a friend or an AI until the format stops being novel and only the specific problem is new. Get sleep before it rather than cramming, because a rested brain that knows less beats an exhausted brain that crammed more. And remember, in the room, that a single interview is not a referendum on your entire worth as a person - it is one artificial test, on one day, that you can simply take again elsewhere if it goes badly.

The technical interview is a gate, not a wall. It is a specific, artificial, entirely learnable skill, and like every skill in this series it yields to deliberate practice. Get good at it, walk through the gate - and then the real adventure starts, which is your first actual job. That is next, including all the things nobody bothers to warn you about.