Give a technical walkthrough that survives questions

A technical walkthrough should start with the user's result. Show the smallest fixture and the expected output, then explain the code path that produces it. This lets the interviewer assess your decisions against something concrete. Starting with a folder tour forces them to infer why the application exists.

Prepare to distinguish what you built from what a framework supplies. Explain the data transformation, state ownership, authorization boundary, and error handling in your own work. If you used generated code, you still need to understand its behavior and verify the important path. Follow the specific employer's stated tool rules. Different interview stages can permit different assistance.

Use a decision record that includes the constraint and rejected alternative. For example, local fixture data may be the right choice when the exercise tests interaction and no backend is required. It is not evidence of production persistence. A server route may be useful for protecting credentials, but it does not automatically authorize every request. Make these boundaries explicit.

A historical employer task can help identify useful skills without becoming a template to copy. Monzo's public web exercise includes authentication, editing, and pagination requirements. Its current use and old dummy API availability are unverified. Practice the underlying state and request reasoning with a local fixture rather than depending on an old service.

A fictional candidate presents the support dashboard from lesson one in four minutes. The first minute shows the five-row fixture and the 11-hour result with the missing-age note. The second follows validation and aggregation. The third demonstrates loading failure and retry. The fourth explains that duplicate IDs require a documented policy and that the current sample uses one account.

The interviewer adds multi-account access. The candidate identifies the needed changes: account identity in requests and query keys, server authorization for each dataset, a clear account switch, and a test that an old response cannot replace the new account's view. The candidate does not claim that adding an account dropdown alone completes the requirement.

A walkthrough has a small set of claims, each with a visible artifact. The interviewer should not need to accept your confidence as proof. Connect the user outcome, fixture, result, implementation decision, and known limit.

1Claim: open-ticket maximum excludes closed rows.2Evidence: fixture row2 is closed/20h; product result remains11h.3Claim: unknown ages remain visible.4Evidence: result includes unknownCount=1.5Claim: old search cannot replace current context.6Evidence: controlled R2-success/R1-late schedule.7Limit: local fixture does not test real account authorization.8Next check: authorized integration fixture for two accounts.

This record turns a demo into a reviewable argument. The evidence can be a test result, an inspected transformation, or a controlled interactive trace. State which it is. A screenshot alone can show a value but does not prove how the value was derived or whether an error path works.

Use a compact decision table:

A rejected alternative should be plausible. Explain why it does not fit this constraint, not why it is bad everywhere. A local adapter may be correct for a local exercise but insufficient for a production integration. A fixed delay may improve perceived stability in one network condition but cannot establish identity safety.

Suppose the reviewer changes the dashboard from one queue snapshot to historical trend reporting. The old deduplication assumption can now be wrong: repeated ticket IDs may represent legitimate observations over time. Identify the new entity, such as ticket snapshot at observation time, and define how state transitions are counted. Do not simply reuse ticket-ID deduplication and erase history.

The changed requirement needs additional input semantics: timestamp timezone, observation order, whether missing intervals mean zero or unknown, and how reopened tickets affect the metric. Ask for the smallest missing rule needed to proceed. Then show a small revised fixture and expected output. This demonstrates adaptation through reasoning rather than uncontrolled feature accumulation.

A different requirement, multi-account access, changes authority and cache context. It does not necessarily change aggregation math. Separating those boundaries helps you explain what can be reused and what must be reverified. The dropdown is only one visible part of the change.

Tool assistance does not remove responsibility for the code path you present. Follow the employer's explicit rules for the stage. If a helper was generated, inspect its inputs, outputs, mutation behavior, error cases, and dependencies before claiming correctness. You can say which behavior you verified and which part needs further inspection.

If challenged on an unfamiliar function, do not invent an explanation. Read the relevant section, construct a small example, and trace it. A precise unresolved question is more useful than a broad claim that the tool always handles edge cases. The same standard applies to a library API or a copied example: source origin does not establish fitness for this case.

One misconception is that a large future-work list demonstrates priority. A useful next step addresses the largest unverified risk or user limitation under the stated requirement. Another is that a demo success proves setup reproducibility. Your machine may contain cached packages, environment values, or hidden fixtures that the reviewer lacks.

Exercise: the app works locally, but setup instructions omit the fixture path and required runtime. You have ten minutes before handoff. Write a completion note with runtime assumption, setup/run instructions, exact fixture location, expected result, and known integration limit. If you cannot verify a clean setup, state that limitation. Award one point for each of those five items and one for avoiding a claim of clean-install verification without evidence.

A strong final presentation can be short because the artifacts carry detail. Show one correct result, one controlled failure, one tradeoff, and one changed requirement. Leave a run manifest that another person can follow. The aim is not to defend every shortcut; it is to make each shortcut understandable enough for the reviewer to judge it.

Write a one-minute answer to what would you improve next. Inputs: aggregation is correct, errors are handled, but the sample renders 20,000 rows and becomes unresponsive. A strong answer prioritizes bounded display and payload, measures interaction delay, and preserves access to the full result through pagination or export if needed. Award one point for the measured problem, one for the proposed change, and one for explaining the trade-off in navigation.

What are you least certain about in this submission? A strong answer names a real unverified boundary and a concrete test or source that would resolve it. Follow up with a request to explain one generated function. A weak answer says everything is production ready because the demo worked once. A useful walkthrough makes the result, reasoning, and uncertainty equally easy to inspect.