Ask a GTM engineer candidate “how do you warm up a domain?” and you will get a fluent answer. Everyone has read the same ten LinkedIn posts. What you cannot hear in that answer is whether they can size an inbox pool against a complaint ceiling, whether they know what a bounce rate is supposed to look like before a sequence ships, or whether their reply routing survives contact with a real CRM. Hand them a Smartlead sending build instead — domains, warmup ramp, inbox rotation, suppression, HubSpot reply routing — and grade the artifact against the numbers mailbox providers now enforce. The exercise takes a candidate 90 minutes and tells you more than four interviews.
Knowledge questions fail because the ground moved
The reason verbal screens stopped working is that cold-email competence is now arithmetic, not opinion. Google tells senders to hold Postmaster Tools spam rates below 0.10% and never to reach 0.30%. Outlook requires full SPF, DKIM and DMARC for any domain sending more than 5,000 emails a day, with failures routed to Junk since 5 May 2025. Validity’s benchmark data puts the tolerated complaint rate at under 0.1%, down from the 0.2–0.3% guidance that senders coasted on for years.
Those three numbers turn “how many inboxes should we run?” into a solvable problem with a defensible answer. A candidate who has internalised them will design backwards from the ceiling. A candidate who has not will give you a volume target and a vibe.
It gets worse specifically where cold outbound lives. The same benchmark report found B2B deliverability degraded in 2025: average inbox placement at hosting platforms fell 1.3%, and at filtering companies it fell 5.8%. Corporate filters are the exact environment your sequences are trying to reach. A build that works against consumer Gmail and dies against a corporate filter is a build that looks fine in Smartlead’s dashboard and produces nothing in pipeline.
The sending system is the variable you are hiring against — not the rep, not the copy.
That is not a rhetorical flourish. The Bridge Group’s research puts the global median for converted meetings at 6 per month, down 43% since 2018. Per-rep output has been falling for seven years. If you are still hiring outbound headcount to fix outbound, you are buying the wrong input. The leverage is in whoever designs the sending infrastructure — which is the whole case for hiring a GTM engineer rather than another SDR cohort.
The brief you hand the candidate
Keep it concrete and bounded. Give them a scenario, a constraint and a deliverable format, then get out of the way.
Scenario. You are launching outbound into mid-market SaaS. Target list is 12,000 verified contacts, roughly 60% on Google Workspace and 40% on Microsoft 365. The company’s primary domain must not be put at risk. Budget allows for sending domains and inboxes; the exact count is your call. Sequence is four steps over 18 days.
Deliverable. A one-page build plan plus a Smartlead configuration you can walk through, covering:
- Sending domain strategy — how many, how named, how they relate to the brand domain
- SPF, DKIM and DMARC records, with the DMARC policy you’d publish at launch and where you’d move it
- A warmup ramp expressed as sends per inbox per day, week by week
- Inbox rotation logic and total daily capacity, with the arithmetic shown
- Suppression architecture — verification pass, global suppression list, domain-level exclusions, existing customers and open opportunities
- Reply routing into HubSpot — what creates a contact, what creates a task, what gets a lifecycle stage change, and what happens on an out-of-office versus a real reply
- The three metrics they would monitor daily and the number at which they’d pause a campaign
That last bullet is the tell. A strong candidate names thresholds unprompted, because they have paused campaigns before.
The rubric: grade the math, not the vocabulary
Score it out of 100 across six dimensions. Publish the rubric internally before the first candidate sees the brief so your interviewers are not inventing standards mid-review.
| Dimension | Weight | Pass condition | Automatic fail |
|---|---|---|---|
| Authentication | 20 | SPF, DKIM and DMARC specified per sending domain; candidate connects the design to the 5,000/day Outlook threshold | DMARC omitted, or “we’ll add it later” |
| Warmup ramp | 20 | Sends per inbox per day ramps gradually and lands at a sustainable steady state; ramp is written as numbers, not “slowly” | Jumps to full volume inside week one |
| Inbox rotation and capacity | 15 | Total daily sends = inboxes × per-inbox cap, stated explicitly and reconciled against the 12,000-contact list and 18-day window | Capacity never calculated |
| Suppression and bounce control | 20 | Pre-send verification plus layered suppression; names a hard-bounce threshold at or near the 1.46% benchmark | No verification step; no customer/opportunity exclusion |
| Complaint thresholds | 15 | Monitors Postmaster Tools; pause trigger set under 0.10%, never at 0.30% | No complaint metric named |
| HubSpot reply routing | 10 | Distinguishes auto-reply, referral, objection and positive reply; defines CRM object changes and owner assignment | ”Replies go to the rep’s inbox” |
A build scoring 75+ is a hire-track build. Below 55, the candidate is repeating playbook language without having run the system.
Why the bounce line matters
The global average unknown-user rate is 1.46%. That gives you a non-arbitrary pass/fail for the verification and suppression layer. Candidates who have shipped real volume will either cite a figure in that neighbourhood or tell you they hold themselves tighter and explain how. Candidates who have not will say “keep bounces low” and move on. Same words, entirely different depth — and the rubric is what separates them.
Why suppression is an engineering requirement
Ask candidates where unsubscribe handling lives in their architecture. The answer should be a system, not a promise. With the tolerated complaint rate now sitting under 0.1%, a handful of people who already asked to be left alone is enough to move the number on a small inbox pool — one mistargeted segment can burn a domain you spent six weeks warming. A good build shows a global suppression list that writes back from HubSpot so an unsubscribe in one tool is honoured in the other within minutes, plus domain-level exclusions for customers and open opportunities. A weak build treats Smartlead and the CRM as separate universes and hopes nobody notices. Ask what happens when the same person appears on two lists under two addresses; the answer separates people who have cleaned up a mess from people who have only read about one.
What the HubSpot section really tests
Reply routing is the part candidates skim, and it is the part that predicts whether your revenue team will trust the system in month three. The questions underneath it are not about email at all — they are about data modelling.
Does an engaged reply create a contact, or enrich one that already exists? Which object carries the sequence membership? Does a positive reply advance lifecycle stage, create a task for the owner, or both — and who is the owner when the contact has no account mapping yet? What happens when the same person replies from a second address? How does an out-of-office get parsed so it doesn’t fire a meeting-request task at 2am?
A candidate who answers these crisply is the same profile you want anywhere near your CRM, which is why HubSpot-fluent operators and GTM engineers increasingly show up in the same candidate pool. If the role sits closer to lifecycle and attribution than to sending, run the same work-sample discipline through marketing operations instead — the format transfers, only the artifact changes.
Strong build versus weak build
The difference is rarely tooling. It is whether the candidate reasons from constraints.
| Signal | Weak build | Strong build |
|---|---|---|
| Domain plan | One lookalike domain, three inboxes | Multiple sending domains, brand-adjacent naming, primary domain isolated |
| Ramp | ”Warm up for two weeks” | Day-by-day sends per inbox, steady state justified against the 0.10% spam ceiling |
| Capacity | Daily send target set by list size | Capacity derived from inbox count × per-inbox cap, then list size fitted to it |
| Monitoring | Open rate | Postmaster Tools spam rate, hard-bounce rate, reply rate — each with a pause threshold |
| Failure plan | None | Named conditions for pausing, rotating a burned inbox, and re-warming |
| CRM | Replies land in a shared inbox | Typed reply handling with defined HubSpot object changes and owner logic |
Notice that nothing in the right-hand column requires a tool you don’t already own. It requires someone who thinks in thresholds.
Running the exercise without losing candidates
Work samples fail when they are unpaid, open-ended or secretly a free consulting engagement. Three rules keep yours clean.
Cap it at 90 minutes and say so. A one-page plan plus a configuration walkthrough is enough. If you need a 10-hour build to make a decision, your rubric is the problem.
Use a generic scenario, not your actual account list. It removes any suspicion that you are harvesting work, and it makes builds comparable across candidates.
Grade it live. Thirty minutes of the candidate walking you through their arithmetic surfaces more than any written submission. Ask them to defend one number — the per-inbox daily cap is the best one — and listen for whether they reason from the complaint ceiling or from habit.
Top-tier GTM engineers are happy to do this. The exercise is the closest thing to their actual job that an interview loop ever produces, and the candidates who resist it tend to be the ones the rubric would have caught anyway. Teams running a rubric-graded work sample reach a decision in days, not weeks, because there is nothing left to debate after the score.
Where this fits in the loop
Run the work sample second — after a 30-minute screen, before any panel. It replaces the technical interview rather than adding to it. If the build scores well, your panel can spend its time on scope, collaboration and how the candidate handles being told no by a security team, instead of re-litigating whether they know what DKIM stands for.
For the rest of the loop structure — scorecards, compensation bands, and how the GTM engineer role should be scoped against RevOps and demand gen — the GTM engineer hiring guide covers it, and salary benchmarks will tell you whether your band is competitive before you make the offer. If the search itself is the bottleneck, spray-and-pray sourcing is not going to find the 40 people who can actually produce this build, which is the case for technical recruiting support rather than a wider funnel.
