A manufacturer says unplanned downtime is killing its margins. They have sensor data nobody uses. What do you do?

Split the lost minutes into how often stops happen and how long each lasts, because sensors help most with the first. They can shorten diagnosis, but not the wait for a technician or a part. The prompt offers you the sensor data as the answer; treat it as one input to check, and start from money. One candidate who reported an entry-level Databricks FDE loop, in a report posted in August 2026, called the decomposition round the most important and said it meant treating the interviewer almost like a client, clarifying stakeholder, scope and KPI before touching architecture. The steps below keep that order: money and people first, data second, a model last. Ask where downtime costs most, and why. Which lines, which failure modes, how many minutes last quarter. Then split those minutes into stop count and time to repair. If the capper stops rarely but each stop waits hours for a technician or a part, spares and response time beat any sensor. A stop on the bottleneck line loses output; a stop on a line with a buffer after it may lose little. Ask whether the plant sells everything it makes; if not, a lost hour costs overtime and scrap, not lost sales. Name the people and the metric. The plant manager owns the margin target. Maintenance planners and technicians act on any alert, and operators log why a line stopped. Controls engineers own the PLCs, the historian and the plant network you must not disturb: read from the historian, ideally a copy outside the control network, and never poll PLCs directly. Success is fewer unplanned minutes per scheduled production hour on that line, against last quarter’s baseline, with planned maintenance hours and ignored alerts beside it. Use the plant’s own words: stop count drives MTBF, repair time is MTTR, and both feed the availability term of OEE. Check the inputs before trusting them. Historian tags, downtime events from the MES, work orders from the maintenance system. For each, ask the owner, the sampling rate, the history and whether tags map to physical assets. “Nobody uses it” often means no tag-to-asset map and no failure labels. Pick one line and one failure mode: the most expensive one that leaves a trace before it happens. Sudden jams do not. Label past failures. Sit with a technician and turn a year of work orders into labeled events. Ship a rule before a model. A daily report for the maintenance planner, with a threshold they can argue with, set by comparing readings before failures with readings from normal running. Plant-wide predictive maintenance is the promise to avoid. Without labeled failures you cannot tell a model that works from one that does not.

Reduce factory downtime | FDE interview question

Where it comes from

Candidates report this round type at Databricks; the prompt is oursSource 1Databricks Forward Deployed Engineer Interview ExperiencePublisherAced (formerly Exponent)Source typecandidate’s personal write-up More Databricks questions The Databricks interview guide

How to answer

Split the lost minutes into how often stops happen and how long each lasts, because sensors help most with the first. They can shorten diagnosis, but not the wait for a technician or a part. The prompt offers you the sensor data as the answer; treat it as one input to check, and start from money.

One candidate who reported an entry-level Databricks loop, in a report posted in August 2026, called the the most important and said it meant treating the interviewer almost like a client, clarifying stakeholder, scope and KPI before touching architecture. Source 1Databricks Forward Deployed Engineer Interview ExperiencePublisherAced (formerly Exponent)Source typecandidate’s personal write-up The steps below keep that order: money and people first, data second, a model last.

Ask where downtime costs most, and why. Which lines, which failure modes, how many minutes last quarter. Then split those minutes into stop count and time to repair. If the capper stops rarely but each stop waits hours for a technician or a part, spares and response time beat any sensor. A stop on the bottleneck line loses output; a stop on a line with a buffer after it may lose little. Ask whether the plant sells everything it makes; if not, a lost hour costs overtime and scrap, not lost sales.
Name the people and the metric. The plant manager owns the margin target. Maintenance planners and technicians act on any alert, and operators log why a line stopped. Controls engineers own the PLCs, the historian and the plant network you must not disturb: read from the historian, ideally a copy outside the control network, and never poll PLCs directly. Success is fewer unplanned minutes per scheduled production hour on that line, against last quarter’s baseline, with planned maintenance hours and ignored alerts beside it. Use the plant’s own words: stop count drives MTBF, repair time is MTTR, and both feed the availability term of OEE.
Check the inputs before trusting them. Historian tags, downtime events from the MES, work orders from the maintenance system. For each, ask the owner, the sampling rate, the history and whether tags map to physical assets. “Nobody uses it” often means no tag-to-asset map and no failure labels.
Pick one line and one failure mode: the most expensive one that leaves a trace before it happens. Sudden jams do not.
Label past failures. Sit with a technician and turn a year of work orders into labeled events.
Ship a rule before a model. A daily report for the maintenance planner, with a threshold they can argue with, set by comparing readings before failures with readings from normal running.

Plant-wide predictive maintenance is the promise to avoid. Without labeled failures you cannot tell a model that works from one that does not.

Follow-ups

What the interviewer may ask next, once your first answer is on the table.

Sketch the table that joins a sensor reading to a downtime event.
The historian samples every minute but failures show up in seconds. What now?
Maintenance logs are free text. How would you label failures for the first line?

Where answers go wrong

Promises predictive maintenance across the plant instead of one line with labeled failures.
Opens with a model on the sensor data before asking which line loses the money, or whether any failure has ever been labeled.

Answer this in two minutes

Write the answer you would say out loud. The clock starts with your first word.

Compare with the model answer

Model answer

The first minute and a half. “Before the sensors, I’d find which line loses the most margin and split its lost minutes into how often it stops and how long each repair takes, because sensor data mainly helps with the first. The plant manager owns the target, the maintenance planner acts on any warning, and the controls engineer decides what I may read, so I read from the historian and never touch the PLCs. The missing piece is usually a map from historian tags to machines, plus failures nobody labeled, so I build both for one line with a technician. Then I ship one readable rule to the planner as a morning report, and measure unplanned minutes per scheduled production hour against last quarter. A model comes after we have enough labeled failures to test it.”

If they want the detail:

Cost and scope. “Before the sensors: which line loses the most margin to unplanned stops? I’d ask for downtime minutes by line and reason code for the last quarter, and finance’s margin per hour of output. Say that points at the filling line, which is the bottleneck, and the top reason is the capper. I split the capper’s minutes into stop count and time to repair, broken into waiting for a technician, diagnosis, waiting for parts and fixing; those timestamps come from the work order. Sensors mainly help with the count, and a little with diagnosis. Last quarter’s unplanned minutes per scheduled production hour on that line are the baseline.”

“Then the money, out loud. Say the capper stopped 38 times last quarter for 55 minutes each, and finance puts margin at $4,000 an hour on the bottleneck line. That’s about $139,000 a quarter, which sets what a pilot is worth, and tells me whether a spare capper head on the shelf would beat any sensor work.”

People. “The plant manager owns the margin target and signs off on the pilot. The maintenance planner is my user, because a warning is only useful if it turns into a scheduled job. The controls engineer is the blocker: nothing touches the PLCs or the plant network without them, so I read from the historian, ideally a copy outside the control network.”

The join. “The table everyone is missing is the map from historian tags to physical assets. With it, I can pull the readings before each stop:”

CREATE TABLE downtime_event (
  event_id      bigint PRIMARY KEY,
  line_id       text        NOT NULL,
  asset_id      text,                 -- null when the operator logged only the line
  started_at    timestamptz NOT NULL,
  ended_at      timestamptz,
  reason_code   text,                 -- operator's pick list, often 'other'
  work_order_id text                  -- link to the maintenance system, often missing
);

CREATE TABLE tag_asset (
  tag           text PRIMARY KEY,     -- historian tag name
  asset_id      text NOT NULL,
  unit          text,
  sample_period interval
);

SELECT d.event_id, r.tag, r.ts, r.value
FROM downtime_event d
JOIN tag_asset ta     ON ta.asset_id = d.asset_id   -- stops with no asset drop out here
JOIN sensor_reading r ON r.tag = ta.tag
                     AND r.ts >= d.started_at - interval '7 days'
                     AND r.ts <  d.started_at
WHERE d.line_id = 'filling_2';

“I pull the same windows at random times with no stop after them, for the same assets. A threshold that fires as often before normal running as before failures is noise. I drop windows that contain another stop or a maintenance job, and I draw the normal-running windows only from scheduled production time, so readings taken during a repair or a planned stop never count as normal running. And I report how many stops have no asset, because the join drops them. I’d also ask for recorded values, not interpolated ones. Historians often store compressed data, and interpolation can smooth over the spike I’m looking for.”

Minute samples, second-scale failures. “Minute data can still show slow drift: motor current creeping up, temperature rising over days. It can’t show a sub-minute event. So I ask the controls engineer two things for this one line: can the capper’s tags be collected faster, and can the edge compute a per-minute max and RMS so a spike isn’t averaged away? I would not promise bearing diagnostics from minute averages; that needs a vibration sensor sampling far faster.”

Labels. “I pull a year of work orders for the line. A technician and I agree on a short taxonomy, component and failure mode, and label a sample together. Keyword rules or a language model label the rest, and I report agreement against our hand labels before anyone trusts them. Then I link each labeled work order to a downtime event by asset and overlapping time.”

First slice. “One line, one failure mode, one morning report for the planner: capper assets whose current or temperature trend crossed a threshold, plus their recent work orders. A rule they can read. A model comes after we have enough labeled failures to test it.”

Failure modes and metric. “Operators pick ‘other’ when they are busy, so I check reason-code quality each week. Too many false alerts and the planner stops reading, so ignored alerts are a guardrail. The metric is unplanned minutes per scheduled production hour on the filling line, not raw minutes, so a busier quarter doesn’t look like a failure; I compare it with last quarter, next to planned maintenance hours. In the plant’s terms, the stop count drives MTBF, repair time is MTTR, and both feed the availability term of OEE.”