DoorDash Revenue Operations Manager (Mid-Level) Interview Preparation Guide

Clarifying scope & goals
Design a 3NF warehouse schema to provide a single source of truth for ARR/Bookings attribution and churn analysis across CRM, Marketing, Billing, and CS.

Core tables / entities

• dim_customer (customer_id PK, name, account_owner_id, industry, created_date, customer_tier)
• dim_account_hierarchy (account_id PK, parent_account_id, account_type)
• dim_date (date_key PK, date, month, quarter, year)
• fact_opportunity (opp_id PK, customer_id FK, stage, amount, close_date_key FK, lead_source, campaign_id)
• fact_lead (lead_id PK, customer_id FK nullable, created_date_key FK, source, campaign_id, status, converted_opp_id)
• fact_invoice (invoice_id PK, customer_id FK, invoice_date_key FK, amount, currency, invoice_type, billing_period_start, billing_period_end, recognized_date_key FK nullable)
• fact_payment (payment_id PK, invoice_id FK, customer_id FK, payment_date_key FK, amount, method)
• fact_cs_touchpoint (touch_id PK, customer_id FK, touch_date_key FK, touch_type, sentiment_score, outcome, associated_opp_id nullable)
• dim_campaign (campaign_id PK, name, channel, owner)

Important fields & notes

• Use surrogate integer PKs; maintain source_id and source_system fields for lineage.
• Store recognized revenue date for GAAP attribution; store invoice and payment dates for cash views.
• Capture lifecycle events (churn_date, churn_reason) in dim_customer or a separate fact_churn.

Example SQL join — Revenue attribution by campaign (bookings + recognized)

SELECT c.customer_id, c.name, d.month, coalesce(SUM(i.amount),0) AS bookings, coalesce(SUM(r.amount),0) AS recognized
FROM dim_customer c
LEFT JOIN fact_invoice i ON i.customer_id = c.customer_id
LEFT JOIN dim_campaign camp ON i.campaign_id = camp.campaign_id
LEFT JOIN dim_date d ON i.invoice_date_key = d.date_key
LEFT JOIN (
  SELECT invoice_id, amount FROM fact_invoice WHERE recognized_date_key IS NOT NULL
) r ON r.invoice_id = i.invoice_id
WHERE camp.campaign_id = :campaign_id AND d.year = :year
GROUP BY c.customer_id, c.name, d.month;

Example SQL join — Churn cohort by CS touchpoints

SELECT d.month, COUNT(DISTINCT c.customer_id) AS churned_customers,
       AVG(cs.touch_count) AS avg_touch_before_churn
FROM dim_customer c
JOIN dim_date d ON c.churn_date_key = d.date_key
LEFT JOIN (
  SELECT customer_id, COUNT(*) AS touch_count
  FROM fact_cs_touchpoint
  WHERE touch_date_key < (SELECT churn_date_key FROM dim_customer WHERE customer_id = fact_cs_touchpoint.customer_id)
  GROUP BY customer_id
) cs ON cs.customer_id = c.customer_id
WHERE d.year = :year
GROUP BY d.month
ORDER BY d.month;

Trade-offs & operational notes

• Normalize for consistency; build marts/flattened views for analytics performance.
• Ensure ETL preserves source lineage and handles partial matches (leads -> opportunities -> customers).
• Maintain incremental pipelines and reconciliation tables for bookings vs recognized revenue.

Overview / objective
As Revenue Ops I’d run a data-driven RCA to find why “Committed” deals slip in last two weeks of each quarter, quantify impact, test causes, and recommend operational fixes to reduce slippage and improve forecast reliability.

Tables / data sources to examine

• CRM Opportunities table (stage history with timestamps, owner, ACV, close_date, committed_flag)
• Activity logs (calls, demos, emails, quotes sent)
• Contract/CLM & Legal queue (SLA timestamps, redlines count)
• Pricing/Discounting ledger (approved discounts, deal desk approvals)
• Billing/Subscription and Implementation tasks
• Rep & AE quota/comp schedule
• Forecast & Actual revenue ledger

Key metrics

• Slip rate by week of quarter ( % committed → slipped )
• Time-in-stage distributions and median days for “Committed”
• Win rate and conversion velocity by AE and segment
• Volume of last-minute discounts, contract redlines, & legal turnaround time
• Forecast accuracy (MAPE) and bias in final two weeks
• ACV concentration of at-risk deals

Visualizations

• Time-series: weekly committed count vs slips heatmap across quarters
• Funnel with cohort waterfall for deals entering “Committed” by week
• Boxplots of time-in-stage for committed deals split by outcome
• Rep/segment scatter: ACV vs slip probability
• Gantt/timeline of contract lifecycle for slipped vs won deals

Hypotheses & tests

1. Legal/contract bottleneck causes slips — test: compare legal turnaround time for won vs slipped (t-test/Mann-Whitney).
2. Deals pushed to quarter-end artificially (pipeline sandbagging) — test: distribution of stage-entry dates; autocorrelation of AE-level last-week closing.
3. Higher discounting/approval delays increase slips — test: logistic regression predicting slip using discount %, time-in-stage, legal days.
4. Resource/implementation capacity causes late cancellations — correlate slipped deals with open PO/implementation backlog.

Operational remediations

• Deal gating: require signed SOW or countersigned contract before marking “Committed”
• SLA & capacity: set legal/finance SLAs; prioritize quarter-end throughput (extra capacity or rotating escalation)
• Deal desk controls: automatic alerts for high-ACV last-week commits requiring managerial review
• Forecast rules: flag and discount last-week commits (probability adjusters) and make rep-level accountability visible
• Process: standardize contract templates, pre-approve common discounts, and enable e-signature + automated reminders
• Training & incentives: discourage artificial compression by aligning comp/forecasting cadence; coach negotiation timelines

Next steps
Run the visualizations, share findings with Sales/Legal/Finance, pilot gating + adjusted forecast probabilities for one quarter, measure reduction in slip rate and forecast bias.

Approach summary
I’d build a regularized distributed-lag regression that models weekly closed‑won revenue as a function of current and lagged channel spend, channel interactions, seasonality controls, and business covariates — then use decomposition (and holdout/experiment validation) to estimate each channel’s marginal contribution.

Model form

Revenue_t = α + Σ_c Σ_l β_c,l * Spend_{c,t-l} + Σ_{c1<c2} γ_{c1,c2} * Spend_{c1,t} * Spend_{c2,t} + f_season(t) + δX_t + ε_t

• f_season(t): Fourier terms or weekly/month dummies or splines to capture seasonality.
• Lags l: e.g., 0..8 weeks, chosen from AIC/lag-decay prior.
• X_t: controls (promotions, pricing, macro, number of sales reps, lead quality score).

Key variables

• Dependent: closed‑won revenue (weekly, by cohort if possible).
• Main features: channel spend (paid search, social, display, email, events), impressions/CTR/leads if available.
• Controls: promo flags, funnel metrics (MQLs, SQLs), seasonality dummies, macro indicators.

Handling multicollinearity

• Use Elastic Net / Ridge to stabilize coefficient estimates and allow correlated spends.
• Compute VIFs; for extremely collinear channels, create grouped composites (e.g., brand vs. performance) or use PCA on spend features and map back via Shapley for interpretability.
• Impose lag-decay priors (Bayesian ridge) to regularize lag coefficients.

Controlling interactions

• Add pairwise interaction terms selectively (business-driven) and regularize heavily to avoid explosion.
• Alternatively use hierarchical models that pool across channels to estimate interactions with shrinkage.

Validation & incrementality

• Holdout time window (future weeks) and backtest forecasting accuracy.
• Compare predicted revenue with and without channel spend (counterfactual): set Spend_{c}=0 in holdout and measure delta.
• Use geo or A/B experiments where possible; validate modelled incremental lift aligns with experimental lift.
• Use Shapley-value decomposition or attribution by proportion of predicted incremental revenue to allocate marginal contribution.
• Sensitivity checks: different lag lengths, alternate seasonality specs, perturb regularization strength; report confidence intervals via bootstrapping or Bayesian posterior.

Operational notes

• Deploy weekly pipeline to refresh estimates; surface channel ROI and recommended budget shifts.
• Document assumptions (causality vs correlation) and align with Marketing/Sales before policy changes.

Direct differentiation (RevOps lens)

• Project management = define scope, timeline, tasks, deliverables, resources (build, configure, test).
• Change management = focus on people: adoption, communications, training, stakeholder alignment, incentives, feedback loops.
  Choose project tasks to deliver the solution; choose change management to ensure it’s used and drives revenue outcomes.

When to prioritize change management
Prioritize change activities when success depends on behavior, cross-functional alignment, or risk to revenue/forecast accuracy.

Examples

• Forecasting process redesign: prioritize change management — new inputs and cadence require sales/CS buy-in, coaching on definition of “commit,” updated dashboards, and executive cadence. Run pilots, role-based training, and weekly coaching until adoption stabilizes.
• Sales compensation change: prioritize change management — impacts motivation and revenue behavior. Communicate modeling scenarios, run Q&A, provide transition payouts, and align payroll and legal; project tasks alone (policy file + calculation) will fail without clear messaging and manager enablement.
• Marketing automation rollout: blend both — project tasks (integration, mapping, flows) first, but ramp change management before launch: train marketers and SDRs, document playbooks, measure KPIs, and set feedback loops to iterate.

Decision checklist

• Will behaviors change? — use change management.
• Is it primarily technical/configuration? — lean project management.
• High revenue risk or cross-team impact? — prioritize change activities.

Approach (brief)
As a Revenue Operations Manager I’d group MQLs by the week of mql_date, count MQLs, count distinct contacts that have a qualified_date within 90 days of their mql_date, and compute conversion_rate = sql_count / mql_count. I’ll use BigQuery/Snowflake date functions.

-- BigQuery / Snowflake-compatible SQL
WITH mql AS (
  SELECT
    contact_id,
    mql_date,
    DATE_TRUNC(mql_date, WEEK) AS mql_week
  FROM marketing_contacts
),
qualified AS (
  SELECT
    contact_id,
    qualified_date
  FROM sales_leads
)
-- join to find qualifications within 90 days of each contact's MQL
, mql_with_qual AS (
  SELECT
    m.mql_week,
    m.contact_id,
    m.mql_date,
    MIN(q.qualified_date) AS first_qualified_date
  FROM mql m
  LEFT JOIN qualified q
    ON m.contact_id = q.contact_id
    AND q.qualified_date BETWEEN m.mql_date AND DATE_ADD(m.mql_date, INTERVAL 90 DAY)
  GROUP BY m.mql_week, m.contact_id, m.mql_date
)
SELECT
  mql_week,
  COUNT(DISTINCT contact_id) AS mql_count,
  COUNT(DISTINCT CASE WHEN first_qualified_date IS NOT NULL THEN contact_id END) AS sql_count,
  SAFE_DIVIDE(
    COUNT(DISTINCT CASE WHEN first_qualified_date IS NOT NULL THEN contact_id END),
    NULLIF(COUNT(DISTINCT contact_id),0)
  ) AS conversion_rate
FROM mql_with_qual
GROUP BY mql_week
ORDER BY mql_week;

Key notes / assumptions / edge cases (in-comments):

• Week starts per DATE_TRUNC(..., WEEK) (Sunday or Monday depends on SQL dialect; confirm org standard).
• Use first qualification within 90 days; if multiple qualifications, count once.
• LEFT JOIN ensures MQLs with no SQL still counted.
• SAFE_DIVIDE/NULLIF avoids divide-by-zero.
• If multiple MQLs per contact in different weeks, each MQL counts independently (change if you want unique-contact attribution).
• Timezone and partial dates: ensure dates standardized to same timezone.

Definition — Process design & workflow automation

As a Revenue Operations Manager I define process design as mapping and standardizing the repeatable steps across lead-to-cash (lead routing, qualification, handoffs, renewals). Workflow automation is using tools (CRM, marketing automation, customer success platform) to enforce those steps, trigger actions, and move data without manual intervention.

Four core benefits (with examples)

• Increased efficiency / time-savings: automating lead assignment saves SDRs hours previously spent triaging inbound lists.
• Consistency / reduced error: standardized opportunity stages and automated field mappings prevent bad data and negotiation mismatches.
• Faster response / improved conversion: instant routing + email/SMS alerts to reps increases lead contact rates.
• Better handoffs / improved retention: automated playbooks trigger onboarding tasks for CSMs when deals close, reducing churn risk.

Concrete automated workflow (simple)

1. Lead submitted via web form → CRM record created (Marketing Ops)
2. Lead scoring runs and threshold checked (RevOps)
3. If score ≥ threshold, auto-assign to SDR based on territory rules (Sales Ops)
4. Send an automated intro email and create a follow-up task (Marketing Ops creates template; assigned SDR executes)
5. If no contact in 48 hours, escalate to Sales Manager and notify via Slack (RevOps/Sales Ops)

This workflow reduces manual triage, speeds responses, and clarifies ownership at each step.

Answer (Revenue Operations Manager perspective)

Minimum required fields (and why)

• Opportunity Name — unique human-readable identifier for audits.
• Owner (user) — accountability for forecast inclusion and follow-ups.
• Close Date (date) — timing of revenue; drives period assignment.
• Stage (picklist) — maps to forecast categories and win probability.
• ACV / ARR / Total Contract Value (currency + term) — revenue impact and smoothing.
• Opportunity Type (new/upsell/renewal) — forecasting motion differences.
• Primary Product / SKU — deal validity and quota attribution.
• Account (company) & Account Tier — roll-up and ICP segmentation.

Historical & system data

• Stage history (timestamped) — velocity analysis and stage duration.
• Amount history (timestamped) — detect amount inflation/changes.
• Owner history — crediting and rep transitions.
• Forecast category overrides & commit notes — audit trail.

Validation rules / automations (at least 3)

1. Required-field enforcement: block save when Owner, Stage, ACV, Close Date, or Account are blank.
2. Logical date guardrails: Close Date must be within [-30 days, +540 days] of today; if Stage = Closed Won/Lost then Close Date locked and Contract Signed Date required.
3. ACV sanity checks: ACV > 0 and consistent with line items; if mismatch, auto-flag and route to deal desk.
4. Stage-probability mapping: when stage changes, auto-set system probability; prevent moving backward from Closed Won without manager override logged.
5. Stale-opportunity automation: weekly report + Slack/email alerts for opportunities with no stage change or activity for >21 days.

These fields and rules create a defensible, auditable dataset so forecasts reflect real timing, accountable ownership, and measurable deal quality.

Definition

• Average Contract Value (ACV): the average annualized value of a closed contract (typically ARR per customer/contract).
• Average Revenue Per Account (ARPA): average recurring revenue generated per customer/account over a period (usually annual).

Calculation

ACV / ARPA = Total ARR ÷ Number of Customers
ACV / ARPA = $2,400,000 ÷ 200 = $12,000

Plain-English: each customer generates on average $12k ARR.

How this influences GTM segmentation & quota

• Segmentation: Use ACV/ARPA to define tiers (SMB: <$5k, Mid-market: $5–25k, Enterprise: >$25k). With $12k ACV, majority fall mid-market — tailor packaging, retention plays, and CAC targets accordingly.
• Quota setting: Translate ACV into sales math — e.g., quota = target bookings * ACV. If a rep’s annual new ARR target is $600k, that’s ~50 deals at $12k ACV; hire/comp plans should reflect deal velocity and conversion rates.
• Forecasting & capacity: Combine ACV with win rates and sales cycle to size pipeline, assign territories, and set realistic activity targets.
• Risk management: Higher ACV reduces deal volume but increases concentration risk; adjust quota collars and renewal incentives to protect ARR.

Approach
I’d group events by date (UTC or company time zone), count distinct user_id per day for the last 30 days, and return date + unique_user_count ordered ascending. This supports adoption tracking on the pipeline feature.

SQL

SELECT
  DATE(event_time) AS date,
  COUNT(DISTINCT user_id) AS unique_user_count
FROM user_events
WHERE event_type = 'new_pipeline_view'
  AND event_time >= CURRENT_DATE - INTERVAL '29' DAY
  AND event_time < CURRENT_DATE + INTERVAL '1' DAY
GROUP BY DATE(event_time)
ORDER BY date ASC;

Notes & edge cases

• I used CURRENT_DATE - 29 days to include today + previous 29 = 30 days. Adjust timezone with AT TIME ZONE if needed.
• If you need zero-filled dates for days with no activity, join against a calendar table or generate_series.
• Useful for weekly trending, funnel analysis, or forecasting adoption velocity.

Clarify requirements & constraints

• Real-time prevention at lead entry (CRM/web forms), cross-system dedupe (marketing automation, billing), low latency (<300ms for UX), scalable for spikes, human review queue, auditability, measurable FP/FN.

High-level architecture

• Client-side checks → API gateway → Rate limit + idempotency → Ingest queue (Kafka/SQS) → Matching engine (sync/async paths) → Identity provider (external ID matching service) → Human review UI + workflow → Authoritative write to CRM and master lead store.

Client-side checks

• Inline normalization (trim, lowercase), simple exact-match checks (email, phone), fuzzy-match hints via lightweight API (returns “likely duplicate” or “clear”) to avoid blocking UX.

Server-side matching engine

• Two-stage: fast filter (exact/email/phone/hash) then probabilistic matcher (name similarity, email domain, phone normalization, company). Use weighted scoring:
  • email exact = 0.5, phone exact = 0.2, name similarity (Jaro-Winkler) = 0.15, company domain match = 0.1, external ID match = 0.05.
• Score range 0–1. Thresholds:

  • = 0.85 auto-block/merge

  • 0.6–0.85 human review (show potential matches)
  • < 0.6 allow create

External identity provider

• Query by email/phone and metadata; if provides enterprise ID, boost score massively and enable cross-system linking; cache responses with TTL.

Queuing & spikes

• Use queue to absorb spikes; synchronous fast-path returns immediate “defer to async review” if queueing latency > threshold; idempotency keys prevent duplicate processing.

Human review workflow

• Review interface shows top N candidates, similarity attributes, audit trail, suggested action (merge, link, discard, create). Provide SLA and routing to data stewards.

Measuring match quality

• Track labeled events (review outcomes) to compute:

precision = true_positives / (true_positives + false_positives)

recall = true_positives / (true_positives + false_negatives)

false_positive_rate = false_positives / (false_positives + true_negatives)

false_negative_rate = false_negatives / (false_negatives + true_positives)

• Monitor weekly, use A/B tests on thresholds, track business KPIs: duplicate rate in CRM, lead-to-opportunity conversion delta, revenue attribution errors.

Operational considerations & trade-offs

• Tightening thresholds reduces duplicates but increases review load and latency; rely on ML re-ranking over time, human-in-the-loop labeling to retrain models, and configurable thresholds per source (marketing vs. sales-entered).