GTM engineer interview questions | From both sides of the table

Say "242 opportunities" in a GTM engineer interview and the very next question will be: how many of those became meetings?

If you don't know, the interview is over. You just won't find out why until the rejection email.

I've been on both sides of this table: interviewing for roles, and helping founders work out who to hire. And I've watched good people lose interviews they should have won, because nobody told them what the questions were really testing.

This is the list of GTM engineer interview questions that actually decide the outcome, what a strong answer sounds like, and the mistakes that cost people the job.

The question that matters most

"Tell me about a campaign that broke. What did you check first?"

If you remember one thing from this post, remember this question. It separates people who have built systems from people who have watched tutorials.

A weak answer: "We rewrote the copy and it worked better."

A strong answer: "5,000 emails, 17 replies, zero interested. Bounce rate was fine and inbox placement was fine, so it wasn't infrastructure. Then I looked at the out-of-office replies: over 100 of them. We'd launched into the US summer holidays and the decision makers weren't at their desks. Next time I'd run a 200-email test first and stop if out-of-office replies passed 2%."

That's a real campaign of mine, and it's the story I'd tell in this question.

The strong answer has an order. It shows you didn't guess. You checked things in a sequence, ruled things out, and found the real cause.

How to prepare: Write down one real failure from your own work, the order you checked things in, and what you changed. If you don't have a failure yet, you haven't built enough. Go build something and break it.

I keep a full version of my diagnostic order in why cold email lands in spam. Learn the order. It's the most useful thing you can bring into an interview.

Questions about your numbers

"What do your numbers actually mean?"

This is the one that ends the most interviews early.

Every number you mention, they'll ask about the next stage down. Know the whole funnel:

The best answer explains the gaps. "The drop from 107 positives to 75 meetings was follow-up speed. Replies that waited more than a few hours converted much worse." That one sentence tells them you understand the system, not just the dashboard.

"What's a good reply rate?"

A trap if you answer with one number.

Strong answer: "It depends on deal size and market. A 0.47% reply rate into a market with $10,000 deals can be worth more than 5% into a market with $500 deals. I'd judge on positive replies and pipeline, not raw replies." That's a real example from my own work: 0.47% reply rate, $324,000 in pipeline.

Questions about building

"How would you build a list for our company?"

They want to see you think before you build.

Strong answer structure:

1. Who exactly buys this, in one specific sentence. Not "B2B SaaS companies"
2. What signal tells you they need it now
3. Where you'd source the data
4. How you'd keep credit costs down: cheap filters first, expensive enrichment only on the companies that pass
5. How you'd verify emails before sending

Research their product before the interview so you can answer for their market. Generic answers lose to specific ones every time.

"Walk me through a Clay table you built."

Often done live on a screen share. Don't panic. They want to hear your reasoning.

Explain each column, why it's in that order, where it costs credits, and one thing that went wrong. Say "I don't know, but here's how I'd find out" if you hit something you don't know. That's a strong answer, not a weak one.

Never list a tool on your CV you can't demonstrate live. If they ask you to share your screen and you freeze, the CV has already lied for you.

Questions about deliverability

"How do you keep emails out of spam?"

What they want to hear: separate sending domains, never the main company domain; SPF, DKIM and DMARC set up and checked; warmup for three weeks or more; low volume per inbox to start, around 15 a day and rising slowly; verified lists with bounce under 2%; and checking inbox placement rather than trusting open rates.

Bonus points for knowing that a lot of B2B companies are on Microsoft, not Google, and that matters for where your emails land.

The question most candidates don't expect

"What would you refuse to build?"

This catches people off guard. They expect to be asked what they can do, not what they wouldn't.

Strong answer: "If your total market is 2,000 companies, I wouldn't build infrastructure for 100,000 emails a month. You'd burn through your whole market in a few weeks. I'd tell you cold email at that volume is the wrong plan."

Knowing when not to build is rarer than knowing how to build anything. It shows judgement, and judgement is what senior people are paid for.

Questions you should ask them

An interview goes both ways. Ask:

• "What broke last time someone tried to do this role?" Their answer tells you what they're worried about
• "How will you measure success in the first 90 days?"
• "Do I own the system end to end, or one part of it?"
• "What tools and access will I have on day one?"

That last question matters more than people realise. If you'll have to ask permission for every tool, every key and every credit, find out before you accept.

What interviewers are really testing

Underneath every question, they're trying to answer one thing: can this person build a system that keeps working when something goes wrong?

Tools are a month of learning. Judgement is years of breaking things. Your job in an interview is to show the judgement, using real examples from things you actually built.

If you don't have those examples yet, that's your next step. Not more interview practice. More building.

I wrote more about the hiring side in how to hire a GTM engineer. It's worth reading before an interview, because it's written for the person interviewing you.

Have an interview coming up?

If you've got a GTM engineer interview coming up and you want to practise your answers, or you're not sure how to explain something you built, message me on WhatsApp.

Tell me the role and what you've built. I'll help you work out how to tell your story so it lands.