Write a failing test that reproduces this reported bug before you fix it.

How to answer

Palantir’s careers page names working within existing codebases as an interviewed competency, noting that developers spend far more time debugging and extending existing code than writing new code. ^[1]Source 1Working Inside Existing SystemsPublisherPalantirSource typecompany hiring page The page covers Palantir hiring in general, not the FDE loop specifically. A failing test shows that skill in minutes.

1. Restate the report as expected and actual. “A sale on the last day of the month should be in the monthly total, and isn’t.” Ask for the exact input, version and time zone; without them, say your hypothesis.

2. Shrink the input. Confirm on the real path, then cut to the smallest input and lowest function still showing the wrong value: one record, not the customer’s export.

3. Assert the correct behavior, and name the test after it. Not today’s wrong output.

   def test_sale_on_last_day_of_month_is_counted():
       sales = [Sale(datetime(2026, 3, 31, 14, 5), Decimal("40.00"))]
       assert monthly_total(sales, 2026, 3) == Decimal("40.00")

4. Run it and read the failure aloud. assert Decimal('0') == Decimal('40.00') is the symptom. An ImportError or fixture error is a broken test, not a reproduction. Run it on the version the customer runs; if it passes there, the failure you saw is a different bug from theirs.

5. Make it fail every run, with the customer’s values. Pin the clock, time zone, seed and ordering to what the customer had, not your laptop’s defaults: pinning UTC can make a month-end bug disappear.

6. Fix, then guard the other side. A neighbor test keeps midnight on the first of the next month out, so the fix is not a widened window. Then rerun the customer’s original input: if it is still wrong, the small test caught one of two bugs.

The trap is fixing first: a test you never saw fail may test nothing. The bug hunt drill practices this on unfamiliar code.