@ -53,13 +53,13 @@ This is a straight-to-the-point, distilled list of technical interview Do's and
| ❌ | Start coding without interviewer's green light. |
| ❌ | Appear too unsure about your approach or analysis. |
### During coding
### Code out your solution
| | Things |
| --- | --- |
| ✅ | 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. |
| ✅ | Type/write at a reasonable speed. Too slow is no good. |
| ✅ | 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. |
@ -69,7 +69,7 @@ This is a straight-to-the-point, distilled list of technical interview Do's and
| ✅ | 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. |
| ❌ | Remain quiet the whole time while coding. |
| ❌ | Spend too much time writing comments. |
| ❌ | 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). |
@ -82,7 +82,7 @@ This is a straight-to-the-point, distilled list of technical interview Do's and
| --- | --- |
| ✅ | Scan through your code for mistakes as if it was your first time seeing code written by someone else. |
| ✅ | Check for off-by-one errors. |
| ✅ | Come up with more test cases. Try extreme test cases. |
| ✅ | Come up with test cases. Try extreme test cases - empty sets, single item sets, negative numbers |
| ✅ | Step through your code with those test cases. |
| ✅ | Look out for places where you can refactor. |
| ✅ | Reiterate the time and space complexity of your code. |
@ -7,95 +7,97 @@ The point of interviews is for interviewers to extract signals from certain cand
When interviewers take down interview feedback, these are likely what is on their feedback sheet.
Refer to the [Facebook's Onsite Interview Guide](https://scontent.xx.fbcdn.net/v/t39.2365-6/75448664_529293754518370_5563533277542744064_n.pdf?_nc_cat=108&ccb=1-5&_nc_sid=ad8a9d&_nc_ohc=wLjmSQfO3zQAX_fyaQ7&_nc_ht=scontent.xx&_nc_rmd=260&oh=577831ef9fb665716a3651b82f7041bc&oe=613A5FE8) for more information.
## Communication
### Clarify problem
- 👍 Appropriately asked good, clarifying questions about the problem
- 👎 Failed to confirm understanding/ask appropriate questions
### Communicating approach
- 👍 Able to explain overall approach, technical terms, and acronyms (where applicable)
- 👎 Failed to effectively explain overall approach, technical terms, and acronyms (where applicable)
### Explains while coding
- 👍 Explains what the code is doing while coding, especially for parts that aren't obvious
- 👎 Keeps silent during coding, or just reading out the code without much explanation
## Problem solving
#### Understanding the problem
### Understanding the problem
- 👍 Understood the key aspects of the problem quickly
- 👎 Had difficulty in understanding the key aspects of the problem
#### Solution/approach
### Solution/approach
- 👍 Approached the problem in a systematic and logical manner
- 👎 Did not demonstrate a logical thought process for approaching the problem
#### Improving the solution
### Trade-offs analysis
- 👍 Came up with multiple solutions and explained the trade-offs of each clearly and correctly
- 👎 Failed to describe trade-offs of different solutions
### Improving the solution
- 👍 Suggested a more efficient solution when prompted, or proactively coming up with a better solution
- 👎 Had difficulty in coming up with a more efficient solution even after being prompted
#### Trade-offs analysis
### Complexity analysis
- 👍 Explained the trade-offs of different approaches clearly and correctly
- 👎 Failed to describe trade-offs of different approaches
- 👍 Able to determine the algorithmic time and space complexity
- 👎 Was not able to determine the algorithmic time and space complexity (explain why TC came up with such an answer)
#### Hinting
### Hinting
- 👍 Did not require any major hints
- 👎 Needed plenty of hints
## Technical competency
#### Speed
### Speed
- 👍 Quickly implemented a working solution
- 👎 Was not able to complete the solution
#### Correctness/Accuracy
### Correctness/Accuracy
- 👍 Implemented the solution correctly (e.g., working solution, minimal bugs)
- 👎 Unable to correctly implement a solution (e.g., non-working solution, incorrect logic, and/or serious bugs)
#### Complexity analysis
- 👍 Able to determine the algorithmic time and space complexity
- 👎 Was not able to determine the algorithmic time and space complexity (explain why TC came up with such an answer)
#### Mastery of chosen programming language
### Mastery of chosen programming language
- 👍 Demonstrated mastery of the chosen programming language
- 👎 Does not seem to be familiar with the chosen programming language
#### Implementation
### Implementation
- 👍 Implementation was clean and straightforward
- 👎 Implementation was unnecessarily complex and/or messy
#### Coding style
### Coding style
- 👍 Coding style was neat (proper indentation, spacing, and no bad practices)
Yangshun
4 years ago