Reading solutions feels like learning and is not. What builds interview skill is committing to an answer before you see it. Use this loop for every puzzle.
Cover the page. Read only the prompt and the code. Do not open the hint or the solution.
Start a timer for the difficulty. Easy: 3 minutes. Medium: 6 to 8 minutes. Hard: 10 to 15 minutes. The tag is at the top of the puzzle page.
Work on paper or a whiteboard, with no simulator. Interviews have no compiler. Write assumptions first (types, widths, clock, sampling point), then trace.
Write the final answer down before the timer ends, even if you are unsure. A written guess can be scored; a thought cannot.
Stop when the timer stops. If you are not finished, write what you would do next. Running over the time teaches you a bad habit for the real interview.
Open the answer, then score yourself 0 to 4 with the rubric. Be strict: right result with no reason is a 2.
Read the solution, then 'How this was checked', then 'Why candidates get it wrong'. The last one is the interview signal.
Say it out loud (next section), then read the interviewer follow-up and try to answer it before reading the model answer.
Repeat misses. Re-do anything you scored 2 or lower after two days, and again after a week. Do not re-read; re-attempt cold.
Many puzzle pages end with a short spoken answer. It is the 20-second answer an interviewer wants to hear: the result, the rule, the trap. Knowing the answer silently is not enough, because the interview is spoken.
Before you open the spoken answer, record yourself answering the puzzle on your phone (voice memo is enough). Aim for 20 to 30 seconds.
Use this order: the answer first, then the one rule that decides it, then the trap, then what changes if the snippet is mutated.
Play it back. Count filler words, find where you hesitated, and check that the answer came first and not last.
Read the spoken answer on the page and compare structure, not wording: did you state the rule? Did you name the trap?
Record it again. Two takes are enough; do not polish a script, because the interviewer will change the question.
Each puzzle page says how its answer was verified. The line takes one of three forms, and each means something different.
The line says | What it means | How much to trust it |
|---|---|---|
Checked by running the code in <tool and version> | The snippet was compiled and run in that tool and the printed output supports the answer on the page. Where a tool prints something different for a legal reason, the note says so. | High for the behaviour shown. It proves the tool behaves that way, not that the language requires it: check the 'why' for the rule. |
Checked by running a model of the rule in a Python model | A small program computed the numbers (probabilities, bin counts, cycle lengths, times) from the rule. It is not a simulator and tells you nothing about tool behaviour. | High for arithmetic. The rule itself comes from the language reference and is explained in the solution. |
Not run here: <reason> | No tool or model run was done, and the reason is given (for example, it needs a feature the checking tools lack). The answer follows the language rules and the solution steps. | Reason it through yourself; if you have a simulator that supports the feature, run it. |
Some puzzles have a clear answer in the standard. Others have an answer that depends on the tool, and the page tells you which. The skill the interviewer is testing is knowing the difference.
fork-join-puzzles-2: Loop Variable Capture in Detached Threads: the order of two threads inside one time step is not defined.
queue-and-array-puzzles-1: Queue Mutation Plus Dynamic Resize: the exact layout printed by %p is tool-specific.
clocking-block-puzzles-1: Why Every Sample Is One Cycle Old: a 2-state tool prints 0 where a 4-state tool prints x.
queue-and-array-puzzles-3: Pop from Empty Queue: one tool returns x when popping an empty int queue, which the puzzle calls non-conforming.
When the standard leaves something undefined, two correct tools can give two different outputs, and neither is wrong. Say that. Do not pick a tool and pretend it is the rule.
When a tool does something the standard does not allow (the page calls this non-conforming), say that the behaviour is a tool deviation.
In an interview, give the answer the standard guarantees first, then say what is left to the tool. See interview-day tips for the exact wording.
Whether you reason from semantics (types, scheduling, solving order, sampling) instead of intuition.
Whether you can predict an exact output, not just 'it depends'.
Whether you can explain the trap, propose the fix, and say what happens when the snippet is mutated.
Whether you know the limit of what is defined, and say so clearly.