Interview guides · Banco Santander

Banco Santander Data Scientist Interview Questions & Guide 2026

Practice explaining analysis before a Banco Santander data scientist interview: the recommendation, the uncertainty, the follow-ups.

The 60-second brief

As a Data Scientist at Banco Santander, you will be stepping into a pivotal role at one of the world's largest and most influential financial institutions. Data is the lifeblood of modern banking, and your work will directly impact how the bank manages risk, prevents fraud, and personalizes the financial experience for millions of global customers. You will not just be analyzing data; you will be building the intelligent engines that drive strategic business decisions across multiple retail and corporate banking divisions.

Learn the economics of the product category before the loop. Marketplaces, subscription products and ad-supported products turn on different core quantities (match rate and liquidity, retention and churn, fill rate and yield) and fail in different characteristic ways.

Focus areas

Separate authorization, settlement and dispute outcomes cleanly
Report only matured cohorts for loss metrics
Read vintage curves, not blended portfolio averages

Overview

The impact of this position is immense, touching everything from real-time transaction monitoring systems to advanced credit scoring models. By leveraging massive, complex datasets, you will help the bank optimize its product offerings, streamline operations, and protect vulnerable users from financial crime. Your models will be deployed at an enterprise scale, meaning the solutions you engineer must be robust, compliant, and highly performant.

Expect a role that balances deep technical rigor with high-level strategic influence. You will tackle ambiguous problem spaces, requiring you to translate vague business challenges into concrete machine learning solutions. Whether you are embedded in the risk modeling team or the customer analytics hub, you will find a dynamic environment where your technical expertise directly translates into measurable global impact.

The Banco Santander interview process

Banco Santander candidates report 2 rounds · ≈ 2-4 weeks. The stages below are what candidates describe, not a published process.

Initial Interview

Rounds outside the standard loop often open with something deliberately under-specified: a loose business problem, an open question about a product area, a dataset described in one sentence. The common failure is surveying, listing six plausible approaches and committing to none of them. The thing that separates a strong answer is scoping out loud. State what you are treating as the goal, name the metric you would move, say what you are choosing not to do and why, then take one path through to an actual answer. An interviewer can follow you down a narrow path. Nobody can grade a menu.

What to demonstrate

Whether you turn an ambiguous prompt into a stated question with a measurable outcome before doing any work
The judgement visible in what you cut, and whether you say why you cut it rather than silently dropping it
Whether you land on a concrete recommendation with its caveat attached, rather than an unranked set of options

How to prepare

Take three vague prompts, such as 'is this feature working', 'why did retention drop', and 'should we expand into a new segment'. For each, write one sentence of goal, one primary metric with its window, and two things you are explicitly not doing.
Practise giving the recommendation first and the reasoning second, in five minutes. Loosely defined rounds are usually time-boxed, and an answer that arrives last often does not arrive.
Keep a running assumption list as you talk, on paper or in the shared doc, so the interviewer can challenge one assumption instead of your whole answer.

Technical Deep Dive

Before anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.

What to demonstrate

Whether an ambiguous term becomes a specific column and filter before any computation happens
Whether you read the schema for keys and cardinality rather than only for column names
Whether the result answers the question at the grain it was asked at, per user or per session or per day

How to prepare

Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over

Where candidates lose points

Using written premium as the denominator of a loss ratio

Premium is written at inception and earned pro rata across the exposure period, so in a growing book written premium runs ahead of earned premium and the loss ratio comes out too low, with the error reversing when the book shrinks. The numerator has the mirror-image problem if it omits incurred-but-not-reported reserves, since recent accident periods then look profitable twice over. Both sides must refer to the same exposure period, which is what an accident-period view at a fixed development age enforces.

Reading the most recent months of fraud and dispute rates as final

Consumer dispute rights commonly run around 120 days from the transaction or expected delivery date, and several reason codes run considerably longer, so the disputes belonging to a recent transaction month have simply not been filed yet. Any chart attributed by transaction date therefore slopes down at the right edge regardless of what is happening. The fix is to report only matured cohorts, or to apply development factors estimated from completed months and to show the estimate as an estimate.

Generalising beyond the population the sample actually supports

State the frame the sample was drawn from and where it diverges from the population you want to talk about: time window, platform, geography, opt-in. If a group is excluded from the frame, either weight to known margins or narrow the claim rather than quietly extending it.

Dropping rows with missing values without naming the mechanism

Say whether the values are missing at random, missing by a known process, or missing in a way that depends on the outcome, and handle them accordingly. Deleting incomplete rows silently redefines the population whenever missingness correlates with what you are measuring.

Questions & practice

How do you handle multicollinearity in a multiple linear regression model?

Medium · machine learning and modelling

Approach

Set a baseline first, so any model has something honest to beat.
Pick an evaluation metric that matches the cost of each error type, not a default.
Check what information would not exist at prediction time, and exclude it.

Follow-up

How would you choose the decision threshold, and who owns that choice?
Where could label leakage enter this setup?

Walk me through how you would build a model to predict customer default on a personal loan.

Medium · machine learning and modelling

Approach

Say how the offline result would be validated online before it is trusted.
Frame the prediction: the label, the moment of prediction, and the action it triggers.
Pick an evaluation metric that matches the cost of each error type, not a default.

Follow-up

How would you choose the decision threshold, and who owns that choice?
Where could label leakage enter this setup?

Simulate false alarms in a merchant chargeback monitoring rule

Medium · simulation · rare events · monitoring thresholds

Baseline matured first-chargeback rate is 12 per 10,000 settled transactions. A monitoring rule alerts when a merchant's observed monthly rate exceeds twice baseline. For monthly settled transaction counts of 500, 2,000, 10,000 and 50,000, simulate the false-alarm probability per merchant-month under the baseline, and the power to detect a merchant whose true rate is 30 per 10,000. Then, for a portfolio of 4,000 merchants split 60, 25, 10 and 5 percent across those four counts, give the expected number of false alarms per month.

Approach

Recognise the rule is a threshold on an integer count, not on a continuous rate. At n = 500, twice baseline is 24 per 10,000, so the first observable value above it is 2 chargebacks, or 40 per 10,000. Derive the trigger count for every n before simulating anything.
Draw binomial counts with numpy at p = 0.0012 and take the share at or above the trigger for the false-alarm rate, then repeat at p = 0.0030 for power. Use at least 200,000 draws per cell so a probability near 0.001 has a usable standard error.
Cross-check every simulated cell against the Poisson approximation with lambda = n*p, which is tight here because p is tiny. A mismatch almost always means the trigger count is off by one.
Weight the per-merchant false-alarm probabilities by the portfolio mix, and report the share of expected alerts contributed by each size band rather than only the total.
Close on the operating consequence: a fixed multiplicative threshold is not a constant false-alarm rate across merchant sizes, so either the threshold scales with n or small merchants need a minimum volume before the rule applies.

Worked solution (30 min)

For each n, compute trigger = floor(2 * 0.0012 * n) + 1 and print the four values before simulating.
Simulate 200,000 binomial draws per n at p = 0.0012 and take the share at or above the trigger.
Repeat at p = 0.0030 and record power for the same triggers.
Compute the Poisson tail 1 - CDF(trigger - 1, lambda = n*p) for both p values and confirm agreement within Monte Carlo error.
Multiply the false-alarm probabilities by 2400, 1000, 400 and 200 merchants and sum.

Expected result: Trigger counts of 2, 5, 25 and 121. False-alarm probability roughly 12 percent at n = 500, roughly 10 percent at n = 2,000, under 0.1 percent at n = 10,000 and effectively zero at n = 50,000. Power against 30 per 10,000 roughly 44, 72, 85 and above 99 percent. Expected false alarms about 390 per month, with over 99 percent of them coming from the two smallest bands.

Verify it yourself

The four trigger counts are derived, not guessed: each is the smallest integer strictly above 0.0024n, giving 2, 5, 25 and 121. Derive them in exact or integer arithmetic, because 20.0012*10000 evaluates to 23.999999999999996 in binary floating point and floor-plus-one silently returns 24.
Simulated probabilities match the Poisson tail at lambda = n*p within about two Monte Carlo standard errors.
Power exceeds the false-alarm rate at every n; if it does not, the null and alternative rates are swapped.
Doubling the draw count moves each probability by less than its own simulated standard error.

Follow-up

How would you set a threshold that holds the false-alarm rate roughly constant across merchant size?
The rule reads the transaction month, but disputes arrive for up to 120 days afterwards. What does that do to the alert and how would you fix it?
What does a month of these false alarms cost, and how would you decide whether it is worth paying?

Write a function to compute the cosine similarity between two user-profile vectors.

Medium · sql and data manipulation

Approach

Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Check whether any join is one-to-many before aggregating, or the sums inflate.
State the window function and its partition and ordering out loud before writing it.

Follow-up

How does the query change if the join becomes one-to-many?
How would you verify this result without re-running the same query?

Explain the difference between an INNER JOIN and a LEFT JOIN, and provide a scenario where you would use each.

Medium · sql and data manipulation

Approach

Say which table is the grain you start from, and join outward from it.
Compute rates by summing numerator and denominator separately, never by averaging rates.
Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.

Follow-up

How would you verify this result without re-running the same query?
How does the query change if the join becomes one-to-many?

Write a SQL query to calculate the 7-day rolling average of daily transaction volumes.

Medium · sql and data manipulation

Approach

Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Check whether any join is one-to-many before aggregating, or the sums inflate.
Say which table is the grain you start from, and join outward from it.

Follow-up

What breaks if events arrive late or out of order?
How does the query change if the join becomes one-to-many?

Attribute chargebacks to transaction month without fanning out

Medium · fan-out · cohort attribution · maturity

Report the matured first-chargeback rate. Numerator: fct_card_dispute rows whose dispute_stage is first_chargeback, representment, pre_arbitration or arbitration, attributed to the requested_at month of the linked fct_payment_authorization row rather than to opened_at. Denominator: settled authorizations in that same transaction month, meaning settled_at is not null and is_reversal is false. One authorization can carry more than one dispute case. Report only transaction months whose last day is at least 120 days old, and mark the remainder incomplete rather than showing them as low.

Approach

Compute the denominator from fct_payment_authorization alone, grouped by the requested_at month, before any dispute table is mentioned, so the join cannot touch it.
Compute the numerator as a separate aggregate: join disputes to their authorization only to recover requested_at, then count dispute rows per transaction month with the stage filter.
Join the two aggregates on the month key, which keeps the grain at one row per month and makes double counting structurally impossible rather than something you have to remember.
Apply the maturity gate on the month's last day plus 120 days against the current date, because a transaction on the final day of the month is the least mature one in the cohort.
Emit an explicit status column of 'final' or 'incomplete' instead of filtering immature months away silently, so a reader cannot mistake absence for zero.

Worked solution (30 min)

CTE denom: SELECT date_trunc('month', requested_at) AS txn_month, COUNT(*) AS settled_txns FROM fct_payment_authorization WHERE settled_at IS NOT NULL AND NOT is_reversal GROUP BY 1.
CTE numer: join fct_card_dispute to fct_payment_authorization on auth_id, filter dispute_stage to the four stages at or beyond first_chargeback, group by the same txn_month expression, count dispute rows.
LEFT JOIN numer onto denom on txn_month so months with zero disputes appear as zero rather than disappearing.
Derive the rate with a numeric cast and a status column driven by (txn_month + interval '1 month - 1 day') + interval '120 days' <= current_date.

Expected result: One row per transaction month with settled_txns, chargeback_cases, a rate in basis points, and a status of 'final' or 'incomplete'. The final months form a roughly flat series; the incomplete months at the right edge are visibly and correctly labelled rather than sloping to zero.

Verify it yourself

settled_txns for a given month is identical whether or not the dispute CTE is joined, which is the direct test that no fan-out occurred.
COUNT(DISTINCT auth_id) in the numerator is at or below the dispute row count; if they are equal, no authorization in the data carries two cases and the fan-out risk is latent rather than absent.
Every month flagged 'final' has its last day at least 120 days before the current date.
Attributing by opened_at instead shifts the series later and flattens the right edge, which demonstrates why the attribution key matters.

Follow-up

Should the numerator count dispute cases or disputed authorizations? Which one reconciles to the loss line, and which one to the operations queue?
Some reason codes allow filing well beyond 120 days. How would you estimate the tail on a month you have decided to call final?
How would you present the incomplete months so that a weekly reader does not read the right-hand slope as an improvement?

How would you optimize a Python script that is running too slowly on a large dataset?

Medium · product sense and metrics

Approach

Decompose the metric into the rates that drive it, and say which one you would check first.
Restate the decision this analysis has to support, and who acts on the answer.
State what result would change your recommendation, so the answer is falsifiable.

Follow-up

Which segment would you cut first, and what would that rule out?
What would you do if the primary metric and the guardrail moved in opposite directions?

We want to launch a new premium credit card. How would you identify which existing customers to target?

Medium

Approach

Work from the decision backwards to the evidence you would need.
Clarify what is being asked and what a complete answer would contain.
State your assumptions explicitly before working the problem.

Follow-up

How would you know your answer was wrong?
What assumption would you test first?

Build the metric tree for a new instalment loan

Medium · metric tree · vintage analysis · leading indicators

A new instalment loan product launches next quarter. Build the metric tree from fct_loan_application and fct_loan_performance_monthly: one primary metric, the intermediate metrics that explain it, and the guardrails. The product owner wants a go or no-go call six weeks after the first disbursements, while the primary outcome is defined at twelve months on book. Name the leading indicator you would accept for the six-week call, state its bias in one sentence, and say what you would refuse to conclude from it.

Approach

Put the primary where the trade is real: risk-adjusted margin per 1,000 units of principal originated, evaluated at months_on_book = 12, charging funding cost at the internal transfer rate. Approval rate and origination volume can both be moved in a week by lowering the cutoff, and neither charges anything for the consequence.
Lay the tree out by layer so a movement can be localised: approval rate on a decision-reaching denominator (decision in ('approve','decline'), excluding withdrawn and expired) feeds offer-to-funded conversion within 30 days by offered_apr_bps band, which feeds the vintage 90+ rate at months_on_book = 12, which feeds risk-adjusted yield on average balances. Each layer's denominator is the numerator of the layer above.
Choose guardrails that catch the opposite failure to the primary's. A margin target is trivially met by shrinking the book to its safest slice, so report approval rate within each model_pd_12m band, where that collapse shows up first, alongside adverse-impact monitoring of the decision rule under compliance review.
For the six-week call, accept first-payment behaviour: the share of funded loans missing the first scheduled payment, or reaching days_past_due at or above 30 by months_on_book = 3. Estimate its relationship to the 12-month 90+ rate from completed vintages of the nearest comparable product, and report the dispersion of that ratio across those vintages as the uncertainty rather than quoting a point estimate.
State the bias in one sentence: early default is loaded toward application fraud and income misstatement and is close to blind to affordability deterioration that develops over months, which is the failure mode a new product with a new population is most likely to have, and the historical ratio breaks exactly when the population or the macro environment changes.
Say what six weeks cannot answer: nothing about the 12-month level in absolute terms, and nothing whatsoever about the applicants the policy declined.

Worked solution (35 min)

Write each metric in the tree as numerator, denominator, exclusions and window, four lines each, before writing any SQL.
Build a vintage table from fct_loan_performance_monthly with origination_month as rows and months_on_book as columns for an existing comparable product, and read the diagonal as calendar time.
For the last eight to twelve complete vintages, compute both the 30+ rate at months_on_book = 3 and the 90+ rate at months_on_book = 12, take the ratio, and record its minimum, median and maximum.
Write the six-week readout using that ratio range as an interval, with the one-sentence bias statement attached to the number itself rather than to a footnote.

Expected result: A four-layer tree whose primary is risk-adjusted margin at months_on_book = 12, plus a six-week readout that converts an observed three-month 30+ rate into a range for the twelve-month 90+ rate using the historical ratio's dispersion, labelled as an estimate with its bias stated inline.

Verify it yourself

Every denominator in the tree is the numerator of the layer above it. If one is not, a movement cannot be attributed to a layer.
The ratio between the three-month and twelve-month rates varies across vintages. If your data shows it constant, confirm you are not comparing cohorts at unequal maturity.
Restructured loans enter the 90+ numerator on their pre-restructure worst state, because restructuring resets days_past_due and would otherwise erase the event.

Follow-up

The first vintage looks excellent at three months on book. What would make you distrust it?
How do restructured loans enter your twelve-month numerator?
Which metric in this tree would you refuse to put on a weekly dashboard, and why?

Fraud losses appear to halve in recent transaction months

Medium · right censoring · development factors · maturity

A weekly chart attributes fct_card_dispute cases to the requested_at month of the linked fct_payment_authorization row. The two most recent months show the first-chargeback rate falling by half, and a risk rule shipped six weeks ago. Columns: dispute_id, auth_id, dispute_category, dispute_stage, opened_at, disputed_amount_minor, liability_shift_flag, outcome, net_loss_minor, resolved_at. Decide whether the rule worked, and produce the version of the chart you would sign your name to.

Approach

Separate the two dates explicitly. opened_at is when a case was filed, requested_at is when the transaction happened. Attributing by transaction month is the right causal choice and is exactly what makes the newest months structurally incomplete.
Measure the filing lag rather than assuming it: the distribution of opened_at minus requested_at over fully developed months, split by dispute_category, and the age at which around 95 percent of cases have arrived.
Build a development triangle of transaction month by months of development on cumulative case counts, and estimate age-to-age factors from the columns that are complete.
Develop the immature months with those factors and plot the result as an estimate with a visible band, kept visually distinct from the matured series rather than blended into it.
State the assumption the method needs: a stable development pattern across cohorts. A change in filing behaviour, merchant mix or the dispute team's own backlog breaks it, so inspect factor stability down each column before relying on the estimate.
Only then evaluate the rule, comparing pre-change and post-change cohorts at equal development age.

Follow-up

What leading indicator would you accept while the cohort matures, and what is its known bias?
How does liability_shift_flag change which disputes you should expect to see in the first place?
If the rule also blocked good transactions, where does that cost appear, and is any of it in this chart?

Suggested practice checklist

For someone who can already write the query and train the model but stalls when asked what to measure or whether a change is worth making. Metric definition and case structure come first; the technical work is kept as maintenance rather than the centre of the week.

Day 1 — Metric anatomy

For three products you use daily, write one primary metric, two input metrics that plausibly move it, and one guardrail that would catch a cheap way of moving the primary at the cost of the product.
For one of them, specify the metric precisely enough that two analysts would return the same number: numerator, denominator, unit of observation, time window, and how returning and deleted accounts are treated.
Pick a ratio metric and write what happens to it when the denominator shrinks for reasons unrelated to the numerator, with a concrete example of that happening.

Deliverable: A one-page metric tree for one product, with the primary metric written as an unambiguous spec.

Day 2 — Diagnosing a drop without guessing

Take the prompt "weekly active users fell 8 percent week over week" and write the segmentation plan before proposing any cause: platform, region, tenure cohort, acquisition channel, and whether the movement sits in the numerator or in a changed denominator.
List the instrumentation failures that manufacture fake drops (a client release that stopped firing an event, a bot filter change, a shifted date boundary or timezone) and write the query that rules out each one.
Rehearse stating the boring explanations first, seasonality and day-of-week composition, before reaching for a product cause.

Deliverable: A drop-diagnosis checklist short enough to recite from memory in under a minute.

Day 3 — Should we build it

Take a feature idea and write it as a bet: what you believe is true, what would have to be true for it to pay off, the metric that would confirm it, and the effect size that would justify the engineering cost.
Size the opportunity top-down and bottom-up, then reconcile the two numbers in writing instead of quoting whichever is friendlier.
Write the counter-metric that would make you kill the feature even if it wins on the primary metric.

Deliverable: A one-page product memo ending in a decision rather than a list of considerations.

Day 4 — The places aggregate numbers lie

Construct a Simpson's paradox numerically: two segments where the treatment wins within each segment yet loses overall, and identify the shift in segment weights that causes it.
Take a heavy right-tailed quantity such as revenue per user and write why the mean is the wrong summary, which percentile you would report instead, and what a moving mean with a stable median tells you.
Write your definition of a session for the product from day one, then name two real behaviours it misclassifies.

Deliverable: One page holding a worked Simpson's paradox table and a session definition with its two known failure cases.

Day 5 — Technical maintenance, aimed at metrics

Solve four timed SQL prompts that all end in a ratio metric, so the question of grain stays live in every answer.
Compute a 95 percent confidence interval for a proportion on a small sample, and state why the normal approximation is unreliable when either np or n(1 minus p) falls below roughly 10, along with which interval you would use instead.
Take one metric from your day-one tree, write the query that computes it correctly, then write the query that computes it wrong in the most plausible way and explain how you would notice.

Deliverable: Four solved prompts plus a matched correct and plausible-wrong query for one metric.

Day 6 — Turning engineering work into data science stories

Write three project stories as situation, decision, trade-off, outcome, each carrying one number and one thing you got wrong.
For the story you will lead with, prepare an answer to "what would you do differently" that names a decision you made, not a constraint you were handed.
Practise the sentence that reframes a systems project as a question project: the question the work answered, ahead of the pipeline it shipped.

Deliverable: Three written stories with the lead story delivered aloud and timed under four minutes.

Day 7 — Mock case and gap list

Run a 40-minute mock case with someone playing a product manager who pushes back on your metric choice, and record it.
Listen back and mark every moment you proposed a solution before the success metric existed.
Rewrite those moments as the question you should have asked, and rehearse the first 90 seconds of the case until scoping comes before solving.

Deliverable: A recorded case plus a rewritten opening 90 seconds.

Rigour against a deadline

Nearly every data role forces a trade between the analysis you want and the one that fits the decision window. Prepare a case where you deliberately shipped something less rigorous, named the weakness to the person relying on it, and said what would change your answer. The naming is the part interviewers listen for.

Describe a time when your data analysis contradicted a stakeholder's gut feeling. How did you handle it?

Medium · behavioural and stakeholder questions

Approach

Pick a story where you drove the decision, not one where you observed it.
Close with what you would do differently, concretely.
State the situation in two sentences and spend the rest on your reasoning.

Follow-up

How did you know the outcome was caused by your change?
What would you do differently if you ran that project again?

How do you handle categorical variables with high cardinality in a machine learning pipeline?

Medium · behavioural and stakeholder questions

Approach

Close with what you would do differently, concretely.
State the situation in two sentences and spend the rest on your reasoning.
Name the disagreement or constraint, and how you resolved it with evidence.

Follow-up

What would you do differently if you ran that project again?
How did you know the outcome was caused by your change?

Turn a one-line fraud-number request into a scoped brief

Easy · scoping · metric definition · denominators

A stakeholder messages: what is our fraud rate, and is it going up? You have fct_payment_authorization, fct_card_dispute and dim_customer. At least four defensible answers exist: count-weighted or value-weighted, attributed to the transaction month or to the dispute filing month, and gross or net of recoveries and successful representments. You get one reply before someone else produces an uncaveated number. Write that reply: the clarifying questions you ask, the single default you will produce if nobody answers, and what the default excludes.

Approach

Establish the decision behind the question first, because a risk-rule change, a board number and a merchant contract negotiation need different denominators, and asking which one is not stalling.
Offer a short menu rather than an open question: a stakeholder can choose between two named options but cannot specify a denominator from scratch.
Commit to a default so the reply is useful even if nobody answers, for example net fraud loss in basis points of settled volume, attributed to the requested_at month, matured months only.
State the exclusions in the same breath as the default: non-fraud dispute categories, transaction months with less than 120 days of maturity, and first-party abuse that arrives coded as consumer_dispute.
Give a delivery time for the default and a longer one for the fuller cut, so the choice between them carries a visible cost.

Follow-up

They come back wanting it by merchant for a contract negotiation. What changes in the definition and in the maturity rule?
How would you separate first-party abuse from third-party fraud in this data, and what would you refuse to conclude from the split?