3 ms·

I have had good luck hiring developers by asking them to do a code review of something WE wrote (but framed as if a junior developer wrote it) This helps us lo

I have had good luck hiring developers by asking them to do a code review of something WE wrote (but framed as if a junior developer wrote it) This helps us look for good signal around their communication skills, mentoring skills, empathy, reasoning skills and software development skills. We used this review as a diagnostic - there are no wrong answers since we know they’re not aware of our style guide and conventions. It worked for us. Maybe it could work for others.

lytefm 5y ago
I'm using the same technique. Taking MRs from Junior Devs together with the Ticket description, reducing the scope a bit and sprinkling different errors or incomplete implementations here and there. In the interview, I'm checking of problems that the applicant notices and see how he approaches the problem. So far I've been satisfied with all hired who passed that test. And they liked not having to solve stupid whiteboard problems.
gwittel 5y ago
I do something very similar and it works quite well for anyone except fresh grads (I've a different variant for them). I pose a situation and introduce the v1 code. They look for bugs and propose fixes. Then I add on a new feature, and they look for more bugs. I've maybe 4-5 levels overall each having different classes of bugs, some of more or less subtlety. Fits on one whiteboard / single piece of paper in the end. There are no syntax errors, just logic. Errors are in categories like: robustness, failure handling (internal or external), data/thread races, unforseen side effects, etc. The more experienced you are, the more problems I expect to be found. A "I don't know" is just fine (and often the following discussion is MORE informative).
- roberthahn 5y ago
  I _really_ like this variant! In my experience new grads never seemed to have too much trouble with the exercise but then I do explain that it’s diagnostic in nature and use the exercise to see how coachable they are.
bojo 5y ago
That is such a refreshing approach to the process. May borrow this next time I hire a developer. Thanks for sharing.

lytefm 5y ago

I'm using the same technique. Taking MRs from Junior Devs together with the Ticket description, reducing the scope a bit and sprinkling different errors or incomplete implementations here and there. In the interview, I'm checking of problems that the applicant notices and see how he approaches the problem. So far I've been satisfied with all hired who passed that test. And they liked not having to solve stupid whiteboard problems.

gwittel 5y ago

I do something very similar and it works quite well for anyone except fresh grads (I've a different variant for them). I pose a situation and introduce the v1 code. They look for bugs and propose fixes. Then I add on a new feature, and they look for more bugs. I've maybe 4-5 levels overall each having different classes of bugs, some of more or less subtlety. Fits on one whiteboard / single piece of paper in the end. There are no syntax errors, just logic. Errors are in categories like: robustness, failure handling (internal or external), data/thread races, unforseen side effects, etc. The more experienced you are, the more problems I expect to be found. A "I don't know" is just fine (and often the following discussion is MORE informative).

roberthahn 5y ago
I _really_ like this variant! In my experience new grads never seemed to have too much trouble with the exercise but then I do explain that it’s diagnostic in nature and use the exercise to see how coachable they are.

bojo 5y ago

That is such a refreshing approach to the process. May borrow this next time I hire a developer. Thanks for sharing.