Every GTM engineer résumé you read this quarter will claim n8n. Some of those claims mean the candidate has shipped a production workflow with retries, dedupe logic and an on-call plan. Most mean they watched a tutorial and duplicated a template. You cannot tell which from a phone screen, and you cannot tell from a portfolio link either — so stop trying. Give them a timed build: inbound form to enriched record to routed Slack alert, scored pass/fail against a rubric you wrote before you met them. It takes one sitting, it produces an artifact you can open and inspect, and it surfaces the exact layer — orchestration — where automation spend quietly fails to turn into productivity.
Why the résumé line is now worthless
n8n stopped being a hobbyist toy. The company raised a $180M Series C at a $2.5B valuation, which means the tool is now standard infrastructure in GTM stacks rather than a side project someone wired up over a weekend. That’s good for you as a buyer and bad for you as an interviewer — because the same post reports 6x user growth and 10x revenue growth in a single year. Exposure is wide. Depth is shallow. A huge share of the people who have touched n8n touched it in the last twelve months, on a template, once.
Meanwhile the demand side has gone mainstream. AI and automation language has spread straight into the postings that sit next to this one: about 15% of marketing postings now carry AI-related terms, which is precisely where the GTM engineer req lives. When roughly one in seven postings in your own function asks for it, every résumé in the funnel answers for it — and the answer stops carrying information.
And people round up. 36% of the US labor force — roughly 64 million people — admit to exaggerating their knowledge, skills or experience because they felt pressure to appear capable. That’s not fraud, that’s a labor market doing what labor markets do. It does mean a tooling checklist on a résumé is a statement of intent, not evidence.
The verification problem is getting structurally worse, too. Gartner predicts that by 2028, 1 in 4 candidate profiles worldwide could be fake. If the profile layer is degrading, evidence has to come from an artifact the candidate produces in front of you.
A work sample doesn’t test whether they know n8n. It tests what they do when the enrichment call fails.
The brief, exactly as you send it
Keep the scope narrow enough that a strong candidate finishes comfortably and a weak one doesn’t finish at all. The gap between those two outcomes is the signal.
The ask: Build a working n8n workflow that takes an inbound demo-request form submission, enriches the record, writes it to a destination, and routes a Slack alert to the correct channel based on the enriched attributes. Ship the exported JSON plus a short README.
What you supply:
- A form endpoint or webhook URL they can POST to (or let them use n8n’s own form trigger)
- Sandbox credentials for one enrichment provider and one Slack workspace
- A sample payload file with deliberately dirty data: a duplicate submission, a personal Gmail address, a blank company field, and one row where the enrichment provider will return a 429
- The routing rule in plain English — enterprise fit goes to one channel, SMB to another, anything unroutable goes to a review channel with the reason attached
What you ask for back: the exported workflow, a README naming every failure mode they handled and every one they knowingly skipped, and a loom-free written answer to one question: what breaks first in production, and how would you know?
That last question is the whole interview compressed into a sentence. A template-copier answers with a feature list. An operator answers with an alert.
The pass/fail rubric
Score it before the call, not during it. Binary per line. No weighted five-point scales — they let interviewers talk themselves into a hire.
| Rubric line | Pass looks like | Fail looks like |
|---|---|---|
| Happy path runs | You POST the clean payload, a Slack message lands in the right channel | Workflow errors on execution or requires manual node-by-node runs |
| Dedupe | Duplicate submission is caught before the enrichment call and before the alert | Two identical Slack pings, two enrichment credits burned |
| Error handling | The 429 row triggers a retry with backoff, then an error branch — not a silent stop | Workflow halts; no one finds out until someone asks where the leads went |
| Routing logic | Branch conditions are explicit, mutually exclusive, and have a default | Nested IFs with no fallback; the blank-company row vanishes |
| Unroutable path | Bad records land in a review channel with the reason attached | Bad records are dropped or routed to the default channel as if they were good |
| Credential hygiene | Keys live in n8n credentials, not pasted into HTTP nodes | API key visible in the exported JSON |
| Idempotency on destination | Upsert on a stable key; re-running doesn’t duplicate rows | Blind create; re-run doubles the table |
| Observability | README names the alert they’d wire up and the metric they’d watch | ”It works” |
| Readability | Nodes renamed, flow readable left to right by someone else | Fourteen nodes named HTTP Request1 through HTTP Request14 |
Our threshold: all of happy path, dedupe, error handling and unroutable path must pass. Those four are the orchestration layer. Miss any one and the automation looks fine in a demo and leaks revenue in week three. The remaining lines are tiebreakers between two passing candidates.
How candidates actually spend the time box
The timing patterns are more diagnostic than the final artifact. Across real submissions, the distribution sorts candidates cleanly:
| Phase | Strong candidates | Weak candidates |
|---|---|---|
| Reading the brief and the dirty payload | A real chunk up front — they open the sample data first | Skipped; they open n8n first |
| Building the happy path | Fast, almost boring — it’s a known shape | Most of the box, with fiddling |
| Handling failure cases | The majority of the remaining time | Barely touched or deferred to the README as “future work” |
| Renaming, documenting, re-running | A final clean-up pass | None; export and send |
| Finished inside the box | Yes, with the error branch built | No, or yes with the happy path only |
The tell is the order. Candidates who read the sample payload before touching the canvas design around the failures. Candidates who open the canvas first build a demo and then try to bolt resilience onto it, which never fits. If you only learn one thing from running this, learn to ask which they did.
There’s a second tell worth watching for: the candidate who finishes early and spends the remaining time narrowing scope rather than adding nodes. That’s the instinct you want on a GTM engineering team — the person who ships the small reliable thing instead of the large fragile one.
Why the Clay-only answer doesn’t expose this
Ask a GTM engineer how they’d solve inbound routing and a lot of them will describe a Clay table. That’s not wrong — Clay is excellent at the enrichment waterfall and it will absolutely produce the enriched record. But the Clay-shaped answer and the n8n-shaped answer expose different competencies, and you should know which one you’re buying.
| Dimension | Clay-only answer | n8n answer |
|---|---|---|
| Enrichment waterfall | Native, strong, provider-fallback built in | Hand-rolled — candidate must sequence providers themselves |
| Dedupe | Table-level, largely handled for you | Candidate must choose the key and the check point |
| Retries and backoff | Abstracted away by the platform | Explicit; visible in the workflow or absent from it |
| Error branching | Limited surface to demonstrate | The core of the exercise |
| Routing to Slack | Possible, often via webhook out to something else | First-class, with conditional branches |
| Idempotency on write | Implicit in the table model | A deliberate decision the candidate must make |
| What you learn about the candidate | Data judgment, provider economics, ICP definition | Systems judgment, failure thinking, operational ownership |
| What stays hidden | Whether they can reason about failure at all | Whether they understand enrichment cost and match rates |
The honest read: you want both signals, and Clay fluency is genuinely valuable — but it’s testable in conversation. Orchestration isn’t. A candidate can describe a waterfall convincingly without ever having run one. They cannot describe a retry-with-backoff branch into existence; either it’s in the exported JSON or it isn’t.
So the best version of this screen lets candidates use Clay inside the n8n flow if they want. The rubric doesn’t care which enrichment provider they call. It cares what happens when the call fails. Pair this with a conversational round on RevOps and data plumbing and you’ve covered both halves.
Why orchestration is the line that matters
Here’s the commercial argument for scoring resilience over cleverness. Gartner surveyed more than 1,800 employees and found that just 21% of time saved by AI actually got redirected into more innovative work. Buying the tool doesn’t produce the return. The return comes from automations that run unattended, fail loudly, recover on their own and don’t require a human to babysit them — which is precisely the orchestration judgment this rubric scores and precisely what a template-copier cannot fake.
Read that 21% next to the 15% of marketing postings asking for AI skills and the squeeze is obvious: demand for the skill is broad, but the realised value is thin, and the gap between the two is orchestration quality. An automation that works on clean data and silently dies on dirty data is worse than no automation, because someone now trusts it. The GTM engineers worth hiring know that in their bones, and it shows up in the first five minutes of how they attack a take-home.
Running it without burning your pipeline
A few operating rules, learned the hard way:
Pay for it or keep it tight. Top-tier talent has options. Either compensate the exercise or keep it to a single sitting with a hard stop you state in writing. Don’t send an open-ended build and hope.
Send the sandbox credentials with the brief. Half of all take-home failures are environment failures. If the candidate spends the box fighting your Slack app permissions, you’ve learned nothing about them and a lot about you.
Score blind where you can. Strip names from the exported JSON before review. The rubric is binary for a reason — let it do the work.
Debrief on the README, not the canvas. Spend the follow-up call on the failure modes they skipped and why. The judgment behind the omission is often better signal than the code.
Decide fast. You’re asking for real work; return a real answer in days, not weeks. A strong GTM engineer running a live process will be gone otherwise — see how the market is pricing this role in our salary benchmarks and the broader GTM engineer hiring guide before you anchor an offer.
Run this on your next three GTM engineer finalists and you’ll find the ranking it produces barely resembles the one their résumés produced. That’s the point. Spray-and-pray screening on tooling keywords selects for people who wrote the keyword. A timed build selects for people who shipped the thing.
