> Or we can assume that the company that does the hiring via 60 second challenge is not ran by complete idiots and they do keep track whether those hires end up being effective employees for them. Let's give them the benefit of a doubt.
You don't seem to be aware of just how disastrous a bad hiring decision can be. The direct financial cost is easily in the tens to hundreds of thousands of dollars, depending on how long it takes to identify their poor performance, warn them, and finally fire them (all the while documenting their performance rigorously to avoid frivolous lawsuits later on). Beyond that, the opportunity cost of having a poor programmer in place of an excellent one is even worse. It is far, far better to avoid a bad hire in the first place than to catch them later.
> Your argument seems to be that there are only two possible programmers: effective designers that are slow to code or fast coders that are bad designers (designer in terms of code architecture, not graphic design, of course).
I'm sorry, but you wrote a lengthy rebuttal to an argument I never made. Read my comment again. When describing the "10x" programmer, I never said that they had to be a slow coder. In fact, I explicitly said they "may be" lightning fast. My actual argument was merely that the most dramatic improvements in software construction speed are due to making better decisions about what to code, what tools to use, how to approach the problem, etc. And, in my opinion, the benefits of making good decisions about these things absolutely dwarf the benefits of being able to slam out the code in record time.
You don't seem to be aware of just how disastrous a bad hiring decision can be. The direct financial cost is easily in the tens to hundreds of thousands of dollars, depending on how long it takes to identify their poor performance, warn them, and finally fire them (all the while documenting their performance rigorously to avoid frivolous lawsuits later on). Beyond that, the opportunity cost of having a poor programmer in place of an excellent one is even worse. It is far, far better to avoid a bad hire in the first place than to catch them later.
> Your argument seems to be that there are only two possible programmers: effective designers that are slow to code or fast coders that are bad designers (designer in terms of code architecture, not graphic design, of course).
I'm sorry, but you wrote a lengthy rebuttal to an argument I never made. Read my comment again. When describing the "10x" programmer, I never said that they had to be a slow coder. In fact, I explicitly said they "may be" lightning fast. My actual argument was merely that the most dramatic improvements in software construction speed are due to making better decisions about what to code, what tools to use, how to approach the problem, etc. And, in my opinion, the benefits of making good decisions about these things absolutely dwarf the benefits of being able to slam out the code in record time.