By FDE Interview Prep, a SourceStrongAI company

In this post10 sections
  1. What Palantir publishes about working in existing code
  2. What candidates report about the round
  3. Questions to ask before you touch the code
  4. The routine: map, reproduce, test, fix, extend
  5. A worked example on a small buggy module
  6. Adding the feature without breaking what works
  7. How to practice on code you did not write
  8. Questions people ask
  9. Keep reading
  10. More from the blog

The interviewer pastes in a file you have never seen, says there is a bug in it, and the clock starts. You don’t know the code’s conventions, you don’t know why it was written this way, and you have to fix it out loud. That is Palantir’s re-engineering interview: candidates report reading existing code and fixing a bug, and one Blind poster preparing for the round expected to add a feature as well. Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 3Palantir Interview Process... So Far, FDSE 2024 (post by u/kircher32245)PublisherReddit r/csMajorsSource typecandidate report on Reddit Below: what Palantir actually publishes, the few first-hand reports, and a worked fix-and-extend example you can run. For every other round in the loop, read the FDE interview guide.

What Palantir publishes about working in existing code

Palantir says it structures its interview process around the engineering competencies it values most, and it publishes guides on them, among them one titled Working Inside Existing Systems. Source 4Palantir Careers | Getting HiredPublisherPalantirSource typecompany hiring page

That guide defines the competency as the ability to work within existing systems, codebases and infrastructure. It also says a developer spends far more time debugging, modifying and extending existing code than writing new code from the ground up. Source 5Working Inside Existing SystemsPublisherPalantirSource typecompany hiring page That is the most likely reason a round like this exists: the job is mostly other people’s code, so the interview puts you in some.

Palantir’s coding guide adds a point that matters here. Palantir says it will not ask about tricky or obscure features of a specific programming language, and it names the among those who need to understand what quality code looks like. Source 6Writing Good CodePublisherPalantirSource typecompany hiring page So the round is not a trivia test of one language. It tests whether you can find your way around unfamiliar code and change it safely.

The name “re-engineering” comes from candidates’ reports, not from that guide’s title. Our glossary entry on the re-engineering round collects the variants you will see.

What candidates report about the round

The reports are few, so here is each one, with who said it and when.

  • The round, in one line. One Blind poster preparing for a Palantir onsite, who did not name the role, wrote in May 2024 that the re-engineering interview “is about going through an existing code, debugging and adding a new feature.” Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on Blind
  • What was on the screen. In that poster’s earlier Blind thread, one commenter said they were given about 50 lines of copy-pasted Java and asked to fix a bug in the last 30 minutes, after 30 minutes on their past work, and said it “was not very difficult.” Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on Blind
  • The tool and the language. A different commenter in that Blind thread said the interface was HackerRank and that the bug “wasn’t java specific.” Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on Blind
  • What an FDSE candidate expected. One FDSE candidate reported on Reddit, in November 2024, that their upcoming onsite would include a “reengineering” round: seeing a codebase for the first time and debugging or explaining what is going on. Source 3Palantir Interview Process... So Far, FDSE 2024 (post by u/kircher32245)PublisherReddit r/csMajorsSource typecandidate report on Reddit
  • What went wrong for one candidate. One candidate for a mid-level Palantir role wrote on Aced, about an interview listed as May 2026, that they could have managed time better in the unfamiliar-codebase round. Source 7Palantir Forward Deployed Engineer Interview ExperiencePublisherAced (formerly Exponent)Source typecandidate’s personal write-up

Two cautions before you build a plan on those reports. The Blind poster and the Reddit candidate both described the round before taking it, so theirs are expectations, not accounts. The only first-hand description of the task itself is the Blind commenter’s: a bug fix at the end of the round, with no feature mentioned. Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on Blind And candidates report different loops: three Palantir FDSE candidates on Blind described different round mixes, and only the first, in February 2025, listed a “Reengineering” round. Source 8Palantir FDSE virtual onsitePublisherBlind (teamblind.com)Source typecandidate report on BlindSource 9Palantir Forward Deployed Software EngineerPublisherBlind (teamblind.com)Source typecandidate report on BlindSource 10Palantir hm callPublisherBlind (teamblind.com)Source typecandidate report on Blind One prep site, interviewing.io, says Palantir’s onsite draws 3 of 4 one-hour interview types, with re-engineering among them. Source 11Palantir’s Interview Process & QuestionsPublisherinterviewing.ioSource typeinterview prep site That is one site’s summary, not Palantir’s statement. The post on what Palantir FDSE candidates report lays out the full spread of loops.

The same round at other companies

The format is not only Palantir’s. One candidate reported on Reddit, in April 2026, a debugging interview for what they called a “more customer facing forward deployed eng” role at a company they did not name: about 40 minutes on a Python codebase of about 100 lines, where the bug was an off-by-one check, > 0 where >= 0 was meant. Source 12Had a debugging interview, fixed the bug but took a while. Am I cooked? (post by u/Boring_Distance_7320)PublisherReddit r/recruitinghellSource typecandidate report on Reddit One Scale AI Forward Deployed Engineer candidate on Aced, interviewing in August 2025, listed “debugging a giant repo” among five onsite parts. Source 13Scale AI Forward Deployed Engineer Interview Experience (2026)PublisherAced (formerly Exponent)Source typecandidate’s personal write-up Sierra says it is piloting, for its engineering candidates, a debugging interview in which candidates improve a colleague’s draft PR in a medium-sized codebase using coding agents. Source 14The AI-native interviewPublisherSierraSource typecompany blog If the assistant is allowed, the post on AI-assisted coding interviews covers how to use it so your judgment still shows.

Questions to ask before you touch the code

This is our advice, not Palantir’s. A minute of questions saves you from fixing the wrong thing.

Ask before you read a line

  • What did the user see, and what did they expect? One concrete example.
  • Can I run the code here? Is there a test file or a way to call it?
  • Is there an input that shows the bug, or do I need to find one?
  • Do other callers depend on these function names and signatures?
  • Do you want the smallest fix, or may I tidy as I go?
  • May I look things up, and are AI tools allowed?

The fourth question matters later, if you are asked to add a feature. If other code calls latest_status, you keep its name and its return shape, whatever you change inside.

The routine: map, reproduce, test, fix, extend

This is our method for working inside unfamiliar code under a clock. Each step has something to do and something to say, because the interviewer can only judge what you make visible.

  1. Map. Read for shape, not detail: the entry points, what data flows in and out, and anything that outlives one call (module-level state, caches, defaults). Then say the map in two sentences. Before you start, tell the interviewer when you will stop reading and name a suspect, then do it, even if the map is incomplete. A wrong suspect you test beats a perfect map with no time left. One Aced report, for an interview listed as May 2026, says the candidate could have managed time better in the unfamiliar-codebase round. Source 7Palantir Forward Deployed Engineer Interview ExperiencePublisherAced (formerly Exponent)Source typecandidate’s personal write-up Reading unfamiliar code is where time goes, and if your round looks like the Blind commenter’s, with the bug in the last 30 minutes, a map that eats most of it leaves no time to fix anything. Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on Blind
  2. Reproduce. Turn the complaint into the smallest input that shows the wrong output. If you can’t run the code, trace that one input by hand and write down each value.
  3. Test. Pin the bug with a failing test before you change anything. A test that fails for the right reason proves you found the cause, not a coincidence.
  4. Fix. Make the smallest change that turns the test green, in the style the file already uses. Run every test, not just yours.
  5. Extend. If a feature follows, ask what it must do at its edges, add it without breaking the interface other callers use, and test the edges.

Our free question on refactoring a long function so you can test it drills steps three and four on messier code than the example below.

If the round opens with your past work

One Blind commenter, in May 2024, reported spending the first 30 minutes on their past work before any code appeared. Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on Blind If your round opens the same way, don’t improvise that half. Prepare one project walkthrough of about two minutes:

  • The problem. Who had it and what it cost them, in one sentence.
  • Your part. Say “I”, and name the decisions that were yours.
  • One hard bug in code you did not write. How you found your way in, how you reproduced it, and what the fix was.

That third point does double duty: it is evidence, before the code even appears, that you can do the rest of the round. Our free question on taking an interviewer through one project in depth has a model answer and the follow-ups to expect.

A worked example on a small buggy module

Here is a module of our own, the kind of file a might hand you. A logistics customer’s dashboard uses it to show where each shipment is.

from collections import Counter

def latest_status(events):
    """Current status of each shipment,
    from its most recent event."""
    current = {}
    for e in sorted(events, key=lambda e: e["id"]):
        current[e["id"]] = e["status"]
    return current

def status_counts(events):
    return Counter(latest_status(events).values())

Each event is a dict such as {"id": "S-104", "ts": 1300, "status": "delivered"}, where ts is a Unix timestamp in seconds. The bug report: “Shipment S-104 shows in transit on the dashboard, but the driver’s app says delivered. It happens a few times a day.”

Map it out loud

Read once, then say something like:

“Two public functions. latest_status is the core: it walks the events and keeps the last status it sees for each shipment. status_counts only counts those. The docstring promises the most recent event, but the sort key is the shipment id, not the timestamp. Sorting by id groups a shipment’s events together; it doesn’t put them in time order.”

You now have a suspect, and you have said it before touching anything. Python’s sorted() is guaranteed to be stable, so within one shipment the events stay in the order the feed sent them. If the feed is in time order, the code works. If not, “last seen” is not “most recent”.

Reproduce it

Ask the question that tests the suspect: “Does the feed ever send events out of order?” In our example, the interviewer says carriers retry failed pings, so an old in-transit ping can arrive after the delivery.

That gives you the smallest failing input: a delivery, then a late ping with an earlier timestamp.

Pin it with a failing test

def ev(sid, ts, status):
    return {"id": sid, "ts": ts, "status": status}

def test_late_arriving_event():
    events = [ev("S-104", 1300, "delivered"),
              ev("S-104", 1200, "in_transit")]
    got = latest_status(events)
    assert got == {"S-104": "delivered"}

Run it and it fails with {'S-104': 'in_transit'}, the customer’s symptom exactly. The file’s one existing test feeds events in time order:

def test_in_order():
    events = [ev("S-1", 1, "in_transit"),
              ev("S-1", 2, "delivered")]
    got = latest_status(events)
    assert got == {"S-1": "delivered"}

It still passes, which explains why nobody caught this: the tests only fed it tidy data.

Make the smallest fix

- for e in sorted(events, key=lambda e: e["id"]):
+ for e in sorted(events, key=lambda e: e["ts"]):

One key changes. All tests pass. Then say the cause in one sentence, because that is what the interviewer will write down:

“The events were grouped by shipment but never ordered by time, so a late retry overwrote the delivery. Sorting by timestamp fixes it, and the new test fails without the fix.”

Two follow-ups show judgment. First, ties: if two events share a timestamp, the stable sort keeps feed order, so ask whether the feed carries a sequence number to break ties. Second, the blast radius: “Wrong statuses have been on the dashboard for a while. I’d check where else this code sorts by id, and ask who uses the counts.”

Adding the feature without breaking what works

Only one Blind poster reported this step, in May 2024, before taking the round, so treat it as preparation for a possible second step. Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on Blind Say the interviewer adds a feature: “Operations wants a list of shipments that look stuck: still in transit, with no event for longer than a limit they set.”

Ask about the edges before you write it:

  • “Longer than the limit, or at least the limit?” Say they answer longer than.
  • “If a shipment’s newest event is a delivery, it is never stuck, even if an older ping is stale. Right?”
  • “Should the list come back sorted, so the dashboard is stable?”

The feature needs each shipment’s latest event, not only its status. The tempting move is to change latest_status to return whole events. Don’t: the dashboard calls it and expects statuses. Pull the shared logic into a helper and keep the old function’s interface.

def _latest(events):
    latest = {}
    for e in sorted(events, key=lambda e: e["ts"]):
        latest[e["id"]] = e
    return latest

def latest_status(events):
    return {sid: e["status"]
            for sid, e in _latest(events).items()}

def stuck(events, now, max_age):
    return sorted(
        sid for sid, e in _latest(events).items()
        if e["status"] == "in_transit"
        and now - e["ts"] > max_age)

Then test the edges you asked about, one case each:

def test_stuck():
    events = [
        ev("S-1", 0, "in_transit"),    # stale
        ev("S-2", 900, "in_transit"),  # recent
        ev("S-3", 500, "delivered"),
        ev("S-3", 0, "in_transit"),    # late ping
        ev("S-4", 400, "in_transit"),  # at limit
    ]
    got = stuck(events, now=1000, max_age=600)
    assert got == ["S-1"]

S-4 is exactly at the limit and is not stuck, because the answer was “longer than”. S-3 was delivered, then a stale ping arrived late; it stays off the list only because stuck reuses the timestamp fix. Then run everything: the original test and the new ones all pass, and you say so.

“The old interface is unchanged, so the dashboard keeps working. The new function reuses the timestamp ordering, so it inherits the fix. I’ve tested the boundary you gave me.”

We ran this module and all its tests before publishing. It is shorter than the roughly 50 lines of Java one Blind commenter described, so practice the routine on longer files too. Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on Blind

Mistakes that cost the round

  • Rewriting before reproducing. Nobody can tell which change fixed it. Fix: failing test first, always.
  • Reading in silence. A long quiet map looks like being stuck. Fix: say the map in two sentences, then say your suspect.
  • Changing a signature other code depends on. Fix: add a helper and keep the old interface.
  • Running only your own test. Fix: run the whole suite after the fix and after the feature.
  • Fixing the symptom. Adding if status == "in_transit" special cases hides the cause. Fix: explain the cause in one sentence, or keep looking.

How to practice on code you did not write

The skill is a routine, so it improves with reps on code that isn’t yours.

If you are not sure which coding formats your target companies use, the free lesson What FDE coding rounds test, by the evidence sorts them by company. Palantir candidates also report a learning round; the post on Palantir’s learning interview covers how to pick up a new concept on the spot.

The re-engineering round rewards a habit more than a talent: map, reproduce, test, fix, extend, and say each step as you do it. Start with the free question on refactoring a long function so you can test it: set a timer, say your map in two sentences, and write the failing test before you change a line. Then work through the coding questions below the same way.

GlossaryForward deployed software engineerPalantir’s title for its FDE role, called Delta internally; OpenAI and EY also post FDSE titles, each with its own duties.More on Forward deployed software engineerGlossaryForward deployed engineerA software engineer who builds and ships production systems inside a customer’s problem and environment, accountable to that customer’s outcome.More on Forward deployed engineerGlossaryRe-engineering roundAn interview in which you learn, debug or extend code or a library you have never seen, against the clock and out loud.More on Re-engineering round

Questions people ask

What do candidates report about Palantir’s re-engineering interview?

One Blind poster wrote, in May 2024, that it is about going through existing code, debugging and adding a new feature, and one FDSE candidate reported on Reddit, in November 2024, an upcoming round of debugging and explaining an unfamiliar codebase. Palantir publishes a guide to working inside existing systems and names that ability among the competencies its process is built around.Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 3Palantir Interview Process... So Far, FDSE 2024 (post by u/kircher32245)PublisherReddit r/csMajorsSource typecandidate report on RedditSource 4Palantir Careers | Getting HiredPublisherPalantirSource typecompany hiring pageSource 5Working Inside Existing SystemsPublisherPalantirSource typecompany hiring page

Which language do Blind posters report for the re-engineering code?

One Blind commenter, in May 2024, described being given about fifty lines of Java, and another commenter in the same thread said the bug was not specific to Java. Palantir’s coding guide says it will not ask about tricky or obscure features of a specific language.Source 1Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 2Palantir re-engineering interview (Blind)PublisherBlindSource typecandidate report on BlindSource 6Writing Good CodePublisherPalantirSource typecompany hiring page

How do I prepare for a re-engineering round?

Practice on code you did not write. Take a small open-source project, pick a closed bug report, reproduce it with a failing test before you read the fix, and time how long you spend mapping the code before changing anything.

Do candidates report a re-engineering round in every Palantir loop?

No source says so. Palantir’s published guides describe competencies rather than a fixed list of rounds, and Palantir FDSE candidates on Blind have described different mixes of coding, decomposition, learning and re-engineering rounds, so prepare for each type.Source 4Palantir Careers | Getting HiredPublisherPalantirSource typecompany hiring pageSource 8Palantir FDSE virtual onsitePublisherBlind (teamblind.com)Source typecandidate report on BlindSource 9Palantir Forward Deployed Software EngineerPublisherBlind (teamblind.com)Source typecandidate report on BlindSource 10Palantir hm callPublisherBlind (teamblind.com)Source typecandidate report on Blind

Keep reading

Guides

Company guides

Lessons

Questions

More in Interview rounds, page 3