Hacker News Reader

My experience isn't 199 out of 200 but it's still like 7 out of 8. I ran my own company, we started interviewing people for programming positions. They'd show up for the interview and an hour into the interview we'd figure out they can't program. It wasted our time.

So, we changed our strategy and started using a couple of fizzbuzz like questions. The moment they walked in the door we'd hand them the test, a pencil, sit them down at a desk and say "take as long as you want". Then we'd go back to work. When they finished we'd look. If they couldn't pass the test we'd kindly show them the door. If they could then the real interview started.

I guess I don't see how any one who can truely program couldn't answer fizzbuzz or any similarly simple non-puzzle question. How simple would it have to be before you'd decide they can't do it. If you asked them to make "Hello World" in the language of their choice and they couldn't do it would you give them the benefit of the doubt or show them the door?

Also I wouldn't put inverting a binary tree at the same level of fizzbuzz. Fizzbuzz is literally 1 to 6 lines of code depending on your coding style. It's 1 step past "write a loop that counts from 1 to 100". If they can't write a simple loop and check for 2 conditions (or 3 if you think it's 3) they can't code. Really. They can't

It honestly depends also at what level they are in the pipeline, and maybe we've already screened out the other people that can't code before we even ask them to, so I don't dump them in the bucket of people who can't code.

Phone screen - maybe 3 out of 10 pass (ish), most are meh, and 1 or 2 out of 10 is terrible. Onsite - because of weeding out at the phone screen level, I think it's maybe 1 in 10 that can't program (or I question their fundamentals), and 1 in 8 that an offer is made, and most are floundering somewhere in between. Most can program but either can't solve the problem, or don't understand some key concepts in the solution.

Adding more gates to reduce the amount of time you're wasting onsite is definitely the right thing. I personally think the phone screen is pretty valuable, as annoying as they are.

>hearing that programmers can't program, especially in such a high number (199 out of 200).

Fyi... that 199/200 quote came from J Spolsky that he got from D E Shaw.[1] That's a hedge fund and like other computational finance firms, they would look for strong programmers who had very good math skills (statistics, probabilities, etc).[2]

Therefore, the typical web programmer who knows the difference between HTML tags and CSS selectors, or knows text slicing with Python/PERL, will not pass the rigorous interviews. Using that criteria, it's very realistic that less than 0.5% of applicants would be hired.

Another way to put it: those trading firms are looking for math nerds who happen to know how to program more than programmers who happen to know some math. Including them in the general discussion about "what's wrong with hiring" will skew the discussion. Most everybody else is just looking for CRUD/web/iOS/etc programmers.

[1]https://en.wikipedia.org/wiki/D._E._Shaw_%26_Co.

[2]http://www.streetofwalls.com/finance-training-courses/quanti...

So high-end finance is the only "complicated" software out there?

No, they can just have higher standards, since there's more interest in working there (due to the high pay).

Their software isn't even usually that complicated (I used to work at D. E. Shaw). It's all just translating their models into code.

They just only want STEM Ph.D.s because it makes it easier to justify the ~2+20 fees they charge even when they have a bad year.

Does it make me a math nerd if I point out that accepting 0.05% of applications would mean rejecting 1,999 out of 2,000?

TL;DR: I think you mean 0.5%

Yep - I fixed the typo.

0.5% of pontificators can pontificate

> Just because someone can't do exactly the type of program you're looking for, or in a particular way, doesn't mean they can't program. It only means they couldn't program what you asked in the way you asked. A fail for sure, but that doesn't always mean what you think.

Two relevant examples of this come to mind.

The first is that the author mentions recursion as a fundamental skill. While I agree, as a Python developer the vast majority of my experience with recursion is thinking "Oh, wait - I can't do that, I'll reach the stack limit". In fact I would go so far as to argue that for any language without proper tail recursion, recursion is almost certainly the wrong way to solve a problem.

The second is the oDesk Python proficiency exam. I took it on a whim a while back and failed. Many of the questions were about obscure parts of the Python standard library. I can't imagine many jobs requiring me to know how to parse email message archives without opening the docs, but apparently that's what they were looking for.

I think what'd be even more interesting is whether a candidate can transform a simple recursive algorithm to an iterative one and vice versa.

It's taught in CS courses for instance but I know a lot of software "engineers" who aren't able to come up with a solution for such problems. (Hint: It's rampant in the webdev crowd)

As a side note: Yeah I also think that recursion is really seldom needed, but sometimes it's actually your only option. For instance I wrote a Future/Promise library with support for continuation for Rust (it'd be the same for C++). Simply said: Since the Promise is a generic the actual type (and thus it's machine code) changes from type to type so you have to use virtual function calls to invoke the next promise in the continuation chain. This obviously has the disadvantage compared to dynamic languages that the chain length is limited by the stack size.

> While I agree, as a Python developer the vast majority of my experience with recursion is thinking "Oh, wait - I can't do that, I'll reach the stack limit". In fact I would go so far as to argue that for any language without proper tail recursion, recursion is almost certainly the wrong way to solve a problem.

Thank you for pointing out the thing that I couldn't remember that always bothered me the times that I had to work in Python. I'm blown away by the vast amount of work being done in that language without it, thought I understand Guido's reasons...and I agree with yours about using recursion in it.

I think in 2016 it should be clearly established that tail recursion is a fundamental programmer right! It is time to write it into programmer constitution.

"If JavaScript has it, what are you doing without it?"