Tell me about a time you had to understand an undocumented system. How did you build your map?

How to answer

Palantir’s company-wide engineering interview guides define one competency as working within existing systems, codebases and infrastructure. ^[1]Source 1Working Inside Existing SystemsPublisherPalantirSource typecompany hiring page The method is the answer; the story is its evidence. Use three sources, each checked against the others: what the system does, what happens when you poke it, and what its people know.

1. The system and the stakes. What it did, why you needed it mapped and by when.
2. Traces first. Follow one real record end to end through logs, the query log, scheduler entries and network calls, starting from the path your change touches. If it doesn’t log, watch its edges: tables it writes, files it drops, connections it opens.
3. Experiments. Reversible probes on a copy whose outbound side you have cut: scheduled jobs off, email and partner endpoints stubbed, read-only credentials for anything real. A copy that still runs its cron jobs sends real invoices. Then change one input and watch the output, and write characterization tests that pin current behavior.
4. People. Who runs it, who gets paged, who changed it last (commits, old tickets). Bring them your draft map to correct, not a blank page.
5. The artifact. What you wrote down (entry points, data stores, schedules, owners, open unknowns) and what keeps it true: characterization tests in CI, a job list generated from the scheduler config, a named owner on their side.
6. What the map got wrong. One edge you drew wrongly and the probe or person that corrected it.

The sentence to say out loud is where two sources disagreed and which you trusted: “The maintainer said the export ran once a night; the scheduler showed a second run at noon that nobody remembered.”

The trap is “I read all the code”, which tells you what could run, not what does. The other is leaning on one person’s memory.