An interviewer says - "You have just joined a company with 900000 units of a 2016 hardware generation in people's homes. 64 KB of RAM. No over-the-air update mechanism of any kind; the firmware is what it is, forever. They speak a fixed binary protocol to a server you do own. Product wants a new feature on them. Walk me through the conversation." How do you scope and answer that?

What the interviewer is testing

Whether you can tell the difference between a design problem and a pricing problem. No clever architecture puts your code on a device with no mechanism to accept code. The senior move is to establish the real design space in a few questions, then come back with options and numbers rather than a diagram.

They are also watching whether you say "we cannot do that" too early. Most features requested on frozen fleets turn out to be implementable, because the constraint is on the device's code, not the server's interpretation of what the device already says.

The clarifying questions that change the answer

• Is there any code path that is not fixed? A configuration blob the device stores and acts on, a downloadable lookup table, a server-supplied threshold. That is the entire design space. Ask first, because every other answer depends on it.
• What exactly is in the wire protocol? A reserved byte is a new flag; a length-prefixed opaque field is a new sub-protocol. And does the device ignore a message it does not understand, or fault? Faulting on an unknown command code closes the door.
• How many units are actually reachable? 900000 is a manufacturing number; the design population is units that completed an exchange in the last 30 days, often 10-20% lower.
• What does a site visit cost, and what does the service contract oblige? The answer to "should we solve this in software" is a currency figure.

A strong answer's arc

Three priced options, not one design.

1. Server-side only, inside the existing protocol. The server reinterprets what the device already sends and accepts. If the unit reports a reading every minute, a new alerting feature, tariff model and customer report are all server work and the device never changes. Most requested features on a frozen fleet are this, and establishing it is the highest-value thing you do in week one.
2. Extend through whatever the device tolerates - reserved fields, unused command codes, a configuration download. Cheap now and expensive forever, because the 2016 units depend on a server behaviour that can never change. Write the field semantics down as a contract, because in five years nobody will remember why that byte must stay 0x03.
3. Replace the hardware, funded as a programme. Sometimes right. Say the number out loud: 900000 units, a per-unit hardware and install cost, against the revenue the feature unlocks. An architect who will not produce that number leaves the decision to someone with worse information.

Common weak answers

• "Ship an update that adds an update mechanism." There is no path to execute your code. Say plainly that it does not exist and move to what does.
• "Force users to upgrade." These are meters in other people's homes: no store, no attention, no contractual right.
• Designing the feature before establishing what the wire format permits. The protocol is the specification now, and reading it is step one.
• Treating the reachable population as the shipped one, which makes every rollout estimate wrong in the same direction.

What a strong answer adds

The testing problem. Every server change is a change against a client population you cannot instrument, patch or interrogate. The answer is a replay corpus of captured real device traffic as the regression suite, plus a staged server rollout by device cohort so a bad interpretation reaches 1% of the fleet. Without it the server is a single point of failure for 900000 unfixable devices.

And the organisational lesson. An update mechanism is not a feature competing for roadmap space; it is what makes every later feature possible, and its absence caps the product's revenue at whatever the 2016 wire format permits. That argument, with the three option prices attached, is what gets a bootloader into the next hardware revision.