Data Science Mock Interview: 20 Questions in 50 Minutes

Although you write SELECT first, the database logically processes FROM and JOIN first, then WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY and finally LIMIT. This explains common errors: you cannot use a SELECT alias in WHERE because WHERE runs before SELECT, but you can use it in ORDER BY. Window functions are computed after WHERE and GROUP BY, so filter on them in an outer query.

A Series is a one-dimensional labelled array: one column of values with an index. A DataFrame is a two-dimensional table made of several Series that share the same index, and each column can have its own dtype. Selecting one column, like df['price'], gives you a Series. Selecting with a list, like df[['price']], gives you a DataFrame. Many methods work on both, but the output shape is different.

Split the data into k folds, train on k−1 folds and validate on the remaining one, rotate and average the scores. It gives a more reliable estimate than one split and helps tune hyperparameters without touching the test set.

The model memorises noise and fails on new data. Prevent it with more data, simpler models, regularisation, cross-validation, early stopping and dropout.

Calibration checks whether predicted probabilities match real frequencies (e.g. 70% predictions are right about 70% of the time). Fix with Platt scaling or isotonic regression.

The novelty effect is when users engage more with a change simply because it is new, so early results overstate the long-term lift. The primacy effect is the opposite: existing users resist change at first, so early results understate it. Both fade with time. To detect them, plot the treatment effect by day and by user tenure, compare new users with existing users, and run the test long enough for behaviour to settle.

Power transforms reshape a skewed feature to look more normal. Box-Cox needs strictly positive values, while Yeo-Johnson also handles zero and negative values; both learn a lambda parameter from training data. A quantile transform maps values to a uniform or normal distribution by rank, which is robust to outliers. They help linear models, distance-based methods and neural networks, but tree models rarely need them.

Simple exponential smoothing forecasts with a weighted average of past values where weights decay exponentially, so recent points matter more. Holt's method adds a smoothed trend component. Holt-Winters adds a seasonal component as well, either additive or multiplicative. Each component has a smoothing parameter between 0 and 1 that is fitted to the data. These models are fast, easy to explain and strong baselines for retail and demand data.

An iterable can produce an iterator (it has __iter__); an iterator has __next__ and remembers its position. A for-loop calls iter() on the iterable and then next() repeatedly.

Chunking splits documents into smaller pieces before embedding them, so retrieval returns focused passages that fit in the prompt. Small chunks, like 200 tokens, are precise but lose context; large chunks, like 1,000 tokens, keep context but add noise and cost. Split on natural boundaries such as headings and paragraphs, add some overlap, and keep metadata like title and section. Then tune chunk size using retrieval metrics on real questions.

Treated and control buyers compete for the same sellers' supply, so a treatment that makes treated buyers buy more takes inventory from control buyers, exaggerating the measured lift. Use designs that limit interference: switchback tests that alternate the whole market between variants over time slots, or randomise by city or region. Analyse at the switch or cluster level with appropriate variance, and accept that these tests need longer to reach power.

First measure the gap with a labelled Hinglish test set. Hinglish mixes scripts and spellings, so tokenisers built for English split it badly. I would try a multilingual or Indic model such as mBERT, XLM-R or IndicBERT, normalise common spellings, and add labelled Hinglish data, possibly with transliteration. Evaluate per language segment and monitor the language mix in production, because it changes over time.

I would ask them to wait for the planned duration. Checking early and stopping on the first significant result, called peeking, inflates false positives. Two days also misses weekly patterns and novelty effects, where users click a new feature just because it is new. If speed matters, we can use a sequential testing method designed for early stopping. Otherwise we run the full sample size calculated before launch.

Random k-fold mixes future and past rows, so the model trains on data from after the period it predicts. That leaks information and inflates scores. Use time-based splits instead: train on an expanding or rolling window and validate on the next period, like TimeSeriesSplit in scikit-learn. Leave a gap between train and validation when features use lagged values, so the test reflects real forecasting conditions.

First check the data processing agreement, data residency and retention terms, and India's DPDP Act requirements with legal. Minimise what is sent: mask or tokenise names, phone numbers, Aadhaar and card numbers before the call, and restore them afterwards if needed. Use enterprise endpoints with no training on your data, log access, and consider a self-hosted open model for highly sensitive workloads.

Situation: new analysts kept misusing two similar revenue columns. Task: reduce repeated questions and errors. Action: I wrote a short data dictionary for our main tables, with definitions, known pitfalls and sample queries, and linked it in the team wiki and onboarding checklist. I updated it whenever schemas changed. Result: onboarding time dropped, and the number of revenue mismatches in reports fell noticeably within a quarter.

Situation: sales leaders wanted an LLM to auto-send pricing quotes to clients. Task: guide them to a safe plan. Action: I demoed real failure cases where the model invented discounts, showed accuracy numbers from a test set and proposed a draft-and-approve flow with fixed price data from our system. Result: they agreed, quote drafting time fell by half, and no wrong prices reached clients.

Situation: during my internship I was building a monthly sales report. Task: make sure numbers were correct before sharing. Action: I compared order counts per day and noticed one day had double the usual orders. A GROUP BY on order_id showed every order that day appeared twice because a load job had run twice. Result: I reported it, the data team removed duplicates and added a uniqueness check. Now I always validate row counts.

Situation: a team wanted to launch a feature after a test showed a 6 percent lift. Task: as the reviewing data scientist, validate it. Action: I found that assignment was triggered after users clicked into the feature, so treatment had only engaged users. I explained the selection bias simply, proposed assigning at app open, and helped rerun it. Result: the true lift was under 1 percent, and we added assignment checks to the review template.