Interview guides · Invesco

Invesco Data Scientist Interview Questions & Guide 2026

SQL practice for Invesco data scientist candidates: window functions, funnel and retention queries, joins that quietly drop rows.

The 60-second brief

A Data Scientist at Invesco plays a pivotal role in bridging the gap between complex financial data and actionable investment strategies. As part of a global asset management firm, you are tasked with leveraging advanced analytical techniques to solve high-stakes problems, ranging from market predictive modeling to optimizing trading execution. Your work directly influences how Invesco manages assets, manages risk, and delivers value to clients across the globe.

In modelling rounds the live question is usually why this model class for this problem, and how you would know six weeks after launch that it is still working. Deriving gradients by hand is rarely what is being probed.

Focus areas

Separate forecast decay from execution cost
Measure shortfall against arrival, not VWAP
Build point-in-time panels without lookahead

Overview

The environment is intellectually rigorous and requires a candidate who is as comfortable with mathematical theory as they are with the practical realities of the financial markets. You will frequently collaborate with quantitative researchers, portfolio managers, and software engineers to translate theoretical models into scalable production systems. Success in this role requires not just technical proficiency, but the ability to communicate complex insights to non-technical stakeholders who rely on your data to make critical investment decisions.

While the role is highly technical, Invesco places significant weight on how you communicate your findings. Be prepared to explain complex models to stakeholders with varying levels of data literacy.

The Invesco interview process

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

Screening Phase

An added round often puts you in front of someone outside the core hiring team: a partner engineer, a product owner, a domain expert, sometimes a more senior manager. The question they are really asking is not whether you can do the work but whether they would trust a number that came from you. That changes what a good answer looks like. Lead with what the decision cost and what it changed, keep the method available but not central, and be plain about the limits of your evidence. Overstating a result is the fastest way to lose this round.

What to demonstrate

Whether you can explain a technical choice to someone who will never read your code, without either flattening it into nothing or hiding inside jargon
Honesty about evidence strength: what the analysis establishes, what it only suggests, and what it cannot say at all
How you take disagreement, specifically whether you update on a good objection, hold your position with reasons, or fold on contact

How to prepare

Write the two-sentence version of your most technical project for a non-specialist, then check that neither sentence needs a method name to make sense.
For one result you are proud of, write the strongest objection someone could raise and a response that concedes the part of it that is correct.
Prepare one decision that turned out to be wrong: how you found out, what it cost, and what you changed afterwards. A senior cross-functional interviewer asks for this more often than a technical one does.

Technical Assessment

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

Team Fit Evaluation

Underneath the questions about your past work sits a resourcing question. Given four things worth doing and one of you, which gets done and what happens to the rest? Managers ask because that is the daily texture of the job, and because the answer shows whether you rank work by effort or by what it changes. The weak version sorts by personal interest or by whoever asked most insistently. The strong version ties each candidate piece of work to a decision somebody downstream is waiting on, and then names the one you would drop and who you would tell.

What to demonstrate

Whether you rank work by the decision it unblocks or by how interesting the method is
How you describe a request you declined, and whether you can say who you said it to
Whether your sense of how long something takes survives one follow-up question about the messy part
How you decide something is good enough to hand over unfinished

How to prepare

Write out your current queue and, next to each item, the decision that stays stalled until it lands. Anything with no waiting decision becomes your example of work you would cut
Rehearse turning down a plausible stakeholder request out loud, including the smaller alternative you offered instead
Have one case where you shipped a rough answer early and one where you refused to, with the reason that separated them

Onsite Assessment

Where a loop includes a partner from outside the data team, that conversation usually carries the same weight as the technical ones and gets the least preparation. The person opposite you will not follow a derivation and does not need to. They are working out whether having you involved would make their decisions better or slower. The failure mode is not being too technical. It is answering a question about a decision with a description of your method, leaving the translation to them. What they carry into the debrief is the sentence you handed them, not the analysis underneath it.

What to demonstrate

Whether a statistical result arrives as something the partner could act on, with the one caveat that would change their decision kept and the rest left out
Whether you can state what you need from their side, in their terms: instrumentation that does not exist yet, a definition they own, or a holdout they have to agree to
Whether uncertainty is given as a range someone can plan against, rather than as hedging that invites them to ignore the result
Whether you ask what decision is actually on the table before explaining anything

How to prepare

Take a result you know well and write the version for someone who stops reading after one sentence, then the three-minute version, and check the short one is not the long one with the qualifications stripped out
For a past project, list everything you asked a non-technical partner for and how you phrased it, then rewrite each ask so it names what goes unmeasured without it
Practise saying where a result does not apply, out loud, in one sentence that a partner could repeat accurately to someone else

Where candidates lose points

Joining research panels to the current instrument master instead of its effective-dated version, so delisted, merged and bankrupt names silently disappear from the historical universe.

The names that leave a universe leave disproportionately after bad returns, so removing them raises backtested return and lowers backtested volatility at the same time. The bias is largest exactly where the strategy claims to add value, in the tails, and it is invisible in the output: the query succeeds, the row count looks plausible, and the equity curve simply looks better than it should. The fix is to resolve universe membership with a predicate on effective_from and effective_to, never on status = 'active'.

Reporting the best backtest out of many trials as if it were a single pre-registered test.

The maximum of N noisy Sharpe estimates grows roughly like the standard error times sqrt(2 ln N) even when every underlying strategy has zero edge, so with a few hundred variants an in-sample Sharpe near 1 is the expected result of pure noise. Worse, the search is rarely counted honestly: parameter sweeps, universe changes, date-range choices and feature variants all count as trials. Quote the number of configurations tried, deflate the Sharpe for it, and keep a genuinely untouched holdout period. Note also that the asymptotic standard error of a Sharpe estimate is approximately sqrt((1 + SR^2/2)/T) for i.i.d. normal returns, which for three years of daily data is roughly 0.33, so two strategies differing by 0.3 in Sharpe are not distinguishable.

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.

Building features from data that postdates the prediction time

Check every feature against the timestamp at which the model would actually score, and drop anything computed from a window that includes or follows the label event. For a forecasting use case, split train and test by time rather than at random, and split by entity when the same entity recurs.

Questions & practice

Can you explain the trade-offs between different machine learning models for predicting market movements?

Medium · machine learning and modelling

Approach

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

Follow-up

How would you choose the decision threshold, and who owns that choice?
What would you monitor after launch to know the model is still valid?

How do you validate a model to ensure it isn't overfitting to historical noise?

Medium · machine learning and modelling

Approach

Set a baseline first, so any model has something honest to beat.
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

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

How large a Sharpe does pure noise produce over many trials

Medium · simulation · multiple testing · numpy

A research team tested 250 strategy variants on the same three years of daily returns (756 observations). The best variant has an annualized Sharpe of 1.4. Under the null that every variant has zero expected return, estimate by simulation the probability that the maximum of 250 Sharpe estimates is at least 1.4. Then repeat with the variants' daily returns equicorrelated at rho = 0.7, which is closer to the truth when variants share a universe. Report both probabilities with Monte Carlo error and say which one belongs in the memo.

Approach

Simulate at the frequency the statistic is estimated at: 756 daily draws per variant, not three annual ones. The Sharpe is scale-free, so standard normal draws suffice and the choice of sigma cannot change the answer.
Build the correlated case as X = sqrt(rho)*Z0 + sqrt(1-rho)*E, with Z0 one common daily draw shared by all variants and E independent per variant. That is exact equicorrelation for one extra column, rather than a 250x250 Cholesky per replication.
Per replication compute all 250 annualized Sharpes as mean/std(ddof=1)*sqrt(252) along the time axis, take the maximum, and count how often it clears 1.4. Use at least 20,000 replications so the Monte Carlo standard error on a probability near 0.85 is about 0.0025.
Check the independent case analytically before trusting the simulation: 1 - Phi(z)^250 with z = 1.4/SE and SE = sqrt(252/756) = 0.577 gives z = 2.43 and p close to 0.85. The simulation should land inside two Monte Carlo standard errors of that.
Get the direction of the correlation effect right. Correlated variants behave like fewer independent trials, so the null maximum is smaller and an observed 1.4 becomes less likely under the null, not more. Present the correlated p-value as the smaller, more favourable number and state plainly that it depends on an assumed rho you did not measure.

Worked solution (25 min)

rng = np.random.default_rng(0); per replication draw X with shape (756, 250).
sr = X.mean(axis=0)/X.std(axis=0, ddof=1)*np.sqrt(252); store sr.max().
Repeat with X = sqrt(0.7)*Z0[:, None] + sqrt(0.3)*E where Z0 has shape (756,).
p = (max_sr >= 1.4).mean(); mc_se = sqrt(p*(1-p)/n_sims).
Plot both null distributions of the maximum with 1.4 marked on each.

Expected result: Independent case: p is about 0.85 with a Monte Carlo standard error near 0.003, and the null maximum has a mean around 1.65, so the observed 1.4 sits below the centre of the noise distribution. Equicorrelated at rho = 0.7: p falls to roughly 0.15 to 0.20. Neither result is significant at 5%.

Verify it yourself

The analytic 1 - Phi(1.4/0.577)^250 must match the independent simulation to within two Monte Carlo standard errors.
The crude asymptotic location sqrt(2*ln(250)) = 3.32 overstates the mean of the maximum of 250 standard normals; the corrected location is about 2.86, so E[max Sharpe] is about 1.65. A simulated mean maximum near 1.92 means you are reading the crude approximation rather than the simulation.
Setting rho = 0 must reproduce the independent case exactly.
Setting n_variants = 1 must reproduce the single-Sharpe p-value of about 0.008.

Follow-up

The team says it only ran six configurations because it discarded the rest early. How do you count trials that were abandoned after somebody looked at the result?
What Sharpe would the best of 250 have to reach for you to call it significant at 5%, and is that number attainable at this strategy's turnover?
How would you carve out a holdout the search has genuinely not touched, given the team has already seen the full sample?

List fills that were never corrected, and survive the NULL

Medium · anti-join · null-semantics · data-quality

execution_fill records a cancel/correct as a new row with is_correction = TRUE and corrects_fill_id referencing the original; an ordinary fill has is_correction = FALSE and corrects_fill_id IS NULL. Return every original fill for a given settle_date that was never corrected, with fill_id, order_id, fill_qty, fill_px and commission_amt. A colleague's version filters WHERE fill_id NOT IN (SELECT corrects_fill_id FROM execution_fill) and returns zero rows on a day with thousands of fills. Explain why, then write the correct query.

Approach

Name the mechanism precisely. x NOT IN (...) expands to x <> v1 AND x <> v2 AND .... Against a NULL element the comparison is UNKNOWN, so the conjunction is either FALSE (when x matches some value) or UNKNOWN, never TRUE. Every probe row is filtered out. It is not an error, which is why it survives review.
Rewrite as NOT EXISTS (SELECT 1 FROM execution_fill c WHERE c.is_correction AND c.corrects_fill_id = f.fill_id). This uses plain equality, is immune to NULLs in the inner column, and is the form the planner turns into a hash anti-join.
If NOT IN has to stay for some reason, add WHERE corrects_fill_id IS NOT NULL to the subquery. It is correct, and it is fragile: the next nullable column someone probes reintroduces the identical bug with no new symptom.
Scope the correction lookup by time, not by the same settle_date. A correction commonly arrives a day or more after the fill it amends, so restricting the inner query to the report date reports already-corrected fills as clean.
Close with arithmetic: originals on the date, minus distinct originals referenced by any correction row, must equal the returned count. If it does not, a correction references a fill_id that does not exist, which is a feed integrity issue worth raising.

Follow-up

Would LEFT JOIN ... WHERE c.fill_id IS NULL give the same answer here? What changes if a single fill is corrected twice?
A correction lands three days after the TCA report went out. How do you make the report reproducible as-of its publication date rather than silently restating it?

Reconstruct a point-in-time universe from effective-dated reference data

Easy · scd2 · point-in-time · temporal-join

instrument_master is effective-dated: one row per instrument_id per version, valid over [effective_from, effective_to), with effective_to NULL while the version is open. Other columns include ticker, asset_class, primary_exchange_mic, status, is_shortable, listing_date and delisting_date. Write one query returning every instrument that was a listed, shortable equity as of 2023-06-30 17:00 UTC: one row per instrument_id, carrying the ticker in force at that instant. The result must still contain names that have delisted since.

Approach

Predicate on the validity window rather than on the latest row: effective_from <= :ts AND (effective_to > :ts OR effective_to IS NULL). The half-open form is what guarantees exactly one row per instrument_id when one version ends at the same instant the next begins.
Read the attributes from that version, not from today's row: asset_class = 'equity', is_shortable, and status as recorded in the version. Today's status is the wrong fact for a past date.
Bound the lifecycle separately: listing_date <= :ts::date AND (delisting_date IS NULL OR delisting_date > :ts::date), so pre-IPO shells and names already dead on that date drop out on that date's own terms.
Probe uniqueness with GROUP BY instrument_id HAVING COUNT(*) > 1. A duplicate means the source has overlapping versions, which is a data-quality finding to escalate, not something to paper over with DISTINCT.
Confirm the temporal behaviour by re-running with the timestamp moved past a known delisting and checking the name disappears then, and only then.

Worked solution (20 min)

Write the range predicate as a CTE parameterised on the cutoff timestamp so the same text is reusable per date.
Add the attribute filters inside the CTE, then the listing/delisting bounds in the outer select.
Run the duplicate probe on instrument_id and confirm it returns no rows.
Re-run with effective_to IS NULL substituted for the range predicate and diff the two result sets.
Inspect the diff: every row present only in the correct version should have a non-null delisting_date or a later reference-data amendment.

Expected result: One row per instrument_id whose open version at 2023-06-30T17:00Z had asset_class = 'equity' and is_shortable = TRUE, including instruments whose current version now reads status = 'delisted'.

Verify it yourself

COUNT(*) equals COUNT(DISTINCT instrument_id).
No returned row has delisting_date <= DATE '2023-06-30'.
At least one returned row has a non-null delisting_date, proving the survivor-only failure did not occur.
The effective_to IS NULL variant returns a different set, and every row it drops is explainable by a delisting or a later amendment.

Follow-up

The vendor backdates a correction, so effective_from for a new version precedes an existing one and your query returns two rows for one instrument_id. How do you resolve it, and what does loaded_at let you express that effective_from cannot?
Someone proposes joining research panels on ticker because it is human-readable. Give a concrete failure mode with a date attached.
How would you turn this single-date query into one that produces the universe for every date in a range without a loop?

How would you handle missing or noisy data in a time-series financial dataset?

Medium

Approach

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

Follow-up

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

What statistical methods do you prefer for testing the significance of a new trading signal?

Medium

Approach

Clarify what is being asked and what a complete answer would contain.
Work from the decision backwards to the evidence you would need.
Say what you would check first and why it is the highest-information step.

Follow-up

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

Choose a randomisation unit when treated orders move the price

Medium · interference · cluster randomisation · switchback

You are testing a participation-rate cap that slows large parent orders. The desk works about 3.2 parent orders per instrument per day, and two orders in the same instrument on the same day consume the same displayed liquidity. Three designs are proposed: randomise per parent order, randomise per instrument-day cluster, or switch the whole desk between arms in thirty-minute buckets. Choose one, justify it from the interference structure rather than from convenience, and quantify what your choice costs in required sample size relative to per-order randomisation.

Approach

State the interference concretely. Under per-order randomisation a treated order that trades more slowly leaves displayed liquidity behind for a control order in the same name, so the control arm's shortfall improves because of the treatment. The measured contrast is biased toward zero, and because the bias scales with the treated fraction rather than with noise, running the test longer does not remove it.
Keep per-order randomisation only for changes with no market footprint, such as logging, post-trade reporting or an internal parameter that cannot alter the order's interaction with the book. Anything that changes when or how much you trade fails the no-interference assumption.
Price the cluster design. With intra-cluster correlation rho of shortfall within an instrument-day and mean cluster size m, the design effect is 1 + (m - 1) * rho, and the order count from a per-order power calculation must be multiplied by it. Inference has to use cluster-robust or cluster-bootstrap standard errors keyed on instrument_id by business_date, not on order_id.
Price the switchback. It removes cross-order interference outright because the whole desk is one arm at any instant, but the effective sample size collapses to the number of buckets rather than the number of orders, and buckets are serially correlated through inventory carried across boundaries and through the intraday volatility profile. It needs assignment balanced within each day so time-of-day is not confounded with arm, a burn-in that discards orders straddling a boundary, and inference at the bucket level.
Recommend cluster randomisation here, because the interference is contemporaneous and confined within a name. Reserve the switchback for a change that consumes a genuinely shared pool, such as internal crossing inventory, a locate pool or a broker's balance sheet, where isolating by instrument isolates nothing.

Worked solution (30 min)

Estimate rho from history by fitting a one-way random-effects model of per-order shortfall grouped on instrument_id by business_date, or by the equivalent ANOVA variance decomposition.
Compute the design effect 1 + (3.2 - 1) * 0.25 and multiply the per-order sample size from the fixed-horizon power calculation.
Count the switchback's units: thirteen half-hour buckets over a regular session times sixty trading days gives 780 buckets, 390 per arm, and compute the bucket-level standard deviation of shortfall.
Express the switchback's minimum detectable effect in bucket standard deviations as 2.8016 * sqrt(2 / 390), then state that serial correlation between buckets inflates it further.
Compare required calendar time across the two viable designs at the same detectable effect, and write the standard-error estimator into the analysis plan before the test starts.

Expected result: At rho = 0.25 and m = 3.2 the design effect is 1.55, so 8,550 orders per arm becomes about 13,250 per arm, a 55 percent increase, and standard errors rise by sqrt(1.55), about 25 percent. The switchback over 780 buckets resolves roughly 0.20 of the bucket-level standard deviation before any serial-correlation penalty, which is usually the binding constraint. Cluster randomisation on instrument-day is the recommendation.

Verify it yourself

The design effect must be at least 1, and equals 1 only when rho is 0. A negative rho estimate means the variance decomposition is absorbing a covariate you should be stratifying on instead.
Cluster-robust standard errors must exceed the naive ones by roughly sqrt(design effect). If they do not, the clustering key is wrong or the clusters are singletons.
Reliability of cluster-robust inference is driven by the number of clusters, not the number of orders. Below roughly forty clusters per arm, switch to a wild cluster bootstrap and say so.

Follow-up

How would you estimate rho before running the test rather than discovering it afterwards?
What spillover survives the cluster design: same sector, same risk factor, the same broker's book on the same day?
If the desk insists on per-order randomisation, can you bound the interference bias, and which direction does it push the decision?

Mean daily IC halved with no model change

Easy · ic · data quality · metric decomposition

The trailing-252-day mean rank IC for one signal_id fell from 0.031 to 0.016 over roughly six months. No model_version changed and no research code shipped. You have signal_score (signal_id, model_version, instrument_id, as_of_date, knowledge_ts, zscore_xs, universe_id, coverage_flag, is_backfilled, computed_at) joined to a daily forward-return panel keyed on instrument_id and date. Decide whether the forecast decayed or the input panel changed. Deliverable: an ordered checklist and the one query that settles it. You may not retrain the model.

Approach

Stop looking at the trailing mean and recompute IC for each as_of_date. A 252-day moving average turns a single-day step into a decline that takes 252 days to complete, so the shape you were shown is equally consistent with a sudden break and with gradual decay. The first difference of the daily series locates a break to within a day.
Count distinct instruments per as_of_date and per universe_id. A universe that silently shrinks changes the population the rank correlation runs over, which makes the new number a different estimator rather than the same one measured worse.
Recompute the daily series restricted to coverage_flag = 'computed' and overlay it on the all-rows series. If the restricted series is flat across the break, the drop lives entirely in imputed or stale scores and the forecast is intact.
Look at computed_at and the is_backfilled share around the break date. A live-job outage and a rerun that rewrote the same dates with different values produce the same IC drop and need different fixes.
Only if all three cuts come back clean should decay be entertained, and then it has to be measured as decay: IC at horizons 1 through 21 and a half-life, not one number compared to another number.

Follow-up

How many trading days of daily IC would you need to distinguish a true IC of 0.031 from 0.016 at conventional power, and what does that say about the six-month window you just used?
If stale rows carry forward a score from one fixed prior date, what happens to their measured IC as the gap widens, and what does that do to the pooled number?

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.

Stories where someone disagreed with you

Have two ready. In one, the data was on your side and you had to move someone who outranked you. In the other, the pushback was correct and you changed position. The second is the harder story and it lands better, because it shows you separate being right from being attached to an answer. Name the person's actual objection.

How do you handle disagreement with a peer or manager regarding an analytical approach?

Medium · behavioural and stakeholder questions

Approach

Quantify the outcome, including what you would not claim credit for.
Name the disagreement or constraint, and how you resolved it with evidence.
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?

Tell me about a time you had to explain a complex technical result to a non-technical stakeholder.

Medium · behavioural and stakeholder questions

Approach

State the situation in two sentences and spend the rest on your reasoning.
Quantify the outcome, including what you would not claim credit for.
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?
What did you decide not to do, and why?

Why do you want to transition your data science expertise to the asset management industry?

Medium · behavioural and stakeholder questions

Approach

Close with what you would do differently, concretely.
Quantify the outcome, including what you would not claim credit for.
Name the disagreement or constraint, and how you resolved it with evidence.

Follow-up

How did you know the outcome was caused by your change?
What did you decide not to do, and why?