"which merges two sorted arrays without allocating any additional memory. Aside from having no real-world value, it's not actually possible, and his solution code clobbered most of the data in the first array."
This is referring to me.
The author has misrepresented the truth.
(1) The problem does not state that you may not allocate additional memory; only that the memory allocated must be constant relative to the size of your input.
(2) Given #1, this problem is absolutely possible.
(3) The problem explicitly asks you to merge the two arrays "in place". If by "clobbered" you mean changed, then that means that by definition one of the arrays will be "clobbered". We can certainly have a separate conversation about whether modifying structures in place is a good coding practice, but it is generally more efficient and highly widespread in non-functional languages.
I'm sure it wasn't purposeful, but I'm disappointed that the author misrepresented our conversation to make a point. Separately:
(4) This problem is extremely applicable to real-life programming IMHO. It does not use any esoteric data structures. It does not use any complicated algorithms. All you need to do is iterate through two arrays at the same time. A great majority of candidates have solved this problem.
In general I agree with this post's thesis. Facebook's general philosophy with interviews is to allow each interviewer to ask whatever questions they want, and the consequence is a variance in the type of questions getting asked. However, based on internal conversations I know that Facebook is trying to move away from "puzzle" questions by explicitly "retiring" a number of questions that we consider to be unproductive.
In reading through the threads, there's a common underlying assumption that if you don't get the problem right, you won't get hired. That definitely is NOT the case in finance. We use the brain teasers and puzzles as a way to showcase how you think. For my interview, out of 5 brain teasers I nailed 2, was heavily helped through 2 more, and never got the last one, even with lots of help. But for each, the interviewer made it very clear that I was to think out loud. After getting the job, I later used the technique in interviews and gave positive reviews to those who had similarly struggled through puzzles but had used a similar thought process. In general we used this to weed out three different types of people:
1. Hard science majors who learned how to solve problems instead of think through problems. These people learned how to derive the heat diffusion equation, but would never put a story modeling a random walk in connection with that equation.
2. People who freeze when things get tough. Obviously a bad thing on the trade floor. While with coding you can often walk away from a hard problem, think about it, and come back, in finance, you can't walk away from losing lots of money over a short period of time ... you have to stop the bleeding.
3. People who learned how to think quickly and with rigorous process. The type of people you want.
Is it possible that the look of distain on his face when the interviewer asked him to solve a puzzle indicated that he wasn't a good fit for their "puzzle culture"?
I don't think it's fair to conclude he didn't get the FB job due to his failure to write a square root function. The funnier part is that this question isn't a puzzle (but does perhaps indicate how well the interviewee has internalized mathematics).
I suspect I'd have failed him for ego ... "Today, after releasing 25 Github projects, creating several widely-used apps in less than a day each, and designing an entire architecture for a streaming platform, I realize I’m a pretty well-rounded and high-performing developer/engineer/architect. At the scale of Facebook, I’m exactly the sort of engineer I’d want many of." I've been in the industry for 30 years and realize I still have so much to learn.
Yeah, I think there's definitely an ego/butthurt attitude here I wouldn't put up with.
Don't get me wrong, I think everyone needs to have a certain confidence on their abilities and expertise, but it works both ways: when hiring for our startup we'd look for honesty and humble acknowledgment of the candidate's shortcomings/lack of expertise.
I wouldn't fail you for not knowing what the Newton's method for finding square roots is, but I will fail you for thinking it's irrelevant or not caring. If you don't care about my requirements in an interview, I don't think you'll do much better with actual work.
I actually did solve the square-root function problem, but I suspect too quickly because I did it from rote memory.
I am fairly objectively the sort of programmer they would want in the sense they seemed to be selecting on.
> This article is obviously somewhat over-stated. However, good programmers are aware of what they know and what they don't know, and maintaining a sense of imposter syndrome forever is somewhat counter-productive.
"How often do you expect candidates to write a function to calculate the square root of a number? I would fire any developer who chose to re-implement standard library functions."
Not this crap again.
Oh and he says he has an "interest in formal computer science"
No, I don't expect you to reimplement square root. Or maybe I do, because that's what a lot of games do (or something similar) because you have to reach a balance between speed and accuracy.
Or maybe because we need a bigger precision than a double, again there are libraries, but again we may need something else that's not in the library.
So yes, absolutely, what I wouldn't hire is a "computer scientist" that can't work their way around a math problem.
Edit: oh it gets worse, he gives the "never parse HTML without a proper HTML parser" talk
Whine whine whine
Step 1 - learn the rules. Step 2 - learn when to break them
And it's only an example
FB didn't lose a "great engineer", they were right on target.
So are they looking for someone that knows the 'look and say sequence' explicitly ? Same way if you presented the meaning of numbers 80 or 443 to someone they'd either know or not, but not be able to guess.
Or did they actually expect someone to work it out on the spot ?
Yes, the problem with the look-and-say sequence is that it's not something that you can derive; it requires having the right insight.
This makes it a bit different from other problems, where the interviewer is often not even so much interested in the solution, but in how you go about finding one. Many other sequence problems are amenable to a more systematic approach that at least tell them something about your problem-solving techniques.
With the look-and-say sequence, you either see it or you don't. Regardless of whether you got it right or not, it doesn't tell an interviewer much about you, and is therefore not a good use of the limited time they have with you that could be used more productively.
> Or did they actually expect someone to work it out on the spot ?
My hope is that they'd hope a candidate would be able to identify the connection to run length encoding within the pattern.
Why do these puzzles emerge at big companies? It looks like a sort of institutional power trip emerges: "if you want to work with us, you need to be real good, and these are the sorts of problems we want you to think we deal with every day!" Except in most cases, they aren't, and there are plenty of mediocre folks already employed there. But the institution NEEDS to believe it only hires the best, and one way to perpetuate that belief is to haze new applicants more and more. All it really produces is candidates who are very lucky, or very compatible with the existing culture.
Hiring is hard, and puzzles are a fail-fast mechanism that is terrible, but produces some sort of results, so it gets used.
If you add the digits in the sequence you get the Fibonacci sequence.
[1 = 1, 11 = 2, 21 = 3, 1211 = 5, 111221 = 8] => [1,2,3,5,8]
I'm not sure if there being multiple "correct" answers makes me like the question or hate it. The Fibonacci sequence seems a bit more obvious though than the "look and say" answer.
While I also doubt the value of this kind of questions in interviews, I don't think that figuring out this sequence is impossible.
I figured it out by myself too when I saw it the first time. Of course that doesn't count for the increased stress levels in an interview situation.
> Or did they actually expect someone to work it out on the spot ?
I just figured it out on my own, from the comfort of my home, while having breakfast. In an interview with a top notch company that'll be a totally different story.
I'm not sure you're right. I was rejected by Google after 2 phone interviews with somewhat similar questions and to this day I feel like it was a failure on my part. I really should have been able to do those puzzles better.
I have a job I love now, but I don't feel like I deserve it. Overall, I suck. You probably do too.
Rephrase this as "Facebook Lost a Great Developer" and it begins to make sense, especially if Facebook was actually looking for a "Great Engineer".
> I would fire any developer who chose to re-implement standard library functions.
Who writes the standard library functions?
> never parse HTML without a proper HTML parser
Who writes the parsers?
On merging arrays in-place:
> Aside from having no real-world value, it’s not actually possible
It is possible, and has value when dealing with large data sets, which I'm sure is a common issue at Facebook. Here's another way to look at it: "Given two sorted 0.5 terabyte arrays on a terabyte drive, and 1 gb of memory, merge the two arrays without an additional drive."
There's no shame in not knowing or caring about things like this (it takes all kinds), but what the poster does (and seems to be good at) just may not be what Facebook was looking for.
> At the scale of Facebook, I’m exactly the sort of engineer I’d want many of.
I'm not sure it's really a bashing. I read it as he's glad after all that facebook didn't hire him, so it's more like a message for those who already "lost" or will "lose" in puzzle-based hiring process. A message that states it's not necessarily their (i.e. prospective employees) loss in the end, and the more important part that it's not a reason they should feel bad about themselves after such "loss", because solving riddles is about solving riddles and not about finding good programmers (being one doesn't necessarily exclude having puzzle-solving ability, but it's not like a symmetric difference of these sets is empty, really, more like quite voluminous, I would say).
Why not? I don't think it's healthful for a culture to impose a wide penalty on criticism.
Criticism, if constructive, is not 100% negative. The post indeed criticizes Facebook, but also lays down an explanation of why Facebook's hiring practices are wrong. It contains useful information.
I agree completely. This could have been written in a way criticizing the hiring practices of companies where it didn't come off as a complete bashing.
One thing you need to remember is that technical people that are performing phone screens are going to do a little research on you as a future candidate, and this isn't the first impression you want to make when vying for a job.
You'd have been just a cog in the machine at Facebook anyway. If you listen to some of their seasoned engineers speak they seem to take great satisfaction from delivering some inane and tiny little web app feature, seeing it through a year of testing, and seeing it in production. Whilst I'm sure that is satisfying if you've never known any different. It sure as hell isn't anywhere near as satisfying as building and scaling out a product or service of your own or one in which you are vested.
The article is well written but you really shouldn't put Facebook on some sort of pedestal. Especially after two years, it seems like you still feel sore about it. It really isn't "all that" to work at Facebook. Do you really want to write PHP all day, for example? For an engineer it is more a bragging right and CV fodder than anything else.
1°) I think you don't get it: when you're Facebook, Google or any other company receiving and interviewing thousands of candidates for a job, you're having a different hiring strategy than a small startup.
Their strategy is "hiring a bad programmer costs us more than rejecting a good one". So they tend to reject good programmers, but they mostly reject bad programmers. In the end: they only hire good programmers, and that's what matters.
In contrast, startups are having the "it costs us more to reject a good programmer than to hire a bad one" strategy. So they hire more easily, most of the time, even if in the end they hire average/bad programmers, they don't care.
2°) I was interviewed for a front-end job at facebook, and I didn't get in. I think I'm not the best programmer around, but I'm okay, and I would do a great job at facebook. And just so you know : my first interview question was way way way harder than any of your questions.
I think those puzzles are a good way to spot good programmers amongst thousands of good/average/bad programmers. I'll give you a really simple example: find the highest number in an array. You can find it using several different ways, but if you just go through the whole array, you might be a good programmer, but the next person I'd interview might be one too, and he will find it with a much lower complexity. I'd hire him. Simple as that.
Bottom line — here's the question I was asked at facebook : you have a matrix of letters, and you have to find all the words you can do with it. For a front-end/product design job. And I'm not posting an article saying they suck at hiring.
I understand that these questions can be ridiculous at times. But I think it is worth pointing out 2 things:
1) They may work well for a subset of applicants for a subset of companies. This, to some, is verification that these sorts of problems are a good way of narrowing down the applicant pool. Hence why they're used.
2) From Facebook (or any other employer)'s perspective, it's an incredibly hard job determining who will fit a given job specification. You may be great on paper, but be a total mismatch with regards to company ethos (I'm not saying you are, I'm just citing this as an example). The way (and that's assuming there is a particular way) of differentiating applicants and determining their suitability is not perfect. Different companies do it different ways, and all of this is constantly evolving. The fact that Facebook is using developers to conduct their interviews could be seen as progress to some compared to what there was x years ago in y company. It's never going to be perfect.
The fact that you've moved on from this and done a bunch of great stuff is fantastic. It's Facebook's loss. But instead of just commenting on why their system sucks, and why it didn't work for you, why not make some constructive suggestions on how it might be improved.
In my honest opinion, the way it can be improved is exactly the way my interview last Friday went:
I walked in, and did the introductions. I had two programming problems to solve, but these weren't puzzles. The two questions were fairly simple, that used a lot of basic features of the language they use in this shop.
The first question I couldn't remember the exact function names in the standard library (it's PHP, the stdlib is HUGE and stupid) but the interviewer helped me, and once I had the right functions in place, was easy.
The second question tested OOP knowledge, and again was easy for any actual programmer.
Then, once I'd passed that with flying colours, we moved on to the normal "interview".
This week, I'm going in for a day (paid), to see if I'm a good culture fit, and look at the projects I'll be working on.
I believe this is a brilliant way of interviewing and making sure you get the right candidate. Anyone who can't program will fail instantly (apparently thats a big problem here in Australia?), and then if the rest of the interview goes well, culture fit is actually TESTED (albeit as much as you can test in one day).
"...I realize I’m a pretty well-rounded and high-performing developer/engineer/architect. At the scale of Facebook, I’m exactly the sort of engineer I’d want many of...."
In my opinion there are at least three no-hire red flags attached to this statement.
I hate puzzles too, but that's primarily because I never know the answers :) On a serious note though, it is quite possible that companies use puzzles as a screening technique because they are not looking for you. Specifically, they are looking for not you.
Think about it, a big company needs an employee that would join them and work for at least 18 months in order to pay back the costs of hiring, but preferably stay for 3-4-5 years... as many as years as possible, if this is a good hacker we are talking about. Hiring someone who's likely to leave in 6 months is counter productive for a large company, and puzzles is one way to keep you away.
You'd have to ask someone who was at Facebooks and Googles in their early days and see if the hiring was based on puzzles. I suspect in those times a lot of decisions were made in much similar ways to how you'd want to do it now. Puzzles are not the answer, and large companies would probably agree with you too, but it's a tool that seems to work best for them and it's scalable to achieve a consisten outcome over a long term horizon. Precisely what large companies need.
Well, the OP statement "write a function which merges two sorted arrays without allocating any additional memory. Aside from having no real-world value, it’s not actually possible" seems strange.
Ok, any real-world usage might be applicable only in embedded systems which is a fairly narrow domain.
Still, it is a small (easy to describe) problem that can be used to see how the applicant does problem solving for problems without a widely known best/proper solution - and that skill is probably 90% of any serious programming; the remainder is just typing while following an arbitrary syntax which a trained monkey can do.
And the solution definitely exists - depending on how the interviewer wants output, you can either push the result out with a trivial iteration with a pointer on each array; or if the arrays aren't read only, you can sort them in-place with a slightly modified qsort or even bubblesort - both of these approaches don't need to allocate any memory on the heap, just 2 int counters in processor registers or stack.
This is standard undergraduate question in algorithms when I went to college. If you need N log(N) solution, look up in-situ mergesort. If you don't care about the order of algorithm, there are much simpler intuitive ways of doing it.
Assume that you have two sorted arrays A and B. At the end of it, A followed by B needs to be sorted. Here is a simple algorithm:
Sort(A,B):
if A[0] is greater than B[0], swap A[0] and B[0].
Bubble up B[0] to its right place (that is make B sorted).
Sort(A+1, B) -- stop if A reached its end.
Naive implementation, such as this is N^2. Leaving it to readers to make it N log(N), which is actually trivial.
That comes to a different point. When I was going to college in Computer science, we had to go through at least three courses in algorithms. We used to hand code most algorithms optimizing for the situation at hand. I suppose the advent of good libraries, and the bottlenecks elsewhere in the systems means that this generation may not find fundamentals of algorithms much use. Instead, they may find concepts in abstraction, higher order functions etc more useful.
"At my current company, we hire based on provable real-world experience."
That is also a pretty bad hiring schema, you are leaving out a great deal of potential great programmers that are just starting, so, which strategy is better? I guess you always leave people behind, if it works for you, it's the right choice, and it has been working for facebook.
Different hiring schemes work for different companies. Hell, even different teams within companies. If this works for FB there's a reason it is working.
Job offers will come and go. Don't burn bridges that you may want to cross later in your career.
Criticisms of the hiring process from those who didn't get hired are hard to take seriously--they may or may not be valid, but humans have a way of rationalizing defeat to protect their ego, and this cognitive dissonance tends to
dent the defeated's perspective badly.
You see this with any kind of objective test--IQ, SATs, etc. and, of course, subjective tests are subject to even more criticism.
Unfortunately, those who passed their interviews have little reason to criticize the status quo.
The best approach is a data-driven, experimental approach, of the kind likely to be taken by large companies. Small companies could do it too if they pooled their data.
Part of trying to get a job is learning about the interview practices of the company you are applying to. If they do puzzles then study some dumb puzzles. The puzzles usually aren't that hard and interviewers generally talk these types of problems over with you as you are solving them.
If you really want to work at Facebook, and you are a conscientious developer, then you'll study and be prepared for their kind of interview.
[+] [-] Ashoat|13 years ago|reply
This is referring to me.
The author has misrepresented the truth.
(1) The problem does not state that you may not allocate additional memory; only that the memory allocated must be constant relative to the size of your input.
(2) Given #1, this problem is absolutely possible.
(3) The problem explicitly asks you to merge the two arrays "in place". If by "clobbered" you mean changed, then that means that by definition one of the arrays will be "clobbered". We can certainly have a separate conversation about whether modifying structures in place is a good coding practice, but it is generally more efficient and highly widespread in non-functional languages.
I'm sure it wasn't purposeful, but I'm disappointed that the author misrepresented our conversation to make a point. Separately:
(4) This problem is extremely applicable to real-life programming IMHO. It does not use any esoteric data structures. It does not use any complicated algorithms. All you need to do is iterate through two arrays at the same time. A great majority of candidates have solved this problem.
In general I agree with this post's thesis. Facebook's general philosophy with interviews is to allow each interviewer to ask whatever questions they want, and the consequence is a variance in the type of questions getting asked. However, based on internal conversations I know that Facebook is trying to move away from "puzzle" questions by explicitly "retiring" a number of questions that we consider to be unproductive.
[+] [-] nilkn|13 years ago|reply
[+] [-] dlokshin|13 years ago|reply
In reading through the threads, there's a common underlying assumption that if you don't get the problem right, you won't get hired. That definitely is NOT the case in finance. We use the brain teasers and puzzles as a way to showcase how you think. For my interview, out of 5 brain teasers I nailed 2, was heavily helped through 2 more, and never got the last one, even with lots of help. But for each, the interviewer made it very clear that I was to think out loud. After getting the job, I later used the technique in interviews and gave positive reviews to those who had similarly struggled through puzzles but had used a similar thought process. In general we used this to weed out three different types of people:
1. Hard science majors who learned how to solve problems instead of think through problems. These people learned how to derive the heat diffusion equation, but would never put a story modeling a random walk in connection with that equation.
2. People who freeze when things get tough. Obviously a bad thing on the trade floor. While with coding you can often walk away from a hard problem, think about it, and come back, in finance, you can't walk away from losing lots of money over a short period of time ... you have to stop the bleeding.
3. People who learned how to think quickly and with rigorous process. The type of people you want.
[+] [-] smoyer|13 years ago|reply
I don't think it's fair to conclude he didn't get the FB job due to his failure to write a square root function. The funnier part is that this question isn't a puzzle (but does perhaps indicate how well the interviewee has internalized mathematics).
I suspect I'd have failed him for ego ... "Today, after releasing 25 Github projects, creating several widely-used apps in less than a day each, and designing an entire architecture for a streaming platform, I realize I’m a pretty well-rounded and high-performing developer/engineer/architect. At the scale of Facebook, I’m exactly the sort of engineer I’d want many of." I've been in the industry for 30 years and realize I still have so much to learn.
[+] [-] dguaraglia|13 years ago|reply
Don't get me wrong, I think everyone needs to have a certain confidence on their abilities and expertise, but it works both ways: when hiring for our startup we'd look for honesty and humble acknowledgment of the candidate's shortcomings/lack of expertise.
I wouldn't fail you for not knowing what the Newton's method for finding square roots is, but I will fail you for thinking it's irrelevant or not caring. If you don't care about my requirements in an interview, I don't think you'll do much better with actual work.
[+] [-] tylermenezes|13 years ago|reply
I am fairly objectively the sort of programmer they would want in the sense they seemed to be selecting on.
> This article is obviously somewhat over-stated. However, good programmers are aware of what they know and what they don't know, and maintaining a sense of imposter syndrome forever is somewhat counter-productive.
[+] [-] raverbashing|13 years ago|reply
"How often do you expect candidates to write a function to calculate the square root of a number? I would fire any developer who chose to re-implement standard library functions."
Not this crap again.
Oh and he says he has an "interest in formal computer science"
No, I don't expect you to reimplement square root. Or maybe I do, because that's what a lot of games do (or something similar) because you have to reach a balance between speed and accuracy.
Or maybe because we need a bigger precision than a double, again there are libraries, but again we may need something else that's not in the library.
So yes, absolutely, what I wouldn't hire is a "computer scientist" that can't work their way around a math problem.
Edit: oh it gets worse, he gives the "never parse HTML without a proper HTML parser" talk
Whine whine whine
Step 1 - learn the rules. Step 2 - learn when to break them
And it's only an example
FB didn't lose a "great engineer", they were right on target.
[+] [-] supercoder|13 years ago|reply
Though I wonder what the intent is here, say for the first question - "What is the pattern here ?"
After looking up the solution on wikipedia - http://en.wikipedia.org/wiki/Look-and-say_sequence I would have to admit there is no way I'd figure that out without knowing the concept ahead of time.
So are they looking for someone that knows the 'look and say sequence' explicitly ? Same way if you presented the meaning of numbers 80 or 443 to someone they'd either know or not, but not be able to guess.
Or did they actually expect someone to work it out on the spot ?
[+] [-] rbehrends|13 years ago|reply
This makes it a bit different from other problems, where the interviewer is often not even so much interested in the solution, but in how you go about finding one. Many other sequence problems are amenable to a more systematic approach that at least tell them something about your problem-solving techniques.
With the look-and-say sequence, you either see it or you don't. Regardless of whether you got it right or not, it doesn't tell an interviewer much about you, and is therefore not a good use of the limited time they have with you that could be used more productively.
[+] [-] tubs|13 years ago|reply
V : 1 2
ω : 1
P : (11 -> 21) (2 -> 12) (1 -> 11)
I think that matches the information given in the question. Would that be an "incorrect answer"?
[+] [-] mattgreenrocks|13 years ago|reply
My hope is that they'd hope a candidate would be able to identify the connection to run length encoding within the pattern.
Why do these puzzles emerge at big companies? It looks like a sort of institutional power trip emerges: "if you want to work with us, you need to be real good, and these are the sorts of problems we want you to think we deal with every day!" Except in most cases, they aren't, and there are plenty of mediocre folks already employed there. But the institution NEEDS to believe it only hires the best, and one way to perpetuate that belief is to haze new applicants more and more. All it really produces is candidates who are very lucky, or very compatible with the existing culture.
Hiring is hard, and puzzles are a fail-fast mechanism that is terrible, but produces some sort of results, so it gets used.
[+] [-] ajq5623|13 years ago|reply
I'm not sure if there being multiple "correct" answers makes me like the question or hate it. The Fibonacci sequence seems a bit more obvious though than the "look and say" answer.
[+] [-] Joe-Z|13 years ago|reply
[+] [-] bmuon|13 years ago|reply
I just figured it out on my own, from the comfort of my home, while having breakfast. In an interview with a top notch company that'll be a totally different story.
[+] [-] lucian1900|13 years ago|reply
[+] [-] brokentone|13 years ago|reply
[+] [-] BoyPopoy|13 years ago|reply
[deleted]
[+] [-] lucian1900|13 years ago|reply
I have a job I love now, but I don't feel like I deserve it. Overall, I suck. You probably do too.
[+] [-] miketwo|13 years ago|reply
> I would fire any developer who chose to re-implement standard library functions.
Who writes the standard library functions?
> never parse HTML without a proper HTML parser
Who writes the parsers?
On merging arrays in-place:
> Aside from having no real-world value, it’s not actually possible
It is possible, and has value when dealing with large data sets, which I'm sure is a common issue at Facebook. Here's another way to look at it: "Given two sorted 0.5 terabyte arrays on a terabyte drive, and 1 gb of memory, merge the two arrays without an additional drive."
There's no shame in not knowing or caring about things like this (it takes all kinds), but what the poster does (and seems to be good at) just may not be what Facebook was looking for.
> At the scale of Facebook, I’m exactly the sort of engineer I’d want many of.
Many possibly, but not only.
[+] [-] happywolf|13 years ago|reply
[+] [-] przemoc|13 years ago|reply
[+] [-] sergiosgc|13 years ago|reply
Criticism, if constructive, is not 100% negative. The post indeed criticizes Facebook, but also lays down an explanation of why Facebook's hiring practices are wrong. It contains useful information.
[+] [-] johnbellone|13 years ago|reply
One thing you need to remember is that technical people that are performing phone screens are going to do a little research on you as a future candidate, and this isn't the first impression you want to make when vying for a job.
[+] [-] BoyPopoy|13 years ago|reply
[deleted]
[+] [-] nbevans|13 years ago|reply
The article is well written but you really shouldn't put Facebook on some sort of pedestal. Especially after two years, it seems like you still feel sore about it. It really isn't "all that" to work at Facebook. Do you really want to write PHP all day, for example? For an engineer it is more a bragging right and CV fodder than anything else.
[+] [-] BenjaminN|13 years ago|reply
1°) I think you don't get it: when you're Facebook, Google or any other company receiving and interviewing thousands of candidates for a job, you're having a different hiring strategy than a small startup. Their strategy is "hiring a bad programmer costs us more than rejecting a good one". So they tend to reject good programmers, but they mostly reject bad programmers. In the end: they only hire good programmers, and that's what matters. In contrast, startups are having the "it costs us more to reject a good programmer than to hire a bad one" strategy. So they hire more easily, most of the time, even if in the end they hire average/bad programmers, they don't care.
2°) I was interviewed for a front-end job at facebook, and I didn't get in. I think I'm not the best programmer around, but I'm okay, and I would do a great job at facebook. And just so you know : my first interview question was way way way harder than any of your questions. I think those puzzles are a good way to spot good programmers amongst thousands of good/average/bad programmers. I'll give you a really simple example: find the highest number in an array. You can find it using several different ways, but if you just go through the whole array, you might be a good programmer, but the next person I'd interview might be one too, and he will find it with a much lower complexity. I'd hire him. Simple as that.
Bottom line — here's the question I was asked at facebook : you have a matrix of letters, and you have to find all the words you can do with it. For a front-end/product design job. And I'm not posting an article saying they suck at hiring.
[+] [-] Schwolop|13 years ago|reply
[+] [-] mohoyt|13 years ago|reply
1) They may work well for a subset of applicants for a subset of companies. This, to some, is verification that these sorts of problems are a good way of narrowing down the applicant pool. Hence why they're used.
2) From Facebook (or any other employer)'s perspective, it's an incredibly hard job determining who will fit a given job specification. You may be great on paper, but be a total mismatch with regards to company ethos (I'm not saying you are, I'm just citing this as an example). The way (and that's assuming there is a particular way) of differentiating applicants and determining their suitability is not perfect. Different companies do it different ways, and all of this is constantly evolving. The fact that Facebook is using developers to conduct their interviews could be seen as progress to some compared to what there was x years ago in y company. It's never going to be perfect.
The fact that you've moved on from this and done a bunch of great stuff is fantastic. It's Facebook's loss. But instead of just commenting on why their system sucks, and why it didn't work for you, why not make some constructive suggestions on how it might be improved.
[+] [-] girvo|13 years ago|reply
I walked in, and did the introductions. I had two programming problems to solve, but these weren't puzzles. The two questions were fairly simple, that used a lot of basic features of the language they use in this shop.
The first question I couldn't remember the exact function names in the standard library (it's PHP, the stdlib is HUGE and stupid) but the interviewer helped me, and once I had the right functions in place, was easy.
The second question tested OOP knowledge, and again was easy for any actual programmer.
Then, once I'd passed that with flying colours, we moved on to the normal "interview".
This week, I'm going in for a day (paid), to see if I'm a good culture fit, and look at the projects I'll be working on.
I believe this is a brilliant way of interviewing and making sure you get the right candidate. Anyone who can't program will fail instantly (apparently thats a big problem here in Australia?), and then if the rest of the interview goes well, culture fit is actually TESTED (albeit as much as you can test in one day).
I'm looking forward to this place actually :)
[+] [-] lynchdt|13 years ago|reply
"...I realize I’m a pretty well-rounded and high-performing developer/engineer/architect. At the scale of Facebook, I’m exactly the sort of engineer I’d want many of...."
In my opinion there are at least three no-hire red flags attached to this statement.
[+] [-] Kiro|13 years ago|reply
Where are the sidenotes?
[+] [-] tellarin|13 years ago|reply
[+] [-] kirillzubovsky|13 years ago|reply
Think about it, a big company needs an employee that would join them and work for at least 18 months in order to pay back the costs of hiring, but preferably stay for 3-4-5 years... as many as years as possible, if this is a good hacker we are talking about. Hiring someone who's likely to leave in 6 months is counter productive for a large company, and puzzles is one way to keep you away.
You'd have to ask someone who was at Facebooks and Googles in their early days and see if the hiring was based on puzzles. I suspect in those times a lot of decisions were made in much similar ways to how you'd want to do it now. Puzzles are not the answer, and large companies would probably agree with you too, but it's a tool that seems to work best for them and it's scalable to achieve a consisten outcome over a long term horizon. Precisely what large companies need.
[+] [-] PeterisP|13 years ago|reply
Ok, any real-world usage might be applicable only in embedded systems which is a fairly narrow domain.
Still, it is a small (easy to describe) problem that can be used to see how the applicant does problem solving for problems without a widely known best/proper solution - and that skill is probably 90% of any serious programming; the remainder is just typing while following an arbitrary syntax which a trained monkey can do.
And the solution definitely exists - depending on how the interviewer wants output, you can either push the result out with a trivial iteration with a pointer on each array; or if the arrays aren't read only, you can sort them in-place with a slightly modified qsort or even bubblesort - both of these approaches don't need to allocate any memory on the heap, just 2 int counters in processor registers or stack.
[+] [-] tantaman|13 years ago|reply
If all you need to do is print what the result of the merge would be then sure, a solution does exist.
[+] [-] kramarao|13 years ago|reply
Assume that you have two sorted arrays A and B. At the end of it, A followed by B needs to be sorted. Here is a simple algorithm:
Sort(A,B):
Naive implementation, such as this is N^2. Leaving it to readers to make it N log(N), which is actually trivial.That comes to a different point. When I was going to college in Computer science, we had to go through at least three courses in algorithms. We used to hand code most algorithms optimizing for the situation at hand. I suppose the advent of good libraries, and the bottlenecks elsewhere in the systems means that this generation may not find fundamentals of algorithms much use. Instead, they may find concepts in abstraction, higher order functions etc more useful.
[+] [-] dedsm|13 years ago|reply
That is also a pretty bad hiring schema, you are leaving out a great deal of potential great programmers that are just starting, so, which strategy is better? I guess you always leave people behind, if it works for you, it's the right choice, and it has been working for facebook.
[+] [-] johnbellone|13 years ago|reply
Job offers will come and go. Don't burn bridges that you may want to cross later in your career.
[+] [-] codex|13 years ago|reply
You see this with any kind of objective test--IQ, SATs, etc. and, of course, subjective tests are subject to even more criticism.
Unfortunately, those who passed their interviews have little reason to criticize the status quo.
The best approach is a data-driven, experimental approach, of the kind likely to be taken by large companies. Small companies could do it too if they pooled their data.
[+] [-] newobj|13 years ago|reply
[+] [-] tantaman|13 years ago|reply
If you really want to work at Facebook, and you are a conscientious developer, then you'll study and be prepared for their kind of interview.