Interviews are not a zero-sum game (FizzBuzz postscript)

My last post sparked some controversy in the comments on Reddit. Whilst the majority seemed on board, there was a sizeable minority who took umbrage. Two objections, in particular, caught my eye, because I think they both relate to the same underlying issue – adversarial interviews. In this (short) post, I’d like to explore this and explain my approach. Finally – unrelated to the bulk of this post, but too fun to ignore – let’s look at some of the wacky FizzBuzz implementations shared in the Reddit comments.

Not how an interview should go. [Image courtesy of David Trawin on Flickr]

So, I published an article recently about how useful FizzBuzz remains as an interviewing tool. I submitted it as a link to Reddit, as I often do when I write a new blog post. Overall I was very gratified with the response – at the time of writing it had attracted over 800 upvotes and a large number of interesting comments. Inevitably, however, there were some less positive responses too.

I won’t dwell on the responses from people who had clearly not read (or, more charitably, had misunderstood) the actual post. For instance, I don’t feel the need to respond to suggestions that TTD and interfaces are overkill for FizzBuzz…

That said, there were quite a few comments that fall into a couple of related themes: the modulus operator and live coding in interviews. I thought it would be good to rebut these first, before going into what I consider to be the underlying theme.

The modulo “gotcha”

There was a recurring theme of comments that objected to the use of FizzBuzz as a simple “do they know modulo” test. It’s true that not everyone will be familiar with modulo. One commenter (/u/mindbleach) put it nicely: “[modulo] is an accidental shibboleth” – i.e. an idiom whose use belies membership to a particular group. And whilst it is possible to complete FizzBuzz without using modulo, it’s probably the most natural approach

So, given these factors, how come I didn’t mention the modulo operator in my original post? Because, In short, on the rare occasions that a candidate doesn’t know about it, we’ll introduce them to it. We’ll have a chat with them about what they are trying to do, and then straight up tell them what the % operator does. Problem solved! And, as a bonus, the candidate has learnt something.

Live coding in interviews

The second theme in the comments that caught my eye was concerned with the inherent fairness of asking a candidate to do live coding in an interview. I completely sympathise with people who get nervous when having to program in front of a stranger, but unfortunately, there really isn’t a good alternative:

• Take-home tasks disadvantage people with busy lives. Plus it can make a recruitment process less attractive to well-qualified candidates, who will likely be interviewing with several companies at once.
• Presenting a portfolio isn’t an option for many people who don’t code outside of work. I really love to see a GitHub link on a CV and will always discuss it at interview, but it can’t be relied upon and I don’t like to penalise candidates on this basis.
• “Whiteboard interviews” suffer the same problem of a coding task, whilst telling me less about a candidate’s abilities.

Additionally, if we’re doing the evaluation non-live/asynchronously, there’s no (time efficient) way to explore new ideas together or to adjust the complexity on the fly. We’re stuck with whatever the candidate prepared beforehand. Yes, we can discuss it, but that’s also true of a live coding task.

Finally, I reject the notion that you never have to code in front of other people as part of a software development job. In my teams, I encourage pair programming as a normal part of writing code. It’s not something I’d suggest people do for 40 hours a week, but it can be really helpful when working on something more complex, or when close collaboration is going to be required.

So if we are sticking with a live coding exercise, I suppose we better make it as painless as possible. To minimise stress, here are the steps I take:

• Be as open as possible about the format of the interview, right from the start of any conversation.
• Send the skeleton solution over in advance and encourage the candidate to try running the app and the tests ahead of the interview.
• Make it clear that they can use whatever IDE/tools they feel comfortable with.
• Set the whole thing up as a pair programming exercise – it’s not a quiz and you really can ask the interviewer for support.
• Explain that it’s not a test of what syntax/design patterns/keywords they remember, but rather a chance to see how they think about problems, communicate with colleagues, and, yes, how they write code.

There will still be candidates who will be nervous. Heck, candidates will be nervous about interviewing, even if there’s no live coding element. It’s a stressful experience. With a bit of empathy and compassion, however, I maintain it’s entirely possible to coax a great performance from a nervous-but-talented developer.

Non-adversarial interviewing

The thing that struck me about both the emergent themes was that they seemed to stem from really negative experiences. Like, “who hurt you, dude?” It made me really sad to think of all the awful interviewing experiences the commenters must have had to make the assumptions they did. It seems so obvious to me that you need to set the candidate up for success, that it didn’t occur to me that I’d need to explain some of this stuff.

Interviewing is not a zero-sum game. You don’t “win” it by making the other person feel stupid. The interviewer should not be looking for reasons to disqualify a candidate. There’s no good reason for the interview to have “gotchas”.

In fact, it’s the opposite: the incentives for the candidate and interviewer are aligned! The interviewer has a vacancy to fill. The candidate wants a job. Both parties have gambled some of their precious time on the hope that it will be a mutual fit.

Maybe this is a step too far? [Image from PxHere]

In many ways, an interview is like a date. Unless you’re an “incel”, a date is usually a chance for both parties to put their best self forward, have a nice time, and hopefully create a positive lasting impression on the other. And it really does go both ways – after making time to interview someone, the worst outcome for an interviewer is for a good candidate to withdraw. Using the modulo operator as an opportunity to make someone feel small is clearly not compatible with this, nor is it to anyone’s advantage.

NB: In case it needs saying, please don’t confuse an interview with a date. Don’t be creepy or make things weird!

I’m reasonably confident that my interviews are pretty good. I attribute this to the age of maxim of “not being a dick”. Why do I feel that people like my interviews? Because I seek feedback and it’s usually pretty good. Crucially, it’s not just the successful candidates that seem to enjoy my interviews – I also get positive feedback from unsuccessful candidates and recruiters. Blowing my own trumpet like this has a purpose beyond self-gratification, by the way: I sincerely hope that someone reading this (hiring manager, or prospective candidate) will change the way they approach interviews in the future.

And now for something lighter…

OK, with that out of the way (and off my chest) I thought we could wrap up with a bit of fun. One of the cool things that happened in the Reddit comments was that all the crazy versions of FizzBuzz came out of the woodwork. Some are parodies, others are just insane demonstrations, but they’re all worth a look.

1. Extremely high throughput FizzBuzz
2. FizzBuzz in TensorFlow
3. EnterpriseFizzBuzz
4. FizzBuzz from scratch (i.e. the base of Yggdrasil itself)

So there we have it. By the way, if you enjoyed these, keep an eye on the blog for an upcoming FizzBuzz competition. For now, since I didn’t intend to blog twice in a week and I promised to keep this post short, let’s leave it there. Ciao!