How do you handle extended or follow-up requirements in an LLD interview?

When the interviewer adds a requirement mid-stream — say, now support electric-vehicle charging spots — I see it as a test of whether my design was open for extension, not as an attack. So my first move is to restate the requirement to make sure I understood it. Then I check whether my existing abstractions can absorb it. Ideally I can add a new subclass like ElectricChargingSpot, or a capability interface like Chargeable, and leave all the existing classes untouched. That's the Open/Closed Principle in action, and I'd narrate it: I'm adding a new class rather than editing working code, so nothing that already works can break.

The more interesting case is when my original design can't absorb the change cleanly. The wrong response is to hack it into existing classes or pretend the design already handles it — interviewers see straight through that. The right response is to be honest: I'd say something like, my current design assumed all spots are passive, so to support charging I'd introduce a Chargeable interface here and refactor these two classes. Naming the limitation and describing the refactor demonstrates more maturity than forcing an ugly workaround.

And whatever I do, I narrate it and I call out any trade-off the new requirement introduces — extra state to manage, new concurrency concerns, more complexity. Showing that I can evolve a design gracefully, and that I know when evolution requires a small refactor, is exactly what the follow-up is probing for.