Palantir runs a distinctive code review round that is not a typical coding interview. Instead of being handed a self-contained problem and writing a solution from a blank editor, you are given an existing codebase and asked to read it, explain what it does, find a bug, and then extend it. The challenge is as much about navigating unfamiliar, over-engineered code as it is about the underlying algorithm.
Because this round is built around reading and reasoning over existing code, there is no single fixed problem statement to reproduce. This page describes the scenario that has come up, the class structure you are asked to work through, the bug you are expected to catch, and the two follow-ups that build on it. The exact starter files and full reference solution were not part of what could be captured, so the focus below is on the shape of the task.
The domain is a graph of cities connected by roads. The catch is that the graph is defined with several overlapping classes, which makes it easy to lose track of what represents what. The class definitions look roughly like this: [Source: darkinterview.com]
class Location {
String name;
public Location(String name) {
this.name = name;
}
}
class Road {
Location from;
Location to;
int distance;
public Road(Location from, Location to, int distance) {
this.from = from;
this.to = to;
this.distance = distance; // weight = 1 for now
}
}
class RoadConnection {
Location destination;
int distance;
public RoadConnection(Location destination, int distance) {
this.destination = destination;
this.distance = distance;
}
}
A large part of the difficulty is simply keeping these three abstractions straight. A Location is a city. A Road carries a from, a to, and a distance. A RoadConnection collapses that into a destination plus a distance, which is the adjacency-list view used when traversing from a given city. Because the naming is so similar, it is easy to get turned around. Take the time to state out loud what each class models before touching the logic.
The bug is that roads are meant to be bidirectional, but the code builds the graph as if they were one-way. A Road from city A to city B should let you travel A to B and B to A, but the graph construction only registers the connection in the from to to direction.
The fix is to make sure each Road produces a RoadConnection in both directions when the adjacency structure is built, so that traversing from either endpoint can reach the other. Catching this requires actually tracing how the Road objects are turned into the connections used during traversal rather than trusting that the model matches the real-world meaning of a road. [Source: darkinterview.com]
The first follow-up asks for the shortest distance between two cities when every road has weight 1. Since all edges cost the same, this is a plain breadth-first search: traverse outward from the start city level by level, and the first time you reach the target city gives the fewest number of roads between them.
The main pitfall here is letting the confusing class structure disorient you while you write the traversal. With several similar-looking classes in front of you, it is easy to tie yourself in knots over a search that is fundamentally straightforward. Keep clear on which class represents what, and BFS stays simple.
The second follow-up relaxes the assumption: roads now have varying weights (distances), and you need the shortest total distance between two cities. Plain BFS no longer works because reaching a city in the fewest hops does not mean reaching it by the shortest total distance. This is where Dijkstra's algorithm comes in, using a priority queue to always expand the closest not-yet-finalized city next. [Source: darkinterview.com]