Interview Questions — IPL Sports Analytics¶
Questions an interviewer might ask about this project.
[Beginner] This dataset has 250,000 rows of ball-by-ball data. How did you turn that into player-level insights?
Show answer
The raw data is one row per ball. To get player stats, I aggregated with GROUP BY:
- Batsman runs:
SUM(batsman_runs)grouped bybatter - Balls faced: count of deliveries excluding wides/no-balls
- Strike rate:
runs / balls_faced × 100
The key challenge was the cricket-specific logic — a wide isn't a ball faced by the batsman, and a run-out isn't a wicket credited to the bowler. Getting these definitions right was more important than the SQL itself. I created flag columns (is_ball_faced, is_bowler_wicket) during cleaning so the aggregations stayed clean.
[Beginner] Why did you exclude wides and no-balls when calculating strike rate?
Show answer
Strike rate measures how fast a batsman scores per ball they face. Wides and no-balls are bowling errors — the batsman doesn't "face" them in the official sense (they don't count toward the batsman's ball count). Including them would unfairly inflate the denominator and understate the strike rate.
This is a domain knowledge point: knowing the rules of the data is as important as knowing SQL. If I'd naively counted all deliveries, every strike rate would be wrong.
[Mid-level] You found that winning the toss only correlates with a 51.5% win rate. How would you present this to a stakeholder who "knows" the toss is crucial?
Show answer
I'd lead with the data but acknowledge the intuition:
"It feels like the toss is decisive — and at 51.5%, the toss winner does win slightly more often. But the edge is tiny, about 1.5 percentage points above a coin flip. What actually matters is the decision after the toss: teams that choose to field first (chase) win 53.5% vs 48.2% for batting first.
So the insight isn't 'the toss doesn't matter' — it's 'the toss matters because of the chasing advantage it unlocks, not the toss itself.'"
This reframes their belief rather than contradicting it, which keeps them receptive. I'd back it with the sample size (950 matches) so they trust it's not noise.
[Mid-level] How would you handle the fact that some players have very few balls in a specific matchup, making the stats unreliable?
Show answer
Small samples are the biggest trap in sports analytics. A batsman who's scored 20 off 10 balls against a bowler looks dominant but it's statistically meaningless.
My approach: 1. Set minimum thresholds: only show matchup stats with ≥30 balls faced. Below that, flag as "insufficient data." 2. Show the sample size: always display "based on 42 balls" so users can judge reliability themselves. 3. Use confidence intervals or shrinkage: for a more advanced version, shrink small-sample estimates toward the player's overall average (empirical Bayes). A batsman with 30 balls against a bowler gets an estimate pulled partway toward their career strike rate. 4. Communicate uncertainty in the product: "limited data" badges prevent users from over-trusting noise.
[Mid-level] Walk me through how you'd calculate a bowler's economy rate correctly.
Show answer
Economy rate = runs conceded per over bowled.
The subtleties: - Runs conceded includes the batsman's runs plus wides and no-balls (the bowler's fault), but NOT byes and leg-byes (those are the keeper/fielder's responsibility, not the bowler's). - Overs bowled = legal balls / 6. Wides and no-balls don't count as legal balls (they're re-bowled).
Where bowler_runs = batsman_runs + (extra_runs if extras_type IN ('wides','noballs') else 0).
Getting the byes/leg-byes exclusion right is what separates a correct analysis from a plausible-looking wrong one.
[Senior] PlayPredict wants to build a model that predicts how many fantasy points a player will score in an upcoming match. How would you approach this?
Show answer
This is a regression problem (predicting a continuous points value). My approach:
1. Define the target: fantasy points per match, using the platform's scoring rules (runs, wickets, catches, etc.).
2. Feature engineering — the heart of the project: - Recent form: rolling average points over last 5/10 matches - Phase-specific stats: death-over SR, powerplay economy - Matchup: historical performance vs the opposition team - Venue: player's record at this venue + venue's scoring tendency - Role and batting position - Home/away - Rest days / fatigue (matches in last 7 days)
3. Model choice: start with a gradient boosting model (XGBoost/LightGBM) — handles non-linear interactions well and is interpretable via feature importance. A linear baseline first to set the bar.
4. Evaluation: time-based split (train on past seasons, test on the most recent) — never random split for time-series, or you leak future info. Metric: MAE on predicted points.
5. The honest caveat: cricket has enormous variance. Even a great model explains maybe 30-40% of the variance — a single match is highly random. I'd frame the output as "expected points with a confidence range," not a precise prediction, and validate that high-projected players actually outscore low-projected ones over many matches (calibration).
[Senior] The product team wants to show "Player X is in great form" badges. How do you define "form" rigorously, and what are the risks?
Show answer
Defining form: Form is recent performance relative to the player's own baseline. A simple, defensible definition:
Above 1.2 = "hot", below 0.8 = "cold". I'd use points (or runs/wickets) and require a minimum number of recent matches.Risks: 1. Regression to the mean: a player on a hot streak is likely to cool off. Labelling them "hot" might lead users to buy high right before a decline. The badge should describe the past ("scored well recently"), not predict the future ("will score well"). 2. Small samples: 5 matches is noisy. One big innings inflates the index. 3. Context blindness: good "form" against weak bowling isn't the same as against strong bowling. A naive form index ignores opponent quality. 4. Self-fulfilling behaviour: if everyone picks the "hot" player, their fantasy value inflates, reducing the edge.
I'd validate the badge empirically: do players flagged "hot" actually outscore "cold" players in their next match? If the predictive lift is near zero, the badge is entertainment, not analytics — and I'd be honest with the product team about that.