Skip to content
Hari KharelStudy

Adapting to changing requirements

intermediateCommon atAnthropicStripeAirbnbCoinbaseRead firstClass design and invariantsTesting and verificationPractise in the Sandbox →

Multi-level rounds grade how well your level 1 survives levels 2 to 4. Build level 1 simply, but make three cheap bets: store records, not bare values; accept the inputs that will obviously arrive (time, ids); and change each piece of state in exactly one place. When a new level doesn’t fit, refactor first, then add the feature, with the old tests as your safety net.

The idea in plain words

Section titled “The idea in plain words”

Many practical rounds aren’t one puzzle. They are one small system that grows: a store, a ledger, a scheduler. You get level 1, make it pass, then level 2 arrives and changes the rules. CodeSignal’s widely used Industry Coding Framework makes this explicit: one project, four levels, 90 minutes. Its published rubric says level 1 checks basic implementation and corner cases, level 2 reusing level 1 code, level 3 keeping backward compatibility while extending, and level 4 adjusting earlier functionality without regressions, with code design judged after the fact. Live interviews at Stripe, Anthropic and others follow the same shape with an interviewer instead of a test runner.

So the real test is not “can you write level 1”. It’s “how much of level 1 do you have to rewrite at level 3?”

Think of building a house you know will get a second floor. You don’t build the second floor now. But you pour a foundation that can take the weight, and you leave the stairwell where it will go. That costs a little extra on day one and saves tearing the house down later.

The counterweight is YAGNI (“you aren’t gonna need it”): don’t build features nobody asked for. The skill is telling a cheap, likely bet (a field, a parameter, one helper) from speculative machinery (plugin systems, abstract base classes, generic event buses).

See it

Section titled “See it”

The same invented problem, a library that lends books, built two ways. The left design is the minimum that passes level 1. The right one makes three small bets. Step through the levels and watch which parts each new requirement touches.

One problem, four levels, two designs
step the levels
level
Level 1: copies, checkout, return. add_copies(isbn, n), checkout(member, isbn) and return_book(member, isbn). Checkout fails if no copy is free or the member already has one.
Minimal for level 1
free: dict[isbn, int] and out: set[(member, isbn)]. No time, no records. Exactly what level 1 asked for.
statenew
add_copiesnew
checkoutnew
returnnew
queriesuntouched
old testsnew
+ free = Counter()
+ out = set()   # (member, isbn)
+ checkout / return_book flip one set entry
this level~28 lines
so far~28 lines
Room to grow
Same features at level 1, but loans are records, every method already accepts a day, and each mutation happens in one place.
statenew
add_copiesnew
checkoutnew
returnnew
queriesuntouched
old testsnew
+ @dataclass Loan(member, isbn, out_day)
+ loans = {}   # (member, isbn) -> Loan
+ methods take day (ignored for now)
this level~34 lines
so far~34 lines
Total code touched so far (rough)
Minimal for level 1
28
Room to grow
34
newsmall editrewrittenuntouched
Level 1: the "room to grow" version is slightly bigger. That is the price of the bet, and it is small.

The minimal design wins at level 1, ties at level 2, and loses badly at level 3, the level where time arrives. That’s typical: level 3 is where the shortcuts of level 1 get billed.

When to reach for it

Section titled “When to reach for it”
The problem says… The likely next level… The cheap bet now
“implement a store / system with operations…” queries over the same data (rankings, filters, totals) Keep data in records keyed by id, so queries can scan or index them.
operations take a timestamp, even if unused expiry, history, “as of time t”, scheduling Thread the timestamp through every method from the start.
“return true/false if it succeeded” return why, or a value (fee, balance, remaining quota) Funnel results through one place, so widening the return type is one edit.
“a user can…” per-user limits, merges, permissions Key state by user id; don’t fold users into totals too early.
“add X to Y” undo, transfers, partial failures One method per state change, so it can be logged or reversed.
a numeric total money, rounding, currencies Integers in minor units from day one.

How it works

Section titled “How it works”
  1. Read level 1 for its nouns and verbs. Nouns become records or classes (Loan, Account); verbs become methods. Ask the interviewer: “Will there be more levels? Is there a notion of time?” They will often hint.
  2. Make three cheap bets. Records instead of bare ints. The obvious extra inputs (timestamp, ids) already in the signatures. Each piece of state mutated in exactly one place.
  3. Write level 1 tests as a table and keep them. They are the regression suite for every later level.
  4. When a new level arrives, classify the change. Is it an addition (new method, new field, new index), an extension (an existing method does a bit more), or a change of model (the core data shape is wrong)?
  5. Additions and extensions: add, then run all tests. Put the new logic where the related mutation already happens.
  6. Change of model: refactor first, keeping the old tests green, then add the feature. Kent Beck’s line: “make the change easy (this may be hard), then make the easy change.”
  7. Say it out loud. “Level 3 needs due dates per loan. My loans are records, so this is one field and two lines.” Interviewers grade the reasoning as much as the diff.

The worked example in code

Section titled “The worked example in code”

Here is the “room to grow” library after three levels. The comments mark which level added each line. Notice how little level 2 and level 3 needed: one index and one counter line for level 2, one field and two lines for level 3. The records and timestamps were already there.

library_loans.py
from collections import Counter
from dataclasses import dataclass


LOAN_DAYS = 14          # L3
FEE_PER_DAY_CENTS = 25  # L3: money as integer cents, never floats




@dataclass
class Loan:              # L1: a record, not a bare int, so later levels add fields, not structures
    member: str
    isbn: str
    out_day: int         # L1 already accepts a time, even though level 1 ignores it
    due_day: int         # L3




class Library:
    def __init__(self) -> None:
        self.free: Counter[str] = Counter()          # L1: isbn -> copies on the shelf
        self.loans: dict[tuple[str, str], Loan] = {}  # L1: (member, isbn) -> open loan
        self.times_borrowed: Counter[str] = Counter() # L2: one extra index, updated in one place


    def add_copies(self, day: int, isbn: str, n: int) -> None:
        if n <= 0:
            raise ValueError("n must be positive")
        self.free[isbn] += n


    def checkout(self, day: int, member: str, isbn: str) -> bool:
        if self.free[isbn] == 0 or (member, isbn) in self.loans:
            return False
        self.free[isbn] -= 1
        self.loans[(member, isbn)] = Loan(member, isbn, day, day + LOAN_DAYS)
        self.times_borrowed[isbn] += 1               # L2: the only line level 2 added here
        return True


    def return_book(self, day: int, member: str, isbn: str) -> int | None:
        loan = self.loans.pop((member, isbn), None)
        if loan is None:
            return None                              # L1 returned False; L3 widened it to "fee or None"
        self.free[isbn] += 1
        return max(0, day - loan.due_day) * FEE_PER_DAY_CENTS  # L3


    def top_borrowed(self, k: int) -> list[str]:     # L2: ties broken by isbn, stated up front
        ranked = sorted(self.times_borrowed.items(), key=lambda kv: (-kv[1], kv[0]))
        return [f"{isbn}({n})" for isbn, n in ranked[:k]]




if __name__ == "__main__":
    lib = Library()
    lib.add_copies(0, "dune", 1); lib.add_copies(0, "emma", 2)
    assert lib.checkout(1, "ana", "dune") and not lib.checkout(1, "bo", "dune")  # L1: no copies left
    assert lib.checkout(2, "bo", "emma") and lib.checkout(2, "cy", "emma")
    assert lib.top_borrowed(5) == ["emma(2)", "dune(1)"]                         # L2
    assert lib.return_book(15, "ana", "dune") == 0                               # L3: on the due day
    assert lib.return_book(20, "bo", "emma") == 4 * 25                           # L3: 4 days late
    assert lib.return_book(20, "bo", "emma") is None                             # L1: double return
    print("ok")

Refactor or patch?

Section titled “Refactor or patch?”

When level N doesn’t fit, you have two moves:

Patch Refactor, then add
What it is Bolt the feature on beside the old model (a second dict, a special case) Change the model so the feature is natural, keeping old tests green
Good when The change is local and the next level is unlikely to touch it again The same data now has two homes, or you’d special-case in several places
Risk Two sources of truth drift apart; every later level pays again Time spent; a broken refactor with no tests
Tell-tale sign you need to refactor You write the same lookup in three methods, or you keep two structures in sync by hand

A useful rule: patch once, refactor on the second patch to the same area. And never refactor without tests running.

What it costs

Section titled “What it costs”
Strategy Level 1 Levels 2-4 Risk
Minimal, patch as you go fastest slower each level; often a rewrite at 3 or 4 regressions, two sources of truth
Cheap bets (records, timestamps, one mutation point) +5-10% mostly additions slight over-design if the next levels go elsewhere
Speculative framework (interfaces, plugins, events) much slower may help, may not runs out of time before level 2

In a 90-minute, four-level format, the middle row is the sweet spot: the bets are a few lines each, and level 3 is where most candidates run out of time.

Variations you’ll meet

Section titled “Variations you’ll meet”
  • Hidden levels. On test-runner platforms, you may only see level N+1 after passing level N, so you design blind. The cheap bets are your hedge.
  • Live follow-ups. With an interviewer, the next level is a conversation: “Now make it work when two calls race” or “What if this has to be distributed?” Answer the design first, then code the smallest change.
  • Backward compatibility. Level 3 may change a return type (“return the fee instead of true”). Keep old callers working: widen carefully, or add a new method beside the old one.
  • Changing an earlier rule. Level 4 sometimes overrides a level 1 rule (“a returned copy now goes to the hold queue”). Find the one place that rule lives. If it lives in three places, refactor first.

Pitfalls

Section titled “Pitfalls”
  • Over-engineering level 1. An abstract repository and a strategy pattern before the first test passes. Make bets, not frameworks.
  • Bare primitives as state. dict[str, int] of counts can’t grow into “count plus due date plus history” without a rewrite.
  • Dropping the timestamp. If the signature has timestamp and level 1 ignores it, keep it anyway and store it. Time almost always matters later.
  • Duplicated mutation. Updating a balance in deposit, transfer and pay separately means three places to change when fees arrive.
  • Deleting old tests to make new ones pass. A level that breaks level 1 tests usually means a regression, not an obsolete test. Check the prompt.
  • Silent behaviour changes. If level 3 changes what an old method returns, say so and update its tests deliberately.

In the interview

Section titled “In the interview”
  • At the start: “Is this going to be extended? Is there a notion of time or users I should plan for?” It’s a fair question, and the answer shapes your data model.
  • Name your bets briefly: “I’ll store loans as records keyed by member and book. It costs nothing now and makes history easy later.”
  • When the next level lands, classify it out loud: addition, extension, or change of model.
  • If you refactor, say why and keep it small: “Both rankings and fees need per-loan data, so I’ll move from a set to a dict of records first, rerun the tests, then add fees.”
  • Expect the closing question “What would you change if you had more time?” Have one honest answer about the design.

Check yourself

Section titled “Check yourself”
Check yourself
pick one
Level 1 asks you to track how many copies of each book are on loan. Every method signature already includes a timestamp, which level 1 doesn't use. What is the best move?
Check yourself
pick one
Level 3 needs per-loan due dates. Your level 1 stored loans as a set of (member, isbn) pairs. You have 20 minutes left. What should you do?

Practice on your own

Section titled “Practice on your own”

Build each in four levels. Write level 1 without looking ahead, then score how much level 3 forced you to rewrite:

  • Parking garage: park/leave → occupancy by floor → hourly pricing with timestamps → reservations that expire.
  • Gym front desk: check members in and out → busiest hour of the day → memberships that expire → guest passes with a visit history.
  • Plant watering log: register plants, record waterings → overdue plants → per-species schedules → watering history with undo.
  • Bike rental dock: rent and return bikes → most-ridden bikes → pricing by ride duration → a waiting list when the dock is empty.

Go deeper

Section titled “Go deeper”
Section titled “Related”
Designing for the next requirementSeams, extension points and their limits.
Class design and invariantsState that stays consistent as methods are added.
API design and evolutionChanging signatures without breaking callers.
Testing and verificationYour level 1 tests are the safety net for level 4.