5 ms·

I basically built an entire product to help make the phone-coding situation better. It's called CoderPad (https://coderpad.io https://coderpad.io) and it basica

by akanet 12y ago

I basically built an entire product to help make the phone-coding situation better. It's called CoderPad (https://coderpad.io https://coderpad.io) and it basically tries to mimic a more natural coding environment inside the browser, for the purposes of conducting interviews. For example, if you're used to Ruby, you'll get a full REPL with debug information and tab-assist, etc. It obviously can't do too much for the psychological side of the problem, but I believe that getting the interview environment as close as possible to your natural coding environment is definitely a needle-mover when it comes to candidate comfort during interviews.

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.

by akanet 12y ago

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.