Programming interviews are hard. While non-technical job-seekers have to worry about getting the interview and passing an HR screening, programmers and engineers are tasked with the daunting “technical interview.” Typically this is an hour interview where one is tasked with proving their skills in a time-boxed session administered by a potential future manager or peer. This is the biggest exam of a young programmer’s life; a test at the end of your computer science education that could have literally anything on it. The worst part is that it is not just one test but a differing test you have to re-pass every time you need a new job and interview with a new company. So how do you consistently pass when every company presents a different type of test?
Technical interviews are a skill that can be hacked and in this article I am going to show you how.
The Biggest Mistake Interviewees Make:
In order to pass your technical interview you must understand your strengths and weaknesses. The biggest mistake engineers make when preparing for interviews is that they do not have an accurate view of their weaknesses. Let me give you an example: Yousef, a bright coding bootcamp graduate, recently interviewed with me at Skilled Inc 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 did not have a complete view of his struggles.
If Yousef is struggling with linked list problems then this implies that his recursion fundamentals are weak. Because of this, we can see that not only will Yousef struggle with a large variety of pure recursion problems like backtracking, combinations, permutations, exhaustive searches, 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 example involves a candidate named Sarah, who gave me her best effort on solving a difﬁcult tree question. Sarah understood what she was supposed to do, asked good clarifying questions, and was on track to complete the interview with a fantastic score, but when it came time to translate her pseudo-coded solution into code she froze. She understood theory, but could not translate her thoughts into code.
Sarah did not stumble due to not understanding the question – she actually worked out the optimal solution faster than most candidates do. The issue was that when she started coding it was clear that she had never used the simple data structure (sets) required in the programming language she said she was proﬁcient at. 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:
Identifying your blind spots is the hardest parts of studying for a technical interview. Thankfully, there are resources that can help you discover areas of weakness. Below are a few suggestions:
- 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 ﬁrst code draft done? When we’re the test cases passing? This is useful but self-reflection without direction will only get you so far.
- Do practice interviews with engineering friends/peers: 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 ﬁxes here.
- Sign up for a Skilled Inc interview: Ok, you knew it was coming, but it’s easiest to learn when you have a professional interviewer giving you feedback. Imagine interviewing with a Facebook engineer (or another engineer from a big tech company) 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 post 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!
If you have any questions or feedback please feel free to add me on Linkedin: https://www.linkedin.com/in/michael-mroczka/
Thank you for reading!