4 ms·

After reading the article, I feel like a code test and discussion and or whiteboard would have filtered the type of developer they mentioned who is a net negati

After reading the article, I feel like a code test and discussion and or whiteboard would have filtered the type of developer they mentioned who is a net negative on the code base.

thescribe 10y ago
This is a good counter-argumnent to the frequent article decrying whiteboard tests.
- beekums 10y ago
  I feel like whiteboarding is really essential when talking about how code should be written, but most whiteboard tests are about writing code on the whiteboard. There's a big difference between the two activities.
  - pryelluw 10y ago
    Good point. The whiteboard should be used to discuss the problem and the solution. Not the actual code.
- tensor 10y ago
  How does a whiteboard test speak to documentation and code quality? By definition pseudo code is not production code and writing production style documented and compiling code on the whiteboard sounds like a terrible idea.
- ryhamz 10y ago
  Only if you assume it actually works, which is the most blatantly circular logic in this thread. This guy could have said "I feel like a daily prayer in the server room would filter bad devs" and it would be just as proven as his feeling about whiteboarding.
  - rokosbasilisk 10y ago
    maybe if prayer required some coding ability
greglindahl 10y ago
I've seen devs that passed a code test and discussion that had this problem. For example, you can interview someone on a good day, when most of their days are bad days. I don't think there's a magic interview style that prevents this problem. Corrective action and fast firing if necessary have worked for me. And whatever you do, don't impose onerous procedures on all of your devs because one of them screws up on a regular basis!
- beekums 10y ago
  > And whatever you do, don't impose onerous procedures on all of your devs because one of them screws up on a regular basis! This is a really important point. Creating processes for the lowest common denominator just stifles every other developer.
  - Karunamon 10y ago
    Seconded. Sometimes the answer to a mistake being made is not to take on a boatload of process in an attempt to make sure it can't happen again, it's to slap the hands of the offending person and say don't do that.
- rokosbasilisk 10y ago
  Ive never done the interviewing, so Im not sure. But if someone fails their code test or discussion doesnt that suggest they are a higher risk factor for being a "net negative"?
- falsedan 10y ago
  Corollary: also don't make processes which enforce the habits of your top performers
- deleted 10y ago
  [deleted]
phyller 10y ago
I agree with the code test, the discussion and whiteboard I would say depends on the type of developer. The former member of my team that produced negative work did well with discussions and popular little whiteboard problems. Our normal policy has become to have applicants do a mini project that represents actual work that we are doing. So far it has worked flawlessly. This guy didn't have to do that because he was so experienced. He ended up creating over-complicated, very buggy code that took more time for us to review than it would have taken for someone else to write. And when we needed to make even minor changes to his code the fastest way to do it was to just delete it all and start from scratch, everything was so complicated and codependent. He had an appearance of technical skill, was very well spoken, knew all the interview questions and answers, but had really bad judgment and somewhat poor logic when he had to come up with novel solutions. On the contrary, I taught myself and didn't have the CS background to do well in purely technical interviews. But I was given the practical challenge and crushed it. I knew what I needed to know for my job. Of course I had a lot to learn (and still do), but I was productive from the start, or so I have been told. I guess there is nothing wrong with whiteboard tests, but I think a practical coding challenge where the applicant makes part of an application is much more valuable. You can see that they have basic coding ability, but also how they organize code and break down larger problems. Can they get the big picture right while making clean, maintainable code?
collyw 10y ago
That sounds wrong to me. I was good at code tests straight out of university (when I practiced that sort of thing). 13 years later I am a far better software developer, keeping things simple but functional. I am a lot worse at code tests now, as I hardly ever need to write that type of code. I am able to design things in a way that doesn't usually need complex code to achieve the required functionality.

After reading the article, I feel like a code test and discussion and or whiteboard would have filtered the type of developer they mentioned who is a net negative on the code base.

thescribe 10y ago

This is a good counter-argumnent to the frequent article decrying whiteboard tests.

beekums 10y ago
I feel like whiteboarding is really essential when talking about how code should be written, but most whiteboard tests are about writing code on the whiteboard. There's a big difference between the two activities.
- pryelluw 10y ago
  Good point. The whiteboard should be used to discuss the problem and the solution. Not the actual code.
tensor 10y ago
How does a whiteboard test speak to documentation and code quality? By definition pseudo code is not production code and writing production style documented and compiling code on the whiteboard sounds like a terrible idea.
ryhamz 10y ago
Only if you assume it actually works, which is the most blatantly circular logic in this thread. This guy could have said "I feel like a daily prayer in the server room would filter bad devs" and it would be just as proven as his feeling about whiteboarding.
- rokosbasilisk 10y ago
  maybe if prayer required some coding ability

greglindahl 10y ago

I've seen devs that passed a code test and discussion that had this problem. For example, you can interview someone on a good day, when most of their days are bad days. I don't think there's a magic interview style that prevents this problem. Corrective action and fast firing if necessary have worked for me. And whatever you do, don't impose onerous procedures on all of your devs because one of them screws up on a regular basis!

beekums 10y ago
> And whatever you do, don't impose onerous procedures on all of your devs because one of them screws up on a regular basis! This is a really important point. Creating processes for the lowest common denominator just stifles every other developer.
- Karunamon 10y ago
  Seconded. Sometimes the answer to a mistake being made is not to take on a boatload of process in an attempt to make sure it can't happen again, it's to slap the hands of the offending person and say don't do that.
rokosbasilisk 10y ago
Ive never done the interviewing, so Im not sure. But if someone fails their code test or discussion doesnt that suggest they are a higher risk factor for being a "net negative"?
falsedan 10y ago
Corollary: also don't make processes which enforce the habits of your top performers
deleted 10y ago
[deleted]

phyller 10y ago

I agree with the code test, the discussion and whiteboard I would say depends on the type of developer. The former member of my team that produced negative work did well with discussions and popular little whiteboard problems. Our normal policy has become to have applicants do a mini project that represents actual work that we are doing. So far it has worked flawlessly. This guy didn't have to do that because he was so experienced. He ended up creating over-complicated, very buggy code that took more time for us to review than it would have taken for someone else to write. And when we needed to make even minor changes to his code the fastest way to do it was to just delete it all and start from scratch, everything was so complicated and codependent. He had an appearance of technical skill, was very well spoken, knew all the interview questions and answers, but had really bad judgment and somewhat poor logic when he had to come up with novel solutions. On the contrary, I taught myself and didn't have the CS background to do well in purely technical interviews. But I was given the practical challenge and crushed it. I knew what I needed to know for my job. Of course I had a lot to learn (and still do), but I was productive from the start, or so I have been told. I guess there is nothing wrong with whiteboard tests, but I think a practical coding challenge where the applicant makes part of an application is much more valuable. You can see that they have basic coding ability, but also how they organize code and break down larger problems. Can they get the big picture right while making clean, maintainable code?

collyw 10y ago

That sounds wrong to me. I was good at code tests straight out of university (when I practiced that sort of thing). 13 years later I am a far better software developer, keeping things simple but functional. I am a lot worse at code tests now, as I hardly ever need to write that type of code. I am able to design things in a way that doesn't usually need complex code to achieve the required functionality.