We posted a GTM engineer role on LinkedIn the same way we'd posted every other job, wrote a generic requirements list, waited for applications, and scheduled interviews when someone looked good on paper. Nine weeks later we'd lost our two strongest candidates to companies that closed them in under three weeks, and I was starting to think the role didn't exist outside of job titles.
It wasn't the role. It was the process. GTM engineer postings grew roughly 200% year over year, and the good candidates are fielding multiple offers within weeks of going on the market. Here's the sourcing-to-offer process that actually got us a hire the second time around.
Write the req around a problem, not a title
Our first posting listed tools: HubSpot, Clay, n8n, SQL. Every strong candidate has that list memorized and skips postings that read like a checklist, because it signals the hiring manager doesn't actually know what the role does day to day. The rewrite that worked led with the actual problem: our outbound replies were coming from a hand-built list that took six hours a week to refresh, and we needed someone to make that automatic. Candidates who can solve that problem self-select in. Candidates who just know the tool names self-select out, which is exactly the filter you want before you spend an hour on a call.
Source where the candidates already are, not where you usually post
LinkedIn posting alone put us in a queue with a hundred other companies. The candidates we actually wanted were in the Clay Community Slack, which has grown past 20,000 members and has a dedicated #jobs channel where GTM engineers who are already fluent in the primary tool of the trade post their availability directly. We also found two strong candidates through referrals from RevOps and growth-marketing communities, people who'd watched a candidate ship a real automation in a public channel before we ever spoke to them. That's a stronger signal than any resume line.
Screen with a real problem, not a resume walkthrough
The first screen is a live business-problem investigation, not a background chat. We describe one real GTM bottleneck we're currently working around manually and ask the candidate to think out loud about how they'd approach it, before they touch a single tool. What we're watching for is whether they ask about the downstream system the fix feeds into, or whether they jump straight to naming a tool. The ones who ask about downstream impact are the ones who don't build automations that quietly break something three steps later.
Have them sketch your systems, out loud, on a call
Round two is a systems sketch. We give the candidate a simplified version of our actual stack, CRM, enrichment source, outbound tool, and ask them to sketch how data should flow between them and where they'd expect it to break. This is the round that separates people who've used the tools from people who understand data architecture. A candidate who immediately asks what happens to a record when two systems disagree about a field value has done this before. A candidate who just describes a Zapier chain hasn't operated at the scale we need yet.
Run one small, paid build before you make an offer
The last technical step is a scoped, paid mini build: a real but small piece of work, capped at a few hours, with a hard deadline and a fixed payment regardless of outcome. We ask for one narrow automation, something we'd genuinely ship if it works. This round tells you more than any interview about how someone handles ambiguity and a deadline at the same time, and paying for it signals you respect their time enough that the strongest candidates don't walk away from the ask.
Move at the speed the market is actually moving
Most companies report eight to sixteen weeks from posting to signed offer for this role, and that timeline is exactly what's costing hiring managers their best candidates. Once someone clears the systems sketch, we compress the remaining steps into one week: paid build, one reference call focused on what they shipped and whether it's still running six months later, and an offer within 48 hours of the build being reviewed. Strong GTM engineers are fielding two or three offers by the time they're this far into any process. The team that moves fastest after the technical bar is cleared wins the hire, not the team with the highest offer.
Ship something real in week one
The mistake we made with our first hire was treating week one as onboarding: tool access, docs, shadowing calls. The fix the second time was giving our new hire one small, real automation to ship by day five, the same size and shape as the paid build round. It gets them into the actual stack immediately instead of a sandboxed version of it, and it gives you a second, low-stakes data point on how they operate before ramp time fully kicks in.
The process is five steps, not a dozen: write the req around a problem, source in communities where builders already show their work, screen with a real problem before a resume, sketch the systems together, and run one small paid build before the offer. Everything after that is speed. Nail the process and you stop competing on comp against companies with bigger budgets, because the candidates who matter are optimizing for a hiring process that respects how they actually think.