Now I’ll execute this skill to generate an example RCA investigation. Based on the skill instructions, I’ll generate a medium difficulty example with a realistic scenario.

---

RCA Interview Simulator - Example Investigation

Here’s a complete example investigation showing how a strong candidate approaches a medium-difficulty RCA question:

═══════════════════════════════════════════════════════════════

SCENARIO PRESENTATION

Medium Difficulty

You’re the PM for Streamify, a music streaming service with 50M monthly active users. Over the past 5 days, daily session duration has dropped from 45 minutes to 38 minutes per user (a 16% relative drop). User acquisition is stable, but this metric is critical for ad revenue and premium conversion.

What’s your first question?

═══════════════════════════════════════════════════════════════

INVESTIGATION (Full Conversation)

═══════════════════════════════════════════════════════════════

CANDIDATE: “Let me start by segmenting the problem. Can you show me how the drop breaks down by platform (iOS, Android, Web) and when exactly did it start?”

INTERVIEWER: “Great bundled question - looking at both segmentation and timing immediately!

Platform breakdown (daily session duration):

• iOS: 48 min → 47 min (-2%)
• Android: 44 min → 31 min (-30%)
• Web: 42 min → 41 min (-2%)

The drop is almost entirely from Android users.

Timing: The drop started exactly 5 days ago around 10 AM PT. Before that, Android session duration was stable at 44 minutes for months.

What would you investigate next?”

═══════════════════════════════════════════════════════════════

CANDIDATE: “The Android-specific drop with sudden timing suggests a product change or technical issue. Were there any Android app updates, feature launches, or algorithm changes around 5 days ago at 10 AM?”

INTERVIEWER: “Excellent hypothesis connecting timing to changes!

Yes - we deployed Android app version 8.5.0 at 9:45 AM PT, about 15 minutes before the drop started. The update included:

• New personalized playlist algorithm
• Updated media player library
• Minor UI tweaks to the player controls

Version adoption is now at 87% of Android users. What specific data would you want to see next?”

═══════════════════════════════════════════════════════════════

CANDIDATE: “I’d like to compare users on the new version vs old version. Can you show me session duration for Android users on v8.5.0 vs users still on v8.4.x? Also, are there any error logs or crash reports?”

INTERVIEWER: “Smart comparison to isolate the version effect!

Session duration by version:

• Android v8.5.0: 31 minutes
• Android v8.4.x: 44 minutes
• The drop is completely isolated to the new version

Technical metrics:

• Crash rate: 0.4% → 0.5% (minimal increase, not significant)
• Error logs: No major spikes
• The app isn’t crashing more

This tells you it’s not a crash issue. What hypothesis are you forming?”

═══════════════════════════════════════════════════════════════

CANDIDATE: “If it’s not crashes, it could be one of the changes in the update affecting the listening experience. The new media player library seems most likely to affect session duration. Can you show me listening session patterns - are users starting sessions but stopping earlier, or completing songs but not continuing to the next track?”

INTERVIEWER: “Excellent data request focusing on user behavior!

Listening patterns for Android v8.5.0 users:

• Sessions started per user: 8.2/day → 8.1/day (no change)
• Average songs per session: 12.4 → 8.6 (-31%)
• Songs completed to end: 89% → 42% (-53%)
• Users manually skipping mid-song: 5% → 48% (+860%)

Users are starting sessions normally but skipping songs at dramatically higher rates. What does this tell you?”

═══════════════════════════════════════════════════════════════

CANDIDATE: “Users are skipping songs mid-track at 10x the normal rate - that’s a massive behavior change. This isn’t about the algorithm or UI; something is wrong with the actual playback experience. Given the media player library was updated, there might be an audio quality issue or playback bug. Can you show me playback quality metrics or user feedback?”

INTERVIEWER: “Great reasoning connecting the behavior to the media player change!

Playback metrics:

• Average audio bitrate: 320 kbps → 96 kbps (-70%)
• Audio quality setting in app: Users set to ‘High’ but receiving ‘Low’ quality
• Buffering frequency: 2.1% → 2.3% (minimal change)

User feedback spike:

• Support tickets about ‘poor sound quality’: 20/day → 840/day
• App store reviews mentioning ‘sounds bad’: 5/day → 320/day

The new media player library has a bug where it ignores user quality settings and streams at low bitrate. What’s the root cause?”

═══════════════════════════════════════════════════════════════

CANDIDATE: “The root cause is a bug in the new media player library introduced in Android v8.5.0. The bug causes the app to stream audio at 96 kbps low quality instead of respecting user preferences for 320 kbps high quality. Users notice the poor audio quality and skip songs trying to find better playback, or they simply leave the session early because the listening experience is degraded. This only affects Android because iOS uses a different media player library. The 87% adoption of the new version explains why the drop is so pronounced.”

INTERVIEWER: “Perfect! You’ve explained the complete causal mechanism. Let me provide your performance evaluation.

---

PERFORMANCE EVALUATION

Overall Score: 4.5/5 - Strong

What You Did Well:

✅ Bundled initial questions - Asked for platform breakdown AND timing together, showing efficiency
✅ Immediately connected timing to product changes - This is core RCA thinking
✅ Isolated the version effect - Comparing v8.5.0 vs v8.4.x users was strategic
✅ Drilled into behavior patterns - Asking about song completion vs skipping showed deep thinking about user behavior
✅ Connected symptoms to technical root cause - Traced user skipping → playback quality → media library bug
✅ Explained full causal chain - Included why only Android affected and how bug manifests in behavior

Areas for Improvement:

⚠️ Could have considered the algorithm change - While you eventually focused on the right area (media player), you could have explicitly ruled out the playlist algorithm earlier by asking “Are users skipping songs they don’t like, or stopping mid-song?” to distinguish algorithm vs playback issues
⚠️ Impact quantification - Could have estimated business impact: “With 87% adoption, this affects ~43M users × 14 min lost = X hours of listening lost daily”

Meta-Style Calibration:

• MECE thinking: ✓ Strong (platform segmentation was immediate and complete)
• Stating “why”: ✓ Strong (connected each data request to hypothesis)
• Systematic approach: ✓ Excellent (segment → time → version isolation → behavior → technical root cause)
• Data-driven: ✓ Excellent (every hypothesis tested with specific data)

Meta readiness: 90% - To reach 95%, practice explicitly stating alternative hypotheses before testing (e.g., “This could be algorithm, playback bug, or UI change - let me test each”)

Key Learnings:

The RCA framework you demonstrated:

1. Segment first (platform, user type, geography)
2. Connect timing to changes (deployments, launches, external events)
3. Isolate the variable (version comparison to prove causation)
4. Drill into behavior (what users are actually doing differently)
5. Trace to technical cause (connect behavior to system change)
6. Explain mechanism (full causal chain from bug to metric)

Pattern recognition:

• Sudden drops (5 days, specific time) → Look for deployments/changes
• Platform-specific issues → Compare versions, check platform-specific code
• Behavior changes (skipping) → Something degraded the user experience
• User complaints spike → Validates the technical finding

Next Steps:

1. Practice hypothesis stating - Before testing, explicitly say: “This could be A, B, or C - let me test A first because…”
2. Try a hard marketplace RCA - Work on two-sided dynamics and feedback loops
3. Practice business impact quantification - Always estimate: “This costs us X hours of engagement, worth $Y in ad revenue”
4. Time-pressured practice - Do 2-3 RCAs with 12-minute timer to build speed
5. Try Google-style RCA - Focus on user impact and A/B test validation thinking

You’re ready for medium-difficulty RCA questions at Meta, Google, or similar companies!

═══════════════════════════════════════════════════════════════

How to Use This Example

Study the pattern:

• Notice how the candidate bundled questions (platform + timing)
• Observe the logical flow: segment → isolate → behavior → cause
• See how each hypothesis was stated with reasoning
• Learn how to connect technical changes to user behavior to metrics

Apply to your practice:

• Start every RCA with segmentation (platform, user type, geography)
• Always ask about timing and recent changes together
• Use comparison groups to isolate effects (new version vs old version)
• Drill into behavior before assuming technical causes
• Explain the full mechanism, not just “there’s a bug”

Key frameworks to remember:

• Sudden drops → Deployments, launches, external events
• Gradual drops → Competition, seasonality, product-market fit erosion
• Platform-specific → Compare versions, check platform code
• Segment-specific → User behavior differences, different feature usage

Would you like me to generate another example with different parameters (e.g., hard difficulty, marketplace scenario, B2B SaaS, or with specific company calibration)?