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?