How many practice problems do I need before a technical interview?

Fewer than you think, if they're spaced and reviewed. One problem a day for six weeks, each followed by a real review and a log entry, plus weekly re-attempts of what you got wrong, builds more transferable skill than hundreds of problems crammed.

Should I practice talking out loud?

Yes — it's the most effective single habit. Interviews reward visible reasoning more than silent correct answers, and narrating your thinking alone, with a timer, makes the real thing feel familiar.

What should I do the night before?

Very little. Light review of your notes, one easy problem to stay warm, and sleep. Attempting hard new material the night before risks a confidence-denting failure with no time to recover.

Technical interviews: a practice system that beats cramming

July 7, 2026 · 4 min read

Technical interviews test recall and reasoning under pressure, and cramming optimizes for neither. Fifteen problems the night before produce a tired candidate who half-remembers all of them. Spaced, realistic practice over a few weeks produces someone who can think clearly with a stranger watching — in less total time. The system below is built on how skills are actually retained, and it fits around a full-time job.

Daily, small, spaced

One problem a day for six weeks beats fifteen on the weekend before. Each session is thirty to forty-five minutes: a problem attempted cold, then a review. The spacing is the point — retrieving an idea after a day's gap is what makes it stick, and a small daily habit survives a busy week where a weekend marathon does not. If you have longer, three shorter sessions beat one long one.

Practice the format, not just the content

Interviews have conditions: a time limit, an audience, the need to explain as you go. Replicate them. Set a timer. Talk out loud through your reasoning as if someone were listening — it feels absurd alone and it is the single most effective thing you can do, because the interview rewards visible thinking more than a silent correct answer. Use a plain editor or a whiteboard rather than your full development environment with autocomplete, if that matches the interview format.

Review is where the learning happens

Attempting the problem is half the session. The other half:

If you solved it, compare your approach with a good reference solution. Where was yours slower or less clear? What pattern did you miss?
If you did not, read the solution until you understand it, close it, and write it from scratch. Reading is not learning; reproducing is.
Write one line in a log: the problem, the pattern it used, and what you would do differently. This log becomes your revision material.

Cover patterns, not problems

There are far more problems than you can practice and far fewer underlying patterns than you fear. Organize your six weeks around the patterns that appear most in your target role — for software roles, the common data structures and the handful of algorithmic techniques; for data roles, the query and statistics patterns; for infrastructure roles, the system design and troubleshooting shapes. When a new problem arrives, the useful question is "which pattern is this?" Practicing pattern recognition is what makes an unfamiliar problem tractable.

Revisit what you got wrong

Every Sunday, re-attempt two problems from your log that you struggled with earlier — without looking at your notes first. If they are now easy, cross them off. If not, they go back in the queue. This is spaced repetition applied to your own weak spots, and it is far more efficient than working through a fresh list.

Add realism in the last two weeks

Do at least two full mock interviews with another person — a friend in the field, a peer preparing for the same thing, or a structured mock service. The presence of a real listener changes everything: the pace, the nerves, the need to explain. Ask for blunt feedback on your communication, not just your correctness. Most candidates who fail technical interviews knew the answer; they failed to show their thinking or froze on a small mistake.

Prepare the non-technical parts too

Technical loops include behavioral rounds and questions about your past projects. Prepare two or three projects in depth: the problem, your specific contribution, the hard decision, what you would change. Interviewers probe these to check the resume is real. A candidate who solves the coding problem and then cannot explain a project they listed raises exactly the doubt they were trying to dispel.

The week of the interview

Taper. Light review of your log, one easy problem a day to stay warm, and sleep. Do not attempt hard new material; a failed problem the night before does more harm to your confidence than a success does good. Arrive with the patterns fresh, the nerves familiar from mocks, and the sense that this is one more session in a system you have been running for weeks — because it is.

Why this beats cramming

Cramming stores information in a form that decays within days and collapses under stress. Spaced practice stores patterns that are retrievable under pressure and transfer to problems you have not seen. Six weeks at forty minutes a day is roughly thirty hours — less than many candidates spend in two frantic weekends — and it arrives at the interview as ability rather than memory.