Courses › AI-Assisted Coding › Round Types

Building from a Spec

Finding the spec's gaps, owning the design and building in verified slices.

"Build this small app from a spec" gives you a one- or two-page spec and 60–90 minutes. With an assistant, generating a first version takes seconds, which is exactly the trap. The candidates who score well treat it like a real project in miniature: clarify the spec, own the design, build in verified slices, and finish with something coherent and tested.

Step 1: Interrogate the spec (5–10 minutes)

Specs in these rounds contain deliberate gaps. Finding them is part of the test. Read the spec and list:

  • Ambiguities: "sorted by date" — ascending or descending? Created date or due date?
  • Edge cases the spec doesn't mention: empty input, duplicates, invalid formats, very large inputs
  • Conflicts between two requirements
  • Unstated non-functional needs: persistence, error messages, performance

Ask the interviewer about the important ones. For the rest, state your assumption and write it down in the README or at the top of the main file.

[!TIP] Let the assistant help you find gaps "Here's the spec. List the ambiguities, edge cases and unstated assumptions a careful engineer would ask about." Then pick the questions that matter yourself. It's a quick way to make sure you didn't miss anything, and it shows good tool use.

Step 2: Design it yourself (5–10 minutes)

Decide and write down:

  • The data model: the core entities and fields. This is the decision that's most expensive to change later.
  • The module boundaries: for example, parsing and I/O, core logic, storage, interface.
  • The public interface: CLI commands, API endpoints or function signatures.
  • The test plan: which behaviors matter most.

Keep it small. You're optimizing for a working, extensible core, not for completeness.

Step 3: Build vertical slices

Build one feature end to end, with tests, before starting the next one:

  • Core model and the most important feature, with tests → demo it
  • The next feature → tests → run everything
  • Validation and error handling
  • Nice-to-haves, only if there's time

For each slice, give the assistant a prompt that includes the design decisions you already made: "Using the Task dataclass in models.py and the storage interface in store.py, implement list_tasks(filter, sort). Sorting is stable, with ties broken by ID. Include tests for an empty list, ties, and an invalid sort key."

[!WARNING] Don't generate the whole app in one prompt One giant prompt produces one giant diff that nobody can review, with design decisions made by the model rather than by you. It's the most common way to fail this format. If you hit an error 40 minutes in, you're debugging code you've never read.

Step 4: Keep it coherent

Generated code drifts. Every few slices, take a minute to:

  • Remove duplicated helpers and dead code
  • Make names, error handling and formatting consistent
  • Check that each module still has one clear job

Step 5: Finish strong (last 10–15 minutes)

  • Stop adding features.
  • Run all the tests, plus a quick manual run of the main flows.
  • Update the README: how to run it, the assumptions you made, what you'd do next.
  • Walk the interviewer through the design, the trade-offs and the known limitations.

A smaller app that's clean, tested and well explained beats a bigger one that's half broken. Interviewers grade the judgment behind the scope you chose.

[!INTERVIEW] Name the cut "I've finished the core features and validation. I deliberately skipped the export feature to leave time for tests. It would be a new formatter behind the existing interface." Saying what you left out, and how it would fit in, often scores better than the feature itself would have.

[!TIP] Practice Build a Small App from a Spec with AI · Prompting Under Pressure