Reverse due diligence

"Name three red flags you'd probe for, and the exact questions you'd use to surface each without being adversarial."

What it is

Reverse due diligence is the systematic evaluation of the employer, conducted inside the interview loop, using questions that also happen to make you look senior. You are gathering evidence about whether this job is winnable, and the interviewers are simultaneously scoring what you thought to ask.

That dual purpose is the whole design. A question like "walk me through your last production incident and whether the action items actually happened" collects hard information and signals that you know postmortem follow-through is where reliability cultures succeed or fail. A question like "what's the tech stack?" collects information you could have read and signals nothing.

Commonly confused with negotiation research or culture-fit assessment. Those are about whether you would enjoy the job. This is about whether the role is structurally winnable: whether success is defined, whether you would have the authority to achieve it, and whether the last person had a chance.

The problem it solves

A bad senior or lead role costs eighteen months and, at this level, is usually not recoverable into a good story. The failure modes are rarely about the technology. They are: no shared definition of success, no air cover, a mandate without authority, or a team problem that hiring cannot fix.

All four are detectable during the loop, and almost none of them appear in the job description. They appear in the inconsistencies between what different interviewers tell you, which is why the mechanic below matters more than any individual question.

Mechanics

The mechanic: triangulate, do not interrogate

Ask the same question of three different people and compare. Consistency is information; divergence is much more information.

"What does success look like for this role at six months?"

Three answers that agree, with specifics, means the org has a shared model. Three answers that diverge (the hiring manager says "stabilise the platform", the director says "ship the Q3 roadmap", a peer says "we mostly need another pair of hands") means nobody has agreed what you are for, and you will spend a year discovering you are failing at a goal you were never told about.

Write the answers down between rounds. You will not remember them accurately after six conversations, and the contradictions are the highest-value data you can collect.

The nine red flags

Weigh patterns, not single data points. Any organisation has one bad answer; three of these across a loop is a signal.

The questions, mapped to the flags

The craft is asking so that a defensive answer is not the natural response. Three techniques do most of the work: ask about the past rather than the present ("what happened last time" rather than "is this a problem"), ask for a specific instance rather than a general characterisation, and give permission to be honest by acknowledging that every organisation has the problem.

Flags 1 and 2: no shared reality, no definition of success.

"What does success look like for this role at six months, and who decides whether it happened?"

Ask this of the recruiter, the hiring manager, a peer and the skip-level. The second clause is the sharp one: a role where nobody can name the person who judges it is a role with no owner.

"What's the problem in your org that made you open this req? What breaks, or stays broken, if it goes unfilled for six months?"

The single best hiring-manager question. The answer is the actual job, which is frequently not the job description. If the answer is vague, the mandate is vague.

Flag 3: predecessor churn.

"Is this role backfilling someone, or is it new scope? What did the last person in the seat find hardest?"

Two questions in one, and the second is doing the work. It is easy to answer honestly ("they struggled to get the platform team to prioritise their work") and that answer tells you about the organisation, not the person. Asking "why did they leave?" invites a defensive non-answer; asking what they found hardest invites a useful one.

Ask a peer separately: "How long has this team been looking for a lead?" A nine-month search for a role that sounds attractive means something is wrong that candidates keep detecting.

Flag 5: no air cover.

"What's your operating rhythm with your leads? What do you want escalated, and what do you expect me to just decide?"

"Where do you and your manager currently disagree about this team's direction?"

The second is bold and it is the highest-yield question in the set. A manager who can answer it candidly has a real relationship with their own manager and is comfortable with disagreement, which is exactly the air cover you need. A manager who deflects entirely is telling you they are not in the conversations that decide your team's fate.

Flag 6: reliability theatre.

"Walk me through your last production incident. What happened, and did the postmortem action items actually ship?"

Ask a peer engineer, not the manager. ICs are the least media-trained people in the loop and will tell you the truth. The follow-up if the answer is positive: "which one, and roughly when did it land?" A specific example is confirmation; a general reassurance is the flag.

Flag 7: centralised authority.

"How do technical decisions that span teams get made here? Can you walk me through the last significant architectural decision and how it was reached?"

Ask for the last one specifically. A description of a process is aspirational; a narration of a specific decision is what actually happens. If every story ends with one named person deciding, you now know the shape of the role.

Flag 8: product and engineering relations.

"What does engineering do that makes your job harder? Honestly."

Ask the product partner. Giving explicit permission to criticise is what makes it answerable, and the tone of the answer carries more information than the content. Wry and specific is a healthy relationship. Guarded is not. A flood of grievance is a warning.

Flag 9: levelling.

"What level is this calibrated at, and what does the committee look for at that level?"

Ask the recruiter, early, in the screen. Recruiters want you to succeed and will usually just tell you. Asking early is also how you avoid the down-levelling surprise at the offer stage, when the band is already set and arguing dollars inside the wrong band is fighting the wrong battle.

Where to ask what

The mistake is asking everyone the same set. Peers cannot tell you about strategy and executives cannot tell you about the codebase, and asking the wrong persona wastes the two or three questions you get.

A worked example: the loop that fell apart

A staff role at a mid-size fintech. Five rounds.

Recruiter. "Calibrated at staff. The committee looks for cross-team impact." Clean answer, no flag.

Hiring manager. "Success at six months is stabilising the payments platform; we've had three sev1s this quarter." Specific, credible, and it names a measurable outcome. Good.

Peer engineer. "What would you fix first with a month of unscheduled time?" Answer: "Honestly, get anyone to prioritise the platform work. We've been asking for two quarters." Flag 5 forming: the manager's stated priority is not reflected in what the team can actually get resourced.

Skip-level. "What does success look like for this role at six months?" Answer: "Delivering the merchant onboarding roadmap on time." Flag 1 confirmed: the hiring manager says stability, the director says roadmap delivery, and those compete directly for the same capacity.

Follow-up to the skip-level, asked carefully: "The hiring manager mentioned platform stability as the six-month priority. How do you see those two sequencing?" Answer: "Well, we need both." Flag 2 confirmed: nobody has made the tradeoff, which means the new hire will be asked to make it without the authority to, and will fail against whichever goal they deprioritised.

Product partner. "What does engineering do that makes your job harder?" Answer, after a pause: "They tell us things are impossible without explaining why." Not a flag on its own, but it is the same story from the other side: the engineering organisation is not making its constraints legible to the people who set priorities.

Assessment. Three flags: divergent success definitions, no owner for the tradeoff, and a team that has been unable to get platform work funded for two quarters. The role is not unwinnable, but it is a political job disguised as a technical one, and the first six months would be spent getting the manager and the director to agree what the job is.

What to do with that, because walking away is not the only option. Two moves. Ask directly: "I want to make sure I've understood the priority. If the platform work and the onboarding roadmap compete for the same quarter, who makes that call, and how do I get it made?" A good answer resolves everything. And if you take the job, make it a condition: get the tradeoff resolved in writing before you start, because it will not get easier once you own the outcome.

Production evidence

The pattern is well documented in engineering-leadership writing. Will Larson's An Elegant Puzzle and Staff Engineer both treat the mismatch between stated mandate and actual authority as a primary cause of failed senior hires, and recommend interrogating it during the interview rather than after.

Camille Fournier's The Manager's Path makes the same point about air cover: a manager who cannot describe their own manager's expectations cannot protect their reports' work from being reversed, and that is detectable in one question.

Google's own published hiring guidance notes that candidate questions are reported in interviewer feedback, which is the mechanical reason this is scored rather than merely tolerated.

The Team Topologies framing supplies the vocabulary for flag 7: an organisation where all cross-team decisions route through one person has, in effect, one decision-maker and many implementers, regardless of the titles on the org chart.

The debate

The case against doing this aggressively: you are also being evaluated, and a candidate who spends the loop probing for dysfunction can read as suspicious or entitled. There is a real risk of interrogating rather than conversing, and some interviewers will experience "where do you and your manager disagree?" as presumptuous rather than engaged.

The case for it: at staff and lead level you are being hired to exercise judgement, and a candidate who accepts an unwinnable mandate without checking has demonstrated poor judgement in the first decision they made about the job. Interviewers who are good at their jobs recognise the questions as evidence of seniority.

My position: ask, but ask about the past and about specifics rather than about the present in the abstract, and frame every question as curiosity about how things work rather than suspicion that they do not. Ask the same success question of three people and let the divergence do the work, because you never have to accuse anyone of anything; you just notice that the answers differ. And write the answers down between rounds.

Reverse due diligence is the wrong emphasis when you have limited leverage and genuinely need the role, in which case gather what you can and go in with your eyes open rather than talking yourself out of it. It is also wrong applied to a small startup, where "nobody can articulate success at six months" may simply be true of the whole company and is not a red flag so much as a description of the stage.

Follow-up Q&A

"Name three red flags and the exact questions to surface each without being adversarial." First, divergent definitions of success: ask "what does success look like at six months, and who decides whether it happened" of the manager, a peer and the skip-level, and compare. Second, no air cover: ask the manager "where do you and your manager currently disagree about this team's direction". A candid answer means a real relationship, a deflection means they are not in the room. Third, reliability theatre: ask a peer engineer "walk me through your last incident and whether the postmortem action items actually shipped", then follow up with "which one?" None of the three accuse anyone of anything; they ask about the past and about specifics.

"What if you get a bad answer?" Do not conclude from one. Any organisation has a bad answer available on any given day. Weigh patterns: three flags across a loop is a signal, one is noise. And test it before deciding, by naming the tension directly and neutrally: "the hiring manager mentioned stability as the six-month priority and you mentioned the roadmap. How do those sequence?" The answer to that question is worth more than the original flag.

"How do you ask about a predecessor without it being awkward?" Ask what they found hardest rather than why they left. It is easy to answer honestly, the answer is about the organisation rather than the person, and it gets you the information you actually wanted. "Is this a backfill or new scope?" is a natural, unloaded way into it, and if it is a backfill the follow-up is obvious.

"Which persona gives you the most reliable information?" Peer engineers and future reports. They are the least media-trained people in the loop, they live with the consequences rather than the narrative, and they will answer specific questions about the past honestly. "How long does a one-line change take to reach production?" is one number that tells you about the whole delivery system, and no manager's description of the process is as informative.

"You found three flags but you want the job. Now what?" Name the flags as conditions rather than reasons to decline. If the success definitions diverge, ask for the tradeoff to be resolved in writing before you start. If authority is unclear, ask for the decision rights to be stated explicitly. If a predecessor failed for structural reasons, ask what has changed. A hiring manager who engages with those requests has given you the answer; one who treats them as unreasonable has also given you the answer, more usefully.

Common misconceptions

The most common is that asking questions is a formality at the end. Interviewer feedback reports what you asked, so it is scored, and the questions are frequently the last thing an interviewer remembers.

The second is that this is about culture fit. Culture fit is whether you would enjoy it. This is whether the role is structurally winnable, which is a different and more important question, and it is answered by evidence rather than by vibes.

The third is that a single red flag is disqualifying. Any organisation has one. Three across a loop is a pattern, and the correct response to one is a follow-up question rather than a conclusion.

Interview delivery note

If asked how you would do this, lead with the mechanic, not the list: "I'd ask the same question of three different people and compare. 'What does success look like at six months, and who decides whether it happened?' If the manager, a peer and the skip-level give me three different answers, nobody has agreed what the role is for, and I'd spend a year failing at a goal I was never told about."

Then two specific questions with their reasoning: "I'd ask the manager where they and their own manager currently disagree, because a candid answer means real air cover and a deflection means they're not in the room. And I'd ask a peer engineer to walk me through the last incident and whether the action items actually shipped, because ICs are the least media-trained people in the loop and 'usually' is the answer that tells you it's theatre."

The depth signal is the framing rule: ask about the past and about specifics, never about the present in the abstract. "Is prioritisation a problem here?" gets a defensive non-answer. "Walk me through the last time platform work competed with roadmap work" gets the truth, and nobody has to be accused of anything.

Further reading

• Will Larson, Staff Engineer and An Elegant Puzzle, on mandate-versus-authority mismatch as the primary failure mode of senior hires.
• Camille Fournier, The Manager's Path, on air cover and what its absence looks like from below.
• Google's published engineering-hiring material, for why candidate questions are recorded in interviewer feedback.
• Skelton and Pais, Team Topologies, for the vocabulary to describe an organisation with a single effective decision-maker.