A better way to interview software engineers
Zach Millman

Hi Zack,

This sounds a very interesting approach, although I have some concerns about how natural it is for people to read code on the spot and review it.

I mean, this is the same difference of reading yourself a book before going to bed, and reading out loud a book in front of an audience. Most people won’t be able to do the latter smoothly, although I’m pretty sure most of them are perfectly capable readers in their bedroom.

Another aspect which concerns me on trying this approach is that when I hire senior engineers I expect them to deeply understand the problem and the context they’re operating within, before working out how to proceed. I frankly struggle to see how that would be possible while reviewing the code of a project you had no clue about before walking in for the interview.

I can see how some people can pick up some obvious mistakes and inefficiencies of a random piece of code, but that to me looks exactly like my computer science exams at uni. To me it only proves you’ve read the textbook of how things should be done in theory. Exercise for the sake of the exercise.

In the real world is much more often the case that decisions need to be made between options which have much more subtle differences, and what is better or worse is totally dependent from the context.

I’d love to understand a bit better what you guys consider good/bad answers and what kind of code you put in front of people.

I’ve thought quite a few times of trying this, but then I always end up fearing I will end up hiring academics vs engineers :)

Like what you read? Give Stefan Manastirliu a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.