Data, SQL & Measurement

The data round at Cursor is where your systems claims get audited. You built an enrichment-and-routing pipeline in the practical round; now you have to prove it worked with a query you write live, while someone watches your reasoning.

Treat the SQL screen as the same job in a different costume. A GTM Engineer who can architect lead routing but can't count routed leads correctly hasn't closed the loop. The interviewer cares less about exotic syntax and more about whether your numbers survive a sanity check.

The grain trapthe single most common wrong answer

Most botched funnel queries come from one mistake: joining tables at different grains and then counting rows as if they were unique entities. A leads row is one person. An opportunities row is one deal. A usage_events row is one product action. Join them naively and a single lead with forty sessions becomes forty leads.

The fix is rarely cleverness. Aggregate the high-cardinality table to the grain you want before you join or wrap your count in distinct on the right key. When usage muddies a per-lead count, collapse usage_events to one row per lead in a CTE first, then join.

with first_qualified as (
  select lead_id, min(qualified_at) as qualified_at
  from lead_stage_history
  where stage = 'qualified'
  group by lead_id
)
select
  l.segment,
  count(distinct l.lead_id)                          as captured,
  count(distinct fq.lead_id)                         as qualified,
  round(
    count(distinct fq.lead_id)::numeric
    / nullif(count(distinct l.lead_id), 0), 3)       as qual_rate
from leads l
left join first_qualified fq using (lead_id)
where l.captured_at >= date '2026-01-01'
group by l.segment
order by captured desc;

Window functions earn their keep on touch attribution and cohortsfirst-touch, last-touch, sequencing

First-touch and last-touch live in row_number() over a partition. Cohorts live in date_trunc plus a window count. Sequencing (did enrichment fire before routing?) lives in lag() and lead(). These four patterns answer most of what the funnel round will throw at you.

with touches as (
  select
    lead_id, channel, occurred_at,
    row_number() over (
      partition by lead_id order by occurred_at asc
    ) as touch_seq
  from marketing_touches
)
select
  date_trunc('month', l.captured_at) as cohort_month,
  t.channel                          as first_touch_channel,
  count(distinct l.lead_id)          as leads
from leads l
join touches t on t.lead_id = l.lead_id and t.touch_seq = 1
group by 1, 2
order by 1, leads desc;

Dirty data is the systems problem wearing a SQL hat

Dedup, nulls and inconsistent enums show up in queries the same way they show up in the pipeline you built. An interviewer who drops a duplicate lead_id or a null segment into the dataset is checking whether you notice before you report. Handle it explicitly rather than letting the database silently decide.

• Dedup at the entity grain with row_number() keyed on the latest updated_at, not a blind distinct that hides which row won.
• Coalesce nulls into an explicit bucket (coalesce(segment, 'unknown')) so they appear in the report instead of vanishing from a group by.
• Normalize enums (lower(trim(stage))) when the source mixes Qualified, qualified and QUALIFIED.
• Guard every division with nullif(denominator, 0) so an empty segment returns null, not a query error.

A growth program without a scoreboard is a hobby. Your job is to pick the two or three numbers that tell the team whether a startup program or partnership motion is working, then defend why those and not the flattering ones.

Cursor runs a developer-led motion that crosses self-serve into enterprise. The metric set has to respect that the same lead can convert through product usage, a partnership or a startup-program credit. Start by separating the one number you steer toward from the numbers that keep you honest.

The program funnel, end to endcapture to expansion

Every growth program shares a backbone. Instrument each transition so you can see where leads stall, then attach a rate to every arrow rather than reporting raw counts that hide the drop-offs.

1. 1Capture. Lead enters from a form, partner feed or product signup. Count: new leads by source.
2. 2Enriched. Waterfall enrichment attaches firmographic and tech-stack data. Rate: enrichment match rate.
3. 3Qualified. Scoring crosses the ICP threshold. Rate: enriched → qualified.
4. 4Routed. Lead lands with the right owner inside the SLA. Rate: routed within SLA.
5. 5Meeting / activated. First real engagement or product activation. Rate: routed → activated.
6. 6Expansion. Paid conversion or seat growth. Rate: activated → expanded.

Efficiency metrics prove the engineering, not just the funnelthe part marketing ops forgets

Funnel rates show the program works. Efficiency metrics show you built infrastructure instead of doing the work by hand. For a GTM Engineer seat, these are often the metrics that separate you from a campaign operator.

Define "qualified" so the metric can't be gamedwhere upstream logic leaks into the scoreboard

If "qualified" means "score above the threshold," then anyone who loosens the scoring model can manufacture qualified leads without improving the business. A precise definition pins the metric to an outcome, not to a knob someone upstream controls.

A defensible definition reads like a query: first time a lead crosses ICP score 75, with a verified work email and a matched account, excluding existing customers. Each clause closes a gaming path. The verified-email clause stops junk captures from counting; the existing-customer exclusion stops the program from claiming credit for accounts it didn't create.

Reporting tells you what happened. A feedback loop changes what happens next. The seat's impact comes from building the second kind, where won/lost outcomes quietly retune the system that produced them.

A scoring model is a hypothesis: "these traits predict a good lead." Without a loop, that hypothesis ossifies. Sales closes deals the model rated low and ghosts leads it rated high and nobody tells the model. Closing the loop means the outcome flows back to the input that made the prediction.

The closed loop, made concreteoutcome feeds the scorer

1. 1Emit. Every routing decision logs the lead, its score, the owner and a timestamp.
2. 2Observe. The CRM marks the deal won, lost or stalled, with a reason code.
3. 3Join. A scheduled job stitches outcome back to the original score and segment.
4. 4Learn. Recompute which traits actually predicted wins; flag features that no longer earn their weight.
5. 5Adjust. Update the scoring weights or routing thresholds, with the change logged and dated.
6. 6Re-measure. Watch the next cohort's conversion to confirm the change helped, not just moved the number.

Detecting drift before it costs a quarterthe silent failure mode

Pipelines rot quietly. A data provider changes its schema and match rate slips from 75% to 60% over three weeks; nobody notices until pipeline dries up. Drift detection means the metric watches itself.

Experiments with honest readoutsA/B on routing and messaging

When you A/B a routing rule or an outreach variant, the discipline is the same as any experiment. Randomize at the lead or account level, pre-register the metric and resist peeking until you have the sample to call it. A directional read stated as a directional read beats a false certainty.

• Randomize at the right unit (account, not lead, when reps work whole accounts) to avoid contamination.
• Pre-commit to the primary metric and the minimum sample before you launch, so you can't retrofit a winner.
• Report the effect with its uncertainty and call out when the sample is too small to conclude anything.

Instrument at the sourcethe workflow emits the events

You can't measure what the workflow doesn't emit. Build the event emission into the automation itself, so every enrichment, score and route writes a structured record at the moment it happens. Bolting analytics on afterward gives you gaps exactly where the system failed.

{
  "event": "lead.routed",
  "lead_id": "ld_8f21",
  "account_id": "ac_03b9",
  "score": 82,
  "owner": "rep_14",
  "rule": "segment_round_robin_v3",
  "sla_target_min": 15,
  "routed_at": "2026-06-15T17:04:22Z",
  "idempotency_key": "ld_8f21:routed:v3"
}

Attribution is where GTM data is most tempting to lie. Every model is a simplification with a built-in bias and a developer-led motion makes the lie easier because product usage muddies every marketing claim.

Truth-seeking, the value screened throughout this loop, shows up most sharply here. The honest answer to "did the startup program drive that revenue?" is usually "partly and here's how confident I am," not a clean number that makes a slide look good.

PLG breaks the marketing-sourced storyproduct usage muddies the claim

In a self-serve motion, a developer can discover Cursor, use it solo for two months, then show up in a partnership-sourced deal that takes the credit. The touch that mattered most never appeared in the marketing log. Any attribution that ignores product usage will systematically over-credit the last human touch.

• Product usage often precedes the first recorded marketing touch, so "marketing-sourced" undercounts product-led demand.
• Bottom-up adoption means the buyer and the user differ; the user's journey is invisible to last-touch.
• A single account can have dozens of self-serve users before one becomes the enterprise champion.

Incrementality is the only honest questionwhat the program actually caused

Correlation asks "did leads who touched the program convert more?" Incrementality asks "would they have converted anyway?" The second is harder and far more valuable. The cleanest evidence is a holdout: a comparable group that didn't get the program, measured against the group that did.

When to invest vs. accept a directional readthe pragmatic call

Better attribution costs engineering time and sometimes deliberately withheld pipeline. Spend it where the decision is expensive and reversible-only-at-cost. For a small experiment, a directional read is enough; for a multi-quarter budget allocation, a holdout earns its cost.

A dashboard nobody acts on is a screensaver. The seat's documentation responsibility lands here: dashboards and metric definitions are how a flat team stays self-sufficient without routing every question through you.

The JD names Looker, Tableau, Power BI and Omni. The interviewer doesn't care which logo you pick; they care that you can justify it and that you design for a decision rather than a data dump.

Pick a BI tool and own the reasoningthe choice matters less than the why

For this seat the honest pick is a tool with a governed semantic layer, because the whole job is preventing the "whose number is right?" fight. Looker or Omni let the definition of qualified live in one place that every chart inherits.

One screen, one questiondesign for a decision

Every dashboard should answer a single question a specific person has to act on. Before adding a chart, ask whose decision it changes. If the answer is "it's interesting," it belongs in an exploration view, not the action dashboard.

Alert on the metric, don't just chart itthe part people skip

A chart waits for someone to look. An alert reaches out when the number crosses a line. The match-rate drift from the feedback-loop section should page you, not sit on a tab nobody opened for two weeks.

• Set thresholds tied to the guardrails, not arbitrary round numbers ("match rate below 65% for two days").
• Route the alert to the owner who can act, with the breakdown attached so they don't have to go hunting.
• Tune for signal: an alert that fires daily gets muted and a muted alert is worse than none.

Document definitions to end the "whose number" fightself-sufficiency by design

The fastest way to lose trust in data is two dashboards showing different "qualified lead" counts. A short, versioned metric dictionary, one definition per metric with the exact logic and owner, prevents it. This is the lightweight documentation the role explicitly asks you to maintain.