Data Leakage

Data leakage means your model accidentally learns from information it won't have in production, making it look great in testing but fail in the real world — and you'll learn exactly how to spot and fix it.

The 97% Accuracy Lie

Picture this: you're building a feature for EngineerPrep that scores how likely a candidate is to pass a mock interview. You pull historical data — past sessions, question difficulty, answer length, timestamps — and train a classifier. You split the data into training and test sets, run evaluation, and the accuracy comes back at 97%. You feel great. You open a pull request. But wait. A week after you deploy, the predictions are garbage. Users are getting "high chance of passing" scores right before they fail badly. You go back and stare at the numbers. The test set accuracy was real — you measured it correctly. The model genuinely did predict that data with 97% accuracy. So why is it failing in production? The answer is data leakage. Not a bug in your code. Not bad luck. A subtle mistake in how the training data was prepared…

The Simple Idea

Imagine you're studying for a test. The night before, your friend who wrote the test accidentally texts you the exact questions. You memorize the answers and score 100%. Was that a fair measure of what you know? No — you had information you shouldn't have had. Data leakage is exactly that, but in a machine learning pipeline. Data leakage happens when your model is trained on information that it won't actually have when it runs in production. The model learns patterns from that extra information, scores well on your test data, and then falls apart on real data — because the real world doesn't hand out the answers in advance. Let's make it concrete. Say you're training a model to predict whether a candidate will pass an interview.…

See It in Action

Imagine a simple table. Each row is one EngineerPrep mock-interview session. The columns are: session id , question difficulty , answer length words , total attempts before passing , and passed (yes/no). Step 1 — The raw data sits in the database. Every column is populated because this is historical data. For every row, you already know whether the candidate passed. The total attempts before passing column is filled in for everyone. What you're looking at: a complete, fully-known past. Nothing is hidden. Step 2 — You feed all columns to the model. You include total attempts before passing as a feature because, hey, it looks related to passing. The model trains. It notices: "when total attempts before passing is 1, the person always passed." Of course — if someone needed only one attempt, they passed on the first try. The column is the answer.…