Facebook Lost a Great Engineer
medium.com
medium.com
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.
We talked it through and he removed the part that bothered me. I'm actually gonna hang out with him tonight...
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.
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.
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 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.
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 ?
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.
In short, if you can't write a simple FizzBuzz program, then you are probably not a good developer. Questions like these are good for being a quick way to separate programmers from those who cannot program at all.
But I agree - as someone who sucks at puzzles under pressure, questions like 'what's next after 111221?' seems like a totally retarded question to me.
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.
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"?
Your major problem would be finding an interviewer who knows what's an L-System
Edit: you should add the rule 111->31, so it may not be an l-system because there are infinite rules? (1111->41), etc
Or we limit it up to digit 9
That's an issue with any sequence-style problems.
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 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.
I have a job I love now, but I don't feel like I deserve it. Overall, I suck. You probably do too.
> 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.
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.
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.
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.
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.
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 :)
Some will (largely correctly) say that if that's the filter they use against me then I wouldn't want to work there in the first place. The problem is that it allows these types of discrimination to feel justified because we all discuss them under the euphemism "culture fit" instead of calling them exactly what they are: blatant discrimination. Personally I think if you have a filter that you would use to disqualify someone, you should be willing to state it plainly.
For example..
Positives:
* Person is a go getter, gets things done, doesn't get blocked
* Person is meticulous, pays careful attention to detail
* Person is a good communicator, articulating explanations eloquently
* Person stumbles around an incorrect solution until hints are given
* Person jumps to conclusion without considering the bigger picture (or the edge cases)
* Person doesn't seem to get it, or at least can't explain himself/herself well
And this can then be inferred from the technical "coding" question, or in more traditional companies they will ask direct questions (usually known as "behavioral" questions) that focus on just those personality traits.
To give a particular example, at Amazon the "culture fit" of a candidate is how well they adhere to the company's leadership principles:
Your amazon link seems to be a good way to define "culture fit". All companies should do this instead of keeping it vague.
"...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.
Where are the sidenotes?
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.
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.
If all you need to do is print what the result of the merge would be then sure, a solution does exist.
The basic idea is to use the (unused) beginning of array b as swap space for the beginning of array a. This swap space needs to be shifted around, so it's of course O(n^2). Still, it was fun to write.
If you have termcolor installed ('sudo easy_install termcolor' on ubuntu), you'll see the arrays a and b as well as the swap space highlighted in color for each step. Example: http://dl.dropbox.com/u/2135523/2013022517.png
I wasn't saying you can't sort arrays in place (quicksort). I was saying you can't merge them in place. Somebody has to grow.
For any practical purpose that's as good as a contiguous array, and in embedded systems you might even make so that the initial two arrays are already contiguous in memory.
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.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.
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.
Job offers will come and go. Don't burn bridges that you may want to cross later in your career.
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.
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.
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