Data Science Interview Questions

My favorite way to explain it is the moment every data scientist has lived: training AUC 0.95, validation AUC 0.71. That gap IS variance: the model memorized noise that does not generalize. The mirror image is both scores stuck low and close together, say 0.72 and 0.71: that is bias, the model is too simple to capture the signal. Bias is error from wrong assumptions, variance is error from sensitivity to the training sample, and total error trades one against the other. In practice I diagnose before I treat: learning curves tell me which side I am on. High variance calls for regularization, more data, or a simpler model; high bias calls for richer features or more capacity. Naming the diagnostic, not just the definitions, is what separates a senior answer.

I usually explain it like this: imagine a world where the thing you're testing has zero effect. If you ran the same experiment in that world, how often would you see results as surprising as what you actually got? A p-value of 0.03 means: if there was truly nothing going on, you'd only see data this extreme by chance 3% of the time. It's not "97% chance this works" - it's a measure of how strange your results would be if the effect wasn't real. The lower it is, the more suspicious you should be that something genuine is happening.

The cleanest approach uses a window function:

SELECT DISTINCT salary FROM (SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk FROM employees) t WHERE rnk = 2

I prefer DENSE_RANK over a simple offset because it handles ties correctly - if two people share the highest salary, this still returns the second distinct value. The classic subquery alternative - SELECT MAX(salary) FROM employees WHERE salary < (SELECT MAX(salary) FROM employees) - works in simple cases but breaks with ties and doesn't scale to the Nth highest without rewriting it entirely.

The core difference is mutability: a list can be changed after creation - add, remove, reorder - while a tuple is fixed. I reach for a list when I'm building something up over time, like collecting predictions as they stream in. I use a tuple for things that should stay constant: coordinates, RGB values, a row from a database result. The practical payoff of tuples beyond just convention is that they're hashable - you can use them as dictionary keys or set members, which you can't do with a list. They're also slightly faster and signal intent: when I see a tuple in someone else's code, I know they meant it to be read-only.

I start with the hypothesis before touching any data: what change am I making, what metric should move, and in which direction? Then I define the minimum detectable effect - the smallest improvement that would actually matter to the business - because that drives sample size. I run a power analysis with 80% power and α = 0.05, check how long it'll take to collect that traffic, and set a fixed end date. Once it's running I do not peek at results early - peeking inflates false positives even when the underlying data is clean. At the end I check baseline balance between groups, analyze the primary metric, then check guardrail metrics to confirm nothing else broke. I present the result in terms of the business decision, not just whether p < 0.05.

I start by asking what the feature was supposed to do for the user and for the business - those don't always overlap, and the right metric lives at their intersection. Then I define one primary metric that directly reflects that value, plus one or two guardrail metrics to make sure I'm not trading something important away. If the feature is a recommendation module meant to increase engagement, my primary metric might be click-through rate on recommendations, and my guardrail is that overall satisfaction or session length doesn't drop. I also separate short-term engagement signals from longer-term retention signals - a feature can look great in week one and quietly hurt retention at month three. And I always ask whether the metric I'm watching is something I can actually attribute to this feature, or if other things are moving it.