Asked about The coding round where the spec keeps changing
How do you write the first version of a problem you know will get harder, without over-engineering it?
An answer that works
Spend only on extensibility that costs a line rather than a structure: inject the clock or the store, key the state even when there is one key, and keep the decision in one method. Refuse anything that needs explaining, such as a strategy interface with one implementation. Then say the assumptions out loud so the interviewer can correct the ones the later levels will break.
Then they push further
The next requirement contradicts your design. Do you refactor or special-case it?
Refactor when the alternative is a second branch duplicating an existing one, or a flag threaded through several methods, because the level after this will then have to be written twice. Special-case it when the change is additive, or when there is not enough time left, and say out loud that time is the reason.
How do you avoid breaking the earlier levels as you add to them?
Write a small test per level as you finish it, using an injected clock so it does not sleep. Re-running them after each change takes seconds and is the only thing that tells you the third requirement did not break the first.
What gets marked up
Strong answers give a concrete budget for what extensibility is worth buying early, name the hidden dependency they would inject, and treat refactoring as an announced decision rather than something done silently.
Reading an answer is not being able to give one. The section that teaches this is The coding round where the spec keeps changing, 4 hours of Interviewing well.
Learn this properlyAlso asked about Interviewing well