# Why you can’t write a good FizzBuzz implementation

At work the other day, conversation on a mailing list fell to the fact that most programmers can’t write FizzBuzz. For those of you who haven’t heard this discussed before, the point is that you set the most trivial possible programming task for interview candidates: Write an algorithm that prints numbers from 1 to 100, except that it should print “fizz” instead of multiples of 3, “buzz” instead of multiples of 5, and “fizzbuzz” for numbers that are both. A full implementation in the most straightforward way involves just two control structures: A `for` loop wrapping round an `if` condition.

Naturally, since we are all programmers and somewhat competitive, we had a go at solving the problem ourselves in the most “creative” way possible. I had a number theoretic solution (repeatedly sum the digits of the number until you have a single-digit number, then compare against 3, 6 and 9 to determine whether it is a multiple of 3) and a slightly more elegant solution involving `itertools` in Python: one iterator produced the “fizz”s, another iterator the “buzz”s, and an `imap` knitted them together into a single sequence.

My second solution was controversial: some thought it was elegant and idiomatic Python. Some thought that it was pretentious obfuscation. I’m going to argue that it’s impossible to tell which of these is true.

Good code is about the relationship between the problem domain and the representation in code. The problem domain is comprised of the stuff that is known by the person with a problem to solve. We can assume they’re intelligent, but they don’t (and shouldn’t need to) know anything about how the program is implemented. The best code preserves and makes accessible the relevant aspects of the problem domain, and minimises the interference of “accidental” details of programming that have no representation in the problem domain.

I maintain that the FizzBuzz problem domain is so badly under-specified that it’s impossible to know how a really good solution would look. There are lots of problems that are isomorphic to FizzBuzz but have different characteristics, that would (if the problem were not so trivial) ideally be approached in different ways. Perhaps “fizz” and “buzz” are two entirely different concepts that different parts of the business want to talk about, in which case my dual-iterator solution might help to make this plain. Or perhaps it’s going to be extended into some kind of number theoretic analysis, in which case we should write our code so that the mathematical properties are foremost (perhaps we introduce a prime factorisation concept from the start). Or maybe we’re writing single-use code for the accounting department to produce a report during the merger of two companies.

I hope it goes without saying that simplicity is also an important feature, and that in the case of something as trivial as FizzBuzz simplicity ought always to win out over other concerns. But sometimes when programmers talk across boundaries of industry and experience it’s necessary to treat toy problems as if they were a bit more than that, and I felt like there was some mileage in that this time.

# Redundancy diary: Applications get serious

This is part of a series of articles talking about my experience of being made redundant from Arista. I am writing these articles as the events happened, though out of respect to my former employer I held off publishing them for several months. The hope is that writing about this will give some encouragement to other people who find themselves in the same position.

This morning I started the process of making serious job applications. My experience of job applications in the past has been almost entirely positive: I work in a field where qualified people are in high demand, and I’m sufficiently articulate to make a good fist of the written application process and the face-to-face interviews. It would be almost impossible to imagine how I might have had more positive reinforcement from the job-hunting experience in the past (I don’t necessarily think I’m a perfect employee once hired, but as an interview candidate I do very well indeed).

And yet I’m petrified. Absolutely consumed by nervousness, to the point where simple tasks take an age, and complex tasks get put off indefinitely. I managed to knock out five job applications first thing in the morning by making heavy use of my already-written CV and covering letter template. I was hoping to make use of the rest of the day to catch up on some new technologies and sharpen my Clojure or C++ skills with a couple of programming projects, but I can’t concentrate on anything at the moment. I’ve had a few positive responses from people wanting to arrange phone calls, but right now this is just making it worse.

I’ve never felt quite so bad when applying for jobs, but then the stakes have never been this high. I have about 6 weeks of runway thanks to my notice period and (minimal) redundancy pay, and objectively this is more than enough time to find a software job in London. But I’ve never previously been in the situation where there’s even a possibility that I might end the month without a job.

I don’t know if this is at all encouraging to people, but I take some heart from the fact that nervousness seems to strike entirely independently of circumstance. If ever you find yourself thinking “I’d be more relaxed if only I’d had better luck with interviews in the past”, just forget it. You’re nervous because you care about the outcome, and that won’t go away.

# I am a Good Software Developer

An anonymous article doing the rounds explains that the author is a bad software developer:

I am now in the buffer zone and have interviewed with close to ten companies to date. I have not been offered a single job and have not made it past the technical interview in most cases. I am a programmer. Until recently I had believed I was a good programmer. However in an industry where hiring practices have adjusted to filter out the plethora of bad, unqualified candidates I’ve found it rather difficult to consider myself a good programmer any longer.

If we are to take the proportion of job interviews that lead to an offer as an indicator of how good you are as a software developer, then I have to face the fact that I am a good software developer. Not just good in fact, pretty close to as good as it’s possible to be. My current hit rate is very close to 100%.

Of course, this is ridiculous. But I thought it might be instructive to put some thought into exactly why this is wrong.

Firstly, job interview success is localised: what constitutes a reasonable level of success will depend on where in the world you are, what industry you work in and when you are applying. From what I’ve seen, these facts dominate the effect of how good you are at your job.

But let’s suppose you’re comparing yourself to your friend who works in the same industry, at the same place and time. It’s still not useful to compare yourself with them because of the amount of random variance involved. If you’ve been rejected from ten companies then you might have been interviewed for less than 20 hours in total. That’s the equivalent of less than three days’ work. Most people wouldn’t conclude after three bad days at work, even a bad week, that there was something fundamentally wrong.

Thirdly, interviewing well is a skill in itself. Those of us who have conducted interviews like to convince ourselves that we did all we could to differentiate people based on how well they could do the job, ignoring things like interview nerves. We even rationalise the fact that the people who communicate the best have the best chances at interview, on the grounds that communication is an important part of working in a team. This is true of course, but communicating in familiar situations with people you know well is very different from communicating with someone you’ve met ten minutes ago.

As well as communicating and thinking on your feet, interviews disproportionately reward people who are immediately likeable. It’s not fair, and I’m sure people would deny they do it, but when you take a liking to someone you overlook their flaws, and exaggerate their qualities. Again, the superficial likeability that works well here is a completely different thing from the personal qualities that make someone a loyal friend or a supportive colleague.

Finally, there’s a strong tendency in interviews for success to breed further success. When you go into an interview with an offer already in the bag from your last interview, you’re more relaxed and confident. Conversely, the awful feeling that you have something to prove or that you won’t impress the interviewer unless you perform at your very best is self-defeating.

I’m sure the original poster won’t read this, but I’ll try and provide my two cents anyway: looking at the number of successful interviews is a really bad way to measure yourself. Technical interviews at different companies have a lot in common, so going to ten interviews is likely to tell you the same thing ten times. If what it tells you is that you meet their standards, this can be very reassuring, but it’s equally false either way. Instead, try to get qualitative data about what went right and wrong in each case rather than playing the numbers. If the company gives detailed feedback (and I believe they should, though not everybody agrees) then you should take as much information from each interview as you can. If you can’t get feedback from the interviewer, talk through what you remember of the interview with a friend. Try to be as objective as possible. Question your assumptions.

If you’re being rejected at the first round, and if you didn’t make any obvious technical blunders, then consider whether you may be trying to over-complicate things. First round interviews in particular tend to have closed solutions that aren’t very complicated, and the bar to clear isn’t always very high. Don’t stumble through implementing a complex data structure without first asking your interviewer whether a naive approach is acceptable (showing that you recognise the trade-off of program efficiency against development time). Even if you’re stuck, talk through your thinking and show a willingness to learn from any hints you are given. Showing that you can learn from the interviewer (and displaying a positive attitude as you do it) is a remarkably strong trait to show. Most importantly, do not ever give up on a problem until the interviewer asks you to move on.

I wish I had a better conclusion to draw. Interviews suck. Some companies do a better job than others, but nobody is perfect here. But I believe anyone can learn to make themselves a better interviewee, even if in an ideal world it wouldn’t be necessary.