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.
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.
Recruiter Phone Screen
reportedA 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 to demonstrate
- 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
reportedThis 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 to demonstrate
- 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
reportedBefore 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 to demonstrate
- 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
reportedWhere 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 to demonstrate
- 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
reportedMost 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 to demonstrate
- 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.
5 candidate reports. Individual accounts describe a particular role and hiring cycle.
Wells Fargo Financial Analyst interview: three structured superday sessions
The process felt organized and standardized, especially at the superday. I completed HireVue and, about a week later, attended an in-person final round with three interviews of roughly 30 minutes each. Two were technical and one was behavioral. Everything ran smoothly, with a familiar rhythm across interviewers. The technical sessions covered accounting and ratios, including debt and equity conce…
Read full experienceWells Fargo Financial Analyst interview: HireVue to superday
After I applied, the process began with a virtual question screen that felt more like a proctored exam than a conversation. I was asked why I wanted the role and then answered many behavioral prompts. It was awkward more than difficult, and I wished it felt more human. That led into HireVue again before anything live. The early video rounds were not very technical; they were mostly open ended and…
Read full experienceWells Fargo Software Engineer Interview Experience: Broad assessment and a condescending later call
After the recruiter stage, I took a HackerRank-style online assessment that combined multiple choice and coding. It focused on DSA and practical problem-solving. Some versions also included aptitude and general computer-science questions. The platform questions did not always match what I expected, but I pushed through and moved to live rounds after passing. The technical interviews felt more lik…
Read full experienceWells Fargo Senior Software Engineer Interview Experience — From Kafka System Design to an AI Grilling with the Hiring Manager
View report detailsWells Fargo Credit Risk Modeler Interview Experience — HR Screen, Technical Interview, 48-Hour Take-home Case Study, and Behavioral Fit
Position: Credit Risk Modeler (Associate Level) Location: Charlotte, NC (Hybrid) Rounds: HR Screening → Technical Interview → Case Study → Behavioral Fit Interview Process Recap ① HR Phone Screen (30min) Brief self-introduction, "Why Wells Fargo?" Confirmed my understanding of Credit Risk Modeling (PD/LGD/EAD basics). Asked one behavioral question: "Describe a time you worked with incomplete data…
Read full experiencePracHub editorial advice for the preparation topics above.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the difference between bagging and boosting. In what scenarios…
Explain the difference between bagging and boosting. In what scenarios would you prefer one over the other?
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Say what the estimate is of, and over what population it generalises.
- Sanity-check the answer against a simple bound or a simulated case.
Follow-up
- Which assumption here is most likely to be violated in practice?
- What sample size would you need to detect an effect half this size?
Share an experience where a model you deployed did not perform as expe…
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?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- 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.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
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.
Approach
- 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.
Worked solution 45 min
- Sort by loan_id and as_of_month_end, shift to form (from_state, to_state) pairs, and flag pairs whose month gap is not exactly one.
- For each loan's final row, assign the absorbing destination from charge_off_flag or prepaid_in_full_flag, and list loans that vanish with neither as an exception count to report.
- Apply the restructure rule, then build the 7 by 7 count matrix with a cross-tabulation over ordered state categories and row-normalise it.
- Assert row sums equal one and absorbing rows are the identity, then take the current month's bucket distribution as a row vector.
- Multiply twelve times, report the charged_off component, and repeat from an all-current vector for comparison.
Follow-up
- 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?
If you were given a raw dataset from a platform like Kaggle, what are …
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?
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- What breaks if events arrive late or out of order?
- How would you verify this result without re-running the same query?
Given a database of customer transactions, write a SQL query to find t…
Given a database of customer transactions, write a SQL query to find the top 5% of customers by transaction volume over the last quarter.
Approach
- State the window function and its partition and ordering out loud before writing it.
- Say which table is the grain you start from, and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
Follow-up
- What breaks if events arrive late or out of order?
- How would you verify this result without re-running the same query?
Walk me through a code snippet containing a common logical error or op…
Walk me through a code snippet containing a common logical error or optimization bottleneck and explain how you would resolve it.
Approach
- State the window function and its partition and ordering out loud before writing it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Say which table is the grain you start from, and join outward from 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?
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.
Approach
- 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.
Worked solution 40 min
- CTE 1: filter out is_reversal rows, then compute prev_requested_at with LAG and the is_new_chain flag.
- CTE 2: build chain_id with a running SUM of the flag over the same partition and order.
- CTE 3: group by partition keys plus chain_id to emit chain_started_at, attempt_count, amount_minor, channel and chain_outcome.
- CTE 4: aggregate chains to (chain_date, channel) with approved value and total value. Add the date spine here only if the report must show empty days.
- Final SELECT: two rolling SUMs over PARTITION BY channel ORDER BY chain_date RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW, divided at the end.
Follow-up
- 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?
How do you prioritize your tasks when managing multiple data science i…
How do you prioritize your tasks when managing multiple data science initiatives with competing deadlines?
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.
- Fix the population and the time window before naming any metric.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- Which segment would you cut first, and what would that rule out?
If we launch a new credit card product, how would you estimate its ado…
If we launch a new credit card product, how would you estimate its adoption rate and predict customer churn in the first six months?
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
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?
Imagine a scenario where a key business metric suddenly drops. Walk me…
Imagine a scenario where a key business metric suddenly drops. Walk me through your step-by-step diagnostic process to identify the root cause.
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Name one primary metric, then the guardrail that stops it being gamed.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- Which segment would you cut first, and what would that rule out?
How would you design an A/B test to evaluate a new feature in the Well…
How would you design an A/B test to evaluate a new feature in the Wells Fargo mobile banking application?
Approach
- State the primary metric and the minimum effect worth shipping, then size the test.
- Name the guardrails that would stop a launch even on a positive primary result.
- Name the randomisation unit first; it decides the variance and what the test can detect.
Follow-up
- How would you handle interference between treated and control units?
- What would you conclude if the result is positive but the test is underpowered?
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.
Approach
- 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.
Worked solution 40 min
- Define the decline cohort and the matched comparison cohort precisely, including matching variables and the pre-period window, and produce the 30-day and 90-day settled-volume difference.
- Decompose the declined cohort into customers who never transact again and customers who transact less, since fraudsters concentrate in the first group and that split tells you how much of the estimate is contamination.
- Write the holdout design: score band, sample share, expected fraud rate in band, expected cost of running it, and the run length needed to detect an effect large enough to change the cutoff.
- Recompute p* = C_FP / (C_FP + C_FN) at the top and bottom of your estimated cost range and state whether the range changes the cutoff you would set.
- Write the one-sentence caveat that will be quoted alongside the number in the pricing decision.
Follow-up
- 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.
Approach
- 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-up
- 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?
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.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Build 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Joins, 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Window 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.
Practice prompt ↗Practice prompt ↗04The 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Write 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.
Practice prompt ↗Practice prompt ↗06One 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.
Practice prompt ↗Practice prompt ↗07Full 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
A number you shipped turned out to be wrong, and someone had already acted on it. That is one of the most useful stories a data person can carry. What is being scored is how fast you noticed, who you told first, and what you changed in the process so the same class of error could not repeat quietly.
Walk me through a complex data science project you led from conception…
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?
Approach
- Name the disagreement or constraint, and how you resolved it with evidence.
- Close with what you would do differently, concretely.
- Pick a story where you drove the decision, not one where you observed it.
Follow-up
- How did you know the outcome was caused by your change?
- What would you do differently if you ran that project again?
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.
Approach
- 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-up
- 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.
Approach
- 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-up
- 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?
- 01
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?
- 02
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.
- 03
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.
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.
PracHub interview research ↗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.
PracHub interview research ↗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.
PracHub interview research ↗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.
PracHub interview research ↗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.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
USAA Data Scientist Interview Questions & Guide 2026
Data-quality drills for USAA data scientist prep: survivorship and selection bias, leakage through time-ordered features, and extreme values where provenance decides the call. A logging fault or unit slip gets corrected or dropped; a genuin
Wtw Data Scientist Interview Questions & Guide 2026
Experiment-design practice for Wtw data scientist candidates, covering randomisation units, power, minimum detectable effect and the traps that invalidate a result.
Worley Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for Worley data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
World Insurance Data Scientist Interview Questions & Guide 2026
Experiment-design practice for World Insurance data scientist candidates, covering randomisation units, power, minimum detectable effect and the traps that invalidate a result.