Courses › AI-Assisted Coding › Round Types

Multi-Level Problems with AI

Designing for later levels, spec checklists and keeping the assistant from rewriting earlier work.

Several companies run their practical, multi-level coding rounds with AI assistance allowed: build an in-memory store, a bank or a file system in four levels, with automated tests at each level. The assistant makes the early levels fast. Whether you finish the later levels depends on how you used it early on.

Why AI changes the strategy

Without AI, the bottleneck is typing and recalling syntax. With AI:

  • Levels 1–2 take minutes, if the design is right.
  • Levels 3–4 (TTL, history, backups, transfers, rollbacks) are where candidates get separated. They need a design that can absorb new requirements, plus careful verification of edge cases.
  • Hidden tests punish small spec deviations, which assistants often introduce: a different sort order, None instead of "", an off-by-one in a time comparison.

A level-by-level loop

[Read the level spec] -> [List the exact edge cases] -> [Update the design] -> [Delegate the change] -> [Review the diff vs the spec] -> [Run the tests] -> [Next level]

Before level 1: design for change

Spend two or three minutes on the data model, thinking about the likely later levels. Tell the assistant about the model up front:

We're building an in-memory key-value store in `store.py`, class `Store`.
Data model: dict key -> dict field -> Record(value: str, expires_at: int | None).
Timestamps are passed into every method (never use the system clock).
All reads go through one helper `_live(key, field, ts)` that applies expiry.
Implement level 1 only: set/get/delete as specified below. Keep methods small.
<level 1 spec pasted verbatim>

The paste the spec verbatim and one-helper-per-rule instructions prevent most of the drift that would break later levels.

Each level: spec → checklist → change → verify

  • Turn the level's spec into a checklist of exact behaviors, including return values for missing keys and the sort order.
  • Delegate the change, pasting the new level's spec and saying which existing helpers to reuse.
  • Review the diff against the checklist, not just for whether it works. Look closely at comparisons (< vs <=), sort keys, and return values for empty results.
  • Run the provided tests, then add two of your own for the trickiest new rule.

[!WARNING] Don't let it rewrite earlier levels When asked to add level 3, an assistant may restructure level 1 code "for consistency" and quietly break passing behavior. Tell it explicitly: "Only add what level 3 needs. Don't modify existing methods except to call new helpers." Then check that the diff respects that.

Speed tactics

  • Keep one file (or a small module) and one test file, so the assistant always has the full context.
  • Commit, or keep a copy, after each passing level. If a change goes badly, roll back rather than debugging it.
  • When the tests fail, read the failing assertion yourself first. Spec mismatches are usually obvious to a person, and an assistant may "fix" the wrong thing.
  • Write small, deterministic parts yourself when that's faster than describing them, such as a sort key or a timestamp comparison.

What to say while you work

Interviewers can't see your judgment unless you say it. At each level:

  • "Here's the new rule, and here's where it plugs into the design."
  • "I'm checking the diff for the sort order and the expiry boundary. Those are what the hidden tests will probe."
  • "Level 3 passes. I'll commit before starting level 4."

[!TIP] Practice Build a Multi-Level In-Memory Store with AI · In-Memory Database · Practical Multi-Part Rounds