Lack of Communication (silence)11. Interviewers want you to do good, so you need to let them into your thought process.
Missing errors and failing to correct them22. If an interviewer gives you a hint, you HAVE to listen.
Lack of follow-through and analysis33. After writing, do not just say, “okay I’m done”; think through your solution again, think about test/edge cases, analysis, etc.
Talking Through Your Thought Process
Takeaway: The interviewer wants to help and hear your thought process.
You have to describe and explain as you go, you can’t just read code aloud.
No matter what is going through your head, you have to share!
Even if you think it’s totally wrong, you can preface it with, “This is something I know isn’t right, but, …”
Clarifying the Problem
When given a problem in a TPS, you should start by talking through potential issues and asking clarifying issues.
Remember: Your goal is to understand the problem!
Recovering From Mistakes
You will make mistakes, the question is whether you can notice and fix them.
If the interviewer asks an “are you sure…” question, that is a sign to listen!
When acknowledging mistakes, don’t get flustered. You have to continue professionally and knowledgabley.
If you are stuck, ask for help; and really listen to the hint you are given.
Testing Your Solution
You need to test your solution and evaluate edge cases in your head! Trace your code!
Tip: Remember to trace what is written; not what you think you wrote!
Algorithmic Problem Solving
Planning
Start by asking clarifying questions to understand the problem
Good questions are relevant and useful.
Then, brainstorm an example input and output
Also think about potential obstacles and special cases
Build a naive solution
Aim for just a naive, working solution initially
Test the solution
Test with normal input
Test with edge cases
Think about data structures
Think about performance
Think about trade-offs
Iterate on design
Analyze your solution and try to make it better
Implementing
Actually write the code
Plan thrice, write once.
Example: Asking Questions
Q: “How would you find the kth smallest element in an array of integers?”
A:
Smallest on the number line, or in magnitude?
Defining “smallest”
Is the array pre-sorted?
Defining the structure
Are there duplicate entries in the array?
Defining more of the structure
Does k start at 0?
Defining the input
Can we change the array?
Is it mutable?
Whiteboard Coding
When writing code on a whiteboard:
Use relatively meaningful names.
For variables, “k” is a readable character44. “i” and “j” can end up being mistaken for each other or for “;”
Leave extra space for easier modification
Write big and legibly.
Interviewers want you to do good, so you need to let them into your thought process.↩︎
If an interviewer gives you a hint, you HAVE to listen.↩︎
After writing, do not just say, “okay I’m done”; think through your solution again, think about test/edge cases, analysis, etc.↩︎
“i” and “j” can end up being mistaken for each other or for “;”↩︎