Comic courtesy of XKCD, via Creative Commons License
Short for ‘decomposition of problems,’ the decomp interview helps us get a sense of how well you’re able to break down a problem into its nitty-gritty components, before the actual nitty-gritty building begins.
The problems we encounter are often nebulous and complex, and require engineers who can break them down, develop a reasonable first-pass solution, and independently take steps to execute that solution. Decomp is a collaborative process – it might involve some coding or sketching out of what the code may look like. But most often, it involves whiteboarding and brainstorming with another dev to talk through the potential feature set.
This reflects what working at Palantir is actually like. Engineers have a tremendous amount of freedom here; our devs aren’t given features described to full specifications simply to implement. Rather, our customers typically give us an idea of what they think they need, but don’t know how to explain fully or build themselves. Since our work is constantly evolving, decomp is essential for all of our devs to be able to strategically assess the work that lies ahead.
We need people we can trust to do the right thing without a lot of supervision—people who can own large projects and take them consistently in the right direction. Invariably, this means being able to communicate well with the people around you. Decomp boils down to being able to see and do the right thing. We want to see if you can take nebulous requirements and translate them into something actionable. The result might be a complex, well-scoped system, or just a basic solution that solves a particular need.
Decomp questions tend to be about designing a system or feature. We are looking for you to break down the problem, identify potential roadblocks, and develop a solution. From there, you’ll be having the same kind of conversation with your interviewer as you might have with a colleague in a planning meeting. This means that you’ll be shaping the discussion and the problem space. Some tips:
In imitation of the collaborative environment at Palantir, your interviewer might suggest alternatives to your solution or point out problematic areas, looking for you to adjust or defend your course of action. Since there are many tradeoffs in any system we design, your interviewer will prod at your approach – don’t be afraid to defend elements that you feel are better than the alternative! But you should also be prepared to accept and incorporate a different implementation than what you had initially envisioned; flexibility is key in good decomp.
The best way to prepare for a decomp interview is to try it out yourself. There is really no substitute for practice, here.
We hope this post has given you a good idea of what to expect and what to prepare for in your decomp interview. But just in case, here are a few pointers on what to avoid: