Wednesday, June 17, 2020

Interviewing Developers

My preference is to have the candidate bring in their own laptop if they have one, or to use one of ours if they don’t, and not to work on a whiteboard at all, but rather, to work in the development environment the candidate’s used to, with full access to the Internet and all that implies. I believe I’m a rarity in the world, though, as I’ve never been interviewed in this particular way, and I’ve written a lot of software standing at a whiteboard.
When I respond to whiteboard questions, I tend to write in c-like pseudo-code, drawing on libraries I already know well, but disclaiming syntax. There’s no reason to look things up in that case.

For the record, I routinely fail phone screens (I’ve failed Amazon’s twice, Google’s once, and Mulesoft’s once, despite being a pretty senior developer and designer), and I give what I consider to be a relatively simple phone screen which causes me to fail about 2/3 of candidates. By the time I see you face-to-face, I know I want you to pass, and I’m going to give you every chance to do so. I only ask the must junior people to write code; most of my interview time is spent working with models, seeing if the candidate knows how to think about objects, big-O behavior, and design.


I don’t use FizzBuzz (anymore), but I do have a 10-question phone screen (drawn from a pool of about 100 questions) that serves the same purpose. It is intended to screen out copy/bash programmers—that is, people who don’t actually know what they’re doing, but who are vaguely familiar with the language. They are prone to copying working code, then bashing at it until it does what they were asked to make it do.

Somewhat astonishingly, about 60% of interviewees fail the screen. They don’t know the difference between a class and an object. They don’t know the main collection types (some can’t name any of them). They can’t write a method that prints out all the odd numbers from 1 to 99. They don’t know what “encapsulation” means, or how to achieve it. And so on. They are not entry-level competent programmers, despite having a job that pays over $100k/year “programming”.
The good news is, I can finish that screen in about 15 minutes with a competent programmer, and we can go on to the fun part of the interview, where we talk about what they want to do and have done, and how they might contribute to our team.

No comments:

Post a Comment