Get that job at Facebook (2012)
facebook.com
facebook.com
In short, I can't cope up with them well without going through quite a few glassdoor type questions of that respective company. And partially it is because most interviewers already have a set of solutions that they are looking for, and can't appreciate novel solutions and at times even better time/space complexity if they do not fit the standard mold. In my experience only some very hot startups had smart/ open enough interviewers to appreciate new solutions or see the relevance of new CS research results that may solve their question.
Before one starts attacking me on being a CS philistine, I want you to ponder on my background- current work involves designing & implementing pretty intricate & complex algorithms, and earlier research & publications in a range of ML related sub-fields, mainly NLP & recommender systems. I also read CS papers for pleasure, code in multiple languages and did reasonably well in programming competitions- no longer participate, latter is many years ago.
For a similar experience, though from a far more accomplished person, see Tanya Khovanova's blog post on hiring 'the smartest people in the world': http://blog.tanyakhovanova.com/?p=402
Also, FYI I don't resent the system a lot. It is better than it being an old-boys-club; I just dread going through the bootcamp of memorizing/ revisiting trivial stuff in case I ever have to look for a job again.
It would suggest that the interview itself selects for mostly irrelevant skills if that is a problem they're having with the process.
We ask people to prep because we want to know if you can do that level of work.
Was your query parser work done under the pressure and constraints of an interview environment? Would you have been able to write that parser in the same form at a white board during your actual interview?
As an example of why, consider this famous Brian Kernighan quote, Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? I've certainly been in the situation where the website is crashing, nobody knows why, but we need it fixed immediately. And solving the problem under pressure like that is twice as hard as debugging it normally.
When things go pear shaped, you really want someone available to debug it who is both competent, and familiar with the code in question. This is easy if the person who wrote the code is competent. But if the person who wrote the code is not amazingly competent, you may be stuck with your choice of competent people who don't know the code, and incompetent people who do know the code. Neither of whom is in a good position to fix the problem.
This is hopefully not a situation that comes up very often. It is not something most of us get a lot of practice for. And we put a lot of effort into avoiding a pants on fire situation. But ideally you want all of your programmers to be able to think at this level. (Even if they mostly demonstrate it by avoiding problems in the first place.)
I'm particularly curious as someone who only did a bit of CS in school and became a full time programmer from work I did as a hobbyist.
And if the answer is "yes, your work has nothing to do with the kind of work we do at Facebook, Google, etc." it's not so much that I'm appalled but actually even more curious about the jobs at those companies than I am now.
Funny that this got brought on the Facebook thread. Though I never applied at FB, I have 'mentored' two people who made it through the process. Mentoring as in, helped them make sense (and see the general pattern) of the solutions which they saw online but could not appreciate/ understand on their own. Though I guess they had lesser trouble regurgitating the solutions in the interviews.
I remember once there was a question on Quora about an IIT BTech guy who had offers from all major web companies. Some one asked him how he did it. And his advice was that you had to simply 'practice'. Simply go out on the internet check for good interview forums work on it an hour every day. Even if you are actually a worthless programmer on the ground. You can pretty much ace any interview with simply practice.
This also reminds of my Math classes in pre-university college here in India. I would generally try to solve a problem in more than one way and show it to my lecturer. One day she scolded me badly, that my experiments might end up in me scoring less marks. Her point was the evaluators were used to seeing a certain pattern of answers over years. And if the student had a new innovative answer, they would simply mark it wrong because it didn't their 'one true' answer, even if the solution was more elegant and better than the common pattern. Therefore the only way of scoring high marks was to practice all the common patterns.
Rote learning works at all levels.
I remember some days back I watched a interview of RMS on youtube, and he was asked a question on how you could be a good programmer and what books you had to read. And he gave a straight reply- You had to simply work on some hard real world problems/projects and bring them to closure. That was his advice.
Too bad these days we check people on everything apart from their actual work.
Interesting that you brought IIT up. Though I barely cleared IIT JEE and did not attend it for I could not get CS at any of the good schools, I had the feeling that it was becoming more and more hackable with the proliferation of coaching institutes. When I was in a top 5 PhD program which attracts the best of IIT K/B/M guys the quality drop became more evident over the years. There were and are still very bright IITians at my school, but I saw more noise coming in at later years.
And for those who are not aware- there are cram shops in India which 'train' you to clear Google/ Microsoft interviews. And this has been going for at least 6 years, if not more. Now from talking to my friends in India I get the impression that the superficial interview difficulty is higher in India than the Bay Area for similar companies. And that is despite the work quality being much higher in Silicon Valley.
It's all very funny and ironic.
This is so true, that I can't even find ways how to assert it more.
As a fresher, I attended a off campus interview here in Bangalore(Those who don't know- these are generally mass hiring drives, where hundreds/thousands get hired) where I happened to talk to a guy between written test sessions who even had taken very elaborate 'class notes' on clearing these interviews. He had gone through something like a 3 months coaching class just to attend these interviews. There are standard coaching materials, which are updated pretty frequently. Pretty much anything that they can ask you in these interviews will be covered. They have made you hard practice it so much it will be cake walk to you make it through.
>>And this has been going for at least 6 years
I can assure this has been going on for a very long time now.
>>It's all very funny and ironic.
Its all about the volumes. A recruiter told me, if a resumes falls down during a mass hiring drive they don't even bother to pick it up. We live in an era where recruiters search monster.com based on some keywords and pick up candidates based on that. So we are now down to SEO optimization for resumes. And then coaching classes to game the interviews.
As a side note, in all major IT services companies in India you have to take 'certification exams' for pay hikes and promotions. I've seen people drop everything they do and practice clearing these for months. The worst part is you have to 'memorize' the whole material. Later I would see those people go on to get promotions and hikes, while the actual who go the work done fail(due to lack of time to practice) in the certification exams.
Pretty sure there would be coaching classes to get into coaching classes with higher hit rates of finally clearing the interviews. It's that broken.
Whenever people talk about the madness of India's youth, I can't help not quoting Soumen:
"It's hard to overstress the liability of a nation of a billion people out of which 700 million are functionally illiterate and the rest have no wish to follow instructions, even when they are asking for a favor."
http://www.cse.iitb.ac.in/soumen/APKGKAH/illiterate/Applicat...
>> As a side note, in all major IT services companies in India you have to take 'certification exams' for pay hikes and promotions.
Hope you are fortunate enough to be not working for such places anymore.
But in my opinion, they just need an easily definable and quantifiable process. And they are happy to look the other way when they see covert cheating/ hacking as long as it clears the process. And there is no denying that there is still a decent ability threshold which most covert cheating people too will pass, which I guess suffices the corp needs.
I am a far bigger fan of pair programming after a basic phone screen, but large companies just can't do that.
You could prepare for months but if you don't understand the core CS concepts then it's difficult to hack these kinds of interview problems. Having a solution is one thing, but coming up with 3 different solutions to the same problem based on various constraints (preprocessing, space/time constraints) requires understanding.
If they "hacked" this, then thru likely understand the concepts well enough such that its sufficient for the job.
Also, interviewers should ask if they interviewee has seen the coding problem before and come prepared with a backup. Interviewers are also looking to see if the interviewee derives the answer too easily. Usually scraping the surface reveals whether the person really knows what they're talking about or not.
A good interviewer does try to gauge whether the answer was known to the interviewee. But I have seen that happen far more at hot startups than big companies- primarily because of their more stringent process which leaves less wiggle room for guess work and is more tuned towards concretely judged parameters.
I just don't like the facade of 'hiring the smartest people' in the world, when their mechanism largely filters just well-trained average people.
And I most certainly don't want to sound condescending, so I apologize before-hand. But I probably used a different definition of average than what you or most people here may have in mind. I know quite a few ACM ICPC world finalists, am a region finalist myself, and have conducted/ published CS research with reasonable impact. So I was simply using my PhD program peers as good, and people with lesser (proven) skills as average. My fault, but I hope you can see what I was trying to say.
I do think there are false negatives through this process but that's the trade off, I believe, for efficiency. Considering how time consuming interviews are (for the interviewer), there has to be some ways of reducing the wheat from the chaff.
After all, many use a university degree (from a prestigious university) as an initial filter. However, I'm sure there are many talented people who don't have degrees. But when looking at the probabilities, your chances of finding a great candidate are significantly higher if you filtered on that degree.
Advice to prep bothers you? Wow! I thought it went without saying that any endeavor of import benefits from prep.
That was the exact opposite of my experience interviewing at Google, and when I got an offer from Google I took it.
Honestly, you should have decided based on compensation, geography, etc. The jobs are similar. But you microptimized :-)
What are some concrete examples of hard problems tech companies face that require novel solutions and why are algorithms problems the best way to find the people qualified to solve them?
I know these seem like a naive questions, but these two things seem to be taken for granted in every interview discussion (or even if someone argues against them it's mostly a "this is how I find good people" argument). I think it's pretty clear this isn't the only way to find good people, I'd just love to hear more about the thinking behind this interview style and what it really means to these companies when they say "we deal with hard problems." The only concrete example I've ever been given is someone at another big Valley company speaking about difficulty of master-master writes between data centers at a large scale. Which certainly qualifies but I'd love to hear what other "hard problems" are out there.
This is best answered by awesome example. See http://research.google.com/people/jeff/ for a list of some the problems that one Google programmer met, and solved. Many of said problems were novel at the time, though many have now learned the answers that Jeff came up with.
These kinds of problems and answers are simply not understandable to people who don't understand algorithms. And you can tell people without a deep understanding of algorithms how to solve those problems, and they will consistently get it wrong.
I'm a User Interface Engineer at Facebook in the Photos team. One common thing we do is to display photos in a grid. This is one subject that's really important, yet I haven't see any good documentation about it. I've first looked at all the websites that did some interesting image layouts algorithms, reproduced them and documented them.
Google Plus: http://blog.vjeux.com/2012/image/image-layout-algorithm-goog... Lightbox: http://blog.vjeux.com/2012/image/image-layout-algorithm-ligh... Lightbox Android: http://blog.vjeux.com/2012/image/image-layout-algorithm-ligh... 500px: http://blog.vjeux.com/2012/image/image-layout-algorithm-500p...
Unfortunately, none of them really suited our needs. We wanted to let users have the ability to make any (or all) images bigger. So I started playing around and writing a new image layout. The hardest part was to have an algorithm that was designed such that you could move images around in real time in ways that feel natural to the user, even though we have constraints that are impossible to solve.
Basic algorithm: http://blog.vjeux.com/2012/image/image-layout-algorithm-face... Reordering algorithm: http://blog.vjeux.com/2012/image/image-layout-algorithm-face...
Are you saying that jeff or whoever algo genius can come up with a solution to all those problems given say a couple of hours?
C'mon- Problem solving especially of difficult problems or big problems or long term projects is pretty much an iterative process. In which discovery and application of knowledge, and staying productive is more important than number of facts in the head.
Of course not. Those problems and solutions were the result of years of work, by one of the best programmers on the planet. (Inside of Google, Jeff is a legend.) The question was what real problems faced by real companies require an algorithm person to solve, and that is an answer.
But any toy algorithm problem that you could be given in an interview, he could solve instantly. I guarantee it.
Heck, I'm nothing on his scale. Yet most algorithm questions that I see people complain about having been given in an interview I can figure out a decent solution to in under 2 minutes. When I hear people talking about prepping for that sort of question, it seems to me like they are missing the point.
The point of these hard questions is not to assess if you know some obscure algorithm. The algorithms in these questions are obscure precisely because you're not supposed to know them. If the candidate clearly knows the algorithm I switch to a new question.
The point of these questions is to assess your ability to perform under pressure in an unfamiliar situation, which is a fundamental skill that all productive engineers require. I expect that any engineer I greenlight to encounter novel situations. These are not necessarily Hard Problems dun dun dun, but these situations will challenge your problem solving skills and you won't be able to look up the right answer on StackOverflow. I expect candidates to have the ability to deliver a solution that works and makes the right tradeoff between time, quality, and scope.
I have also had interviewers ask hard problems for the wrong reasons. Frowntown to that.
1. Obviously hard, and needs no explanation e.g. self-driving cars. 2. Basic problems done at ridiculous scale. Quickly matching keywords to web pages is not a hard problem; quickly matching keywords to every web page on the internet is a hard problem. 3. The problem is that (forgivably or not, depending on circumstances) we have no idea what we're trying to do.
You're working on the front-end development for a chatting website. Each conversation gets it's own 100x200px div and they are placed on the screen such that two conversation windows are never intersecting.
We want to display a new conversation window, write an algorithm to determine where a conversation can be placed such that it does not overlap with any current conversations. Assume that the website is being displayed at 1024x1280px.
Or is the problem different? For example you already have some arbitrary number of windows already displayed at arbitrary locations that you cannot move?
So keep a list of possible candidate positions. Each of these positions represents either an edge of the screen or a position directly above/below/to the left/to the right of an existing window. You will need to calculate different offsets for each of these circumstances to generate candidate positions. You easily eliminate ones that fall outside of the screen.
Each time you attempt to add a window you iterate the list of candidate positions. If a candidate position can fit a window (just use brute force 2D AABB collision detection against all windows, or a quadtree/spatial hash to optimise) then place the window there. If it cannot fit remove the position from the candidate list.
Once you have added the window, calculate all the candidate positions (for each side) and add these to the list of possible positions for later windows.
Well it's late and that's the best I can manage.. I know somebody will point out a flaw here :)
And can you code an AABB tree on a whiteboard? :-)
One could try placing the new window at (100x, 200y) for integer x,y, and check for intersection each time with all the existing windows. 3600 overlap tests in the worst case, but you get huge benefits in practice by hinting the location of the last new window.
Optimize a bit by sorting lists of windows by x and y, so you can binary search for the few candidates to overlap test, and you are down to about 1000 window checks. You miss some cases if windows are very maliciously aligned off grid, but you can mitigate that by using a slightly finer grid.
Or test the 8 neighbors (edges and corners) of each existing window (if any), as it is nearly impossible for available space to be not one of those positions.
(You can compute the next window position after the previous window creation or move, so there is no latency when rendering a new window.)
I almost solved it; after screwing around for a while trying to record only one value for each square, I realized you need to store two values for each square. If we’re looking for the upper-left corner we can put a window, each dead pixel/pixel “poisons” all the pixels less than the width of the window to the left of it and the height of the window above it. Then you just do a linear scan over the remaining pixels. I think my problem was that I used too much RAM because I was trying to store the whole 2D grid; you only need to keep one dimension in memory.
You can see people’s submissions here: https://www.facebook.com/hackercup/scoreboard?round=18989011...
I also guess that when you run the largest online community out there you might run into problems that you can't find the answer to on stack overflow. Even if these are not the majority of problems you face day to day there's an advantage to having staff on-site who have a hope of solving them.
Maybe they were trying to ascertain something else about their candidates. Like how they approach problem-solving in general?
When dealing with scale, its important to have efficient solutions. They may need to be time efficient or space efficient due to constraints. Even though space is cheap and hardware is fast, inefficient algos may never work or be very high cost.
Maybe you won't be the one implementing this infrastructure but you may be implementing code on top of this infrastructure and it matters that you understand (at least the basics) the consequences of designing things a certain way.
This makes me wonder, who or what kind of a candidate the person even trying to hire. Programming or any career for that matter is by and large a kind of job that requires you to perform everyday, you have to be consistent. Its not an Boxing match or America's got talent contest which happens once an year for which you do all the preparation for 12 months and then perform on the last hour. Software projects or any project for that matter simply don't work that way. You don't read books for months, decide to do the project and then hammer out all the code in an hour.
>>Impress us with your mastery of whatever language you're best at.
Again, whom are you trying to hire?
>>Hard training makes for an easy battle. Brush up on techniques that you may not use every day, but are very useful when you need them: recursion, graph theory, tree traversal, combinatorial problems, etc.
Sorry but this is getting boring. This algorithm thing is so badly gamed, it doesn't even make a good point of testing a candidate anymore. I've known people who work an hour everyday practicing these interview problems and can ace through such interview in a breeze, but wouldn't even last hours in a demanding work environment.
The best way to check if a candidate is good for you is to do a through check on the quality and kind of projects/problems they have worked on in the past. If they have done well, hire them. Else regardless of whatever they might know from the text books, if they can't get the job done or haven't in the past. They are worthless to you anyway.
I'm afraid that interviewing is never going to be easy for both...
Take a few hours to study up before interviewing at the big engineering-focused companies.
I've turned down a couple of companies that take the formulaic approach. In most cases, I've not been looking. So, if you reach out to me, there is something in my background that is interesting, and I expect contact to be based around that.
As a counter, when I interview a candidate, I mostly avoid typical questions and try and ask questions intersecting the candidate background and what we are up to. If that is a stretch, I prefer focusing in on a passion or project and talking about the design/implementation challenges there.
Google and Facebook seem to have similar approaches, and because of the number of resumes they get have set up a formulaic system. It probably gets a certain level of quality, but probably also puts artificial caps at the high end.
My comment is only meant as practical advice to candidates. It is not normative.
1) Implement a red black tree on a white board
I would argue, though, if that's the bar, there are probably other bars that are a bit lower that at least some of the algorithm triumphalists would fail, such as to
2) Throw up a basic and secure Wordpress site on an Amazon EC2 instance
or
3) You're running into an issue where you're getting an error message about running out of file descriptors. Tell me what's the issue here and what you'd do about it
or
4) write a basic, safe script that makes backups of each file in a given directory and its subdirectories
or
5) tell me what the fuck is the clearfix?
Now, if intermediate algorithms is something that people should be able to do, surely you'd agree 2-5 are even lower bars to meet (since they're things that virtually all of those "bad programmers" are able to do). By the same token, though, it's absolutely the case that many hires at the BigCos actually wouldn't be able to respond to 2-5.
I wouldn't say that those people shouldn't have been hired; after all, people learn! But if algorithms are actually part of the everyday job, someone could also learn them, no?
To the extent that you're testing for raw intelligence--which is the most important aspect of any of these types of jobs--algorithms are a good ruler. But to equate the measurer with the measure is somewhat foolish, because it's a means to an end, not the end itself. If you can use other probes of raw intelligence, those function just as well as being able to vomit up algorithms and data structures that, as people point out, any person who spends a month or so studying can get a solid grasp on and then never need again.
If they have no idea, they are likely going to google and follow the wrong advice. If they have an idea but have forgotten the specifics they will know where to go and which advice to take.
If, however, you have a strong basis in algorithms, but still no pre-existing knowledge on the red-black tree specifically, then you will be in a better posistion to adapt or optimise it for your particular use case. Not to mention have a better intuition in what to search for in the first place, or who to structure the rest of you code to play nice with an algorithm that is a good fit.
Maybe applicants shouldn't be able to "undo" during the interview? Or maybe applicants should be able to manually convert the code to assembler? Or, heck, have them use one of those behemoth computers with the blinking lights that we have to plug wires into sockets to program?
I mean...why should we rely on any technology that has been developed to make software engineers more effective and that the majority use daily? That would be like if we let sales people use tools they rely on, like charisma, during interviews!
The only sensible argument I've heard for why companies interview with programming puzzle questions is that it "takes too long" to do an interview better (like the way simonsarris pointed out Sencha does). At the point a company is unwilling to look at applicants as humans, and instead treats them as numbers/percentages, I wonder if they're a company worth working for any way.
Many programmers will take longer to configure their environment than you have available for the interview. Therefore if you tried to let them interview in the programming environment of their choice, there would be no actual interview. (And you'd have to undo whatever they did before the next interview.)
I've seen people spend days getting themselves set up exactly the way that they want. And looking at http://xkcd.com/1205/ it isn't obvious that this is a waste of time either.
I've managed inside Engineering at Facebook and am now back to just being a straight Engineer, and my advice to everyone I work with is the same: Don't kill yourself working 70/80 hour weeks. We pay you to give 40 solid hours, and that is what I want. What I ask of you is that you set expectations for the people and teams around you as accurately as you can. Don't make a bunch of promises you have to work crazy hours to keep.
The majority of our most successful engineers have a very good work-life balance.
Maybe it's Facebook PR's fault.
I personally disagree pretty heavily on sleeping in the office and working crazy hours. I find it very counter productive and generally think it leads to bad decisions, bad code, and ultimately bad products. It is certainly the exception, and not something you should be doing if you aren't 22 years old and/or more than a little crazy. I personally haven't worked crazy hours at Facebook since probably 2009.
Talking about this sort of thing from a PR perspective seems has to balance getting people excited about our environment and explaining our goals and day-to-day. I've found it's something the media outlets love to play up. The normal day-in-the-life of an engineer is fun, but chill, and not particularly news worthy.
I personally disagree pretty heavily on
sleeping in the office and working crazy hours.
I get that you don't have complete control of the press you get, but maybe it'd be worth focusing some attention on these work-life balance issues in the outlets you do have complete control over.
getting people excited about our environment
I don't just mean programmers. The advertising industry hires many of the most talented people in many areas.
Then, we dig deeper. Anything they say, I continue to ask them followup questions. Eventually, we dig deep enough to know whether this person truly knows said technology or just put in on their resume for buzzword compliance.
It might go something like, "Oh, I see you've had some experience with REST. What is REST?" ... "How does REST relate to HTTP? Is HTTP required?" ... "What HTTP verbs are considered idempotent? What does that even mean, how is this useful?" ... "How would you implement a {insert} application using REST?"
There's no "tricking" the candidate this way. If they know their stuff, they get to talk in depth about it allowing them to shine. You will recognize this person, as we all love to talk about things we actually know something about.
And the other type will also be spotted. They get nervous when you start probing deeper on what they said they should know. They start giving really bad, contradictory and even laughable answers as you go.
I just joined a couple of weeks ago as a product manager and in the short time here, I've loved it.
I don't have a problem with the piece per se, I just have the general feeling that an article on how to impress mid level managers to get a job at some giant established company is considered "hacker" news is.. I mean, am I the only one that thinks that's the antithesis of hacker ethos? There's no "hack" to this, it's like reading a pamphlet on how to get a job after college or something. It's not /wrong/, per se, but there's no real special insight here, and it basically reads like a PR piece.
Still, it seems like rather run-of-the-mill process. It will certainly filter out the bad, but you may miss some very good workers who work in different ways. Facebook still seems to be totally focused on code problems, and doesn't even mention if what you've already built is important.
In my opinion, stuff that someone has made should probably be considered the most important thing by miles. It doesn't have to be open-source code, but that certainly helps.
Second most important is communication skills, especially how well they can explain things they have worked on.
From this post, Facebook seems more interested in making sure developer can re-re-re-implement merge-bubble sort-reduce, I'm sure while occasionally printing "Buzz". I understand why these tests can be necessary for a lot of people[1], but I imagine the caliber of people that get past screening at Facebook aren't of that type.
~~~
The most delightful interview I ever had (I was being interviewed) was one where the development team didn't even ask me any general programming questions. They took what I had written as fulfilling that pass, and went straight into several conversations with different developers about the ways we go about making libraries. They asked me to talk about decision making process and how I might explain or advocate for various concepts. I'd like to think if they had any suspicions they might have switched gears to a FizzBuzz level, but I can't know for sure.
These talks got very in depth, and whiteboard-writing was had, but at no time did they ask a programming question that wasn't rooted in the concrete. It was always directed: "How did you...?" "How might we...?" "Didn't you run into problems with...?"
Never did they ask me to implement a common algorithm, which feels silly. I can't remember all of them (or even most of them), and if I needed to in the course of my work I'd consult Professor Wikipedia long before I touch my own corruptible memory. Never did they ask me to implement an obscure algorithm, which popular companies seem to enjoy but I imagine filters out a lot of good candidates who happen to have spent time knowing the wrong things. I do not understand why obscura in itself might impress.
Instead, they had me make worthwhile claims about (my or other's) code and then prove them.
Then they showed me what each of them was working on, ensuring there was two-way discussion on each. They showed me problems they were having, what they were doing, and asked my opinion. They showed me bugs, and we sat down and set breakpoints, talked it over and stepped through until the issue was resolved.
This process lasted two days, and the entire time I was delighted. They did an incredible job of making me feel accepted as a fellow professional developer. I ended up not taking the job for personal reasons, but the entire process and people involved were all wonderful.
(The company was Sencha).
[1] Jeff Atwood's "Why Can't Programmers.. Program?" has a good discussion on that http://www.codinghorror.com/blog/2007/02/why-cant-programmer...
Facebook still seems to be totally focused on code problems
I would say that statement is categorically false. In fact, the article lists 4 criteria, only one of which would be "code problems". The interview certainly has a focus on coding, but it most assuredly is not a total focus. And people can, have, and will pass the coding bar, and still fail to get an offer.
stuff that someone has made // communication skills, especially how well they can explain things they have worked on.
Both of these are critical parts of every facebook interview.
From this post, Facebook seems more interested in making sure developer can re-re-re-implement merge-bubble sort-reduce
I don't think that is a well supported inference from the post in question.
Facebook's interview process seems to have a very high variance in terms of candidates' experiences about the process. In the telephone rounds, collabedit often has sync issues, which can be quite stressful for first timers. Occasionally, interviewers either do not speak clearly, keep moving away from the speakerphone or have a very difficult to understand accent (not sure how to solve this one). These two things compounded together have caused several people I know to have a terrible experience in the first round, and it appears that these issues are not taken into consideration when making a final decision, as was the case for me. I had two phone interviews because the first one had these issues. I was called to the campus for the final interviews, which I would certainly describe as "code problems", or more accurately as algorithm based problems. I actually found these interviews to be easier than the phone rounds, which was a common opinion among the other candidates I met. I was quite surprised to not get an offer and my guess is that the botched phone round had an effect, but I may be wrong.
This is intended as honest feedback rather than a sour grapes reaction to not being extended an offer. I have interviewed with several other companies and usually the experience is either consistently good or consistently bad, which at least gives the candidates a fair playing field. My guess would be that this feedback is getting ignored because it primarily comes from rejected candidates.
Finally, it would be great if software companies started sharing feedback about candidates' performance if they don't receive an offer instead of a cliched e-mail. Quora seems to be the only one doing this at the moment: https://www.quora.com/Quora-Recruiting/Can-I-get-the-feedbac...
From the post in question:
> [screening portion] The bulk of the time is spent on coding exercises. The interviewer will send you a link to a collaborative editor and ask you to solve some programming problems.
> We will ask you to do a lot of coding during the interview process, because programming ability tends to correlate strongly with how well people perform as employees. We even have a large set of take-home questions. It can't hurt to check them out and maybe solve a couple before you even submit your resume.
> Take your time preparing. Do code katas and practice interviewing with friends. Try solving the interview questions on our site.
> Hard training makes for an easy battle. Brush up on techniques that you may not use every day, but are very useful when you need them: recursion, graph theory, tree traversal, combinatorial problems, etc.
> You might be asked to implement some well-known library functions.
Being asked to implement some well-known library functions is why I said re-re-re-implement merge-bubble sort-reduce. The rest is why I said FB seems more interested in this than anything else on the list.
Code katas? Take-home questions? Maybe it isn't this way in practice, but the post certainly makes it sound like a bizarro SAT. Needing to "prep" and "practice" coding questions in the way encouraged seems rather odd to me.
Implementing some well-known library functions is basically a quick way to see whether you know how they work.
If you don't feel it's necessary to ever practice for an interview, well, ok. This advice is not for you.
I don't think that was his point at all, with all due respect. I got the impression he was just criticizing the rather stereotypical technical interview, which Facebook seems to subscribe to very strongly based on the article.
It seems like you should be asking 'Write me something to do X, using Y from the standard library' and evaluating that code, if you're looking to evaluate how well someone knows a library function.
At least this type of interview seems to solve the problem of developers strangely needing to study for an interview, and I would guess it also better represents coding ability.
Alternate versions can include "debug this" and "design this" (which is pretty popular AFAIK).
It is wrong to conclude that the person whose comment you replied to, feels that way. Excerpt: "Needing to "prep" and "practice" coding questions in the way encouraged seems rather odd to me." [emphasis added]
This may be well suited for fresh grads, but not for mid-career senior engineers.
You should seek good candidates as is. But, you already assume that one needs to prepare...
I recommend that people prepare because I've seen many many obviously smart people not make it through. It's like showing up for a singing audition without warming up your voice. You might have a beautiful voice, but you have to show it in the best condition possible.
An interview needs a greatest common denominator. That is what an undergraduate CS test is.
I've used that ever since when I've been a technical interviewer. It's fascinating hearing how people go about solving problems, and it tells me a lot about their actual skills.
(One of the best responses for a sysadmin role qas a quiz around sudenly degraded performance and the first question was, "What's changed? I'll check the change management to see what's gone live recently.")
Problem is, a lot of good engineers (especially at big companies) may have spent a lot of time working on something that wasn't very important or good. They may have been a sparkling diamond in a sea of mediocrity.
One of my first jobs I spent the best part of a year working on something pretty dumb that was mired in bureaucracy and most people considered a bad idea from the start.
Yet that is what I worked on for around a year because that was where I was assigned, and it was considered important by edict of a person who earned approx 1000x my salary.
They eventually scrapped the project altogether.
The next time I interview someone to work for me, I really hope I can make the experience as collaborative and rewarding as it sounds this was for you.
The kinda person who I can work through this interview with is exactly the kinda person I wanna work for / employ.
http://swizec.com/blog/the-most-pleasant-job-interview-i-hav...
https://www.facebook.com/media/set/?set=vb.9445547199&ty...
My only complaint is I wish they were on Youtube, I'd like to make playlists and watch them on my TV.
"pls give me job at facebook call me 5551231234"
"send link to aplication to email@email.com"
Obviously, services grow and the Facebook of 2013 is very different from the Facebook of 2004, but it's kind of funny to see companies that succeeded because the original team was able to ship (period) evolve to focus on hiring CS majors who can reinvent the wheel on a whiteboard.
The "fit" category is fairly vague, but a better description of it (and what I think about when interviewing candidates) is "how would I feel if I had to stay late fixing a live site issue with this person?" Ideally that doesn't happen, but I find it helpful framing question.
For coding questions, I generally have a pretty low bar - and it's gotten lower. Generally I look for understanding of basic data structures, and the ability to manipulate them. I realize that's slightly biased towards recent grads, but I think linked-lists, binary trees, and pointers are fair game even for experienced candidates. I'm sometimes amazed at how many people have problems with what I think are simple questions.
SQL and schema design questions are also good, and lend themselves very well to iterative questions. It's easy to start with simple problem statement, have someone get a reasonable solution, and then throw additional requirements in.
Simple is not the same thing as relevant.
About a week back, I applied to Facebook after solving a puzzle on their Interviewstreet page successfully within given time.
Sadly I didn't get any kind of acknowledgement from their recruiting team, neither saying I am rejected nor that they have received my application.
Syntactically it looks a lot like PHP and is backward compatible for many thing, but it's not really PHP anymore. The HipHop team has done a ton to make the language a lot more enjoyable to work in.
Too my knowledge (I'm not directly on the Hip-Hop team) it will be open sourced, additionally we also generally present a PHP patch as well to allow it in future versions of standard PHP.
Yet so few companies give feedback.
By the way, I'm wondering why do some people insist of working at a company which doesn't want them? Besides money from a lawsuit, of course. Even if the interview wasn't "fair", it's someone else's company, so they should be able to hire whoever they want.
I'm looking forward for the time I'll be able to solve their problems, too.
Not sure how you imagine a 'small team' managing a system that has an exabyte of data. From network infrastructure all the way down to cold storage, a 'small team' would be needed for each.
Fb recruiter, if you read this, shoot me an email.