Capstone: Mock Loop

The recruiter screen is won or lost in the first ninety seconds. Before anyone asks about Clay tables or routing logic, they're deciding one thing: does this person build durable GTM infrastructure or do they run campaigns by hand. Rehearse against a timer until that answer is unmistakable.

Set a 30-minute clock and run the whole screen out loud - your build story, your why Cursor, your questions. Record it. The gap between what you think you said and what you actually said is where this round is decided.

The 90-second build-something storyone system, one number

Pick one GTM system you built end to end, not a project you helped with. The screener wants to hear ownership of the plumbing: a data flow, a routing engine, an enrichment pipeline that someone still relies on today.

1. 1Open with the mess. Name the manual, broken workflow before the fix: "reps were enriching leads by hand in spreadsheets and 40% of inbound sat untouched past the first day."
2. 2Name the system you built. Two sentences on the architecture - sources, the orchestration layer, where decisions got made. Concrete tools, not adjectives.
3. 3Land one quantified metric. Match rate, time-to-route, leads handled per week, hours of toil removed. One number, stated as a delta from the old world.
4. 4Close on durability. Say who still uses it and how it extended to a case you didn't originally build for. That sentence is what separates engineer from operator.

The 30-second 'why Cursor'

Generic enthusiasm reads as a red flag here. Ground it in two specifics: the product you actually use and the shape of this role. Cursor is a developer-led, PLG-to-enterprise motion and they want someone who reaches for AI to remove toil by instinct.

Three questions that signal seniority

Junior questions ask what it's like to work there. Senior questions probe the system you'd inherit and the impact you'd have. Bring three, ask the two that fit the conversation.

• "Where's the current source of truth for the lead and account object model and how much identity-resolution debt am I inheriting?"
• "Which growth programs are most blocked on infrastructure today - startup, dev ecosystem or partnerships - and what would 'unblocked' look like in 90 days?"
• "How do you draw the line between what GTM engineering owns versus Data versus Eng, so I'm building plumbing and not stepping on a platform team?"

Self-score the screen

“Design enrichment, scoring and routing for a new startup program.” That's the prompt and the clock is thirty minutes. This is the AI-barred round - no copilot, no autocomplete - so the room is grading your raw reasoning and whether you narrate the tradeoffs you reject, not just the ones you keep.

Run a fixed spine so the open-endedness doesn't sink you: capture, dedup, enrich, score, route, measure. Draw it as a left-to-right flow on the board and walk it once before you go deep on any box.

The pipeline, box by boxthe diagram you'll draw

Dedup and the waterfall - where most candidates rush

Dedup is the box people skip and it's the one that breaks GTM systems in production. State your match key explicitly and handle the person-versus-account grain. Then make the enrichment a true waterfall, not a fan-out.

1. 1Pick a deterministic key first. Normalized email for person, normalized domain for account. Lowercase, strip plus-addressing, strip www/subdomains.
2. 2Fall back to fuzzy only when deterministic fails. Company-name + region similarity, gated by a confidence threshold, never silent.
3. 3Order the waterfall by cost and hit-rate. Cheapest, highest-coverage provider first; stop the chain the instant you have a confident match.
4. 4Cap spend per lead. Set a max number of provider calls so a hard-to-match lead can't run up the bill against all four vendors.

Scoring and routing - make it explainable

A score nobody can explain gets ignored by reps and overruled by leadership. Keep it a transparent weighted sum to start, with thresholds that map cleanly to routing actions.

Generalize the one case into a primitive

The last five minutes are where this round is actually won. The prompt was one program, but Cursor wants reusable program primitives that extend across segments, geos and program types.

The practical project is the decision round - at Cursor, finalists often do an intensive, paid, hands-on build with the team. This section is a self-administered version of that brief, with the realism injected on purpose, because a clean sample list teaches you nothing about how you behave when a provider dies mid-run.

Give yourself a fixed window (2–3 hours), a 200-row sample list and the constraints below. Build it in Clay if that's your tool or script it - the team cares that it works and that you can defend it, not which logo you used.

The briefwhat 'done' looks like

1. 1Enrich. Take a raw list (name, email, company) and resolve firmographics through a provider waterfall with a per-lead call cap.
2. 2Score. Compute a transparent 0–100 ICP score and write it back to each row with the contributing signals visible.
3. 3Route. Bucket by threshold into top-rep / SDR-queue / nurture, with a fallback owner for unmatched territories.
4. 4Report. Produce one metric or mini-dashboard: match rate, score distribution and counts routed to each bucket.

Inject the realism

A demo that only handles clean data fails the round. Seed your sample with the four failures below and make sure your flow survives all of them without silent data loss.

Earn the AI step

Cursor builds an AI tool and expects you to apply AI to real workflows, but a gratuitous LLM call is worse than none. Add exactly one AI step that genuinely beats a deterministic rule and put a guardrail on it.

# Constrain the output space, ground it in real fields and verify before trusting it.
prompt = f"""Classify this company into exactly one segment.
Allowed values: ["startup", "midmarket", "enterprise", "unknown"].
Return only the value, no prose.

Company: {row.company}
Employee count: {row.employee_count}
Description: {row.description}
"""

label = llm(prompt).strip().lower()

# Guardrail: reject anything off-menu; never let a hallucinated label route a lead.
if label not in {"startup", "midmarket", "enterprise", "unknown"}:
    label = "unknown"        # fail closed, send to human review

# Cross-check against a hard signal so the LLM can't override ground truth.
if row.employee_count and row.employee_count > 2000 and label == "startup":
    label = "needs_review"   # contradiction → flag, don't silently trust

Deliverables and the demo script

The build is half the score. The other half is the short spec/runbook and how you narrate it, because this role lives or dies on written communication and clear decisions.

The data round hands you a schema and one question: "What's our stage conversion by segment?" The trap is that the obvious query double-counts. This drill is about getting the grain right, handling nulls on purpose and being honest about what your number does not capture.

Assume a typical GTM warehouse shape: a leads table (one row per captured lead, with segment, score, created_at) and a stage_events table (one row each time a lead enters a funnel stage). Set a 25-minute clock and narrate every definition as you write it.

Task 1 - stage conversion by segment, without double-counting

Collapse to one row per person before you count and count distinct people who ever reached each stage, not raw stage events. Make the NULL segment its own visible bucket instead of letting it vanish.

WITH person AS (                       -- collapse duplicate leads to one person
  SELECT
    LOWER(TRIM(person_email))            AS person,
    MAX(lead_id)                         AS canonical_lead_id,
    COALESCE(MIN(segment), 'unknown')    AS segment   -- NULL segment is a real bucket, not a silent drop
  FROM leads
  WHERE person_email IS NOT NULL
  GROUP BY LOWER(TRIM(person_email))
),
reached AS (                            -- did this person EVER reach each stage
  SELECT
    p.person,
    p.segment,
    BOOL_OR(e.stage = 'captured')  AS hit_captured,
    BOOL_OR(e.stage = 'qualified') AS hit_qualified,
    BOOL_OR(e.stage = 'meeting')   AS hit_meeting,
    BOOL_OR(e.stage = 'won')       AS hit_won
  FROM person p
  JOIN leads l   ON l.lead_id = p.canonical_lead_id
  JOIN stage_events e ON e.lead_id IN (   -- all lead_ids belonging to this person
        SELECT lead_id FROM leads WHERE LOWER(TRIM(person_email)) = p.person)
  GROUP BY p.person, p.segment
)
SELECT
  segment,
  COUNT(*) FILTER (WHERE hit_captured)  AS captured,
  COUNT(*) FILTER (WHERE hit_qualified) AS qualified,
  COUNT(*) FILTER (WHERE hit_meeting)   AS meeting,
  COUNT(*) FILTER (WHERE hit_won)       AS won,
  ROUND(100.0 * COUNT(*) FILTER (WHERE hit_qualified)
              / NULLIF(COUNT(*) FILTER (WHERE hit_captured), 0), 1) AS cap_to_qual_pct
FROM reached
GROUP BY segment
ORDER BY captured DESC;

Task 2 - define 'qualified' and state what it misses

Before you trust the number, define the word. "Qualified" is a choice, not a given and the round rewards you for saying which choice you made and what it leaves out.

Task 3 - propose the feedback loop

The round closes by asking what you'd do with the number. A GTM engineer doesn't just report conversion; they wire it back into the system so it improves.

1. 1Find the leak. The query already exposes which segment has the worst capture→qualified rate; start there.
2. 2Form one hypothesis. Low rate in the 'unknown' segment likely means missing enrichment, so those leads never clear the ICP threshold.
3. 3Close the loop in the system. Feed won/lost outcomes back as labels to recalibrate score weights and add an enrichment retry for the segment that's starved of firmographics.
4. 4Re-measure on the same definition. Watch the same cohort conversion after the change so you're comparing like with like, not a moved goalpost.

The values round screens for truth-seeking, agency, simplicity and AI-native impact - and it does it with follow-ups, not the opening question. A story that survives the first ask but collapses under "what would you do differently" tells the room more than a polished headline ever could.

For each Cursor value, have one real story loaded, then run it against the tough follow-up below until the answer holds without inflation. If a story isn't true, specific and quantified, cut it.

One story per value, stress-testedthe follow-up is the real test

The true / specific / quantified gate

Run each story through three filters before it goes in your kit. Most stories fail on specificity - they describe a category of work instead of one Tuesday when you did the thing.

Find your weakest stage and fix it

You don't get to choose where you're weak, but you do get to choose what you drill last. Score yourself honestly across the loop and spend your remaining time on the lowest box, not the one that's already comfortable.

Final readiness checklist

• I can tell one build-something story in 90 seconds with a single quantified metric and a reuse line.
• I can whiteboard enrich→score→route end to end, name the failure modes unprompted and generalize it to a primitive.
• I can build (or script) the sample flow so it survives dirty data, a dead provider, a 429 and a dedup collision.
• I can add one AI step that beats a deterministic rule and explain the guardrail that fails closed.
• I can write the funnel query at the right grain, handle nulls on purpose and state what the number misses.
• Every behavioral story is true, specific, quantified and survives its toughest follow-up.