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.
To expand on your point, They aren't looking for people who know the current bleeding edge (in scaling, say). Instead they need people who can continue to define the future bleeding edge.
This doesn't make any sense to me. You can't take a shortcut around understanding the systems as they are now.
Also, it's not clear to me that in this case they were even trying to find someone to be so bleeding-edge. They also need sysadmins to do other kinds of work -- fight fires, deal with adding servers, handle local IT, administer testing environments, and so on. If they are looking at people with the OP's background I'd hazard it was more about the latter.
More likely a subset. Just because you can read up on what other people have done and implement their ideas, doesn't mean you can come up with your own, better, ideas.
I don't know. Taking in the context of this discussion, it would mean someone with vigor and no understanding of basic CS concepts can come up with breakthrough in distributed computing. This is in spite of tens of thousands smart people who actually know the stuff and been researching it for years standing where they are now.
Just does not sound very probable.
EIDT: OK it's not quite what you've been arguing about. Yes, not everyone familiar with the field is going to ever push the envelope. My point was that the chance of an outsider there is quite small.
I think that was my point. Understanding the cutting edge within the field is necessary, but in no ways sufficient, to have what it takes to push the envelope. And if you need to hire someone to push the envelope then you need to look beyond simply what they know when hiring.
> 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.
Companies - even ones that use the "false negative is better than false positive" heuristic - would also rather that you ask enough questions and adapt them to the candidates background so that you can rule out "false" anything.
This can work if you really are an expert at something but just got a bad interviewer or bad interview question. The tricky part is that you have to be an expert at something. I wasn't really seeing this from the author's blog post - experts typically wouldn't go for a bunch of blog articles and YouTube videos to learn more than a cursory overview, they'd look for the source of existing open-source libraries and implement a couple projects on their own.
There's also something to be said for specifically targeting areas a candidate is not strong with to see how they handle their weakness. If you clam up, get defensive, or try to bullshit your way that's an automatic fail from my perspective. I don't want to spend 8 hrs/day working with any of those 3 personality types.
I've interviewed a lot of people, but I've never seen one that didn't BS just a little bit.
What annoys me is outright lying, like saying on your resume that you worked on some cool-sounding project, but your role was to get coffee for the people doing the actual work. What annoys me more is that when you do the same thing, but with something that doesn't even sound cool, like "converted a database to a CSV file". (I am not making this up. I saw this on someone's resume and thought, "hey, at least they're honest... maybe we can guide them towards being useful". Nope. The candidate had clearly never even typed code into a computer before.)
Interview questions I find relevant:
* reverse a C string
* what do you hate the most about your favorite language
* if you could spend a week trying something new, what would it be
* what projects are you working on in your own time right now
It is amazing how poorly people do at the middle two. Getting the first one wrong, I can understand -- you have to know how to program, and most companies will hire bad programmers if they can BS a little. The last one, fine, you have a three hour commute and eight kids, and you don't even like programming or making things.
But really... you can't think of anything you hate about your favorite language. Do you ever write any code? Nothing? Not one single, solitary thing? Nothing annoys you in the slightest, tiniest bit? LIES.
And... you can't come up with some BS about what you want to learn? You have no ambition in your life? You care so little about your field that if we gave you money to learn something, you wouldn't do it? You're not curious about "Web stuff"? You have no interested in Scala? Really? Really?
The second and third questions are particularly mean in an average interview environment, whereas they are incredibly easy in a relaxed environment.
It's really really hard to think of stuff like that off the bat, sure in an hour long friendly chat I'll probably complain about many things in languages, thus answering your question. But if you straight ask my mind goes blank thinking "Huh ... well I could complain about a lot of stuff, but what is THE thing that bugs me ..." see, ordering by priority is very difficult to do. First one has to decide what their favourite language is (very difficult for programming polyglots) and then what the most annoying thing is.
That's hard.
Same goes for the third question. Well if I have a week to learn something, what on earth should I pick!? There's so many options, how many are really viable for a single week. And what would I like not to learn because I'm learning this. Again, prioritisation is hard here.
I think it all boils down to the fact that those two are BS questions.
> "I think it all boils down to the fact that those two are BS questions."
Useful if your goal is to hire people willing to put up with BS and looking to put their own BS skills to work within your organization.
At a deeper level, the problem is that a person who actually hates features of their favorite language is likely to be miserable using the one their job requires, and a person who views languages as a tool for getting things done (rather than tribally) can't give an honest answer. A better version of the second question might be, "Are there any technical shortcomings within your favorite/current language?"
Likewise many honest answers to the third question are entirely inappropriate within an interview, e.g. "I'd like to try a nudism for a week." A better version is quite possible. For example, "If you could try any other position within our organization for a week, what would it be?" is open ended, relevant to the context, and provides useful feedback about the candidate's career and growth objectives.
I mean, if I had one week to learn _anything_ I'd probably pick sky diving or rally driving. I can learn about the stuff I do every day, well, every day. That one week should be special, something completely out of what I currently know how to do.
It's easy if you've coded enough to know. I hate the fact that in Python, to reverse a string, I have to do slicing:
string[::-1]
In Ruby, I can do string.reverse() so that makes me hate that about Python, well... that and a few other things, but otherwise I love it.
I think he's looking for knowledge enough to know what you would do differently if you could change the language. Otherwise, you're not interviewing a qualified person.
Out of curiosity, how long does it usually take people to answer the second question? I'm talking about good candidates, not people who don't code.
I'm asking because I've actually seen this question mentioned before, and each time, I spend some time thinking about it (as applied to Python). But it honestly takes me some time to think of problems with Python; not because it's perfect, just because I don't spend every day thinking "hey why can't it do this".
Anonymous functions in Python are what immediately popped into my mind. I do embedded work and mostly use C, but a lot of the problems with C actually make since when you have less than 1 kB of RAM. I'd prefer to use Lua for building test applications and the like, but I keep going back to Python because the library support is tremendous in comparison.
In any event, I think the question of what problems you have with your favorite language is at least a good conversation starter. It would be nice to know that those kinds of conversations are easy and interesting to a candidate. Although, that isn't necessarily a requirement.
I use Python mostly, and I was asked this in an interview question (shortly after being asked if I could enumerate the differences between 2.6 and 3, when I said 'quite frankly no, I'm building a real world app and focused entirely on 2.6 at the moment since migrating to 3 isn't an option').
I was actually working closely with Django so ended up listing things I disliked about Django rather than Python itself. I think one of the easier ways to answer would've been with a Javascript/C/ML/Lisp hat on - was chatting to someone at the weekend who was totally against the space-indentation, for example.
Python has it's share of warts. Its automatic memory management is not a modern GC, it involves reference counters that are slow, take up memory and don't play well with copy-on-write semantics of modern virtual memory managers. Its functional programming support is half-hearthed, its implementation is slow, there is no optional static typing, the GIL sucks. And yet it's the best programming language for me - the others are worse.
Don't ask these questions. Okay, ask the first one. Throw away the other three.
I have also interviewed (and hired/not hired) dozens of people at several companies, some small start ups and others massive Fortune 500 companies. I've also judged collegiate and high school interview competitions and been through several corporate hiring and interview training programs.
This is not meant to say anything about me, personally, it's that I have learned that almost no one in start ups or even large companies have any education about hiring. Almost everything that we see routinely practiced is done by folk-wisdom, 'feel' and common group think.
There's only a handful of questions that any interview is intended to determine:
1. Is this person QUALIFIED to do the work (easy to figure out)
2. Will this person DO the work (not as easy to figure out)
3. Will this person actually fit in here (very hard to figure out)
Go back and re-read the interview question above. #1 is a pretty basic programming question. But what are you expecting from #2, #3, and #4? What are 'right' answers? What are 'wrong' answers? Are you trying to get a sense of who the person is?
Why wouldn't a smart person just lie to you? These questions are easy to BS. What am I working on in my spare time? I'm building a neurolinguistic interpreter to decipher real time requirements gathering. Or, whatever else I can conceive of in the two seconds between the time you asked me and the time I spit it out.
Recent college grads are adept at these BS answers by the way. People who have a lot of experience are likely to wonder why you're asking such off topic questions.
The key is that these questions lead to good follow-up questions. "Oh, you don't like memory management in C++? How do you mitigate the downsides?" "Neurolinguistic interpreter? What language did you use? Walk me through the core algorithm."
These always help with your #1 and #3. Nobody ever knows if anyone will do the work, but it's pretty easy to determine whether or not they'd be able and how they'll approach it.
Couldn't agree more with the relevant questions. Especially the first two. Show me you can write some simple code and show me you've pushed a language far enough to get frustrated with it in some non-trivial way.
Of course, after questions like that you still have to figure out whether someone will actually get s* done. That's another matter, but hopefully you can get a feel from their enthusiasm.
Maybe you need to put yourself on the other side of that interview.
* What is my favourite programming laguage...?
I don't hate anything about it because, you know, if I found it annoying then it wouldn't be my favourite language anymore. Maybe it's just a personality thing, but I personally don't settle just so I can say iI have a favourite.
Most of the time I would spend answering that question would be taken up by me thinking which language I liked the most and that'd (at the moment) be Lua and only because it's very small and I can feel like I understand most of it. The only thing I find annoying about it is that it's standard library is small which means I have to rely on third-party libraries but that I think is necessary for me to actually like it more than Python which is so huge that it just doesn't feel very fun to write anything in. Many people might say the fact that it doesn't have classes. It does however support OOP via prototyping, I just see it as different, not a disadvantage and it actually fits very nicely with the laguage, possibly better than classes would.
* I'd say write a couple short stories. I have enough unfinished projects, why would I want to waste a week either starting a new one that I won't finish in a week or continue on an old one that I also won't finish in a week.
I wasn't asking... but your first answer is fine, and the first sentence of the second answer is also good.
why would I want to waste a week either starting a new one that I won't finish in a week or continue on an old one that I also won't finish in a week
I would keep this to myself in an interview. The reason you work on your own projects is to structure some learning; sure, there is some finished product that you want, but there is also the experience of making something that's important. You can't learn programming if you don't do it, and the usual 9-5 work environment is 90% distractions and 10% actual programming. So to be the best among programmers, you need to supplement your 9-5 job with something that's 100% programming and 100% you.
The reason I work on my own projects because I enjoy doing them. Why does everything have to be for "structured learning"? I bet you learn and discover more just randomly fiddling around....
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.
Martial arts analogies too. Someone who uses "kung fu" metaphors has seen The Matrix one too many times; I never hear it from people who actually do do a martial art.
"Kung fu", translated literally from the Chinese means "hard work". So you may be misinterpreting the writer's intent. He didn't strike me as some pseudo-martial arts meathead.
Perhaps you've never heard someone use the word kung fu to describe their martial art, because their art wasn't of that particular Chinese tradition?
Personally I thought the writer's usage was apt, given that he had newly dedicated himself to a difficult path of work.
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.
Your smugness disagrees with me. In my personal experience, I covered the basics - analysis of algorithms, graph theory, the usual data structures, operating system architecture, parsing & state automata (DFA, NFA, PDA etc.) - long before I went to college. You risk tarring all autodidacts with the same brush.
And let's not forget, there are plenty of CS graduates who conversely aren't very good at programming.
Well I have a CS degree, and I value it quite a bit, but honestly it's a second order concern in industry. The first thing is, can you write and debug code in a production environment? This is something that university just doesn't teach you; as long as you have the intelligence to understand the theory, the professors will prod you in the right direction on the assignments.
Now, once you can code your way out of a paper bag, then the question is do you have the CSCI fundamentals to apply the best known solutions to difficult problems. Facebook has their pick of the litter, so it makes sense that they might spend more time validating CSCI knowledge, but for most companies that are hiring this would be a very poor metric to go by.
While this is true, I have never needed to explain CS stuff in an interview, it is also true that very often when faced with a tough algorithmic problem even the little CS foundation my few years of formal education in the field have granted me helps quite a bit. If nothing more than the fact I know what to google for.
It's surprisingly easy to google for solutions once you know what you're looking for instead of searching descriptively :)
Ha, you said it man. Looking back I began to realize that this was the biggest benefit of my degree.
Technically, a homeless person could dig in at a terminal in the library and teach themselves anything they needed to learn about computers. However, first they'd need to know what to look for and by God that was difficult before I spent 4 years talking to people who worked with computers all day. I think my time on Reddit actually enriched me there a bit, too.
In today's day and age, it's true that Google will likely lead you in the right direction. However there really is no more efficient way to get a mental lay of the programming land than a quality CS program. Dynamic programming algorithms for example, are something that very few will ever stumble into on their own. You might get lucky when Googling, but it's not the same as having a mental model of the breadth of CS fundamentals.
Sure, but I still think it's more efficient to learn while you work on something real. When you do this there is less waste on certain topics you never encounter, and because you need what you're learning it's better absorbed and understood. It's just this method is less practical for employers since they just want someone already equipped with what they need.
Throughout my career, I've met many developers who couldn't code their way out of a paper bag, network engineers who couldn't network their way out of a paper bag, sysadmins who couldn't sysadmin their way out of a paper bag, etc.
I propose a new interview question: How would you code your way out of a paper bag? You will be given several constants, such as the strength of the paper bag, difficulty of tearing, etc, and will be expected to write your own Tear() function and call it properly.
The best part is that when the recruiters/headhunters ask why you rejected a candidate, you can honestly say "he couldn't code his way out of a wet paper bag."
Which you picked up from books after getting a degree at a university that most likely taught you (or at least improved) your ability to think and learn. I think it is a bit disingenuous to say that you learned CS for far less than the tuition at a typical university after you got a degree at a typical university.
Well, to be pedantic, I didn't get a degree at "a typical university", I got a degree at a really expensive private college (courtesy of a scholarship which made it not so expensive to go). I got there by being raised to read a lot, engage in critical thinking, etc., etc., which skills were then honed over the course of four years.
Anyway, college was a boost, yes, but my main point was that one doesn't need a CS degree (and, honestly, there aren't many CS degrees out there anymore -- just Java-programming degrees masquerading as CS) to be able to do this stuff. Any sort of good liberal-arts background, even one not involving an actual piece of sheepskin from a four-year institution, should be all anyone needs to pick up CS or just about any other subject.
But the merits of a real liberal-arts education are a whole 'nother thread.
On the flip side of that, I once interviewed a candidate for a summer internship at my tech company in San Jose. Our first question was "What is your favorite operating system?"
The candidate looked confused and replied, "What's an operating system?"
The candidate was a 2nd-year CS major at a college in Silicon Valley.
Needless to say, we hired another candidate--the 16-year-old kid who built Linux boxes at home for fun. :)
At the risk fanning a flame war between the value of having a degree vs. not, I think one of the big advantages of having a technical degree in the field of something you're applying for is having a lower value on the crackpot index[1] from the get-go.
Whether you're an expert or not is irrelevant. Its that statistically you're probably more likely to be humble about what you don't know, so that way you can go and hunt down the solution if you need to when those problem situations occur.
It's not about the piece of paper, but about the theoretical background. You can't even have a conversation with someone about algorithms, performance tuning, optimization etc if they don't know Big-O for example.
Incidentally that's why CS undergrads "waste" their time learning all the sorts, not 'cos you'll ever need to write one from scratch ever, it's just a good way to introduce ideas about time and space complexity.
I have a degree, but it is 10 years old by now. I can't even remember much from it. I don't think you learn that much useful stuff - real learning is learning by doing.
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.
Yeah, I also got the impression that the author's technical background was slightly weak. Trying to cram on scalability questions using YouTube isn't going to give them the same background they'd get from hacking on real projects.
But having interviewed programmers, I'm deeply impressed by the author's work ethic. Probably less than 5% of people I've interviewed have spent even 30 minutes preparing. I'd love to have employees who approached problem solving with that kind of gonzo determination and resourcefulness.
If you're hacking on a real project where do you get solid scalability experience? Unless you hit gold and, say, create a social network that explodes like wildfire...
I got the impression the author had a strong practical sysadmin background, was interviewing for a sysadmin position (this wasn't totally clear), and had some technical chops. Interviewing him on CS101 seemed weak.
I don't know about Facebook, or about this particular job opening. But at Google, many of the "sysadmin" positions are really SREs, or "Site Reliability Engineers." These positions have some pretty hard-core requirements, including a solid CS background _and_ serious sysadmin experience.
So if you're applying as a sysadmin at Google/Facebook/Amazon, pay very careful attention to the position description.
For more background, see this exchange on the SAGE lists:
> I still think they're looking for math geniuses who can write hundreds of lines of extremely complex code in their heads for every position, even what should be a sysadmin/engineer/architecture job that doesn't need it. Me, with a good 12-15 years of experience, might be qualified for a junior sysadmin job in one of their NOCs somewhere.
> A good proportion of the "sysadmin" positions which we (Google) advertise are for the group we call "Site Reliability Engineering". The people in this group are part sysadmins, part development engineers. Their function is to keep the Google web properties up and running, highly available, and performant. A solid foundation in systems administration is essential for this role, but the SRE group
are not primarily sysadmins - they are application admins, which is quite a different thing. Any given Google application may have hundreds or even thousands of actual servers associated with it, so the kind of "system administration" with which most people here are familiar is not necessarily pertinent. Yes, sysadmin skills are essential here, however we also require a very strong skillset in development, automation, high-level systems architecture, networking, statistics and general problem-solving. This is why the SRE candidates are grilled so mercilessly.
To be frank, the red flag for me was that his scripting had gotten rusty.
Perhaps I'm biased because I spend so much time in front of a computer, but I can't imagine ever getting rusty at scripting unless I'd left the industry totally and gotten rid of my computer. There's simply too many simple tasks that are made much easier with ad-hoc scripting. I don't think I could make it through a week without writing an ad-hoc script, be it something as simple as transcoding videos to MP4 for playing on devices, finding some files with specific criteria, renaming and classifying photos based on EXIF data, etc.
To be honest, I know exactly how it can get rusty. For a little background, I'm a sysadmin at a large healthcare company. I'm no slouch when it comes to scripting. I've written my own automation scripts that use Perl:DBI and a MySQL back-end to automate most of my daily functions. I know how to create a database schema from scratch, populate the tables, and generate CRUD apps from them.
Still, even getting that deep into it, there are 1 or 2 month stretches of time where I do no scripting at all. I might be deploying a 100TB SAN somewhere, building Oracle database clusters (using automation scripts I wrote months ago in cfengine), doing firmware updates, fixing network issues, helping VMware admins figure out their boxes, etc.
The problem with a sysadmin's life in general is that there is way too much stuff to do to focus on scripting or coding 8 hours a day. Some of us love that stuff, but when you've got a brand new SAN, blade chassis, or servers to deploy, they don't just deploy themselves. There are probably only a few shops that actually embrace the sysadmin coder, or devops as I've heard it called.
Your point about ad-hoc scripts is well taken. I use one-liners on a daily basis, even for general computing tasks like renaming files, or to manipulate data using awk or sed. This is not what I would call real scripting, but it does require a fundamental understanding of the tools.
Yeah it's a tough one, designing a project for load you may never get is a real waste of development time, so for most people they wouldn't have had to deal with anything at large scale.
It's the same in any field really though, even supermarkets are reluctant to hire people without relevant experience that you can only obtain from working at a supermarket.
Guess it's all about getting a lucky break, impressing someone enough to give you a chance, or getting lucky with your own venture that it eventually gets up to a scale where the same concepts apply.
>>.. it sounds like Facebook missed out on a hire it probably should have made. Commitment, motivation, intelligence, and learning skills..
When you say Facebook missed out on a hire it implies he has what they seek and by not hiring him they are now not getting what they first sought, right?
I wonder if that's the case though. There probably exists people who are committed, motivated, intelligent and has good learning skills but yet also would manage to perform "flawlessly" (during the interview) or even as sought.
Now I'm not saying anything about whether they should have hired him or not, just merely stating that above conditions (commitment etc) are not always enough when comparing candidates. Ones current knowledge base is a factor since if persona A has x amount of knowledge and person B has y where y>x it would take A time to go from x to y while in the same time B goes from y to z where z>y.
>>just his lack of knowledge about some technical issues
"just". That's the thing. Why not hire the committed, motivated, intelligent, good learning-skilled person without that lack of knowledge about that technical issue?
As he states in his post -- it's not like [big tech-company] has a shortage of bright people to pick and choose from.
The article isn't even telling half of the story, though. We only know his perspective on the actual interview, which includes his brain's attempt to explain what he perceives as failure, and we have no idea about the nature of the hiring process or what the other candidates looked like.
At some companies, you can apply for a position, go through the entire interview process, and then a company-wide hiring freeze can kill it dead. Sometimes you might be up against an internal applicants with huge advantages. The interviewer might have had a hangover. There are so many things you just can't know.
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.
The guy had taken some time off and was probably rusty.
I was thinking the same thing, but at a 20k a month clip, the interviewer expects a lot of the people he takes time to talk to. I do web development and I feel that I can know if the interview is over after a few simple questions.
That sounds like a more expensive long-term process than finding an applicant who is better qualified.
Maybe the OP is better finding a startup or open source project where he can learn at a faster pace. I suspect facebook maybe a tad too busy to help him along.
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".
How does this get downvoted? I know we're all about good conversation but in bursts, stuff like this completes this forum. This comment was clever and I laughed out loud. If a lighthearted comment is good enough to do that, it's worthy - at very least - of not getting downvoted.
FYI this is a reference to the movie - if you haven't seen it, it won't be funny and is probably worthy in your mind of being downvoted. If you have seen it, you're hitting thumbs up.
Yes, I think it was not clear to everyone that izaidi was quoting, from the movie, Sean Parker's advice to Zuck about thefacebook. A comment that can pithily cast an ironic sidelight on a sober request for precision in the naming of a company by alluding obliquely to the movie whose title is being rejected is, as you say, clever and funny, and, as I think you imply by saying it "completes the forum," interesting to those with an intellectual curiosity that is not strictly one-dimensional. Your comment, I take it, is being downvoted because it's complaining about downvoting, however legitimately. And this one probably should be because its author takes the whole question seriously enough to compose this excessive reply.
Yeah I was subject to the "Curse of Knowledge" - believing everyone who read this thread was someone who had seen the movie. I added an edit likely after you started this and before you published regarding that very fact.
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.
> Why are established computer scientists forced to take a week to study up for trivia-like interviews?
I don't ask anything in an interview that my colleagues didn't automatically learn long ago, just from being good at their jobs. Cram studying for an interview is a waste of time—unless you're trying to get a job you aren't qualified for.
> But, for more established professionals, it would seem that a "tell me about your achievements" discussion would be more applicable.
Once I had met an appalling number of candidates who are incapable of putting sensible pseudocode on a whiteboard, I stopped taking for granted that everyone actually can write what they claim to have written. I don't know where these people are coming from or why, but they're definitely out there, and over-represented in the candidate pool (because everyone is trying to avoid hiring them).
Similarly to the blogger I was contacted by a Facebook employee asking if I'd like to apply for a job (they found work of mine online). I then had to complete a quiz (build a front-end app that conforms to a given criteria and screenshot) and take part in two 1 hour phone interviews using the collabedit website. I guess it seems to be quite standard for them to solicit applications and then scrutinise them heavily.
Luckily I hadn't read a blog post like this otherwise I would have been much more nervous for the interviews! (I thought it was just formality and expected them to only knock me back if I performed exceptionally bad).
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.
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.
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.