How to answer DS video prompts

A strong way to answer all five prompts is to use a modified STAR structure: - **Situation**: Brief context. - **Task**: What you needed to accomplish. - **Action**: What you specifically did. - **Result**: Quantified outcome if possible. - **Reflection**: What you learned or would do differently. Because each answer is only about 2 minutes, aim for roughly: - 20 seconds of context - 60-70 seconds on your actions - 20-30 seconds on results - 10 seconds on lessons learned ## 1) Problem solved using Python or R What the interviewer wants: - Can you apply programming to a real problem? - Do you understand data cleaning, analysis, modeling, or automation? - Can you explain impact, not just tools? Strong answer structure: - Problem and business/research goal - Why Python/R was appropriate - Libraries or techniques used - Result and impact Good example points: - Built a churn prediction model in Python using pandas, scikit-learn, and XGBoost - Automated a reporting pipeline in R using dplyr and ggplot2 - Cleaned messy experimental data and reduced manual work by several hours per week What makes an answer stronger: - Mention tradeoffs: speed vs interpretability, simple baseline vs complex model - Mention validation: train/test split, cross-validation, precision/recall, calibration - Mention stakeholder value: saved time, improved decision-making, increased accuracy Sample outline: - "In a customer retention project, we wanted to identify users likely to churn. I used Python because the data volume was moderate and we needed both feature engineering and modeling. I cleaned transaction and engagement data with pandas, engineered recency and frequency features, and trained a logistic regression baseline before comparing it with gradient boosting. I evaluated performance using AUC and recall at a fixed precision threshold because the business cared more about catching at-risk users without over-contacting too many customers. The final model improved recall by 18% over the baseline, and the insights were later used to prioritize retention campaigns." ## 2) Situation where you used SQL What the interviewer wants: - Can you retrieve and manipulate data independently? - Do you understand joins, aggregations, filtering, and data quality? - Can you connect SQL work to a business question? Strong answer structure: - Business question - Tables/data sources used - SQL operations you performed - Insight or output produced What to mention: - Joins across fact and dimension tables - Window functions for rankings, running totals, retention, deduplication - CTEs for readability - Handling nulls, duplicates, date filters, and metric definitions Sample outline: - "I used SQL during a product analytics project to analyze user conversion through a signup funnel. I joined event logs with user profile tables, filtered by acquisition date, and built CTEs to calculate step-level drop-off rates. I also used window functions to identify each user's first qualifying event so that we would not double count repeat activity. The analysis showed that most drop-off happened at the verification step, which helped the team prioritize a form redesign." A weak answer says only "I wrote queries." A strong answer shows: - why the query mattered - how you ensured correctness - what decision it informed ## 3) Project with little context What the interviewer wants: - Can you operate in ambiguity? - Do you break down vague problems into solvable pieces? - Can you avoid common failure modes like optimizing the wrong metric? This is especially important in data science because many projects start with unclear goals, noisy data, and stakeholder disagreement. Strong framework: 1. Clarify the objective 2. Identify stakeholders and constraints 3. Define success metrics 4. Start with simple exploratory analysis 5. Iterate with feedback 6. Document assumptions and risks Important concepts to mention: - Ambiguity reduction through stakeholder interviews - Proxy metrics when the primary metric is delayed or unavailable - Guardrail metrics to avoid local optimization - Selection bias or confounding if data is observational Sample outline: - "I once joined a project where the request was simply to 'improve engagement,' but no one had defined which users or which behavior mattered. I first met with stakeholders to understand the decision they wanted to make. Then I translated the vague request into measurable questions: which segment was underperforming, what engagement event mattered, and over what time window. I conducted exploratory analysis, proposed a primary metric and two guardrail metrics, and documented assumptions such as seasonality and new-user mix. After reviewing early findings with the team, we narrowed the scope to activation among first-week users. That made the project actionable and prevented us from optimizing a metric that was too broad to be useful." This answer is stronger if you mention: - how you handled missing data - how you prevented scope creep - how you aligned on success criteria early ## 4) Explain a technical project to a non-technical audience What the interviewer wants: - Can you translate technical work into business language? - Do you understand what actually matters to stakeholders? - Can you avoid jargon without losing accuracy? Best approach: - Start with the business problem, not the algorithm - Use plain language and analogies - Focus on decisions and outcomes - Avoid unnecessary technical detail unless asked Bad version: - "I trained a gradient boosted ensemble with engineered features and hyperparameter tuning." Better version: - "We built a system that helps identify which customers are most likely to leave, so the business can intervene earlier and spend retention resources more efficiently." Simple communication structure: 1. Problem 2. What data you used 3. What your solution does in plain English 4. What decision it improves 5. Limitations or caveats Sample outline: - "I would say: our goal was to predict which customers were likely to cancel soon, so the team could focus outreach where it would matter most. We looked at patterns like how recently people used the product and whether their activity was dropping. The model then assigned a risk score to each customer. This did not guarantee someone would churn, but it helped us rank customers by risk and target interventions more effectively. As a result, the business had a clearer way to prioritize retention efforts." Bonus points if you mention audience tailoring: - Executives care about impact and risk - Product managers care about actions and tradeoffs - Engineers may care about implementation and reliability ## 5) Keeping everyone aligned in a team project What the interviewer wants: - Can you collaborate effectively? - Do you create clarity around roles, timelines, and decisions? - How do you handle disagreements? Strong framework: - Set a shared goal early - Clarify owners and deliverables - Establish communication cadence - Use written documentation - Surface risks early - Resolve disagreements with data and decision criteria Good details to mention: - Weekly check-ins or standups - Shared project tracker or task board - Written metric definitions - Decision logs to prevent confusion - Escalation when blockers appear Sample outline: - "In a team project, I helped keep everyone aligned by first making sure we agreed on the problem statement, timeline, and success metric. We created a shared task tracker with clear owners and deadlines, and I scheduled short weekly check-ins to review progress and blockers. When there was disagreement about approach, I tried to bring the conversation back to the project objective and available evidence. I also summarized key decisions in writing so everyone had the same understanding. This reduced duplicate work and helped the team deliver on time." ## What separates great answers from average ones Great answers usually include: - Specific examples rather than generic statements - Quantified impact - Clear personal contribution - Evidence of judgment under uncertainty - Awareness of tradeoffs and limitations - Communication adapted to audience Average answers often fail because they: - Sound too rehearsed or too vague - Focus only on tools, not impact - Describe what the team did without your role - Skip the result - Overuse jargon ## Final interview tips - Prepare 2-3 reusable stories that can be adapted to multiple prompts. - Make sure each story highlights a different strength: technical depth, ambiguity handling, communication, collaboration. - Keep answers concrete: what was the problem, what did you do, what happened? - If you lack internship experience, use class projects, research, hackathons, or student organizations. - Practice speaking naturally, not memorizing exact wording. - End with a short takeaway, such as: "That experience taught me how important it is to define metrics early when the problem is ambiguous."