"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."<p>This is referring to me.<p>The author has misrepresented the truth.<p>(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.<p>(2) Given #1, this problem is absolutely possible.<p>(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.<p>I'm sure it wasn't purposeful, but I'm disappointed that the author misrepresented our conversation to make a point. Separately:<p>(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.<p>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.
A Finance sector perspective:<p>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:<p>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.<p>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.<p>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"?<p>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).<p>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.
Sorry for the off topic but<p>"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."<p>Not this crap again.<p>Oh and he says he has an "interest in formal computer science"<p>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.<p>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.<p>So yes, absolutely, what I wouldn't hire is a "computer scientist" that can't work their way around a math problem.<p>Edit: oh it gets worse, he gives the "never parse HTML without a proper HTML parser" talk<p>Whine whine whine<p>Step 1 - learn the rules. Step 2 - learn when to break them<p>And it's only an example<p>FB didn't lose a "great engineer", they were right on target.
Yeah these sort of questions are pretty ridiculous.<p>Though I wonder what the intent is here, say for the first question - "What is the pattern here ?"<p>After looking up the solution on wikipedia - <a href="http://en.wikipedia.org/wiki/Look-and-say_sequence" rel="nofollow">http://en.wikipedia.org/wiki/Look-and-say_sequence</a> I would have to admit there is no way I'd figure that out without knowing the concept ahead of time.<p>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.<p>Or did they actually expect someone to work it out on the spot ?
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 <i>should</i> have been able to do those puzzles better.<p>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".<p>> I would fire any developer who chose to re-implement standard library functions.<p>Who writes the standard library functions?<p>> never parse HTML without a proper HTML parser<p>Who writes the parsers?<p>On merging arrays in-place:<p>> Aside from having no real-world value, it’s not actually possible<p>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."<p>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.<p>> At the scale of Facebook, I’m exactly the sort of engineer I’d want many of.<p>Many possibly, but not only.
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.<p>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.
Tyler, I have two things to say about this.<p>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.<p>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.<p>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:<p>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.<p>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.<p>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.
You did not get the job because of your attitude.<p>"...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...."<p>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.<p>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.<p>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.<p>Ok, any real-world usage might be applicable only in embedded systems which is a fairly narrow domain.<p>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.<p>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.
"At my current company, we hire based on provable real-world experience."<p>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.
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.<p>You see this with any kind of objective test--IQ, SATs, etc. and, of course, subjective tests are subject to even more criticism.<p>Unfortunately, those who passed their interviews have little reason to criticize the status quo.<p>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.<p>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.
Yet another take on puzzles.. I reckon people are asked puzzles because if you can solve them, the probability of you solving real world problems is higher.<p>Now that your raw intelligence/interest is proved, it's now a question of whether you have the tenacity to maintain huge codebases with your team