The Most Important Thing in a Technical Interview
Let’s face it. Programming interviews are hard. While most of the population just have to worry about getting the interview and passing an HR screening, programmers are stuck with the daunting task of proving their worth in a time-boxed session of doom called the “technical interview.” To those that don’t work in the tech space, simply imagine a test at the end of your entire computer science education that could have literally anything on it. The biggest exam of a young programmer’s life. It’s similar to the bar exam that lawyers take or the FE exam required by engineers. The difference is that it usually is only one question and you have to re-pass the test every time you need to get a new job and interview with a new company. …
The Most Important Thing in a Technical Interview
Let’s face it. Programming interviews are hard. While most of the population just have to worry about getting the interview and passing an HR screening, programmers are stuck with the daunting task of proving their worth in a time-boxed session of doom called the “technical interview.” To those that don’t work in the tech space, simply imagine a test at the end of your entire computer science education that could have literally anything on it. The biggest exam of a young programmer’s life. It’s similar to the bar exam that lawyers take or the FE exam required by engineers. The difference is that it usually is only one question and you have to re-pass the test every time you need to get a new job and interview with a new company.
So you’re overwhelmed and not sure about what to study? Maybe you did well in your computer science classes, but freeze in an interview? Or perhaps your school focused more on theory and less on practical knowledge and has left you without any real chance of passing the technical interview? No worries – don’t panic! Believe it or not, technical interviews are a skill that can be hacked. Let me show you how.
The biggest mistake interviewees make
The biggest mistake people make when preparing for interviews is that _they don’t have an accurate view of their weaknesses_. Yousef, a bright coding bootcamp graduate, recently interviewed with me and he let me know at the start of the interview that he “struggles with linked lists and dynamic programming, but can do everything else.” While I’m sure that Yousef does indeed struggle with these things, he has an incomplete view of his struggles.
For instance, if Yousef is struggling with linked list problems then this implies that his recursion fundamentals likely need work. Because of this, we can see that not only will Yousef struggle with a large variety of pure recursion problems like backtracking, combinations, permutations, etc, but he will also struggle with many other types of data structure centric problems including binary search trees, k-ary trees, tries, graphs and – of course — dynamic programming.
Another recent interview involved a candidate, Sarah, giving me her best effort on solving a difficult tree question. She understood what she was supposed to do, asked good clarifying questions, and had a good chance at completing the interview with a fantastic score, but when it came time to translate her pseudo-coded solution into code she froze. She knew the theory, but _couldn’t translate her thoughts into code_.
Interestingly, she didn’t stumble because she didn’t understand the question – she actually worked out the optimal solution faster than most candidates do. When she started coding, it was clear that she had never used the sets before (a relatively simple data structure). After the interview was over she reflected on it and commented that she spent all her time preparing by solving problems in her head and never actually spent time coding them up since she thought that that was the easy part.
How to fix it
Not knowing where your blind spots are is easily one of the hardest parts about studying for a technical interview. Thankfully, there are resources that can help you discover areas of weakness. Below are a few suggestions:
1) Set up a camera and record yourself solving a problem online: Talk as if you were in the room interviewing with a real person. After you’re done, play it back and time yourself. How long before you found the solution? When did you have the first code draft done? When we’re the test cases passing? This is useful but self-reflection without direction will only get you so far.
2) Have a CS friend ask you questions: This can be helpful and usually helps with things you wouldn’t necessarily notice by yourself. “You rock back and forth when you’re nervous” and “You started coding too soon and should wait until you have a full solution before you jump in” are both common fixes here.
3) Get some interview coaching: Ok, you knew it was coming, but it’s easiest to learn when you have a someone giving you feedback that knows what to look for and actionable tips on how to improve. Imagine interviewing with a Facebook engineer and then being able to get personalized feedback on exactly what you need to tweak in order to land your dream job!
In the next section, we’ll talk more about what’s happening on the “other side of the clipboard” in a technical interview. We’ll discuss different interview types and the exact metrics that an interviewer cares about at each stage in the interview. Until then, keep practicing my friends!