5 ms·

Ask HN: Code reviews instead of whiteboard for interviews

25 points by devnonymous 10y ago

I initially started writing this as an Ask HN but it exceeded the 2000 word limit so posted it on Medium here: https://medium.com/@lonetwin/code-reviews-instead-of-whiteboard-for-interviews-e0b66f8db71b Would love to hear thoughts on this from the excellent folk here.

afarrell 10y ago
I've had an interview where the interviewer showed me a poorly-written flask app and asked me to code review it with him. I felt that it was a pretty good interview. I've also had one where I wrote a thing ahead of time and then code reviewed it with them. I also thought it was a good experience and I got a sense of how it would be like to work with them. I suspect that trying to do it for an actual piece of production code would require too much context.
clueless123 10y ago
When requested to code on a language I have not used in a while, I have to go back and code on it for a while before getting back on the "zone" (quickly remembering libraries, usages etc). In comparison, I think I could quickly be ready to go through a code review on any language I ever been proficient.. probably because It does not requires you to remember minutia?
stephenbez 10y ago
I've recently started giving a code review interview. I show them a toy example involving a few classes and a some tests and ask them to review it in terms of correctness, maintainability, testability, etc. Once they've identified some problem areas, I then have them edit the code and ask them to make the changes they suggested. I think it's been working well since there have been examples of people doing well on algorithms questions, but not noticing a single problem with lots of bad code. I think the question works better for more experienced candidates.
seanwilson 10y ago
Code reviews during an interview sounds like it would give good insights to me but why not do both? People are way too melodramatic about having to write code during interviews.
- lsiebert 10y ago
  I'm happy to write code on a computer. Whiteboarding is a cultural artifact.
  - gravypod 10y ago
    It depends. If they expect psudocode then I have no problem with that (just writing down the steps of the solution). If they expect doing some 100% implementation of a large project in Java, I'd say no thanks.
  - seanwilson 10y ago
    I agree it's not ideal but people talk about it like it's the end of the world.
  - devnonymous 10y ago
    I agree with that. My problem with whiteboarding is you almost never do that in the course of your daily work. The idea was about introducing more of what we do in the course of a typical day in the interview process.
flukus 10y ago
I like the idea, but I would add that it doesn't need to be done during an interview. I think it would be better if we let the candidate check out the code and review it from home, maybe write out a longer and more detailed review of the code, including the good and the bad, not just the problems. It would be great from the candidates point of view as well. Usually you don't get a real indication of the companies code practices until you start. In fact, before starting a new job I think you should be able to review the companies code base.
tedmiston 10y ago
I like code reviews or practice tasks like "add feature x to this codebase" because of the focus on modifying an existing system vs building a tiny one from scratch. That's a much more realistic representation of daily developer work.
tedmiston 10y ago
> The colleague I mentioned earlier was new to the company and among other things that we spoke about, we seemed to disagree on whether or not it is a good idea to introduce new patterns/paradigms into existing codebase. I am of the opinion that code should appear as though written by a single author even if it has been worked on by different people. His was that introducing newer patterns improves the quality of the code. While I agreed to an extent with him, I would vote against this if it violates the principle of least surprise[1]. Regarding that point, I disagree with you as well. To totally abstain from new patterns / paradigms make it easier for a codebase to become completely legacy to the point of needing a full rewrite. And full rewrites never happen [1]. In general, I favor reducing tech debt with gradual adaptation of new patterns supported by good unit tests and high test coverage for codebases in ongoing projects. Admittedly I have no idea the functionality or role of the specific codebase you're referring to, but that is my general philosophy. [1]: "Things You Should Never Do, Part I" by Joel Spolsky http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

25 points by devnonymous 10y ago

afarrell 10y ago

I've had an interview where the interviewer showed me a poorly-written flask app and asked me to code review it with him. I felt that it was a pretty good interview. I've also had one where I wrote a thing ahead of time and then code reviewed it with them. I also thought it was a good experience and I got a sense of how it would be like to work with them. I suspect that trying to do it for an actual piece of production code would require too much context.

clueless123 10y ago

When requested to code on a language I have not used in a while, I have to go back and code on it for a while before getting back on the "zone" (quickly remembering libraries, usages etc). In comparison, I think I could quickly be ready to go through a code review on any language I ever been proficient.. probably because It does not requires you to remember minutia?

stephenbez 10y ago

I've recently started giving a code review interview. I show them a toy example involving a few classes and a some tests and ask them to review it in terms of correctness, maintainability, testability, etc. Once they've identified some problem areas, I then have them edit the code and ask them to make the changes they suggested. I think it's been working well since there have been examples of people doing well on algorithms questions, but not noticing a single problem with lots of bad code. I think the question works better for more experienced candidates.

seanwilson 10y ago

Code reviews during an interview sounds like it would give good insights to me but why not do both? People are way too melodramatic about having to write code during interviews.

lsiebert 10y ago
I'm happy to write code on a computer. Whiteboarding is a cultural artifact.
- gravypod 10y ago
  It depends. If they expect psudocode then I have no problem with that (just writing down the steps of the solution). If they expect doing some 100% implementation of a large project in Java, I'd say no thanks.
- seanwilson 10y ago
  I agree it's not ideal but people talk about it like it's the end of the world.
- devnonymous 10y ago
  I agree with that. My problem with whiteboarding is you almost never do that in the course of your daily work. The idea was about introducing more of what we do in the course of a typical day in the interview process.

flukus 10y ago

I like the idea, but I would add that it doesn't need to be done during an interview. I think it would be better if we let the candidate check out the code and review it from home, maybe write out a longer and more detailed review of the code, including the good and the bad, not just the problems. It would be great from the candidates point of view as well. Usually you don't get a real indication of the companies code practices until you start. In fact, before starting a new job I think you should be able to review the companies code base.

tedmiston 10y ago

I like code reviews or practice tasks like "add feature x to this codebase" because of the focus on modifying an existing system vs building a tiny one from scratch. That's a much more realistic representation of daily developer work.

tedmiston 10y ago

> The colleague I mentioned earlier was new to the company and among other things that we spoke about, we seemed to disagree on whether or not it is a good idea to introduce new patterns/paradigms into existing codebase. I am of the opinion that code should appear as though written by a single author even if it has been worked on by different people. His was that introducing newer patterns improves the quality of the code. While I agreed to an extent with him, I would vote against this if it violates the principle of least surprise[1]. Regarding that point, I disagree with you as well. To totally abstain from new patterns / paradigms make it easier for a codebase to become completely legacy to the point of needing a full rewrite. And full rewrites never happen [1]. In general, I favor reducing tech debt with gradual adaptation of new patterns supported by good unit tests and high test coverage for codebases in ongoing projects. Admittedly I have no idea the functionality or role of the specific codebase you're referring to, but that is my general philosophy. [1]: "Things You Should Never Do, Part I" by Joel Spolsky http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html