interview

MasterMind: Interview

A precise spec is cheaper than a wrong build. Time spent making the spec exact pays off more than time watching the implementation (~/.mastermind/engineering/core/product-sense.md, ~/.mastermind/engineering/core/agent-loop.md). This produces the what, not the code.

First, say what you think they're asking for

Lead with your reading of the ask and how sure you are: a wrong guess gets corrected faster than a blank question gets answered. One or two lines, then proceed or ask:

Reading it as: a way to see which jobs failed overnight, so the morning starts with a fix not a search.
~70% sure: what I'm missing is whether "failed" includes timeouts.

If you do have to ask: one question at a time, and answer it yourself first. A batch of questions hands your job back and makes the user do technical work; asking blind makes them generate an answer from nothing. Ask the single question that unblocks the next decision, with your recommendation attached, people correct a wrong guess far faster than they compose an answer:

Q: Should a failed import roll back the whole batch, or keep the rows that parsed?
   I'd keep the good rows and report the failures: a 5,000-row file failing on row 4,900
   is the case people actually hit. Say the word if you'd rather it be all-or-nothing.

Look facts up rather than asking for them: the stack, the conventions, what the code already does are yours to find. Only the decisions are theirs.

Two things to catch, because both hide a wrong build behind an apparent agreement:

• The out-of-scope half. Most misalignment is silent disagreement about what is not being built, which is why step 2 below names it explicitly rather than leaving it implied.
• A hollow yes. "Whatever you think," "sounds good," and silence are not confirmations; they're delegation, politeness, and fatigue. Restate the ask concretely and get a real one, or decide it yourself and say plainly that you did.