How to Practice Coding Interviews Alone: A Real System

Most coding interview advice quietly assumes a second person: a friend who also interviews, a senior who owes you a favour, a coach you can pay. Without one, the question of how to practice coding interviews alone collapses into "solve more problems" — the one thing you already know how to do, and the thing that is probably not what is failing.

This is the version that works with nobody else in the room. It assumes you can already code; the skill it builds is saying the right things, in the right order, under a clock, while part of your brain is busy with an array.

What a practice partner actually supplies

Before you replace a partner, be precise about what they do. It is three things, and only one of them genuinely needs another human.

• An audience. Someone to narrate to, which drags the explanation out of your head and into sentences. You cannot skip a step out loud the way you can skip it in thought.
• Pressure. Being watched changes your pacing — it is why people who solve a problem in twelve minutes alone need thirty-five with an observer.
• An unscripted objection. The "does that handle duplicates?" you did not plan for, arriving at the worst moment.

An audience and pressure are both reproducible: a recorder and a timer do most of that work. The unscripted objection is the hard one, and it is also where the most score is decided. Keep that asymmetry in mind — it tells you where to spend the one favour you can call in.

Six ways to practice coding interviews alone, in order of payoff

Ranked by how much interview score each one moves, not by how comfortable it is. The first two are not optional.

1. Narrate to an empty room, with a timer running

Set forty-five minutes. Pick a problem you have not seen. Then do the whole thing out loud — restating the question, the input ranges you are assuming, the two approaches you are choosing between, why you picked one, the complexity, the edge cases, and the walkthrough at the end.

It feels absurd for the first two sessions and then it stops feeling like anything. That transition is the point: in a real round you want narration to be a reflex, not a performance you have to remember to give. Most candidates who "go blank" under pressure have simply never said these sentences out loud before.

2. Record it and watch only the first three minutes

Recording is what replaces the second pair of eyes, and the first three minutes are where almost all of a scorecard is won or lost. Watch for four specific things: did you restate the problem in your own words, did you ask about input size and duplicates, did you name an alternative approach before committing, and did you say the complexity of the approach you chose before writing code.

You will be unpleasantly surprised the first time. Most people discover they went silent somewhere around second forty and stayed silent until the code compiled.

3. Write the interviewer's objections before you start

This is the cheapest approximation of a live interviewer. Before you begin, write three questions a reviewer would ask about any solution to this problem — "what if the array is empty", "what is the memory cost at ten million elements", "why not sort first" — fold the paper, and open it at minute twenty-five. Answer them out loud, on the clock.

It is scripted, so it cannot surprise you. What it does train is the recovery motion: being interrupted mid-thought, parsing the objection, and answering it instead of repeating your original explanation.

4. Explain the solution to someone who cannot code

A flatmate, a sibling, a parent. Not for technical feedback — for the compression. If you cannot explain the approach without the words "hashmap" and "O(n)", you are leaning on vocabulary rather than understanding, and a good interviewer will find that in one follow-up question.

5. Review your own code the way a reviewer would

After the clock stops, read your solution as a pull request from a stranger. Google's published standard of code review is a useful bar here, including its central caveat that there is "no such thing as 'perfect' code—there is only better code". Interviewers apply roughly that standard: not perfection, but whether the code is readable and could go in.

Concretely, ask whether a stranger could name what each variable holds, whether the function would survive an empty input, and whether you would need to explain any line of it aloud for it to make sense.

6. Add an AI interviewer for the part you cannot fake

Everything above is a drill. None of it pushes back when your answer is weak, and pushing back is the dimension solo practice structurally cannot reach. This is the gap an AI interviewer fills: it asks the follow-up you did not script, it does not get bored on your fourth attempt at the same problem, and it is available at eleven at night on a Tuesday, which no human mock partner is.

It is not a replacement for a real interview loop. It is a replacement for the objection you cannot generate yourself. We have written separately about how to structure a month of preparation with these tools, and compared what the free tiers actually include across the ones worth using.

The forty-five minute solo session, phase by phase

A session without structure becomes a problem-solving session with extra steps. Run these phases with a visible clock, and treat the boundaries as real.

The phase clock

Minutes 0–4: clarify out loud

Restate the problem. State your assumptions about input size, value range, duplicates, sortedness and expected output format. Say them even though nobody will confirm them — the habit is what you are building, and in a real round these forty seconds move problem understanding from a 1 to a 3.

Minutes 4–9: two approaches and a price

Name a brute-force approach and its cost, name a better one and its cost, then choose and say why. Out loud, in full sentences. Jumping straight to the optimal solution scores worse than you would expect, because nobody can tell whether you reasoned to it or recognised it.

Minutes 9–32: code, still talking

Keep a thin commentary running: what the loop is doing, why the index starts where it does, what you are deferring. When you go quiet for more than about twenty seconds, notice it on the recording later — that silence is the single most common piece of feedback in the whole category.

Minutes 32–40: verify before being asked

Walk one real input through your own code, by hand, out loud. Then the empty input, the single element, and the duplicate case. Offered verification is worth considerably more than extracted verification on every scorecard.

Minutes 40–45: score yourself, then stop

Write the scores down before you watch the recording. Comparing your guess to the playback is how you find out which parts of your own performance you cannot see — which is the actual blind spot a partner would have covered.

Score the session against a real rubric, not a feeling

"That went badly" is not usable feedback. A rubric is, and you can apply ours to your own recording. Taqari's coding round is scored on four model-judged criteria, each on a nought-to-three scale:

• Correctness of approach — does the algorithm solve the stated problem, including the edge cases it implies. Explicitly not "did the tests pass".
• Complexity reasoning — can you state the time and space cost of your own solution and defend it. Nought is no claim, or a wrong claim left uncorrected.
• Communication under questioning — when pushed, does the explanation get clearer or vaguer.
• Response to a hint — what you do with a nudge, which is often more predictive than where you started.

The full dimension-by-dimension breakdown, including what a 2 and a 5 look like on a human interviewer's form, is in our write-up of the coding interview evaluation criteria. What a finished session hands back looks roughly like this:

Complexity reasoning             2 / 3
  You stated O(n) time correctly at 06:14, unprompted.
  Space cost was not mentioned until it was asked for.
  To reach 3: price the data structure, not only the loops.

Communication under questioning   1 / 3
  Asked "does this handle duplicates?" at 09:02, you repeated
  the original explanation rather than addressing the case.
  To reach 3: restate the objection, then defend or revise.

Grading your own recording

Scoring yourself, two of the four are easy to judge from a recording and two are not. Correctness and complexity you can grade honestly. Communication under questioning and response to a hint need someone, or something, to do the questioning — which is exactly why those two are the reason to add a live element rather than a seventh drill.

The honesty problem

Self-scoring drifts upwards. The fix is to write each criterion as something you could point at in the recording with a timestamp. "Explained well" is an adjective and you will always award it to yourself. "Restated the objection before answering it" either happened at 09:02 or it did not.

A recording setup that takes two minutes

There is no need for a studio. Two options, both adequate:

Your phone, propped against a book

Audio is what matters; you are listening for silences and vague sentences, not watching your face. A phone on a shelf pointed at your desk is a complete setup. The only rule is that you watch it back — an unwatched recording is a ritual, not a method.

The browser, if you want it automatic

If you would rather not touch a phone, the browser records natively. The MediaStream Recording API captures a microphone or screen stream through a MediaRecorder and hands you the data in chunks you can save to a file — it is the same browser primitive behind most practice tools, and perfectly usable directly. If you want a text transcript to scan instead of audio to re-listen to, the Web Speech API exposes SpeechRecognition in the browser, with the option of running recognition on-device.

A transcript is genuinely better than audio for one specific job: counting how many sentences you spoke in the first three minutes. That number, more than any score, predicts how a real round will go.

What solo practice cannot fix

Being honest about the ceiling is more useful than pretending there is not one.

• Recovering from a genuine surprise. You cannot ambush yourself. Scripted objections train the motion; they do not train the panic.
• Calibration against a real bar. Alone, you have no idea whether your thirty-five-minute solution is fine or slow for the level you are targeting.
• Reading a person. Noticing that an interviewer has gone quiet because you are heading the wrong way is a skill with no solo equivalent.
• Interview nerves. Partly reducible by repetition, never eliminated by practising in your own room.

Which gives a clean rule for how to practice coding interviews alone: use solo sessions for volume and habit, and spend any live opportunity — a friend, a senior, an AI interviewer — entirely on being interrupted. Do not spend a scarce mock on a problem you could have narrated to a wall.

Mistakes that make these sessions worthless

• Practising silently. It becomes a problem-solving session. Useful for DSA, nearly useless for interviewing.
• No clock. Without a hard stop you never learn what you do at minute thirty-eight, which is the only minute that reliably hurts.
• Recording and not watching. The review is the entire value; the recording is just the storage.
• Only practising problems you can solve. You need sessions where you get stuck, because recovering out loud is itself a scored skill.
• Treating the score as the output. The output is one sentence about what to change next session. Everything else is bookkeeping.

Four weeks, one change at a time

Pick one thing per week and let the overall score go wherever it goes. Trying to fix everything at once reliably fixes nothing.

1. Week one: say the first four minutes. Two sessions. Success is restating the problem and naming your assumptions every time, nothing else.
2. Week two: price everything. State the complexity of both approaches before coding, unprompted, in every session.
3. Week three: verify unasked. Walk an input through your code by hand at the end, every time, including the empty case.
4. Week four: get interrupted. Sealed objections at minute twenty-five, or a live round with a person or an AI interviewer. This is the week that needs the second voice.

Two sessions a week, eight sessions total, three problems of real narration each. That is roughly twenty-four properly rehearsed problems in a month — far fewer than most preparation plans claim, and considerably more interview-ready.

The short version

If you have solved hundreds of problems and still get rejected after the coding round, another pattern is very unlikely to be the missing piece. What is missing is almost always the half of the interview that happens out loud — and that half is rehearsable alone, as long as you actually speak, actually time it, and actually watch it back.

Start with one recorded forty-five minute session this week and watch the first three minutes of it. If it tells you what you suspect it will, add the one thing a room cannot give you: something that interrupts. You can run a free mock round and read the per-criterion feedback before committing to anything paid.