Writing Good Code

Definition

The ability to write code that is:

• Efficient. Code runs at optimal performance and can be scaled.
• Effective. Code should be free of bugs, and it should be easy to test.
• Easy to read, maintain, and upgrade. Elements of the code should be properly structured and and defined, from simple variable naming to the structure of multiple files, classes, and frameworks.

Why do we value writing good code?

Palantir is a big company made up of small teams. Across Product and Business Development, teams of 4-8 engineers contribute to our core platforms and extend these platforms with custom code. Code must be good for this decentralized model to work.

Our business moves fast. To maximize engineering creativity and velocity, we give our engineers a lot of freedom to architect their code without strict style guidelines. Whether you're a Software Engineer working on a long-term platform project or a Forward Deployed Software Engineer prototyping an extension with a deadline next week, you need to understand what quality code looks like.

How to prepare

We will not ask you about tricky or obscure features of some specific programming language. We are interested in your skill as a coder, not your ability to memorize specifics of the Java compiler.

The best way to prepare to demonstrate your coding skills is to write code! Some things to keep in mind as you practice:

• One of the core facets of a good coding interview is the ability to translate a conceptual algorithmic solution into the code that actually implements it. Often, this translation isn't obvious and requires some planning and thinking ahead.
• Think about edge cases and the ways in which your code could break. Think about how to test it.
• Once you find an algorithm that runs with the optimal theoretical complexity (say, O(n)), keep thinking about scalability and what's important in terms of efficiency. Sometimes an O(n) algorithm can be implemented either with a loop that does n or 2*n iterations. Sometimes adding a data structure with O(n) space complexity is unnecessary.
• Think about structure, naming and overall tidiness of your code.
• Be mindful of API calls. It's okay to use simple utility calls like array and string manipulation or data structures, but for each API call you make, be sure that you understand what it does and with what complexity.

In terms of the interview itself:

• We are generally okay with most programming languages you might decide to use in the interview, as long as they're imperative. Avoid anything too exotic or ancient. For instance, we are obviously fine with languages commonly found in industry such as Java, Python, C/C++, C#, JavaScript and so forth (including variations like Rust, Go, Groovy, TypeScript). We are also fine with slightly older languages as long as they are still imperative, like Visual Basic, Pascal/Delphi, Perl, etc. But we won't be okay with non-imperative languages (Prolog, Lisp, Erlang) or languages that are too exotic, ancient and/or different from modern industry practices (Cobol, Fortran).
• Be prepared to code on a whiteboard when you come on site to interview. (We can provide pen and paper or a computer upon request.)