Palantir Interview Questions (2026): What They Actually Ask

The pattern Palantir tests: you call page 1, check the response for a total_pages or next_cursor field, loop through remaining pages, collect and filter records, then write output. The common mistake is not handling the case where the API returns an empty list on the last page vs. a 404 vs. a next_cursor of null. Handle all three.

Reported from multiple Palantir OA and FDSE screen write-ups. The filtering criteria vary (date range, status field, record type) but the pagination pattern is consistent. FDSEs do exactly this in real deployments when integrating with a customer's existing data API.

import requests

def fetch_all_records(base_url: str, params: dict) -> list[dict]:
    records = []
    page = 1
    while True:
        resp = requests.get(base_url, params={**params, "page": page})
        resp.raise_for_status()
        data = resp.json()
        batch = data.get("results", [])
        records.extend(batch)
        if not data.get("next"):  # None or empty string means no next page
            break
        page += 1
    return records

Define the required schema as a simple spec: field name, expected type, and whether it's required. Load the JSON, walk the spec, and for each required field check presence first, then type. Collect every violation rather than stopping at the first one, since a customer fixing a config file wants the full list of problems in one pass, not one error at a time.

This is a direct proxy for the FDSE job: customers hand over configuration files with typos, wrong types, and missing fields on a regular basis, and a deployed engineer needs to give useful feedback fast rather than a stack trace. Reported from an FDSE-track phone screen in 2025. The interviewer's follow-up asked for nested field validation, a "contact" object with its own required sub-fields, which means the validator needs to recurse rather than only check the top level.

def validate_config(config: dict, schema: dict, path: str = "") -> list[str]:
    errors = []
    for field, spec in schema.items():
        full_path = f"{path}.{field}" if path else field
        if field not in config:
            if spec.get("required", True):
                errors.append(f"missing required field: {full_path}")
            continue
        value = config[field]
        expected_type = spec["type"]
        if expected_type == "object":
            if not isinstance(value, dict):
                errors.append(f"{full_path} should be an object")
            else:
                errors.extend(validate_config(value, spec["fields"], full_path))
        elif not isinstance(value, expected_type):
            errors.append(f"{full_path} should be {expected_type.__name__}")
    return errors

Pick a decision where you were genuinely wrong, or genuinely right but couldn't get traction. Both are interesting. The pattern Palantir rewards: you brought a clear argument with evidence, you listened to the counterargument, and you either updated your position or escalated appropriately (not passive-aggressively). What they don't want: either total deference ("I just went with what the team decided") or stubbornness ("I implemented my own approach anyway").

This maps directly to the Learning round and to the day-to-day of an FDSE embedded at a new customer site. Interviewers want a real account of how you oriented yourself, what you read first, who you asked, and how long it took before you shipped something real. Vague answers, "I just figured it out", don't land as well as a specific sequence: what you did in the first hour, the first day, the first week.

Strong answers also name what you got wrong initially. Assuming you fully understood a system after a quick skim and then breaking something is a better story, honestly told, than claiming a clean ramp-up.

Most candidates report 4 to 8 weeks from first contact to verbal offer. The OA and phone screen move quickly once the recruiter call is done, usually within a week each. The gap is typically between the onsite and the hiring manager final, which can take 1 to 2 weeks. Palantir does not move at Google or Amazon speed; they interview fewer candidates more deliberately.

Yes, at minimum for the recruiter screen. You don't need product expertise, but you should know what Foundry is (Palantir's commercial operating system, used by companies like Airbus and Ferrari for data operations), what Gotham is (the government and defense platform, used by intelligence agencies and military), and what AIP is (the AI layer announced in 2023 that sits on top of both). Candidates who can't distinguish these during the "why Palantir?" question don't advance. It takes 30 minutes of reading to get there.

System design asks you to architect a technical system, scaling, storage, services, APIs. Decomposition asks you to figure out what the system should be before designing it. You're given an ambiguous problem, no clear scope, no defined users, no stated constraints, and your job is to ask questions that reveal those things. No code is expected. The round rewards structured thinking about stakeholders, data, decisions, and MVP scope. Most candidates who fail it do so by jumping to technical architecture before they've defined the problem.

Different in kind, not just in difficulty. Google and Meta run standardized loops where you can prep a specific set of patterns and expect consistent questions. Palantir's loop varies by role (SWE vs. FDSE), by what rounds you're assigned, and by how aggressively your behavioral fit is probed. Candidates who are strong at LeetCode sometimes fail at Palantir because the Decomposition round has no equivalent in standard prep. The coding rounds are LC Medium on average, which is not harder than Google or Meta. The behavioral bar is stricter.

FDSEs embed directly at customer sites (hospitals, defense agencies, financial institutions) and build software for those customers with minimal handholding. The role is part engineer, part consultant. The interview for FDSE skews heavier toward Decomposition and Learning rounds, which test how quickly you can orient in an unfamiliar environment and structure a solution for a non-technical stakeholder. DSA questions are lighter. Behavioral questions about working with ambiguous requirements and non-technical clients are heavier. You're also asked directly: "why FDSE specifically and not SWE?"

Palantir has a reputation for a high intern-to-return-offer conversion rate for candidates who perform well during the internship, though the company has also had hiring freezes that affected internship conversion in 2023 and 2024. The intern interview includes the OA and a shorter onsite (typically 2 to 3 rounds rather than 4 to 5). Decomposition is usually included even for interns. The behavioral bar for interns is lower on "why Palantir" but the company still filters for genuine interest over generic tech-job motivation.

Not as a separate labeled round, but the Decomposition round functions like one. Instead of "how would you improve Instagram Stories," you get an operational problem, hospital bed allocation, disaster response coordination, and are evaluated on how you scope it, not on writing code. Data modeling shows up too, both in Decomposition and occasionally as its own System Design question centered on Palantir's ontology concept, the object layer that links related entities across otherwise disconnected datasets. If you're prepping only DSA and system design in the traditional sense, you're missing this entire axis of the loop.

A hash table stores key-value pairs by running each key through a hash function that produces an integer, then using that integer (modulo the table size) as an index into an underlying array. Insert, lookup, and delete all reduce to computing the hash once and jumping straight to the right bucket, so average case time doesn't depend on how many other entries are in the table.

That average case falls apart if the hash function clusters many keys into the same bucket. With a bad hash function, or an adversary who crafts keys to collide on purpose, a bucket can end up holding most of the entries, and lookups in that bucket degrade to a linear scan, O(n) in the worst case. Real implementations guard against this by resizing and rehashing once the load factor (entries divided by bucket count) crosses a threshold, usually around 0.75, and by chaining collisions into small linked lists or trees (Java's HashMap switches a bucket from a linked list to a red-black tree once it holds more than eight entries, specifically to cap the worst case).

A stack is last-in-first-out: whatever you pushed most recently is the first thing that comes back out with pop. A queue is first-in-first-out: the oldest item still enqueued is the first one dequeued. Both support O(1) insert and remove when implemented with an array or linked list, the difference is purely which end you're allowed to touch.

Stacks show up anywhere you need to unwind something in reverse order of how it happened: undo/redo in an editor, matching parentheses or tags, and the call stack a program uses to track function returns. Depth-first search on a graph or tree is naturally a stack, whether it's the recursion stack or one you manage explicitly. Queues fit anywhere order of arrival matters: task schedulers, message buffers between producers and consumers, and breadth-first search, where you want to fully explore one level before moving to the next.

The ontology is the layer that turns a customer's raw, disconnected data, rows in a warehouse table, files in a data lake, readings from a sensor feed, into real-world objects with names, properties, and relationships. Instead of every dashboard or pipeline defining its own private notion of what an "Aircraft" or a "Shipment" is, the ontology defines it once: an Aircraft object type with properties like tail number and maintenance status, linked to Flight objects and Part objects, plus actions that are allowed on it, like scheduling a maintenance check.

That's why it's described as foundational rather than just another feature: every application built in Foundry, whether it's a Workshop dashboard, a pipeline transform, or an AIP agent, reads from and writes back to the same ontology. Update an object's status in one application and it's immediately visible everywhere else that references it, because there's one shared model instead of many copies of the data drifting out of sync across many different tools.

An inner join only returns rows where the join condition matches in both tables, anything without a match on either side gets dropped from the result entirely. A left join returns every row from the left table no matter what, and if there's no matching row on the right, it fills those columns in with NULL instead of dropping the row.

The common gotcha is filtering on the right table's columns in the WHERE clause after a left join. If you write a WHERE condition on orders.status after a LEFT JOIN, any customer with no orders has NULL for that column, and NULL never equals a literal value, so that customer silently disappears from the results, turning your left join back into an effective inner join. The fix is to move that condition into the ON clause instead, so it's applied while the join is happening rather than filtering the joined result afterward.

-- wrong: silently drops customers with no orders
SELECT c.name, o.status
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'shipped';

-- right: keeps every customer, matches shipped orders where they exist
SELECT c.name, o.status
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id AND o.status = 'shipped';

Sliding window with a hash map tracking character frequencies. Expand the right pointer. When the map has more than K distinct keys, shrink from the left until it's back to K. Track the maximum window size seen.

Reported from multiple Palantir phone screen and OA write-ups between 2024 and 2025. The follow-up almost always asks what changes if duplicate characters within the window matter, or if the input is a stream rather than a static string. Prepare both variants.

def longest_k_distinct(s: str, k: int) -> int:
    freq = {}
    left = 0
    best = 0

    for right, ch in enumerate(s):
        freq[ch] = freq.get(ch, 0) + 1
        while len(freq) > k:
            left_ch = s[left]
            freq[left_ch] -= 1
            if freq[left_ch] == 0:
                del freq[left_ch]
            left += 1
        best = max(best, right - left + 1)

    return best

Sort by start time. Walk through the list. If the current interval's start is within the last merged interval's end, extend the end. If not, push a new interval. Return the merged list.

Palantir frames this as scheduling: "given a list of hospital staff shifts, return the continuous coverage windows." The algorithm is the same, but the framing requires a quick mental translation. Reported from a 2024 online assessment.

Sort meetings by start time. Use a min-heap keyed on end time. For each meeting, if the earliest-ending room in the heap frees up before the new meeting starts, pop it and reuse that room; otherwise push a new room onto the heap. The heap's size at any point is the number of rooms in use, and its maximum size across the whole pass is the answer.

Palantir's real-world framing on this one is usually a booking system for shared lab equipment across research teams rather than office meetings, which is the same overlap-counting problem wearing different clothes. Reported from a 2025 OA and a phone screen write-up. The follow-up asks you to also return which room number each meeting was assigned, which forces you to track room identity in the heap rather than just a count.

import heapq

def min_meeting_rooms(intervals: list[list[int]]) -> int:
    if not intervals:
        return 0
    intervals.sort(key=lambda x: x[0])
    rooms = []  # min-heap of end times

    for start, end in intervals:
        if rooms and rooms[0] <= start:
            heapq.heappop(rooms)
        heapq.heappush(rooms, end)

    return len(rooms)

Parse each entry into its domain hierarchy. For "discuss.leetcode.com", you increment counts for "discuss.leetcode.com", "leetcode.com", and "com" separately. Use a hash map of domain strings to visit counts. Then format the output.

Reported from Palantir OAs across multiple candidate accounts. The wrinkle is parsing correctly: split on "." and build each suffix from left to right. The solution looks simple but candidates who try to hardcode the dot-splitting logic get tripped up on edge cases like single-label domains.

from collections import defaultdict

def subdomain_visits(cpdomains: list[str]) -> list[str]:
    counts = defaultdict(int)
    for entry in cpdomains:
        count, domain = entry.split()
        count = int(count)
        parts = domain.split(".")
        for i in range(len(parts)):
            counts[".".join(parts[i:])] += count
    return [f"{v} {k}" for k, v in counts.items()]

Build a reverse adjacency list (child maps to parents). Run DFS or BFS backward from each target node to collect all reachable ancestors. Sort and return. The key insight is that the forward graph gives you descendants; reversing the edges gives you ancestors.

Reported directly from Palantir phone screen write-ups in 2024 and 2025. A common follow-up: "what if the graph has cycles?" The answer changes the algorithm to cycle-detection-aware traversal using a visited set with a recursion stack. Palantir likes this kind of constraint mutation mid-problem.

from collections import defaultdict

def get_ancestors(n: int, edges: list[list[int]]) -> list[list[int]]:
    parents = defaultdict(list)
    for u, v in edges:
        parents[v].append(u)

    result = []
    for node in range(n):
        ancestors = set()
        stack = [node]
        while stack:
            curr = stack.pop()
            for p in parents[curr]:
                if p not in ancestors:
                    ancestors.add(p)
                    stack.append(p)
        result.append(sorted(ancestors))
    return result

Use two sets or a single hash map tracking loss counts. Walk through every match result. Track how many times each player appears as the loser. Players with zero losses form one output list, players with exactly one loss form the other. Sort both lists before returning.

Reported from a Palantir 2025 OA. It's a simple problem on the surface, but candidates who reach for nested loops instead of a single-pass hash map get flagged in follow-up complexity questions. Interviewers specifically asked about time complexity in this OA report.

Build an adjacency list and in-degree counts. Push all nodes with in-degree 0 into a queue. Process the queue: dequeue a node, add to the output order, decrement in-degree of all its neighbors. If any neighbor's in-degree hits 0, enqueue it. If the output length at the end doesn't equal n, a cycle exists and no valid ordering is possible.

Topological sort shows up in multiple Palantir coding reports across 2024 to 2025. The company's real-world framing is usually "given task dependencies, find a valid execution order" rather than "given courses and prerequisites." The algorithm is identical. Know the BFS (Kahn's) version well, it's easier to talk through than recursive DFS under interview pressure.

from collections import deque, defaultdict

def find_order(num_courses: int, prerequisites: list[list[int]]) -> list[int]:
    graph = defaultdict(list)
    in_degree = [0] * num_courses

    for course, prereq in prerequisites:
        graph[prereq].append(course)
        in_degree[course] += 1

    queue = deque([i for i in range(num_courses) if in_degree[i] == 0])
    order = []

    while queue:
        node = queue.popleft()
        order.append(node)
        for neighbor in graph[node]:
            in_degree[neighbor] -= 1
            if in_degree[neighbor] == 0:
                queue.append(neighbor)

    return order if len(order) == num_courses else []

BFS from the starting position. Track visited cells and the shortest path to each target. If multiple targets exist, run multi-source BFS or run BFS once and collect distances to all targets in a single pass. Return the order in which targets are reached, or the shortest path if only one target exists.

Reported from a Palantir technical phone screen. The Palantir framing was about a robot navigating a warehouse floor to pick multiple items. The core is standard BFS, but the multi-target extension catches candidates who hardcode a single goal cell.

Doubly linked list combined with a hash map. The map provides O(1) key lookup; the linked list maintains insertion order. On get, move the node to the head. On put, if the key exists, update and move to head. If the cache is full, evict the tail and remove its key from the map.

Shows up in Palantir coding rounds and OAs. The follow-up reported in 2025: "how would you modify this if multiple threads are reading and writing concurrently?" The expected answer: a read-write lock, or Python's threading.RLock around the get and put methods. Simple dict + list approaches that give O(n) operations get called out immediately.

Standard flood fill. Walk every cell in the grid. When you hit an unvisited land cell, run DFS or BFS outward in four directions, marking every connected land cell as visited, and count that as one landmass. The total count across the grid is the answer. Runs in O(rows x cols) since every cell is visited once.

This is the geospatial-imagery version of the standard "number of islands" problem, and it comes up because Gotham's client base does real geospatial analysis on tile data. Reported from a 2025 onsite Coding round. The follow-up: what if a landmass can wrap across the grid's edges, like a globe? That changes the neighbor-check logic to wrap indices modulo the grid width and height instead of bounds-checking against zero.

def count_landmasses(grid: list[list[int]]) -> int:
    rows, cols = len(grid), len(grid[0])
    visited = [[False] * cols for _ in range(rows)]
    count = 0

    def flood_fill(r, c):
        stack = [(r, c)]
        while stack:
            cr, cc = stack.pop()
            if cr < 0 or cr >= rows or cc < 0 or cc >= cols:
                continue
            if visited[cr][cc] or grid[cr][cc] == 0:
                continue
            visited[cr][cc] = True
            stack.extend([(cr + 1, cc), (cr - 1, cc), (cr, cc + 1), (cr, cc - 1)])

    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == 1 and not visited[r][c]:
                flood_fill(r, c)
                count += 1

    return count

Two cases. If the node has a right subtree, the successor is the leftmost node of that subtree. If it doesn't, walk down from the root tracking the most recent ancestor where you branched left, since that ancestor is the smallest value greater than the target. No parent pointers are needed if you do a single root-to-node traversal and keep updating a candidate as you go.

Reported as a Coding-round question where the interviewer frames the tree as a sorted index over timestamped records: find the next record chronologically after a given one. Candidates who reach for a full inorder traversal and then scan for the target get a correct but O(n) answer; interviewers push for the O(h) walk described above once you've produced the brute-force version.

Tokenize the text into a word list. Track the most recent index of each of the two query words as you scan left to right. Every time you see either query word, check the distance to the last seen index of the other word; if it's within k, record the pair of positions. A single left-to-right pass is enough, there's no need to compare every pair of occurrences.

Palantir frames this as a document search proximity query, useful in Foundry-style text analytics over case files or reports. Reported from a phone screen in 2025. The follow-up extends it to three or more query words, which breaks the "track the last index of each word" approach and requires tracking a sliding window of the most recent occurrence of every query word instead.

def proximity_pairs(words: list[str], word_a: str, word_b: str, k: int) -> list[tuple[int, int]]:
    last_a, last_b = -1, -1
    pairs = []

    for i, w in enumerate(words):
        if w == word_a:
            last_a = i
            if last_b != -1 and i - last_b <= k:
                pairs.append((last_b, i))
        elif w == word_b:
            last_b = i
            if last_a != -1 and i - last_a <= k:
                pairs.append((last_a, i))

    return pairs

Systematic approach: read the top-level entry point first, not line 1. Identify what the system claims to compute and trace backward from the output to find where the computation diverges from the spec. Add print statements or assertions at intermediate steps. Palantir interviewers watch whether you have a search process or whether you're reading code linearly hoping to spot something.

Reported bugs in this type of round involve things like: a running total that doesn't reset between accounts, a sort that orders by string representation of numbers instead of numeric value (so "10" sorts before "9"), or a condition that inverts the sign of a transaction type. The re-engineering round is testing code-reading speed and systematic debugging, not algorithmic creativity.

Read the interface spec before reading the implementation. Know what each function is supposed to take and return before looking at how it works. Implement your feature against the interface, not against the implementation details. If the implementation detail leaks through the interface (and it often does in these rounds), name it explicitly: "I'm relying on the fact that this returns an ordered list, is that guaranteed by the spec?"

The Learning round is more common in the FDSE loop than in the SWE loop. Palantir's FDSEs spend their first weeks at a new customer deployment doing exactly this: reading code they didn't write and extending it quickly. Candidates who treat "I don't know this codebase" as a problem rather than a starting condition tend to struggle.

Parse each subscription record into a structured object. Check whether today falls within [start_date, end_date]. For subscriptions still active, check the send_schedule field against today. Send schedules might be "daily", "weekly on Monday", or "monthly on the 1st", each needs its own check. Return users who match. The edge cases Palantir cares about: timezone handling, subscriptions where end_date is null (no expiry), and send_schedule formats that are user-entered strings (requiring normalization).

Reported from a 2025 Palantir OA as the "real-world scenario" coding problem. The candidate noted the tricky part wasn't the logic but parsing the schedule format correctly and handling null end dates without crashing.

Group transactions by account_id and sum the amounts. A transaction might have a positive or negative amount depending on the type. Filter the grouped results where the sum is not zero. If the transaction table has a "type" column (debit vs. credit) rather than a signed amount, you need a CASE statement in the SUM to apply the correct sign.

Reported from the SQL component of the Palantir OA. The candidate noted the table had a "type" column with values "credit" and "debit" rather than signed amounts, which was the only real wrinkle.

# SQL query (shown as a Python string for context)
QUERY = """
SELECT
    account_id,
    SUM(
        CASE
            WHEN type = 'credit' THEN amount
            WHEN type = 'debit'  THEN -amount
            ELSE 0
        END
    ) AS balance
FROM transactions
GROUP BY account_id
HAVING balance <> 0
ORDER BY account_id;
"""

The question has a specific trap. "Palantir is working on hard problems" is the generic answer and it doesn't work. What works: specifics about the platform (Foundry, Gotham, or AIP), specific customer types (healthcare systems, defense agencies, commercial manufacturers), and a genuine explanation of why software that helps those institutions make better decisions matters to you. Saying "I want my work to have real-world impact" is only the start of a good answer, not the whole thing.

Palantir interviewers distinguish between candidates who know what the company does and candidates who have thought about whether they want to work on it. The distinction shows in the specificity of your answer. If you haven't looked at Palantir's AIP announcements from 2024 to 2025 and the Foundry use cases before this screen, you're not ready for the question.

Palantir asks this because its software is used by immigration agencies, intelligence services, and law enforcement, and it has been publicly controversial for that reason. The company doesn't want candidates who are uncomfortable with the territory and pretending otherwise. It also doesn't want candidates who are unreflective about it.

A strong answer names a real situation, describes the competing interests clearly, explains what information you gathered to make the decision, and says what you'd do differently if you had to do it again. "I didn't face any ethical dilemmas" is a worse answer than "I made a call I'm still uncertain about, and here's why."

Palantir uses the phrase "missionaries, not mercenaries" internally. The behavioral question that surfaces this: when did you go beyond the assigned work because you cared about the outcome? The answer should show initiative on scope (you noticed something that wasn't in the spec), initiative on quality (you raised a concern that slowed you down but prevented a future problem), or initiative on communication (you flagged a risk before it became someone else's problem).

Avoid stories where your ownership consisted of "finishing my tickets on time." Own the outcome: what did you ship, who used it, what happened after you shipped it?

Every Palantir loop includes this. The bar is higher than most companies because the interviewer expects you to name something real, explain why it happened at a structural level (not just "I worked too hard"), and say what changed as a result. Stories about a project that slipped one sprint don't count as failures here. Stories about a product launch that didn't land, a technical decision that had to be reversed, or a team conflict that affected delivery are appropriate.

End the answer with a concrete change: "After that I started X practice, and it has prevented Y kind of problem since." Without that, the story is just a confession. With it, it's a demonstration of growth.

This is the FDSE behavioral question in its clearest form, and it also shows up for SWE candidates. Palantir engineers work with defense agencies and hospital systems where the person defining the need is often not a product manager but a field operator or a department head with a problem, not a spec. Strong answers describe a specific questioning technique you use (structured discovery, ask "what decision are you trying to make with this data?"), a situation where the initial ask was wrong and your questions revealed the real need, and an outcome.

Weak answers describe the stakeholder's vagueness as a problem you had to endure rather than a constraint you designed around.

Palantir asks this because it mirrors what happens constantly in Decomposition-style work: a customer's real need shifts once they see a first version. Interviewers want to hear that you treat a changed requirement as new information rather than as scope creep to resist. Name a specific instance: what changed, what you'd already built, what you kept versus threw away, and how you communicated the impact to whoever depended on the original plan.

Answers that describe rigidly defending an original spec against a legitimate change in the customer's understanding of their own problem tend to work against you here. The company wants people who treat changing requirements as normal, not as someone else's failure to plan.

Break the number into groups of three digits: ones, thousands, millions, billions. Write a helper that converts any three-digit group into words, handling the hundreds place, the teens as a special case, and tens plus ones separately. Then join the groups with their scale words, skipping any group that's zero.

Palantir reportedly frames this as converting a ledger amount into words for a compliance document rather than the bare "integer to English words" prompt, which is the same problem with a finance wrapper. There's no clever trick here; the difficulty is entirely in handling edge cases cleanly, zero, negative numbers if they're in scope, and groups like "one hundred" where the ones-helper needs to avoid a trailing "and" or an extra space. Candidates who don't write the three-digit helper as its own function tend to end up with tangled if-else chains that break on inputs like 1,000,000.

Start with the query plan, not the data. Run explain() or look at the Spark UI's SQL tab, and compare the physical plan before and after the schema change. The thing to look for is whether the join strategy flipped, for example from a broadcast hash join to a sort-merge or shuffle hash join. Adding a column, even a nullable one, changes the table's estimated size, and if that pushes one side over the broadcast threshold, the optimizer stops broadcasting the small table and instead shuffles both sides across the cluster, a completely different cost profile.

Next check the stage metrics for skew and spill. A nullable key means some fraction of rows now have NULL in that column, and if the join condition treats those NULLs as a single group, they all land in one partition during the shuffle, creating one task that takes far longer than the rest while every other task finishes early and sits idle. The task duration histogram in the Spark UI makes this obvious, one or two tasks running dozens of times longer than the median is the signature of skew, not a broadcast/shuffle regression.

Once you know which one it is, the fixes differ. If it's a plan regression from stale statistics, run ANALYZE TABLE with COMPUTE STATISTICS after the schema change so the optimizer has accurate row counts to work from, or force the broadcast with a hint if you know the small side is still genuinely small. If it's skew from NULL keys, filter or bucket the NULLs separately before the join, since they usually don't represent a meaningful match anyway, or salt the join key to spread that group across multiple partitions.

Say the counter starts at 5. Thread A reads 5. Before A writes anything back, thread B also reads 5, because reading doesn't lock anything. A computes 6 and writes 6. B, still working off its stale read of 5, computes 6 and writes 6 as well. Two increments happened, but the counter only moved from 5 to 6, one of the updates is gone. Nothing exotic has to happen for this, a single context switch landing between the read and the write on either thread is enough, which is why this bug is flaky under load and almost never shows up in a single-threaded test.

The straightforward fix is a mutex around the entire read-modify-write sequence, so only one thread can be inside that critical section at a time. It's easy to reason about and obviously correct, but it serializes every increment, so throughput drops as contention rises, and if a low-priority thread holds the lock while a high-priority thread is blocked waiting on it, you can get priority inversion.

The other fix is a lock-free compare-and-swap loop, using whatever atomic primitive the language or runtime provides.

int oldValue, newValue;
do {
    oldValue = counter.get();
    newValue = oldValue + 1;
} while (!counter.compareAndSet(oldValue, newValue));

This scales much better under contention because there's no blocking, a thread just retries if another thread beat it to the update. The tradeoff is that it's harder to extend correctly beyond a single counter, compound operations across multiple variables need something heavier, like a versioned struct or an actual lock, and under very high contention the retry loop can spin and burn CPU without making progress, which is effectively livelock.

Two-phase commit gives you real atomicity: a coordinator asks both databases to prepare the transaction, waits for both to say yes, then tells both to commit. It works, but it requires both databases to speak the same distributed transaction protocol, it holds locks on both sides for the full round trip so throughput suffers under load, and if the coordinator crashes between the prepare and commit phases, both participants can be left holding locks on an in-doubt transaction indefinitely. Most modern databases, message brokers, and managed cloud services don't support that protocol at all, which rules 2PC out the moment you cross vendor or service boundaries.

The outbox pattern gives up strict atomicity in exchange for something that actually works in practice. The billing service writes the debit and a corresponding event row to an outbox table, in the same local transaction, so that part is atomic within one database. A separate process, either a poller or change-data-capture on the outbox table, reads new rows and publishes them to a queue, which fulfillment consumes to record the shipment. If the publisher dies after the local commit but before publishing, it just retries the unpublished rows on restart, giving at-least-once delivery, which means fulfillment has to be built to handle duplicate messages idempotently, an event ID it's already seen gets acknowledged and dropped, not reapplied.

I'd pick the outbox pattern for almost any real system spanning services you don't fully control. It doesn't need a shared transaction coordinator, it degrades gracefully if one side is temporarily down instead of holding locks and stalling everything else, and the cost of writing idempotent consumers is much lower than the operational cost of keeping a fragile 2PC coordinator alive across services with different failure modes.

Maintain a sorted list, or balanced tree, of booked intervals. On a new booking request, binary search for the insertion point and check the immediate neighbors on both sides for overlap. If neither neighbor overlaps, insert the interval and return success; otherwise reject the booking. A naive linear scan through all existing bookings works too, and it's often the version interviewers want first, before asking you to speed it up.

Palantir's version of this problem is usually framed as booking operating-room time slots or shared lab instruments rather than a generic calendar, consistent with the hospital and research-lab systems the company's customers actually run. The follow-up in one 2025 report: add a cancellation method, which requires the interval structure to support deletion in addition to insertion and overlap checks.

Ask what's being tracked, inventory units, shipments, or both? Who sees alerts, procurement managers or warehouse staff? What decisions do alerts enable, reorder now, reroute a shipment, or escalate to a supplier? These questions transform "supply chain tracker" into a specific system with tractable scope.

Reported from a Palantir decomposition round in 2025. The interviewer added a constraint at the midpoint: "now assume suppliers update their inventory data in batch files sent every 24 hours, not via API." A strong answer acknowledges the polling implication, defines a reconciliation job, and explains what staleness means for alert accuracy.

Start by asking who uses this: a floor technician logging a repair, a plant manager deciding which machine to replace, or both. Ask what "failure" means here, a full stoppage, a quality defect in output, or either. The data model follows from those answers: an equipment entity (machine id, location, install date), a maintenance event entity (technician, date, parts replaced, downtime), and a failure entity linked back to the equipment and, ideally, to the maintenance history that preceded it.

A reasonable first version logs maintenance events and links them to equipment, nothing more, since that alone lets a plant manager see which machines fail most often without building any predictive layer yet. Palantir's commercial Foundry customers include manufacturers running exactly this kind of tracking, and interviewers reportedly probe whether you separate what happened, the event log, from what should happen next, maintenance scheduling, since conflating the two tends to produce a design that can't answer either question well.

Token bucket per customer is the standard answer: each customer gets a bucket that refills at their tier's allowed rate, and a request is allowed only if a token is available. Store bucket state in a fast shared store, Redis or similar, keyed by customer id, since a single gateway instance can't hold state safely once you have more than one instance behind a load balancer.

The follow-up reported in a 2025 onsite: what happens when the rate-limiting store itself is briefly unavailable? Failing open, allowing all requests, protects availability but exposes the system to abuse during the outage window. Failing closed protects quota guarantees but takes down every customer's traffic if the store has a bad minute. Palantir interviewers want you to name this as a policy decision that depends on which customer tier is affected, not a purely technical call.

import time

class TokenBucket:
    def __init__(self, capacity: int, refill_rate_per_sec: float):
        self.capacity = capacity
        self.tokens = capacity
        self.refill_rate = refill_rate_per_sec
        self.last_refill = time.monotonic()

    def allow(self) -> bool:
        now = time.monotonic()
        elapsed = now - self.last_refill
        self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
        self.last_refill = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

Start with stakeholders: field responders, coordination center staff, government officials monitoring status. Each group needs different views of the same data. Ask what decisions each user makes and what information they need to make them. Then define the data: incidents, responders, resources, location, status. Identify the most critical workflow: a responder in the field needs to log an incident and request resources, and a coordinator needs to see all active incidents and available resources on a single dashboard.

Don't design the whole system. State explicitly what you're deferring and why. "I'd build the incident logging and resource request flow first, because without that we don't have any data to coordinate around." Interviewers will introduce a constraint change at the 30-minute mark, something like "now assume cellular connectivity is unreliable." That's intentional. Treating it as an attack on your prior work rather than a new design input is the failure mode.

Clarify first: is this for a single hospital or a regional hospital network? Is the primary user a charge nurse, a hospital administrator, or both? What does "prioritization" mean, triage severity, wait time, or a combination? The right data model depends entirely on these answers.

One reasonable minimal version: a patient intake form that captures severity score and arrival time, a bed inventory that tracks availability by ward, and a matching workflow that surfaces the highest-priority unassigned patient to an available bed. Permissions matter here, not everyone should see every patient record. Palantir interviewers specifically probe whether you named access control as a constraint before they prompted you.

Distinguish between the detection system (which flags suspicious transactions) and the review workflow (what analysts do with those flags). A Decomposition round is almost always about the review workflow, not the ML model upstream. The analyst needs to see the transaction, its context (account history, similar patterns), the flag reason, and a way to record their decision. That decision then needs to feed back to improve the flagging model.

Data model: transaction entity, flag entity (with flag reason and source), analyst decision entity (approve, reject, escalate), account entity. The relationship between these is the design. State that you'd build the analyst review UI and decision capture first, before building the feedback loop to the flagging system, because one is observable and testable in isolation and the other isn't.

The key tension at Palantir's scale: data sources often have inconsistent schemas, update frequencies, and reliability. The integration layer needs to handle schema reconciliation, deduplication across sources, and provenance tracking (which source produced which record, at what time). Start with the ingestion pipeline: a message queue per source, schema normalization to a canonical format, deduplication by a defined primary key, and a persistent store with full history rather than latest-only.

Interviewers push on what happens when a source goes offline for 48 hours and then sends a catch-up batch. The answer: your ingestion pipeline needs idempotent writes (the same record arriving twice shouldn't create duplicates), a timestamp field from the source (not just arrival time), and a reconciliation step that identifies which downstream datasets need to be recomputed after a late batch arrives.

# Simplified schema reconciliation approach
from dataclasses import dataclass
from typing import Any

@dataclass
class CanonicalRecord:
    source_id: str
    record_id: str
    timestamp: str  # ISO 8601 from the source, not ingestion time
    payload: dict[str, Any]
    schema_version: str

def normalize_record(raw: dict, source_schema: dict) -> CanonicalRecord:
    """Map source fields to canonical schema. Raises ValueError on missing required fields."""
    return CanonicalRecord(
        source_id=source_schema["source_id"],
        record_id=str(raw[source_schema["primary_key"]]),
        timestamp=raw.get(source_schema["timestamp_field"], "unknown"),
        payload={
            canonical_key: raw[source_key]
            for canonical_key, source_key in source_schema["field_map"].items()
            if source_key in raw
        },
        schema_version=source_schema["version"],
    )

Audit logs are append-only and immutable. The requirements that matter here: every data access event must be logged with who accessed what, from where, at what time, and what action they took. Logs must be tamper-evident (a hash chain works for this at modest scale; a dedicated audit log service with write-once storage works at Palantir scale). Retention is often mandated by policy, design for configurable retention periods and compliant deletion.

Palantir interviewers specifically probe the failure case: what happens if the logging service is unavailable at the moment of an access event? If you fail the access request to preserve auditability, you've broken availability. If you allow the access and log it asynchronously, you risk losing the log entry on crash. A write-ahead log with a guaranteed-once delivery semantic is the right answer for high-stakes audit trails.

Two components with different latency requirements. The detection component (ML scoring) runs in near-real-time: transaction arrives, goes onto a stream (Kafka), scoring service consumes it, flags or clears it in under 100ms, downstream action follows. The review workflow operates at human latency: flagged transactions go into a work queue, analysts pick them up, make decisions, and the decision is written back to the transaction record and fed to the model's retraining pipeline.

The state management between these two systems is the hard part. If a transaction is flagged and an analyst is reviewing it, what happens if the payment processor's timeout fires before the analyst finishes? That's a business policy decision, not a technical one. Design a slot to store that policy and surface it explicitly rather than hardcoding the timeout behavior.

The problem underneath this question is schema mapping at the semantic level, not just the storage level. Two datasets might both contain "customer" records with different field names, different identifiers, and different levels of completeness. The design needs an object layer that sits above the raw datasets: object types (Customer, Order, Facility), properties mapped from one or more source datasets to each object type, and links, relationships between object types that may themselves be derived from a join key in a source dataset rather than stored explicitly.

This maps closely to what Palantir's own product calls an ontology, and FDSE candidates in particular report getting a version of this question because building this kind of object layer for a new customer's data is close to the actual job. The hard part interviewers push on: what happens when the same real-world entity appears in three datasets with three different identifiers and no shared key? A strong answer proposes a resolution step, fuzzy matching on name plus address, or a human-reviewed merge queue, and explicitly separates identity resolution from the object model itself, since conflating the two makes both harder to reason about.