You’re a snowboarder in the Olympics. An entirely new snowboarding course was built just for this competition, and you (and only you) get to trial run it as many times as you want before the actual competition. You have quite an advantage, right?
Practicing in the environment that you’ll be performing in leads to better results.
Failing to practice for the actual interview environment is one of the main reasons for failed tech interviews. Checkout these tips for whiteboard interviews and phone interviews to give yourself an edge.
Whiteboard Interview Tips
“Whiteboard interviews suck. People don’t code on a whiteboard. It’s not like my actual job.”
It’s true. Whiteboard interviews aren’t the same as actual coding. But, why does an interview have to be exactly like coding? When a salesperson interviews and gets asked, “Sell me this pen”, is that the same as selling to a customer? Would you rather be asked wishy-washy questions like, “What’s your greatest weakness?” Just the fact that this complaint comes up so often, confirms that there’s a huge advantage to be gained by getting used to coding on the whiteboard.
Interview tip: Use the whiteboard to your advantage
I was once asked during an interview, “List all the ways you can think of to print a linked list in reverse order.”
“Hmm…weird warmup question,” I thought to myself.
Me: “How about using a stack, similar to what the recursive solution would doeither directly, or using recursion.”
Interviewer: “Sounds Reasonable.”
The interviewer wrote on the whiteboard:
- Recursion
Me: “Or how about, reversing the linked list, printing, then reversing it back again.”
The interviewer updated the whiteboard:
- Recursion
- Reverse, print, reverse
Me: “I’d probably use one of those ways. I’d have to be careful, The reverse, print, reverse method wouldn’t work if called by multiple threads at once.”
Interviewer: “But is there anything else you could do? Without modifying the linked list?”
At this point, I started to get a bit nervous, it seemed weird to do anything other than what I suggested. Reversing, printing, and then reversing had a good time complexity $((O(n))$ and didn’t waste space (but wasn’t good for concurrency), using a stack would likely be the most common solution.
Me: “Well, you could iterate all the way to the end and print, then start from the beginning and iterate to end-1 and print, then repeat again for end-2, end-3, etc. Taking $O(n^2)$ time to print a linked list in reverse seems pretty bad though…”
Interviewer: “Anything else?”
At this point, I was lost. Really? I have to come up with something else? There was an awkward silence since. I knew this was supposed to be a simple warm-up…
Me (now just grasping): “How about we copy the whole thing to some other sort of data structure, like an array, print it in reverse then delete the array.
Interviewer: “So that would be like, what? Like a stack, right?”
He was looking for STACK the whole time! The same thing I meant by my very first response! I said stack, like recursion, and he keyed on that word, recursion, and took it to mean the recursive solution, and I was too busy thinking about more ways to even realize!
I should’ve been the one writing the list.
In a whiteboard interview, always use the whiteboard to help illustrate your points. Control the marker and use it to write out lists. Diagram your solutions before you code them. In general, use the whiteboard to help you communicate.
Once you learn to view the whiteboard as a tool to help you show off your knowledge, rather than something to fear writing code on, you’ll have an edge.
Interview tip: Practice on the whiteboard
If you go to a whiteboard interview without doing any interview questions on the whiteboard beforehand, you’re putting yourself at a disadvantage.
Practicing even just three to five questions by fully working them out on a whiteboard, can make a huge difference when it comes to your interview performance.
If you don’t have access to a whiteboard, a mini whiteboard, whiteboard markers, and a dry eraser, would be a very small investment relative to the salary you’ll be making when you pass through the interview.
Interview tip: Come prepared.
During an interview, you’ll be nervous and stressed, small annoyances can throw you off.
One thing that can happen is a meeting room with an out of ink whiteboard pen or a missing eraser. In order to avoid running into this situation, you can bring your own!
Another thing you can consider bringing to an on-site interview is a laptop that you regularly code on. If you really dislike whiteboard coding, and are asked to code something, the interviewer might allow you to use it.
Phone Interview Tips
These days, technical phone screens are more and more likely to be a competitive programming question (e.g. a leetcode question) done in some sort of collaborative coding environment (typically coderpad).
Interview tip: Use a headset
Holding a phone using your neck, while trying to write code on your laptop, while also explaining what you are writing to someone you’ve never met, is just bound to go wrong.
You can use speakerphone, but background noise can end up being an issue when it comes to trying to communicate with someone that may have an accent you’re not yet used to understanding.
Not buying or borrowing a headset, can be the reason you fail your tech interview.
Interview tip: Practice in a collaborative coding environment
If your phone interview is going to be using a collaborative coding environment (like coderpad, or sometimes just google docs), ask the recruiter which one, and try a few questions in that environment beforehand.
I commonly use vim bindings when I code, and after realizing that coderpad also had vim bindings, I felt much more comfortable during coderpad interviews.