A GTM engineer role went up in one Clay Slack channel last week. Seven days later the person hiring posted again: over 100 applications, still working through them.
There are 34,802 people in that channel.
That is the part nobody mentions. You are not competing for a job. You are competing for thirty seconds of attention from someone with a hundred tabs open.
A friend messaged me yesterday. Three months of applying, not one reply. I asked what he was sending.
Hi, my name is X, I'm from X, I have X years of experience and I'm interested in this position.
That is not an application. It is a form.
Here is the system I actually use.
The CV: ten rules, none of them about design
1. Proof strip under your name, before any job history. Mine reads: 5.5M+ emails sent, 564 opportunities, $2.09M pipeline in 60 days. It is what stops the scroll in the first second.
2. Every bullet follows XYZ. Accomplished X, measured by Y, by doing Z. Never a duty. Always an outcome, a number, and a method.
3. Bullet one of each role carries the metric, bolded, at the front. Someone reading 200 CVs sees your job title and bullet one. Nothing else.
4. Two lines per bullet, maximum. The eye bounces off anything longer at scan speed.
5. Group short roles into blocks with "Selected clients:" lines. This kills the job-hop red flag while staying completely truthful.
6. Mirror the job description's exact vocabulary. If it says "TAM scoping" or "enrichment waterfalls", those literal strings go in. Applicant tracking systems match strings, not meaning.
7. Builder verbs only. Architected, built, automated, designed. Never "used", "worked with" or "responsible for". Every GTM job description is screening for systems-builder versus tool-operator.
8. Bold does the navigating. A skimming eye should land only on numbers and role titles.
9. Never list a tool you cannot demonstrate live. If they ask you to share your screen, the CV has already promised something you have to deliver.
10. Tailor per application. Swap the keywords, never rebuild the structure.
Score the job before you apply
Rate each role out of 100 against your actual stack. Below 70, skip it.
A weak application costs more than a skipped one. You spend the hour you could have given to a role you would have won, and you put a mediocre example of your work in front of someone who might have hired you later.
Where you apply matters more than the CV
This is the part most people get wrong.
If a hundred people saw the post, your application is competing with ninety-nine others no matter how good it is. The fix is not a better message. It is a smaller room.
| Board | Why it is worth your time |
|---|---|
| bloomberry.com/gtm_jobs | Crawls company career pages directly, not LinkedIn. You see roles before they are broadcast |
| getcargo.ai/jobs | GTM engineer roles, verified weekly |
| gtmjobs.xyz | GTM, RevOps and marketing ops only |
| adamgtm.com/jobs | GTM specific, low volume |
| upliftgtm.com/jobs | GTM specific |
| clay.com/job-board | Better than the Slack channel, same ecosystem |
| lennysjobs.com | Product and growth, wider but high quality |
| demandcurve.com | Growth roles |
| exitfive.com | B2B marketing community |
And wherever you can, apply on the company's own careers page. A form nobody else found beats a message in an inbox holding a hundred others.
The message
When you do write to a person, read their business first.
Here is the difference in practice. This is the version that gets ignored:
I have X years of experience and I'm interested in this position.
And this is the version that gets answered:
You've got a Client Success Partner on strategy and a Setter closing meetings. So the GTM Engineer is the one thing holding both ends together. If the campaigns underperform, neither of them can fix it. That's the seat I want.
Then the proof. Tools you use daily rather than tools you have heard of. Real numbers. Screenshots of campaigns that worked.
The first message asks them to imagine you doing the job. The second shows you already understand it before anyone has hired you.
The question that actually separates candidates
In interviews, the tell is when someone asks what broke rather than what you built.
Anyone can follow a tutorial. Very few people can explain why a domain went quiet in week three, what they checked first, and what they would do differently. Tutorials cover the build. Nothing covers the hour after it breaks.
That is also why rule nine matters. Knowing when not to build something is rarer than knowing how to build anything, and it is the thing nobody can fake on a call.
Apply where ten people are looking, not ten thousand.