HIRING AND BEING HIRED
RevOps interview questions that test judgement, not trivia
Whether you can name every object in a CRM is knowable from a résumé. Whether you can tell that a conversion rate improved because the definition narrowed is not — and it is the whole job. These twelve questions are built for the second thing.
Each question below is followed by what a strong answer contains. If you are hiring, that is your rubric. If you are interviewing, it is what the good version of your answer needs to do — and the honest use of this page is to think the questions through rather than to memorise the answers, because every one of them has an obvious follow-up that memorisation does not survive.
Measurement literacy
Whether the candidate knows what a number excludes. The highest-signal area and the fastest to test.
“Our lead-to-opportunity conversion rate improved twelve points last quarter. What would you check before we celebrate?”
A strong answer. Whether the definition of a lead changed, whether volume fell (a smaller, better-qualified top of funnel raises the rate without improving anything), whether the measurement window shifted, and whether something is being excluded that used to count. A strong answer treats the improvement as a claim to be falsified. A weak one explains why conversion rates improve.
“Pipeline coverage is 3.2x and the forecast still missed. What happened?”
A strong answer. Coverage says nothing about pipeline quality or age. Expect them to ask about close dates in the past, stage distribution, whether coverage is measured against the right quota period, and win-rate assumptions baked into the ratio. The best answers point out that coverage is a ratio of two numbers that can each be wrong.
“Marketing reports 400 qualified leads. Sales says they got 80. Who is right?”
A strong answer. Both, and the disagreement is the finding, not a dispute to arbitrate. Look for them to go to the definitions and the handoff — what each side counts, at what moment, and whether anything is being lost in routing rather than in judgement.
Process reasoning
Whether they can model how work actually flows, as opposed to how the diagram says it does.
“Walk me through how you would find where our funnel is leaking, in your first month, with no budget.”
A strong answer. A method, not a tool. Inventory the stages and their definitions, measure time in stage and stage-to-stage conversion, find where volume drops or time inflates, then interview the people at that boundary. Strong candidates mention talking to reps, because the data shows where and people explain why.
“A process step has two owners. Is that better or worse than none?”
A strong answer. The same, and knowing that is a genuine marker. With two owners each assumes the other has it; with none everyone does. Both fail silently, which is what makes them dangerous compared to a step that fails loudly.
“Reps are routing around the process you designed. What do you do?”
A strong answer. Find out what the process costs them before enforcing it. Workarounds are almost always rational responses to a real friction, and a candidate whose first instinct is enforcement will design processes that keep getting routed around.
Governance and data
Whether they understand that the constraint is usually ownership, not technology.
“Two systems hold a different value for the same customer. How do you decide which is right?”
A strong answer. Establish which system is the system of record for that field — a governance decision, not a technical one — then reconcile toward it and prevent recurrence by constraining writes. Weak answers go straight to a sync or a deduplication tool without deciding what authoritative means.
“How would you decide whether a new required field is worth adding?”
A strong answer. By what decision it changes. Required fields are a tax on every record created forever, paid by the people least invested in the reporting. A strong answer asks who will use it, how often, and what happens if it is blank — and is willing to conclude no.
“What would you not automate?”
A strong answer. Anything where the exception rate is high, the cost of a wrong action is large, or the rule is still changing. Automating an unstable process just makes it fail faster and less visibly. This question separates people who like tools from people who understand them.
Authority and judgement
Whether they can operate in a role that is accountable for things it cannot mandate.
“You need sales to change how they use a field. They do not report to you. How do you get it done?”
A strong answer. Evidence first, and something given back. Look for a quantified cost of the current behaviour, a change small enough to adopt, and an understanding that the ask has to cost the other team less than the problem does. Escalation as a first move is a poor sign.
“Tell me about a time your recommendation was rejected.”
A strong answer. A specific instance, what the objection actually was, and whether they later thought the objection was right. Candidates who cannot name a rejection have either not proposed much or are not telling you.
“What is a metric you used to believe in and stopped believing in?”
A strong answer. Any concrete answer is good. This tests whether their thinking has moved at all, and it is the question most likely to produce a genuinely revealing conversation. No answer usually means no reflection.
Five questions to ask them
These are diagnostic. The answers tell you whether the role has been scoped with the authority to succeed, which is the main determinant of whether you will enjoy it — see the authority problem.
- What can this role decide without consensus?
- Who owns the forecast today, and would that change?
- What broke last quarter that this role would have prevented?
- Which function will be most annoyed by this role doing its job well?
- Is there a single written definition of a qualified lead, and can I see it?
WHERE THIS FAILS
These questions suit a process-owning role. For a specialist position — systems administration, deal desk, enablement — you should be testing depth in that surface instead, and the measurement and governance sections will over-weight generalist reasoning the job does not need.
A rubric can become a script. Now that the strong answers are written down, some candidates will have read them. That is fine and largely self-correcting: ask for the specific instance behind the answer. Judgement survives a follow-up question; a memorised answer does not.
The best interview answer is a real audit
Every question above is easier to answer well if you have actually run the work once. That is what the courses here produce — a structured audit of a real revenue operation, with the workbook to show for it.
COMMON QUESTIONS
- What questions are asked in a RevOps interview?
- Good ones cluster into four areas: measurement literacy (what does this number exclude), process reasoning (how would you find where the funnel leaks), governance (which system is authoritative for this field), and authority (how do you get a team that does not report to you to change). Weaker interviews substitute tool trivia — which screens for people who have used a particular stack rather than for people who can fix a process.
- How do I prepare for a revenue operations interview?
- Prepare one worked example you can walk through end to end: a process you measured, what you found, what you recommended, what actually happened, and what you would do differently. Nearly every good question in a RevOps interview can be answered from a real example, and a candidate with one concrete story outperforms a candidate with general knowledge almost every time.
- What should I ask in a RevOps interview?
- Ask what the role can decide without consensus, who owns the forecast, and what broke last quarter. Those three answers tell you whether the job is scoped with the authority to succeed — which predicts your satisfaction in the role more reliably than compensation or title. A company that cannot answer the third question is either not measuring or not being candid.
- Should RevOps interviews include a technical test?
- A short, realistic one is reasonable — read a small dataset and say what is wrong with it, or critique an existing report. Multi-day take-home projects screen for availability rather than for capability, and they disproportionately exclude the experienced candidates you most want. Keep it under two hours and make it resemble the actual job.