Capital One Data Scientist Interview Guide: Cases, SQL, and Experiments

Capital One hires Data Scientists into different teams and levels, so one candidate's interview schedule is not a reliable blueprint for another. The useful preparation is role-based: confirm the current process, practice business cases with explicit decision rules, write SQL and Python that survive data-quality checks, and explain experiments or models in business terms.

This guide does not promise a particular round order, interview length, scoring system, or question set. Use the current job description and recruiter guidance to decide which preparation modules deserve the most time.

Confirm the role-specific process

Start with the role you actually applied for. "Data Scientist" can describe work centered on experimentation, product analytics, risk modeling, machine learning, or a mixture. The same company can assess those jobs differently.

Ask the recruiter or scheduling contact questions that change how you prepare:

Clarification	Why it matters
Which conversations or assessments are scheduled?	Establishes the current loop without relying on old reports
Will any session include live SQL or Python?	Determines whether environment fluency is required
Is there a business case or analytical case?	Signals a need for recommendation and communication practice
Are statistics or experiment design assessed separately?	Helps allocate study time beyond coding
Is machine learning design in scope?	Prevents overpreparing modeling for a primarily analytics role
What tools, languages, or materials are allowed?	Avoids assumptions about the working environment

Do not ask for exact questions. Ask for capability areas and logistics. If the recruiter cannot share topic detail, the job description still provides a useful evidence map: translate each responsibility into one project, decision, or technical example you can discuss.

The Data Scientist interview question guide can broaden your practice set once you know which capabilities are relevant. It should not replace confirmation of the current Capital One process.

Solve the case as a decision, not a calculation

An analytics case needs a recommendation supported by a transparent model. Begin by clarifying the decision owner, objective, constraints, and time horizon. Then define the unit of analysis and write the decision rule before doing arithmetic.

For a fictional case about changing a credit-card fraud alert, a weak answer starts with a machine learning model. A stronger answer first separates the outcomes:

• fraudulent loss prevented;
• legitimate transactions incorrectly interrupted;
• customers who abandon after an alert;
• operational review cost;
• delayed or displaced fraud that the metric could miss.

That framing changes the question from "Can detection increase?" to "Does the change reduce expected loss without creating unacceptable customer and operational harm?"

Use a compact structure under pressure:

Step	What to say
Frame	"The decision is whether to launch, pilot, or stop this change for the target population."
Model	"I will compare expected benefit with customer, risk, and operating costs."
Assumptions	"I need the baseline fraud rate, false-positive cost, and alert response behavior."
Analysis	"I will calculate by customer or transaction segment, not only in aggregate."
Sensitivity	"I will find the value at which the recommendation changes."
Recommendation	"Given these assumptions, I recommend a limited test with these guardrails."

Cases often contain incomplete information intentionally. Do not silently invent missing values. Name the assumption, proceed with a symbol or plausible range, and explain how the result changes across that range. The data science case study guide provides more worked structures for metric diagnosis, product decisions, and model evaluation.

Make SQL and Python auditable

In SQL, correctness starts with grain. Before writing a join, say what one output row represents. A query that should return one row per week can be inflated by joining applications to a one-to-many event table before aggregation.

Here is a complete weekly approval-rate walkthrough. The input is one row per application:

application_id	submitted_at_utc	status
A1	2026-08-03 10:00+00	approved
A2	2026-08-04 12:00+00	declined
A3	2026-08-05 09:00+00	pending
A4	2026-08-10 14:00+00	approved
A5	2026-08-10 16:00+00	approved
A6	2026-08-11 11:00+00	declined

The decision rule is explicit: group by UTC week, count only approved or declined applications in the denominator, and keep the date range half-open so midnight on August 17 is not accidentally included.

SELECT
    date_trunc('week', submitted_at_utc AT TIME ZONE 'UTC')::date AS week_start,
    COUNT(*) FILTER (
        WHERE status IN ('approved', 'declined')
    ) AS decided_applications,
    COUNT(*) FILTER (
        WHERE status = 'approved'
    ) AS approved_applications,
    ROUND(
        100.0 * COUNT(*) FILTER (WHERE status = 'approved')
        / NULLIF(COUNT(*) FILTER (
            WHERE status IN ('approved', 'declined')
        ), 0),
        1
    ) AS approval_rate_pct
FROM applications
WHERE submitted_at_utc >= TIMESTAMPTZ '2026-08-03 00:00:00+00'
  AND submitted_at_utc <  TIMESTAMPTZ '2026-08-17 00:00:00+00'
GROUP BY 1
ORDER BY 1;

The rendered output is:

week_start	decided_applications	approved_applications	approval_rate_pct
2026-08-03	2	1	50.0
2026-08-10	3	2	66.7

The first week has three submitted applications, but only two have a final decision. That distinction is why stating the denominator before writing SQL matters. Also clarify whether timestamps are stored in UTC, how partial weeks are handled, and whether a reapplication creates a new unit.

SQL check	Failure it catches
Compare row counts before and after each join	Accidental fanout
Count distinct business keys	Duplicate entities
Inspect null rates on join keys	Silent row loss
Reconcile numerator with status counts	Incorrect conditional aggregation
Test the first and last date boundary	Inclusive or exclusive range errors
Calculate a small example by hand	A correct-looking but wrong denominator

The SQL for data analysis guide covers aggregation and window patterns, while SQL practice questions can be used to rehearse them against unfamiliar schemas.

In Python, keep data manipulation and modeling logic testable. Separate validation, feature construction, fitting, and evaluation. Check schema and units before converting types. If a task includes train and validation data, fit preprocessing only on the training partition. A scaler, imputer, encoder, or feature selector that learns from the full dataset leaks information even when the model never sees the validation labels directly.

When asked to debug a result, print or inspect intermediate shapes, key uniqueness, missingness, and summary distributions before changing the algorithm. That sequence is usually faster than rewriting a pipeline whose real problem is a duplicated join or shifted unit.

Connect experiments and models to a business choice

An experiment design answer should identify the decision the result will support. Define the randomization unit, exposure rule, primary outcome, guardrails, analysis window, and major interference risks. Then explain what you would do for a positive, negative, or inconclusive result.

For the fraud-alert example, randomizing individual transactions might create confusing mixed experiences for the same customer. Customer-level randomization may be cleaner, but it changes sample size and variance. If alerts affect a shared merchant or household, even customer-level treatment may not eliminate interference. The correct unit depends on the mechanism.

Avoid using approval rate alone. A change can approve more transactions by accepting more fraud. Pair the primary customer or loss outcome with guardrails such as confirmed fraud, support contacts, transaction abandonment, manual-review load, and unequal impact across relevant segments.

For an observational model, separate prediction from causal explanation. A feature that improves out-of-sample prediction is not automatically an intervention lever. If the recommendation says changing that feature will change the outcome, explain the causal assumption or propose an experiment.

Communicate results in decision order:

1. recommendation;
2. expected impact and uncertainty;
3. main evidence;
4. risk and guardrail;
5. next measurement or decision point.

Behavioral examples should follow the same discipline. Describe the problem, your decision, the evidence you used, and the result. The STAR method guide can keep context concise, but it should not turn a technical discussion into a memorized script.

FAQ

What questions does Capital One ask Data Scientist candidates?

Question content can vary by role, team, level, and hiring cycle. Prepare for the capabilities named in the current posting and confirm the scheduled format with recruiting. This guide focuses on common Data Scientist skills rather than claiming a current question list.

Is the Capital One process the same for analysts and Data Scientists?

Do not assume so. Similar analytics titles can emphasize different combinations of cases, SQL, Python, statistics, experimentation, modeling, and behavioral evidence. Use the exact job description and invitation.

How advanced should my SQL be?

Be able to define grain, join safely, aggregate with correct denominators, use window functions, and validate the result. Advanced syntax matters less than producing an auditable answer that handles nulls, duplicates, and time boundaries.

Should I use Python or SQL for an analytics task?

Use the tool requested by the interviewer. If the choice is open, explain it. SQL is often efficient for relational filtering and aggregation; Python is useful for iterative analysis, statistical work, and model pipelines. A strong candidate can move the correct dataset between the two without changing its meaning.

What should I do when a case lacks data?

State the missing input, continue with a symbol or bounded assumption, and show what value would change the recommendation. Do not invent a precise number or stop the analysis entirely.