Why this matters: everyone has used a thread pool, which is exactly why the round is dangerous — familiarity substitutes for thought. The requirements conversation is where you separate the pool you've called from the pool you can build: every question below surfaces a decision that using submit() never made you face.

The prompt, as given

Implement a thread pool.

Services in your codebase keep spawning ad-hoc threads and it is hurting: unbounded thread counts, no reuse, no way to reason about parallelism. You are building the shared thread pool they will all use — callers submit work from many threads, and a fixed set of workers executes it.

The motivation sentence is doing real work: shared, many submitting threads, fixed workers. This is infrastructure other teams will lean on, which raises the bar on every edge — a task that throws, a queue that fills, a result someone forgot to collect.

The questions, and why each one matters

"How many workers, and who decides?" Fixed at construction is the sane answer — but the follow-up is the real content: how would a caller choose N? Be ready to reason it in words: CPU-bound work wants roughly the core count (more just adds context-switching), IO-bound work wants more than the cores it wastes waiting — or its own separate pool. No formula required; the reasoning is the signal.

"Is the queue bounded?" An unbounded queue is a slow-motion out-of-memory: a burst of submissions outruns the workers and the backlog grows without limit. Asking about the bound tells the interviewer you've seen that movie. And the moment a bound exists, a policy question is born — what does submit do when the queue is full? — which deserves its own conversation (lesson 04 gives it one).

"How do results come back?" Fire-and-forget, or a handle the caller can wait on? A future-style handle changes the design meaningfully: someone must store the result, signal completion, and hold it until it's claimed.

"What happens when a task throws?" The single most load-bearing question in the set. If an exception escapes into the worker loop, it kills the worker — and a pool that quietly shrinks every time user code has a bug is a production incident generator. The exception must be captured and delivered through the result handle, never allowed to take a worker down.

"Ordering and priorities?" FIFO is the honest default; priorities are a follow-up. Ask so scope is on the record.

"What primitives do I have?" Mutexes and condition variables — this is a blocking design, not a lock-free one. Knowing which game you're playing keeps you from over-engineering.

The requirement set this chapter builds against

Workers       fixed N at construction; caller sizes it
              (CPU-bound: ~core count; IO-bound: larger or separate)
Queue         bounded, FIFO
Submission    from many threads concurrently
Results       submit returns a future-like handle; caller may
              wait on it or ignore it
Task failure  an exception is captured into the handle;
              it must NEVER kill a worker
Priorities    out of scope
Lifetime      the pool lives for the process; shutdown design is
              out of scope for this chapter
Primitives    mutexes and condition variables; lock-free not required

The lifetime line deserves a note: real pools need a shutdown story, and designing one is its own substantial topic. This chapter scopes it out and builds the steady-state machine — submit, queue, execute, deliver — which is where the core synchronization lessons live. And as with every chapter in this course: this requirement set is representative. A live interviewer's answers may differ; the conversation is the skill.