
Ask HN: Code reviews instead of whiteboard for interviews - devnonymous
I initially started writing this as an Ask HN but it exceeded the 2000 word limit so posted it on Medium here:<p>https:&#x2F;&#x2F;medium.com&#x2F;@lonetwin&#x2F;code-reviews-instead-of-whiteboard-for-interviews-e0b66f8db71b<p>Would love to hear thoughts on this from the excellent folk here.
======
afarrell
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.

------
stephenbez
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.

------
tedmiston
> 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)

------
clueless123
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?

------
tedmiston
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.

------
flukus
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.

------
seanwilson
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
I'm happy to write code on a computer. Whiteboarding is a cultural artifact.

~~~
gravypod
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.

