So, I'd like to counter with some reasons why you should over-think FizzBuzz, and why I did, because I don't think I did a great job of explaining that in my last post. But first, lets assume you're not being asked to solve it on a whiteboard while the interviewer waits. In that case my 400(ish) line solution is completely inappropriate. In fact, anything but a quicky solution is inappropriate. Lets also assume that in submitting an over-thought solution to FizzBuzz you make it perfectly clear that you know it's over-thought and what you were hoping to achieve by going to such ridiculous lengths in your creation.
As I mentioned in FizzBuzz rethink hundreds of programmers rushed to solve FizzBuzz in the comments of the various posts about it and many of them got it wrong. I suggested that this was a classic example of what's wrong with this industry. And the reason I believe that is exactly why I think FizzBuzz should be over-thought.
As sad as it is that there are so many "programmers" out there who can't successfully solve the FizzBuzz problem I believe it's even sadder how many companies are allowing their programmers to take a half-assed approach to software development. There are far too many who still think that writing unit tests isn't worth the time, or that since they can't possibly test for every possible scenario they'll test for none. Some don't even use version control. These companies, like the people who rushed to post FizzBuzz solutions without really reading the instructions, allow their developers the slap together the first thing that comes to mind and rush it out the door without any real clue if it'll break anything else when deployed, if it really meets the clients needs, or, in the case of the posters, if it will make them look like an idiot for not even being able to correctly solve FizzBuzz.
With the previously stated assumptions in mind an over-thought FizzBuzz solution is excellent because it tells the employer that:
- you'll actually apply some thought to the problems they set before you.
- you recognize the value of things like testability (you do have unit tests right?)
- you are familiar with and prepared for the common changes that clients will ask for.
- you are self-motivated and not the type of person who go above and beyond what's asked of you.
It's great for the interviewee because if the employer starts bikeshedding you know you don't want to work for them. If the interviewer does "grill you over why your solution doesn’t use the Y Combinator to implement `compose", as Raganwald suggests, then you know these people may actually have brains, and I would much rather work for people with brains who will challenge me. If the challenge comes in the form of suggesting you're a loon for such an extreme solution it's an opportunity to defend why you think it's good and see how they deal with a person willing to stand up for their craziness. You'll quickly learn if they're the kind of company where they expect you to roll over and acquiesce to their suggestions or if they are willing to have a real debate with you. Either way you learn a lot about the employer that will help you decide if you'd even want the job. It'll also give them a good idea of how you handle your peers suggesting that you've done something wrong.
I'm not sure I want to work for someone who can't see the value of an intentionally over-thought FizzBuzz like mine.