Capital One Data Scientist Interview Guide

It's four tasks, back to back, and they build on each other: some basic analysis first, then you pull a bunch of split files into one clean table, then you preprocess that table, then you train a model on it. They're scored independently though, so a stumble early doesn't sink the rest.

The early tasks are honestly pattern-matching once you've done one — read files, combine, group, aggregate. Where I actually lost time was the merge-heavy one. I kept fixing one join and accidentally breaking another, going in circles. The fix was dumb-simple in hindsight: do all your merges in one continuous block instead of running them piecemeal across different cells. When you run them piece by piece you keep overwriting your own progress. Chain them together and it just works.

The preprocessing task is where you lose points to wording, not skill. The instructions have small traps baked in — the difference between "round to nearest" and "round down" is a different function and a wrong answer. Read every step literally. The scaling step also has a convention gotcha: the grader expects a slightly different standard-deviation calculation than the obvious library default, so if your scaled numbers are off by a tiny constant amount, that's the tell — switch the calculation and it lines up. And watch the column names generally; there are typos planted in the data.

The modeling task was the smooth part for me. The thing that matters is understanding what the metric actually rewards and tuning for that rather than accepting defaults — check performance across a range of settings on the validation set, then pick the one that optimizes what they're grading, not what the library hands you automatically.

Real talk on difficulty: the data science thinking is not the hard part. The hard part is environment friction and reading carefully — the specs have traps, the data has typos, and small details decide pass/fail. Budget your first couple of minutes on each task just reading before you write any code.

Go in expecting the traps, keep your merges in one block, and don't trust defaults on the graded metric — you'll be fine.

Questions asked: Capital One DS

Four tasks, sequential, each building on the last output. Scored independently.

Basic analysis — combine split files, compute a few aggregate stats (an average, a couple of percentages/rates), write results to a CSV in a fixed format. Multi-file merge — join drivers + cars + split ride files into one table per driver. Derived columns: days-since-a-date, experience from a start year, summed upvote flags per driver. Left joins throughout so nobody drops.

Preprocessing (leakage-safe) — fill missing values with a train statistic, ordinal-encode categoricals, standard-scale a numeric column, map a class label to 0/1. All stats fit on train, applied to test. Partial scoring per step.

Modeling — classifier predicting driver class; metric was recall-focused with a precision floor. Threshold tuning on the validation set was the key move.

What cost me time / lessons:

Merge task: run all joins in one block, not piecemeal across cells — piecemeal overwrites progress. Spec wording traps: round-to-nearest vs round-down are different functions; read each step literally. Scaling: grader used sample std (ddof=1), not the library default — tiny constant offset is the tell. Planted typos in column names — always print columns first. Don't accept the default decision threshold when the metric rewards recall.

Takeaway: the DS thinking wasn't the bottleneck — spec-reading and environment friction were. Budget the first ~2 min per task just reading.