The strongest candidate I ever debriefed lost the hire decision in the last four minutes.
He shredded the system design round. Then the hiring manager said "any questions for us?" and he said, "No, I think you covered everything." One line went into the scorecard: no questions, can't tell if he wants this job or a job. We hired someone with visibly rougher code who had asked us what our rollback story looked like, and then asked a follow-up when our answer got mushy.
That was the moment I understood that the questions to ask the interviewer are not a politeness ritual. They are a scored round with no rubric published, and they are also the only round where you get to interview them.
TL;DR
- The "any questions?" segment is scored in most structured loops, usually as evidence of role-specific interest and seniority, not as trivia.
- Bad questions ask for things the careers page already answers ("what's the culture like?"). Good questions ask for a specific past event the interviewer had to live through.
- The single most useful trick: ask the same question to three different interviewers and compare the variance. The disagreement is the signal, not the answer.
- Match the question to the role: recruiter gets process, peer gets daily reality, hiring manager gets decision rights, skip-level gets roadmap risk.
- If an answer is vague, ask one calm follow-up. How they handle being probed tells you more than the answer itself.
Why do interviewers score the questions you ask?
Because it is the cheapest way to separate people who want this team from people who want an offer. Most scorecards have a "motivation" or "role fit" line, and for a lot of interviewers, your questions are the only evidence that line ever gets.
There is a second reason, and it is more brutal: your questions leak your seniority. A junior asks about the tech stack. A mid-level asks about the process. A senior asks about ownership, blast radius, and who decides what. Nobody plans it that way, but every interviewer I know pattern-matches on it instantly.
What questions should you ask the interviewer?
Ask about events, not adjectives. Adjectives ("collaborative", "fast-paced") are free to say and impossible to check. Events have to be remembered, and people are bad at inventing them under time pressure. Here are seven that consistently pull real information out of a room, roughly in order of how much they've paid off for me.
1. "What happened to the last person in this role?"
Backfill or growth? Promoted internally or quietly gone? If it's a backfill and nobody wants to say where the person went, you've learned something the offer letter will not tell you. Ask it flat, without apology. It's a normal question.
2. "Tell me about the last incident that woke someone up at 3am. What changed afterward?"
This one is my favorite because it's a three-for-one. You learn the on-call reality, whether postmortems produce actual changes, and whether the person can talk about failure without getting defensive. Teams with a healthy blameless culture answer this in cheerful detail. Teams without one get weirdly clipped.
3. "How does code get from my laptop to production, and how long does that take today?"
Note the word today. Everyone has a beautiful CI diagram. Ask how long it took last Tuesday. "About twenty minutes, we deploy a few times a day" and "well, we batch into a release train and QA signs off" are two completely different jobs.
4. "How much of a sprint goes to work nobody outside engineering asked for?"
That's tech debt, tooling, migrations, and reliability. If the honest answer is zero, you're joining a feature factory and your first year will be spent apologizing for a codebase you didn't write. A real number, even a small one, means someone is protecting engineering time.
5. "Who decides what I work on next quarter, and what happens when I disagree?"
Decision rights are the actual org chart. The first half is easy for them to answer. The second half is where you find out whether engineers here are partners or ticket-takers. Listen for a concrete instance of an engineer changing a plan.
6. "What's the most recent thing this team shipped that didn't work, and how did you find out?"
"How did you find out" is the payload. If the answer involves dashboards, an experiment, or a customer metric, they measure. If nobody remembers anything failing, either nothing ships or nobody checks, and both are bad.
7. "If I'm doing great six months in, what does that look like specifically? And who besides you has to agree?"
The second sentence separates managers who can actually promote you from managers who can only advocate. Ask it politely and you will occasionally watch someone realize, live, that they don't know.
What questions kill your rating?
Questions whose answers are on the careers page, and questions that can't be wrong. "What's the culture like?" cannot be answered badly. "Do you like working here?" is answered by a person whose employer is in the room. "What's a typical day?" gets you a job-description recital.
Also skip these until an offer exists: total comp, vacation policy, remote flexibility beyond what's already posted. Not because wanting them is shameful, but because the recruiter is the right person and post-offer is the right time, when your leverage is at maximum. Asking a peer interviewer about PTO burns your one high-signal slot on information you'll get for free later.
And one warning about the clever ones. "What's your biggest weakness as a manager?" reads as a gotcha you got from a listicle. If you want that information, ask "what's something this team is bad at that you're actively trying to fix?" Same information, no theater.
What's the trick that actually works?
Ask the same question in every round, then compare the answers. This is the highest-leverage thing in this entire post.
Pick one: "what's the biggest risk to this team hitting its goals this year?" Ask the recruiter, the peer, the manager, and the skip-level. Write down all four answers.
If they're broadly consistent, that team has a shared understanding of reality. That is rarer than you think, and it correlates with almost everything good.
If the manager says "hiring" and the peer says "the legacy billing service" and the skip-level says "we're waiting on a decision from another org," you've just mapped the dysfunction in ten minutes of small talk. The variance is the finding. I've turned down offers on variance alone and never regretted it.
How do you ask a hard question without sounding hostile?
Frame it as your own planning, not as an audit. "I want to understand what my first quarter would actually look like, so: how does code get to production today?" is the same question as an interrogation, minus the interrogation.
Then, if the answer is vague, ask exactly one follow-up. One. "Got it. What did that look like the last time it came up?" That's it. Two follow-ups on a sore spot and you're the person who cross-examined the team.
Watching how someone handles that single follow-up is worth more than their answer. Somebody who says "honestly, that's a mess right now and here's what we're doing about it" has just given you a better reason to take the job than any perk in the packet.
So what are the best questions to ask the interviewer?
The best questions to ask the interviewer are specific, event-based, and answerable only by someone who works there: what happened to the last person in this role, what the last incident changed, how long a deploy takes today, how much time goes to unglamorous engineering work, who decides your roadmap, what recently failed and how they found out, and what success at six months concretely looks like. Ask two or three of them per round, ask one of them in every round so you can compare answers across interviewers, and treat inconsistency between those answers as your most reliable signal. You will get a better read on the team than any Glassdoor page, and you will score higher on a rubric line most candidates never knew existed.
What's the one question you always ask? I'm collecting good ones.
