Coding interview anxiety: practising under a timer
Elman Huseynov · 2026-09-08 ·
Add a timer after you can solve the pattern untimed. Adding it earlier trains panic and nothing else.
The timer is a diagnostic. Its job is to show what breaks when there is no time to think.
What a timer actually removes
Pressure does not make you slower at typing. It takes away working memory.
Working memory holds the invariant, the loop bounds and the edge cases while you write.
Anxiety occupies part of it. Ashcraft and Kirk showed this for maths in 2001.
Same mechanism when you forget an approach you knew ten seconds ago.
A timer takes the thing you were relying on. Holding several things in your head at once.
Everything you had written down survives. That is the lever.
Three phases, in order
Phase 1. No timer. Solve until you can produce the pattern correctly with the tab closed. A timer here just tells you what you already know.
Phase 2. A generous timer. 40 minutes for a problem you would normally finish in 20. It creates awareness of the clock without a threat.
Phase 3. The real thing. 25 to 30 minutes, cold problem, out loud, no pausing.
Some pressure helps and too much stops helping. That curve has a name, the Yerkes-Dodson law.
Most people jump straight to phase 3 in week one. Then they conclude they are bad at algorithms.
The honest reading: they were tested before they were taught.
The five-minute rescue
Your mind goes blank. Here is the script. It needs no working memory at all.
- Say the input and the output out loud.
- Write a tiny example, four elements, by hand.
- Solve that example on paper the slow way. Any way at all.
- Look at what your hand did on each step. That is usually the algorithm.
- Say which pattern it resembles. Say which word points there. That is reading the statement under pressure.
Every line is external. Paper, voice, a written example. Nothing asks you to hold state.
Practise the script itself, not only the problems.
You will need it once. It decides between a bad twenty minutes and a bad hour.
Slow is a separate diagnosis
Missing the time limit has three causes. Each needs a different fix.
Too long deciding the pattern means recognition work. Too long writing means you have not written that structure enough times. Too long debugging means you skipped the edge cases at the start.
Practise in the language you will use: all six are supported.
Write down which one it was.
Otherwise "I ran out of time" becomes the whole diagnosis. There is nothing to act on in that sentence.
The one honest use of a timer
A timer answers one question. Can you do this without the pause where you look something up?
The timer's answer is worth knowing two weeks before an interview. It is worth very little two months before.
Where this is built in
AlgoPath keeps the timed work separate. The steps are untimed.
The recognition drill and the gauntlet run on a clock. Both come after the pattern is in place.
The first 33 steps are free.