I’m graduating this semester, meaning I spent the better part of last four years job hunting. Three internships and a full-time offer later, I’ve had a lot of interviews, and thought it would be a good time to write down my experiences and thoughts on the state of talent acquisition for tech. One important thing to know about tech interviews is that, like the jobs they seek to fill, they are constantly changing. There are books written solely on the topic from both the interviewer’s and the candidate’s perspective.

As far as experience goes, I’ve been through roughly 50 interviews thus far, including ones at all of the big 5, and seen a wide assortment of questions. Since I was interviewing for either internships or entry-level positions, the questions I received were tailored appropriately. Here is my categorization of most of them, as well as some opinions on their efficacy, and some gifs.

Sanity Check

Example: Fizz buzz. Merge two sorted lists.

This was often the first question I got in the interview process. It’s solvable with just a basic knowledge of programming constructs and algorithms/data structures. It’s serves as nice way to ease the candidate in and ensures they weren’t completely lying in their application. Failure and success are very easy to tell apart, and even an untrained interviewer should be able to ask and judge a response to this kind of question.

Generalist

Example: How would you build Amazon. Give languages, frameworks, etc.

I only received this kind of question once, but I found it very interesting and think it should be used more often. It gives the applicant the chance to show that they are up to speed on the latest development trends outside of the classroom. The interviewer can propose alternatives to what the applicant suggests to see what reasoning they are using, and whether or not they are open to new ideas.

Changing Constraints

Example: Find the average value of nodes in tree. Now do it without overflow errors.

If I were only going to ask one interview question, it would be one of this kind. It starts easy. Almost as easy as fizz buzz. After the candidate solves the most simple case, the interviewer adds constraints or edge cases that the existing solution doesn’t account for. Often explores trading time for space complexity. Nice because it mirrors the changing requirements and constraints of real world development. Also eases the candidate in to solving a complex problem by letting them solve the easy version first.

Puzzler (aka maybe you read it in Cracking the Coding Interview)

Example: Count inversions in a list. Detect cycle in linked list.

This is a far too common programming question at the big competitive firms. Others have written longer, more in-depth denouncements of it than me, so I will just let them speak. In short, either the candidate has heard it before and will be able to regurgitate the answer verbatim (proving that they either studied hard for the interview or got lucky), or they have not heard it (proving nothing).

Weird

Example: How many ping-pong balls fit in a bus

These are the ones that Forbes thought it was so fun to write about in Google’s early years. They’ve pretty much completely fallen out of vogue, insofar as I’ve yet to get one of them in an interview.