Archive for October, 2016
It has been two years since I published my initial post “Understanding the Coding Interview”, and since then, I’ve had a lot of time to read and reflect on this topic to arrive at more insights. As I emphasized in my first post, preparation is no doubt an essential part of the game. However, what interview-coach books often overlook is the utmost importance of putting yourself into the right mindset for the interview. You could have studied hundreds of questions prior to the interview, but on the big day, standing in-front of the white-board, faced with a tough question from the interviewer, your mind shuts off, like a deer caught in headlights. This effect, as I later found out from reading Charles Duhigg’s book “Smarter, Faster, Better”, is known as “cognitive tunneling”, and can lead to you to make bad decisions in the face of pressure. The key to overcoming “cognitive tunneling” is to build a strong mental model of the task well before you perform it, so your mind will stay focused on the correct objectives during the task. To that end, I have devised a mental model of the “technical interview” that may help you succeed at what is traditionally viewed as an obscure and arbitrary evaluation procedure amounting to nothing more than a coin-toss.
The key idea behind my mental model is to view technical interviews not like job interviews but rather like school exams. Viewing technical interviews as school exams immediately implies several important axioms:
One, you need to study for technical interviews just like school exams. Do practice problems and read solutions to practice problems. No matter how smart you are or how confident you are, you will not do well (or as well as you could) on a school exam if you don’t study for it. This is the focus of my first blog post on this topic, so I won’t go into the details here.
Two, you need to think of technical interviews as grading you on an “A, B, C” scale, as opposed to being pass-fail. It is true that many people who “pass” interviews barely manage to squeak by, and that’s what matters at the end of the day, but “passing” should not be your primary mental focus. If you set “passing” the interview as your goal, you are aiming too low, and a single careless mistake will send you over the edge of the cliff. On the other hand, if you aim to score an “A” on the interview, even if you make some mistakes that hurt your score and put you in the “B” range, you may still pass the interview! One of my favorite sayings is, “Shoot for the moon – if you miss, at least you will land amongst the stars”. It applies to life, it applies to exams, and it applies to technical interviews.
What does this all mean in practice?
First, to elaborate on the “A, B, C” grading scale for technical interviews, here is what each grade roughly amounts to:
“A” is reserved for the top tier candidates who demonstrate deep understanding of algorithms and object-oriented design. These are the candidates who are able to quickly provide an O(n) solution to a tricky array problem (using learned techniques such as “Two Pointers”), and show liberal use of object-oriented design principals such as inheritance and polymorphism in design questions. These are the candidates that all companies are looking to hire.
“B” is reserved for the mid tier candidates who demonstrate good understanding of algorithms and design. These are the candidates who are able to optimize an O(n^2) solution to O(nlogn) after some trial and error, and shows reasonable competency in using classes in design questions. Depending on the company’s hiring-bar, this may be good enough to “pass” the interview, but not always.
“C” is reserved for the low tier candidates who demonstrate barebones knowledge of algorithms and design. They are the ones who are able to cough out an O(n^3) brute force solution to an algorithms problem and implement basic methods in design questions. This is not good enough to pass the interview by any stretch of the imagination.
“F” is reserved for the candidates who shows up to the interview with a hang-over.
Note that I’ve used the word “demonstrate” instead of “possess”, and the reason is as follows: The interviewer doesn’t evaluate you on your raw smarts or the vast array of knowledge you possess, but rather on what you are able to demonstrate or show in one hour. Depending on the candidate, this can be a blessing in disguise because putting on a “show” is something that can be learned and prepared for in a relatively short amount of time, even if you are not the smartest apple in the bunch. The key is to study and prepare!
Finally, another important element of the “school exam mental model” for technical interviews is acclimating to the interview environment. When you are in school, you learn in the same classrooms or lecture halls as where you eventually take your exams, so growing up you have always been taking tests in familiar environments. On the other hand, onsite-interviews often require you to code on the white-board or on a piece of paper, which you would rarely do as a software developer, and this can be a jarring stimuli in an interview. The only way to overcome this cognitive dissonance is to actually simulate this environment while preparing for your interviews - go out and buy a white board if you don’t already have one! Get used to the smell of those dry-erase markers! Brush up on your handwriting! Only when coding on the white board feels like second nature will you truly be prepared to solve algorithms questions without external interference.
In future posts, I will provide concrete examples of “A”, “B”, “C” grade solutions to further illustrate what to shoot for and what to avoid.