4 ms·

This is the way the company I work for currently does it. They provide the candidate with a piece of terrible code, ask for a code review of as many issues as

This is the way the company I work for currently does it. They provide the candidate with a piece of terrible code, ask for a code review of as many issues as the candidate can find, and also for a refactored copy of the code. Both of which are completed remotely on the dev's own time. This is before even meeting the candidate in person. Once we meet in person for the first time, another terrible piece of code is provided -- in this case a basic data structure -- and another code review is requested. The candidate is given 15 minutes to complete it. It's interesting what comes back. Some people comment only stylistic issues, others only logical or architectural issues. One person got up and left during their alone time. Other than these, no coding is required. So far, it's worked out pretty well. And when I was going through it, I enjoyed it.

BrandonM 13y ago
I think that a lot of companies forget that they are also being interviewed during their interviews. Were I to interview at your company, I would think that your employees spend most of their time performing code review. I would probably walk out, too.
- scrabble 13y ago
  I can understand that take on it. Our take is more that if you can recognize what is wrong with the code on multiple levels then you can most likely write good code. This is easier to check on non-trivial code when done through a code review then by getting the interviewee to write the same kind of code that every other interview looks for. The submitted code sample does this as well. I'd also want people on my team to be able to successfully refactor legacy code just by looking at it and being able to identify where things can be better cleaned up and tested.
  - BrandonM 13y ago
    I am completely behind code review and refactoring. I am our company's Chief Refactorer (a title I just made up, but it's accurate), and after instituting code review a few months ago, it has made our development process so much better. At this point, I hate merging in a feature that I've written without having someone else review it. So that's not my issue. I was pointing out that your interview process seems to involve only code review, based on your comment above. Put yourself in an interviewer's shoes: in two different instances, you've been presented with bad code and asked to code review it. Personally, I would be concerned that (1) your company writes bad code, and (2) I'm going to be expected to spend all my time reviewing and fixing other people's bad code instead of writing code myself. Now I doubt that's actually the reality of working at your company (at least I hope so!), but first impressions are very important, and that's what your interview process would tell me if I were interviewing there.

BrandonM 13y ago

I think that a lot of companies forget that they are also being interviewed during their interviews. Were I to interview at your company, I would think that your employees spend most of their time performing code review. I would probably walk out, too.

scrabble 13y ago
I can understand that take on it. Our take is more that if you can recognize what is wrong with the code on multiple levels then you can most likely write good code. This is easier to check on non-trivial code when done through a code review then by getting the interviewee to write the same kind of code that every other interview looks for. The submitted code sample does this as well. I'd also want people on my team to be able to successfully refactor legacy code just by looking at it and being able to identify where things can be better cleaned up and tested.
- BrandonM 13y ago
  I am completely behind code review and refactoring. I am our company's Chief Refactorer (a title I just made up, but it's accurate), and after instituting code review a few months ago, it has made our development process so much better. At this point, I hate merging in a feature that I've written without having someone else review it. So that's not my issue. I was pointing out that your interview process seems to involve only code review, based on your comment above. Put yourself in an interviewer's shoes: in two different instances, you've been presented with bad code and asked to code review it. Personally, I would be concerned that (1) your company writes bad code, and (2) I'm going to be expected to spend all my time reviewing and fixing other people's bad code instead of writing code myself. Now I doubt that's actually the reality of working at your company (at least I hope so!), but first impressions are very important, and that's what your interview process would tell me if I were interviewing there.