4 ms·

I'm really conflicted when I keep hearing that programmers can't program, especially in such a high number (199 out of 200). I've done a fair bit of interviewi

by cbanek 10y ago

I'm really conflicted when I keep hearing that programmers can't program, especially in such a high number (199 out of 200). I've done a fair bit of interviewing (on both sides), and while I've seen some bad people, it seems like if 199 out of 200 candidates couldn't write code, then we'd have a lot of out of work coders, since as everyone also complains about, everyone has to write code when doing interviews. 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. I always like to let a candidate go to their strongest area, if that is a particular technology or problem, or bit of code they've written, because then I know I should be able to ask them deep questions (performance, design tradeoffs) that actually matter on their job, instead of fizz buzz or inverting a binary tree. There's also just the possibility of nerves, or other factors as well. It's fun to follow people on linkedin and keep up good relations even if they're a no-hire, to see if your hunch was right, or dead wrong.

jasode 10y ago
>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 https://en.wikipedia.org/wiki/D._E._Shaw_%26_Co. [2]http://www.streetofwalls.com/finance-training-courses/quantitative-hedge-fund-training/quant-interview-questions-answers/ http://www.streetofwalls.com/finance-training-courses/quanti...
- wlievens 10y ago
  So high-end finance is the only "complicated" software out there?
  - w1ntermute 10y ago
    No, they can just have higher standards, since there's more interest in working there (due to the high pay).
  - busterarm 10y ago
    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.
- laughinghan 10y ago
  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%
  - jasode 10y ago
    Yep - I fixed the typo.
  - edoceo 10y ago
    0.5% of pontificators can pontificate
LyndsySimon 10y ago
> 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.
- lhecker 10y ago
  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.
- busterarm 10y ago
  > 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.
greggman 10y ago
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
- cbanek 10y ago
  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.

by cbanek 10y ago

jasode 10y ago

>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 https://en.wikipedia.org/wiki/D._E._Shaw_%26_Co. [2]http://www.streetofwalls.com/finance-training-courses/quantitative-hedge-fund-training/quant-interview-questions-answers/ http://www.streetofwalls.com/finance-training-courses/quanti...

wlievens 10y ago
So high-end finance is the only "complicated" software out there?
- w1ntermute 10y ago
  No, they can just have higher standards, since there's more interest in working there (due to the high pay).
- busterarm 10y ago
  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.
laughinghan 10y ago
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%
- jasode 10y ago
  Yep - I fixed the typo.
- edoceo 10y ago
  0.5% of pontificators can pontificate

LyndsySimon 10y ago

> 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.

lhecker 10y ago
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.
busterarm 10y ago
> 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.

greggman 10y ago

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

cbanek 10y ago
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.