On a whiteboard with someone watching, what breaks first compared with solo untimed practice?
answer
- practice conditions decide what transfers
- what was the run button doing for you
- no undo, no autocomplete, an audience
- correctness must come from reasoning
- the idea was never the bottleneck
basics
~20 sVerification breaks first. With no run button you discover you had been checking correctness by executing rather than reasoning, and the audience plus the missing undo then eat the working memory you were using to hold the plan.
solid answer
~50 sThe first thing to go is not the idea, it is the verification habit. In solo untimed practice the run button quietly does your correctness checking: you write something plausible, run it, and let failures point at the bug. Take it away and you find out whether you can establish correctness by hand-tracing a small input — a genuinely different skill that untimed practice never exercises. Close behind it: no autocomplete exposes structure operations you knew by shape rather than by name, an audience consumes working memory so the plan you were holding in your head starts leaking, and the cost of erasing a block makes committing to a wrong layout much more expensive than in an editor. The conclusion is not that the idea skill is worthless; it is that practice transfers narrowly, so the reps closest to a loop should run under loop conditions.
go deeper
Know that practising with a timer and without running the code is a different exercise from solving at leisure, and expect to fail problems you thought you had. That failure is information, not a setback.
Explain which crutch each practice condition removes — execution as a correctness oracle, autocomplete as an operations reference, free undo, solitude — and what skill each one was hiding. Name hand-tracing as the replacement for the run button.
Show that you design the practice harness rather than just doing more problems: escalate from timed-no-execution to one-pass-on-paper to a watched attempt, and reserve fast-feedback practice for learning new patterns. Be specific about which reps go closest to a real loop.
Own the tradeoff for a team preparing at scale: watched mocks are the highest-fidelity rep and also the most expensive in peer hours, so decide where the cheap solo constraints buy most of the benefit and spend the scarce watched sessions on the failures those cannot reveal.
## The claim being tested The belief this question targets is: *"I can solve these untimed at home, so the timing and the audience are a formality."* It is a reasonable-sounding belief and it is wrong in a specific, diagnosable way — because untimed solo practice with an editor trains only one of the four skills a live round measures, and it trains it with several crutches attached. ## What the crutches were doing **The run button.** This is the big one. When execution is one keystroke away, the cheapest way to check an idea is to run it. Over hundreds of practice problems this builds a workflow — write plausible code, run, read the failure, patch — that feels like problem solving and is actually a guess-and-check loop with a very fast oracle. Remove the oracle and the question becomes: can you convince yourself this loop is correct before anyone executes it? That requires stating what the loop maintains at each step and checking the boundaries by hand. Candidates who have never practised without the oracle discover the skill is missing at the worst possible moment. **Autocomplete and reference lookup.** These let you know a structure's operations by shape rather than by name and cost. On paper you find out whether you actually remember which operations a heap gives you cheaply, or whether you had been discovering them from a suggestion list. **Unlimited retries and undo.** In an editor, restructuring is free: select, delete, rewrite. On a board, erasing a block is visible, slow, and costs composure. This changes the economics upstream — layout and naming have to be decided before writing, which is exactly why a real planning phase matters more here than in an editor. **Solitude.** An audience is not a superstition; it is a measurable load. Holding a plan in working memory while writing code while a person watches is strictly more demanding than doing the first two alone, and working memory is the resource the whole exercise runs on. The observable symptom is losing your place: you write four correct lines, look up, and cannot remember what the fifth was going to do. **The absence of a clock.** Untimed practice lets you take a break at the hard part and come back with a fresh mind. A timed round does not, so the ability to keep going through the uncomfortable middle is itself a trained skill. ## Transfer is narrow The general principle behind all of this is that practice transfers to conditions close to the practice conditions and degrades quickly as conditions diverge. Solving untimed in an editor is genuinely good for one thing — building a library of patterns and recognizing which one a problem fits — and that is worth a lot. It is simply not the same as producing a defensible solution in 40 minutes on a surface with no oracle while someone watches. ## How to build the harness cheaply You do not need a whiteboard or a partner for most of the benefit. A workable escalation: 1. **Editor, timer on, execution forbidden until you declare done.** This alone removes the oracle while keeping everything familiar. Declaring done before running is the whole drill. 2. **Paper, timer on, one pass.** No erasing whole blocks; if the layout is wrong you have to live with it or restart deliberately. This forces the planning phase to do real work. 3. **Paper or shared editor with a live watcher.** Adds the working-memory load and the accountability that makes you keep moving rather than pausing. Run the last reps before a real loop at level 2 or 3. Keep level-0 untimed editor practice for learning new patterns, where fast feedback is exactly what you want. ## The tell that the harness is working You will fail problems you "can already do." That is the point and it is the evidence the untimed impression was inflated. The first few attempts under the harness usually reveal a stable list — an off-by-one at the last element, an empty-input case never considered, a structure whose operation costs you had wrong — and that list is far more useful than another dozen problems solved comfortably.
- Interviews are mostly in a shared editor now. Does whiteboard-style practice still matter?Yes, because the shared editor usually removes exactly the crutches a whiteboard removes: no execution, no autocomplete, no reference lookup, and a person watching every keystroke. The physical surface was never the point; the missing oracle and the audience were. Practising in a plain editor with execution forbidden until you declare done reproduces almost all of it.
- How do you stop paper practice from just being slower typing?Make the constraints binding rather than cosmetic: one pass with no wholesale erasing, a timer with phase boundaries, and a rule that you declare the solution correct — with a hand-traced small input and its boundary cases — before anything is executed or checked. If you can execute at any moment, the guess-and-check habit survives the change of surface.
- Does this mean fast-feedback editor practice is a bad habit?No. Fast feedback is the right tool for acquiring patterns and for exploring an unfamiliar technique, where a tight loop teaches quickly. The mistake is using it exclusively and inferring interview readiness from it. Mix the modes deliberately: acquisition with feedback, rehearsal under the constraints you will actually face.
Rehearsing a talk by reading the slides silently at your desk is not the same rehearsal as saying it out loud on your feet, and the difference shows up only in front of the room.
saying these in an interview costs you the question
- If I can solve it untimed, I can solve it timed
- Whiteboard practice is obsolete now that rounds are remote
- The only difference is typing speed
- An audience does not change how I think
- Running the code is how you establish correctness