173: Machine Coding - Requirements and Timeboxing

Learning outcomes

• turn an ambiguous prompt into a small contract;
• separate must-have behavior from polish;
• choose state ownership and interfaces before coding.

Practice

Write requirements, exclusions, data shapes, loading/error states, accessibility expectations, and a 90-minute plan for a typed autocomplete. Define “done” before implementation.

Lesson: turn ambiguity into a contract

Ask whether queries are local or remote, the minimum query length, debounce interval, result limit, selection behavior, and whether results may be cached. A useful contract is: empty query clears results; a query of two or more characters requests results; only the latest request may render; ArrowDown/ArrowUp changes the active option; Enter selects it; Escape closes the list; loading, empty, and retryable error states are visible and announced.

Model query, status, options, activeIndex, and requestId explicitly. Keep fetched options server-owned and transient focus/input state local. Build the request/render path first, then keyboard behavior, then accessibility polish. Reserve the last 15 minutes for tests and the last 5 for explanation; do not spend the core budget on styling.

Worked plan and rubric

Minutes 0-10 clarify and write acceptance tests; 10-20 sketch state and DOM roles; 20-55 implement happy path and stale-response protection; 55-75 keyboard and failure states; 75-90 tests, cleanup, and demo. Score 2 points each for clarified contract, sensible state ownership, correct async behavior, accessibility, tests, and prioritization. A polished component with ambiguous stale-data behavior is not complete.

References

• WAI-ARIA APG: Combobox pattern
• Frontend Interview Handbook

Checkpoint

Explain the first feature you would cut under time pressure and why cutting scope is safer than weakening correctness or accessibility.

Planning worksheet

Write the user action, state transition, external dependency, observable result, and failure recovery for each requirement. Define an interface before choosing a library. Reserve the final 15 minutes for tests and the final 5 minutes for an explanation; an unfinished polish pass is acceptable, an untested core contract is not.

Interview questions

How do you handle a requirement that is ambiguous? What do you implement first if the API is unavailable? Which assumption would you verify with the interviewer?