A Data Scientist at Wise. Energy plays a pivotal role in driving the intelligence behind our global financial and operational systems. At its core, the role is about transforming massive, complex datasets into actionable products, automated decisions, and strategic insights. You will work on the front lines of scalability, developing machine learning models and analytical frameworks that optimize transaction routing, mitigate risk, predict user behavior, and ensure our services remain lightning-fast and cost-effective.
The impact of this position is immense. By building production-grade algorithms, you directly influence the pricing engines, liquidity management, and fraud detection systems that millions of customers rely on daily. You are not just analyzing data to generate static reports; you are deploying intelligent systems that operate in real-time, directly shaping the user experience and driving the company's bottom-line efficiency.
What makes this role uniquely challenging and rewarding is the sheer scale and variety of our data. You will collaborate closely with cross-functional partners in engineering, product, and operations to solve highly ambiguous problems. Whether you are optimizing a routing pipeline or designing a novel system architecture, your work as a Data Scientist will require a rare blend of deep mathematical rigor, software engineering discipline, and business acumen.
Preparation focus
editorialNo round sequence has been reported for this company, so work the categories below and confirm the format with your recruiter.
What to demonstrate
- Breadth across SQL, experimentation and product reasoning
- Ability to state assumptions before choosing a method
How to prepare
- Drill the practice exercises below and time yourself
- Prepare three quantified stories about decisions you drove
2 candidate reports. Individual accounts describe a particular role and hiring cycle.
Wise. Energy Software Engineer interview with pair programming
I went through a standard multi-stage loop. It started with a recruiter conversation, then a 30-minute coding interview, followed by a longer technical session with system design and another coding segment with two engineers. After that came a product interview and a final conversation with managers and a lead. The exercises felt practical rather than contrived. In the pair-programming portion, c…
Read full experienceWise. Energy Software Engineer Interview Experience: Rigid technical screens and contradictory role expectations
The vibe and fairness felt off from the start. In a technical round where I filled in parts of a skeleton script, the session felt rushed and rigid, as if I were being judged against a memorized approach instead of how I reasoned. The scope changed at the last minute because they could not define what they wanted. There was also a mismatch in fundamentals: state-machine concepts were not handled…
Read full experiencePracHub editorial advice for the preparation topics above.
Computing average inventory from period-end snapshots
Shipments cluster before period close, so the month-end on-hand position is systematically the lowest point of the month; turns computed against it are biased high and days of supply biased low, frequently by ten to twenty percent, and the bias grows precisely when close-period push is strongest. The same shape of error appears when a daily snapshot is joined to shipment events on date equality: a SKU with several legs on one day fans the snapshot out and multiplies the valued inventory. Average across every daily snapshot in the window for the denominator, and join snapshots to events with an explicit as-of condition and a row-count check at each grain before aggregating.
Averaging rates across SKU-locations instead of re-summing
Fill rate, turns, OEE and on-time rate are all ratios whose denominators differ by orders of magnitude between cells, so an unweighted mean gives a slow-moving C item at a small node the same vote as a high-volume A item at a national node. The blended figure then moves whenever the portfolio mix moves, and it can improve in every cell while the company-level ratio worsens, or the reverse, which is Simpson's paradox with a warehouse attached. Always sum numerator and denominator to the reporting level and divide once, and when a rate must be compared across nodes, standardise on a fixed SKU mix before reading anything into the difference.
Reporting a p-value with no effect size or interval
Give the estimated difference with a confidence interval in the units the business cares about, then say whether that whole interval is worth acting on. A p-value only addresses whether you can rule out exactly zero; it says nothing about magnitude.
Reporting a mean for a heavy-tailed metric without saying what it hides
For spend, session length or items per order, a small fraction of units carries most of the total, so the mean has a wide standard error and one account can move it. Fix the handling before you see the result: cap or winsorise at a pre-declared percentile, and report the median or the share above a threshold next to the mean. Capping changes the estimand, so say which question the capped number answers, and check how much of any difference comes from the top 0.1 percent of units.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the concept of conditional probability and how you would apply…
Explain the concept of conditional probability and how you would apply Bayes' Theorem to detect anomalous transaction patterns.
Approach
- Write down the assumption the method needs before you use the method.
- Sanity-check the answer against a simple bound or a simulated case.
- Say what the estimate is of, and over what population it generalises.
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?
What are the mathematical trade-offs between using L1 (Lasso) and L2 (…
What are the mathematical trade-offs between using L1 (Lasso) and L2 (Ridge) regularization in a high-dimensional regression model?
Approach
- Say how the offline result would be validated online before it is trusted.
- Check what information would not exist at prediction time, and exclude it.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
Audit a daily inventory snapshot for silent corruption
You receive fct_inventory_daily with inventory_date, sku_id, location_id, on_hand_qty, allocated_qty, blocked_qty, available_qty, in_transit_qty, demand_qty, shipped_qty, stockout_flag and standard_cost_cents. The table is supposed to carry one row per active sku-location per date, including days with no movement. Write a check suite that returns one row per named check with the number of sku-location-days affected, the share of the scope, and the on-hand value at standard cost sitting behind the failures. Do not repair anything; the deliverable is the evidence.
Approach
- Start with the arithmetic identity the table declares: available_qty must equal on_hand_qty minus allocated_qty minus blocked_qty. Report exact row counts rather than a boolean, because a handful of violations is a feed bug and a uniform offset is a definition change upstream.
- Check sign constraints separately from the identity. Negative on_hand_qty usually means receipts posted out of order, while negative available_qty is legitimate at some sites when allocation is allowed to over-commit, so flag it and ask rather than assuming corruption.
- Check calendar completeness per sku-location by comparing the observed row count against the number of dates between that pair's first and last appearance. Count the missing dates without reindexing the frame, because filling them with zeros converts a feed gap into a plausible run of zero-demand days.
- Check stockout_flag in one direction only: available_qty of 0 at the cut-off with stockout_flag false is a contradiction, while flag true with positive available_qty is not, since the flag records an intraday touch of zero that a late receipt can recover.
- Weight every failure by on_hand_qty times standard_cost_cents so the summary orders checks by money at risk rather than by row count, and state the scope denominator on each row.
Worked solution 20 min
- Define the scope explicitly as the distinct sku-location pairs and the date range under audit, and store the scope row count for use as every check's denominator.
- Evaluate the identity, sign and stockout-flag checks as boolean masks over the frame and record the count and affected value for each.
- For completeness, group by sku_id and location_id, take min and max inventory_date and the row count, and compare the count to the number of calendar days spanned.
- Assemble one output row per check with check_name, failing_rows, share_of_scope and failing_on_hand_value_cents, sorted by value descending.
- Spot-print five failing rows per check so the output is actionable rather than a set of counts.
Follow-up
- Someone proposes asserting shipped_qty is at most demand_qty on the same row. Why does that fire on thousands of healthy rows?
- Half the missing dates fall on Sundays at one set of nodes. What is the most likely explanation and does it change the severity?
- Which of these checks would you run as a blocking gate before a nightly planning job, and which as a monitored report?
Landed cost per delivered unit by lane without fan-out
fct_shipment_leg holds one row per leg: shipment_id, leg_seq, origin_location_id, destination_location_id (NULL when the stop is a customer address rather than a network node), direction, mode, shipped_units, stop_count, leg_status, and linehaul_cost_cents, fuel_surcharge_cents, accessorial_cost_cents and expedite_premium_cents. fct_order_line carries shipment_id, NULL until shipped. Compute monthly landed cost per delivered unit by lane for direction in ('outbound','interfacility'), keying the lane on origin and destination with customer stops bucketed. Do not route through fct_order_line to get units. State the multi-stop allocation basis and what shipped_units means on a leg.
Approach
- Keep the entire computation at leg grain. Numerator is the sum of the four cost columns, denominator is SUM(shipped_units), both over legs with leg_status = 'delivered' and the two directions. The order table is not needed and joining it can only damage the number.
- Bucket destination_location_id IS NULL into an explicit customer_stop lane key with COALESCE, because a NULL never equals anything and will otherwise drop the row from a join or split it silently in a GROUP BY comparison.
- Say out loud whether shipped_units is units on board or units dropped at that stop. Under units on board, summing the legs of a multi-stop load counts a unit once per leg it rides and understates cost per unit; under units dropped, the leg sum is a true shipment total.
- Declare whether multi-stop cost is allocated by weight or by cube, since dense and bulky freight rank lanes in opposite orders under the two bases and the lane league table is not readable without it.
- Roll months up by re-summing cost and units and dividing once. Averaging leg-level cost per unit weights a one-pallet LTL leg the same as a full truckload.
Worked solution 25 min
- Filter fct_shipment_leg to leg_status = 'delivered', direction IN ('outbound','interfacility'), and the month range.
- Build lane_key from origin_location_id and COALESCE(destination_location_id::text, 'customer_stop').
- Aggregate per month and lane_key: total_cost_cents as the sum of the four columns, total_units as SUM(shipped_units), leg_count as COUNT(*).
- Divide once: cost_per_unit_cents = total_cost_cents / NULLIF(total_units, 0).
- Cross-check the grand total against an unaggregated SUM over the same filter, and record the allocation basis and shipped_units semantics in the output header.
Follow-up
- Cost per unit rose 8 percent while contracted linehaul rates were flat. Which columns do you cut first, and what does a rise in accessorials rather than linehaul point to?
- How do you separate a rate change from a mix change across mode and service_level?
- If cost genuinely had to be attributed to an order line, how would you allocate a leg's cost, and what does your rule do to a line that shipped one heavy item on an otherwise full truck?
Weekly unit fill rate by ship-from node
fct_order_line holds one row per customer order line per ship-from node in its terminal state, with ordered_qty, shipped_qty, requested_ship_date, actual_ship_at_utc, line_status and ship_from_location_id; dim_location carries location_code. Produce weekly first-pass unit fill rate by node. Numerator is shipped_qty on lines shipped on or before requested_ship_date; denominator is ordered_qty on every line requested that week except line_status = 'cancelled_by_customer'. Return node, week, numerator, denominator and rate, plus one network total row. State in the output how substituted lines are counted.
Approach
- Anchor the query at order-line grain filtered on requested_ship_date, never at shipments: a line that was never filled has no shipment row, and starting from shipments deletes exactly the failures the metric exists to count.
- Build the numerator as a conditional SUM over the same row set, SUM(CASE WHEN actual_ship_at_utc IS NOT NULL AND its ship date <= requested_ship_date THEN shipped_qty ELSE 0 END), so short and backordered lines stay in the denominator instead of vanishing behind a WHERE clause.
- Exclude only line_status = 'cancelled_by_customer'. A line cancelled for lack of supply is a service failure and belongs in the denominator at full ordered_qty.
- Group by node and by DATE_TRUNC('week', requested_ship_date), then build the network row by re-summing numerator and denominator across nodes, not by averaging the node rates.
- Declare the substitution rule explicitly in one column or one comment: lines with substituted_sku_id NOT NULL count toward the numerator only if substitution is an accepted fill in the service definition.
Follow-up
- actual_ship_at_utc is UTC but requested_ship_date is a local calendar date at the node. How does the comparison change for a node at UTC+9, and which direction does the error run?
- Fill rate rose two points while a node's short_reason_code mix moved from 'no_stock' toward 'credit_hold'. Is that a supply improvement?
- How would you hold SKU mix fixed so the network number is comparable month over month?
How do you calculate the percentage difference and ratio changes betwe…
How do you calculate the percentage difference and ratio changes between two fluctuating operational metrics?
Approach
- Fix the population and the time window before naming any metric.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
How do you determine the statistical significance of an A/B test when …
How do you determine the statistical significance of an A/B test when sample sizes between the control and variant groups are highly imbalanced?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- State the primary metric and the minimum effect worth shipping, then size the test.
- Say whether units interfere with each other, and switch design if they do.
Follow-up
- What would you do if you could not randomise at all?
- What would you conclude if the result is positive but the test is underpowered?
Price a three-point service target against inventory turns
Commercial wants the cycle service level on C/Z items raised from 95 to 98 percent at every regional DC. Finance holds you to inventory turns. Using fct_inventory_daily (on_hand_qty, standard_cost_cents, demand_qty, safety_stock_target_qty, reorder_point_qty, stockout_flag), dim_sku (abc_class, xyz_class, shelf_life_days, lifecycle_status) and receipt history for lead times, state the primary metric, the guardrail, and the arithmetic that turns the request into units, cash and a payback claim. Say what the request does not buy.
Approach
- Fix the vocabulary before any number, because the two candidate definitions are not even ordered the same way. Cycle service level is the probability of no stockout within a replenishment cycle, Phi(z). Unit fill rate under continuous review with backordering and normal lead-time demand is 1 - G(z) * sigma_dl / Q, where sigma_dl is the standard deviation of demand over the lead time, Q the replenishment quantity and G the standard normal loss function. The two are equal only at Q = G(z) * sigma_dl / (1 - Phi(z)), which is 0.418 * sigma_dl at z = 1.645 and 0.367 * sigma_dl at z = 2.054; above that Q the fill rate is the larger number.
- Convert the z change: the 95th and 98th percentiles of the standard normal are 1.645 and 2.054, so safety stock scales by 1.249 at unchanged variability. That is a 24.9 percent rise in the safety component only; cycle stock is untouched, so total inventory rises by less.
- Size the variability correctly with the variable-lead-time form, sigma_dl = sqrt(L_bar * sigma_D^2 + D_bar^2 * sigma_L^2), where sigma_L is the standard deviation of the lead time itself. On the long inbound lanes that feed C items the second term usually dominates, and the deterministic-lead-time form understates the requirement.
- Cost it: incremental units times standard_cost_cents times an annual holding rate built from cost of capital, storage and an obsolescence term that is materially larger where shelf_life_days is non-null or lifecycle_status is 'phase_out'.
- Value it honestly, and size the benefit in the unit the request actually moves. Expected units short per cycle fall from G(1.645) * sigma_dl = 0.0209 * sigma_dl to G(2.054) * sigma_dl = 0.0073 * sigma_dl, a 64.9 percent cut in shortage units. Convert that to contribution only with the margin and repeat-purchase assumptions written on the page, rather than assuming three points of service convert wholly into sales.
- Give the conflict its own line rather than smoothing it: turns fall by construction because the denominator rises against unchanged COGS, so propose a differentiated policy by ABC/XYZ cell instead of claiming both numbers improve.
Worked solution 35 min
- Compute D_bar and sigma_D per sku-location at the review-period grain the policy actually uses, and L_bar and sigma_L from receipt history in the same time unit.
- Compute sigma_dl with the variable-lead-time form, then safety stock at z = 1.645 and z = 2.054; the difference is the incremental units.
- Value those units at standard_cost_cents and apply the annual holding rate, showing the obsolescence component separately for shelf-life and phase-out SKUs.
- Read the fill rate both policies actually deliver by evaluating 1 - G(z) * sigma_dl / Q per cell at the Q in force, and report the Q/sigma_dl distribution so the cells near the crossover are visible rather than averaged away.
- Recompute inventory turns: trailing-52-week COGS over the average of daily on-hand at cost, averaged across every daily snapshot rather than month-end positions.
- Write the payback line: incremental annual carrying cost against incremental contribution from avoided shortage, with the shortage-to-lost-sale conversion stated as an assumption rather than buried in a spreadsheet.
Follow-up
- The customer contract specifies fill rate, not cycle service level. How does the answer change, and in which direction?
- The same cash could shorten the inbound lane instead. How do you compare the two options on one page?
Forecast accuracy collapsed at nodes missing snapshot rows
WMAPE at lag 7 for one region jumped from 31 percent to 58 percent over three weeks with no model change and no retraining. fct_inventory_daily is specified to carry one row per active sku-location-date even when on_hand_qty is zero, and a release changed how the end-of-day cut-off is derived from dim_location.timezone. Using fct_inventory_daily (inventory_date, sku_id, location_id, demand_qty, forecast_qty_lag7, stockout_flag) and dim_location, decide whether demand changed or the table did, and quantify the contaminated share before anyone retrains.
Approach
- Run a completeness check before touching any accuracy number: expected rows per location per day from the active sku-location grid, against actual rows present. If the table is incomplete the accuracy question is not well posed, and this check costs one query.
- Separate the two failure modes a cut-off change produces. Rows missing entirely shrink the denominator, and the sku-days that vanish are not a random sample. Rows present but with demand pushed onto the adjacent date create a one-day shift that inflates absolute error on both days while leaving the weekly total intact.
- Test the shift hypothesis directly by comparing SUM(demand_qty) per ISO week per node before and after the release. If weekly totals match and only the daily split moved, the model is fine and the grain is broken.
- Recompute WMAPE on clean node-days only and report both figures with the excluded row count and the share of demand those rows represent, since the metric definition already requires the excluded count to travel with the number.
- Check whether the affected nodes share a timezone that crosses a daylight-saving boundary or sits far from the offset the pipeline assumed. That grouping is the discriminating evidence between a code defect and genuine demand movement.
Follow-up
- Weekly totals match and only the daily split moved. Does the ordering decision care? At what replenishment frequency does it stop mattering?
- How would you backfill the missing days, and which of them would you refuse to backfill?
- What assertion would you add to the snapshot job so this fails loudly instead of surfacing three weeks later as model drift?
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.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Metric 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Diagnosing 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.
Practice prompt ↗Practice prompt ↗03Should 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.
Practice prompt ↗Practice prompt ↗04The 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Technical 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.
Practice prompt ↗Practice prompt ↗06Turning 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.
Practice prompt ↗07Mock 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.
Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
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.
Scope a vague request about rising inventory
A planning director opens with: inventory is up twelve percent on flat shipments, get me an analysis by Friday. You have fct_inventory_daily (inventory_date, sku_id, location_id, on_hand_qty, standard_cost_cents) and fct_order_line (shipped_qty, unit_cogs_cents, requested_ship_date). Nothing else is specified: not the window, not the comparison basis, not whether the twelve percent is units or value. State the three questions you would ask before writing any SQL, name the decision each answer changes, and describe the first cut you would run if nobody answers you before Friday.
Approach
- Ask what decision hangs on the answer: a buy stop, a write-off provision, a policy review and a board slide all need different cuts, and the director usually has one of them in mind.
- Pin the measurement before the cause: units or value, which two windows are being compared, and whether the denominator is average daily on-hand or a period-end snapshot, since a month-end denominator biases turns high by ten to twenty percent and can manufacture the whole movement.
- Ask which part of the network is in scope, because echelon matters: a build at echelon 2 ahead of a promotion and a build of blocked_qty at a plant are different problems with different owners.
- Commit to a default if no answer arrives: value at standard cost, averaged across every daily snapshot in both windows, cut by echelon, then by abc_class and xyz_class, then by lifecycle_status to separate phase_out stock from active cover.
- Say out loud what the first cut cannot settle, so the director is not surprised: it localises the build but does not attribute it to forecast bias, a lot-size change or a supplier pulling orders in.
Follow-up
- The build is concentrated in one product family at two DCs. What are your next two queries, and what would make you stop calling it a planning problem?
- The director wants the number by Friday and the cause by Friday. Which do you drop, and how do you say so?
Quantify your own impact on a safety stock change honestly
In March you re-sized safety stock at twelve regional DCs using the variable lead time formula. Unit fill rate at those nodes rose from 94.1 to 96.5 percent by June. In the same window a supplier that had been running 71 percent inbound on-time recovered to 93 percent, and Q2 volume is seasonally about 8 percent below Q1. Your manager asks for one sentence on impact for a performance review. Write the claim you are willing to defend under challenge, and explain how you bounded the portion attributable to your change.
Approach
- Refuse the naive claim first: the 2.4 point gross movement contains at least three generating processes, and attributing all of it is the sort of claim that collapses the moment someone plots the supplier's on-time series next to it.
- Build a comparison group from nodes that did not get the change, check that their pre-period fill rate moved in parallel with the treated nodes for at least two quarters before March, and estimate the difference in differences with variance clustered at the node, since twelve treated clusters is the effective sample size regardless of how many node-weeks there are.
- Strip the confounders you can measure directly rather than trusting the design alone: restrict to sku-location cells sourced from other suppliers to remove the recovery, and hold the sku mix fixed across periods so the seasonal volume drop does not enter through mix.
- Sanity-check the mechanism, not just the coefficient: if your change worked, the improvement should concentrate in cells whose reorder point rose and in short_reason_code = 'no_stock' lines, and should be absent where the policy did not move. If the gain is spread evenly, something else caused it.
- State the result as an interval with the confounders named, and state the cost side too: extra units held at the applicable cost of capital, so the claim is a net one rather than a service headline.
- Write the sentence so that it survives someone else re-running it, which usually means a smaller number than the gross movement and a named method.
Follow-up
- The comparison nodes are not parallel in the pre-period. What do you do next?
- Your bounded estimate is roughly half the gross movement. How do you present that to a manager who already told his boss the larger number?
Tell a sponsor the effect cannot be measured in six weeks
A VP wants a read in six weeks on a forward-stocking policy now live at eight of forty nodes. Replenishment lead time on the affected lanes is five weeks, the eight nodes were chosen by the ops team because they were the worst performers, and the cross-node standard deviation of weekly fill rate is about 3 points. The VP has already told his leadership team that a number is coming. Tell him what you can and cannot deliver in six weeks, and propose the design and timeline you would commit to instead.
Approach
- Do the power arithmetic in front of him rather than asserting the test is underpowered: comparing eight treated against thirty-two untreated node means with a between-node standard deviation of 3 points gives a standard error near 3 times the square root of one eighth plus one thirty-second, about 1.2 points, so the minimum detectable effect at 80 percent power and a two-sided 5 percent test is roughly 3.3 points. Any real effect smaller than that comes back as a null you cannot interpret.
- Name the burn-in problem separately: with a five-week lead time, six weeks covers barely one replenishment cycle, so whatever you measure is the transition rather than the new steady state, and the transition usually looks worse than the policy is.
- Name the selection problem third: nodes picked because they were worst will improve toward the network mean without any policy, so a simple before-and-after at those nodes is biased upward and will over-claim.
- Offer what is genuinely deliverable in six weeks: an implementation read, meaning whether the policy is actually in force at the eight nodes, whether inventory positions moved as designed, and whether any leading indicator such as short_reason_code mix is moving, framed explicitly as operational verification and not an effect estimate.
- Propose the real design with dates: extend to sixteen weeks covering roughly three cycles, use a difference in differences against matched comparison nodes chosen on pre-period fill rate and volume, cluster variance at the node, and pre-register the burn-in window that will be excluded.
- Help him with the commitment he already made: give him the exact wording for what he reports at week six, so the honest answer arrives as something he can say rather than as a refusal.
Follow-up
- He asks you to add the remaining thirty-two nodes to the rollout next month. What does that do to your design?
- If the effect really is 1 point, is the policy worth keeping, and how would you ever know?
- 01
A planning director opens with: inventory is up twelve percent on flat shipments, get me an analysis by Friday. You have fct_inventory_daily (inventory_date, sku_id, location_id, on_hand_qty, standard_cost_cents) and fct_order_line (shipped_qty, unit_cogs_cents, requested_ship_date). Nothing else is specified: not the window, not the comparison basis, not whether the twelve percent is units or value. State the three questions you would ask before writing any SQL, name the decision each answer changes, and describe the first cut you would run if nobody answers you before Friday.
- 02
In March you re-sized safety stock at twelve regional DCs using the variable lead time formula. Unit fill rate at those nodes rose from 94.1 to 96.5 percent by June. In the same window a supplier that had been running 71 percent inbound on-time recovered to 93 percent, and Q2 volume is seasonally about 8 percent below Q1. Your manager asks for one sentence on impact for a performance review. Write the claim you are willing to defend under challenge, and explain how you bounded the portion attributable to your change.
- 03
A VP wants a read in six weeks on a forward-stocking policy now live at eight of forty nodes. Replenishment lead time on the affected lanes is five weeks, the eight nodes were chosen by the ops team because they were the worst performers, and the cross-node standard deviation of weekly fill rate is about 3 points. The VP has already told his leadership team that a number is coming. Tell him what you can and cannot deliver in six weeks, and propose the design and timeline you would commit to instead.
Is this an official Wise. Energy interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Wise. Energy. Rounds and questions reflect what candidates have reported, not a process Wise. Energy has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the Data Scientist interview process at Wise. Energy?
A: The process is highly rigorous and rated as moderately difficult to very difficult. It tests a wide array of skills, ranging from rapid cognitive and arithmetic tests to deep-dive coding, math, and machine learning assessments. Thorough preparation across both coding and statistics is essential to succeed.
PracHub interview research ↗Do I really need to memorize code for the HackerRank assessment?
A: Yes. Candidates have reported that certain automated stages, such as the Jupyter notebook modeling task, do not provide access to external documentation. You should be highly comfortable writing standard data manipulation, EDA, and scikit-learn modeling syntax from memory.
PracHub interview research ↗What is the company's culture and working style like for Data Scientists?
A: We operate with a high degree of autonomy and ownership. Data scientists are integrated directly into cross-functional product teams, meaning you will work closely with developers and product managers. It is a collaborative, mission-driven environment where data is highly valued in every decision.
PracHub interview research ↗How hard is the Wise. Energy interview?
Candidates most commonly rate Wise. Energy interviews as medium, based on 539 reported interviews. About 21% of candidates who interview go on to receive an offer.
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.
ZF Group Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for ZF Group data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
XPO Data Scientist Interview Questions & Guide 2026
Data-quality drills for XPO 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 genuine
Xometry Data Scientist Interview Questions & Guide 2026
A prep plan for Xometry data scientist candidates built on spaced review: write a full answer before opening any solution, keep a running list of the assumptions you failed to state, and repeat every missed exercise three days later instead
W.W. Grainger Data Scientist Interview Questions & Guide 2026
Modeling drills for W.W. Grainger data scientist prep: choosing a baseline, reading regression coefficients honestly, handling class imbalance, and defending a model you would actually ship.