A Plan to Win your Next Interviewing Battle

In October 2018 I quit my engineering job at Yelp. The 6.5 years I spent working there were amazing in many ways but it was time for me to move on. The purpose of this post is to reflect on my interviewing experience (all of it: preparation phase, interviews, post-interview communication) and write down details/tips. Hopefully it’s useful to somebody out there (you?) but if nothing else it’ll surely be useful for me next time, when I’m on the job market again.

Get cozy: this is a long read. Table of contents below:

1. Lead Generation

First things first let’s talk about how to get an interview. Three main parts: your resume, your network, and other people’s networks.

1.1. Build your resume

There are a lot of strong opinions out there about what should and shouldn’t go into a resume. My experience, both as someone who screened hundreds of resumes and as someone who applied to tens of job postings, is that resumes are at best neutral. If you have an awful resume, you probably won’t get responses when applying. If you fix your resume, you’ll probably get responses and that’s the sweet spot. If you build an amazing resume, you’ll also get responses, but it won’t help you in any other way.

To be effective with your time, do not spend too much time on perfecting your resume. Give it the attention it deserves and move on quickly. It’s much better to spend your time on generating leads, finding referrals, or brushing up on your CS fundamentals (more on that later).

That being said, here are the cardinal resume sins in my book:

Some other tips:

For reference and transparency, here’s my resume. Feel free to open a pull request on Github if you spot something off ;)

1.2. Job applications

Once you have a resume and a web presence it’s time to actually apply for jobs! As a software engineer you have a ton of options:

1.3. Invest in your network

It should be clear from the list above: your professional network is going to be a strong asset when looking for a job. A “professional network” doesn’t have to mean colleagues in the strict sense. Think wider.

I’ve gotten my first internship at Google thanks to a well-connected professor of mine. The timing worked out. Yes I got lucky. What I want you to consider: please take more chances. Go talk to people around you even when you think the odds aren’t in your favor. You only need one of these to work out to make it worth your while!

2. Interview preparation

In this section we’re going over what’s most important: preparation before your battleinterview.

2.1. Hard Skills

2.1.1. Review Computer Science Fundamentals

I’ve written about this previously: I really don’t know why Computer Science Fundamentals are such a big focus in our industry. The reality of interviewing is that they are the most common denominator across companies, roles, and level of experience. Love it or hate it, studying CS fundamentals is the most efficient thing you can do if you are prepping for technical interviews because 1) it’s probably been a while since you’ve done anything with binary trees or linked lists and 2) these questions come up all the time.

So what exactly is considered “CS fundamentals”? Here’s my take on it:

2.1.2. Pick a language & stick with it

“Coding interviews are basically glorified IQ tests”. That’s something I’ve heard directly from an interviewer. I think it’s an accurate statement.

The good news is that no IQ test is perfect and you can “game” the system provided that you know what’s expected of you. What it comes down to is: save as much brain power as possible. The more resources you have to think about the problem itself the more likely you are to succeed in interviews.

Picking a language that you’re fluent in saves you a lot of mental energy. Instead of thinking about the best way (or how) to write a class, or trying to avoid off-by-one errors, practice ahead of time so that a high percentage of your time is allocated to thinking about the problem during an actual interview.

Here is a non-exhaustive list of things to practice applicable to Python (my interviewing language of choice). If you pick another language the specifics between parenthesis vary but the concepts remain the same:

2.1.3. Practice & improve your coding skills

You’ll be judged on more than just pure “coding” during a coding interview. Whether they’re aware of it or not, interviewers will grade you based on:

Because there are so many things you’ll be judged on aside from coding, don’t fall into the trap of practicing on too many different problems. What I suggest instead: pick a problem and try to solve it in different settings, ideally a few days apart.

First practice it in the most comfortable setting: with your favorite IDE/editor. This forces you to focus on the problem itself. Then practice solving the same problem on a Google doc (or somewhere with no syntax highlighting). This forces you to focus on language constructs and syntax that you might be unfamiliar with. Copy/paste the code you wrote into your editor/IDE only once you’re damn sure it compiles/run. It probably won’t and that’s fine! Make a note of the mistakes (more on this in the following section) and come back to your Google doc to re-examine your code. Do this until your code runs! Then solve the same problem on paper or a whiteboard to practice handwriting and space management.

Finally, if you’re interviewing with a company which does whiteboard coding only (Google, Facebook, Amazon, probably others – unfortunately!) try solving a few problems on the whiteboard first while talking out loud as if a person was listening and judging. And time yourself. Afterwards, copy what you wrote on paper or whiteboard and type it in mindlessly in an editor/IDE. Does it compile/run? Does it do what you want? Make note of the mistakes and repeat. Speaking of mistakes…

2.1.4. Your mistakes are your best assets

Something worth buying: a nice notebook and a pen that you like. It’s not that expensive and it should help you a ton. This notebook should be your “mistake” log. Every time you screw up (you expected your recursion to finish but it doesn’t, you made a silly syntax error, maybe your loop was off by one), log that into the notebook and move on.

Over time more mistakes will pile on. Regularly review the contents of your notebook to spot trends: are you making many syntax errors? Do you always forget to declare variables when they’re in a for loop? What sort of problems are causing you the most grief?

I reviewed my notebook once a week and before each interview. This helped me tremendously. Why? Awareness is more than half the battle. There are hundreds of potential mistakes people make when coding but you have your own special weaknesses.

Being aware and actively on the lookout for specific types of mistakes drastically reduces the chance of making them. With a bit of training you’ll spot them as soon as they’re on your computer screen or whiteboard. Eventually you’ll probably eliminate them in your mind, which means entire classes of mistakes/bugs are gone!

2.2. Don’t forget about “soft” skills!

This was prompted by my preparation for Amazon’s and Facebook’s interview processes. Soft skills are really important. Most candidates underestimate the importance of soft skills in coding interviews and do not prepare effectively as a result. That’s good news for you: preparing just a little bit puts you ahead of the pack. It’s definitely worth investing an afternoon or two don’t you think?

2.2.1. Questions to prepare for

Here’s a list of questions/prompts to prepare. I gathered this list as I went through interviews. Being prepared for those will get you 95% of the way there and you probably won’t feel surprised by any “soft” questions anymore:

Finally, prepare a big list of questions for non-technical folks and technical folks. You should have enough questions to last a whole lunch break with either type of people (I’ve found that 10 questions is generally more than enough).

2.2.2. Tips for good long-form answers

These tips (in italic) are taken straight from Amazon’s “in person” interview preparation guide that you can find here:

2.2.3. Craft & refine your story

This has already been mentioned in the previous section but it’s worth calling out on its own: you should have an answer to the dreaded, classic questions: “What brings you here?” and “So why don’t you tell me about yourself?”.

This deserves special attention. Look at yourself in the mirror, ask a friend to tell you what they think, and perfect your answers until you feel confident.

If you’re transitioning from one role to another (say backend to iOS development, or from marketing analytics to engineering), it’s worth crafting a compelling story and be ready to answer “so why did you choose to switch from X to Y?”

Important note: crafting a story is different from lying. Don’t say things that aren’t true. Don’t try to embellish what happened. Do think about where you’re going to start, what you want to convey, and how: what do you want the listener to take away from your answer to these question?

3. Interviewing tips and tricks

3.1. The interaction Log

I kept a log of all the communications I had with every company, regardless of the stage. Here’s an exerpt for a company didn’t move forward with:

Interaction Log Excerpt

I had to redact a lot of it, but the general structure holds. Some things worth pointing out:

3.2. Planning

Planning is one of the most crucial aspects of a job hunt. Put everything in one calendar (I used Google Calendar) and be very diligent about keeping track of who is supposed to call you when. Set reminders to prepare for the call, and take notes!

Another tip that I can give here: try your best to line up interviews that you care about least first, and the ones that you care about most last.

3.3. Tips on video or phone interviews

3.4. Tips on on-site interviews

4. Interviews are over. Now what?

So you’ve gone through your interviews and hopefully have gotten far enough in the process that you’re stressed and unsure about what to do next. Negotiating your salary and committing to a decision is no easy task. Below I’m laying out my experience with both of these. I’m offering some of my personal criteria to evaluate each company and some tips about offer negotiation. Ready?

4.1. Making the most out of your recruiters

4.1.1. Email tips

4.1.2. Expectation management

Be as transparent as you can about your timeline from the beginning. In my experience there isn’t much benefit to information asymmetry. Recruiters are your best allies: the more they know about your particular set of needs, the better off you’ll be. Why are they allies? They usually have financial incentive to meet hiring targets. You get in the door, they get paid, both of you are happy!

Along the same lines: be very diligent about informing your recruiter(s) about changes along the way. I found that having a list of names/emails for each company helped immensely (you don’t have to think hard about who to email when something changes if you have one place where everything is). I kept track of this as part of my big “interaction log” document (described above).

4.1.3. You have more power than you think

You have a lot of power as an engineer looking for a new job. The market right now (2018-2019) is as good as it gets. Don’t be a jerk about it (obviously!) but be aware that you can ask for a lot. Asking nicely will get you most of what you want, so remember to ask! This is especially important when it comes to…

4.2. Offer, compensation, and negotiation

A couple of links on the subject of negotiation:

The above resources will do a far better job than I can at teaching you about salary negotiation. A few things I’d like to stress:

4.3. Making a decision

There’s a ton of criteria to evaluate when picking a job. It can get emotional and overwhelming so I’ve used this spreadsheet to be as rational as possible. Columns are criteria you care about (compensation, quality of manager, technical stack, etc). Each of them is of a certain importance to you and that’s reflected by a weight (from 1 to infinity). Rows are companies you’re considering, and each company gets a 0-10 score for each column. The rightmost column displays a weighted sum to help you compare easily and see which company comes at the top.

What should you care about even? What should the weights be set to? Well that’s personal. But here’s my opinion: a job is mostly made of people. Your manager and teammates are crucial. You’re going to spend 40hrs+ per week interacting with them. Make sure you consider this very carefully. A great compensation and a kick-ass brand won’t save you from a lousy manager or a toxic team. So weight this accordingly.

Another piece of advice that I’ve heard from mentors and colleagues: focus on learning and growth early in your career. Weight compensation lightly if that’s possible for you to do.

Now how do you actually go about evaluating your future company, manager, or teammates during your interviews? Obviously it depends. Teammates, managers and engineering cultures are all made of people. A manager who feel awful to me might be a great fit for you. Below are my personal criteria to gauge these things. I encourage you to develop your own and write them down.

4.3.1. Evaluating your future manager

I hate micro-managers. The absolute worst manager would be one who’s constantly looking over my shoulder and my teammates'. In a manager I’m also looking for somebody who’s 1) cool-headed and 2) who can be a good “shield”. Concretely this means somebody who’ll fight to keep the team focused on a minimum number of projects, and who will switch priorities only when absolutely necessary. The third thing I’m looking for: someone who can coach, be understanding, and listen.

It’s hard to probe for these things directly but I’ll tell you my personal opinion on what you can look for in an interview setting.

The person you are talking to is more likely to be a bad manager if they…

And here are some positive attributes. The person you are talking to is more likely to be a good manager if they…

4.3.2. Interviewing teammates

Teammates are a bit easier to gauge. What makes an ideal teammate to me? Somebody who’s willing to spend time to show me the ropes and obscure tips to boost my productivity. Somebody who’s willing to say “I don’t know” and learn from me when I can teach them something they don’t know. Somebody who’ll happily take ownership of an idea that isn’t their own. Somebody who says “hi” when you cross paths in the office or outside (a nod of acknowledgment and a smile goes a long way). Somebody who admits to making mistakes without trying to cover them up.

How to evaluate this when you’re talking 1-1 to someone? The person you are talking to is likely to be a bad teammate if they…

Conversely the person you are talking to is likely to be a good teammate if they…

4.3.3. Gauging work culture

Work culture constantly shifts within a company. Very often it’s not consistent across teams. Heck, you may change and consider a culture “cool” now and “awful” in a few years. That’s certainly happened to me.

At the time of writing my ideal work culture offers a good work-life balance. I want to be able to sleep and spend weekends 100% disconnected when I feel like it (if I’m on-call, fine – that’s a planned thing). I value work cultures with an emphasis on social good will (help each other, be positive, teach/learn from your neighbors, etc), (self)-education and transparency. See this post for my values overall.

Now onto how to evaluate this in an interview setting. Some of these criteria are self-explanatory; others require that you ask specific questions to your interviewers. Most interviewers reserve some time at the end of their interviews specifically for this. An immense majority of recruiters are be happy to set up additional calls if you didn’t have time to ask all your questions. Without further ado, the company you’re interviewing for is likely to have a bad culture if:

Conversely what I’m looking for; the company you’re interviewing for is likely to have a good culture if:

4.4. Reflection on interviewing pipelines and processes

I’ve been through a few interviewing pipelines recently. Below are some really good ideas I’ve seen implemented in the wild. If you’re a recruiter or an engineer in charge of some part of a recruiting pipeline, this section is for you!

4.4.1. Automatically graded coding test

This saves a ton of time, and can often replace an expensive and biased (because it involves the judgment of a single person) “phone screen” or “video call” with an engineer.

While we’re on the subject of coding tests: some companies opt for a “take home assignment”. In my experience this can be a good idea but make sure to set a strict time limit (target under an hour – if longer than that a lot of good candidates will lose interest) and grade the test based on objective criteria established ahead of time.

4.4.2. Realistic interviews

During on-site interviews: focus on what’s difficult to assess! In my opinion, on-site interviewers should steer clear of coding questions as much as possible. The best way to know whether a candidate would be good to work with is to simulate working with them! Try pair programming. Try whiteboarding systems. Try simulating the experience of finding/fixing a bug together! How about reviewing and discussing a piece of real code?

Quite frankly I don’t understand why this isn’t more common. The fact that Google, a company I deeply admire for their ethos and ability to innovate, sticks to whiteboarded algorithm questions (for the most part…they do have design questions for senior engineers though) is baffling.

4.4.3 No-surprises interviews

Interviews do not have to feel like taking an exam. Why not communicate the names of the interviewers, their teams, and rough subjects of the interviews ahead of time? When I’m working on something new at work or when I’m called to go to a meeting with a new group, I’m given notice on the agenda and topic. I see no reason why interviews should be different.

A bad schedule example:

  • 9am: meet and greet
  • 9:15am-10am: coding interview
  • 10am-10:45am: coding interview
  • 10:45am-11:30am: design interview
  • 11:30am-12:30pm: lunch break
  • 12:30pm-1:15pm: coding interview
  • 1:15pm-2pm: coding interview
  • 2pm-2:15pm: wrap up

A better example:

  • 9am: recruiter will meet you in the lobby and walk you to your room for the day
  • 9:15am-10am: coding interview with Sarah, engineer on the Payments team. This will focus on tree-like structures and performance
  • 10am-10:45am: coding interview with John, senior engineer on our Infrastructure team. Focus will be on caches in the context of web applications as well as code quality
  • 10:45am-11:30am: design interview with Jane from our data science team. You’ll get to talk about data pipelines and associated technical trade-offs
  • 11:30am-12:30pm: lunch break
  • 12:30pm-1:15pm: coding interview with Noah, engineer on the Platform team. This interview will focus on finding a bug in one of our internal web frameworks used in our microservices fleet
  • 1:15pm-1:30pm: wrap up with your recruiter, to shield questions and escort you out of our HQ

Sure candidates will study ahead of time. But that a good outcome! I’m betting that this would lead to higher-quality interviews overall and a better experience for both candidates and interviewers.

5. A final offering: my personal TODO list

To conclude this blog post (that’s the last section! Good job making it this far!) here is the precise list of things I did to prepare myself for interviews at the end of 2018. I interviewed for backend/full-stack software engineering positions, with Python as my language of choice whenever coding was needed. This list may not be as useful if you’re interviewing for something vastly different.

Below I graded each item from 1 to 10 with the power of hindsight (“Looking back, was this item useful for my interviews?").

Items related to interview prep in general:

Items related to CS fundamentals:

To prepare for backend/systems questions:

To prepare for design interviews:

Do not fit in the above categories (miscellaneous):

Finally, what I did not do (the items left on my giant TODO list basically). I will never know if these would have been useful to do or not…but here they are anyway:

You made it. You’re a hero. ♫ This is the end ♪.

To Ryan N. and Jon L.: thank you so much for the valuable feedback on early version of this article! You rock ❤