4 ms·

We use a similar tool during phone screens: http://rextester.com/runcode http://rextester.com/runcode Doing so has dramatically improved the screening process

by nsb1 12y ago

We use a similar tool during phone screens: http://rextester.com/runcode http://rextester.com/runcode Doing so has dramatically improved the screening process for us. This site allows real-time multi-person interactive coding sessions in a variety of languages (note: If you try the "live cooperation" mode, you need to click the link yourself as well as give it to others. This wasn't obvious for some people. ) As for whether or not coding problems on the phone or the whiteboard are a good idea, in my opinion they are when applied properly. There is no way I am going to hire someone for a software development position without seeing them write some code, and there is no way I am hiring someone for an embedded C position without knowing that they understand how pointers work. There are not that many reliable ways to do this in a controlled environment. We know that everyone can use google to find answers - I'm more interested in where people are starting from. There is a balance though. I do not ask interviewees to solve brain teasers; that sort of problem only serves to increase stress in the interview. Most of the problems I ask are simple, such as printing out multiplication tables or simple string manipulation, or linked list type questions for embedded C. When doing these on a whiteboard, I am very clear up-front that trivial errors like missing punctuation or spelling do not matter. I am interested in seeing how the candidate approaches the problem logically, and it is surprisingly obvious what sort of candidate you are dealing with when seeing them attack a problem.

kasey_junk 12y ago
> There is no way I am going to hire someone for a software development position without seeing them write some code How often do you watch your currently hired developers as they actually produce the code? How does the best of them handle you standing over their shoulder judging their typing technique? I'm unfairly giving you a hard time because you seem to have a sensible approach to hiring, but you should definitely know that watching people code, impacts the code they write. I've also found little evidence that people that are good at coding in front of someone, are necessarily better at the final product, than people that need some space to code.
- igammarays 12y ago
  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.

by nsb1 12y ago

kasey_junk 12y ago

> There is no way I am going to hire someone for a software development position without seeing them write some code How often do you watch your currently hired developers as they actually produce the code? How does the best of them handle you standing over their shoulder judging their typing technique? I'm unfairly giving you a hard time because you seem to have a sensible approach to hiring, but you should definitely know that watching people code, impacts the code they write. I've also found little evidence that people that are good at coding in front of someone, are necessarily better at the final product, than people that need some space to code.

igammarays 12y ago
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.