My Google interview a few years ago was very similar. No matter how confident you are, it's amazing how nerves can cause you to stand there at the whiteboard babbling like a newborn.
Google actually had me do two on-site interviews (one in my hometown and one in Mountain View). The first one went very well. I had a great rapport with the (single) interviewer, and had fun solving the (single) problem he gave me.
The Mountain View interview went more or less like the one described in the article. Marathon style. Had good rapport with some of the interviewers, less so with others. Once you start stumbling your confidence starts to fall apart, and it can really hurt you for the rest of the day (the interview lasted all day).
I also didn't exactly end up with the job. They offered me a testing position with "fast-track" promotion to engineering. I passed on that.
Good advice in the article though: practice problems on a whiteboard at home or with friends. Especially fundamental problems that you learned in your first algorithms class and the like.
Yeah, when was the last time you wrote code on a whiteboard when you WEREN'T in an interview? Definitely good advice, but I would caution that it's just an interview skill, and only serves to improve your performance rather than your content.
Also, you should remember from your test-taking skills that time asleep is more valuable than time studying. Thus, as pointed out, you should really make sure you're well-rested.
"Reading the technical questions made me realize how crappy a programmer I am, algorithms-wise"
The good news is that this is very fixable.
I could answer the questions in the article without effort but this is a very different situation from about 3 years ago when I wouldn't have been able to answer even one of these.
I really started hitting the Algorithm books(Skiena, Cormen, if anyone is interested ) about three years ago and am now comfortable with thinking "algorithmically" - at least for sequential algorithms.
Studying algorithms to a fair degree of competence is very feasible even for non CS folks - I have no degree in CS and am entirely self taught. The tough part was working through proofs - As I was reading about unit tests for the answers , either in the original article or the reddit comments, I forget which - I was thinking it might be better to write down a formal proof that the algorithm works.
If I face tough questions on parallel/concurrent algorithm, I'd probably take a while to answer or fail completely - I need to look into parallel/concurrent algorithms in the coming year.
The interview process is definitely an intense one in this field. One thing to keep in mind when you're answering technical questions is that the interviewer is just as interested in hearing you think out the problem as they are in hearing the right answer. Thinking out loud is sometimes a good strategy if you run into a problem you can't answer on the spot.
This is hard to read because they specifically asked for a short line count, but it's not really very complicated. an if/else, a map, and a recursive call. Could maybe do the string manipulation more cleverly, but the obvious (assigning a new string to an index) is destructive in ruby.
With all the institution name dropping, somehow I suspect a weaker candidate from a big(ger) brand name university would be hired over him and his main chance was to measurably prove he was better at programming, which sadly he failed to do. We all have our bad days.
Also, I really dislike the fact that FaceBook have yet to reimburse him, even after having >1year to do so and especially considering they have $MM and he was a student at the time! It reminds me of an interview I had at MXTelecom years ago, a company with ~40 employees that generated >$120M each year, which refused to reimburse interview expenses until "after" the interview process for them (read several weeks) was complete and which never did. Moral of the story: always be clear about payment of expenses before attending interview (especially if you are a student - do not be afraid to clarify and if need be force the matter), and chase up what you are entitled to.
didn't at first want to work for facebook because he thought it was a toy, but was eventually persuaded and now loves it
...
Apparently he's responsible for the "Gift" feature in facebook (you know, the hole-in-a-box/heart/pantie/etc. little graphic you can gift to people?). He was the sole person responsible for that.
Fight fiercely, Harvard. It amazes me that code-up-a-copycat-in-a-weekend websites like facebook think that they need 1st rate engineers.
"It was either the little graphic gift heart, or control systems for helicopters..."
Control systems for helicopters are developed by soulless clock-punching factory workers, marching to the slow beat of enormous, impenetrable bureaucracies under the iron fist of stifling, heavyweight processes. Inquisitive engineers need not apply.
No, you need first rate engineers to come up with stuff like this: http://en.wikipedia.org/wiki/Kalman_filter or this:
http://en.wikipedia.org/wiki/Phase-locked_loop. I'm sorry, but a scalable web friend contact app is not first rate engineering. I found it funny that they had such rigorous requirements for something so mundane as well. Pearls before swine, I suppose.
I think the end (goal) of Facebook is not exactly a noble one but the means can still be impressive. Managing 110 million users (or 110 million of any high-maintenance node for that matter) is no picnic. Their engineering blog has some pretty interesting stories about the challenges they have faced.
If you are into changing the world by willing society forward with ground breaking [insert impressive thing here], your talents would be wasted at Facebook (despite Mark Zuckerburg's stated belief that fb can change the world by allowing people to share with each other and understand each other better).
I think they are solving complex problems (which is respectable) for a largely trivial mission.
Would you say that Google does not require first rate engineers? I would imagine that the most important part of their operation is scaling. They have admitted themselves that the difference in search results returned by the search engines is virtually nil, so their strategic advantage is really being able to support a lot of users (for the search engine as well as other internet services).
It depends on what you mean by first-rate. I mean, developing the sorts of things the parent mentioned requires a lot more talent than writing an app. But, to be fair, that requires an incredible amount of skill. Most people, including bright and capable people who work hard to learn, won't ever do something like that. But I agree that the people at Facebook, if not all revolutionary and brilliant, are all pretty damn good at what they do. Beyond scalability, too: Facebook has got more small little quirks that go towards usability than any other site that I know. Then they make a redesign that renders all those small quirks pointless because the new layout is vastly easier. Then they introduce more quirks.
The first time that I wrote a long message and saw the message window expand, I jumped with excitement. It was pretty awesome to find a new feature one day that I didn't expect and never would have thought to ask for.
I think that if people don't call fb engineers first rate then they have to refrain from using that label for many very good engineers (I used Google as an example in my last comment).
I am just reluctant to say that engineers at fb are not first-rate. Are we saying that they are second rate?
That's exactly the problem that I had with my comment. They're only not first-rate if you expect every engineer to be literally genius. That's too much to expect for any one company. So first-rate is as close to accurate a description as you could get.
I've always found it odd that not many hackers that I've met really get into discussing video game mechanics: either hardware or software. It's odd because video games are what got me into programming software, and the only time I've ever felt like making hardware it was designing imaginary game systems.
I agree with Kalvin above. They've had to do a lot of work to keep facebook running smooth and snappy, incorporating many different technologies. And luckily they are open sourcing a lot of their technologies! =]
White board problems are killers, no matter how well you know your stuff. I definitely advocate this too.
I'm interested if anyone else here has interviewed at fb, I'd love to hear more about this as I'm working out solutions to their programming puzzles too.
Facebook definitely sounds like a decent place to work. Them and Google are places I hope to take influence from if I ever make it to having an actual physical office space :P
Google actually had me do two on-site interviews (one in my hometown and one in Mountain View). The first one went very well. I had a great rapport with the (single) interviewer, and had fun solving the (single) problem he gave me.
The Mountain View interview went more or less like the one described in the article. Marathon style. Had good rapport with some of the interviewers, less so with others. Once you start stumbling your confidence starts to fall apart, and it can really hurt you for the rest of the day (the interview lasted all day).
I also didn't exactly end up with the job. They offered me a testing position with "fast-track" promotion to engineering. I passed on that.
Good advice in the article though: practice problems on a whiteboard at home or with friends. Especially fundamental problems that you learned in your first algorithms class and the like.