A practice protocol

Weight the mix to the loop. For this target, roughly half of practice time should go to JavaScript utility implementations and vanilla-DOM components — the BFE.dev and GreatFrontEnd style — because that is what the screen is. A quarter goes to pattern problems: hashing, two pointers, sliding window, binary search, BFS/DFS, and simple recursion. The last quarter is design-round and take-home rehearsal, which is where the highest marginal value sits for a senior role.

One problem, done properly, beats five skimmed. The protocol per problem: 25 minutes on a timer, in a plain editor with no autocomplete and no AI assistance, speaking out loud as if someone is watching. If you are stuck at 25 minutes, look at the approach only — not the code — and then implement it yourself. Afterwards write two lines: what the recognition cue was ("sorted input plus find-a-pair → two pointers") and what you got wrong. Those two lines are the actual artefact. Re-solve the problem cold three days later, then two weeks later.

Practise the format, not just the content. Type the solution rather than reading it. Run it, with your own test cases including the empty and single-element ones. Record yourself occasionally, or use a mock-interview partner — hearing your own filler and dead air is uncomfortable and effective. If the company uses a shared editor, practise in a browser-based one, because losing your keybindings and formatter for the first time during the real thing costs real minutes.

Know when to stop. This section is deliberately small, and the practice should be too. Coverage of the patterns matters much more than volume, and hitting diminishing returns here means time is better spent on React internals, a system design rehearsal, or sharpening the deep-dive story about your own work — all of which are weighted more heavily in these loops. Two or three focused sessions a week, sustained, beats a fortnight of grinding.

Keep a mistake log. One file, one line per error: comparator returned a boolean, forgot to un-choose in backtracking, off-by-one on the window's right edge, mutated the input when it wasn't allowed. Reread it before an interview. Mistakes repeat, and the log is the cheapest possible intervention.

Most preparation failures are format failures, not knowledge failures — knowing the pattern but freezing when the timer, the unfamiliar editor, and another person's attention are added. Practising under those exact conditions removes the surprise, and the spaced re-solve is what converts "I recognise this" into "I can produce this cold".

• Weight practice to the actual loop: about half utility and component implementations, a quarter pattern problems, a quarter design and take-home rehearsal.
• Time-box to 25 minutes, in a plain editor, out loud — practise the conditions, not just the content.
• After 25 minutes look at the approach only, never the code, and then write it yourself.
• Write down the recognition cue for each problem; pattern recognition is the transferable skill, the solution is not.
• Re-solve cold at three days and two weeks — spaced retrieval is what makes recall survive interview pressure.
• Keep a one-line-per-mistake log and reread it before interviews, because the same mistakes recur.
• Always run your solution against empty, single-element, and duplicate inputs before declaring it done.
• Stop at pattern coverage rather than problem count; further volume here is worth less than React depth or design practice.