You do not need to understand the answers technically. You need to notice whether they are specific, and whether the person giving them has clearly thought about it before you asked. That is genuinely most of the signal.
One framing note before the list. Ask these as someone trying to plan, not as someone conducting an inspection — "I am working on the hiring plan and I want to understand what we are dealing with" gets you the truth. Anything that sounds like an audit gets you reassurance, which is worth nothing.
1. How long before a new engineer ships something a customer sees?
Good answer: "Three or four days. The setup is documented and their first task is usually a small real fix."
Worrying answer: "Depends on the person." It does not, much. This number is a property of the product, not of the hire, and if nobody has measured it you are about to pay for it several times over.
What it costs: every week here is a week of salary with no output, multiplied by every hire in your plan.
2. Who can put a release live on a Friday afternoon?
Good answer: two or more names, and a documented process anyone could follow.
Worrying answer: one name — or "we do not release on Fridays", which usually means the process is frightening rather than that the policy is deliberate.
What it costs: one person controls your ability to ship and to fix things. Holidays, illness and resignations all become company events.
3. What happens automatically when someone changes the payment flow?
Good answer: "Automatic checks run on sign-up and payment; if they fail the change does not go out."
Worrying answer: "We test it manually." Which means sometimes.
What it costs: the failures customers actually notice, and the ones that quietly take money without delivering anything. You do not need broad coverage — you need it exactly where money moves.
4. What would break first if traffic went up ten times tomorrow?
Good answer: something short and specific, ideally with a number attached. "The search would fall over around 5,000 concurrent users; we know how to fix it, it is about a week."
Worrying answer: "It should be fine." Nobody knows this without having looked, and the confident version of this answer is more concerning than an honest "we have not checked".
What it costs: your product goes down on the day you finally get attention. This is the failure that turns a good week into a bad quarter.
5. Which part of the product are you most nervous about touching?
This is the best question on the list, because every engineer knows the answer immediately and almost nobody is ever asked.
Good answer: a specific area, a clear reason, and an idea of what it would take to fix.
Worrying answer: "nothing, it is all fine." Every real product has a scary corner. Not naming it means either it has not been looked at or it is not safe to say so.
What it costs: that corner is where your incidents will come from, and it is usually two weeks of work away from being ordinary.
6. If you were hit by a bus, what would we not know?
Phrase it lightly; the question is serious. You are looking for knowledge that exists in exactly one head.
Good answer: a short list, ideally followed by "and I have been meaning to write that down."
Worrying answer: a long list delivered with pride.
What it costs: this is the finding investors call key-person risk, and it turns into conditions in a term sheet — see what investors check.
7. What would you fix if I gave you three uninterrupted weeks?
The closing question, and the most useful one to write down word for word.
Good answer: an ordered list of three or four specific things, with reasons. This is a roadmap produced by the person with the most information, for free.
Worrying answer: "rewrite it." Sometimes correct, usually the instinct rather than the diagnosis — the distinction is the whole of Rewrite or Repair?.
What to do with the answers
- Write them down verbatim, including the hedges. The hedges are data.
- Count how many were specific. Five or more confident, specific answers is a genuinely healthy sign, whatever the content.
- Take the answer to question seven and cost it. Three weeks of one person is rarely the constraint people assume it is.
- Bring questions 2 and 6 to your next board meeting before anyone asks you. Naming key-person risk yourself is the difference between a plan and a finding.
None of this requires you to learn anything technical. It requires you to ask, listen for specificity, and treat the answers as the operating information they are.
