At Siemens, a Data Scientist does not work in a vacuum or focus solely on abstract digital products. Instead, you are positioned at the intersection of the physical and digital worlds. Siemens is a global powerhouse pioneering innovations in industry, infrastructure, transport, and healthcare. As a Data Scientist, your work directly impacts real-world systems—from optimizing smart grids and building digital twins for manufacturing plants to implementing predictive maintenance algorithms for high-speed trains.
The models you build and deploy are critical to driving operational efficiency, reducing carbon footprints, and enabling autonomous industrial systems. Whether you are joining the Digital Industries, Smart Infrastructure, or corporate technology teams, you will tackle massive, complex datasets generated by industrial Internet of Things (IoT) devices. This requires a unique blend of classical machine learning, deep learning, and robust software engineering practices to ensure models are stable, scalable, and safe for industrial deployment.
This role is highly collaborative and strategically influential. You will work alongside domain-specific engineers, product managers, and business leaders to translate physical-world challenges into data-driven solutions. For senior and Principal Data Scientist roles, you will also be expected to lead complex projects, mentor junior team members, and drive the adoption of cutting-edge technologies like Large Language Models (LLMs) and Generative AI across different business units.
HR Screening Call
reportedMost candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.
What to demonstrate
- Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
- Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
- The substance of the questions you ask back, which an experienced screener reads as a level signal
How to prepare
- Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
- Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
- Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered
Technical Evaluation
reportedThis round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.
What to demonstrate
- Whether your row counts survive each join, and whether you notice on your own when they do not
- Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
- Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
- Reaching a defensible answer inside the window instead of a refined one after it
How to prepare
- Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
- Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
- Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither
Detailed Technical Interviews
reportedMuch 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
Panel Interviews
reportedWhere 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
4 candidate reports. Individual accounts describe a particular role and hiring cycle.
Siemens Senior Applied Scientist Interview Experience — Recruiter Screen, Then a Data-Pipeline Coding Round and Rapid-Fire LLM Questions
I mass-applied online and roughly two weeks later got an email from a recruiter, scheduling a recruiter phone interview. Recruiter phone interview This round mostly asked about my related background (my experience doing LLM post-training), then three behavioral questions (an end-to-end work experience, a time I failed, a time I disagreed with someone). The recruiter said the team works on Physica…
Read full experienceSiemens Software Engineer interview: technical depth and resume discussion
The Siemens process felt structured and focused on technical depth without becoming a huge drawn-out process. I went through rounds that mixed coding and probing with a manager discussion and an HR step. Throughout, the questions kept coming back to my resume. In the technical rounds, I discussed core data structures and algorithms as well as real-world problem-solving scenarios. I had to explain…
Read full experienceSoftware Engineer interview at Siemens: interview experience
An agency recruiter set up my first interview after an initial chat. It was an online conversation with an engineering manager, and at that point the process seemed to be moving toward something more hands-on. I was told the next stage would have been an onsite, more technical interview, but I never reached it. The manager conversation itself was calm and conversational. I could explain my backgr…
Read full experienceSiemens Software Engineer interview: two rounds and a hiring-manager discussion
In the recruiter call, we agreed on availability and I was told to expect two rounds focused on AI/ML. The HR step was straightforward, with basic questions related to the role. I also sent some details by email and booked a Microsoft Teams slot. A short time later, I met the hiring manager online for the main discussion. We focused on my background and how it connected with the role's needs. The…
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.
Scoring intermittent demand with MAPE
MAPE is undefined whenever the actual is zero, which is most days for a C-class item at a forward-stocking location, and it is asymmetric even where it is defined: under-forecasting is bounded at 100 percent error while over-forecasting is unbounded. Optimising it therefore drives systematic under-forecasting on exactly the items whose stockouts are most expensive, and the bias is invisible in the headline because the zero-actual rows were dropped before averaging. Use WMAPE (sum of absolute errors over sum of actuals), a scaled error such as RMSSE, or a pinball loss at the service quantile the policy targets, and always state the aggregation level and forecast lag, because the same series scores very differently at daily SKU-store level and weekly SKU-region level.
Reading experiment results before checking the arm split
Compare observed arm counts against the intended allocation ratio, not an assumed even split, and set the alarm far below the conventional 0.05: at 0.05 roughly one healthy experiment in twenty trips it, which is why sample-ratio checks usually run at p < 0.001 or stricter. The test's power scales with sample size, so it misses a real diversion on a small experiment and fires on an imbalance too small to move the estimate on a very large one. A flag means go find the assignment or logging fault before reading any outcome, not report a mismatch.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the difference between bagging and boosting, and when you woul…
Explain the difference between bagging and boosting, and when you would choose one over the other for tabular sensor data.
Approach
- 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.
- Set a baseline first, so any model has something honest to beat.
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?
Walk me through the architecture of a deep neural network you have dep…
Walk me through the architecture of a deep neural network you have deployed in production.
Approach
- Say how the offline result would be validated online before it is trusted.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- Where could label leakage enter this setup?
Given a messy dataset with missing timestamps and sensor drift, walk m…
Given a messy dataset with missing timestamps and sensor drift, walk me through your step-by-step process for data cleaning and feature engineering in Python.
Approach
- Check what information would not exist at prediction time, and exclude it.
- 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
- 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?
As-of join snapshots to order lines without merge_asof
You have fct_order_line (order_line_id, sku_id, ship_from_location_id, actual_ship_at_utc, shipped_qty, shipment_id) and fct_inventory_daily (inventory_date, sku_id, location_id, available_qty). For every shipped line, attach available_qty from the latest snapshot strictly before the ship date for that exact sku and node, plus the shipment's delivery timestamp from fct_shipment_leg (leg_id, shipment_id, delivered_at_utc, leg_status). The output must have exactly one row per input order line. pandas.merge_asof is not available; implement the as-of match yourself.
Approach
- Collapse fct_shipment_leg to one row per shipment_id before joining anything. A shipment is one or more legs, so a direct line-to-leg join multiplies every line by its leg count and quietly inflates every sum computed afterwards.
- Define the shipment-level delivery as the maximum delivered_at_utc across its legs, and set it null if any leg is not delivered, since the customer has the order only when the last leg lands.
- Sort the snapshot frame by (sku_id, location_id, inventory_date) and the line frame by the same key plus ship date, then use np.searchsorted with side='left' on the sorted dates within each key group to find the insertion point; the matching snapshot is the row at position minus one.
- Guard the boundary explicitly: an insertion point of 0 means no snapshot exists before that ship date, and the result must be null rather than the first available future snapshot. Count those lines and report them.
- Assert the output row count equals the input line count immediately after each merge, before any aggregation. Row-count drift is the only symptom a silent fan-out produces, and it is invisible once the frame has been grouped.
Worked solution 30 min
- Aggregate legs by shipment_id to produce delivered_at_utc as the max, leg_count, and a delivered_all flag from leg_status.
- Left join that one-row-per-shipment frame onto fct_order_line by shipment_id and assert the row count is unchanged.
- Sort snapshots and lines by the composite key, then compute per-group insertion points with np.searchsorted and subtract one.
- Mask positions below zero to null, take available_qty at the remaining positions, and attach it as available_qty_prior.
- Validate on a single sku-location pair by printing its snapshot dates and one line's ship date and confirming the chosen date by eye.
Follow-up
- The snapshot is taken at the node's local end of day and actual_ship_at_utc is UTC. Where does that break the strictly-before rule and what do you need from dim_location to fix it?
- How would you extend this to allocate each leg's linehaul cost back to the order lines it carried?
- What changes if a line ships in two partial shipments?
Write a SQL query to calculate the rolling average of machine temperat…
Write a SQL query to calculate the rolling average of machine temperatures over a moving seven-day window.
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- State the window function and its partition and ordering out loud before writing it.
- 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?
- How would you verify this result without re-running the same query?
Lag-7 forecast accuracy and bias at weekly grain
fct_inventory_daily has one row per sku_id x location_id x inventory_date carrying demand_qty, forecast_qty_lag7 (the forecast for that date as published seven days earlier, NULL before the series existed) and stockout_flag. Compute trailing eight-week WMAPE and signed weighted bias at the sku x location x week grain the ordering decision uses: aggregate demand and forecast to the week first, then form errors on the weekly totals. Exclude any week containing a NULL forecast day and report how many cell-weeks that removed. Return one accuracy row per ABC class.
Approach
- Roll daily rows to sku-location-week with SUM(demand_qty) and SUM(forecast_qty_lag7), carrying COUNT(*) FILTER (WHERE forecast_qty_lag7 IS NULL) so a partial week is visible rather than quietly summing to an artificially low forecast.
- Drop cell-weeks with any NULL forecast day and emit the dropped count as a column: an accuracy figure without its exclusion count cannot be checked by anyone.
- WMAPE = SUM(ABS(weekly_demand - weekly_forecast)) / NULLIF(SUM(weekly_demand), 0). Bias = SUM(weekly_forecast - weekly_demand) / NULLIF(SUM(weekly_demand), 0), signed, with cancellation as the whole point of reporting it next to WMAPE.
- Join dim_sku for abc_class and group there by re-summing both sides. Averaging per-SKU WMAPE gives a number weighted by nothing in particular.
- Report the share of retained cell-weeks containing a stockout day beside the result, because demand_qty on those days is censored at what could be supplied and the error is being scored against a truncated actual.
Worked solution 25 min
- CTE one: GROUP BY sku_id, location_id, DATE_TRUNC('week', inventory_date) with SUM(demand_qty), SUM(forecast_qty_lag7) and the NULL-day count.
- CTE two: split the cell-weeks into retained (null_days = 0) and excluded, and keep COUNT(*) of each.
- Join dim_sku on sku_id for abc_class, then aggregate the retained set per class with the two ratio formulas.
- Compute the stockout exposure share over the same retained set and attach it to each class row.
- Print retained count, excluded count and window bounds alongside every ratio.
Follow-up
- Why is MAPE unusable on a C-class item at a forward-stocking location, and what do you score it with instead?
- WMAPE improves sharply when you move from sku-location-week to sku-region-week. Which of the two belongs in the planning review, and why?
- Bias is +6 percent and WMAPE is 45 percent. What does that pair tell you to investigate first?
Explain how you would optimize a slow-running PySpark or Pandas pipeli…
Explain how you would optimize a slow-running PySpark or Pandas pipeline processing millions of daily IoT events.
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
- Name one primary metric, then the guardrail that stops it being gamed.
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?
Value a staggered forward-stocking rollout that was never randomised
Six forward-stocking locations were opened over five months, chosen because their regions had the worst P90 order cycle time. There is no holdout. You have 24 months of node-month history in fct_order_line and fct_shipment_leg for all 40 nodes, and each new location draws its volume from the regional DC that used to serve the same customers. Estimate the effect on P90 order cycle time and on landed cost per delivered unit, and state the assumption your estimate rests on and how you test it.
Approach
- Fix the unit of analysis before choosing an estimator. Volume transfers from the parent regional DC to the new location, so the parent is treated by interference: its mix, lane density and cost per unit all change. Aggregate to the region, meaning new location plus parent, so the transfer is internal, and keep parents out of any comparison group.
- Name the selection problem. Sites were picked on the worst pre-period outcome, so mean reversion alone manufactures an apparent improvement. Difference-in-differences does not require matching levels, only that untreated trends would have been parallel; test that with an event-study specification whose lead coefficients should be indistinguishable from zero, and look specifically for a pre-period dip that would have reverted on its own.
- Avoid the naive two-way fixed effects estimator. With five distinct opening dates and effects that grow after opening, TWFE uses already-treated regions as controls for later ones and can put negative weight on those comparisons; use a group-time estimator such as Callaway and Sant'Anna or Sun and Abraham with never-treated regions as the comparison group, then aggregate to a dynamic path.
- Run synthetic control per treated region as an independent second read: fit donor weights on pre-period P90, volume and lane mix, require pre-period fit error that is small relative to the post-period gap, and obtain inference from placebo-in-space permutations, ranking the treated gap against every donor's placebo gap.
- Be honest about inference with six treated units. Cluster-robust standard errors are badly anti-conservative at that count, so use a wild cluster bootstrap with Rademacher weights or randomisation inference over opening dates, and report both outcomes together, since cycle time bought with expedite premium is a different result from cycle time bought with position.
Worked solution 40 min
- Build a region-month panel: P90 order cycle time computed from raw line-level durations per region-month, plus landed cost per delivered unit, plus an opening-date column.
- Fit an event study relative to opening month with region and calendar-month fixed effects, and inspect leads from minus six to minus one.
- Estimate group-time average treatment effects with never-treated regions as controls, then aggregate to a dynamic path and a single post-period average.
- Fit a synthetic control per treated region, compute the treated gap and every donor's placebo gap, and report the rank-based p-value.
- Re-run inference with a wild cluster bootstrap at the region level, and present the DiD and synthetic control estimates side by side, flagging disagreement rather than picking the friendlier one.
Follow-up
- Your event study shows a downward lead coefficient two months before opening. What are the two explanations, and how do you tell them apart?
- One region's synthetic control has a pre-period fit error as large as its post-period gap. What do you report for that region, and does it enter the pooled estimate?
A seven percent demand rise that is a calendar artefact
A planner reports regional demand up 7 percent for the most recent four weeks against the prior four and wants safety stock raised. fct_inventory_daily is cut at each node's local end of day using dim_location.timezone and working_calendar_id. The recent window contains one public holiday fewer and spans a daylight-saving transition. Using fct_inventory_daily (inventory_date, location_id, sku_id, demand_qty, stockout_flag), dim_location and dim_sku, test whether underlying demand moved at all. Deliverable: a calendar-adjusted growth figure and a statement of what you would raise, if anything.
Approach
- Count exposure before comparing totals, and be exact about what can differ. Any 28-day window contains exactly four of each weekday whatever date it is anchored to, so two consecutive four-week windows have identical weekday composition and a weekday-mix reweighting between them is identically zero. Assert it rather than assume it, then set it aside. The weekday term only becomes live when a window is not a whole multiple of seven days, which happens the moment someone compares calendar months or a truncated most-recent week, so the assertion is worth keeping in the query.
- What does differ is working days, and that is where the arithmetic lives. Derive each window's non-working dates per node from working_calendar_id: on a five-day calendar a 28-day window holds 20 weekdays, so one public holiday fewer takes a node from 18 working days to 19 (5.6 percent more selling exposure) or from 19 to 20 (5.3 percent), before any demand moves. Compare demand per working day, not demand per calendar day.
- Weight those days the way demand is actually distributed. Because order cut-offs are daily and local, days are not interchangeable: build a day-of-week index per node from 52 weeks of history with holiday dates excluded (mean demand_qty by weekday over the node's overall daily mean), and define exposure as the sum of that index across the window's working days. Demand per unit of index-weighted exposure is the adjusted figure; demand per plain working day is the cruder version and is wrong by the index spread whenever the holiday falls on an unusually heavy or light weekday.
- Measure the holiday's shoulder separately, because the exposure adjustment cannot see it. Orders that would have been placed on the closed day arrive on the working day before or after, so a window with one holiday fewer also loses the displaced spike its neighbours carried. Compare demand_qty on the two working days either side of each holiday against those weekdays' index values and report the displaced units as their own line.
- Bound the daylight-saving effect instead of arguing about it. The snapshot is cut at local end of day, so one inventory_date per timezone spans 23 or 25 hours: at most one extra or missing hour of order capture on one of 28 days, about 0.15 percent of the window even if that hour carried normal trading volume, which at an overnight transition it does not. Identify the transition date per timezone, compare its demand_qty against neighbouring same-weekday dates, and report growth with and without it so the term is shown to be small rather than presumed to be. Then test whatever residual survives against the same calendar weeks one year earlier under the identical exposure adjustment, and ask whether it is demand or the relaxation of censoring: an order never placed because the item displayed as unavailable leaves no row at all, so a window with fewer stockout days records higher demand_qty with underlying demand flat. Cut the residual by stockout_flag history per sku-location before calling it growth.
Follow-up
- After adjustment the growth is 0.4 percent with a wide interval. What do you tell the planner, and what would change your answer?
- Which of these adjustments would you bake into the standard report, and which stay manual because they need judgement?
- If the residual is recovered censored demand rather than growth, does that argue for more safety stock or less?
Roughly 90 minutes a night on weekdays with one longer weekend block. The plan deliberately cuts scope rather than compressing everything, on the assumption that finishing one thing a night beats half-starting four.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Fix the scope and set a baseline
- Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list for everything else and keep it visible all week.
- Take one 20-minute SQL prompt and one 10-minute metric question cold, and write the single sentence that says what blocked each attempt, since that sentence is what decides which two topics get the most evenings.
- Set the week's one rule: one problem finished to completion every night, including the night you only have 40 minutes.
Deliverable: A one-page scope with an explicit not-doing list and two cold attempts, each carrying one sentence on what blocked it.
Practice prompt ↗Practice prompt ↗Worked solution ↗02One query pattern, written three times
- Choose the single pattern most likely to appear (a cohort retention grid, or a funnel counted by user) and write it three times from a blank file rather than editing the previous attempt.
- On the third attempt, write the grain of every CTE as a comment before writing its body.
- Stop at 90 minutes even if the third version is imperfect, and write the one thing you would fix with another hour.
Deliverable: Three independent versions of the same query plus a note on what changed between them.
Practice prompt ↗Practice prompt ↗03Only the statistics you will be asked to defend
- Write, in under 200 words, how you would decide whether a difference between two groups is real: the test, its assumptions, and what you would switch to when an assumption fails.
- Compute a 95 percent confidence interval for a difference in proportions by hand on realistic numbers, then write in one sentence what changes if the two samples are paired rather than independent.
- Write your answer to "what does a p-value mean", check it against a definition, and delete the version that describes it as the probability the hypothesis is true.
Deliverable: A 200-word written answer and one hand-computed interval you can reproduce under pressure.
Practice prompt ↗Practice prompt ↗04One case, and the assumptions holding it up
- Answer one product case aloud in 20 minutes with a recording running, then listen back with a pen and mark every claim you asserted without saying what it rested on: an assumed user behaviour, an assumed data source, an assumed baseline rate, an assumed grain.
- Pick the three assumptions the recommendation actually depends on, write how you would check each one against data, and say which one being wrong would flip the recommendation rather than merely weaken it.
- Write the four-step structure you used onto a card small enough to hold in working memory when you are nervous.
Deliverable: One recording, three load-bearing assumptions each with a written check, and a four-step structure card.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Your own work, timed
- Write a 90-second version and a four-minute version of your main project, and time both out loud rather than reading them.
- Prepare answers to the two follow-ups that always come: what you would do differently, and how you knew it worked.
- Put one number in the first sentence and be able to say exactly where that number came from and what it excludes.
Deliverable: Two timed narratives with one defensible number in the opening line.
Practice prompt ↗Practice prompt ↗06The one full rehearsal, in a longer weekend block
- Run a 60-minute mock covering query work, a case and a behavioural question in a single sitting with no breaks, because sustained attention is the thing evenings have not trained.
- Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
- Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.
Deliverable: Mock notes naming three failure moments with a specific fix written under each.
Practice prompt ↗07Taper
- Write the 20-minute warm-up you will actually do on the morning of the interview: one query you can already write from a blank file, one metric you can define out loud, and nothing you have never seen before.
- Re-read only your own notes from this week, and open no new material.
- Write down the logistics: the tool you will be asked to work in, whether lookups are allowed, and the sentence you will use when you do not know something.
Deliverable: A one-page card holding the case structure, the project numbers, and the logistics.
Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Nearly every data role forces a trade between the analysis you want and the one that fits the decision window. Prepare a case where you deliberately shipped something less rigorous, named the weakness to the person relying on it, and said what would change your answer. The naming is the part interviewers listen for.
How do you handle highly imbalanced datasets, which are common in pred…
How do you handle highly imbalanced datasets, which are common in predictive maintenance and anomaly detection?
Approach
- 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.
- Quantify the outcome, including what you would not claim credit for.
Follow-up
- How did you know the outcome was caused by your change?
- What did you decide not to do, and why?
Defend a finding that the expedite program bought nothing
Over two quarters, expedite_premium_cents on outbound legs in fct_shipment_leg rose from 0.4 to 1.3 percent of landed cost, while perfect order rate moved from 91.2 to 91.5 percent, inside the week-to-week spread. The transport lead who sponsored the expedite program disputes the finding in a review in front of his director, arguing that your window contains a port disruption that would have made service worse without the spend. Present the finding, say what you concede on the spot, say what you hold, and name the evidence that would change your conclusion.
Approach
- Restate his objection in its strongest form before answering it, because a counterfactual worsening is a legitimate argument and treating it as an excuse ends the conversation.
- Separate what you measured from what you claimed: the data show no detectable service gain, not that expedite has no effect, and the difference is the entire argument.
- Test his hypothesis with the data you already have rather than defending in the abstract: split legs by exception_code = 'customs_hold' and by lane, and compare expedited against non-expedited legs on the same lanes in the same weeks, since if expedite were holding the line the expedited lanes should show a service gap over comparable non-expedited ones.
- Concede what is true: without a holdout you cannot rule out a protective effect, and the pre-period is contaminated by the disruption, so the honest statement is an upper bound on the gain rather than a zero.
- Hold the part that survives: the spend is real, it is concentrated in a small set of lanes, and nobody set a decision rule for when a leg gets expedited, which is a controllable problem independent of the counterfactual.
- Name the next measurement: a lane-level staggered switch-off with a stated burn-in, and say what it would cost and how long it would take.
Follow-up
- He offers to run the switch-off only on his two best lanes. Why is that a problem, and what do you counter with?
- His director asks you for a yes or no on cutting the budget today. What do you say?
Walk through an inventory analysis that turned out wrong
Six months ago you published inventory turns by node using the month-end on_hand_qty snapshot from fct_inventory_daily as the denominator, and two DCs cut cover on the strength of it. A finance review later showed month-end is systematically the lowest on-hand point of the month, because shipments cluster before close, so your turns were overstated and days of supply understated. Tell the story: what you built, how the error surfaced, what it cost, what you corrected, and the control that now prevents this class of mistake rather than this specific instance.
Approach
- Give the facts in order and own the decision, not just the code: you chose the month-end snapshot because it was one row per sku-location and fast, and you did not check whether the sampling point was representative.
- Quantify the error rather than describing it: recompute the same window against the average of every daily snapshot and state the gap in turns and in days of supply, which in a network with close-period push typically runs ten to twenty percent.
- Separate the consequence from the mistake honestly: say what the two DCs did, whether service actually degraded, and if it did not, say so instead of inflating the damage to sound accountable.
- Describe the correction and the notification: who was told, how quickly, and whether the restated number changed the recommendation.
- Close on the generalised control: a denominator convention written into the metric definition, plus a row-count assertion at each join grain, because the same shape of error appears when a daily snapshot is joined to shipment events on date equality and one shipment with several legs fans the snapshot out.
Follow-up
- How did you decide whom to tell first, and how did you phrase it?
- What made you trust the month-end snapshot in the first place, and what would have caught it in review?
- 01
How do you handle highly imbalanced datasets, which are common in predictive maintenance and anomaly detection?
- 02
Over two quarters, expedite_premium_cents on outbound legs in fct_shipment_leg rose from 0.4 to 1.3 percent of landed cost, while perfect order rate moved from 91.2 to 91.5 percent, inside the week-to-week spread. The transport lead who sponsored the expedite program disputes the finding in a review in front of his director, arguing that your window contains a port disruption that would have made service worse without the spend. Present the finding, say what you concede on the spot, say what you hold, and name the evidence that would change your conclusion.
- 03
Six months ago you published inventory turns by node using the month-end on_hand_qty snapshot from fct_inventory_daily as the denominator, and two DCs cut cover on the strength of it. A finance review later showed month-end is systematically the lowest on-hand point of the month, because shipments cluster before close, so your turns were overstated and days of supply understated. Tell the story: what you built, how the error surfaced, what it cost, what you corrected, and the control that now prevents this class of mistake rather than this specific instance.
Is this an official Siemens interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Siemens. Rounds and questions reflect what candidates have reported, not a process Siemens 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 Siemens?
The overall difficulty is generally rated as average to challenging, depending on the seniority of the role. While the coding and basic modeling assessments are straightforward, the technical deep dives into your past projects and the machine learning system design rounds are highly rigorous and detailed.
PracHub interview research ↗What is the typical timeline from the initial application to an offer?
The entire process usually takes between three to four weeks. Siemens is known for running a structured and punctual recruitment process, and candidates typically receive consistent feedback after each stage.
PracHub interview research ↗How much emphasis is placed on deep learning versus classical machine learning?
Both are highly valued, but the emphasis depends on the team. Industrial IoT and predictive maintenance roles rely heavily on classical machine learning and time-series analysis, while computer vision, robotics, and generative AI teams focus deeply on neural networks and LLMs.
PracHub interview research ↗Does Siemens support remote or hybrid working models for Data Scientists?
Yes, Siemens offers flexible, hybrid working arrangements in most locations, allowing you to balance remote work with in-office collaboration. The exact policy depends on your specific team and local office guidelines.
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