@ -21,7 +21,7 @@ This is a straight-to-the-point, distilled list of technical interview Do's and
| ✅ | Request for the option to interview over Hangouts/Skype instead of a phone call; it is easier to send links or text across. |
| ✅ | Decide on and be familiar with a programming language. |
| ✅ | Familiarize yourself with the coding environment (CoderPad/CodePen). Set up the coding shortcuts, turn on autocompletion, tab spacing, etc. |
| ✅ | Prepare answers to the [frequently-asked questions](behavioral-questions.md) in an interview. |
| ✅ | Prepare answers to the [frequently-asked behaioral questions](behavioral-questions.md) in an interview. |
| ✅ | Prepare some [questions to ask](questions-to-ask.md) at the end of the interview. |
| ✅ | Dress comfortably. Usually you do not need to wear smart clothes, casual should be fine. T-shirts and jeans are acceptable at most places. |
| ✅ | Stay calm and composed. |
@ -41,7 +41,7 @@ This is a straight-to-the-point, distilled list of technical interview Do's and
| | Things |
| --- | --- |
| ✅ | 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 any assumptions you made subconsciously. Many questions are under-specified on purpose. E.g. 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. |
@ -66,13 +66,13 @@ This is a straight-to-the-point, distilled list of technical interview Do's and
| ✅ | 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. |
| ✅ | 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., "Under non-interview settings, 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. |
| ❌ | Use extremely verbose or single-character (unless they're common like `i`, `n`) variable names. |
| ❌ | Copy and paste code without checking (e.g. variables need to be renamed). |
| ❌ | 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. |