3 ms·

There's a need to watch the candidate code at least once, and at least for simpler problems, simply because if you don't watch them you can never be sure they'r

There's a need to watch the candidate code at least once, and at least for simpler problems, simply because if you don't watch them you can never be sure they're not cheating by getting real-time help from someone else.

kasey_junk 12y ago
This gets trotted out a lot as a reason for "watching" someone code, and I don't find that to be very compelling. 1 - I don't think "cheating" is rampant. Obviously opinions will vary, but if you think that you are getting a lot of cheaters in your hiring pipeline, I would suggest the problem is in the funnel part not the evaluation part. 2 - I view getting help on a programming problem to be a good thing. I suppose in certain environments you need to make sure that your hiring candidates are not collaborating with others, but I'd be surprised if that was common. The idea that it is bad to seek outside help on work problems is some weird vestige of our education system, not an actual day to day issue with most developer jobs. 3 - It is much more important to find out if a candidate understands the code they've submitted and thought about the trade offs they've made (or didn't) as well as if they can explain it to the people around them. This is true regardless of how the code was produced. We suss this out with our colleagues all the time, and at least in my professional career its never been via watching someone work. We have tools like code review, discussion, documentation etc to do that.
- FLUX-YOU 12y ago
  >The idea that it is bad to seek outside help on work problems is some weird vestige of our education system, not an actual day to day issue with most developer jobs. You do need some knowledge up front and immediately accessible. However, almost no one agrees what that body of knowledge should be per position (and it's never going to be the same across positions or companies). Part of that is because you need to be able to practically communicate to someone about the things he's going to be responsible for. The other parts are actually doing the job and reducing the ramp up time. The more accommodating positions will need less up-front knowledge (e.g. hiring any junior developer). They're okay if you don't know a few basics but you need to demonstrate something. You can't be too accommodating or what is the difference between him and someone from another field with no knowledge? You also can't require too much knowledge up-front, or you just end up hunting for purple squirrels. Everyone (that is sane) already accepts that there is some ramp up time. 'Hitting the ground running', which is what people with a lot of up-front knowledge should be able to do, should be a luxury, not a requirement. Asking it of someone who isn't prepared is asking for a technical debt loan from the mafia loan sharks. The reason hiring managers seek people who can do this is because it means more work done in the same amount of time. The conventional way to break into the industry is a CS degree and an internship, but that's not set in stone (contrast: medical doctors/scientists/etc). However, the industry still accommodates the self-taught crowd and other quirky origins because the body of knowledge we require to work in this industry is just so diverse and not agreed upon at all.

kasey_junk 12y ago

This gets trotted out a lot as a reason for "watching" someone code, and I don't find that to be very compelling. 1 - I don't think "cheating" is rampant. Obviously opinions will vary, but if you think that you are getting a lot of cheaters in your hiring pipeline, I would suggest the problem is in the funnel part not the evaluation part. 2 - I view getting help on a programming problem to be a good thing. I suppose in certain environments you need to make sure that your hiring candidates are not collaborating with others, but I'd be surprised if that was common. The idea that it is bad to seek outside help on work problems is some weird vestige of our education system, not an actual day to day issue with most developer jobs. 3 - It is much more important to find out if a candidate understands the code they've submitted and thought about the trade offs they've made (or didn't) as well as if they can explain it to the people around them. This is true regardless of how the code was produced. We suss this out with our colleagues all the time, and at least in my professional career its never been via watching someone work. We have tools like code review, discussion, documentation etc to do that.

FLUX-YOU 12y ago
>The idea that it is bad to seek outside help on work problems is some weird vestige of our education system, not an actual day to day issue with most developer jobs. You do need some knowledge up front and immediately accessible. However, almost no one agrees what that body of knowledge should be per position (and it's never going to be the same across positions or companies). Part of that is because you need to be able to practically communicate to someone about the things he's going to be responsible for. The other parts are actually doing the job and reducing the ramp up time. The more accommodating positions will need less up-front knowledge (e.g. hiring any junior developer). They're okay if you don't know a few basics but you need to demonstrate something. You can't be too accommodating or what is the difference between him and someone from another field with no knowledge? You also can't require too much knowledge up-front, or you just end up hunting for purple squirrels. Everyone (that is sane) already accepts that there is some ramp up time. 'Hitting the ground running', which is what people with a lot of up-front knowledge should be able to do, should be a luxury, not a requirement. Asking it of someone who isn't prepared is asking for a technical debt loan from the mafia loan sharks. The reason hiring managers seek people who can do this is because it means more work done in the same amount of time. The conventional way to break into the industry is a CS degree and an internship, but that's not set in stone (contrast: medical doctors/scientists/etc). However, the industry still accommodates the self-taught crowd and other quirky origins because the body of knowledge we require to work in this industry is just so diverse and not agreed upon at all.