Before the interview
Coding interviews differ more than they used to. Knowing which kind you'll get, and practicing for that kind, is most of the preparation.
Find out the format
Ask the recruiter. It's a normal question, and the answer changes how you prepare:
- What kind of problem is it: a short algorithm, an existing codebase, or building something from scratch?
- Will I use your environment or my own editor? In which language?
- Are AI tools allowed, and which ones?
- Is there a practice environment I can try beforehand?
- How long is it, and is it one part or several?
The three formats
| Aspect | Algorithm problem | Existing codebase | Build from scratch |
|---|---|---|---|
| You get | One small, self-contained problem. | A small project with a bug to fix, a feature to add, or both. | A short brief and an empty project. |
| They look for | Choosing the right approach, clean code, knowing its complexity. | Reading code fast, small safe changes, testing beyond what's given. | Structure and design decisions, and a working core before extras. |
| Practice with | Classic problem sets - timed, and out loud. | Bug-fixing and feature exercises in our catalog. | Empty-project exercises in our catalog. |
Any of the three may allow AI tools - another reason to ask.
Practice the real conditions
Solving a problem in your head isn't the same as solving it in an interview. Practice with a clock running, talking out loud, in code you didn't write, with someone - or something - asking you questions. Rehearse the tools too: opening a terminal, running a single test, reading a stack trace.
That's what our practice sessions are built for: a real codebase, a clock, and an AI interviewer that asks follow-up questions.
A two-week plan
- Week 1
- A practice session every day or two, alternating formats. After each one, write down the one habit that cost you the most.
- Week 2
- Full-length mock interviews. Before each one, reread your note from the last. Practice answering questions about your own code.
- The day before
- Check your setup, microphone and screen sharing. Reread the checklist at the end of this page. No new topics - sleep instead.
During the interview
Eight habits, roughly in the order you'll need them. None of them is about knowing more - they're about showing what you know.
1.Clarify before you write code
The first minutes decide whether you solve the right problem. Tasks are often a little vague on purpose, to see whether you notice. Restate the task, ask about the rules, and say your assumptions out loud.
What it sounds like
- “So the task is to accept or reject each booking - did I get that right?”
- “What should happen when the list is empty?”
- “I'll assume times never go backwards. Is that fair?”
The common mistake: Typing in the first minute, then finding out halfway through that the task meant something else.
See it in a real session: asking about a rule.
2.Read the code before you change it
When you're given a codebase, reading unfamiliar code quickly is the skill being tested. Find where the behavior lives, run what already exists, and read the failing test before you form a theory.
What it sounds like
- “Let me run the tests first, to see where we stand.”
- “The behavior in the complaint is decided here, in book().”
The common mistake: Rewriting a function you haven't understood, and breaking something that worked.
See it in a real session: running the tests first.
3.Plan in a few sentences
A short plan, said out loud, lets the interviewer follow you and correct course early. Mentioning an option you didn't take shows you weighed it.
What it sounds like
- “I'll keep a list of meetings per room and check each new one against it. Sorting would be faster, but I'll get the simple version right first.”
- “I'll fix the first complaint, then look at the second one.”
The common mistake: Designing in silence for ten minutes, or starting with the clever version before a simple one works.
4.Work in small, checked steps
Change one thing, run it, look at the result. Small steps keep bugs small, and every passing run is progress the interviewer can see.
What it sounds like
- “One change: the end time no longer counts as a clash. Running the tests again.”
The common mistake: Writing everything at once, then spending the last twenty minutes debugging all of it.
See it in a real session: a one-character fix.
5.Test what nobody gave you
The given tests only check what someone thought of. Boundaries, empty input, duplicates, and the case that contains another case are where bugs hide - and where strong candidates stand out.
What it sounds like
- “The given test passes, but it never tries a meeting that covers another one. Let me add that.”
The common mistake: Stopping the moment the given tests turn green.
See it in a real session: finding the case the tests missed.
6.Think out loud
The interviewer can only judge what they can see. Narrate decisions, not keystrokes: what you're checking, what you expect, and why you chose it.
What it sounds like
- “I expect this to fail on the second booking - let's see.”
- “I'm reading the loop now. Give me a moment.”
The common mistake: Long silences. Even a strong solution scores lower when nobody knows how you got there.
7.When you're stuck
Everyone gets stuck. What counts is what you do next: say where you are, shrink the problem to a smaller example, and ask a precise question.
What it sounds like
- “I'm stuck on why this case passes. Let me try it with just two meetings.”
- “Can I check one thing: should a cancelled meeting free its slot right away?”
The common mistake: Going quiet and trying random changes until something works.
8.If AI tools are allowed
More interviews now let you use an AI assistant. The bar doesn't drop - it moves. You make the decisions and the AI types; interviewers watch whether you stay in control of the code.
- Plan first, then give it one clear, small instruction - not the whole task.
- Read every line it writes before you run it.
- Run the tests after every change it makes.
- Say what you asked for and why, and whether you agree with the result.
- Use it freely for practical things: syntax, a library call, how to run one test.
The common mistake: Pasting in the task and accepting whatever comes back. A wrong suggestion you didn't check counts against you.
If AI isn't allowed, nothing here changes - you type it yourself.
At the end
Many interviews close with questions about what you built. This is where a decent solution becomes a convincing one.
Questions about your work
Expect some of these:
- “Walk me through your design.”
- “Why this data structure?”
- “Which edge cases did you consider, and how did you check them?”
- “What would you change with more time, or before shipping it?”
- “How would you test it further?”
How to answer
- Be specific: name the function and the case.
- Point out the gaps you know about before they find them.
- “I'm not sure, but I'd check it by…” is a good answer. Guessing confidently isn't.
- Answer, then stop. Short is fine.
See it in a real session: the end-of-session conversation.
Your questions for them
Have one or two ready: how the team reviews code, what a first project usually looks like, how they use AI tools day to day. A real question tells them you're picturing the job, not just the interview.
The checklist
The whole page on one screen. Reread it the day before.
Before
- Know the format
- Practice out loud, against a clock
- Note one habit to improve
- Check your setup
During
- Restate the task, ask about the rules
- Read and run what exists
- Plan in a few sentences
- One change, then run it
- Test the cases nobody gave you
- Keep talking
At the end
- Name functions and cases
- Admit known gaps
- “I'm not sure, but I'd check…”
- One or two questions of your own