The technical interview is where a company checks that a candidate can actually do what the resume says they can do. Unlike the recruiter screen, there is a concrete problem on the table: a coding exercise, a business case, a lab procedure, a demo lesson. And unlike what many candidates assume, the correct answer is only part of what is being scored.
This guide covers the most common technical interview formats, lays out a one-to-two-week preparation plan, explains what the evaluator observes beyond the result, and walks through the mistakes that produce the most rejections. It applies to software roles, but also to finance, teaching, design, engineering, and any field where a hands-on assessment exists.
In this guide
What a technical interview is and where it shows up
In almost every hiring process with more than one round, the technical interview comes after the initial recruiter screen and before the final conversation with the hiring manager. It is run by someone who does or supervises the actual work: a tech lead, a department manager, a senior professional. Their goal is to reduce uncertainty around a single question: if this person joins the team on Monday, can they solve the real problems of the role?
The name changes by industry. In tech it is a technical screen or onsite; in consulting, a case interview; in education, a demo lesson or teaching demonstration; in healthcare and labs, a skills assessment or practical exam. The format varies, the logic does not: show the work instead of describing it.
The most common technical interview formats
It pays to confirm the exact format ahead of time. Most recruiters will share it when asked, and spending a week preparing for live coding when a take-home is coming is a week wasted.
Live coding or live exercise
The candidate solves a problem in front of the evaluator, in a shared editor or on a whiteboard, for 45 to 60 minutes. Problems are usually of medium difficulty: manipulating data structures, traversing a collection, designing a function with edge cases. What counts is the process: how the prompt is understood, what questions get asked before writing, and how the candidate reacts to their own mistakes.
Take-home assignment
A written prompt arrives and the deliverable is due in two to five days. It tends to be a small but complete project: an API with two endpoints, an analysis of a dataset, a design proposal for a screen. Speed is not the point here; judgment is: readability, tests, brief documentation, and justified decisions. A ten-line README explaining what was built and what was left out for lack of time is worth as much as the code.
System design
Reserved for candidates with a few years of experience. The evaluator poses an open-ended problem ("design a notification system for one million users") and expects the candidate to ask questions, scope the problem, propose an architecture, and discuss trade-offs: consistency versus availability, cost versus latency. There is no single right answer; what is measured is the ability to hold a conversation about technical decisions.
Case interview
Standard in consulting, finance, marketing, and product roles. A situation is presented ("a client is losing 10 percent of sales every quarter, what would you do?") and the candidate is asked to structure the analysis out loud, estimate magnitudes, and reach a recommendation. The order of the reasoning matters more than the final number, as long as the number can be defended.
Practical assessments in other fields
Technical interviews exist outside of offices too: the 20-minute demo lesson in front of a hiring committee, the tasting or line test in restaurants, the bank reconciliation exercise for an accounting role, the timed translation of a page, the diagnosis of a fault on a piece of equipment. Preparation follows the same logic as in tech: know the format, practice under time, and explain what is being done while doing it.
How to prepare in one to two weeks
With the format confirmed, one to two weeks is enough to arrive in good shape if the time is spent wisely. The plan below assumes roughly 8 to 12 total hours, spread across short sessions.
- Days 1 and 2: reread the job posting and map the syllabus. Every technology, tool, or competency mentioned in the posting is a likely topic. Write down which ones are solid and which are shaky, and concentrate study time on the second group.
- Days 3 to 6: practice problems of the expected type. For live coding, two or three medium-difficulty exercises a day, timed and out loud. For case interviews, one case a day with a written structure. For demo lessons, the full lesson plan rehearsed in front of someone.
- Days 7 and 8: review role fundamentals. The concepts a senior evaluator expects anyone at this level to handle without hesitation. Typical questions by level are covered in the guide to junior developer interview questions.
- Days 9 and 10: full mock interview. One session with the real duration and format, with another person or a simulator, followed by an honest review of what went wrong.
- The day before: rest and logistics. Development environment tested, camera and microphone checked if remote, and no new topics.
The non-technical side of preparation (researching the company, preparing questions of your own) is covered in the guide on how to prepare for an interview. Skipping it is a mistake: a technical interview is still an interview.
What is evaluated beyond the answer
An experienced evaluator knows that a 45-minute exercise is a small sample. That is why they watch for signals that predict real-world performance better than the outcome of the exercise itself.
Thinking out loud. This is the factor that carries the most weight and gets practiced the least. Narrating the reasoning ("first I'll validate the input, then handle the general case, and finally check the edges") lets the evaluator follow the process and step in if needed. Prolonged silence, even when it ends in a correct solution, leaves the evaluator with nothing to score.
Questions before starting. A technical prompt almost always contains deliberate ambiguities. Asking about data size, edge cases, or time constraints shows the habit of understanding a problem before solving it, which is exactly what the job requires.
Reaction to mistakes. Making an error during the assessment is normal, and for the evaluator it is a chance to see something valuable: whether the candidate catches it alone, how they fix it, and whether they accept a hint without getting defensive. A candidate who gets stuck and asks for a minute to regroup comes across better than one who insists on a wrong path.
The questions the candidate asks at the end. Asking how code review works, which tools the team uses, or how the team decides what to build shows interest in the actual work. The guide on questions to ask in an interview has examples that work for this round too.
When the answer is unknown, the worst option is to make one up. Saying "I haven't used it, but my understanding is that it works like this, and here is how I would verify it" signals honesty and method. Defending a false answer under follow-up questions is an almost certain rejection.
Common technical interview mistakes
Rejections at this stage are rarely due to a total lack of knowledge. They come from habits an evaluator spots quickly and that practice can fix.
| Avoid | Better |
|---|---|
| Starting to write code the moment the prompt is read | Restating the problem out loud and asking two or three questions before writing |
| Solving in silence for ten minutes | Narrating the plan and every intermediate decision, even the obvious ones |
| Optimizing from the start and never finishing | Delivering a working solution first, then improving it if time remains |
| Submitting a take-home with no tests and no README | Including minimal tests and a README with decisions and open items |
| Arguing with a hint from the evaluator | Taking it, thanking them, and moving on; the hint is part of the exercise |
| Answering "I don't know" and going quiet | Explaining how the answer would be found and what would be tried first |
| Having no questions prepared for the end | Bringing two questions about how the team works day to day |
One more mistake, specific to take-homes, is spending three times the suggested effort. Evaluators notice, and they do not necessarily reward it: a 40-hour submission for a 6-hour prompt suggests difficulty with scoping, not dedication.
Practicing the format before the day
The gap between knowing how to solve a problem and solving it while someone watches shows up on the first attempt. That is why the full mock on days 9 and 10 is not optional: it reproduces the pressure, forces talking while thinking, and exposes filler words and dead air.
There are three ways to do it. With a colleague acting as the evaluator, the most realistic option but hard to schedule. Recording on a phone while solving an exercise out loud, useful for catching long silences. Or with an AI interview simulator that asks role-specific technical questions, follows up on the answers, and returns an evaluation at the end. The guide on mock interviews with AI explains how to get the most out of it. Two rounds are usually enough for thinking out loud to stop feeling forced.
Frequently asked questions
How long does a technical interview last?
It depends on the format. A live coding session or a system design interview runs 45 to 90 minutes. A take-home is due in two to five days, with a suggested effort of 4 to 8 hours. Case interviews usually take 30 to 45 minutes per case.
What happens if the exercise is not finished?
It is not an automatic rejection. Many exercises are designed not to be finishable in the allotted time, precisely to see how the candidate prioritizes and communicates. A partial solution, well explained and with the remaining work identified, is often scored higher than a complete one produced in silence.
Can the internet or documentation be used during the assessment?
In a take-home, yes, and it is expected. In live coding it depends on the company: some allow it explicitly, others do not. Ask before starting; the question itself costs nothing.
How to prepare when the posting does not say what kind of assessment there is?
Ask the recruiter. It is a normal request, it almost always gets answered, and it avoids preparing for the wrong format. If there is no reply, the safest assumption is a live exercise of medium difficulty on the core technologies or competencies of the posting.
Are there technical interviews outside of software?
Yes, under other names: demo lessons in education, case interviews in consulting and finance, practical assessments in restaurants, healthcare, trades, and labs. The preparation logic is the same: know the format, practice under real time constraints, and explain what is being done while doing it.