The Potential Stress of Technical Interviews
Technical recruiters should take heed, it’s really important to help ease the nerves of developers as they prepare for their technical interviews for programming positions. Going in with the right mindset and game-plan is critical for landing the job. Crelate is happy to offer some ‘inside’ information from guest blogger John Franti of Epicodus – a vocational school for aspiring programmers.
The technical interview is the most nerve-wracking part of the hiring process for most new or junior developers. Probably for most developers, full-stop. Programmers with years of accumulated experience and confidence report the same doubts, nerves, and anxieties every time the interviewer points to the whiteboard.
And why wouldn’t we? A search for the term “technical interview” in the Computers & Technology section on Amazon returned 710 responses. Among the books that are “must-haves” for junior developers are Cracking the Coding Interview and Elements of Programming Interviews. Both are great resources and immensely helpful, but if you don’t have time to read the books here are a few things to ponder.
Seemingly Everyone has an Opinion for how to Prepare
Everyone should prepare for any interview, but there can be a hidden message communicated by this flood of guidance, advice, and “insider” information: The technical part of your interview is a terrifying experience that will haunt you and ruin your future.
Additionally, there is no widely acknowledged difference in the literature between the skills needed to successfully interview for a job, or work as a systems architect at Google or Facebook and a junior front-end or back-end developer at an agency, or start-up. To believe the conventional wisdom, everyone needs to be a “10x haxxor”, a “ninja”. This is what Jacob Kaplan-Moss called the Programming Talent Myth. There are few great programmers, and everyone else is untalented and unfit to work as a programmer. Wrong. Instead, Kaplan-Moss tries to enforce the idea that programming skills follow the same bell curve as any other set of skills. By this theory there are a few extremely talented people, a very few uniquely unskilled individuals, and the majority of programmers fall somewhere in the middle of the pack.
It’s no wonder that so many developers suffer from imposter syndrome or even fail to apply for relevant jobs for fear of being unqualified given the high bar of success that is often set. This doesn’t have to be the case. I’ve helped hundreds of students in my role at Epicodus prepare for their very first programming interviews. There are direct carryovers from the skills a person has at the keyboard to the skills needed at the whiteboard.
Think of the Technical Interview as a Conversation
A good technical interview should be a conversation. It should not be a test of knowledge. A technical interview is best used when it evaluates how a candidate thinks and works, not evaluating what they know. The candidate’s resume, and the non-whiteboard part of the interview should be sufficient to determine if they have experience with the required languages, frameworks, and concepts. As an interviewee, if you’re asked to whiteboard, that’s great news – the interviewer knows you have the skills to work through a difficult question, and wants to see how you do so.
Tips & Tricks for the Technical Interview
So, what are some good practices?
I love the idea of treating each technical question like a mini-project. First, have the interviewer repeat the question. Second, listen carefully, and write down a list of specs. Where? On the whiteboard, of course.
Again, you’re showing how you work. You work from a list of specs, like the good, professional developer you are. Therefore, once the specs are listed, read them back and start looking for keywords and easy requirements that will help you answer the question.
* Are you writing a function? Get the word function and some curly braces up on the board.
* Does the function accept any kind of argument? Get it in the parens.
* Does the function return a value? Let’s put a return statement at the end of the function.
Easy, right?
A Couple More Words of Wisdom
The purpose of all this boilerplate, or any similar setup is to give ourselves a familiar work space. Further, it’s how we write functions when we’re in our text editor – why would it be any different just because it’s ink and not pixels? It also gets some information on the board, and can get you thinking.
Are you stuck, or do you need to test your algorithm? Draw a box on the whiteboard and list your variables and their initial values inside. This box represents machine memory during the process. Next, pass some test data into your function and talk through the behavior with the interviewer while changing the values within the box. By doing live, manual testing this often can help the interviewee get unstuck.
And of course, it’s alright to say “I don’t know” as long as you finish with the word “…yet.” Then, go forward with the interviewer. How would you go about finding out? What terms would you search for? Where have you seen similar behavior? Keep communicating and showing how you think.
A Note for Interviewers
Finally, for interviewers who may be reading this, because the goal of the technical interview is how we think and not what we know, the question itself doesn’t need to be that hard. A new programmer can show just as much knowledge writing a factorial algorithm as they can solving an advanced sorting problem. The way the thought process is communicated is often what stands out.
You can check out a few more simple tips within my lesson at Learn How to Program
John Franti is a professional programming instructor with Epicodus and is the director for their Seattle campus. He has contributed to open-source learning tools for students of PHP, Drupal, C#, and .NET Core. He lives in Ballard, WA with his wife, Madeline.
