The Coding Interview | Palantir
Most important is the ability to write clean and correct code—it's not enough just to be correct. A lot of people will be interacting with your code once you're on the job, so it should be readable, maintainable, and extensible where appropriate.
As you work, we also watch for debugging ability, problem-solving and analytical skills, creativity, and an understanding of the ecosystem that surrounds production code.
Make sure you understand the problem.
Don’t hesitate to ask questions. Specifically, if any of the problem requirements seem loosely defined or otherwise unclear, ask your interviewer to make things more concrete.
Work through simple examples.
Think about and list simple cases, corner cases. check them when write code.
This can be useful both before you begin and after you’ve finished coding. Working through simple examples before coding can give you additional clarity on the nature of the problem—it may help you notice additional cases or patterns in the problem that you would otherwise have missed had you been thinking more abstractly.
Make a plan.
Be wary of jumping into code without thinking about your program’s high-level structure. You don’t have to work out every last detail (this can be difficult for more meaty problems), but you should give the matter sufficient thought. Without proper planning, you may be forced to waste your limited time reworking significant parts of your program.
Choose a language.
WHILE YOU’RE CODING
Think out loud.
Break the problem down and define abstractions.
One crucial skill we look for is the ability to handle complexity by breaking problems into manageable sub-problems. For anything non-trivial, you’ll want to avoid writing one giant, monolithic function. Feel free to define helper functions, helper classes, and other abstractions to reach a working solution. You can leverage design patterns or other programming idioms as well. Ideally, your solution will be well-factored and as a result easy to read, understand, and prove correct.
Delay the implementation of your helper functions.
Write out the signature, and make sure you understand the contract your helper will enforce, but don’t implement it right away. This serves a number of purposes: (1) it shows that you’re familiar with abstractions (by treating the method as an API); (2) it allows you to maintain momentum towards the overall solution; (3) it results in fewer context-switches for your brain (you can reason about each level of the call stack separately); and (4) your interviewer may grant you the implementation for free, if he or she considers it trivial.
Don’t get caught up in trivialities.
ONCE YOU HAVE A SOLUTION
Think about edge cases.
Step through your code.
Huge caveat here: when mentally simulating how your code behaves, your brain will be tempted to project what it wants to happen rather than what actually says happen.
Explain the shortcuts you took.
Read full article from The Coding Interview | Palantir
Most important is the ability to write clean and correct code—it's not enough just to be correct. A lot of people will be interacting with your code once you're on the job, so it should be readable, maintainable, and extensible where appropriate.
As you work, we also watch for debugging ability, problem-solving and analytical skills, creativity, and an understanding of the ecosystem that surrounds production code.
Make sure you understand the problem.
Don’t hesitate to ask questions. Specifically, if any of the problem requirements seem loosely defined or otherwise unclear, ask your interviewer to make things more concrete.
Work through simple examples.
Think about and list simple cases, corner cases. check them when write code.
This can be useful both before you begin and after you’ve finished coding. Working through simple examples before coding can give you additional clarity on the nature of the problem—it may help you notice additional cases or patterns in the problem that you would otherwise have missed had you been thinking more abstractly.
Make a plan.
Be wary of jumping into code without thinking about your program’s high-level structure. You don’t have to work out every last detail (this can be difficult for more meaty problems), but you should give the matter sufficient thought. Without proper planning, you may be forced to waste your limited time reworking significant parts of your program.
Choose a language.
WHILE YOU’RE CODING
Think out loud.
Break the problem down and define abstractions.
One crucial skill we look for is the ability to handle complexity by breaking problems into manageable sub-problems. For anything non-trivial, you’ll want to avoid writing one giant, monolithic function. Feel free to define helper functions, helper classes, and other abstractions to reach a working solution. You can leverage design patterns or other programming idioms as well. Ideally, your solution will be well-factored and as a result easy to read, understand, and prove correct.
Delay the implementation of your helper functions.
Write out the signature, and make sure you understand the contract your helper will enforce, but don’t implement it right away. This serves a number of purposes: (1) it shows that you’re familiar with abstractions (by treating the method as an API); (2) it allows you to maintain momentum towards the overall solution; (3) it results in fewer context-switches for your brain (you can reason about each level of the call stack separately); and (4) your interviewer may grant you the implementation for free, if he or she considers it trivial.
Don’t get caught up in trivialities.
ONCE YOU HAVE A SOLUTION
Think about edge cases.
Step through your code.
Huge caveat here: when mentally simulating how your code behaves, your brain will be tempted to project what it wants to happen rather than what actually says happen.
Explain the shortcuts you took.
Read full article from The Coding Interview | Palantir
