The Social Network Bust: What I learned from my job interview with Facebook

It's good that the author prepared him or herself so thoroughly, but in my experience, someone like Tom Cook would not waste time asking a new candidate how to scale Facebook. That's like preparing for your interview with NASA by studying how they built the Space Shuttle. They know you aren't going to have experience there.

What they want are people who understand the fundamentals of how the computer and the OS works, who can diagnose problems correctly, who know modern sysadmin tools. They can teach you the ins and outs of their macro-scale systems on the job.

> What I slowly understood while I was talking with Tom Cook was that this was not a discussion on scalability on a macro scale, however it was it was discussion of scalability on a micro-scale. I was not prepared for some of these questions, since some of these questions were Computer Science fundamental. It took me a short while to re-calibrate myself, and try not to sound like I was bullshitting my way through an answer, and began some of my retorts with , “From my experience from C programming…”

I wonder if he could've answered, "Oh my, I spent two weeks preparing like crazy for this, but I was working and reading nonstop on scalability, and focusing more on showing you hands on what I can do on collabedit." Maybe he did, but it sounds like he just tried to play it off when the interview went in another direction - if you research/prepare like a madman, my god, you've got to let the interviewer know how dedicated you are and how much you want it. If the interview goes in a different direction than you planned for, you could still possibly guide it back towards what you're strong in, or at least get a mention in of how dedicated and prepared you are for this, and how much you want it.

The author/candidate may have ten years' experience, but he still sounds a little naive:

(1) He seems to have (twice) gone into intensive studying mode without first doing research on what questions facebook was likely to ask him at that stage. He seems to have instead guessed at what they were going to want to talk about.

(2) For a computer geek, the Facebook site/system resembled the UNIX system. And I just love NIX. Wall == wall command on unix. Message == mail. Photo and video viewing permissions was dependent upon groups or individual USER_ID rights. The thousands of external sites using an API to connect to the Facebook internals, reminded me of service ports on a given system.

^ These analogies are not useful from the perspective of actually understanding how facebook works.

Admirably, he has learned from his experience, and is taking steps to correct what he was probably lacking with respect to the position he wanted.

Don't you just love it how often all of us practical programming types who are too cool for school, realise that getting a CS degree/education is pretty damn useful as soon as a real problem comes your way.

From reading this post, it sounds like Facebook missed out on a hire it probably should have made. Commitment, motivation, intelligence, and learning skills are usually more important predictors of how someone will perform in a job than their pre-existing knowledge base. Of course, those things are very hard to measure through a standard application and interview process. At the same time, I am a bit surprised that questions about threads and interprocess communication were challenging for a senior systems engineer with ten years experience. Still, I think if I was in Facebook HR, after reading this blog post, I might decide to give the guy a call back and give him another chance, assuming it really was just his lack of knowledge about some technical issues that resulted in his rejection.

I hope people don't start referring to Facebook as "The Social Network". It's the name of a movie and there's really no reason to use it instead of just saying "Facebook".

I've been in a similar position as this guy, and really-- you never know what goes on behind the scenes when you don't get hired. His feelings about what he may have missed might or might not be accurate. We have no idea what the other candidates looked like. That 20k number doesn't really mean much once you've made contact.

I interviewed at Facebook in the August of 2009. I believe that I'm precluded from discussing the technical details of the interview and any secret sauce I may have seen (N.B. Mark Zuckerberg's office is a fishbowl in the middle of the office.) In the end, they decided not to offer me a position and I believe I'm better off for it. Without any reservations I can say that Facebook employs a lot of extremely bright people -- it sometimes feels like a terrible waste of intellect.

A friend at FB suggested that I apply for a Software Engineer position. I sent in my CV and was granted an initial phone interview with a recruiter. Unlike the anonymous article writer, I went into my interviews cold. After as bit of a funny phone interview -- at one point I answered a question by saying "I have no idea how <thing> works. I'd read the manual" -- I was granted an on-site interview. (It probably didn't hurt that I was in Palo Alto in preparation for some climbing at Tuolumne Meadows).

My first technical interviewer was whip-sharp, having worked with a well known programming language designer. The questions he asked were designed to assess my basic knowledge and problem solving abilities. About an hour after this interview concluded, I was phoned by the HR person to schedule a more in depth battery of interviews the following day.

The next day I met with four interviewers, each from a different group. Two of them were fabulous; enthusiastic and engaged. One stuck me as bored by the whole interview process. I overheard the fourth interviewer outside the room complaining to a co-worker about how his time was being wasted interviewing me. (Gee, thanks.)

Parts one and two went swimmingly. With one of the awesome interviewers, I flubbed an easy algorithmic design question. I set out on the wrong angle of attack, and he did a great job of nudging me back. I made my best of my talk with the grumbly interviewer and worked through an open ended problem that required some domain specific knowledge. Some interview practice wouldn't have hurt, but I don't think that there would have been a benefit from technical preparation.

After a few days out in Yosemite Valley I chatted with my initial HR contact who informed me that FB would not be making an offer. So it goes.

Sorry to keep things vague, I did agree not to give out their interview questions or engage in industrial espionage. If anyone has specific questions, I'd be happy to try to answer them.

What is load exactly? What does it mean? Discussions on threads and processes. How can two processes communicate with one another? [...] I was not prepared for some of these questions, since some of these questions were Computer Science fundamental.

I enjoyed this article, and I rooted for the author to get the job, but I was somewhat confused by this part of the article. Perhaps the questions he mentioned weren't what he considered to be "Computer Science fundamental", but were there just for flavor. The questions mentioned seem more like Unix fundamental -- the load one in particular I ask almost every time I interview a sysadmin.

A nice piece, indeed. From experience both as an interviewer and an interviewee, my favorite set of questions to be hit with (or bring up) are:

1) What have you done and what did you like/dislike about it? 2) What sort of an environment do you thrive in? 3) What is an area that has most challenged you and how did you deal with it?

Specific technical chops are one thing, but anyone who is smart enough will be able to/driven to pick up the areas where they may be lacking. For me, the real test is in what adversities/challenges have they run into/how they articulate it/and how did they get themselves out of it.

Someone who can't tell a story and can't convey how they dug themselves out of a whole will not meet my initial threshold. Specific solutions to specific problems (or brain teasers) that are likely to come up in an interviews provide a very minor insight into who the person is and what they can/can't do. For me, how they convey their experiences will tell much more.

Nice piece. Of all of the take away's from this article, I think the author's outlook at the end is what is most important. Being able to learn and grow from an experience is so important, particularly in the tech field. Regardless of the outcome, no time was lost if it's spent increasing your knowledge base. Kudos.

I find it odd that Facebook solicited an application from the OP and then proceeded to run him through the usual interview process. Maybe that was a result of some FB script seeking more qualified applicants.

Either way, it seems that FB missed out on an opportunity. Scientists don't already know all of the answers to novel problems. And, someone can make a Phd look like an idiot if you quiz them on topics not related to their specific field of study.

Why are established computer scientists forced to take a week to study up for trivia-like interviews? I would expect trivia-like interviews for young professionals straight out of college. But, for more established professionals, it would seem that a "tell me about your achievements" discussion would be more applicable.

Hiring decisions are best weighted on the person as a whole, and less on the testing scores.

Edit: typo fix

I don't think interviewing for highly technical positions at Facebook could be "prepared" for, not especially, by reading so many books about high-level subjects (ex: Visual Basic).

A better approach would be books involving POSIX standards, implementations of all (current) OSI layers, compsci algorithms, how compilers work, and how various runtimes work for various interpreted languages and how to debug them (PHP, Ruby, Python, Obj-C, Java). None of these have anything to do with unix system administration, user permissions, shell scripting, or web servers.

"What I slowly understood while I was talking with Tom Cook was that this was not a discussion on scalability on a macro scale, however it was it was discussion of scalability on a micro-scale."

You maybe misunderstanding macro and micro; scale is a function of both, not one or the other.

Having read many similar accounts of interviewing at Google I can't help but believe the two companies share the same hiring sentiment: they'd rather leave more qualified engineers on the table than risk hiring a bad one. If I were the OP I wouldn't (and it doesn't seem like he does) feel bad about it but instead use it as a determinant in viewing one's granularly-acquired skillset in contrast to the skillset involved in working at one of these gigantic companies. Its a good perspective to have regardless of if you end up working for them or not.

Nice piece. I don't think the writer can be faulted; (s)he prepared quite valiantly for the interviews.

I'd say that someone with the experience and interest that the author had would be exactly the type of person I'd like to interview for the Hadoop opening at Mozilla. Finding someone who is always looking for new things to learn and ways to do so is unfortunately rare.