1. 22
  1. 11

    It seems to me there’s a middle ground between “the old way” (whiteboard coding with no resources beyond your own memory) and the article’s “new way” (completely abandoning the idea of candidates writing code): let the candidate use a more realistic development tool, and encourage them to open browser tabs and use search engines as needed.

    For the last decade, 100% of the coding interviews I’ve conducted have either used a full-fledged IDE or a tool like CoderPad, and I have always told candidates to make full use of their web browser to look things up. The problem I give is always a variant of a problem I’ve personally had to solve on the job, not a crazy algorithm trick question, and they’re free to use any programming language I know how to read.

    Doing coding interviews like that means most of this article’s complaints about “the old way” don’t apply, aside from the one about the interview involving the candidate being judged by the interviewer. Which… I mean, yes, judging candidates is the goal of interviewing. The “new way” also involves judging the candidate.

    Not saying the article’s approach is a bad one. I’m curious to give it a try, in fact.

    1. 3

      Your approach taken to it’s fullest extent is the Take Home Exercise. That’s what the company I work for uses as the candidate can use the exact tools they’re familiar with, take as much time as they like (although we tell them to use an upper bound to not waste their time), and truly have the freedom to search the web in a realistic manner. If I were coding live and the interviewer told me to feel free to use Google I’d still be super hesitant to do so and the things I did search for wouldn’t closely resemble my day to day.

      Now of course this means it’s easier for the candidate to “cheat” and copy from the web, or have someone else do the exercise for them. To combat that we use an approach of a “design up front” through a pull request review. The candidate first sumbits a quick design of how they would solve the problem with some feedback from us (mainly to make sure they’re not going to go down rabbit holes or waste time taking an approach that won’t work; this feedback is meant to help guide the candidate) then an implementation. Both of which go through a quick PR review.

      Not only is this exactly how we work day to day (design up front, and all PRs get a review), so it helps us guage the non-code interaction, but also gives the candidate a chance to see if they would like working with these processes. Interviews are two way streets.

      We believe it’s super unlikely you’re paying someone to impersonate you on GitHub (and subsequently for your beginning period at the company). Also in all interviews examples I’ve seen no two have looked exactly alike. We also follow this up with a quick video chat to just talk through the submission which quickly surfaces anyone who just copy pasted.

      No process is perfect, but I like to think we have the candidates interest in mind and want them to be as comfortable as possible with as little stress as possible (minus the inherent stress of finding a job).

    2. 3

      I’ve been conducting code reading interviews for a few months and I swear by them, they’re powerful. I’ve been meaning to write about how I conduct the interview, how to find code samples, what to look for, etc.

      I had wanted to change away from coding interviews for years, but I couldn’t locate an alternative that wasn’t terrible. Code reading definitely seems like the least terrible option, but it does require preparation.