Doing a technical phone screen has always been a challenge for me. My preferred in person technical interview, especially for more junior engineers, is to take a relatively simple programming task, and dive deeply into it. The code will be simple enough to commit completely to a whiteboard, or a piece of paper, but I’ll lead the conversation to edge cases, performance, and how to test that code, for example. The coding task is really just the framework within which the interview happens.

What emerges from this conversation goes beyond seeing if the candidate can solve the problem. It lets me determine if the solution the candidate provides is a rote answer, or if they are able to analyze the whys and hows of the solution. Writing Merge sort, or Quicksort, for example, isn’t that hard, and many engineers can code it up in a couple of minutes. But when to use one or the other can be a subtle thing, and only discussion can make evident if someone gets that.

Also, engineers don’t work in a vacuum, they work on teams, which are sometimes quite large. A candidate’s ability to engage in quality discourse regarding the pros, cons, and other ramifications of sample code is also demonstrative of their ability to engage in similar discourse with their teammates regarding the real-world problems they will encounter.

I’ve found translating this to the phone doesn’t work very well. I’ve tried a variety of collaborative editing tools for doing programming, but all the nuances of an in-person interaction are lost, and I just can’t get a good of feeling for how someone is thinking about a problem. This is similar to the latency and throughput issues which make in-person visits to offices in other cities necessary.

Over time, my phone interview methodology has shifted more and more to discussions about engineering theory. I use questions that start off high level, but let you dive deep into a variety of technical areas. One interesting question is how you should go about choosing what language to build a project in. Something like “If you were going to build X, of the languages you know, which would you use and why?” The discussion can go through all sorts of trade offs of various memory models, concurrency, team composition, and type systems, any of which can lead to revealing conversations. I particularly enjoy when they end up in the bowels of different garbage collection algorithms.

The end result is similar to that of my in-person technique, in that a discussion of why gives me more insight than simple “how” answers.

None of this, of course, is to downplay the importance of the ability of an engineer to write clear, performant, bug-free code. But for me, an interview is not about that. Interviews are about learning how a person thinks, what kind of decision making process they use, and how they absorb and use new information.