Monday, June 4, 2007

Rethinking FizzBuzz - Function Z

The notion that a program as simple as FizzBuzz was over the heads of a non-trivial number of developer candidates caused a stir for the sort that reads programmer blogs.
I was as astounded as everyone else was - here's a program that's a tiny step above HELLO WORLD in terms of its complexity and one can actually use it to weed people who call themselves developers (and have the experience on their resumes to back it up) out? Really? But at the same time, guy's got a point - why don't we have prospective developers prove that they can really write code?
In the mad dash to whip it out and measure their programming prowess, people missed out on pondering another fundamental need from candidates - reading code.
Nobody wants to cop to being a lowly maintenance programmer. The digs aren't hard to find - "cut and paste programmer", "they just cobbled the code together", "Java is the new COBOL", etc.
But when you get down to it, how much of your code is really "new"? Do you refactor relentlessly (or ever)? Have you ever found a bug in your own code and fixed it? Have requirements changed, leaving you to modify your classes to get things working as they should today?
Congratulations, you're a maintenance programmer. As a maintenance programmer, you had to do something that I imagine manages to elude even more so-called developers than writing FizzBuzz - reading (and more importantly, understanding) code.
My tweak on the FizzBuzz script is the following snippet. Along with it, I pose the (very hopefully hypothetical) question - "I found this function in the code base the other day and 'z' obviously isn't very meaningful. Could you walk me through how you'd go about figuring out what to rename it?"

public static void z(int[] x)
for(int i = x.Length - 1; i > 0; i--)
for(int j = 0; j < i; j++)
if(x[j] > x[j + 1])
int t = x[j];
x[j] = x[j + 1];
x[j+ 1] = t;

To get it out of the way, yes, it's a bubble sort written in a C-like language. At this point, let me just state for the record, I think you're all better than me.</Seinfeld>
So why is this so much better than having someone write FizzBuzz? Think about it - if they can't write FizzBuzz, they can't read it either. If they blow either question, interview over. If they get FizzBuzz right, where do you go from there? It's a binary question (only right or wrong) and those aren't useful for interviews where you're trying to get a feel for the person.
With Function Z, you're weeding out the FizzBuzz failures (and more of them), plus you're getting some lightweight insight into their thought processes, plus bonus insights once they've figured out that it's a sort function.
For example...
  • Are they the prosaic type, questioning whether or not the language provided a native Sort() method on the integer array and why it wasn't used?
  • Are they a Not Invented Here cowpoke, quick to point out that you should rewrite it as a quick sort and speed things up (I can see how this feels like a trick question for an interview, but I get nervous about people who make changes with that little context (on the other hand, encapsulation and wow I wouldn't even hire myself, would I?))?
  • Are they the type that wants to leave everything better than they found it, cleaning up the variable names as they go along?
  • Do they ask for the unit tests to accompany it?!?!??!?

I can see how either FizzBuzz or Function Z can spin into the ugly territory of "monstrous interview question I ask to make them feel like a dick", so I implore you to keep your hypothetical functions short and sweet.
So who else has some deceptively simple interview techniques?


anjan bacchu said...

hi there,

dave solomon posted a link to this post from another interview blog post.

You could give 2/3 such code samples that could help you grade candidates should time come to pick among the lot.

2 or 3 read samples AND 2 or 3 write samples + some way for them to explain what they've done should go a long way in weeding out most candidates for most positions.


Dave Solomon said...

I don't know how much more you'd learn from the next code sample question (and the one after that) than you'd learn from the first, but it's not like I'm sitting on a mountain of interview experience here.
Curious that when it comes to interviewing someone I'll be working with for a long while, one of my concerns is making sure that it's not a marathon interview. I want to get the right person, but I don't want to spend more than an hour with them to make sure?

Anonymous said...

One thing that I think is often overlooked in interviews is social fit within a team.

For example, a boss I once worked for told me of an interviewee he'd dealt with. Brilliant guy, technically the best qualified for the job. But my boss didn't offer him the job. He was ex-military and it was obvious to my boss from the way the interacted in the interview that he would rub the civilians he would be working with up the wrong way.

The guy might be more productive than the person who was actually hired but overall the team's productivity would suffer because of him pissing people off.