05The 60-second brief

A Data Scientist at Wells Fargo plays a pivotal role in shaping the future of banking by leveraging massive datasets to drive strategic decisions, mitigate risks, and optimize customer experiences. As one of the largest financial institutions in the world, Wells Fargo relies on data science to solve highly complex problems across diverse business lines, including consumer banking, corporate risk, wealth management, and fraud prevention. In this role, you will not simply build models; you will translate vast, multi-structured financial and behavioral data into actionable intelligence that impacts millions of customers daily.

Wells Fargo candidates report 5 rounds · ≈ 4-6 weeks. The stages below are what candidates describe, not a published process.

06What a Data Scientist does at Wells Fargo

The work of a Data Scientist here is highly collaborative and carries significant responsibility. You will design, develop, and deploy predictive models and machine learning algorithms that directly influence credit decisioning, detect fraudulent transactions in real-time, and personalize financial products. Because Wells Fargo operates in a heavily regulated industry, your models must not only be highly accurate but also robust, transparent, and compliant with strict financial governance standards. This balance of cutting-edge innovation and rigorous risk management makes the position both intellectually challenging and highly impactful.

Whether you are optimizing marketing campaigns, analyzing customer journeys, or developing sophisticated risk-scoring algorithms, you will work with advanced technologies and cloud-based data platforms. Successful data scientists at the firm are those who possess a strong quantitative foundation, exceptional coding skills, and the ability to articulate complex technical concepts to non-technical business partners. It is a career path that offers the scale of a global financial giant alongside the opportunity to drive meaningful technological transformation.

07The Wells Fargo interview process

Wells Fargo candidates report 5 rounds · ≈ 4-6 weeks. The stages below are what candidates describe, not a published process.

Recruiter Phone Screen

A screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.

What it evaluates

• Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
• Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
• Whether timeline, location and compensation expectations make the rest of the loop worth scheduling

How to prepare

• Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
• Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
• Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice

Technical Assessment

This round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.

What it evaluates

• Whether your row counts survive each join, and whether you notice on your own when they do not
• Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
• Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
• Reaching a defensible answer inside the window instead of a refined one after it

How to prepare

• Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
• Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
• Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither

Take-Home Assignment

Before any modelling, the dataset is itself the first test. Take-home data usually carries something broken: rows duplicated at an unexpected grain, a join that silently drops part of the population, timestamps stored in more than one timezone, or missingness correlated with the outcome. An hour spent profiling row counts, key uniqueness and date ranges is not overhead, because it decides whether every number after it is real. What separates submissions is whether you report the defects you found and adapt the analysis to them, rather than modelling over them quietly and hoping the aggregate absorbs it.

What it evaluates

• Whether you established the grain of each table and checked row counts after every join, and said so in the writeup
• Whether data defects you found are surfaced with their effect on the conclusion, instead of being dropped without comment
• Whether filters and exclusions are reproducible from the submitted code, with the size of the excluded population quantified

How to prepare

• Write a short profiling script you can point at any unfamiliar table: row count, distinct key count, null rate per column, and the min and max of every date field, then run it before anything else
• Write the funnel or the join chain as one query and check the row count at each grain, so a silent fan-out shows up as a number rather than as a wrong answer later
• On a past dataset, list every exclusion you applied and how many rows each one removed, then draft the single sentence about it you would put in a report

Onsite Interview Rounds

Where a loop ends with a senior leader, that conversation is rarely another skills test. The technical signal already exists by then, so the questions tend to open up: what you would look at first, where a metric you have heard about could mislead, what you would push back on. The decision being made is scope, which in practice means level and how much you would be trusted to own unsupervised. Treating it as a formality is the usual mistake. An open question late in the day is still being scored, and a vague answer reads as someone who has not run anything themselves.

What it evaluates

• Whether your view of the business has anything specific behind it, given that you are working only from what is public and are expected to say so
• Whether the scope of work you describe owning matches the scope of the role, instead of sitting a level below it
• Whether you can disagree with something concrete and stay useful about it, rather than agreeing with everything said in the room
• Whether your questions are ones only this person could answer, as opposed to ones the recruiter already covered

How to prepare

• Build one view you could defend for two minutes using only public information: what the funnel probably looks like, which metric likely drives decisions, and where that metric could mislead. Being wrong for a stated reason survives this round; having no view does not
• Write down the largest piece of work you have owned from question to decision, who else touched it, and what you decided alone, then check that it reads at the level you are interviewing for
• Prepare one thing you would want changed if you joined and phrase it as a question rather than a verdict, so it opens a conversation instead of closing one

Behavioral Interviews

Most of the weight in this round sits on the disagreement questions. Data work routinely produces an answer someone senior did not want, and the interviewer is trying to learn what you do in that hour. Both failure modes are common: folding as soon as a director pushes back, and treating the pushback as ignorance to be corrected with a better chart. A strong answer usually contains a specific thing the other person knew that you did not, and describes how you found out whether it changed the conclusion.

What it evaluates

• Whether you can state the other side's argument accurately before you explain why you disagreed
• What you treated as evidence during the disagreement, such as a rerun under their assumption or a holdout check, rather than persuasion technique
• Whether you distinguish being overruled from being wrong, and can give an example of each

How to prepare

• Write out one disagreement where you turned out to be wrong, and say what in the data misled you. Candidates prepare the story where they were right, and the follow-up asks for the other one.
• For your main disagreement story, be ready to say what result would have made you drop your position. If no such result exists, you were not arguing from the data.
• Practise stating the opposing position out loud in one sentence the stakeholder would accept, then continue the story.

08Questions Wells Fargo candidates report

These are the prompts PracHub has collected for this role and company. They are a record of what candidates describe being asked, so treat them as the shape of the conversation rather than a script Wells Fargo works from.

Product sense and metrics

Every question in this group starts from the same move: name the outcome the product is supposed to produce, then name the number that would show it happening. Work forward from the mechanism, not backward from a metric you already like. Ask what behaviour changes, for whom, and how soon, and only then pick the measure that sits closest to that behaviour without being trivially satisfied by it. What usually separates answers is the counterfactual. A candidate who says what result would make them call the change a failure has defined success; one who only describes what going well looks like has not.

• How do you prioritize your tasks when managing multiple data science initiatives with competing deadlines?
• If we launch a new credit card product, how would you estimate its adoption rate and predict customer churn in the first six months?
• Imagine a scenario where a key business metric suddenly drops. Walk me through your step-by-step diagnostic process to identify the root cause.

SQL and data manipulation

These questions are rarely hard to solve and easy to get subtly wrong in the minutes available, so how you spend the clock is part of the answer. Write the filter and the spine, run it, look at ten rows, then add one layer and run again. That costs seconds and catches the errors that otherwise arrive as a plausible number you cannot defend. Keep the last minute for checks that fit on one line: row count against distinct key count, funnel stages that should only shrink, and nulls where a left join found nothing. Say out loud what you checked.

• If you were given a raw dataset from a platform like Kaggle, what are the first five steps you would take to clean, explore, and prepare the data for training?
• Given a database of customer transactions, write a SQL query to find the top 5% of customers by transaction volume over the last quarter.
• Walk me through a code snippet containing a common logical error or optimization bottleneck and explain how you would resolve it.

A/B testing and experimentation

The standard analysis assumes one unit's treatment cannot affect another unit's outcome. Say that assumption out loud, then ask where it breaks in the setting you were handed: shared supply, a shared budget, a ranking that reorders when other people click, any two-sided market where the arms compete for the same inventory. Interference does not merely add noise, it biases the estimate, and where the arms compete for scarce supply it usually flatters the treatment because the control group absorbs the cost. The answer that lands names the channel the spillover travels through, then changes the design rather than the test.

• How would you design an A/B test to evaluate a new feature in the Wells Fargo mobile banking application?

Statistics and probability

Treat a hypothesis testing question as an audit of preconditions rather than a request for a procedure. Every test carries a model of how the data were generated, and the useful part of your answer is where that model could be wrong here. Independence fails most often and gets checked least: repeated measurements on one user, or many sessions inside a single account. When units inside a cluster move together, the naive variance understates the true one and the test rejects a true null far more often than its stated level. Name the unit you are willing to call independent before you name a test.

• Explain the difference between bagging and boosting. In what scenarios would you prefer one over the other?

Machine learning and modelling

A model that clearly improves offline can move nothing online, and the useful question is why. The candidate set feeding it may already exclude the cases it would have caught. The score may enter a surface where a cap, a fallback or a business rule blunts it. Training labels may describe a population the live traffic no longer matches, because they were collected under an earlier policy. Treat the offline number as a filter rather than as proof, plan the launch as a measured rollout with a guardrail and a rollback, and say which of those gaps you would check first.

• Share an experience where a model you deployed did not perform as expected in production. What did you learn, and how did you address the issue?

Behavioural and stakeholder questions

A large share of these land on disagreement: someone wanted a different answer, a different metric, or a different date. The weak version of the answer makes the other person wrong and the data right. The strong version treats their position as a constraint you had not priced in, usually a cost, a deadline, or a commitment made outside your view. Before you say what changed their mind, say what evidence would have changed yours. That one sentence separates someone who argues with numbers from someone who reasons with them, and it is the sentence that survives the follow-up.

• Walk me through a complex data science project you led from conception to deployment. What challenges did you face, and how did you overcome them?

09Practice exercises with worked solutions

The prompts above tell you what gets asked. These are PracHub exercises written to drill the same skills, with the reasoning spelled out so you can check your own answer instead of guessing whether it was good enough.

Collapse merchant retry chains before measuring authorization approval

Merchant retry logic turns one declined purchase into several rows in fct_payment_authorization. Collapse attempts into chains: inside a partition of (card_token_id, merchant_id, amount_minor), consecutive rows whose requested_at gap is 15 minutes or less belong to the same chain. Return one row per chain with chain_started_at, attempt_count, amount_minor, channel, and chain_outcome set to 'approved' when any attempt in the chain was approved. Then report a 7-day rolling dollar-weighted approval rate by channel over chains rather than attempts. Exclude is_reversal rows.

How a strong candidate works it

• In a CTE, take LAG(requested_at) OVER (PARTITION BY card_token_id, merchant_id, amount_minor ORDER BY requested_at) and set is_new_chain when the previous value is null or the gap exceeds 15 minutes.
• Turn the flag into a chain identifier with SUM(is_new_chain::int) OVER (same partition, same order, rows unbounded preceding to current row), which is the standard gaps-and-islands construction.
• Aggregate to one row per chain: MIN(requested_at), COUNT(*), and BOOL_OR(auth_result = 'approved') as the chain outcome, because the purchase succeeded if any attempt in the chain did.
• Roll the chains to a daily grain per channel, then apply the rolling window as PARTITION BY channel ORDER BY chain_date RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW. An interval-offset RANGE frame is value-based: it admits every row in the partition whose chain_date falls in the closed window [D - 6 days, D], so a channel with no chains on some dates still gets the right seven-day sums — sparsity is exactly what this construct tolerates. ROWS BETWEEN 6 PRECEDING AND CURRENT ROW is the one that needs a dense grain, because it counts rows and on a sparse grain reaches back further than seven days.
• Left-join a dense date spine only if the output needs a row on days with no chains. That is a presentation requirement, not a correctness one, and it leaves every rolling sum unchanged. The RANGE frame's preconditions are that chain_date is a date or timestamp (an interval offset needs an ordering column it can be added to) and that the aggregation left one row per (channel, chain_date).
• Divide approved chain value by total chain value inside the rolling frame, never the average of daily rates, since averaging rates weights a quiet day the same as a heavy one.

Expected result (40 min): A rolling series with one row per date and channel, where the chain count is strictly below the attempt count on ecommerce and recurring, and the chain-level approval rate is at or above the attempt-level rate for every channel, since collapsing removes failed attempts that later succeeded.

Check yourself

• SUM(attempt_count) over all chains equals the filtered attempt row count exactly; if it does not, the chain identifier is not partitioned the same way as the LAG.
• Every chain has exactly one row whose is_new_chain flag is true, so COUNT(DISTINCT chain_id) equals the number of flagged rows.
• A chain whose attempt_count is 1 must have chain_outcome equal to that single row's approved status.
• The rolling denominator on day D equals the sum of the daily denominators over every date present between D-6 and D inclusive — seven terms on a dense grain, fewer on a sparse one, and the same total either way.
• Adding or removing the date spine leaves every rolling sum identical, because spine rows contribute zero. Swapping RANGE for ROWS changes them on any channel whose grain has a gap, which is the direct test of which construct tolerates sparsity.

Follow-ups

• This definition chains off the previous attempt, so a chain can span an hour if attempts arrive every 14 minutes. When is that right, and when would you anchor the window to the first attempt instead?
• Two genuine purchases of the same amount at the same merchant, four minutes apart, collapse into one chain. How large is that error and how would you bound it?
• A channel goes dark for three days mid-window. Which of the two frame types would silently widen, and what would the resulting rate look like?
• What changes if the merchant retries with a slightly different amount to dodge a velocity rule?

Estimate a delinquency roll-rate matrix and project twelve months

fct_loan_performance_monthly gives loan_id, as_of_month_end, months_on_book, delinquency_bucket, charge_off_flag, prepaid_in_full_flag and restructured_flag. Build a month-to-month transition matrix over the five delinquency buckets plus absorbing charged_off and prepaid states. Loans that stop appearing must be routed to an absorbing state rather than dropped. Project the current book forward 12 months by repeated matrix multiplication and report the projected share reaching charge-off. Handle restructured_flag explicitly, and name one place the Markov assumption fails on this data.

How a strong candidate works it

• Build consecutive month pairs per loan by shifting as_of_month_end within loan_id, then verify the shifted value is exactly one month later. A gap is not a transition, it is an exit you have not resolved yet.
• Resolve exits before counting anything. A loan whose last row carries charge_off_flag moves to charged_off, one carrying prepaid_in_full_flag moves to prepaid, and one that disappears with neither is a data question to raise rather than silently discard, because discarding it is survivorship that inflates every cure rate.
• Count pairs into a 7 by 7 matrix and row-normalise. Assert every row sums to one and the two absorbing rows are the identity; a row that does not sum to one means exits were dropped.
• Decide and state the restructure rule. Restructuring resets days_past_due, so a dpd_60_89 to current move on a restructured loan is not a cure. Either give restructured loans their own state or carry the pre-restructure bucket, but do not let that move land in the cure cell.
• Project by taking the current bucket distribution as a row vector and multiplying by the matrix twelve times. Report the charged_off entry, and report it again from an all-current starting vector so the reader can see how much of the projection comes from loans that are already delinquent today.
• State the homogeneity failure plainly: transition rates depend strongly on months_on_book, so one pooled matrix applied to a book with a young mix understates early-life delinquency. If the mix is moving, estimate separate matrices by seasoning band.

Expected result (45 min): A 7 by 7 row-stochastic matrix with identity rows for charged_off and prepaid, a current-to-current diagonal typically above 0.95, roll rates rising with bucket depth, and a 12-month projected charge-off share of a few percentage points from an all-current start and materially higher from the actual book.

Check yourself

• Every row sums to one within floating-point tolerance, and both absorbing rows are exactly the identity.
• No mass sits in cells that skip a bucket upward, such as dpd_1_29 to dpd_60_89 in one month; if there is, the pairs are not actually consecutive months.
• The projection from an all-current start is strictly below the projection from the real book distribution.
• Backtest by estimating on months up to t minus 12 and comparing the projected distribution with the realised one at t; a systematic optimistic gap points at dropped exits or at seasoning, not at noise.

Follow-ups

• How would you validate the projection against what actually happened, and over what window?
• The cure rate out of dpd_30_59 rose five points last quarter. What are the candidate explanations and how would you separate them?
• When would you prefer a vintage curve to a roll-rate projection, and why?

Price a false decline when the label does not exist

Your expected-cost threshold needs a figure for what a false decline costs beyond the margin on the blocked transaction. fct_payment_authorization records the decline, nothing records what the customer did next elsewhere, and declined transactions never produce a fraud outcome, so neither side of the error is directly observable. Propose the measurement: the proxy you would build from the tables you have, the design that yields an unbiased estimate for at least part of the score range, the bias in each, and the single sentence you would attach to the number when it reaches a pricing decision.

How a strong candidate works it

• Write down what is unobservable and why. The counterfactual spend of a customer who was not declined, and the fraud label on any transaction the rule blocked, are both missing because of the decision itself. Missingness that depends on the decision is not fixed by matching on observed covariates.
• Build the observational proxy anyway and be specific. For customers receiving a first risk-rule decline in a window, compare settled volume and active status over the following 30 and 90 days against customers matched on pre-period settled volume, tenure, segment and channel mix who attempted a comparable transaction and were approved. The bias runs one way: matching conditions on having attempted something that scored near the cutoff, and part of the declined group are genuine fraudsters whose disappearance is a saving rather than a loss, so the estimate overstates the damage.
• Buy one unbiased local estimate. Hold a small random share of authorizations inside a defined risk_score band out of the decline rule and approve them, sizing the sample in advance from the expected fraud rate in that band so the cost of the experiment is known before it runs. The result is unbiased for that band only, and it is simultaneously the only source of fraud labels in the declined region.
• Bound the extrapolation instead of hiding it. Run the holdout in two or three adjacent bands and report the spread. If the effect is flat across bands a constant is defensible; if it is steep, quote band-specific figures and decline to supply a single number.
• Handle the window. Attrition after a decline can resolve over months, so a 90-day window truncates it and the randomised estimate is a lower bound on long-run damage at the same time as the observational version is an upper bound. Stating both directions is what makes the number safe to use.
• Write the sentence that travels with the number: what it is (an estimate from a randomised holdout in one score band over a 90-day window), what it is not (a measurement anywhere else on the score range), and which way it is likely to be wrong.

Expected result (40 min): Two numbers with opposite biases, an observational estimate labelled as an upper bound and a randomised in-band estimate labelled unbiased for that band only, plus a sensitivity table showing how p* moves across the range and an explicit statement of whether the residual uncertainty changes the decision.

Check yourself

• If the cost range moves p* by less than the granularity at which the rule can actually be set, further measurement is not worth buying and that is the finding.
• The observational estimate should exceed the randomised one in magnitude. If it does not, the matching is capturing something other than the effect of the decline and needs re-examining.
• Removing customers with zero prior settled volume from both cohorts should shrink the observational estimate, since new-account fraud concentrates there.

Follow-ups

• Compliance and finance both object to deliberately approving transactions you believe are fraudulent. What is your answer, and how do you size the holdout?
• Your interval spans the decision boundary. What do you recommend?
• How would you detect that this number has gone stale?

Settled volume jumps after a new acceptance corridor launches

Settled payment volume per active customer rose 12 percent in the month a new acceptance corridor went live. The pipeline sums settlement_amount_minor from fct_payment_authorization and divides by 100 to get major units. Columns available: amount_minor, transaction_currency, captured_amount_minor, settlement_amount_minor, settlement_currency, settlement_fx_rate, settled_at, is_reversal, issuer_country, acquirer_country. Confirm or refute the 12 percent, and specify exactly the conversion the metric should be using.

How a strong candidate works it

• Split the month-over-month increase by settlement_currency. If one currency carries nearly all of it while its transaction count barely moved, the problem is arithmetic rather than demand, and that is a two-minute check.
• Look up each currency's ISO 4217 exponent. Dividing a three-decimal currency by 100 instead of 1000 overstates it tenfold; dividing a zero-decimal currency by 100 understates it hundredfold. Neither is a rounding issue.
• Rewrite the conversion to scale settlement_amount_minor by ten to the power of that currency's exponent, then convert to the reporting currency. Do not reuse settlement_fx_rate for this; it is the rate applied between transaction and settlement currency at settlement time, not a reporting-currency rate.
• Check the other half of the series too. settlement_amount_minor is denominated in settlement_currency while amount_minor is in transaction_currency, so any series that mixes the two is uninterpretable regardless of the exponent fix.
• Exclude reversals and refunds, recompute, then reconcile the corrected total to the settlement ledger for the same period and show the tie-out in the write-up.
• Recompute the per-customer denominator on the corrected month, since a new corridor adds customers as well as volume and the ratio can move either way once the numerator is right.

Follow-ups

• Where else in the warehouse does a hardcoded divide-by-100 appear, and how would you find every instance?
• What test would fail the build the next time a currency with a different exponent is onboarded?
• The reporting-currency rate is itself a choice. Which rate, on which date, and why does finance care about the answer?

Recommend a decision whose true outcome matures a year later

An underwriting rule change must be decided in six weeks. Its real outcome, the vintage 90-plus rate at months_on_book 12 in fct_loan_performance_monthly, matures in a year. The executive wants a yes or no, not a range. Randomising the credit decision across the whole population is not available. Name the leading indicator you would accept, state its bias and the direction of that bias, define the decision rule and stopping condition before any rollout starts, and say what reading would make you recommend reversing the change.

How a strong candidate works it

• Fix the readout before the rollout, because a readout chosen after the data arrives is a story rather than a decision rule: indicator, window, threshold and reversal condition all go in writing first.
• Choose the leading indicator on its measured relationship to the matured outcome in historical vintages rather than on availability. Early delinquency, typically the share reaching dpd_1_29 or missing a first scheduled payment by months_on_book 3, is the usual candidate, and you quantify how well it predicted the 12-month rate across past cohorts.
• State the bias and its direction plainly: early delinquency under-represents default that emerges later and is contaminated by servicing and payment-date effects, so treat it as a floor on risk rather than an estimate of it.
• Buy identification where full randomisation is unavailable: a narrow randomised approval band around the cutoff, or a staged rollout by channel or region read as a difference-in-differences, with the parallel-trends assumption stated and checked in the pre-period rather than assumed.
• Give the executive the binary they asked for with the trigger attached in the same sentence: yes, conditional on the month-3 indicator staying inside a stated band, with an automatic hold if it breaches.

Follow-ups

• How would you validate that the month-3 indicator predicts the 12-month outcome, and what evidence would invalidate it mid-rollout?
• Compliance refuses a randomised band. What is your next-best identification strategy, and what precision do you lose by taking it?

Defend a vintage finding that contradicts the portfolio dashboard

The lending dashboard shows blended 90-plus days-past-due falling for four consecutive quarters while originations grew 60 percent. Using fct_loan_performance_monthly, you build a vintage view keyed on origination_month by months_on_book and find the three most recent vintages are worse than their predecessors at the same age. The business lead presents that dashboard weekly and pushes back hard, suggesting you picked favourable cohorts. You get one meeting and the vintage table. Present the finding so it survives the cherry-picking objection and ends in a decision.

How a strong candidate works it

• Reconcile before you contradict: show that aggregating your vintage table along the calendar diagonal reproduces the published blended series, so the disagreement is about age mix rather than about data quality.
• Make the mechanism arithmetic rather than rhetorical: a loan cannot reach 90 days past due before it is 90 days old, so rapid origination growth shifts weight onto young months-on-book where the rate is structurally near zero.
• Show every vintage rather than a selected pair, all indexed at months_on_book equal to 12, with cohort sizes printed beside each curve so nobody can claim the divergence rests on a thin cohort.
• Handle restructuring explicitly, because restructured_flag resets days_past_due: count each loan on its worst pre-restructure state, or recent vintages will look better than they are.
• Close on the decision rather than the chart: state what the divergence implies for the cutoff or the channel mix, and state in advance what evidence would make you withdraw the claim.

Follow-ups

• Two cohorts differ at month 12. How do you separate a seasoning effect from a genuine credit-quality effect?
• Someone argues the recent vintages are simply a broker-channel mix shift. How do you test that, and what would confirm it?

10Where candidates lose points

Recalibrating an underwriting cutoff on approved and funded applicants only

Rejected applicants have no repayment outcome, and they were rejected because the incumbent model scored them badly, so the missingness depends directly on the outcome being modelled. Reject inference by augmentation or parcelling fills the gap using the incumbent model's own assumptions, which means it can confirm those assumptions but cannot test them. The only genuinely new information about the reject region comes from bureau performance on rejects who borrowed elsewhere, or from a deliberately randomised approval band around the cutoff.

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.

Analysing at a different unit than the one randomised

Say out loud what was randomised (user, device, account, cluster) and make the analysis unit match, or account for the clustering with cluster-robust standard errors, the delta method, or aggregation up to the randomised unit. Randomising users and then running a test over sessions understates variance and inflates the false-positive rate.

Sizing estimates built on unnamed, unrevisable assumptions

Write each assumption as a named number you can change, then show the arithmetic so the interviewer can challenge one input instead of the whole answer. Finish by saying which assumption the result is most sensitive to, which matters more than the point estimate.

11SQL first, for a candidate whose queries have gone rusty

For someone who has spent the last year in notebooks, dashboards or modelling work and has not written raw SQL under time pressure. The first four days rebuild query fluency against a fixture you control and can verify by hand; the last three attach that fluency to the rest of the loop.

Day 1 — Build a fixture you can check answers against

• Create a local Postgres or SQLite database with four tables (users, sessions, events, orders) holding roughly 200 rows you generated yourself, so you know the contents well enough to predict every result.
• Deliberately seed the cases that break queries: a user with no sessions, a session with no events, two orders sharing a timestamp, a NULL in one join key, and one duplicated user row.
• Before writing any SQL, hand-compute five answers on paper (how many users placed at least one order, median orders per ordering user, and three others) and save them as the ground truth for the week.

Deliverable: A one-command seed script plus a text file of five hand-computed answers to grade every later query against.

Day 2 — Joins, filters and NULL semantics

• Answer "which users have no orders" three ways (LEFT JOIN with IS NULL, NOT EXISTS, NOT IN) and confirm that the NOT IN version returns zero rows once the subquery contains a NULL, because the comparison is never TRUE.
• Reproduce the LEFT JOIN that silently collapses to an inner join by putting a right-table predicate in WHERE, then fix it by moving the predicate into the ON clause, and record both row counts.
• Create a fan-out bug on purpose by joining orders to order_items and summing the order total, then correct it with a pre-aggregated subquery and explain in one line which table changed the grain.

Deliverable: One annotated .sql file holding the three join traps, each with the wrong result and the corrected result side by side.

Day 3 — Window functions and frames

• Write three window queries against the fixture: a running order total per user, the rank of each order within its user by value, and the day gap to that user's previous order, then check each against the day-one ground truth.
• Run ROW_NUMBER, RANK and DENSE_RANK over a column containing ties, print all three side by side, and write one sentence on when each is the correct choice.
• Switch one query from the default frame (RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which is what you get when ORDER BY is present and no frame is written) to ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and explain why the output differs only when the ORDER BY column has duplicates.

Deliverable: Three verified window queries plus a short note explaining the RANGE versus ROWS difference in your own words.

Day 4 — The four analytical query patterns

• Write a monthly retention grid: first order month per user, then months-since-first as the column, and verify that month zero equals the cohort size exactly.
• Sessionize the events table under a 30-minute inactivity rule using LAG plus a cumulative sum over a new-session flag.
• Build a four-step funnel that counts distinct users rather than events at each step, and state the rule you applied to a user who reaches step three without ever logging step two.

Deliverable: One file with the retention, sessionization and funnel patterns, each carrying a one-line note on the assumption it bakes in.

Day 5 — Write SQL the way you will have to write it live

• Set a 12-minute timer and solve three medium prompts in a plain editor with no execution and no autocomplete, then run them and tally syntax errors separately from logic errors.
• Narrate one solution aloud while writing it, stating the grain of each intermediate result (one row per user, one row per user-day) before you type its body.
• Rewrite your slowest solution as a CTE chain where every CTE name states its grain, and time yourself re-solving it from blank.

Deliverable: A recording of one narrated solution plus an error tally that separates syntax from logic.

Day 6 — One day for everything that is not SQL

• Write the preconditions of the two-sample t-test from memory, then check them: independent observations, and a difference in means whose sampling distribution is approximately normal, which at large sample sizes follows from the central limit theorem rather than from normality of the raw values.
• Write the difference between an odds ratio from logistic regression and a relative risk, and state the condition under which the two are close (low outcome prevalence).
• Prepare a 90-second answer to "how would you know this model is any good" that names the metric, the baseline you would beat, and the cost of the errors you care about.

Deliverable: One page of notes covering test preconditions, the odds-ratio caveat and the model-quality answer.

Day 7 — Full loop rehearsal

• Run a 45-minute mock with someone willing to interrupt: 20 minutes of SQL, 15 minutes defining a metric, 10 minutes on a past project.
• Re-solve from blank the two queries you were slowest on this week and compare the times against day five.
• Write a five-line answer to "walk me through a project" that puts a number in the first sentence and names the decision the work changed.

Deliverable: Mock feedback notes plus a timed project narrative you can deliver without reading it.

12Frequently asked questions

Is this an official Wells Fargo interview guide?

No. It is PracHub's own research and practice material for the Data Scientist role at Wells Fargo. Rounds and questions reflect what candidates have reported, not a process Wells Fargo has published, and they change over time. Confirm the current format and scope with your recruiter.

How technical is the interview process for Data Scientists at Wells Fargo?

The process is highly technical but balanced. You will face rigorous evaluations on statistical theory, machine learning algorithms, SQL, and Python coding. However, you will also be heavily assessed on your business acumen, case-solving abilities, and how well you can explain your technical decisions to non-technical stakeholders.

What is the typical timeline from the initial recruiter screen to a final offer?

The interview process generally takes between 3 to 6 weeks, depending on the specific team, location, and seniority of the role. The team works to move candidates through the stages efficiently, keeping you informed of your status after each major round.

What differentiates successful candidates in the Wells Fargo interview process?

Successful candidates are those who demonstrate not only technical brilliance but also an understanding of the financial services context. Showing that you prioritize model explainability, understand risk and compliance implications, and can communicate complex ideas clearly will set you apart from other technically qualified applicants.

Does Wells Fargo support remote work or hybrid arrangements for Data Scientists?

Wells Fargo typically operates under a hybrid work model, which combines in-office collaboration with remote work flexibility. The exact expectations depend on the specific team, department, and office location, and these details are usually discussed early in the recruitment process.

13Keep practising

• Data Scientist question bank — cross-company practice.
• Interview preparation framework
• All interview guides