What Gets a RevOps Analyst Hired: Defending a Number, Not Knowing the Tool
Every candidate can list the stack. Almost none can survive being asked 'walk me through how you got this number' for ten straight minutes.
Every RevOps candidate I've interviewed in the last few years can recite the stack without hesitating: Salesforce, Outreach, Gong, Clari, dbt, Hex, pick your combination. It sounds like competence. It isn't. Tool fluency is maybe twenty minutes of onboarding at a new company and completely irrelevant three years from now when the stack has changed again. What I actually want to know is whether the candidate can defend a number they produced, under real questioning, without either bluffing or folding.
Here's the test I run. I pull a real number from a report the candidate hasn't seen — say, this quarter's win rate, 24%, straight off our own pipeline. Then I ask them to imagine they built it, and I interrogate it for ten minutes:
- What's the denominator — every opportunity ever created, or only those that reached a qualified stage?
- Does a deal that was reopened from closed-lost count once or twice?
- If a rep backdates a stage change after the fact, which reporting period does it land in?
- Does a self-serve deal that never touched the "Opportunity" object show up here at all?
- Is there one enterprise mega-deal in this number skewing the whole quarter, and would you know if there was?
Most candidates who nailed the stack questions start improvising somewhere around question three. Some guess with confidence, which is worse than admitting they don't know, because it means they'd have shipped a wrong number to a VP with the same confidence. A few get defensive, as if the questioning itself is the problem rather than a normal part of the job. The rare good answer sounds like: "I'd need to check whether reopened deals are deduped in the source view — here's exactly where I'd look, and here's what I'd flag if I couldn't find it." That answer is worth more than a candidate who can name every table in the warehouse from memory.
Why this, specifically, is the skill
A number that can't survive cross-examination is worse than no number — it gets repeated in a board deck, someone makes a call on it, and it turns out the denominator quietly excluded a category nobody thought to mention. The job of a RevOps analyst isn't producing numbers. It's knowing the lineage of every number well enough to say, under pressure, exactly what it includes, what it excludes, and where it would break. Call it what it is: numeric lineage under pressure. It's a distinct, nameable competency, not a personality trait some people happen to have and others don't.
It also happens to be almost entirely untrained. Analysts get taught SQL, taught the tool, taught the metric definitions on day one — and then almost never get deliberately drilled on defending a number to a skeptical audience. The skill gets built by accident, usually after someone gets publicly wrong in a leadership meeting and never wants that feeling again. That's a slow, painful way to build a competency that could be trained on purpose in month one.
What tool fluency actually predicts, versus what this predicts
| Tool fluency | Defending a number | |
|---|---|---|
| Half-life | 12–24 months before the stack changes | Doesn't decay — the discipline transfers to any tool |
| What it's tested by | Take-home exercises, stack trivia | Live, unscripted follow-up questions |
| What it predicts | Time-to-first-dashboard | Whether leadership can trust a number without re-deriving it themselves |
| How obviously it fails | Rarely — most candidates clear this bar | Constantly, and expensively, in the first board meeting it matters |
The uncomfortable part for hiring managers: tool fluency is easy to screen for and mostly useless as a differentiator, because almost every candidate clears it. Numeric defence is hard to screen for and enormously predictive, which is exactly why most interview processes skip it — it's harder to grade, and it takes ten uninterrupted minutes you can't easily template into a scorecard.
How to build it if you're the candidate, not the hiring manager
If you're early-career RevOps and want this to be your edge:
- Own one metric completely, end to end, for a quarter — not "contribute to," own. Know its source table, its filters, its exclusions, and its known edge cases better than anyone else in the building.
- Present that metric monthly to someone whose job is to be skeptical of it — a manager, a finance partner, anyone who'll actually push back rather than nod. If nobody in your org will play that role, ask a peer to do it deliberately.
- Keep a running list of every follow-up question that stumped you, and go find the answer before you're asked it again in a room that matters. This is the single highest-use habit in the list — most people get asked a hard question once, feel bad about it, and never close the gap.
- Practice saying "I don't know, here's how I'd find out" out loud until it doesn't feel like a failure. It's a stronger answer than a guess delivered confidently, and interviewers who know what they're testing for will treat it that way.
Sales Metrics Literacy Quiz is a reasonable gut-check on whether you actually know the standard definitions cold before you get tested on the edge cases. And if you're prepping for an interview specifically, pick a number like CAC & LTV Calculator output and force yourself to defend it against every version of "but what if" you can think of — the exercise matters more than the specific metric.
For hiring managers
If your current process is a take-home exercise plus a stack-trivia round, you're screening for something that expires in eighteen months and skipping the thing that doesn't. Swap one round for a live number, pulled from your own pipeline, defended for ten uninterrupted minutes. If you want a structured version of what you're actually screening for across the role, RevOps Tech Stack Audit Checklist is useful for the opposite reason it sounds — it'll show you how much of what you're currently interviewing for is tool knowledge that any competent hire picks up in week one anyway.
The stack will change again before this candidate's second review. The willingness to sit still under ten minutes of "but why" and answer honestly won't.