given two full hours and any high-level language
(including pseudocode) only 10 percent of professional
programmers implemented binary search correctly,
according to Jon Bently.
Wow!
I'm not particularly intelligent and I'm not in the top 10% -- but I could implement an in-place quick-sort in C in 10 minutes that my interviewer could run with only a minor fix (forgot a semi-colon), and I even described the parallel version with OpenMP (although there I got the syntax slightly wrong). This was for my interview at Adobe, when I got hired by them a couple of years ago; went on to other things since then.
By that logic that should place me in the top 1 percent ... but so are my ~ 100 friends that are also software developers from my city, and statistically speaking, something smells like shit in those statistics thrown around.
Maybe binary search, when discovered, used to be a hard to understand problem, but now it is taught from high-school. And sure there are lots of idiots out there, but many of those idiots also believe they are in the top 10%, because some statistic told them so.
So cut the crap and build stuff. Only by that metric you can prove yourself.
-- EDIT --
I'm not referring or addressing the article's author directly. I'm also not saying that you SHOULD be able to implement binary search, or quick-sort or whatever metric du-jour -- in interview conditions. I get it that you may be stressed by eyes watching you, or that you may be bitten by edge-cases other people haven't noticed for years.
I'm referring more to these metrics flowing around -- like, if you read HN you're in the top 5%, if you read this stupid blog you're in the top X%, if you can implement binary search ... etc, etc...
We are software developers, mathematicians, computer scientists -- surely we understand selection bias and should be able to recognize bullshit, even if it doesn't appeal to our ego.
Ive choked on some very simple programming problems in circumstances where I am being closely watched. I need to be by myself to think about problems and attack the problem incrementally. Somehow having an audience seems to force me to attack the whole problem at once before writing anything. In short, I don't know if my experience is unique but there might be other programmers who under perform when being closely watched.
I sometimes just completely fail to function at a whiteboard. I've choked to comedic proportions on problems I'd solved easily only a few days before. There's not a doubt in my mind that my resume's been thrown in the "Non-programming programmer" pile due to my stage fright at least once. I can certainly sympathize with the need for a low false-positive rate, but as a candidate I can't help but wish that overcoming stage fright wasn't also such a prerequisite for working with good programmers.
Don't be so pompous. Most people know how to implement it, it's not a difficult concept. It's just that there are edge cases and intricacies of implementation that yield bugs.
The quote I'm referring to mentions pseudocode, which makes integers overflowing and stuff like that irrelevant, since that's dependent on the integer representation you're using.
It's not integer overflow that makes the problem difficult. It's off-by-one errors in the predicates (< vs. <=) and indexing operations (n/2 vs (n+1)/2).
Not arguing with you as that gets many good people during interviews. But I'm going to provide some anecdotal evidence to the contrary ...
In binary search this problem comes from the length of an array, which is either odd or even, and then you're doing a division by 2, which should trigger alarms in your head all over. And just as when you were taught in your first CS class (either high-school or college) you pick 2 simple examples for both cases, and test with pen and paper (tools provided during any interview).
When I did interviews from the employer's side -- the people not doing this were either totally unprepared, failing most other questions, or brilliant (and lazy) people that considered the problem too easy to bother checking the implementation.
Surely, put into context it can provide a valuable filter, but it's not saying much about the top X% of the talent pool, which my post was about.
It depends on how the test was given. For example, did they ask you to write quicksort == you submit a version and then they grade it. If so I can imagine a lot of little mistakes... from the integer overflow issue (if they did pick a language), to off by one errors, to not handling empty lists, or the case where the item isn't in the list, or other errors that if someone were to say, "it doesn't work with this input" you could easily fix it, but if not given a chance for correction many could easily get wrong.
There was a post a while ago on HN about how a very large of the people applying for a given job are in the bottom fraction of the total talent pool. Essentially, the good people get hired quickly (or are never looking for someone else to pay them in the first place), and don't apply for lots of jobs, whereas the people who don't get hired keep applying for other jobs, thus stinking up the statistics.
The sad truth is that many people who program professionally simply cannot so basic programming tasks. If anything, I think top 10% might be overestimating how many can do it - I suspect 10% might have some kind of idea of how binary search would work, but most of them will fail with edge cases etc.
Agreed. Saying because you can do <insert easy/trivial task here> you are in the top X percent just means that the rest of the (100-X)% are incompetent. Being "above average" isn't really saying much when the average is dismal.
I'm not particularly intelligent and I'm not in the top 10% -- but I could implement an in-place quick-sort in C in 10 minutes that my interviewer could run with only a minor fix (forgot a semi-colon), and I even described the parallel version with OpenMP (although there I got the syntax slightly wrong). This was for my interview at Adobe, when I got hired by them a couple of years ago; went on to other things since then.
By that logic that should place me in the top 1 percent ... but so are my ~ 100 friends that are also software developers from my city, and statistically speaking, something smells like shit in those statistics thrown around.
Maybe binary search, when discovered, used to be a hard to understand problem, but now it is taught from high-school. And sure there are lots of idiots out there, but many of those idiots also believe they are in the top 10%, because some statistic told them so.
So cut the crap and build stuff. Only by that metric you can prove yourself.
-- EDIT --
I'm not referring or addressing the article's author directly. I'm also not saying that you SHOULD be able to implement binary search, or quick-sort or whatever metric du-jour -- in interview conditions. I get it that you may be stressed by eyes watching you, or that you may be bitten by edge-cases other people haven't noticed for years.
I'm referring more to these metrics flowing around -- like, if you read HN you're in the top 5%, if you read this stupid blog you're in the top X%, if you can implement binary search ... etc, etc...
We are software developers, mathematicians, computer scientists -- surely we understand selection bias and should be able to recognize bullshit, even if it doesn't appeal to our ego.