A teammate calls your fixed-capacity array of 16-bit sensor samples primitive and says hardware bounds-checks it for free — how do you defend the design and correct the claim?

## What the fixed-capacity design actually buys On a memory-constrained device — firmware polling a sensor, an embedded controller, a real-time capture path — a flat, fixed-capacity array of samples is not a primitive habit; it is a set of guarantees: **A provable memory budget.** Footprint is `capacity × element_size`, known at design time. One million 16-bit samples occupy 2,000,000 bytes, and that number appears in the memory map before the device ever runs. A growable container's footprint depends on runtime history: growth typically over-reserves (doubling leaves up to half the block unused), and the transient during a grow — old block plus new block alive at once — can briefly need triple the steady-state memory. On a 4 MB device that transient is not a detail; it is an outage. **No allocation in the hot path.** The buffer is allocated once. The sampling loop performs address math and stores — no allocator calls, hence no allocator latency spikes, no fragmentation over months of uptime, and no allocation-failure branch in code that must not fail. Growable containers put the most dangerous operation (allocate-and-copy) at the least predictable moment (whenever the workload happens to cross a threshold). **The element-size lever.** Because footprint multiplies element size across the whole capacity, choosing a 16-bit cell over a 64-bit default divides memory by four. Address math costs the same either way — `base + i * 2` is no slower than `base + i * 8` — so the width choice is purely a space decision, and on small devices it is a first-order one. ## Correcting the 'hardware checks it for free' claim The claim confuses two different protection mechanisms. Hardware memory protection — the memory-management unit — operates on *pages*, units of kilobytes. It can fault an access to an unmapped page, which catches wild pointers. It cannot know that within one mapped page, bytes 0–1999 are the sample buffer and byte 2000 begins something else. A write one element past the buffer therefore succeeds silently and corrupts whatever neighbours it. Element-granular bounds checking exists only as *software*: a comparison of the index against the stored capacity, inserted by a checked runtime, a compiler, or the programmer. So the fixed buffer imposes a duty the growable container does not remove: bounds discipline is explicit. Concretely: - **Check at the write boundary.** The fill path compares the write position against capacity before storing. One compare per sample, branch almost never taken — effectively free next to the sensor read itself. - **Define the full-buffer policy.** Fixed capacity forces the question a growable container silently answers with "allocate more": what happens when the buffer is full? Reject new samples, block the producer, or flush downstream — any of these can be right, but it is chosen at design time and visible in the code. On a device where "allocate more" is the one unavailable move, being forced to answer explicitly is a feature, not a limitation. - **Use checked builds where available.** Ecosystems differ in their defaults — some languages check every index at runtime (Rust, and managed runtimes such as the JVM and .NET, all do), while C and C++ toolchains offer element-granular checking only through opt-in sanitizers — so the practical policy is: run the checking configuration in tests and CI, and decide deliberately, not by omission, what the production build does. ## When to concede Steel-manning the teammate: a growable container is the right call when the workload size is genuinely unknown or bursty, memory is plentiful, occasional allocation latency is tolerable, and the runtime checks indices by default. Amortized growth is a beautiful deal *when you can pay for it*. The senior position is not "flat buffers always"; it is that on this device, with this budget and this hot path, the fixed buffer's guarantees are load-bearing — and that neither choice exempts anyone from bounds discipline, because the hardware never provided element-level checking to begin with. ## The shape of the answer in an interview Structure it as: (1) name the guarantees fixed capacity buys — provable budget, allocation-free hot path, element-size control; (2) refute the hardware claim with the page-granularity argument; (3) show the discipline that replaces the myth — boundary checks, explicit full policy, checked builds in testing; (4) state honestly when the growable container wins. That sequence demonstrates judgment rather than dogma, which is what the question is probing.