Questions That Signal Seniority

Every interviewer leaves time for questions, and most write down what you asked. It's a cheap signal and candidates routinely waste it on things the website answers, or on nothing at all — "no, I think you've covered everything" is the worst available answer and it happens constantly.

Ask about the actual work. "What's the thing that would land on my plate in the first month?" "What did the last two weeks look like for the team?" "Which part of the codebase does everyone flinch at?" These get concrete answers and reveal more than any culture question.

Ask about decisions. "What's a technical decision the team made that you'd revisit?" "How was the last big architectural change decided — who was in the room?" This tells you how the company makes calls, which is the thing you'll be living inside.

Ask about failure. "What happened during your last incident?" "When something ships and doesn't move the metric, what happens next?" Willingness to answer these tells you almost as much as the answers.

Ask something only they could answer, drawn from their product or engineering blog. It's the strongest available proof you did the work, and it changes the register from assessment to conversation.

Tailor to the person. Engineers get depth about the codebase and how work arrives. The hiring manager gets team shape, how success is measured, what happened to the last person in this role. Founders get strategy, runway, and where the model risk sits. Asking the founder about the test suite wastes the one slot you get with them.

Two or three good ones is right. Don't run a checklist, and don't ask questions whose answers you don't actually care about — it shows.

This is the one part of the loop where your judgement is on display without a prompt shaping it, and interviewers treat it that way. It's also the highest-leverage information you'll get about whether the job is any good — a job search is bidirectional, and at a startup the downside of a bad match is a year of your life.

• What you ask is recorded and scored; "nothing, you covered it" is the weakest possible answer.
• Prefer concrete over cultural: first-month work, last two weeks, the part of the codebase people avoid.
• Ask how a real decision got made — it reveals the actual operating model.
• Ask about a recent failure or incident; the willingness to answer is itself the signal.
• Include one question only this company could answer, drawn from their blog or product.
• Match the question to the person — depth for engineers, team and success for managers, strategy for founders.
• Two or three genuine questions beats a list you're working through.
• Ask what you actually need to decide with; you're also evaluating them.