4 ms·

> A single bad engineer could theoretically destroy a company if they were savvy enough. This sentence does not compute. Anyways, I think a big portion of th

> A single bad engineer could theoretically destroy a company if they were savvy enough. This sentence does not compute. 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. This results in crazy interview multi-hour processes. In the real world, the worst employees rarely ever negate the work of more experienced workers. Thats like saying if you hire a bad teacher, students will forget information rather than learn.

tekromancr 13y ago
I think bad in this sense is malicious as opposed to incompetent.
- vonmoltke 13y ago
  There is almost nothing about multi-hour coding interviews that does anything to filter out the malicious, unless they happen to be incompetent as well. Screening out malicious people is a very hard task.
vonmoltke 13y ago
Agreed. Many people parrot this line, but I have not seen anyone put actual data behind it. I have seen made-up scenarios about what could happen. Those usually stick to near worst case situations, though, with no indication of the actual risk. People also seem to minimize or ignore the cost of a no-hire. If your company has an open position it is trying to fill, it should be feeling pain. Work isn't getting done. Projects or clients can't be bid on. Current engineers are working overtime to meet commitments. If you can look at this situation, shrug your shoulders, and say, "Eh, we're going along fine. We can wait several months for a perfect fit.", then I think you need to re-evaluate why you have an open position in the first place. I would like to see some actual data to back up this conception. Something that gives the actual statistical risk. As someone mentioned on another story here recently, humans tend to over-estimate the risks of negative events. I think the risk of bad hires in SV has been seriously over-estimated.
- hso9791 13y ago
  In my observation, the rule that people get promoted to their highest level of incompetence holds true way too often. I.e. the incompetent new guy just has to fake it long enough that he gets promoted. Now his incompetence has leverage. He can most likely shove responsibility onto others, and eventually gets promoted again. More leverage. If I were to start an organization, I would make damned sure that every single new hire could do what they were hired to do - and then some. Otherwise, the office dynamics may lead to a stagnant organization over time.
karlmdavis 13y ago
> 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.
mason55 13y ago
> This sentence does not compute. Meaning. Someone who is bad at programming but savvy about interacting with their coworkers, bosses, etc. Someone who might be able to keep a job long enough to really fuck stuff up even though they're bad at what they're doing. Six months in you realize that they've built a bunch of terrible stuff into the system and now you need multiple people to tear it out and rebuild.

tekromancr 13y ago

I think bad in this sense is malicious as opposed to incompetent.

vonmoltke 13y ago
There is almost nothing about multi-hour coding interviews that does anything to filter out the malicious, unless they happen to be incompetent as well. Screening out malicious people is a very hard task.

vonmoltke 13y ago

Agreed. Many people parrot this line, but I have not seen anyone put actual data behind it. I have seen made-up scenarios about what could happen. Those usually stick to near worst case situations, though, with no indication of the actual risk. People also seem to minimize or ignore the cost of a no-hire. If your company has an open position it is trying to fill, it should be feeling pain. Work isn't getting done. Projects or clients can't be bid on. Current engineers are working overtime to meet commitments. If you can look at this situation, shrug your shoulders, and say, "Eh, we're going along fine. We can wait several months for a perfect fit.", then I think you need to re-evaluate why you have an open position in the first place. I would like to see some actual data to back up this conception. Something that gives the actual statistical risk. As someone mentioned on another story here recently, humans tend to over-estimate the risks of negative events. I think the risk of bad hires in SV has been seriously over-estimated.

hso9791 13y ago
In my observation, the rule that people get promoted to their highest level of incompetence holds true way too often. I.e. the incompetent new guy just has to fake it long enough that he gets promoted. Now his incompetence has leverage. He can most likely shove responsibility onto others, and eventually gets promoted again. More leverage. If I were to start an organization, I would make damned sure that every single new hire could do what they were hired to do - and then some. Otherwise, the office dynamics may lead to a stagnant organization over time.

karlmdavis 13y ago

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

mason55 13y ago

> This sentence does not compute. Meaning. Someone who is bad at programming but savvy about interacting with their coworkers, bosses, etc. Someone who might be able to keep a job long enough to really fuck stuff up even though they're bad at what they're doing. Six months in you realize that they've built a bunch of terrible stuff into the system and now you need multiple people to tear it out and rebuild.