- Job Search Process
- Tips and Tricks
- Practice Questions
- Recommended Reading
Traditional resumes DON'T WORK.
Learn how to write a dev resume
the right way to get hired fast.
When the interviewer describes a problem, don't immediately jump into writing code! That shows a lack of planning on your part and is generally interpreted as a strike against you. Instead, try to sketch out an example first, and ask questions to make sure you understand the problem. Some interviewers deliberately leave out important facts to see if you ask the right questions. Do not begin unless you are sure you understand the problem.
After trying out a couple of examples to verify your understanding, concentrate on the algorithm you'll use to solve the problem. A key decision is selecting a good data structure to model the problem. Picking the right data structure will make a huge difference in the amount of code required to solve a problem, so if you are getting stuck, think about alternative data structures you may have missed. Resist any temptation to dive into coding until you have developed a high level algorithm that you think solves the problem. If you have trouble coming up with an algorithm, try more examples to see if you can extend specific solutions into a generic solution.
Don’t look to the interviewer to find out if you are proceeding correctly or not - they want to see your train of thought, so even if you are wrong it may still be okay if you chose a reasonable approach. Do feel free to ask about facts that you would be able to quickly look up online, like specific language syntax or a function you might have forgotten.
Throughout the problem solving process, make sure to talk about what you're thinking. Interviewers can't read minds; if you're standing there silently, it could mean you're completely clueless or thinking hard, but they can't tell which. Make sure they know your thought process by verbalizing it. This way they can also give hints if you made a bad assumption or are missing a key ingredient to the solution. Don't worry about the efficiency of your code until after you've reached a correct solution.
Even if you know the answer to a problem, don't just shout out the answer! You want to demonstrate that you understand the problem and the components to its solution, so go through the same steps and show your understanding of the concepts.
While you're writing the code for your solution, explain what you're writing. Solutions should be around 25 lines or less; anything more is probably suboptimal or completely wrong. Definitely mention any additional information you may know about a problem, even if it's not particularly relevant; it demonstrates your breadth of knowledge on the topic.
As soon as you finish writing the code, make sure to trace through your solution with the examples you first tried it out with to check for correctness. Pay special attention to the edge cases and where exceptions may occur (null pointers, division by zero). Missing these checks is costly in a production setting, so getting these right will set you apart from the crowd. Also, try to include sanity checks to make sure your inputs are valid.
Afterwards, be prepared to discuss the running time of your algorithm and design tradeoffs. Even if the interviewer doesn't ask, feel free to volunteer this information if you are confident in the answer to demonstrate your depth of knowledge.