How to pass a technical interview: stages and…

A technical interview doesn't test how much you know by heart. In about an hour, the interviewer is trying to answer three questions: do you understand your stack, how do you approach an unfamiliar problem, and what would it be like to discuss code with you on the same team. Knowledge matters, but candidates more often fail for other reasons: they go silent over a task, recite memorized definitions, or argue with every hint.

So prepare for the format, not just the questions. Below is what a technical interview usually consists of, how to prepare for each part, and what to do during the conversation.

What a technical interview consists of

The format depends on the company and the level, but these parts are the most common:

Talking about your experience. What you worked on, which problems you solved, what was hard. The interviewer is looking for something to dig into later.
Questions about your stack. Theory: how the language, framework, database or network works. From mid level up, the questions shift to "why" and "what happens if".
A coding task. An algorithm, "what does this code print", finding bugs, refactoring. You write in a shared editor or in your own IDE while sharing your screen.
Your questions. The last five to ten minutes. These are evaluated too.

From mid level up there's usually system design as well, but it's a separate interview, often with a different interviewer. More on it below.

It's best to find out the stages in advance. A recruiter will almost always tell you if you ask directly:

Could you tell me what parts the technical interview will have? Will there be live coding, in which language, and can I run the code?

The answer narrows your preparation right away. If there's no live coding, the evening you planned for algorithms can go to stack questions instead.

How to prepare: a one-week plan

Find out what this company asks. Company profiles collect questions from real interviews. They show where a company tends to dig: some focus on theory, others go straight to a coding task.

Go through the questions for your stack out loud. Open the question bank for your area and answer each question out loud in a minute or two without looking. If you can't explain something simply, that's a weak spot. Reading correct answers isn't enough: in the interview you'll have to say them in your own words.

Solve problems with a timer and out loud. One or two problems a day is enough. What matters is not the number but the habit of talking through your reasoning. The live coding article covers how to do this in detail.

Prepare two or three stories about your projects. What the problem was, what you did personally, how it ended, and what you'd do differently. You'll almost certainly be asked about your hardest task, and here's how to answer that. If the project is under NDA, that's manageable too.

Reread your resume. Any technology on it can become a question. If you list Kafka, be ready to explain why it was needed and what you did with it.

Do at least one practice run. Ask a developer you know to grill you, or take a mock interview with an AI interviewer: it asks questions about your stack, follows up, and at the end shows where your answers were weak. One practice run takes away more nerves than another evening of reading.

If you're really short on time, there's a separate plan for the night before.

Stack questions: how to answer

A good structure: a short answer, then details, then an example from practice.

An index speeds up lookups but slows down writes, because it has to be updated on every change too. On my last project we added an index on the order status field, and the report query went from seconds to milliseconds.

The first sentence answers the question. The second shows you've actually used it. From there, the interviewer decides where to dig.

Don't turn it into a five-minute lecture. If the topic is big, answer briefly and offer to go on:

I can go into how it works under the hood if that's useful.

This way you don't spend time on what the interviewer doesn't need, and you give them a reason to ask about what you know well.

If you don't know the answer, don't make it up. Say what you know nearby and reason out loud. Ready-made phrases for this are in the article Don't know the answer in an interview?

The coding task

The main rule of live coding: the interviewer should understand what's going on in your head. The order is roughly this:

Restate the problem in your own words and clarify the edge cases.
Describe your plan before you start writing.
Write a simple working solution first, then improve it.
Run the code on a couple of examples, including empty input.
State the complexity and what you'd improve with more time.

Getting stuck isn't the problem. Getting stuck in silence is. If you can't see the solution, say what you're trying and ask for a specific hint.

A separate round: system design

System design is usually its own interview, most often after the technical one. The whole hour goes to a single task: design a service like a news feed, a URL shortener or a chat. There's no single right answer, what's evaluated is how you reason.

Start with requirements. How many users, what the read and write load is, what matters more: speed or consistency. Without this, any design is guesswork.
Draw the high-level picture. Client, API, services, database, cache, queues. Don't dive into details until the overall picture is ready.
Go deeper where the interviewer leads. They'll usually show you which part interests them.
Name the trade-offs. "A cache takes load off the database, but its data can lag by a few seconds. That's fine for a feed, not for an account balance."

You can practice this in the system design mode of the mock interview: it has a whiteboard where you draw the design, and the interviewer asks questions about it.

How to behave during the interview

Clarifying is fine, and expected. "Do I understand correctly that…" never looks weak.
Be honest about your experience. "I've used it but haven't gone deep" is better than a confident story that falls apart at the second follow-up.
Don't argue for the sake of it. If the interviewer pushes back, explain why you chose your approach and ask what they'd suggest. Sometimes they're just checking how you handle criticism.
Watch the time. If you have forty minutes for a task and thirty have passed, say what you'll finish and what you'll describe in words.

Your questions at the end

"No questions" sounds like a lack of interest. Ask about the team, the processes, how releases and code review work. It's also your chance to find out whether you want to work there. There's a list of questions worth asking in a separate article.

After the interview

Within an hour, write down every question you remember and mark where you felt unsure. A day later, half of it will be gone. These notes are your preparation plan for the next interview. How to review a failed round step by step is covered in Failed a job interview?

If you use a copilot

Sobes Copilot recognizes the interviewer's question and suggests an answer during the interview. But you're still the one who explains and defends the answer, and the follow-up questions will be for you too. So the preparation in this article matters even with suggestions: read the answer, put it in your own words, and be ready for "why did you do it that way?".

Checklist for the night before

You know the stages and whether you can run code.
You've checked your microphone, camera, screen sharing and the editor you'll write in.
You've reread your resume and prepared two or three stories about your projects.
You've gone through the main topics of your stack out loud.
You've written down three or four questions for the interviewer.
You have water, paper and a pen for diagrams nearby.