Fixing the coding part of interviews

How we got here

If you’re a programmer, there’s a 99% chance you’ve been in this part of an interview:

How we actually code

That’s not how humans write code these days. Code is too complicated to write on a whiteboard. We have special-purpose software that enables us to write code faster, smarter, and more productively every day. I have four linters keeping me honest with every keystroke, and two machine-learning systems supplying me with code constructs, so I can focus on the part that needs actual human intervention.

  • knowledge and learning potential
  • adaptability to new situations, even if it takes a minute
  • working well with others, including critiquing and improving each others’ work
  • finding and explaining the root cause of problems
  • coming up with solutions for problems
  • explaining why something is or is not a good solution in context

The Solution: Other People’s Code

My variant on Jakob’s Law states “Programmers spend most of their time looking at code other than their own.”[3]

  1. You are given a short block of code in your preferred language, and a series of tests for it.
  2. Some of the tests are failing. There is also a note from the code’s author, who is on vacation this week, sorry.
  3. I ask you to talk through the code and explain what you see, including why the tests are failing.
  4. I ask you to talk through solutions for making the code behave correctly and the tests pass. This might be improvements to the code, fixing the tests, dusting off and nuking from orbit, whatever.
  • Can they understand the code? Can they explain it to me? Do they understand what parts are important and what parts are boilerplate? Do they make use of all available info (e.g.: code, comments, API documentation, etc., etc.)
  • Can they see the flaws? How quickly do they find them, and what methods do they use to find them?
  • Can they explain the behavior in human terms, and hypothesize what’s causing any problems?
  • Can they come up with plausible solutions, and explain to me why those solutions are appropriate?
  • Can they critique code in a way that will make the original coder comfortable enough to accept the input and improve the work?

Summary

tl;dr: Interview using code reviews, not blank-board coding. It is more true to life, and tells you much more about how the candidate will perform in day-to-day work.

Footnotes

[1] Or, if you’re interviewing in the stone age, they hand you a whiteboard marker. Because that’s how I write all my code![4]

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alex Feinman

Alex Feinman

Obligate infovore. All posts made with 100% recycled electrons, sustainably crafted by artisanal artisans. He/him/his.