Palantir FDSE interviews: how to practise the re-engineering and learning rounds

You are handed a codebase of 200 to 1,000 lines that you have never seen. It produces wrong results, and you have 60 minutes in CodePair to fix it. The bug might be nothing more than a minus sign that has become a plus.

That is the re-engineering exercise in Palantir’s onsite for Forward Deployed Software Engineers. The onsite draws up to four rounds from five types: Decomposition, Re-engineering, Coding, Learning and System Design. This guide covers two of them: re-engineering and learning.

Both are worth practising properly because they sit close to the real job. Re-engineering means working with an existing system: understanding it, critiquing it, then extending or fixing it. It is a fairly faithful simulation of what an FDE does with a customer’s legacy systems.

The learning round gives you an unfamiliar tool or API and expects you to use it straight away. That, too, is a familiar situation when you have to work with whatever tools the customer already runs.

The process is scored, not the speed

The Aced/Exponent guide is explicit that interviewers focus on whether your debugging process is systematic, not on how quickly you spot the first bug. According to TechPrep, the round also measures how long it takes you to get to grips with a messy repository and start producing useful work.

Grinding through lots of problems is therefore not enough. You need to practise a process until it becomes a reflex. The steps below show how to build a small set of exercises on your laptop to do exactly that.

What you need: Python 3, an editor, a timer and a way to record yourself. A friend willing to play the interviewer is even better.

Step 1: Seed bugs into a piece of code

The bugs in Palantir’s problems are logic bugs: a flipped sign, a wrong assumption about sort order, or a variable that is not reset between loop iterations. The code below was written for practice and is not a real interview problem. It deliberately contains two of those three kinds of bug.

# ledger.py — a self-built exercise with planted bugs
def net_by_customer(txns):
    result = {}
    total = 0
    current = None
    for cust, kind, amount in sorted(txns):
        if cust != current:
            if current is not None:
                result[current] = total
            current = cust
        if kind == "refund":
            total += amount
        else:
            total += amount
    result[current] = total
    return result

txns = [("A", "sale", 100), ("A", "refund", 30), ("B", "sale", 50)]
print(net_by_customer(txns))

Run python3 ledger.py. The correct result is 70 for A and 50 for B. What it actually prints is {'A': 130, 'B': 180}. Check: if you see exactly those two numbers, the exercise is ready.

Step 2: Work back from the wrong output to the input

Strong candidates follow the data from the output back to the input; guess-and-try is what leads to rejection. Start with the most obviously wrong number.

B comes out at 180, yet customer B has exactly one transaction of 50. The extra 130 must come from somewhere else, and 130 is precisely A’s value. Working upwards, you find that total carries A’s entire balance over to B because it is never reset to 0 when the customer changes.

Next, A. It shows 130 instead of 70, a gap of 60, which is twice the refund of 30. A discrepancy of exactly double a value is a classic sign of a flipped sign: the code adds 30 where it should subtract it. You now have two hypotheses, both derived from the numbers rather than from a hunch.

Check: after fixing each bug, re-run and see which number has come right. Change only one thing at a time, so you know for certain which change produced which result.

Step 3: Read the whole block before you fix anything

Aced/Exponent advises reading the entire block from top to bottom before settling on a fix, because the most visible problem is not necessarily the real one. In ledger.py, many people see sorted(txns) and immediately suspect the sorting. In fact, sorting by customer is exactly what the loop needs in order to group correctly.

To practise the sort-order bug on its own, write an extra function that takes txns[0] as a customer’s first transaction, then feed it data that is not in chronological order. Then ask yourself: what does this code assume the input looks like, and who guarantees that assumption holds?

Step 4: Say each hypothesis out loud

As you work, speak in this pattern: “Where the output is wrong. Why I suspect it. How I will check.” Record the full 60 minutes. When you play it back, count how many times you changed code without first stating a hypothesis. Each one is a time you were guessing.

The learning round: read the docs more carefully than you think

The learning round gives you an unfamiliar concept or small API and asks you to build something with it. The most common reason for failing, according to Leonstaff, is skimming the documentation and then guessing how the API behaves.

How to practise: pick a module in your language’s standard library that you have never touched. Give yourself 20 minutes just to read the documentation, then write a small script with a clear purpose. Before every function call, say out loud what you expect it to return, then run it to check.

Predict first, run second: a go with groupby

Here is a sample session with Python’s itertools.groupby, assuming you have never used it. The self-set task: count each customer’s transactions.

from itertools import groupby
custs = ["A", "B", "A"]
print([(k, len(list(g))) for k, g in groupby(custs)])

A skim reader sees only the name “group by” and predicts, SQL-style: [('A', 2), ('B', 1)]. Run it and you get [('A', 1), ('B', 1), ('A', 1)]. The prediction was wrong, and that is exactly the moment your mental model needs correcting.

Go back to the documentation and you will find that groupby only groups consecutive elements with the same key, so the input must be sorted first. Change it to groupby(sorted(custs)) and you get [('A', 2), ('B', 1)]. This is also why sorted(txns) in ledger.py is not a bug.

Check after the session: you have written down at least one place where your prediction diverged from the documentation, and you can explain why. In the interview room, a single sentence such as “I assumed it grouped everything; it turns out it only groups adjacent elements” shows the interviewer how you learn.

Ask little, but ask at the right level

Explain how you currently understand the problem, so the interviewer can correct your mental model before you commit to an approach. But asking too many detailed questions can make you look as if you need hand-holding.

Compare two questions. “Does this function return a list or a dict?” is something you could look up yourself. “My understanding is that this API works in batches; if that’s wrong, I’ll change the design” shows the interviewer the level you are thinking at.

Long silences are easily read as being stuck, even when you are actually thinking. If you need quiet to read, say so first: “Give me two minutes to read the authentication section.”

Common mistakes

The first is fixing the first thing that looks wrong and re-running to see what happens. The second is changing several things at once, so that even when the result comes right you cannot explain why.

The third, in the learning round, is filling gaps in the documentation from memory of a similar-looking library, which is exactly the SQL trap with groupby.

Where this skill is used on a customer site

Imagine you have just arrived at a customer and they report that a summary table does not add up. The pipeline was written by someone else years ago, and there is nobody yet to ask. The approach is the same as with ledger.py: take one specific wrong record, measure the discrepancy, trace back through each transformation step, and state your hypothesis clearly to the customer before fixing anything.

On your CV, do not just write “debugged legacy systems”. Structure it instead: what the wrong output looked like, how you isolated it, and what you fixed. When reading job descriptions, phrases such as “existing systems” or “unfamiliar tools” signal that the role needs exactly the two skills this guide practises.

Palantir’s interviewers do not award points for how fast you catch the first bug, but for how you go looking for it. That systematic way of finding bugs is also what you need to bring with you when you face a customer’s systems.