Case Study: Improve City Traffic with Sensor Data

A city, a pile of sensor data and a goal with no owner

Someone hands you five years of road-sensor readings and says "use it to improve traffic". Where does the first box on the whiteboard go? Nowhere yet, because nobody has said who the work is for. "Improve traffic in New York City" is reported as a Palantir decomposition prompt in candidate write-ups collected by prep guides (Aced's Palantir FDE guide), and Aced's Databricks guide reports a 60-minute decomposition round that asks how to use city traffic data to reduce congestion and define the KPI (Aced's Databricks FDE guide). Both are second-hand reports, so treat the wording as approximate. Your version will differ in the details and match in shape: a city, a pile of sensor data, a goal with no owner.

To rehearse that shape, here is a fictional brief. Every number in it is made up for this lesson.

Harbour City's transportation department has installed roughly 1,200 roadside sensors over five years: inductive loops in the road surface that report vehicle counts and occupancy every 30 seconds, plus a few dozen cameras at major junctions. The commissioner says: "We have years of this data and traffic keeps getting worse. Use it to improve traffic." You have 60 minutes and a whiteboard.

Look for three things in it: who the work is for, what decision it should change, and how anyone would know it worked. None of them is there, and that gap is the exercise.

Three groups could use the same sensor feed

Read as an engineering spec, "improve traffic" invites a city-wide model that tunes every signal. Read as a customer request, it describes a commissioner under pressure who owns a data asset and wants it to pay off. The second reading prompts a better question: whose behaviour would change if the data were put to work? Three groups could use the same feed, and they need different things from it.

The table is the first useful thing to draw, because it turns "traffic" into three products and forces a choice. The commissioner can reach operators and planners directly. Commuters are reachable only through third-party apps the city does not control, which makes them a weak first user however sympathetic their case.

What the interviewer means, then, is closer to this: pick one person who can act on the output, find out whether the data can support what they need, and give them something within two weeks. That maps onto the decomposition rubric the research file lists for Palantir: structured breakdown, end-user anchoring, data reasoning, scoping to an MVP, and iteration with success metrics. A strong opening, said aloud: "Before I draw any architecture, I'd like to know who in the department would do something differently next Monday if this worked. Is it the control room, the planning team, or someone else?"

The candidate states an assumption: "I'll assume the control-room operators are the first user, because they act within minutes and the department already employs them. Their decision is which incident to respond to and whether to change a signal plan. If I'm wrong and the commissioner cares more about the annual capital plan, the same pipeline feeds planners later with a different output." The interviewer confirms operators, who currently learn about congestion from radio calls and camera wall checks. That is the process the MVP has to beat.

Asking about the loops before touching a model

With a user chosen, the temptation is to sketch a model. The candidate does something duller first and asks about coverage, outages, clocks and drift, because each is a specific way sensor data can mislead.

Coverage is the share of segments on each corridor with a working sensor; a corridor with half its loops dead produces alerts with holes in them. Outages matter because of how a dead loop reports. A missing row or a null is visible. If it writes a zero, a zero count at 8am looks like an empty road, which is the opposite of the truth, and anything trained on it learns that the broken segments flow freely. Clock alignment matters because loops on different controllers may have drifting clocks, so readings should be bucketed into fixed 5-minute bins before neighbouring sensors are compared. Drift matters because loop sensitivity degrades over time, so a sensor's "normal" should come from its own recent history rather than a city-wide constant.

Coverage takes one query to check. In Postgres 14 or later, date_bin buckets timestamps, and a 30-day window has 30 × 288 = 8,640 five-minute bins, so the distinct bins a sensor reported in, divided by 8,640, give its reporting share.

SELECT s.sensor_id,
       s.corridor,
       COUNT(DISTINCT date_bin('5 minutes', r.observed_at,
                               TIMESTAMPTZ '2026-01-01'))
         / 8640.0 AS reporting_share
FROM sensors s
LEFT JOIN readings r
  ON r.sensor_id = s.sensor_id
 AND r.observed_at >= now() - interval '30 days'
GROUP BY s.sensor_id, s.corridor
ORDER BY reporting_share;

Sorting ascending puts the worst sensors at the top. Keep that list, because it matters later.

Corridor 7 looks like the obvious pick until you ask

The candidate's first instinct is Corridor 7, the busiest arterial, because a win there would be visible to the commissioner. They say so, and the interviewer reveals a fact: "Corridor 7 was resurfaced last spring. About 40 percent of its loops were cut and have not reported since. Corridor 3 is the second busiest and has close to full coverage."

The weak response keeps Corridor 7 and proposes filling the gaps with interpolation. It sounds resourceful, but interpolating across a run of dead loops invents exactly the congestion signal the operators would act on, so the detector would fire on numbers nobody measured. The strong response switches corridors and says why: "Then I'd move the MVP to Corridor 3. A detector on a corridor where four loops in ten are silent would have holes exactly where operators look. The Corridor 7 gap is itself a finding: I'd hand the maintenance team a ranked list of dead sensors from that query, because no detector on that corridor works until they are repaired."

Is giving up the busiest corridor a loss? A little, in visibility, but the commissioner gets a working detector on the second-busiest road and a repair list that makes Corridor 7 usable later. The interviewer injected the resurfacing fact to see whether the plan bends when the data says it should.

A congestion alert on one corridor

The MVP is congestion detection on Corridor 3, delivered to operators. For each segment and 5-minute bin, compare occupancy (the share of time a vehicle sits over the loop) with the same segment's baseline for that weekday and time of day over the previous eight weeks. Raise an alert when occupancy exceeds the baseline's 95th percentile for three consecutive bins, and say in the alert which segments are affected and for how long. The weekday-and-hour baseline stops the detector from shouting about every ordinary rush hour.

Three bins means 15 minutes of persistence, which suppresses single noisy readings at the cost of slower alerts. State that trade-off aloud and say the operators should help tune it, since they know how many false alarms they will put up with. The output goes where operators already look, a panel in their console or a message in the channel they monitor, and no new dashboard in week one.

Signal optimization comes later, if at all. It needs traffic-engineering sign-off, a simulation or careful field trial, and authority over the signals, and the department may not own every controller on the corridor. Detection needs none of those things, which is why it goes first.

Measuring against the last twelve weeks

The candidate proposes measuring two things on Corridor 3, both baselined on historical data before launch. Say, as made-up numbers, the last 12 weeks show a median of 14 minutes from congestion onset to the first operator action, reconstructed from incident logs, and a median peak-hour travel time of 22 minutes end to end.

The MVP's target is the first number: cut onset-to-action time, because that is what the operators control. Travel time is the outcome the commissioner cares about, and it moves for many reasons, so it gets tracked against a comparable corridor that did not get alerts. Without that comparison, a quiet holiday month would look like a triumph. A third, guard-rail metric is alerts dismissed per shift. If operators dismiss most alerts, the threshold is wrong and they will stop reading them.

The city-wide model and its smaller relatives

The failure this case is built to catch is proposing a city-wide optimization model without checking sensor coverage or asking who can act on the output. It costs points on two rubric lines at once. "Data reasoning" goes because the model is trained on whatever the loops wrote, including zeros from dead sensors. "End-user anchoring" goes because nobody in the room owns a city-wide signal plan, so the model's output has no one to receive it. The same mistake also comes in smaller sizes, and each costs a rubric line of its own.

The last row deserves a question in the room. Some signals on a city corridor may belong to a different agency, and an output that recommends changing them goes nowhere. Asking who runs the controllers takes one sentence.

How this shows up in the interview

Per the research file, Palantir's decomposition round is reported as 60 minutes at a whiteboard with minimal code, built around a vague prompt, and the interviewer injects new constraints as you go; AI tools are reported as prohibited in Palantir's real interviews (Aced, Ophy). Aced's Databricks guide reports a 60-minute decomposition round with a city-traffic prompt and an explicit request to define the KPI (Aced).

Expect the interviewer to withhold the data-quality facts until you ask. The Corridor 7 reveal above is the kind of thing that only arrives if you ask about coverage, and the credit goes to asking and then changing the plan. Expect pushback too: "Why not just optimize every signal in the city?" A good reply names the dependency chain: "Because I don't yet know which signals the city controls, which sensors work, or who would approve a timing change. Detection on one well-covered corridor tells us all three within two weeks, and it's useful to operators on its own."

For Databricks-style phrasing, have the KPI ready with its baseline and its owner. "Median minutes from congestion onset to first operator action on Corridor 3, baselined on the last 12 weeks, owned by the control-room supervisor" is a complete KPI. "Reduce congestion" is not.

Check yourself

• Why are commuters a weak first user for a city transportation department's sensor project? Answer: The department reaches commuters only through map apps it does not control, so it cannot ship them anything in two weeks or measure their decisions. Operators and planners are internal and act on the output directly.
• A dead loop writes a count of zero. What does that do to a naive congestion model? Answer: It makes the segment look empty, often at the busiest hour, so the model learns that broken segments flow freely and never alerts on them. Outages must be marked as missing before any baseline is computed.
• The interviewer says your chosen corridor has 40 percent of its sensors offline. What do you do? Answer: Move the MVP to a corridor with near-full coverage, and report the dead sensors to maintenance as a finding. Interpolating across long gaps would fabricate the very signal operators act on.
• What makes "reduce travel time" an incomplete success metric for this MVP? Answer: It has no baseline, no owner, and it moves for reasons the MVP does not control. Pair a controllable metric (onset-to-action time, baselined on historical incident logs) with travel time tracked against a comparison corridor.