---
title: "How to prepare for coding interviews properly"
url: https://algopath.pro/blog/how-to-prepare-for-coding-interviews
language: en
summary: "Fewer problems, each one used four times, with recognition trained on its own. What to do in the weeks before a coding interview."
updated: 2026-09-09
---

# How to prepare for coding interviews properly

The usual advice is to solve a lot of problems.

 

That advice is incomplete enough to waste months.

 

This method is what I'd hand someone starting today.

 

## Split the four skills

 

An interview answer needs four things.

 

**Recognition.** Working out what kind of problem this is.

 

**Recall.** Remembering how that kind is solved.

 

**Boundaries.** Empty input, one element, no answer.

 

**Coding.** Writing it without bugs.

 

Most practice trains coding. It touches recall. It leaves the other two to chance.

 

Interviews fail on the other two.

 

Train them separately. That is the whole method.

 

## Practise recognition without solving

 

One habit here brings the highest value. It costs 3 minutes a problem.

 

Read the statement. Write two lines.

 

What kind of problem this is. Which words told you.

 

Check the answer here. If it's right, move on and leave it unsolved.

 

If wrong, write down what you thought it was. Then solve it.

 

You can do 20 of these in an hour. Solving 20 takes a day.

 

You need unlabelled problems for this. Most sites sort by topic, so the answer sits above the question.

 

Signals, pattern by pattern, are in [pattern recognition](/blog/leetcode-patterns).

 

## Use each problem four times

 

Solve a problem once and the work evaporates.

 

The fix is the [spacing effect](https://en.wikipedia.org/wiki/Spacing_effect). It is the best supported result in the learning literature.

 

**Day 1.** Solve it. Badly is fine.

 

**Day 4.** Read the statement. Name the pattern out loud. No code.

 

**Day 11.** Write the core from a blank file. No notes.

 

**Day 27.** Name the pattern in under 30 seconds.

 

Failing a step drops you back one interval.

 

Those gaps look odd on purpose. They sit just past the point where it starts to fade. Dragging it back is where the strength comes from.

 

## Recall, never re-read

 

Re-reading your old solution feels productive.

 

Familiar text produces a strong sense of knowing. That feeling dies in front of a blank editor.

 

Producing the answer instead has its own name, the [testing effect](https://en.wikipedia.org/wiki/Testing_effect).

 

Every review has to produce something. A blank file. Or say it out loud with the screen closed. Or write the approach on paper.

 

My rule: produced nothing, reviewed nothing.

 

## Add the timer late

 

An interview is a timed performance in front of a stranger.

 

Practise calm and untimed for months, and your first timed attempt is the interview itself.

 

Wait until a topic is comfortable. Take an unseen problem. Give yourself 25 minutes.

 

Talk the whole time, to an empty room. It feels ridiculous.

 

Talking out loud is also what gets scored. Interviewers grade the thinking they can hear.

 

Once a week is enough.

 

## Keep a confusion matrix

 

Wrong pattern calls get written down: what it was, what you said.

 

After 30 or 40, a shape appears.

 

Almost everyone has three or four pairs they keep swapping.

 

Two pointers against sliding window. [Greedy](https://en.wikipedia.org/wiki/Greedy_algorithm) against [dynamic programming](https://en.wikipedia.org/wiki/Dynamic_programming). BFS against DFS.

 

Those pairs are your study plan. New problems mostly test what you already get right.

 

## A week that works

 

3 sessions of 45 minutes. One long session does less.

 

Each session: 10 minutes of recognition, 25 minutes on one new problem, 10 minutes of review.

 

One timed spoken attempt a week.

 

Sunday: 10 minutes with the matrix. Pick next week's focus.

 

Under 3 hours a week. Four months of that beats a month of 6 hour days.

 

## What to skip

 

Top 150 lists, until you have the patterns. A list is an order of problems, and an order is not a curriculum.

 

Memorising solutions. It works for one problem and fails for its neighbour. Interviewers change one detail on purpose.

 

Videos of someone solving a problem they already know, unless you tried it first.

 

Why the material feels hostile in the first place is in [why people hate algorithms](/blog/i-hate-algorithms).

 

## Where I put this into practice

 

[AlgoPath](/) runs on this method. 194 unlabelled prompts. A review queue on the ladder above. A confusion matrix built from your own misses. A timed gauntlet.

 

The first 33 steps are free, and the trainer works inside them.