How to Reverse-Interview a Company: The Questions Engineers Should Ask Before Accepting
How to Reverse-Interview a Company: The Questions Engineers Should Ask Before Accepting
The interview process is sold as a one-way evaluation. It isn't. You're also deciding whether you want to work somewhere, and the window you have to collect that data closes the moment you sign.
Most engineers under-use this window. They prepare relentlessly for the technical screen, the system design round, the behavioral section — and then, when the interviewer says "do you have any questions for us?", they ask something polite and generic. How's the culture? What does a typical day look like?
Those questions don't give you signal. They give the interviewer an opportunity to recite the employer brand talking points they've been trained to deliver.
The questions in this playbook are designed to produce real information — about the team's actual engineering practices, the manager's style, the promotion machinery, the on-call burden, and the red flags that are almost never mentioned until you're three months in and unhappy.
Why This Stage Is Underrated
The standard interview funnel — application, screen, technical round, offer — is designed to evaluate you. The reverse interview is your equivalent evaluation of them, and it has a structural advantage: people are much harder to coach on specific operational questions than they are on "what's the culture like?"
Ask a hiring manager how often they deploy to production and you'll get an actual answer, not a brand statement. Ask what happens after a major incident and you'll see whether the team does blameless postmortems or assigns blame. Ask what the career ladder looks like past senior and you'll learn whether staff-level growth is real or theoretical.
The goal is to get information you can't find on the careers page — because the data that most affects whether you'll thrive in a role lives in the specifics: practices, cadences, ownership structures, real examples of what happened.
Stage 1: Recruiter Screen — Filter for Dealbreakers Early
The recruiter screen isn't a throwaway round. It's the cheapest point in the process to surface dealbreakers before you've invested four rounds and a take-home.
The questions that cut through:
-
"What's the typical timeline from offer to start date? And is this backfill or a new headcount?" — Backfills usually mean the role has real scope defined; net-new headcount can mean the role is still being figured out.
-
"What's the current on-call expectation for engineers in this role? Is there a rotation, and how often does it page after hours?" — If the recruiter doesn't know, ask them to find out before the next round. An evasive answer here is a signal.
-
"What does the work structure actually look like — remote, hybrid, or in-office? And has that policy changed in the last 12 months?" — You want to know both the current policy and its trajectory. A company that went from fully remote to 3-days-in-office in 18 months is likely to continue that direction. RTO mandates have accelerated significantly in 2026 — understand where this company stands before you get emotionally invested in the process.
-
"What's the engineering team size, and how does the team structure work?" — Small teams mean broad scope and context-switching. Large teams often mean slower decision-making and more specialization. Neither is bad; both are worth knowing.
What you're screening for: Dealbreakers. If on-call is every other week and you have a child with medical needs, that's a dealbreaker you've discovered before spending 20 hours on interviews.
Stage 2: Hiring Manager — The Most Important Conversation
Your hiring manager is the single biggest predictor of your success in a role. The research on this is consistent — manager quality outweighs company, benefits, and compensation in predicting employee engagement. You're interviewing them as much as they're interviewing you.
This is also the stage where most engineers are the most passive — because the hiring manager holds power in the conversation. Push past that instinct.
Engineering Practices
"What does your deployment process look like? How often does the team ship to production, and who can trigger a deploy?"
Healthy answer: Deploys happen multiple times per week (ideally per day), engineers can self-serve them, there's a CI/CD pipeline, and rollbacks are straightforward. Any answer that mentions "release windows," "change advisory boards," or "only ops can push to prod" is telling you something about the engineering culture.
"What does your incident response process look like? Do you do postmortems, and are they blameless?"
Healthy answer: Incidents get documented, postmortems focus on systemic causes rather than individual blame, and the findings actually drive improvements. A manager who says "we do postmortems" but can't give you a concrete example of something that changed because of one is giving you a non-answer.
"How much of the team's time goes to new development versus maintaining existing systems and paying down technical debt?"
This question has no universally right answer — a startup at 80% new development and 20% maintenance is probably fine; the same ratio at a 10-year-old product company is likely a debt problem waiting to compound. What you're looking for is whether the manager has a clear, honest answer — or whether they hedge in a way that suggests the ratio is uncomfortable to state.
Career Growth
"Can you walk me through what the promotion path looks like from my current level to senior? And past senior — do you have staff or principal engineers on the team?"
Vague answers ("it depends on performance") aren't necessarily wrong, but push for examples: "Can you tell me about someone on the team who was promoted recently — what did that trajectory look like?" If the manager can't name a single concrete example of recent growth, that's data.
"What separates the engineers who grow quickly here from the ones who plateau?"
This is a better question than "what does success look like?" because it asks for differentiation, which forces specificity. A manager who can answer this well — with concrete project types, technical domains, behavioral patterns — understands what growth looks like on their team and has probably created it before.
"How does the performance review process work, and how directly does it connect to compensation outcomes?"
Ask explicitly: are reviews once or twice a year? Is there a forced calibration (ranking against peers) or individual assessment? Does a "meets expectations" review produce a raise, and if so, what percentage? What's the process for going from "strong performer" to "exceeds"? The more the manager can tell you specifically, the better the system actually works.
Manager Style
"How do you think about giving engineers ownership over features end-to-end versus distributing work across the team?"
This reveals whether you'll have real scope or be a ticket-taker. An engineer who wants to own things end-to-end — problem definition, architecture, implementation, monitoring — needs a manager who operates that way. An engineer who wants clear task definition and good execution support needs a different manager. Neither is wrong; match matters.
"Tell me about a time you and a direct report disagreed on a technical decision. How did you handle it?"
A good manager has a specific story and some reflection on it. The story reveals whether the culture is psychologically safe for technical dissent — or whether disagreement with the manager is career-limiting.
Stage 3: Team Interview — Read the Engineers, Not the Script
Your future teammates are the most honest information source in the process. They're less trained to recruit, they have direct experience with what you're asking about, and they have the most to gain from being honest (they're the ones who have to work with you).
The best questions for team interviews surface what it's actually like to be an engineer on the team — not what it sounds like on the careers page.
"What's the hardest part of your job right now? Not the most interesting — the hardest."
The distinction matters. Interesting problems are the ones recruiters brief engineers to discuss. Hard problems — coordination overhead, legacy systems, unclear ownership, technical decisions they disagree with — are the ones that affect your day-to-day quality of life.
"What does your code review process look like? Who reviews, how long does it take, and what are you looking for in a review?"
A team that can describe their code review process specifically — who reviews, what the bar is, typical turnaround — is a team with shared engineering standards. A team that says "we review PRs" but can't describe what a review actually covers is a team where standards may be implicit or absent.
"What was the most controversial technical decision your team made in the last year? What was the outcome?"
This question reveals several things at once: whether the team has a culture of making actual decisions (some teams endlessly defer), whether engineers feel safe disagreeing with each other, and whether the team learns from the decisions it makes. The answer doesn't need to be about a successful decision — a team that candidly describes a mistake and what they learned is a healthier team than one that only talks about wins.
"What's the state of the onboarding process? If I joined tomorrow, what would week one actually look like?"
Compare what they say to what you want. A specific, structured answer — "you'd start by reading the RFC library and the architecture docs, then pair with [person] on a starter ticket, and we'd do daily check-ins" — is a good sign. "We just kind of get you going" or "it's a little ad hoc" is honest but tells you something about how organized the team is.
"How long has the longest-tenured engineer on the team been here? And what's the average tenure?"
Tenure patterns reveal a lot about team health. Low average tenure (under 18 months) in a non-startup environment usually signals something structural. But also watch for the inverse: very high tenure in a team that also hasn't shipped anything significant in years can indicate stagnation.
Stage 4: Final Round — Long-Term Signals
Final rounds often include a conversation with a VP or director, a cross-functional leader, or a panel. These conversations tend to be more strategic and less operational — but they're where you can assess the long-term trajectory of the role and the organization.
"What does the company's engineering strategy look like over the next 12 months? Where is headcount being added, and where is it being held flat?"
A senior leader who can answer this specifically — and whose answer aligns with what the hiring manager told you about the team's roadmap — is a leader who's communicating clearly down the chain. Inconsistency between answers at different levels is itself a signal.
"Is this role a backfill or net-new? And if it's a backfill, what happened to the person who held it before?"
This is a question recruiters often deflect but senior leaders usually answer. If the previous person was promoted, that's a green flag — the role has a growth track. If they were managed out, or if the answer is evasive, dig a little more.
"What are the biggest organizational risks you're navigating over the next 6–12 months?"
This question only works if you're ready to hear an honest answer and not have it faze you. Leaders who can describe real risks clearly — market competition, a difficult migration, headcount constraints — are operating with transparency. Leaders who say "I can't think of any" either aren't being honest or aren't looking.
What the Answers Tell You: Green Flags and Red Flags
Green flags:
- Specific examples over general platitudes ("Here's someone who was promoted and what their trajectory looked like" vs. "We really value growth")
- Engineers who can describe the last major incident clearly, including what changed because of it
- A promotion process with documented criteria, not vibes
- Deployment cadence measured in days, not quarters
- On-call load that's bounded and explicitly managed (rotation size, escalation policy, on-call stipend or comp time)
- Technical disagreements that get resolved through explicit process (RFCs, tech leads, escalation path), not ignored or escalated to politics
Red flags:
- Multiple interviewers cite the same unresolved problem ("we have a lot of legacy systems," "we're rebuilding the infrastructure") — if everyone's warning you, that's not a coincidence
- The hiring manager can't describe the promotion bar concretely
- Questions about team turnover are deflected: "people stay a long time here" without any specifics
- Nobody has shipped a concrete thing they can point to recently
- The interviewer can't name the on-call rotation structure or says "it's not that bad" without giving a number
- Interviewers give suspiciously aligned, rehearsed answers about culture — genuine teams have genuine disagreements
The viraptor/reverse-interview repository on GitHub has been used by thousands of engineers as a checklist for this process — worth reading before your next interview loop.
The Question That Cuts Through Everything
If you can only ask one question across the entire process, make it this:
"What would the engineer who succeeds most in this role in the next two years be doing differently from the engineer who does average work?"
A manager who can answer specifically — with real examples, skill domains, and behavioral patterns — understands what success looks like on their team and has created it before. A manager who gives a generic answer about "ownership" and "initiative" either isn't thinking about it or is telling you what sounds good.
The answer also tells you whether you're a fit. If the success bar requires skills you're actively building, that's an opportunity. If it requires skills that have nothing to do with why you'd take the role, that's a useful data point before you sign.
Where This Fits in the Job Search
The reverse interview isn't a standalone skill — it's the data collection stage before the decision stage. The information you gather here feeds directly into the offer evaluation process. Once you have an offer, the 6-dimension offer evaluation framework is how you turn that information into a weighted decision — comparing total comp, manager quality, tech stack trajectory, career growth structure, team health, and work structure across competing offers.
If you're running multiple interview processes in parallel (which you should be), the job search system covers how to manage competing timelines and use offers to generate leverage. And if compensation is the next thing to negotiate after the reverse interview reveals the role is worth pursuing, the salary negotiation playbook covers how to counter in writing with data rather than gut instinct.
The reverse interview is the missing stage between "interview prep" and "evaluate the offer" — and it's the stage that most directly answers the question the offer evaluation framework needs answered: is this company actually what it claims to be?
TL;DR: The Question Bank
Recruiter screen:
- What's the on-call expectation and rotation for this role?
- Has the remote/hybrid/in-office policy changed in the last 12 months?
- Is this backfill or net-new headcount?
Hiring manager:
- How often do you deploy to production, and who can trigger a deploy?
- What does incident response look like, and do you run blameless postmortems?
- What percentage of team time goes to new development vs. maintenance and debt?
- Can you walk me through a recent promotion on your team?
- What separates the engineers who grow quickly here from the ones who plateau?
- Tell me about a time you and a direct report disagreed on a technical call.
Team interview:
- What's the hardest part of your job right now? Not the most interesting — the hardest.
- What was the most controversial technical decision your team made in the last year?
- What does code review actually look like on this team?
- What would week one look like if I joined tomorrow?
Final round:
- Where is headcount being added over the next 12 months, and where is it flat?
- What are the biggest organizational risks you're navigating right now?
The one question that cuts through everything:
- What would the engineer who succeeds most in this role in the next two years be doing differently from the engineer who does average work?
The materials you bring into an interview loop shape the offers you receive. Wrok helps software engineers build the resume and career narrative that gets them into these conversations in the first place — so the work of reverse interviewing actually has a room to happen in. If your resume isn't getting you to the hiring manager conversation, that's the earlier problem to fix.