5 ms·

I don't think that's good enough. It's unfair to ask candidates to write code on the spot.

by serve_yay 11y ago

eru 11y ago
Why? Isn't writing code exactly what you are interviewing for?
- learc83 11y ago
  How often are you asked to solve a problem in 15 minutes while someone watches over your shoulder?
  - eli 11y ago
    Seems like you'd have a similar problem with almost any job interview for any type of position.
    - learc83 11y ago
      Ask your friends who aren't software engineers. How many of them solve problems they've never seen before while someone watches over them during an interview? The vast majority of other professions spend their time talking about past projects. For instance all my designer friends show off their portfolios, then maybe they get a take home work sample. My writer friends submit samples of their work. And my engineer friends discuss past projects they've worked on.
      - eli 11y ago
        I take your point, but actually I work in media and a lot of my writer friends had to take writing or editing tests as part of their interview.
- fapjacks 11y ago
  Maybe if you give the candidate four hours. But in the hour or so that is ubiquitous among individual interviews (even if repeated four or five times with different interviewers), you aren't going to be any meaningful information out of anything the interviewee will have time to code. An hour is enough time to write something trivial. Anything that really pushes a developer's skills is going to need a big part of that hour just for them to put pen to paper for design. The best interviews I ever had involved a week-long spare-time development project at my own pace. Those are the only interviews I ever was able to really show what I'm capable of. Incidentally, my interview at the Googleplex I thought was worthless.
  - eru 11y ago
    Interesting. They'd need to pay me quite a lot of money for a weeks worth of effort.
    - fapjacks 11y ago
      Well, I would say the total tasks were tasks taking about a handful of hours, but the deadlines were about a week out from when they were given. So essentially, they were spreading the "normal" five or six hours worth of interviewing with developers and doing trivial tasks (that I think don't really show the interviewer what kind of programmer I am), but compressed into one project, meanwhile time-wise spread out across a week. I've interviewed maybe five times like this (most recently twice last year). Definitely I felt like the code they got was a good representation of the kind of code I write normally. I would never agree to working for a week for a job interview without pay. Though most recently I had an interview where the guys didn't even ask for my resume once. They only ever looked over my Github, which for me was a nice touch, and made me feel like those guys know wtf they're doing. I should mention here that I interview for fun continually, otherwise I would have taken the one the guys offered who didn't even ask for my resume.
dataminer 11y ago
I have had my share of bad interviews but I don't agree with this sentiment, why is it unfair? Haven't you ever been in a situation where you have to create a hot fix and deploy it as fast as you can. Haven't you ever gone through a crunch period where the deadline is closing in and and you have to fix that elusive bug. There is limited time for everything, the sooner we realize that the better. Having control over your nerves when s* hits the fan is a valuable quality, which we should all strive for. Most of these interviews are tests to see your approach to solving a problem. The best practice is to come up with a strategy before you hit the first key, ask as many questions as you can and find as many corner cases as you can. All the sane interviewers will appreciate that even if you don't end up with the best solution. And please treat all interviews as a learning experience, you will be much better off.
- learc83 11y ago
  I must've been working in a much different environment than you. I've never had to solve a difficult problem in 15 minutes while someone who knew the solution watched over my shoulder and did their best to answer my questions without answering them too well. Ohh yeah and the results of my performance had potentially life changing consequences. The adversarial and extreme time boxed nature of a coding interview is something that is truly outside the day to day experience of the vast majority of programmers. >Having control over your nerves when s* hits the fan is a valuable quality, which we should all strive for. That may be true, but think about that for a minute. Go back to college and think of how many people in the class were comfortable going up to the board and solving problems in front of everyone. When I was taking Automata, we could get an extra point on our final grade by going to the board and correctly working out a problem that we hadn't seen before. Only myself and 2 other people ever did it--in a class of 60. Do you think that your company is solving problems so hard and paying so well that you can can only consider 3 out of every 60 developers (or whatever the real ratio is) who are otherwise qualified who have also mastered control of their nerves far beyond what is required 99% of the time on the job? Maybe if you're Google, for the rest of us we need to find a better solution. By the way, even though I was able to solve problems at the board, I hated every minute of it, and I refuse to work for companies that require this kind of interview.
jeff_marshall 11y ago
I sort-of disagree. If you aren't judging whether they get a correct working solution (i.e. passes some unit tests after running it through the compiler/interpreter), and actively engaging them on their thought process while they attempt to find a solution, it can be a useful tool (esp. in early filtering with really trivial problems). Interpreting the results, and picking the coding problem, are not easy tasks. That said, I've certainly found myself in the position described by the story, and all I can say is that I'm glad I've never actually needed to find a job in my career (new opportunities have always come from people who already know me and my track record). You may (though I wouldn't bet on it) get fewer bad "hire" decisions by doing a code interview like the one in the article, but you also get bad "no-hire" decisions. I'd love to see some empirical data on the subject from someone who knows how to design an experiment.
jmilloy 11y ago
Fairness is definitely not relevant here. But, an interview technique can be useful for a company or not. Asking candidates to write code on the spot isn't inherently useful or not useful. Assessing a candidates typos and compiler errors smugly is probably not very useful. But assessing their approach to understanding expectations, understanding problems, and solving problems is useful. If a candidate just assumes the expectations without asking in the interview, they are likely to do the same on the job.

I don't think that's good enough. It's unfair to ask candidates to write code on the spot.

eru 11y ago

Why? Isn't writing code exactly what you are interviewing for?

learc83 11y ago
How often are you asked to solve a problem in 15 minutes while someone watches over your shoulder?
- eli 11y ago
  Seems like you'd have a similar problem with almost any job interview for any type of position.
  - learc83 11y ago
    Ask your friends who aren't software engineers. How many of them solve problems they've never seen before while someone watches over them during an interview? The vast majority of other professions spend their time talking about past projects. For instance all my designer friends show off their portfolios, then maybe they get a take home work sample. My writer friends submit samples of their work. And my engineer friends discuss past projects they've worked on.
    - eli 11y ago
      I take your point, but actually I work in media and a lot of my writer friends had to take writing or editing tests as part of their interview.
fapjacks 11y ago
Maybe if you give the candidate four hours. But in the hour or so that is ubiquitous among individual interviews (even if repeated four or five times with different interviewers), you aren't going to be any meaningful information out of anything the interviewee will have time to code. An hour is enough time to write something trivial. Anything that really pushes a developer's skills is going to need a big part of that hour just for them to put pen to paper for design. The best interviews I ever had involved a week-long spare-time development project at my own pace. Those are the only interviews I ever was able to really show what I'm capable of. Incidentally, my interview at the Googleplex I thought was worthless.
- eru 11y ago
  Interesting. They'd need to pay me quite a lot of money for a weeks worth of effort.
  - fapjacks 11y ago
    Well, I would say the total tasks were tasks taking about a handful of hours, but the deadlines were about a week out from when they were given. So essentially, they were spreading the "normal" five or six hours worth of interviewing with developers and doing trivial tasks (that I think don't really show the interviewer what kind of programmer I am), but compressed into one project, meanwhile time-wise spread out across a week. I've interviewed maybe five times like this (most recently twice last year). Definitely I felt like the code they got was a good representation of the kind of code I write normally. I would never agree to working for a week for a job interview without pay. Though most recently I had an interview where the guys didn't even ask for my resume once. They only ever looked over my Github, which for me was a nice touch, and made me feel like those guys know wtf they're doing. I should mention here that I interview for fun continually, otherwise I would have taken the one the guys offered who didn't even ask for my resume.

dataminer 11y ago

I have had my share of bad interviews but I don't agree with this sentiment, why is it unfair? Haven't you ever been in a situation where you have to create a hot fix and deploy it as fast as you can. Haven't you ever gone through a crunch period where the deadline is closing in and and you have to fix that elusive bug. There is limited time for everything, the sooner we realize that the better. Having control over your nerves when s* hits the fan is a valuable quality, which we should all strive for. Most of these interviews are tests to see your approach to solving a problem. The best practice is to come up with a strategy before you hit the first key, ask as many questions as you can and find as many corner cases as you can. All the sane interviewers will appreciate that even if you don't end up with the best solution. And please treat all interviews as a learning experience, you will be much better off.

learc83 11y ago
I must've been working in a much different environment than you. I've never had to solve a difficult problem in 15 minutes while someone who knew the solution watched over my shoulder and did their best to answer my questions without answering them too well. Ohh yeah and the results of my performance had potentially life changing consequences. The adversarial and extreme time boxed nature of a coding interview is something that is truly outside the day to day experience of the vast majority of programmers. >Having control over your nerves when s* hits the fan is a valuable quality, which we should all strive for. That may be true, but think about that for a minute. Go back to college and think of how many people in the class were comfortable going up to the board and solving problems in front of everyone. When I was taking Automata, we could get an extra point on our final grade by going to the board and correctly working out a problem that we hadn't seen before. Only myself and 2 other people ever did it--in a class of 60. Do you think that your company is solving problems so hard and paying so well that you can can only consider 3 out of every 60 developers (or whatever the real ratio is) who are otherwise qualified who have also mastered control of their nerves far beyond what is required 99% of the time on the job? Maybe if you're Google, for the rest of us we need to find a better solution. By the way, even though I was able to solve problems at the board, I hated every minute of it, and I refuse to work for companies that require this kind of interview.

jeff_marshall 11y ago

I sort-of disagree. If you aren't judging whether they get a correct working solution (i.e. passes some unit tests after running it through the compiler/interpreter), and actively engaging them on their thought process while they attempt to find a solution, it can be a useful tool (esp. in early filtering with really trivial problems). Interpreting the results, and picking the coding problem, are not easy tasks. That said, I've certainly found myself in the position described by the story, and all I can say is that I'm glad I've never actually needed to find a job in my career (new opportunities have always come from people who already know me and my track record). You may (though I wouldn't bet on it) get fewer bad "hire" decisions by doing a code interview like the one in the article, but you also get bad "no-hire" decisions. I'd love to see some empirical data on the subject from someone who knows how to design an experiment.

jmilloy 11y ago

Fairness is definitely not relevant here. But, an interview technique can be useful for a company or not. Asking candidates to write code on the spot isn't inherently useful or not useful. Assessing a candidates typos and compiler errors smugly is probably not very useful. But assessing their approach to understanding expectations, understanding problems, and solving problems is useful. If a candidate just assumes the expectations without asking in the interview, they are likely to do the same on the job.