4 ms·

> Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if the

> Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit. I've worked in organizations where the hiring process the OP is advocating for (short one hour, possibly non-technical, interviews) demonstrably led to serious problems in that organization. Have you ever sat in on technical software engineer interviews? It's beyond horrifying how many developers I've seen that have a great resume, a decent portfolio, talk a big game, but literally can't solve a fizzbuzz-style problem on a whiteboard. I'd say the percentage in my area of developers who fail at this is at least 80%! Think about that... if your hiring procedures are lax, possibly 4 out of every 5 developers on your team will be ludicrously incompetent. I don't care how tight the hiring market gets; dumbing down interviews is simply not an option with those kinds of odds. If you haven't already seen it, you should read Atwood's article on the same subject: "Why Can't Programmers.. Program?" [1]. [1] http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

freework 13y ago
Youre under the assumption that "can't do fizzbuzz == can't program", "can do fizzbuzz == can program", which isn't true. I'll tell you a secret. The first time I was asked to do fizzbuzz in an interview I got it wrong. It was about a year ago. I have been programming sine I was in middle school (I'm 29 now). Walking out of that interview was probably the worst day in my entire life. Ever since then, two things have happened. First, the lines of fizzbuzz are forever etched into my mind. I can recite fizzbuzz verbally now. I don't even need any writing utensil. For i in xrange 1 comma 101 colon if i mod fifteen equals zero colon print "fizzbuzz" elif... [and so on]". This has come in handy in interviews since. All you have to say is "fizzbuzz" and I go ahead and write away. I don't even need the interviewer to explain the actual wording of the problem. And the second thing is that I now have absolutly zero interrest in hiring a company that has fizzbuzz (or any other live coding portion) as part of it's hiring process. If I'm at an interview and the interviewer tells me "we're going to write code now", I'm done. If the problem is interesting I'll do it, but if it's fizzbuzz or anything having to do with reinventing something, I'm done. Not gonna work there. I've struggled to put into words how to describe why I think live coding is such a terrible thing to ask candidates during interviews. Joel Spolsky makes a great point thats hard to argue against. If you're hiring a guitar player, you want to hear him play. If you're hiring a programmer, you'd first want to see them write code. I think the problem is that programming is kind of more like song writing. You can't ask a song writer to go the white board and bang out a new song. Even if you tell him exactly what the song should be about. Song writing is a process, and so is programming.

freework 13y ago

Youre under the assumption that "can't do fizzbuzz == can't program", "can do fizzbuzz == can program", which isn't true. I'll tell you a secret. The first time I was asked to do fizzbuzz in an interview I got it wrong. It was about a year ago. I have been programming sine I was in middle school (I'm 29 now). Walking out of that interview was probably the worst day in my entire life. Ever since then, two things have happened. First, the lines of fizzbuzz are forever etched into my mind. I can recite fizzbuzz verbally now. I don't even need any writing utensil. For i in xrange 1 comma 101 colon if i mod fifteen equals zero colon print "fizzbuzz" elif... [and so on]". This has come in handy in interviews since. All you have to say is "fizzbuzz" and I go ahead and write away. I don't even need the interviewer to explain the actual wording of the problem. And the second thing is that I now have absolutly zero interrest in hiring a company that has fizzbuzz (or any other live coding portion) as part of it's hiring process. If I'm at an interview and the interviewer tells me "we're going to write code now", I'm done. If the problem is interesting I'll do it, but if it's fizzbuzz or anything having to do with reinventing something, I'm done. Not gonna work there. I've struggled to put into words how to describe why I think live coding is such a terrible thing to ask candidates during interviews. Joel Spolsky makes a great point thats hard to argue against. If you're hiring a guitar player, you want to hear him play. If you're hiring a programmer, you'd first want to see them write code. I think the problem is that programming is kind of more like song writing. You can't ask a song writer to go the white board and bang out a new song. Even if you tell him exactly what the song should be about. Song writing is a process, and so is programming.