How to Prepare for a Technical Interview: the Complete Guide

To prepare for a technical interview, confirm the format, map the skills in the job description, rehearse STAR behavioural answers, and run timed mock interviews. A technical interview tests how you think and communicate under pressure, not only what you know. That distinction shapes the whole plan below.

Most candidates pour nearly all their preparation time into technical content and almost none into communication and process. Yet many employers weight problem-solving and clear communication during the assessment at least as heavily as the final solution. This guide corrects that imbalance.

The principles here apply across markets and roles. They work for a software engineering interview in San Francisco, a data analysis role in London, a DevOps position in Toronto, or a systems engineering role in Sydney. Market-specific context is flagged where norms differ.

Understanding the Format: What Kind of Technical Interview Are You Facing?

A technical interview takes one of several distinct formats, and each requires a different preparation approach. Confirming which format applies to you is the critical first step. The five common formats are below.

Live coding interview — You are given a programming problem and expected to solve it in real time, typically using a shared coding environment (CoderPad, HackerRank, or a Google Doc). The interviewer observes and may ask questions as you work. This format is dominant in US technology companies, from startups to major tech firms.

Whiteboard or virtual whiteboard interview — A variant of the live coding format in which you draw or write your approach rather than type code. More common in US tech for system design discussions at senior levels. Less common in UK hiring.

Take-home assignment — You are given a brief and complete the work independently, usually over 3–7 days, before presenting and defending it in a follow-up interview. This format is widely used in UK and Australian technology, product, data science, and design roles.

Technical case study — Common in UK management consulting, strategy roles, and financial services. You analyse a business problem and present a structured recommendation. Quantitative case studies (market sizing, financial modelling) are frequent in investment banking and consulting interviews in London and Toronto.

Technical panel interview — A structured interview with multiple evaluators, each typically representing a different technical domain. Common in UK public sector technology roles, NHS digital programmes, and large infrastructure projects.

Understanding which format you face determines everything else about your preparation.

Step 1: Map the Technical Skills Being Evaluated

The job description tells you which technical skills the interview will test. Reading it closely is more valuable than any generic revision. Map every listed skill into three categories.

Must-have technical skills — the role cannot be performed without them. These will almost certainly be tested directly in the interview. If the job description says "Python 3, Pandas, and SQL are required," expect questions or tasks involving all three.

Nice-to-have technical skills — listed as desirable but not essential. These are worth preparing to discuss, but deep demonstration is less critical. Knowing enough to have an intelligent conversation about them — rather than full technical fluency — is usually sufficient.

Implied skills — not explicitly listed, but obviously required by the context. A "data-driven marketing manager" role implies Google Analytics and basic statistical literacy. A "cloud infrastructure engineer" role implies AWS or Azure knowledge even if not explicitly stated. Glassdoor Interview Reviews for that specific company often reveal exactly which implied skills were tested.

Step 2: Prepare for the Behavioural Component

Almost every technical interview includes a behavioural component, even a predominantly technical one. In UK hiring especially, the competency-based interview framework gives behavioural questions significant weight in technical roles.

The standard framework for behavioural answers in UK, Canadian, and Australian interviews is the STAR method: Situation, Task, Action, Result. Use the STAR method for every behavioural question. It gives the evaluator the specific context, your specific contribution, and the measurable outcome, which are the three things the evaluator is trying to assess.

Prepare STAR-format answers for the following competencies, which appear in virtually every technical job interview across all markets:

• Problem-solving under ambiguity — a time you had to find a solution without clear requirements or precedent.
• Technical communication — a time you explained a complex technical concept to a non-technical stakeholder.
• Debugging or troubleshooting — a time you identified and resolved a significant technical issue.
• Collaboration on a technical project — a time you worked closely with another engineer, data scientist, or developer to deliver something complex.
• Handling technical disagreement — a time you had a different technical opinion from a colleague and how it was resolved.

Step 3: Prepare for System Design (Senior Roles)

Senior engineering interviews almost always include a system design round. Expect one if you interview for a senior, architecture, or principal engineer role, especially in the US or at UK-based technology companies. A system design interview is a 45–60 minute discussion in which you design a large-scale system from scratch. Common prompts include "Design Twitter's feed," "Design a ride-sharing service," and "Design a URL shortener."

A system design interview assesses your ability to:

• Break a complex problem into components
• Make informed trade-off decisions (latency vs. consistency, cost vs. performance)
• Understand distributed systems concepts (load balancing, caching, database sharding, CDNs)
• Communicate architectural decisions clearly

The standard preparation resources are Grokking the System Design Interview (available on Educative.io), the System Design Primer on GitHub, and ByteByteGo. For UK senior roles in financial technology, additional knowledge of regulatory data requirements (GDPR, FCA regulations) is often expected.

Step 4: Simulate the Interview Under Real Conditions

Run timed mock interviews that match the real format before the interview day. Reading about interview formats is useful, but simulating them under real conditions is what builds performance under pressure.

For live coding interviews: use Pramp (peer mock interviews, free) or Interviewing.io (anonymous mock interviews with FAANG engineers). The platform simulates the exact environment of a real technical interview. Candidates who complete at least three mock sessions report significantly reduced anxiety and improved code quality in their real interviews.

For take-home assignments: find publicly available briefs from similar roles (many companies publish old case studies) and complete them under the self-imposed constraints of the actual task — same time budget, same tools, same output format.

For case study interviews: practise with a partner who plays the interviewer role. The Case Interview Community on Reddit has a partner-matching service used by UK consulting candidates at all levels. Timing your responses is critical — case interviews have strict time expectations that feel very different in practice than in preparation.

Step 5: The Day Before and the Day Itself

Stop active preparation the afternoon before, then protect your sleep. On the day, ask clarifying questions and think aloud throughout. Cramming new material the night before raises anxiety without improving performance.

The day before:

• Stop active preparation by mid-afternoon. Your brain consolidates memory during sleep, and attempting to cram new material the night before an interview increases anxiety without improving performance.
• Prepare everything you need: your development environment (for coding assessments), the video link (for remote interviews), the relevant tools and any materials you are permitted to use.
• Review your key strengths and two or three specific achievements you intend to reference in behavioural questions.
• Sleep. Seven to eight hours is not a luxury — verbal fluency and working memory both degrade meaningfully on less than six hours of sleep.

During the interview:

• Ask clarifying questions before starting a technical problem. "Just to confirm — am I optimizing for time complexity, memory, or readability here?" signals experienced engineering judgment.
• Think aloud throughout. Narrating your approach helps the interviewer follow your reasoning and helps you structure your thinking. "I'm considering two approaches here — a brute force O(n²) solution and a hash map approach that would give me O(n) — let me think through the trade-offs."
• If you get stuck, say so and be specific: "I'm not immediately seeing the optimal approach here — let me think through the edge cases." This is far better than silence, which reads as confusion rather than thought.

For guidance on managing nerves during the interview itself, see our article on interview anxiety tips. For assessment-specific preparation strategies, see our guide on how to prepare for a technical assessment or skills test.

Step 6: The Post-Interview Follow-Up

Send a brief follow-up email within 24 hours of a technical interview. Thank the team, reference one specific technical topic from the conversation that you found interesting, and confirm your continued interest in the role.

The follow-up email is standard practice in UK, US, and Australian hiring. In a competitive technical market where two or three candidates perform similarly, this small step can be the differentiator. See our guide on how to follow up after an interview for templates adapted to different seniority levels and markets.

FAQ

How long before a technical interview should I start preparing?

Start two to four weeks ahead for most roles. Spend the early period mapping the skills in the job description and rehearsing STAR behavioural answers. Reserve the final week for timed mock interviews. Senior roles with a system design round usually need the longer end of that range.

What is the STAR method and why does it matter in technical interviews?

The STAR method structures a behavioural answer into Situation, Task, Action, and Result. It matters because even technical interviews include behavioural questions, particularly in competency-based UK hiring. The STAR method gives the evaluator the context, your specific contribution, and the measurable outcome in one coherent answer.

Should I think aloud during a coding interview?

Yes. Narrating your approach lets the interviewer follow your reasoning and helps you structure your own thinking. Stating a trade-off, such as choosing a hash map for O(n) over a brute-force O(n²) solution, demonstrates engineering judgment that silent typing hides.

How do I prepare for a system design interview?

Study distributed systems fundamentals: load balancing, caching, database sharding, and content delivery networks. Practise designing well-known systems out loud, such as a URL shortener or a news feed. Resources like Grokking the System Design Interview, the System Design Primer on GitHub, and ByteByteGo cover the core patterns.

What should I do if I get stuck during a live coding interview?

Say so out loud and be specific about where you're stuck: "I'm not immediately seeing the optimal approach here — let me think through the edge cases." Interviewers read silence as confusion, not concentration, so narrating your reasoning even while stuck keeps the interviewer engaged with your thought process rather than guessing at it.

Analyse my CV free →