Technical interviews filter on two things simultaneously: whether you can solve problems, and whether you can do it in a way that's visible and communicable to others. Brilliant candidates fail these interviews because they go quiet, work internally, and produce an answer without showing their work. Interviewers need to see the thinking, not just the result.
What technical interviews actually test
Beyond the obvious (technical knowledge and problem-solving ability), technical interviews are specifically testing:
How you approach ambiguity. Most real-world engineering problems aren't fully specified. Do you ask clarifying questions or do you immediately jump to a solution that may be solving the wrong thing?
Communication under cognitive load. Can you talk and think at the same time? In real teams, engineers need to explain their reasoning, discuss trade-offs, and collaborate — even when the problem is hard.
Adaptability when you're wrong. If you go down a path and the interviewer gives you a hint that it's not optimal, can you receive that gracefully and adjust? Or do you dig in?
Knowledge depth vs breadth. Can you go beyond the surface answer? If you give a solution, do you know its time and space complexity? Its failure modes? Its trade-offs?
The single most important skill: thinking aloud
This is the advice that makes the most difference and the one most candidates don't follow. Every step of your thinking should be visible to the interviewer — not just the answer.
This means: reading the problem and restating it. Identifying constraints. Proposing an approach before you start implementing. Explaining what you're doing as you do it. Flagging trade-offs as you see them. Asking if this direction makes sense before investing time in it.
A candidate who gets the right answer silently is less impressive than a candidate who works through a problem intelligently while narrating their approach, even if the second candidate doesn't reach the optimal solution. The thinking is what the interviewer is hiring.
What to do when you're stuck
Getting stuck is normal. How you handle it is what matters.
Say you're stuck — don't go silent. "I'm not immediately seeing a path from here — let me think about this from a different angle" is infinitely better than two minutes of silence.
Walk back to basics. What does the problem need? What are the inputs and outputs? Can you solve a simpler version first? Can you brute force it and then optimise?
Ask for a hint if you genuinely need one. "I'm not sure I'm on the right track — is there something about the constraints I should be paying more attention to?" Most interviewers will help. A candidate who asks for guidance and then makes progress is better than one who stays stuck.
Don't catastrophise. Getting stuck on a hard problem doesn't mean you've failed the interview. Interviewers calibrate difficulty. How you respond to being stuck is often more informative than how you handle a problem that's too easy.
A framework for approaching any problem
- Clarify. Restate the problem in your own words. Ask about constraints (input size, edge cases, null inputs, time limits). Make sure you're solving the right thing.
- Examples. Work through one or two examples manually to build intuition before writing any code or formula.
- High-level approach. Propose your solution verbally before implementing. "My approach is to use [method] because [reason] — does that seem like a reasonable direction?" Get buy-in.
- Implement. Write the solution while narrating what you're doing. Don't go silent.
- Test. Check your solution against your examples and edge cases. Catch your own bugs before the interviewer has to point them out.
- Optimise. If there's time or the interviewer prompts it, discuss whether a better solution exists and what the trade-offs would be.
The behavioural side of technical interviews
Most technical processes have a separate behavioural round. For software engineering roles at larger companies, this can include questions about system design decisions, handling technical disagreements, working across teams, and explaining technical work to non-technical stakeholders.
Prepare for this separately. Your STAR answers need to be technical enough to be credible (specific language, real constraints, actual trade-offs) but explained at a level where a non-technical recruiter or senior manager could also follow the story.