Technical interviews are just tough. For the month and a half I went through them, I felt like I was constantly studying for and taking a final exam. We were trying to cram at least a semester’s if not a years worth of computer science concepts into our brains as well as practice how to solve problems with an audience in a handful of days.
I definitely felt fear at the white board the first several times I was there. I would go blank and forget everything I knew. I was lucky if I remembered my name. But trust me when I say that you will survive this and practice is the key.
Technical interviews vary in delivery from over the phone, view web meeting/Google Hangout or in person. They range from an hour to spanning over a couple of days. Behavioral and get to know you questions are mixed in at times but the main focus is to run through coding a solution to at least one problem (e.g. reverse a string or merge sort).
Usually you can code in your preferred language. The interviewer may ask you to work on a whiteboard or on paper to write out the solution, and the typical expectations on how to respond to a problem are as follows:
- ask clarifying questions
- write in code how to solve the problem
- explain out loud as you write your thought process
- run through sample input and expected output to test the solution
At times, white-boarding felt like being asked to chew gum, rub my belly and head in opposite directions and cure cancer at the same time.
If you finish the problem sometimes the interviewer asks you to rework and/or expand the solution (e.g. write fewer lines or improve space complexity). Sometimes they give you more than one problem to solve (usually during meetings more than an hour and usually by different interviewers). Typically the interviewer asks about solution time complexity which is Big-O.
For technical phone interviews, you will usually do a call and use a web interface so the interviewer can have you code a problem on a shared screen. These interviews typically are an hour at most to get a sense for whether you are someone they want to bring in for an in person and more in-depth interview.
Some interviews also contain questions on computer science subjects and that really varied based on the role and company. Also there is the infamous brain teaser questions that I only came across once in an interview. These questions are used to test the way you think and there is debate on effectiveness.
Bottom line for the technical interview structure, the interviewer wants to see how effective you are at solving a problem.
During the interview, just remember to keep talking about what you are thinking and why. Use pseudo code to help create an initial solution plan if that helps. Just make sure you write actual code and don’t get too caught up in syntax.
Before and after interviews, I took on the approach to code at least one sample problem a day. It made me much more flexible and faster in my problem solving as well as improved my Python knowledge. Sometimes I just coded straight on the computer. Other times I get mentors and friends to drill me on a whiteboard. In between that, I would study recommended computer science topics and look at sample brain teasers.
Other helpful resources during my interview study:
- ABC: Always Be Coding
- Guerilla Guide to Developer Interviews
- Hacking a Google Interview
- Cracking the Coding Interview
- Geeks for Geeks
- Python Interview Questions & Answers
- Runestone Interactive
Best advice I’ve received is be authentic, confident and up front when you don’t know something. I know it sounds counter intuitive to be confident and admit you don’t know something. What you want to indicate is that it’s not something you know about and then explain how you would go about finding the answer. What companies need is someone who will show they are resourceful and capable to tackle the unknown in a systematic way.