There is plenty of information on the internet about getting that job at {web-scale firm here}, this post starts a series about all the information I amassed whilst preparing. In addition, I have personal advice about what to expect when interviewing, which is especially useful if you haven’t interviewed for one of these companies before.

First go buy the wondering “Cracking the Coding Interview” by Gayle Laakmann McDowell. Read the book. Read her answers on quora, read her careercup site.

I wont repeat what is written in that book, and elsewhere, but I’ll try to add what I discovered. It’s kinda huge, so I’ll break it into several follow up posts, this one covers some general notes:

Timeline

First of all, expectations. Lets assume you’ll read this post, and the rest of the series, but wont delve into details.

Just look at the volume of questions in Gayle’s book. If it takes you ~15 mins per question, and there are 189 questions, then that’s 48 hours of work. If you are only doing 2 hours / week, then that is 24 weeks / six months right there. That doesn’t even include other questions!

Do not imagine that you can do this in a short time, this isn’t even just a couple of months work. This is like weight loss, you can’t just go on a crash diet, you need a lifestyle change. It’s common for medical doctors to spend time each year working on their professional development. Software engineers need to do this too.

Don’t start scheduling interviews; even phone screens; before you are close to being ready.

General Advice

In addition to the book, most companies will email you some advice on preparing for their interview; read it.

In addition to that, there’s professional sites like Interview Cake that will coach you for a fee.

It can be cheaper, and more effective, to get a friend to help you. If you are currently not looking for a job, you should consider being that friend, as it’s a great way to keep your skills sharp.

Tech Interviews

There are so many posts out now about how tech interviewing is completely broken, I think it’s like that Churchil democracy quote:

Many forms of Government have been tried and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.

i.e.

Algorithmic coding interviewing, is the worst form of recruiting, other than all others that have been tried.

In fairness, it is just a system that prefers false negatives over false positives. If you are willing to fire fast, that is also a possibility for your company, but that seems really brutal for the candidate, who must have rejected their other offers. I think this interviewing style really started in the valley after Google posted its Lake Wobegon Strategy hiring strategy, and a lot of other companies began to emulate it.

While everyone says:

We just want to see how you think!

What they really mean is:

We just want to see how you think, as you get to the exactly right answer, as quick as possible.

Do not kid yourself, it’s an exam that has “must show workings for full credit” at the top of the paper.

According to some reviews out there, some companies even say “this is an exam, we know all the past interview questions are out there, and you are all looking at them”.

So you study, and practice with friends at the white board, but what happens if you get the past exam paper!

Honestly is probably the best course of action here. The interviewer will get zero signal if you just knock out a perfect answer, and will view you as dishonest.

Wait a minute though! Sure, you remember that question because you did it recently, but how well? If you say you know it, and you are tested, you’d better be certain, because a poor performance here is going to make you look arrogant or a fool.

Looks like you can’t win here, so what to do?

Start working through the question, if it seems really familiar, mention you did something “similar” last week, but you want to see if you remember all the pieces correctly. Remember to explain as you go along (show your working).

Prep Classes

It’s so bad out there that companies are even running prep classes.

Facebook runs a 2 hour (on-site/online) class with Gayle that is really useful. It’s probably a good idea to buy her book first and go over the first few chapters. Of course if you go in person, you can even score an autograph!

Google does a 1 hour prep class. That’s really short, and doesn’t cover half as much that you need to know as the 2 hour FB one, but they do make you peer-program on the board, so you do get that real “fear” feeling.

Your Situation

If you are a recent CS grad, you can really do quite well at these tech interviews. You’ve just got to review your entire degree, and you should be good to go.

For everyone else, in addition to revising your entire degree…

…if you have up to 10 years experience, it’s not going to be so bad, there will be a slightly larger focus on “non-abstract large scale system design”, but it will still be a smaller part of the interview process.

…if you are more than 10 years into your career, you are going to get almost 50/50 design questions, or more! There’s hardly much information out there about this interview process, so it’s much harder to prepare for. The site interviewbit does have a couple of examples, as does Gayle’s book, and if you look hard there are a few other blog posts out there. I’ll make a post specifically about how to prepare for these interviews.

Behavioural Questions

This topic is talked about, but I only saw it in just under half the interviews I did. There’s some material out there on questions, and plenty in Gayle’s book.

Even though the topic is smaller, remember to practice with a friend. You need to be able to listen and remember the question well, and phrase complicated scenarios clearly.

Don’t try too hard to be “funny”. Remember that the person doing the interviewing doesn’t know you personally, you need to avoid red flags here.

Make a note of the stories that come up when you practice, perhaps even record yourself, so you can see how it comes across.