Questions to Ask Your Interviewer: A Round-by-Round Guide from the Interviewer's Chair

"Do you have any questions for me?" arrives in the last five or ten minutes of nearly every interview round, and in my experience it's the least prepared moment in the whole loop. Candidates spend weeks drilling algorithms and rehearsing behavioral stories, then improvise the one section they could have scripted completely in advance. Having run a lot of these loops from the interviewer side, I can tell you the improvisation shows, and I can also tell you that some of the candidates I remember most clearly, years later, I remember specifically because of what they asked me at the end.

The unofficial grade

Most rubrics I worked from had no line item for the candidate's questions, but they get evaluated anyway. Strong ones show up in writeups ("asked sharp questions about our on-call load"), get repeated in debriefs, and land at the exact moment the interviewer's impression is freshest, since the reverse Q&A is usually the last thing that happens before they sit down to write their notes. The round realistically keeps being graded until you leave the call, and a lot of candidates visibly relax and check out the moment the technical portion ends, which is completely understandable (you just sprinted for 40 minutes) but leaves a small amount of value on the table every single time.

I want to be honest about the weight. I never saw a great reverse Q&A flip a clear no into a yes, and no question you ask will rescue a bombed coding round. Where it matters is the in-between cases. When a panel is split, the candidate who "asked thoughtful questions and clearly did their homework" gets the benefit of the doubt more often than the one who asked nothing, and nearly every rubric does carry some version of a "would I want to work with this person" box that your questions feed directly.

What generic questions signal

"What's a typical day like?" and "how would you describe the culture?" won't sink you, but they're questions you could ask at any company without knowing a single thing about this one, and interviewers notice. They read as low effort, or at least as low specific interest, and teams quietly wonder whether a candidate wants this job in particular or just any job. Asking nothing at all reads worse; it comes across as checked out even when it's really just fatigue. If you've blanked before and said "no, I think you covered everything," don't be too hard on yourself. Nearly everyone has done it once, and this is the easiest weakness in the entire interview to fix, because it's the only section you can fully script before you walk in.

Specific, researched questions do several jobs at once. They prove you did the homework, they signal genuine interest in this team rather than in an offer generally, and they convert the last ten minutes into a peer conversation, which is where rapport actually forms. It's much easier to like a candidate who just asked you an interesting question about your own work.

The questions are for you too

I garden, and one of the first lessons the hobby teaches (usually the hard way) is to check the soil before you plant anything you care about: the drainage, the sun, what died in that spot last year. The plant spends years living with whatever you didn't bother to check. The reverse Q&A is you checking the soil before you plant yourself somewhere, so past all the signaling value, ask things you genuinely want to know. You're allowed to be evaluating them too, and in my experience the candidates who clearly were evaluating us came across as stronger for it, because that kind of quiet confidence reads as having options.

What to ask in the coding round

The general trick across every round is to match the question to the person in the room, since each interviewer can only speak firsthand to their own corner of the company. Your coding interviewer is usually an engineer on or near the team, so ask about the engineering day-to-day:

• How does code review work on your team, and what does a good one look like?
• What happens between "code written" and "code running in production," and how often do you ship?
• What is on-call actually like (rotation size, how often it pages, what pages most)?
• What are you working on right now, and is it typical of the team's work?

What to ask in the system design round

Design rounds are usually staffed by senior engineers, which makes them your best opening for real architecture conversation:

• What part of your current architecture would surprise me, or what would you redesign if you could?
• What's the scaling problem the team is actually fighting this year?
• If the company has a public engineering blog (the same blogs that make good design prep material), ask about a real post: "I read the writeup on your move to X, how did that play out from the inside?" This is, in my experience, the single most memorable question type, because you're asking engineers for their war stories, and engineers love telling war stories.

What to ask the hiring manager

Behavioral and manager rounds are where questions about growth and expectations belong, because the manager is the one person in the loop who actually owns the answers:

• What does success in this role look like at six months, and at a year?
• How do promotions actually work here (manager-driven, committee, calibration cycles)?
• What separates someone doing fine on this team from someone doing great?
• What's the biggest challenge the team has right now that isn't technical?

Prepare three or four per round, in writing

You want 3-4 questions per round, written down beforehand. A notes file on a second screen is fine for video calls and paper is fine onsite; nobody loses points for glancing at prepared questions, and if anything it reads as organized. You need that many because some will get answered naturally during the interview, and asking a question the interviewer already covered 20 minutes ago is the one way the reverse Q&A actively hurts you, since it signals you weren't listening. Cross them off as they come up and go to your spares.

The questions come out of the same research you should be doing anyway: the job posting, the engineering blog if one exists, recent product or company news, and actually using the product when you can. Good questions basically require that research to exist, which is sort of the point. Writing them becomes a forcing function to do the homework, and that's why they get their own bullet in week 4 of the 4-week prep plan.

What to avoid

• Comp, vacation, and perks questions in technical rounds. Those belong with the recruiter, whose actual job this is, and realistically levels.fyi will answer the comp part better than any single interviewer can.
• Questions that are secretly speeches (a 60-second preamble demonstrating your knowledge, followed by "thoughts?"). Interviewers can tell, and it burns rapport instead of building it.
• Prosecutorial versions of hard questions. You can and should ask about attrition, reorgs, or why the role is open (that's soil-checking), but tone carries it, and genuine curiosity lands very differently than cross-examination. The later the round, the more direct you can afford to be.

The reverse Q&A is a small thing, and I don't want to oversell it, since no closing question rescues a failed technical round. But it's also the cheapest improvement available anywhere in the process: ten minutes of research per company buys you rapport, information you genuinely need before you commit years of your life somewhere, and a stronger final impression. If mock interviews are part of your prep, run the reverse Q&A portion too instead of stopping when the technical part ends (a friend across the table covers this for free, and if you'd rather practice against an AI interviewer, that's what we build at Preppable). Either way, walk into every round with your 3-4 questions already written down.