Survival Guide for Technical Interviews

The following blog post is a collection of resources that I’ve amassed over about 6 years of technical internships, half a year of full time employment, and about the same amount of time watching others go through the process too.  I’m planning to come back to this post periodically and edit in additional resources or advice that I encounter. 

*NOTE* – The opinions and advice in this post are specifically my own and are in no way endorsed by Google, Alphabet, or any company.

That all being said, below is a pseudo-outline of mixed advice, tricks, and links that should give you a fighting chance in any technical interview.  Remember, interviewers aren’t out to get you.  They’re trying to find people that will work well with the company and maybe even with the interviewers themselves.  This is a measure of your technical skill, your motivation, and all of the other aspects that make you an asset to a company.  Interviewers are there to observe you in your natural engineering/problem solving state, so relax as much as possible and try to have fun with it.  The more relaxed and at home you are when you’re talking about your past work experience or solving problems on a whiteboard, the more likely they are to be engaged and really be able to gauge your talent.

Know what you’re talking about (practice makes perfect) 

• Pick one language that you’re going to interviews in, do all of your practice in that.
  • I picked Java because I have the most experience in that language and in my opinion the syntax and it’s static typing makes it the easiest to visualize on a whiteboard. 
    • It’s really all personal preference within the confines of the position you’re applying to.  For example, web design positions should be javascript or python, backend positions should be C, C++, Java, Go, etc.
• Make sure to get familiar with the standard libraries of the language you pick:
  • Data structures – lists, sets, trees, stacks, queues, etc.
  • Representation conversion functions
  • Language idioms – this stuff matters for code quality in general but especially for companies/teams that do language specific things like apis/libraries/language development

Practice good interview skills

• Speak clearly and ask clarifying questions
  • Phone interviews suck.  They just do.
    • Make sure you have a pair of headphones, a quiet space with good cell reception, and probably wifi.
    • Do a tech test with a friend *BEFORE* the interview.
    • Don’t be afraid to ask people to repeat themselves if you need.  Correctness is more important
  • In person interviews aren’t necessarily better
    • Sometimes there’s a language/accent barrier.  Do your best and again, don’t be afraid to ask clarifying questions.
• Practice Interview Coding
  • Code out loud – reveals your thinking, shows that you have the depth of knowledge and that you’re not just repeating a solution that you found somewhere
  • Figure out the medium – whiteboard coding or do they have laptops?  Get good at both if you don’t know.
    • Whiteboard code requires forethought because there’s no “up-arrow-enter-key” to add a new line
    • Pseudo code first and figure out how you’re going to space things out before actually writing code.
  • On that note, always write pseudo-code before you start writing actual code anyway.  This shows that you understand the problem and that you’re not just spitballing around with a solution.  Also it’s easier to debug when it’s just in pseudo code and you haven’t taken the time to figure out all of the language specifics.
• Be explicit with your assumptions
  • And ask clarifying questions. Can I assume the input array is sorted?  Can I assume the input string is not null?  etc.
  • Interview questions are intentionally left vague to see if you pick up on the details or corner cases. (This doesn’t mean that you should get good at trick questions, but it means that you need to have healthy distrust for what you’re given.  Figure out where things might break or where corner cases exist.)
• Get good at picking apart the problems
  • Figure out inputs and outputs
  • Look for exceptional conditions
    • Bloch’s standard exceptions should always be used before custom exceptions when using Java!  Just mentioning them and having some context will get you brownie points with most Java programmers (especially at Google!)
    • Golang has a very specific way of doing error handling.  Know it like the back of your hand.
  • Fuzz the inputs:
    • What if you passed null?
    • What if you passed 0 or “”?
    • What if you passed garbage values (or incomplete objects?)
    • What if you pass in a subclassed item with a bunch of methods overwritten?  (Ok, maybe that’s an extreme example, but you should always be thinking worst case.)
    • ^^ Your code should handle all of these.
  • Look for redundant or unnecessary statements
    • Don’t use two statements to do what you can do with one.
    • Don’t initialize variables for things that are only used once.  Just pass in the value or expression where you would use it later.
• Prepare for the typical non-technical interview content
  • They’re probably going to ask you about something on your resume
    • Please, for the love of all that is holy, know everything that’s on your resume.  Interviewers have a bullshit detector and they will find the fluff and go after it.
    • This is a really important part of the interview – show them passion and drive.  Don’t make it too long because you want to get to the actual coding part, but make sure you can really have fun talking about stuff you enjoy for a few minutes before diving into the code.
  • They could ask you about times you’ve shown leadership or <insert business sounding attribute here>.  They could also ask you to talk about “your favorite project in school or work”
    • Have canned answers ready for this.  Nothing looks worse than not having anything to show that you’re proud of.
    • Use this time like the first bullet point – talk about your passion project. Bonus points if you have a link to a github or something on your resume and you can point them at that.
  • They will probably have time at the end of the interview for you to ask questions to them about the company
    • Try to use these to your full advantage.  Most of the time these legitimately won’t be part of the interview and it’s actually open time.
    • DO NOT ASK FOR STATISTICS OR CONFIDENTIAL MATERIAL
    • Do ask “what can I be doing to best prepare myself for work at <xyz company>” or “what’s the piece of technology that is most important for me to be learning right now?”
    • Show them a passion for technology and a drive to learn more – these things are important qualities in an engineer.

Collection of resources:

• Google SWE Practice doc – HERE
  • This doc is something that they send (or used to send, at least) to SWE interview candidates before their interviews.  They have a great breakdown of things to think about, topics to prepare for, and in the case of Google interviews, what to expect.
  • !!! THIS IS PROBABLY THE MOST IMPORTANT LINK SO IF NOTHING ELSE< READ THIS ONE !!!
• Hackerrank coding practice (or TopCoder, which Google recommends.  I like HR’s GUI better though.  They’re effectively the same thing though.)
  • Specifically the interview prep section of HR.  This site is more relevant now than ever before as more and more companies are turning to automated code interviews like this.  There’s so much to practice on and you can even talk them out while you’re coding if you have a friend who cares to listen or even just a trusty rubber duck.
• Skiena’s Stonybrook data structures lectures.
  • I really wish I had taken analysis of algorithms from this guy.  He explains things extremely well, has a lot of great practical examples / practice problems, and the slides are very well developed.  There’s a lot to be learned from this link, especially if it’s been a semester or two since you took this class and you’re going back for full time interviews.
• Other topics to make sure you know well:
  • Runtimes – know that big-O
    • Remember, things like Arrays.sort(some_array) have runtimes, even if they’re builtins.
    • Know the runtime of typical data structure operations – adds, queries/reads, and deletes
  • Sorting algorithms – As mentioned in the Google SWE prep doc, know AT LEAST two n(log(n)) sorting algorithms (quicksort and mergesort, for example) and know their strengths and weaknesses
    • For example, merge sort can be distributed very well
  • Concurrency / multithreading, induction and math proofs, and system design are all cool things to know and pull out on an interview.  For advanced topics like these at lower levels (intern interviews) it’s much better to just say you haven’t learned that yet and that you’re not going to be comfortable answering a question on it.  The alternative is bullshitting it and I guarantee that’s the easiest way to fail an interview.  Honesty is a pretty solid policy, in this case.

————————————————————————————————————-

Footnotes:  Here’s a bit of insight into the Google hiring process for SWE’s.  From what I’ve heard, Google has the longest hiring process and most other companies won’t put you through anything as long as this.  Make sure that you figure out how long it takes companies to get back to you so that you can schedule all of the potential offer letters at around the same time.  This lets you see who offers you the most.  Supply and demand, etc.

Interns have it easy comparatively, but there are some benefits to the full time process.  The first thing you get if you pass the initial resume screen is called a scaled assessment.  Google added this as a new step in the process sometime in between now and when I interviewed to be an intern.  This takes the form of a 90 minute online coding challenge where you get one easy-ish question and then one main “harder” question.  From the two people I’ve talked to that went through this, the format is very similar to HackerRank and the questions are pretty much the same as you would get in a normal person-driven interview.  

If you make it past this, that’s where the paths diverge.  Interns are then put through a series of two phone interviews leading into a hiring review and potentially an offer.  Full time employees do a phone screen followed by a full day of five on-site interviews.  This is where I believe they have a slight advantage over the intern interviews because there’s a lot that can’t really be expressed over the phone or a video call.  The feedback generated there goes to a hiring committee which is followed by project matching and executive approval.  Once all of that is done, an offer is extended.  Of course, this means the process will be fairly long and there’s a low hit rate, but in my slightly biased opinion, it’s well worth the time and effort spent if you’re successful.

————————————————————————————————————-

Ideas and wisdom contributed by:

Eric M.

Aaron V.