Collaborate with PM and Eng as DS
Company: Reddit
Role: Data Scientist
Category: Behavioral & Leadership
Difficulty: easy
Interview Round: Onsite
## Question
As a Data Scientist working with Product Managers and Engineers:
1. How do you structure collaboration (requirements, timelines, ownership)?
2. How do you decide which requests to **push back on** vs which to proactively drive?
3. Describe a concrete example where you influenced product direction or prevented a bad decision.
(Answer as if you’re supporting an Ads product team.)
Overview: This question evaluates a data scientist's cross-functional collaboration, prioritization, ownership, stakeholder management, and influencing skills when engaging with product managers and engineers.
Read the full Reddit Data Scientist interview experience this question came from
Solution
## 1) Collaboration model (operating cadence)
A practical DS–PM–Eng operating model:
- **Intake/brief:** 1-pager with problem statement, target users, success metrics, constraints.
- **Metric contract:** align on primary metric + guardrails before building.
- **Execution plan:** instrumentation checklist, analysis plan, experiment plan, timeline.
- **Recurring sync:** weekly to unblock; async updates to reduce meetings.
- **Ownership:** PM owns product decision, Eng owns implementation, DS owns measurement/causal validity.
## 2) When to push back (and how)
Push back when:
- **No decision will change** based on the analysis (“vanity analysis”).
- Success metric is undefined or conflicting.
- Data is missing and timeline doesn’t allow instrumentation.
- The request creates high risk (privacy, policy, user harm) without guardrails.
How to push back constructively:
- Reframe: “What decision are we trying to make?”
- Offer alternatives: “We can do a quick directional cut now, but the causal answer needs an experiment.”
- Propose minimum viable scope and a follow-up plan.
## 3) When to proactively drive work
Proactively drive when:
- You detect metric regressions or opportunity areas (e.g., auction health, advertiser churn signals).
- There’s a repeated decision pattern that needs standardization (experiment templates, dashboarding).
- The org is about to launch without measurement readiness—step in with an instrumentation/guardrail plan.
## 4) Example structure (STAR)
- **Situation:** Ads team wants to launch a new targeting feature quickly.
- **Task:** Ensure it increases revenue without harming advertiser ROAS or user experience.
- **Actions:**
- Defined primary metric (incremental revenue) + guardrails (ROAS, complaints).
- Flagged selection bias in “before/after” and insisted on holdout.
- Added instrumentation and ran a staged ramp with weekly checkpoints.
- **Result:** Launch decision based on measured lift; avoided rolling out a variant that increased revenue but materially harmed ROAS for small advertisers.
## 5) Common failure modes
- DS accepts a vague ask and becomes a “report generator.”
- PM/Eng ships without guardrails and then argues over metrics after the fact.
- DS over-indexes on statistical purity and misses product timelines—balance rigor with iteration.