Facebook Lost a Great Engineer

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.

Tyler, I have two things to say about this.

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.

Merge them in-place - if the inital array A had 400 items and array B 600 items, then put the sorted first 400 items in original array A and the last 600 items in array B.

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.

It does and that's what I generally understood it to mean. The problem to me is that its so vague that it serves as a blanket justification for denying someone employment based on "gut feeling" or other basically discriminatory practices. It seems like it can also include "is willing to be in the office 12 hrs a day because he has no home life". No one would actually codify this in writing, but I have a feeling these are the types of filters that fall under "culture fit".

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.

Without any other information, how can you possibly implement max() without going through the whole array?