Interactive Process Technology Data Scientist Interview Questions & Guide 2026

The 60-second brief

At Interactive Process Technology, a Data Scientist plays a pivotal role in bridging the gap between complex data systems and strategic business decisions. You will be responsible for building, optimizing, and deploying machine learning models that directly affect the company's enterprise clients and internal product suites. The role is highly dynamic, combining deep technical execution with consultant-style client interaction to solve real-world operational challenges.

A large share of questions open as "how would you measure X", where the real work is choosing the metric, fixing its denominator, and defining the population it applies to. Any computation comes last and is frequently not required at all.

Focus areas

• Separate contracted seats from actively used seats
• Power experiments for heavy-tailed account revenue
• Read NRR on a fixed account cohort

Overview

As a Data Scientist, your work directly influences product roadmaps, user experience optimization, and business-critical automation. You will work with massive, often unstructured datasets to extract actionable insights, build predictive pipelines, and present high-impact findings to both technical and non-technical stakeholders. This position requires not only technical excellence but also the ability to translate complex statistical outputs into compelling business narratives.

The work environment at Interactive Process Technology is fast-paced and highly collaborative. You will partner closely with software engineers, product managers, and external client teams to integrate data-driven solutions into production environments. If you thrive on solving ambiguous problems, designing custom analytical functions, and seeing your models drive tangible business value, this role offers an exceptionally rewarding and high-impact career path.

The Interactive Process Technology interview process

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

Online Coding 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 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

Technical Rounds

Much of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.

What to demonstrate

• Whether the query you write matches the plan you just described
• What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
• Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly

How to prepare

• Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
• Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
• Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock

Behavioral Interview

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 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.

Panel Interview

A loop is not scored one interview at a time. The people you meet compare notes afterwards, usually in a meeting you are not in, and the outcome turns on what each of them can say about you when asked. That rewards something other than survival: every room needs one specific thing worth repeating, and none of them can contradict another. The common way to lose is to tell the same project four times with different numbers in it, or to be uniformly fine in a way that leaves nobody with anything to argue for.

What to demonstrate

• Whether your account of a project survives being told twice, with the same scale, the same metric definition and the same numbers each time
• Whether each interviewer leaves with one concrete claim they could make on your behalf later, rather than an absence of complaints
• Whether a question you already answered in an earlier room gets the same answer at the same depth, without visible impatience

How to prepare

• Write a one-page fact sheet for your two or three main projects that fixes the numbers you will quote: rows of data, the metric as a single sentence, the effect you measured and how long the work took. Say them aloud from the sheet until they come out identical every time
• For each kind of room you expect, decide the one sentence you want that interviewer repeating in a debrief, then check during the mock that you said it outright instead of implying it
• Rehearse answering the same project question twice in one sitting, the second time as though you had not just answered it, because the thing that needs fixing is the flatness that creeps into a repeated story

Where candidates lose points

Computing monthly churn against the entire customer base when contracts are annual

An annual contract has no opportunity to churn except at its renewal date, so an account that is eleven months from renewal is in the denominator while being incapable of appearing in the numerator. The resulting rate is smaller than the real one by roughly the ratio of the base to the renewal-eligible base, and it oscillates with the seasonality of when deals were originally signed rather than with anything about the customers. The corresponding trap on the other side is counting a churn on the date the record was updated rather than on term_end_date, which shifts losses into whichever month the operations team did its paperwork.

Reading consumption metrics before the metering lag window has closed

Usage pipelines land late and correct themselves, which is exactly what is_restated and restated_at record. A dashboard queried on day T sees a partially populated tail for the last several days, so the most recent points always slope downward and always look like a regression. Analysts then explain the artefact, and sometimes ship a change to fix it. Establish the empirical settling time by measuring how much a given usage_date's total moves between first_written_at and its final value, exclude that many trailing days from every reportable figure, and never compare a fresh period against a settled one.

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.

Stopping an experiment the moment it crosses significance

Fix the sample size or duration before launch, or use a method built for continuous monitoring such as a sequential test, always-valid confidence intervals, or group-sequential boundaries. Repeatedly checking a fixed-horizon p-value against 0.05 pushes the real false-positive rate well above 5 percent.

Questions & practice

What metrics would you use to evaluate a highly imbalanced classification model, and why is accuracy insufficient?

Medium · machine learning and modelling

Approach

1. Frame the prediction: the label, the moment of prediction, and the action it triggers.
2. Say how the offline result would be validated online before it is trusted.
3. Check what information would not exist at prediction time, and exclude it.

Follow-up

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

Describe the process of feature engineering for high-cardinality categorical variables.

Medium · machine learning and modelling

Approach

1. Pick an evaluation metric that matches the cost of each error type, not a default.
2. Check what information would not exist at prediction time, and exclude it.
3. Frame the prediction: the label, the moment of prediction, and the action it triggers.

Follow-up

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

Implement seven-day activation rate from its written definition

Easy · metrics · pandas · activation

Given dim_account (account_id, created_at, is_internal, is_current) and fct_api_request (account_id, request_at, http_status, api_key_id, traffic_class), implement activation_rate(accounts, requests, week_start). Definition: the numerator is accounts whose first request with http_status < 400, api_key_id not null and traffic_class != 'synthetic_monitor' occurs no later than 168 hours after created_at; the denominator is non-internal accounts created during the ISO week starting week_start. All timestamps are tz-aware UTC. Return the rate and both counts, and refuse to report a week until every account in it has had its full 168 hours.

Approach

1. Reduce dim_account to one row per account_id before joining anything. It is a type 2 dimension, so several versions of the same account exist; joining the versioned table to requests multiplies the denominator by the number of plan changes an account happened to make.
2. Build the denominator first and freeze it: is_internal == False and week_start <= created_at < week_start + 7 days. Everything after this is a filter on the numerator only, because an account that never sent a request must still sit in the bottom of the fraction.
3. Filter requests to qualifying rows and only then take groupby('account_id').request_at.min(). The first qualifying request is not the same object as the global first request filtered afterwards, and the two answers differ for every account whose first call was a 4xx.
4. Left-join the first qualifying timestamp onto the cohort and test (first_ok - created_at) <= Timedelta(hours=168). NaT propagates to False in that comparison, which is the behaviour you want, but assert it rather than assume it.
5. Guard reportability explicitly: if week_start + 7 days + 168 hours exceeds the maximum request_at in the data, the week is censored and will read as a drop, so return None or raise rather than emit a number.

Worked solution (20 min)

1. cohort = accounts.loc[~accounts.is_internal & accounts.created_at.between(week_start, week_start + pd.Timedelta(days=7), inclusive='left'), ['account_id','created_at']].drop_duplicates('account_id')
2. ok = requests[(requests.http_status < 400) & requests.api_key_id.notna() & (requests.traffic_class != 'synthetic_monitor')]
3. first_ok = ok.groupby('account_id', as_index=False).request_at.min(); m = cohort.merge(first_ok, on='account_id', how='left'); assert len(m) == len(cohort)
4. activated = (m.request_at - m.created_at) <= pd.Timedelta(hours=168); return {'rate': float(activated.mean()), 'numerator': int(activated.sum()), 'denominator': len(m)}

Expected result: A dict whose denominator is the count of distinct non-internal accounts created in that ISO week, numerator <= denominator, and rate = numerator / denominator; accounts with no qualifying request sit in the denominator with NaT and evaluate to False.

Verify it yourself

• len(m) == cohort.account_id.nunique(); the merge must not add rows.
• Dropping the synthetic_monitor filter can only raise the numerator, never lower it.
• Widening the window from 168h to 336h is monotone: the numerator must not decrease.
• An account whose only qualifying request falls at exactly created_at + 168h counts as activated, since the comparison is inclusive.

Follow-up

• Median time-to-first-call is more informative. What breaks if you take the median over activated accounts only, and what estimator fixes it?
• How would you decide whether 168 hours is the right window rather than 72 or 336?
• An account signs up, does nothing for 20 days, then integrates heavily. Where does it land in this metric, and is that what you want?

Write a Python script using Pandas and NumPy to clean a raw dataset, handle missing values, and normalize features for modeling.

Medium · sql and data manipulation

Approach

1. Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
2. Compute rates by summing numerator and denominator separately, never by averaging rates.
3. Check whether any join is one-to-many before aggregating, or the sums inflate.

Follow-up

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

Implement a custom function to solve a complex sliding window problem on a given array.

Medium · sql and data manipulation

Approach

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

Follow-up

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

Create a custom function that identifies duplicate records across multiple columns without using built-in library functions.

Medium · sql and data manipulation

Approach

1. Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
2. State the window function and its partition and ordering out loud before writing it.
3. 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 does the query change if the join becomes one-to-many?

Collapse retried requests into logical operations per account

Medium · window functions · deduplication · null semantics

fct_api_request carries request_id, account_id, api_key_id, idempotency_key (null when the caller supplied none), is_retry, request_at and http_status. For one ISO week, count logical operations rather than HTTP calls: requests sharing (account_id, api_key_id, idempotency_key) collapse to the earliest one, while every request with a null idempotency_key is its own operation. Return per account the raw request count, the logical operation count and the ratio between them, and state which direction a rising 5xx rate pushes that ratio.

Approach

1. Split the stream before deduplicating. GROUP BY and PARTITION BY treat NULLs as equal to one another, while the = operator does not, so a single grouping pass folds every null-key request in an account into one 'operation' and can cut the count by orders of magnitude.
2. Deduplicate the keyed rows with ROW_NUMBER() OVER (PARTITION BY account_id, api_key_id, idempotency_key ORDER BY request_at, request_id) and keep rn = 1. Including request_id in the ORDER BY makes the result deterministic when two rows share a millisecond, which they will.
3. UNION ALL the null-key rows back in unchanged; they need no dedup and must not pass through the partition.
4. Aggregate per account: count() over the raw week, count() over the union, and the ratio of the two. Report the ratio, not the difference, so accounts of very different sizes are comparable.
5. Cross-check against is_retry, which flags a resend of the same idempotency key: raw minus logical should sit close to the count of is_retry rows, and a large gap means clients are resending without a key and the dedup is under-counting duplicates.
6. Name the inversion explicitly: 5xx responses provoke client retries, so amplification rises exactly when reliability falls, and any engagement metric built on raw request counts will show growth during an outage.

Worked solution (25 min)

1. Filter to the ISO week with request_at >= :week_start AND request_at < :week_start + interval '7 days', and record the raw count per account as the baseline.
2. Build keyed_dedup: SELECT ... ROW_NUMBER() OVER (PARTITION BY account_id, api_key_id, idempotency_key ORDER BY request_at, request_id) AS rn FROM the week WHERE idempotency_key IS NOT NULL, then keep rn = 1.
3. Build unkeyed: the same week's rows WHERE idempotency_key IS NULL, taken as-is.
4. UNION ALL the two, then GROUP BY account_id selecting the logical count; join back to the raw counts and compute raw::numeric / logical.
5. Validate on one account by comparing raw - logical against COUNT(*) FILTER (WHERE is_retry) for that account and explaining any gap.

Expected result: One row per account with raw_requests, logical_operations and an amplification ratio at or above 1.0, where logical_operations counts each distinct (account_id, api_key_id, idempotency_key) once and each null-key request once.

Verify it yourself

• logical_operations is never greater than raw_requests, and the two are equal for accounts whose keys are all distinct.
• For accounts with no null idempotency_key, raw_requests - logical_operations is close to the count of is_retry rows.
• Deliberately grouping on the key without the null split reproduces a visibly lower count, confirming the NULL collapse is the mechanism.
• Re-running the dedup returns the same surviving request_id set, proving the ORDER BY tiebreak made it deterministic.

Follow-up

• Which of these two counts belongs in the billable-units metric, and which in an engagement metric?
• An account's amplification ratio jumps from 1.05 to 3.0 in a day. Name three causes and the query that separates them.

Describe a situation where you had to manage competing priorities and tight deadlines on a high-stakes project.

Medium · product sense and metrics

Approach

1. State what result would change your recommendation, so the answer is falsifiable.
2. Restate the decision this analysis has to support, and who acts on the answer.
3. 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?
• How would you detect that the metric is being gamed rather than genuinely improving?

Triage a sample ratio mismatch before reading the result

Easy · srm · assignment · instrumentation

An account-randomised test assigned arms 50/50 by hashing account_id. Exposure logging recorded 4,200 accounts: 1,987 in treatment and 2,213 in control. A chi-square goodness-of-fit test against the intended 2,100/2,100 split gives chi-square(1) = 12.2, p about 0.0005. The analyst reports the primary metric up 6% in treatment and asks to ship. Explain what the imbalance implies about that 6%, rank the causes you would investigate first given this domain's data, and name for each the single query against fct_api_request or dim_account that confirms or eliminates it.

Approach

1. State the rule before diagnosing anything: a sample ratio mismatch below a 0.001 alarm threshold invalidates the readout. Whatever mechanism removed 113 accounts from one arm almost certainly removed them non-randomly, which makes it a selection effect on the outcome. The 6% is not to be adjusted, caveated or shipped; it is unusable until the mechanism is named.
2. Verify the test is testing the right thing. chi-square = (1987 - 2100)^2 / 2100 + (2213 - 2100)^2 / 2100 = 6.08 + 6.08 = 12.16 on one degree of freedom. Confirm the denominator is the intended assignment count rather than the observed total, and that you are testing assignment rather than an analysis population that has already been filtered.
3. Rank causes by how this domain actually breaks rather than by textbook order: is_internal accounts filtered after assignment instead of before; exposure logged on a code path that returns 5xx more often in one arm, silently dropping those accounts; assignment recorded at first request but exposure at a later event, so accounts that churned in between appear in only one arm; dim_account type-2 versioning giving one account_id two surrogate keys and two hash inputs; deployment_model = 'self_hosted' accounts that never emit exposure telemetry at all.
4. Attach one discriminating query to each: count arms before the is_internal filter; compare the http_status >= 500 rate by arm on the exposure endpoint in fct_api_request; compare the distribution of created_at and churned_at by arm in dim_account; count distinct account_sk per account_id inside the experiment window; cross-tabulate arm against deployment_model.
5. Compare counts at three fixed stages, assignment, first exposure, and analysis population, and localise the divergence to one of them. The stage where the arms first separate names the subsystem, and everything downstream of it is a symptom.
6. Report the outcome as abort, fix, rerun, and be explicit about what survives: the variance estimate for re-powering, the instrumentation fix, and nothing whatsoever about the effect size.

Worked solution (20 min)

1. Recompute the statistic: two terms of 113^2 / 2100 = 6.08, total 12.16, p about 0.0005 on one degree of freedom, below the 0.001 alarm line.
2. Pull arm counts at assignment, at first exposure, and in the analysis population, and find the first stage at which they diverge.
3. At that stage, cross-tabulate arm against is_internal, deployment_model, and the 5xx rate on the exposure endpoint.
4. Write the abort note naming the mechanism, the corrected code path, and the rerun date, with the effect estimate explicitly withheld.

Expected result: chi-square(1) = 12.16, p about 0.0005, so a 0.001 alarm threshold fires and the readout is abandoned. The divergence is localised to a single pipeline stage by comparing arm counts at assignment, at exposure and at analysis, and the most likely causes in this domain are post-assignment internal-account filtering or exposure logging that fails asymmetrically on 5xx responses.

Verify it yourself

• A 113-account shortfall on 2,100 expected is a 5.4% deficit in one arm, which under a sound hash is roughly a 1-in-2,000 event. That is what the 0.001 threshold is calibrated to catch.
• Counts at the assignment stage should already be balanced if the bucketing is correct. If they are not, the bug is in the hash or the salt, not in the logging.
• Any fix that restores balance by filtering on a variable measured after exposure has conditioned on a post-treatment variable and reintroduces the bias it appears to remove.

Follow-up

• The imbalance disappears once you restrict to accounts with at least one successful request. Does that fix the experiment or confirm the bug?
• What alarm threshold would you set for this check, and why is 0.05 the wrong one for a diagnostic you run on every experiment every day?
• How would you detect a mismatch confined to one segment while the overall split looks clean?

Monthly logo churn triples with no change in satisfaction

Hard · renewal-eligible base · censoring · timestamp semantics

Monthly logo churn, computed as churned accounts divided by all paying accounts, tripled last month. Contracts are annual. From fct_subscription_period (account_id, term_start_date, term_end_date, amendment_type, auto_renew, booked_at, superseded_by_id, is_current) and dim_account (account_id, churned_at, account_status, employee_band, acquisition_channel), rebuild churn on the renewal-eligible base, separate calendar effects from customer behaviour, and state whether retention actually changed. Note that churned_at is sometimes set when the record was updated rather than at term end.

Approach

1. Rebuild the denominator as accounts whose term_end_date falls in the month. An account eleven months from renewal sits in the current denominator while being structurally incapable of entering the numerator, so on annual contracts the published rate understates the truth by roughly the reciprocal of the annual renewal fraction and moves with the signing calendar.
2. Plot the renewal-eligible base by month across two years. A signing surge twelve months earlier reproduces itself as an eligibility surge now, and a rate whose denominator ignores that tracks the sales calendar rather than customer sentiment.
3. Date each churn by term_end_date, never by churned_at or an update timestamp. Inspect the distribution of churned_at minus term_end_date: a backlog cleared in one batch appears as a mass at a single date and shifts losses into whichever month the operations team did its paperwork.
4. Apply the 45-day grace for late renewal paperwork so the most recent month and a half is marked not reportable, rather than printing a number that will rise once the paperwork lands.
5. Compare corrected gross logo retention against its own trailing distribution, and if a real change survives, cut it by employee_band, acquisition_channel and plan_tier before proposing any cause.

Follow-up

• Some contracts in the window have not reached their renewal date. When does this require a survival estimator rather than a simple rate, and which one would you use?
• How do you report churn to an audience that wants a monthly number when the underlying event is annual and lumpy?

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.

Explaining a method to someone who will not follow the maths

Half of this section is about translation. Be ready to describe how you explained a result to someone who did not want the method, only the implication, and what you did when the simplified version started being repeated in a way that overstated it. Correcting your own simplification is a strong beat.

How do you handle database nulls and aggregate functions when performing complex left joins?

Medium · behavioural and stakeholder questions

Approach

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

Follow-up

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

Why are you interested in this role at Interactive Process Technology, and how do you handle project environments with high travel requirements?

Medium · behavioural and stakeholder questions

Approach

1. Name the disagreement or constraint, and how you resolved it with evidence.
2. Pick a story where you drove the decision, not one where you observed it.
3. Close with what you would do differently, concretely.

Follow-up

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

Disagree with a product manager about an adoption claim

Medium · conflict · telemetry hygiene · adoption metrics

A product manager is about to present that a new SDK release drove a 40 percent rise in requests among adopting accounts, computed from fct_api_request counts grouped by sdk_version. You find the rise is concentrated in traffic_class equal to ci, that rows with is_retry true grew alongside it, and that restricting to interactive non-retry traffic leaves a 3 percent lift. The launch review is in two days. Decide how you raise this, with whom and in what order, and what you propose the claim becomes.

Approach

1. The interviewer is probing whether you can correct a colleague without ambushing them, and whether your own counter-analysis carries the caveats theirs lacked. Go to the product manager privately before the review. A correction delivered in the room is a status move and loses the argument you are actually trying to win.
2. Bring a decomposition rather than a verdict: the same accounts and window, requests split by traffic_class with retries held out as their own column, so their 40 percent and your 3 percent reconcile line by line and neither has to be taken on trust.
3. Reproduce their figure exactly first. If you cannot land on 40 percent with their method, you do not yet know what you are disagreeing with.
4. Ask whether the continuous-integration lift is itself valuable. An account wiring the SDK into its pipeline has increased integration depth, which is the dominant switching cost in this domain, so the honest claim may be that integration depth rose while interactive usage moved 3 percent. Improving the claim beats deleting it.
5. Name the mechanism that makes the raw count dangerous: clients retry when the platform degrades, so retry volume climbs exactly when the customer is most at risk. Pull the 5xx rate for the same accounts and window before anyone concludes anything, and note that billable_units is zero on 5xx rows, so request counts and billable quantities diverging is itself the signal.
6. Close with a standing definition for launch metrics so the next release does not repeat the exercise.

Follow-up

• The product manager argues that continuous-integration traffic is real usage and declines to split it out. Is that position defensible, and under what metric definition?
• Suppose the 5xx rate for those same accounts also rose 40 percent. What is the claim now?
• The review happens and the raw number is presented regardless. What do you do next, and what do you not do?