Why this matters: the spinlock is the shortest problem in the systems set — a correct one fits in a dozen lines — and that's precisely why it's asked. With no volume of code to hide behind, the round becomes pure reasoning: every line must be justified, and the questions you ask up front decide whether you have justifications or just recollections.

The prompt, as given

Implement a mutual-exclusion lock from scratch, using only atomic operations — no OS mutex, no futex, nothing that parks a thread.

The code will be short. That is the point: with so few lines, every one of them has to be right, and you should expect to defend not just that your lock works but why it performs the way it does — and when anyone should actually use a lock like this instead of the one the OS provides.

Read the second paragraph as the grading rubric it is: works, performs, and when to use it are three separate things you'll be asked to defend. The requirements conversation sets up all three.

The questions, and why each one matters

"What atomic primitives do I have?" Atomic exchange, compare-and-swap, fetch-add, and loads/stores with acquire/release semantics is the standard kit. Asking first signals you'll build from stated primitives rather than half-remembered intrinsics — and the answer licenses the vocabulary you'll use for the rest of the round.

"What's the hardware model?" Multi-core with genuinely parallel threads, and — the part that matters — per-core caches kept coherent by an invalidation-based protocol. This question looks academic and is anything but: the entire performance story of a spinlock lives in coherence traffic, so you're asking for the stage on which your later argument will play out.

"Can a thread be preempted while holding the lock?" Yes — the OS can deschedule a lock-holder at any moment. Surfacing this early is the mark of someone who's seen spinlocks in the wild, because it feeds directly into the "when should anyone use this" judgment the prompt demanded: a lock that burns CPU while its holder isn't even running has a pathology worth naming before you build it (lesson 04 stares at it directly).

"How long are critical sections?" The intended answer — microseconds, no I/O, no allocation — is the spinlock's habitat. If sections can be long, spinning is the wrong tool and the honest answer is to say so. Asking shows you know the tool has a habitat at all.

"What's the API?" lock() and unlock(); try_lock() optional. Small, but it puts scope on the record.

The requirement set this chapter builds against

Primitives   atomic exchange, CAS, fetch-add; loads/stores with
             acquire/release semantics; ISA-neutral, no assembly
Hardware     multi-core, parallel threads; per-core caches under an
             invalidation-based coherence protocol
Preemption   exists — a holder CAN be descheduled mid-section
Sections     short: microseconds, no I/O, no allocation
API          lock() / unlock(); try_lock() optional
Quality bar  correct mutual exclusion + right ordering semantics;
             graceful under contention; honest about when NOT to
             use it

As with every chapter in this course, the set is representative — a live interviewer's answers may differ, and the conversation that surfaces them is the skill being practiced.