EasyTechnical

59 practiced

Describe what you know about DoorDash's mission and business model. In three to four sentences explain how DoorDash creates value for customers, merchants, and Dashers. Then identify two key data sources a DoorDash data scientist would rely on to measure overall marketplace health and explain briefly why each source is important.

EasyBehavioral

71 practiced

Tell me in two minutes why you want to join DoorDash as a data scientist. Mention which parts of DoorDash's mission or product excite you, and explain how your background and prior work uniquely prepare you to contribute. Be specific about one product area (for example: last-mile logistics, marketplace pricing, or personalization) and describe one measurable impact you would aim to achieve in your first six months.

MediumTechnical

82 practiced

Give a specific example of mentoring a junior data scientist. Explain how you set goals, provided feedback, delegated tasks, and evaluated progress. What structures or tools would you introduce at DoorDash to scale effective mentorship across teams?

Sample Answer

Situation: At my last company I mentored a new junior data scientist (Anna) who joined to support delivery-optimization models. She had solid statistics but limited production ML and cross-team communication experience.

Task: My goal was to bring her to full ownership of a rerouting feature within 3 months: technical competency (data pipelines, model validation), product sense (trade-offs), and stakeholder communication.

Action:- Set clear goals using a 90-day plan with measurable milestones: week-by-week tasks (EDA, baseline model, feature store integration, CI/CD pipeline), plus behavioral goals (presentations, ticket estimates).- Delegated work progressively: start with data cleaning and exploratory analysis, then feature engineering, then owning a small model component with my review.- Gave structured feedback weekly in 1:1s and asynchronous code reviews. I used the SBI (Situation-Behavior-Impact) format for feedback and paired programming twice a week for hands-on learning.- Evaluated progress via milestone demos, PR quality metrics (test coverage, review iterations), and stakeholder feedback after her presentations. When gaps appeared (e.g., model validation) I adjusted tasks and provided resources (notebooks, example tests).Result: After 10 weeks she independently shipped the feature component; model performance improved 8% AUC and deployment time shortened by 30% due to cleaner pipelines. Her confidence and cross-team communication improved; she later mentored a new intern.

To scale mentorship at DoorDash:- Standardize a mentorship playbook: 30/60/90 templates, leveled competency rubric for DS skills (data engineering, modeling, product communication).- Implement lightweight tracking in Notion or Confluence plus OKR alignment so mentor/mentee goals map to team priorities.- Pair-programing rota and office-hours calendar; require two code reviews (peer + mentor) for first 3 PRs of a mentee.- Training resources: curated learning paths (MLflow, Feature Store, infra patterns), recorded brown-bag sessions, and a mentorship Slack channel.- Mentor matching + micro-mentorship program for quick skill swaps; measure impact with quarterly surveys, promotion/ownership rates, and time-to-first-PR metrics.These structures keep mentorship consistent, measurable, and aligned with DoorDash’s emphasis on rapid, reliable delivery.

MediumTechnical

64 practiced

You detect a sudden spike in refunds in a specific region. Provide a prioritized triage plan using dashboards, sampling, transaction logs, customer support tickets, and ops interviews. What immediate mitigation steps would you recommend before a full root-cause analysis is complete?

Sample Answer

Triage plan (prioritized, with rationale)1) Quick dashboard sweep (0–15 min)- Confirm spike: time window, magnitude, affected products, payment methods, user cohorts, and geography. Check KPIs: refund rate %, refund volume $, orders/sec, fraud flags.- Rationale: fast scope and triage decisions.

2) Transaction log sampling (15–45 min)- Pull a stratified random sample of refunded transactions across time, products, and payment methods. Extract order id, user id, timestamps, payment provider response, refund reason code, shipping status.- Rationale: find commonalities (same payment gateway, same item, same flow).

3) Customer support tickets & free-text analysis (30–60 min)- Query recent tickets with refund keywords for that region; run quick NLP/topic counts to surface recurring complaints (e.g., “double charge”, “item not received”, “unauthorized”).- Rationale: identifies customer-facing symptoms and potential UX or fraud patterns.

4) Correlate with system/ops signals (30–90 min)- Check recent deployments, config changes, third-party outages, payment gateway error rates, promo codes activated, pricing changes. Interview ops/infra for alerts.- Rationale: operational causes (deploy, API changes) are common roots.

5) Targeted interviews with ops/support/product (within 2 hours)- Ask for recent changes, known incidents, abnormal queues, or manual refunds policy changes.

6) Deeper analytics & model checks (2–6 hours)- Run cohort analysis, feature importance from fraud/return-prediction models, and compare to baseline.

Immediate mitigations (before full RCA)- Hold/flag refunds above threshold: route high-value refunds from region to manual review (low friction to customers but prevents mass erroneous refunds).- Throttle automated refund workflows tied to the suspect flow/gateway or disable specific refund reason codes if evidence supports.- Revert recently deployed changes affecting payments/returns if strongly correlated and low-risk.- Temporarily increase fraud/manual review staffing for that region; add a banner/notification to CS to avoid duplicate refunds.- Communicate briefly to stakeholders and next-steps timeline.

Metrics to monitor during mitigation- Refund rate, false-positive manual reviews, customer wait time, revenue at risk. Re-evaluate every 30–60 minutes and proceed to full RCA if mitigations stabilize or identify cause.

MediumSystem Design

116 practiced

Design a minimal instrumentation plan to support an experiment testing dynamic pricing for delivery fees. Specify what events to record, required user and session identifiers, timestamps and geolocation granularity, contextual metadata (for example surge indicator, merchant id, vehicle type), and how you would validate the integrity of the collected data before conducting analysis.

Sample Answer

Requirements / goals:- Measure causal effect of dynamic delivery-fee treatment on conversion, order value, delivery acceptance/time, and retention while ensuring attribution, joinability, and low instrumentation bias.

Events to record (minimal set):- impression.delivery_fee_shown {user_id, session_id, timestamp, experiment_id, treatment_variant, fee_amount, currency, merchant_id, outlet_id, location_lat, location_lon, geo_granularity, surge_indicator, vehicle_type, device_type, app_version}- click_fee_details {user_id, session_id, timestamp, experiment_id, fee_amount, …}- order_initiated {user_id, session_id, timestamp, experiment_id, cart_value, items_count, merchant_id, estimated_delivery_fee}- order_placed {user_id, order_id, session_id, timestamp, experiment_id, final_fee_charged, payment_method, order_value, merchant_id}- delivery_assigned {order_id, driver_id, timestamp, vehicle_type, eta}- delivery_completed {order_id, timestamp, actual_delivery_time, driver_rating}- exposure_opt_out / consent events

Identifiers and timestamps:- Persistent user_id (hashed PII), session_id (UUID per app session), order_id, driver_id- All timestamps in ISO 8601 UTC with ms precision- Include event_publish_time and event_ingest_time for latency checks

Geolocation granularity:- Record precise lat/lon at event if allowed; for analysis store aggregated buckets: city, zip3 or 3-digit grid (~1–5 km). For privacy, persist hashed coarse grid; keep exact only for ops and delete per policy.

Contextual metadata:- experiment_id, treatment_variant, UI_location, surge_indicator (binary + multiplier), merchant_id, outlet_attributes (fulfillment_capacity), vehicle_type, estimated_eta, promotion_id, user_cohort_tags (new_user, high_freq), currency, country, locale, app_version, network_type.

Data validation before analysis:- Schema validation at ingestion (required fields, types, enums)- Sequence checks: impression before order_initiated before order_placed for same session/order- Deduplication by event_uuid + idempotency keys- Consistency checks: fee_amount >=0, final_fee_charged equals displayed fee for treatment (or flagged), currency matches user locale- Exposure / assignment integrity: tie treatment_variant in impression to experiment assignment store; compute mismatch rates; reject sessions >X% mismatched- Completeness sampling: daily counts vs expected traffic by bucket (region, app_version); alert on >10% drift- Latency and replay detection: event_publish_time << ingest_time, flag future timestamps- Randomization balance test: compare baseline covariates (user_cohort, region, time-of-day) across variants; run sanity A/A checks- Logging of validation failures to audit table; pipeline rejects or quarantines bad records with clear reasons.

Instrumentation best practices:- Use idempotent event writes, versioned schema, and lightweight SDK with local buffering and retry.- Keep experiment assignment deterministic server-side and log assignment source.- Maintain a small sample of raw events and deterministic replay for debugging.

This plan provides the minimal fields to attribute exposure, link to outcomes, preserve privacy, and automated checks to ensure data integrity before causal analysis.

Motivation for DoorDash and Data Science Role Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank