This is a straight-to-the-point, distilled list of technical interview Do's and Don'ts, mainly for algorithmic interviews. Some of these may apply to only phone screens or whiteboard interviews, but most will apply to both. I revise this list before each of my interviews to remind myself of them and eventually internalized all of them to the point I do not have to rely on it anymore.
| ✅ | Repeat the question back at the interviewer. |
| ✅ | Clarify any assumptions you made subconsciously. Many questions are under-specified on purpose. A tree-like diagram could very well be a graph that allows for cycles and a naive recursive solution would not work. |
| ✅ | Clarify input format and range. Ask whether input can be assumed to be well-formed and non-null. |
| ✅ | Work through a small example to ensure you understood the question. |
| ✅ | Explain a high level approach even if it is a brute force one. |
| ✅ | Improve upon the approach and optimize. Reduce duplicated work and cache repeated computations. |
| ✅ | Think carefully, then state and explain the time and space complexity of your approaches. |
| ✅ | If stuck, think about related problems you have seen before and how they were solved. Check out the [tips](algorithms/introduction.md) in this section. |
| ✅ | Explain what you are coding/typing to the interviewer, what you are trying to achieve. |
| ✅ | Practice good coding style. Clear variable names, consistent operator spacing, proper indentation, etc. |
| ✅ | Type/write at a reasonable speed. |
| ✅ | As much as possible, write actual compilable code, not pseudocode. |
| ✅ | Write in a modular fashion. Extract out chunks of repeated code into functions. |
| ✅ | Ask for permission to use trivial functions without having to implement them; saves you some time. |
| ✅ | Use the hints given by the interviewer. |
| ✅ | Demonstrate mastery of your chosen programming language. |
| ✅ | Demonstrate technical knowledge in data structures and algorithms. |
| ✅ | If you are cutting corners in your code, state that out loud to your interviewer and say what you would do in a non-interview setting (no time constraints). E.g., I would write a regex to parse this string rather than using `split()` which may not cover all cases. |
| ✅ | Practice whiteboard space-management skills. |
| ⚠️ | Reasonable defensive coding. Check for nulls, empty collections, etc. Can omit if input validity has been clarified with the interviewer. |
| ❌ | Remain quiet the whole time. |
| ❌ | Spend too much time writing comments. |
| ❌ | Use extremely verbose variable names. |
| ❌ | Copy and paste code without checking. |
| ❌ | Interrupt your interviewer when they are talking. Usually if they speak, they are trying to give you hints or steer you in the right direction. |
| ❌ | Write too big (takes up too much space) or too small (illegible) if on a whiteboard. |
| ✅ | Ask questions. More importantly, ask good and engaging questions that are tailored to the company! Pick some questions from [this list](questions-to-ask.md). |
