How to define, interview for, and evaluate AI-fluent RevOps talent across the analyst-to-VP ladder, plus the role everyone keeps asking about: the GTM Engineer.
This is part three of our series on hiring AI-Native GTM talent. Read our general rubric for GTM here, and our in-depth guide to hiring AI-Native Sales Talent here.
The RevOps role has changed. The job description hasn’t.
Lauren Hughes joined Justworks about a year and a half ago to run Revenue Effectiveness, a brand-new function her boss had the vision to create by pulling RevOps and Enablement under one roof. She walked in and started looking at the team she'd inherited.
What she found were roles that made complete sense for how RevOps had always worked: instructional designers, classroom trainers, LMS administrators, project managers, operators running around taking tickets. Helpful people doing helpful things, but largely reactive. Also largely not what the next two years were going to require.
She rebuilt. About 75% of her team is now new or in a different seat. The roles she retired aren't coming back. The roles she stood up barely existed 18 months ago: four GTM Engineers with a fifth open, two AI Enablement leads, RevOps business partners paired with technical builders.
And this isn't a story about one bold leader getting ahead of the curve. It's a data point about where the curve is.
Bri Doyle runs RevOps recruiting at Captivate and sees the demand side of this across every search. What she's watched over the last 12 to 18 months isn't just more RevOps hiring. It's a different profile. Founders and GTM leaders moving away from admin and reporting-focused operators toward technical systems builders, asking which workflows can be automated, where AI agents fit, and how many people they actually need. The profile has shifted, but the job descriptions haven’t fully caught up yet.
So what does AI-native mean in RevOps, specifically? Across GTM, this remains one of the most poorly defined requirements in hiring. Everyone agrees it matters. Almost nobody can articulate what it actually looks like.
The cost of an undefined bar is real. You hire someone who can talk about AI but hasn't built anything. You screen out the operator who's been building for two years and doesn't know how to sell it. You over-index on AI fluency and miss that the foundation underneath is shaky.
This guide is our answer for RevOps, built from conversations with six operators who are living inside this transformation, and what our team is seeing across hundreds of searches:
- Lauren Hughes (VP Revenue Effectiveness, Justworks)
- Jen Igartua (CEO, Go Nimbly)
- Yezi Peng (VP Strategy and Ops, Glean)
- Elio Narciso (Co-Founder and CEO, Scalestack)
- Andy Mowat (Co-Founder, Whispered)
- Bri Doyle (Head of RevOps Recruiting, Captivate Talent)
What follows is a framework, not a prescription. The goal is to give you something you can actually use to navigate these decisions and thinking about building your RevOps org.
Why the stakes are higher here than anywhere else in GTM
Every function is dealing with AI right now. Sales, Marketing, Customer Success, each has its own version of the conversation. RevOps is different, and it’s important to understand exactly why the stakes are so high.
An AI-native RevOps hire isn't someone who uses AI to do their own job faster. They build the system everyone else runs on.
RevOps has historically been a function that could only influence, not act. Yezi Peng put the old constraint plainly: RevOps couldn't close a deal or source an opportunity on its own. It had to work through policy, through tooling, through convincing other people to do the thing. That was the ceiling.
But that’s changing quickly. At Glean, Yezi's team started asking whether RevOps could run outbound at scale using Clay and Claude, actually generating pipeline rather than influencing the people who generate it. They're building outbound campaigns through their GTM Engineer and working out how to even credit it. A RevOps-sourced pipeline bucket is the direction they're moving toward.
Individual AI gains are real and worth acknowledging. Every AE wiring their own research workflow. Every SDR using AI to personalize at volume. Those gains add up. But Yezi names the limit:
What sits above that ceiling is what you might call organizational intelligence. Sit at the altitude where you can see what the best reps are actually doing, codify it, and build it into workflows everyone uses. Scattered individual hacks become something the whole org inherits. That move, from personal productivity to shared infrastructure, is what a RevOps leader is positioned to make. Nobody else in the org has the vantage point.
Lauren describes her team as "the front door for the go-to-market organization in terms of AI and AI literacy, AI transformation." She means it practically. Her team was on Claude early, before the enterprise account was ready, because they bought it themselves and got moving. They ran lunch-and-learns where the GTM Engineers brought what they learned in outside forums and taught the broader team. Then they pushed adoption outward, to the outbound team, to AEs, to customer success, even to the people team.
The stakes are asymmetric. A great seller who underuses AI costs one quota. A RevOps hire who can't build the foundation leaves the whole org stuck at individual hacks, because there's no one turning those hacks into something durable.
Elio Narciso has watched the pattern play out across the companies he works with: teams rushing to automate the frontline, outbound, content, the AI SDR, and leaving the foundational data layer untouched. The CRM is still full of bad data. The campaigns run, the token spend climbs, and conversion doesn't move, because nothing underneath got fixed.
That's the cost of getting this hire wrong. It's not one missed number. It's a whole org spending money to stay in place.
AI fluency is the accelerant. Functional craft still decides the hire.
The fundamentals haven't changed as much as the noise suggests, and if anything, they matter more.
Systems architecture, data governance, process design, cross-functional alignment, revenue analytics. These were the things that made someone a good RevOps hire before AI existed. They still decide the hire.
The one that gets underestimated is empathy. Elio makes the case that RevOps serves Sales and Marketing. There are far more people in those functions than in ops, which means without credibility, you drown in tickets. In his words:
He also flags something that goes against the instinct most hiring managers have. He's more impressed by the candidate who made a constrained system work than the one who swapped to a better tool and called it a win. "We had Dynamics, it was limiting, so I moved to Salesforce" is less interesting than building something functional around Dynamics' deficiencies and moving the metric anyway. Constraints push good operators to invent. The escape hatch of a new tool doesn't.
This matters now more than ever, because the shortcut is more tempting than ever.
The companies you see on conference stages talking about impressive AI workflows? They’re still doing the unglamorous work behind the scenes: Clean data. Scalable integrations. Documentation that any agentic system can actually reference. Jen Igartua, CEO of Go Nimbly, whose firm works inside some of the most sophisticated RevOps teams in the market sees this happening behind the scenes every day.
She also sees what happens when you skip it: there's an initial high, and then a crash.
You hire someone who can build, and they deliver. Data gets normalized, reps get prep emails before meetings, signals get surfaced. Everyone's excited. Then someone asks which signals are actually working. The answer is: I didn't track that. I'd have to build a model. The high gives way to the realization that you can't keep stacking clever one-offs on a foundation that was never built to hold them.
Match the hire to where you actually are
Before you open a single rubric, take an honest read of where you are. The right hire for a Series A company with messy data is not the right hire for a Series C company with a clean foundation and the budget to build on it.
Think of it as a dial.
At the early end: foundation first. Lauren's advice to early-stage founders is direct. She wouldn't even go out and hire a GTM Engineer. GTM Engineers aren't magicians. They can't build on broken data and undefined process, and you can't GTM-engineer your way to product-market fit. Get the foundation right, then think about who builds on top of it.
At the resourced end, Yezi's framing: distribute the builder spirit, don't silo it. When you have the foundation and the team, you don't want all the building talent locked in one seat. You want the whole RevOps function thinking like builders.
Lauren stresses why it’s so important to be honest about your operating maturity. If you have messy data, undefined processes, and unclear ownership, AI isn't going to fix that.
It'll make it worse, honestly.
Where you land on that dial shapes everything that follows. So before you even get into reading about the roles, be honest about where you are.
The role-by-role framework
For each role: a short read on what's changed, what the job looks like now, the three-tier rubric, green flags, red flags, and interview questions.
The three tiers are the same across this series.
- AI-Curious (Baseline): aware of the tools, uses them occasionally, not woven into how they work.
- AI-Active (Adoptive): regular, intentional use that improves output and speed.
- AI-Native (Transformative): AI is embedded in how they work and build. Not a tool they reach for, the mode they operate in.
How to hire an AI-Native RevOps Analyst
Despite all the noise of AI replacing entry-level - the analyst/associate jobs haven’t entirely disappeared – they’ve just changed more than most others.
The work that used to define it, pulling reports, reconciling data, documenting processes, prepping analysis by hand, is exactly the work AI now does fastest. Bri recently saw a company consider a commissions analyst hire and decide to automate most of the work instead. The role isn't vanishing, but the bar to do it is rising, and the pipeline of who is good at it has widened.
This is also where the bar counterintuitively might be highest, which catches most founders off guard. Andy's framing is the provocation:
His logic is operational: the gathering and documentation work is what AI absorbs first, so the analyst who isn't automating their own workflow is the most exposed person on the team.
The strongest analysts Bri places already feel this. They use AI to accelerate research, write SQL, and generate first-pass analysis, which frees them to do the part that still needs a person: deciding what the numbers mean and what to do about them.
The profile widened, too. The standout analyst Bri placed recently didn't come from a SaaS background at all. She had been building on her own, teaching herself tools out of curiosity, and came into the screening call with sharper questions than candidates with better credentials. The tell at this level is curiosity and self-direction. As Bri hears it from hiring managers again and again: if a candidate isn't doing it at work, what are they doing on their own?
What the job looks like now: Less time producing information, more time validating it and deciding what to do with it. Automating the gathering so the hours go to interpretation, then bringing a point of view to stakeholders instead of just handing over the numbers.
Green flags:
- Talks in workflows and outcomes, not tool names
- Can walk through a specific thing they automated and what it changed
- Came from an unexpected background and is stronger for it
- Asks sharp questions in the interview, not just answers
- Has a story of building something on their own time
Red flags:
- "I use ChatGPT every day" with nothing behind it
- Experience described as a list of tasks owned, not problems solved
- Analysis stops at the output, never pushes toward "so what"
- No evidence of curiosity or building outside assigned work
Interview questions:
- Walk me through a recurring task you automated. What did you build, what did you use, and what would you do differently now?
- Tell me about something you figured out on your own in the last six months. What pushed you to dig into it?
- You've been given a dataset and 90 minutes. Walk me through how you'd approach it.
- What's the last AI tool or technique you tried that didn't work the way you expected? What happened?
- What are you building or experimenting with outside your current role?
How to hire an AI-Native RevOps Manager
The Manager level is where the job description has arguably changed most visibly. It used to mean owning a process or a system. Now it means building the solution, not just specifying it.
Yezi frames it as a move from buyers to builders:
The profile she used to love, and hired plenty of, was the ex-banker or ex-consultant: the sharp analytical generalist who could build a beautiful deck and hold a room. The profile she looks for now thinks like a product manager. Problems first, not tools first. Jobs to be done. What is the actual pain across GTM, and what's the right thing to build to solve it, rather than starting from a standard tech stack and retrofitting problems to the tools you happened to buy.
Glean runs an AI fluency component in every interview, role-specific, and for RevOps that means real questions: walk me through a workflow you automated, how did you build it, what did you use, why those tools and not others? The point is to get past the hypothetical. Plenty of people can describe what they'd love to build. Yezi wants to know what they've actually built with the tools in front of them.
The failure mode at this level has two names:
- Yezi's test for it is a single follow-up: okay, you built something, what outcome did you actually change? If they can't answer, the build was decoration.
- Jen calls the downstream version "random acts of AI": a junior builder who can generate a slick data point or a pre-meeting research email, and then suddenly you have 30 Clay tables, 13 agents, and a Zapier sprawl that does a mediocre version of a workflow and breaks the moment you run it at scale.
The Manager is supposed to be the check on these impulses, not be the one enabling it.
What the job looks like now: Owning a process or system area and building the solutions, not just specifying and buying them. Thinking in jobs-to-be-done. Able to explain not just what they built but why, and what it changed. Holding the line on scalability when the temptation is to ship something clever and fragile.
Green flags:
- Leads with the problem before the tool
- Can defend tool choices under follow-up ("why Clay and not n8n?")
- Talks about what an automation changed, in numbers
- Has a point of view on when to build versus buy versus configure
- Thinks in scalable systems, not one-off cleverness
Red flags:
- Cool workflows with no outcome attached
- Every answer is about the tool, not the problem
- Can't say why they chose one tool over another
- Hypothetical fluency without real examples behind it
- Random acts of AI with nothing connecting them
Interview questions:
- Walk me through a workflow you built recently. What was the problem, what did you build, and what did you choose not to build?
- Tell me about something you built that looked great and didn't work. How did you know, and what did you do?
- Tell me about a time you had to explain a technical decision to a sales or marketing stakeholder. How did you frame it?
- You have unlimited AI budget and engineering support. What's the number one GTM pain you'd go solve, and how would you know if it worked?
- Tell me about a build that required a real design decision. What were you choosing between?
How to hire an AI-Native director of RevOps
At this level you're hiring judgment. The person sets direction for the function, works across the org, and increasingly has to be technical enough to lead a team that builds.
What that actually means in practice is worth spelling out. Jen puts it directly: if a leader candidate is talking only about the cool workflows they've built, and not about architecture, clean data, documentation, that's a red flag.
Those aren't the boring parts of the job. They're the job. The workflows are downstream of a well-designed system. A Director who can't articulate the foundation isn't ready to own the function.
The other thing you're hiring for is outcome-mindedness, and the connection between these two things matters. The trap a weaker leader walks into is easy to narrate. The board says get AI adoption up. So the leader gets everyone Claude, and three months later produces a chart showing 98% of the team is using it.
The recovery move is what separates an effective leader. They hear "get adoption up" and they ask why. What are the gaps, what are the problems, where can this actually be pointed? Then they come back with: here are the three places I'm putting AI because they roll up to conversion rate, to deal velocity, to retention. They translate a vague mandate into outcomes. They can tell that story upward to a board asking for "AI" without knowing what it means.
None of that works, though, without credibility with the people you serve. Elio talks about this as the thing that most often gets overlooked. You need strategy, systems, data. But without empathy for Sales, specifically, the currency you need to actually influence the org, none of the rest lands. What he's watched happen when RevOps leaders don't have it: sales stops engaging strategically and starts filing tickets. Everything becomes friction.
The relationship that should make the function powerful becomes the reason it can't get anything done. His read is that a RevOps leader who has spent real time in the trenches with salespeople, not just in org charts above them, is meaningfully better equipped than one who hasn't.
That matters most at this seat. This is the person sitting across from the CRO. The architecture, the AI roadmap, the systems investment, all of it requires buy-in from GTM to work. A Director who has that credibility can say: I heard you, I know it's a priority, here's where it fits. One who doesn't gets a queue of tickets.
The red flag Lauren saw most vividly at this level: not keeping up. She was interviewing for an outbound pipeline leadership role and walked the candidate through her team's vision for an always-on prospecting engine. She mentioned that Salesforce had just rolled out a major capability with a ZoomInfo integration the week before.
The candidate looked at her like she had four eyes. For a leadership role in outbound pipeline generation, not knowing about a major launch in your own domain is, in Lauren's word, alarming.
What the job looks like now: Setting direction for a function that's building, not just buying. Translating vague AI mandates into outcomes that roll up to revenue. Carrying credibility with sales leadership so the team gets pulled in, not routed around. Staying current enough that nothing major in their own domain is news to them.
Green flags:
- Reframes an adoption ask into outcomes that roll up to revenue
- Technical enough to lead a build and defend the tradeoffs
- Visibly credible with sales leadership
- Caught up on the latest moves in their domain without prompting
- Talks about the boring infrastructure as readily as the cool workflows
Red flags:
- Treats adoption as the goal, not the means
- Leans on "I'm business-minded" to dodge the technical bar
- No real credibility with the revenue team
- Surprised by a major development in their own area
- All vision, no foundation
Interview questions:
- Your board says "get AI adoption up." Walk me through what you actually do next.
- Tell me about a time you were asked to show AI adoption. How did you frame it, and what did you actually measure?
- Walk me through a technical decision you made in the last year. What were the tradeoffs?
- Tell me about an initiative you killed or paused because the foundation wasn't ready.
- What changed in our space in the last month that you're paying attention to, and why?
How to hire an AI-Native VP of RevOps
This is the highest strategic and architectural bar, and the seat where you're buying a view of where the whole function is going.
Lauren has the clearest picture of where it's going, because she's building toward it.
The future org thins in the middle. Lauren's reasoning is structural: AI compresses organizational layers because coordination can finally scale. When AI handles documentation, analysis, task orientation, QA support, and workflow execution, you need fewer people whose job was to coordinate other people.
What replaces that middle is a pairing she keeps coming back to: a senior strategic architect who works cross-functionally and moves fast, set next to a highly technical builder. Business context next to build capability, with the coordination layer between them mostly gone.
The career path changes with it. It stops being time-served. In Lauren's words, it's going to be a lot less ten-year-based going forward. What replaces it looks more like an engineering progression. First, demonstrate you can technically build. Then, demonstrate cross-functional understanding, how your part of the revenue factory connects to everyone else's. Then, demonstrate you can think bigger-picture and design forward. You advance by clearing capability bars, not by waiting.
Build versus buy becomes strategy at this altitude. Jen's strongest advice for a leader in this seat: build your own intelligence wherever it can become a competitive advantage. Your unique data, the way you go to market, how you talk about your product. She won't let clients ship the out-of-the-box AI email features from their existing tools, because that output just looks like everyone else's. The judgment of what to build for advantage and what to buy for convenience belongs to the VP.
What the job looks like now: Designing the revenue architecture and the org around it. Pairing senior strategic operators with technical builders and thinning the coordination layer between them. Making build-versus-buy a strategic call that protects competitive advantage. Setting a skills-based path for the team. Timing scaling roles like AI Enablement to the actual stage.
Green flags:
- Has a thesis about what the org looks like in three years, grounded in something real
- Talks about what the team is building, not just what tools they're using
- Has made a bet something not everyone was doing yet, and can explain the reasoning
- Treats build-vs-buy as a strategic question, not a procurement one
Red flags:
- Great AI adoption story with no revenue outcome attached
- Managing up to the trend without a thesis underneath
- Ten years in RevOps and the model looks exactly like RevOps ten years ago
- Has never made a build decision, only buy decisions
Interview questions:
- Tell me what you think RevOps looks like in three years. What roles exist that don't today? What roles go away?
- Walk me through the hardest architectural decision you've made. What were you choosing between, and how did you decide?
- Tell me about a bet you made that most people in your position weren't making yet. What did you see that others didn't?
- How do you think about what to build versus what to buy? Give me a real example.
- Tell me about a time the org design you had wasn't the right one. How did you know, and what did you do?
The GTM Engineer: What It Is, Where It Came From, and Whether You Actually Need One
In June last year, Bri went through LinkedIn and tracked how many people actually had the title "GTM Engineer" or "Go-to-Market Engineer."
286.
That's it. In a market where the conversation about this role is everywhere, the talent pool is barely two hundred people deep. And of those two hundred, the practitioners who've hired them have varying definitions on what the role actually is.
Lauren Hughes has hired four of them at Justworks. Her read: "The title spread faster than the capability." The market saw a real problem. GTM teams were too slow, too manual, too dependent on human intervention in steps that should run themselves.
The demand for someone who could fix that spiked fast. And in the absence of a clear definition, everyone reached for the trendiest title available.
Growth hacker with a different name, basically. Lauren's heard the comparison. She doesn't fully disagree.
So what is a GTM Engineer?
In Lauren's version, a GTM Engineer sits at the intersection of revenue strategy, systems architecture, automation, data, and AI. The key tell is sequencing: they ask what before they ask how. They're not maintaining the machine. They're redesigning it.
Jen has a more skeptical take. These are technologists. They know how to pull a Clay table. That's not the same thing as having go-to-market expertise. And "GTM Engineer" has, in a lot of cases, become shorthand for "Clay expert," which is a tool skill, not a function.
Her concern with a GTM Engineer floating independently in an org is concrete, not theoretical. Without RevOps structure around them, they build in a silo. You end up with 30 Clay tables, 13 agents, a Zapier zap nobody can explain, and a bunch of cool individual things that break the moment you try to run them at scale. She calls it random acts of AI. The work looks impressive. The infrastructure isn't there to support it.
Her position: GTM Engineers belong embedded in RevOps, not floating independently. The function needs to own them, or you lose the cross-functional integration that makes the work stick.
Lauren doesn't disagree that the title covers two very different jobs. Her diagnostic is simple: are you trying to maintain existing infrastructure, or invent a new capability? Maintenance is an administrator, maybe one with strong tool skills. Invention is a GTM Engineer.
If the pain is bad Salesforce hygiene and broken routing rules, you probably need a strong RevOps administrator. If the pain is that you have data everywhere and you're not doing anything with it, that you want signal-based workflows, that you want to remove human intervention from a step entirely, you might be in GTM Engineer territory.
She'd also say: sequence matters. A GTM Engineer is a force multiplier. Which means you need something to multiply. Clean data, a defined ICP, systems that are actually stood up. When those aren't there yet, the builder you hire runs out of runway fast.
What we see in practice
Bri has hired for multiple GTM Engineering roles across different types of companies, and sees what founders ask for and what they actually need, and the gap is consistent.
When a founder says they need a GTM Engineer, it usually means one of two things. Either they need foundational RevOps first (clean data, clear ownership, basic system discipline) and the GTM Engineer comes later once there's something to build on. Or they're describing an actual engineering role, something closer to product or technical growth, that happens to touch go-to-market. Those are different jobs with different profiles and different comp bands.
When a founder says they need a Director of RevOps, it often means they actually need a hands-on IC builder. There's no team yet. The Director title is aspirational. The real work is building.
Here’s how it played out across five real searches (all anonymized):
A: "GTM Engineer" was actually a pure technical growth engineer. The founder was describing a coder and systems builder closer to product than RevOps.
B: "GTM Engineer" was actually a RevOps-grounded hybrid. A prior tool-first hire had failed. The real need was a senior IC who owns the full ops function first, GTM engineering second.
C: "GTM Engineer / Systems Admin" was actually a core Sales Ops and Marketing Ops reset. The CFO wanted the shiny title. The function needed stabilization, with GTM engineering sequenced to later or handled on contract.
D: "Director of RevOps" was actually an IC builder. The work described was wireframe, build, and automate in HubSpot. Explicitly individual contributor work, regardless of what the title said.
E: "GTM Systems leader now" vs. "RevOps manager later." The 40→250 scale-up had two different humans hiding in one req; naming the split kept the search focused.
The pattern across all five: founders reach for the title that sounds right, either the one that's having a moment or the one that sounds senior enough. The real need gets surfaced by two questions:
- How mature is your ops foundation?
- Does this hire need to build, or manage what's already been built?
Getting those two questions answered first is what makes the search work. It's also what keeps you from hiring twice.
What RevOps Really Pays: Ranges, Caveats, and What Drives the Variance
A few things to know before you read these numbers.
These ranges come from our actual search data, and they skew toward what we see in Tier 1 markets: San Francisco, New York. They represent the higher end of the market, because that's who we work with. If you're hiring in Austin, Denver, or remotely, adjust down. If you're Series A and offering equity, the cash comp picture looks different too.
One more thing: bonuses show up about 50% of the time at the Analyst and Manager levels. When they do, ranges vary widely. We're calling that out because a number without context is worse than no number at all.
These should just be a helpful direction, not gospel:
Analyst / Sr. Analyst
$90,000-$120,000 base
Manager / Sr. Manager
$130,000-$180,000 base + bonus
Director / Sr. Director
$170,000-$225,000 base + bonus
VP of RevOps
$250,000-$350,000 base + 20-40% bonus + equity. We've seen base go to $400,000 at the high end. These are generally Series B and later.
GTM Engineer
This one has the most variance of any role we cover. Bloomberry's analysis of 1,000+ postings found a median of approximately $127,500. Clay's job board, which skews toward AI-native companies building at that level, shows closer to $160,000.
Mid-range ICs through senior/lead typically land between $130,000-$170,000 base, with senior and lead roles reaching $170,000-$220,000+.
Seed and Series A companies often trade lower cash for larger equity; Series B+ companies pay a premium for strong automation, SQL/Python, and AI implementation depth.
At the extreme end, we've talked to companies with essentially unlimited budget for the right profile... but those searches come with equally extreme requirements.
How to interview RevOps candidates
Andy Mowat said something that doesn't get repeated enough: most of the people interviewing for these roles don't have the fluency themselves.
That's not an indictment. It's a practical problem with a practical answer: you compensate by going deep.
Go deep, not wide. Yezi's principle: you learn a lot more in an interview by going deep on specific things someone has done than on hypotheticals. Past work over hypotheticals, always. Don't ask what they would do. Ask what they did.
Elio's bar-raiser method adds the technique: ask the question, get the answer, then ask a question about the answer. Why that way and not another? What would you change? What would you do differently now? Don't accept the first layer. His signal for a strong candidate: they tell him something he didn't know. If he can go deeper and the detail holds up, they owned it.
Case studies: let them prep with AI, then pressure-test live. Lauren has seen candidates come in with polished Gamma slides and fall apart the moment she asks a follow-up. The exercise was outsourced to AI and they didn't actually understand the output. What she actually wants is the opposite: use AI on the data analysis, then bring your own design of the solution. The slides can look perfect. Walk me through why you'd use Clay instead of n8n in this context. That's where you find out whether they know what they're talking about.
Andy's framing on the time-box: "A good person does it with AI in two hours. A bad one in 40, and I'm not going to know the difference." So time-box it, constrain the scope, and add a live pressure-test. Banning prep time so candidates can't use AI is backwards. Using AI is the job.
Bri's addition: there's still real signal in the live component. The ability to explain thinking in real time, defend tradeoffs, adapt when pushed, that's the part AI can't fake.
Remove the constraints. Yezi's favorite question: if you had unlimited AI budget, what's the number one GTM pain point you're dying to solve? The answer tells you whether they have a real perspective on what they'd build, or just what they've been allowed to build.
Keep the process tight. Bri's guidance: three to five rounds for IC and Manager-level roles, four to six for Director and VP. Every interview has a distinct purpose and a distinct evaluator. RevOps bloats this process worst because the function touches every team. Sales wants to meet them. Marketing wants to meet them. Finance wants to meet them. Customer Success wants to meet them. Cross-functional buy-in matters, but adding every stakeholder to the process is how you end up with six or seven rounds and a candidate who accepted somewhere else.
Values and mindset. Lauren is clear that curiosity is non-negotiable. She scrolls Instagram learning about Claude launches. Her team is on TikTok learning the same things. You have to be looking outside as much as you're looking inside. The candidate who didn't know about a major platform rollout directly relevant to their own domain isn't just behind. They weren't looking.
Before you start hiring
Bri's root cause for most RevOps hiring mistakes: founders spend too much time on the title and not enough on the problem.
What are you actually trying to solve? Where does it hurt? Is it a data and systems foundation problem, or an automation and build problem? Is the work building something new, or maintaining what exists? Is this an IC role or a leadership role, and be honest about that distinction, because they often aren't the same thing at the stage you're at.
Lauren's checklist for early-stage founders: define the problem. Understand whether you need maintenance or invention. Be honest about your operating maturity. If the data is messy, the processes undefined, the ownership unclear, you're not ready for a GTM Engineer. Get the foundation right first. GTM Engineers are not problem-solvers for a problem you haven't named.
The conviction we hold at Captivate: the hardest part isn't the rubric. It's the honesty. Most founders know they want an AI-native RevOps hire. Fewer have defined what they actually need. We'd rather spend 20 minutes grinding through the real problem with you than fill a seat with someone who looks right on paper and doesn't fit the moment you're in.
Download all four role-by-role scorecards here (no email required)
