Data Scientist Interview Questions

First, I'd investigate why data is MNAR - is it due to user behavior, system failures, or privacy concerns? For MNAR data, simple imputation can introduce bias. I'd consider: 1) Creating a missing indicator variable to capture the missingness pattern as a feature, 2) Using domain knowledge for informed imputation (e.g., if income is missing for privacy, it might indicate higher earners), 3) Multiple imputation techniques like MICE that can handle MNAR mechanisms, or 4) Model-based approaches that explicitly account for the missing data mechanism. I'd also consider if the feature is truly critical - sometimes feature engineering can create proxies. The trade-off is between introducing bias through naive imputation versus losing information through deletion. I'd validate my approach by comparing model performance and checking if the missingness pattern correlates with the target variable.

95% accuracy could be misleading, especially with imbalanced datasets. I'd first examine the confusion matrix and calculate precision, recall, and F1-score for each class. For business context, I'd ask about the cost of false positives vs false negatives - in fraud detection, missing actual fraud (low recall) might be costlier than false alarms. I'd plot ROC and PR curves to understand performance across thresholds. To improve the model: 1) Address class imbalance using SMOTE, class weights, or threshold tuning, 2) Feature engineering - create interaction terms, polynomial features, or domain-specific features, 3) Try different algorithms or ensemble methods, 4) Hyperparameter tuning using cross-validation, 5) Collect more training data, especially for minority classes. I'd also check for data leakage and ensure proper train/validation/test splits. Finally, I'd implement proper monitoring to track model performance over time as data distributions may shift.

I'd start by defining clear success metrics: primary (click-through rate, conversion rate), secondary (user engagement time, revenue per user), and guardrail metrics (user retention, diversity of recommendations). For experimental design: randomly split users 50/50, ensuring stratification by key segments (new vs returning users, demographics). Sample size calculation: using historical CTR variance and desired minimum detectable effect (e.g., 2% relative improvement), I'd calculate needed sample size for 80% power and 5% significance level. I'd run the test for at least one full business cycle to account for weekly patterns. For significance testing, I'd use two-sample t-tests for continuous metrics and chi-square tests for proportions, applying Bonferroni correction for multiple comparisons. I'd also check for novelty effects by monitoring metrics over time and ensure no interaction effects between user segments. Before concluding, I'd validate results aren't driven by outliers and consider practical significance alongside statistical significance.

At my previous company, I discovered through customer segmentation analysis that our assumed 'high-value' customers were actually less profitable due to higher support costs. The marketing team initially resisted this finding. I scheduled a presentation and avoided technical jargon, instead using a simple analogy: 'Imagine customers as different types of cars - some look expensive but have high maintenance costs.' I created clear visualizations showing customer lifetime value minus service costs, and used concrete dollar amounts rather than statistical measures. I provided actionable recommendations: shift marketing spend from acquisition to retention for truly profitable segments. To ensure buy-in, I involved them in the solution design and ran a small pilot to validate findings. I also created a simple dashboard they could use to monitor the new metrics. The result was a 15% improvement in marketing ROI. The key was making the data story relatable, showing clear business impact, and involving stakeholders in the solution rather than just presenting conclusions.

I was tasked with building a churn prediction model for a subscription service. My initial approach used standard features like usage frequency and payment history, achieving only 65% accuracy with high false positive rates. Rather than immediately trying different algorithms, I stepped back to understand the business context better. I conducted interviews with customer success teams and discovered that customer support interactions were actually strong predictors of churn - something not captured in my original dataset. I also learned that seasonal usage patterns were important for certain customer segments. I redesigned my approach: incorporated support ticket sentiment analysis, added seasonal features, and segmented models by customer type. This improved accuracy to 78% with significantly fewer false positives. The experience taught me to always start with business understanding before diving into technical solutions, and that domain expertise often trumps algorithmic complexity. I now make it a practice to involve business stakeholders in the feature engineering process and validate my assumptions early through exploratory data analysis.

While working on a customer analytics project, I had to combine data from our CRM, payment processor, web analytics, and customer support system. Each had different customer IDs, timestamps in different formats, and conflicting information about customer status. I started by creating a comprehensive data profiling report, documenting inconsistencies and missing data patterns. I worked with engineering teams to understand each system's data capture logic and identified that web analytics used session-based IDs while CRM used email-based matching. I built a robust ETL pipeline with multiple validation checkpoints: schema validation, referential integrity checks, and business rule validation (e.g., registration dates before first purchase). For conflicting data, I established a hierarchy of truth based on data source reliability and recency. I created automated data quality dashboards and set up alerts for anomalies. I also maintained detailed documentation and worked with data governance to establish ongoing data quality standards. This systematic approach reduced data inconsistencies from 25% to under 3%, and the resulting customer 360 view became a critical business asset used across multiple teams.

I would first acknowledge my initial disappointment privately, then focus on the positive outcomes. I'd reach out to the other team to understand their approach and see if there are opportunities to collaborate or if my higher-accuracy model could still add value. I'd schedule a meeting with my manager to discuss lessons learned about project prioritization and communication. For example, I might suggest implementing regular cross-team syncs to avoid duplicate work. I'd also document my model's methodology and results for future reference, as the techniques could be valuable for other projects. Rather than viewing this as wasted effort, I'd frame it as an opportunity to improve our team's project coordination processes.

I would explain that artificially inflating scores could lead to worse outcomes for Group B and potential legal issues. I'd first investigate the root cause - examining whether we have sufficient training data for Group B, checking for proxy features that correlate with demographics, and analyzing if our feature selection inadvertently disadvantages this group. I'd propose several ethical alternatives: collecting more representative training data for Group B, using fairness-aware algorithms like equalized odds or demographic parity constraints, or developing separate models optimized for each group. I'd also suggest implementing bias testing in our ML pipeline and establishing fairness metrics alongside accuracy metrics. Throughout this conversation, I'd emphasize that true fairness requires understanding why the disparity exists rather than masking it, and I'd collaborate with the stakeholder to define what fairness means in our specific business context.

I'd design a hybrid system combining collaborative filtering and content-based approaches. For the architecture, I'd use a two-tier system: a fast retrieval layer using approximate nearest neighbors (like Faiss) to get candidate items in <100ms, followed by a ranking layer using gradient boosting or neural networks for final scoring. For cold start users, I'd implement popularity-based recommendations and leverage demographic/geographic data for initial clustering. For cold start items, I'd use content-based features and category-based recommendations. The system would include offline batch processing for model training and feature engineering using Spark, real-time feature stores (like Redis) for user session data, and A/B testing framework for continuous optimization. I'd deploy using microservices with auto-scaling capabilities and implement fallback mechanisms. Key metrics would include CTR, conversion rate, diversity, and latency. For real-time performance, I'd precompute user embeddings and use caching strategies for popular items.

I once had to explain a customer churn prediction model to a VP who preferred intuition-based decisions. Instead of starting with technical details, I began with a business story: 'Imagine we could identify which customers are likely to leave next month and proactively reach out to save them.' I used simple analogies - comparing the model to how experienced sales reps intuitively spot at-risk customers, but at scale. I presented the results with clear business impact: 'This model identified 1,000 at-risk customers last month. Our retention team reached out to 200, saved 120, generating $50K in prevented revenue loss.' I addressed skepticism by showing model validation: 'We tested this on historical data - it correctly predicted 8 out of 10 customers who actually churned.' I also acknowledged limitations and provided a pilot plan with clear success metrics. The key was focusing on ROI and actionable insights rather than statistical metrics like precision and recall.

I'd evaluate this based on several key factors: the company's long-term data strategy, budget constraints, time-to-value needs, and competitive advantage requirements. In-house capabilities offer better institutional knowledge retention, faster iteration cycles, and deeper integration with business processes. However, they require significant investment in hiring, training, and infrastructure. External partners bring specialized expertise and can deliver faster initial results but may lack deep business context and create dependency. My recommendation would be a hybrid approach: build core analytical capabilities in-house for strategic, recurring analyses that directly impact competitive advantage, while leveraging external partners for specialized projects or to handle capacity spikes. For example, maintain in-house customer analytics and product optimization teams, but outsource specialized projects like computer vision or NLP implementations. This approach allows for knowledge transfer from consultants while building internal competency. I'd also recommend starting with external partners for proof-of-concepts, then transitioning successful initiatives to internal teams.

I'd start by conducting stakeholder interviews to understand their specific concerns and current decision-making processes. Common issues include lack of trust in model outputs, unclear business value, or models that don't fit existing workflows. I'd implement several strategies: First, create 'data science champions' in each department by identifying early adopters and providing them with extra support and training. Second, develop better communication materials - instead of showing accuracy metrics, I'd present business impact dashboards showing ROI and key outcomes. Third, I'd establish regular 'lunch and learn' sessions to demystify our methods and share success stories. Fourth, I'd work with stakeholders to design models that integrate seamlessly into their existing processes, rather than requiring workflow changes. For example, if sales teams resist a lead scoring model, I'd embed recommendations directly into their CRM system. I'd also implement feedback loops where stakeholders can report when recommendations don't align with their experience, helping us improve model relevance and build trust over time.