We were three weeks into onboarding a GTM engineer before I realized he'd never actually built a data pipeline in his life. He talked fluently about "systems thinking" and had a portfolio full of dashboards someone else had wired up. What caught it wasn't the interview. It was a take-home assignment I almost skipped because I didn't want to slow down the hire.
GTM engineer job postings are up roughly 200% year over year, and most founders hiring for the role are doing it for the first time, with no internal technical hire on the team to sanity-check the candidate. Recruiters know this, and the good talkers know it too. Here's the interview process I wish I'd run the first time, built from the mistake and from talking to a dozen other founders who've since made the same one.
The three questions that separate a builder from a talker
Skip the resume walkthrough. Ask these three instead, in order, and listen for specifics, not frameworks:
"Tell me about the last process you built from scratch, end to end." A real GTM engineer names the tools, the exact data fields, and the failure they hit halfway through. A talker describes an outcome ("we increased pipeline 40%") with no system underneath it.
"Walk me through how you'd diagnose why our email reply rate dropped 30% last month." You want a sequence: check sender reputation and deliverability first, then list quality, then messaging, then timing, in that order. If they jump straight to "let's rewrite the copy," they're a copywriter with a technical vocabulary, not a GTM engineer.
"If I handed you a database with our product usage, CRM, and marketing data right now, what's the first query you'd run?" There's no single right answer, but there is a wrong one: silence, or a request for someone else to "pull the data" for them first. The whole point of the role is that they don't wait for a data team that doesn't exist yet.
The answer that should end the interview: "I export a CSV and clean it in Excel"
Ask how they'd keep your CRM, product usage, and outbound tool in sync. If the answer involves a person manually exporting and re-uploading a spreadsheet on any kind of recurring basis, that's not a lightweight starting point, it's the whole job going undone. A real GTM engineer builds a persistent pipe, even a scrappy one, because manual imports break the moment your data volume or your headcount doubles. The candidate who reaches for Excel first isn't being pragmatic, they're telling you they've never had to make a system survive scale.
The deliverability test almost every founder skips
This is the one that almost got us blacklisted. Ask the candidate to explain SPF, DKIM, and DMARC from memory, no Googling. You are not testing whether they can configure DNS records live in the interview. You're testing whether they've ever been responsible for a sending domain's reputation, because someone who hasn't will suggest blasting a thousand cold emails a day from your primary company domain without mentioning inbox rotation or subdomain isolation. That single mistake can get your entire domain blacklisted, including your billing emails and your password resets, and it can take months to recover sender reputation once it happens. If they can't explain the three protocols, or worse, don't think to ask about your domain health before proposing volume, that's disqualifying, not a minor gap to train around.
Can they define your ICP from your website in five minutes?
Send them your homepage and pricing page the day before the interview and ask them to define your ideal customer profile cold, in the room, in under five minutes. A GTM engineer who can't do this is going to build targeting logic that's too broad, and broad targeting is what tanks reply rates and burns domain reputation before you've even measured whether the channel works. This isn't a strategy test, it's a proxy for whether they read before they build, which is the habit that separates a good hire from an expensive one.
Give a real take-home, not a whiteboard exercise
Hand them an anonymized export: a slice of CRM records, a product usage log, and a marketing spreadsheet, and give them 48 hours to find one thing worth fixing and show their work. Watch for tunnel vision, a candidate who recommends a single channel without weighing alternatives. Watch for shiny object syndrome, someone who name-drops the newest tool without explaining why it beats what you already have. And watch for a total absence of commercial framing, an answer that's technically clean but never connects back to pipeline, revenue, or deal velocity. The strongest take-homes we've seen read like a memo to a founder, not a script to an engineer.
What we do differently now
Three-question phone screen, then the take-home, then a reference check focused on one specific, measurable system that candidate actually shipped, not a general "were they good to work with" call. We reject automatically on the CSV answer, on failing to explain SPF, DKIM, or DMARC, and on taking longer than five minutes to sketch our ICP. Everything else is a judgment call. The role is too new, and too easy to fake with the right vocabulary, to hire it on vibes and a portfolio deck. The system you're hiring them to build is the same kind of system you should be using to hire them.