Off-topic: "Microsoft" questions in interviews

I've been seeing a bit of traffic around the net these days about the so-called "Microsoft questions" and whether they provide any value (most recently I think I saw this on a blog). The questions most often raised is "shouldn't my code speak for itself?" and "what could this possibly tell you about me?". The answers are - "no" and "a lot". Let me elaborate.
I've been on the hiring side of the table for over 15 years. I've interviewed several dozens of people and hired only a handful of that total number. Did I pass up very qualified individuals? Yes. Did I make what I think, even in retrospect, were good decisions? Yes. The reason is that I picked individuals who answered those "Microsoft" questions well. Not always correctly, but well.
The reason behind the "Microsoft question" is to find out how someone thinks. I couldn't have cared less if the candidate got the right answer. Rather, I was looking to see how that person thought and approached the question. One of my favorites was the following:

Sherlock Holmes is looking for a new Dr. Watson. You are placed in a room with 3 light switches. Down the hall is another room where Holmes is sitting with a single lamp. One of the 3 switches controls the lamp. You can't disassemble the switch and can't see or hear anything outside of the room.You can play with the switches as long as you want but when you enter the room with Holmes you must tell him, with 100% certainty, which of the switches operates the lamp. How do determine which switch controls the lamp?

I love this question. But why? Because it requires the person to think creatively and "outside the box". I don't really care if you get the right answer. I want to know how you think. I always ask my candidates to think out loud so I can understand what their thought process is. How are they attacking the problem? Are they finding the obvious and hidden information in the question?
I was a Windows developer for several years and one thing that I learned pretty quickly was that if you didn't want to just make another version of Word with the Microsoft Foundation Classes (MFC), you really needed to find alternative solutions. MFC didn't always do things in ways that you thought it would. It often required some creative solutions to make the MFC do what you wanted. If someone approached the problem above with a straight-forward approach they'll fail. Same thing with MFC (or any other technology for that matter). Which means they'll get stuck easily and need some help. Which means that I or one of my leads would be spending a lot of time trying to teach this person how to solve problems, not just work through the hard problems of architecture and design. Just today I was talking with a friend about his experience in Drupal and the same thing came up. You can't always rely that things will work as advertised and sometimes you need to get your hands dirty to solve the problem.
The hardest thing I ever did on Windows was override a common dialog. If you're not familiar with these, suffice it to say that they are provided by the framework at a very low level in the system and that, while they provide some override functionality, what I got asked to do was not part of the traditional customization flow. I got some of the problem solved with some straight-forward work but it took some pointers from a senior developer to lead me to the final solution which required not one but two different class overrides. It wasn't just something I could Google (even though Google didn't exist yet). The final result was a small thing but it made the product manager happy and I learned quite a bit about how Windows messaging worked. Would someone unable to approach that problem above have been able to solve it? Possibly, but it have been far more challenging - and time-consuming. And for those people who just give up on the Sherlock Holmes problem they would have come back to me saying it was impossible (even though it apparently wasn't).
My wife's workplace has something of a mantra that there was one qualification you had to have and the rest they could just teach you (theirs was financially-based). I follow that same kind of mantra, but it's around creative thinking. If you can think creatively, you can usually work your way through or around almost any obstacle that pops up from a development perspective. Sometimes the answer is "can't be done" but if you have more than a hammer in your tool bag you'll have a lot of options to try before you come up with that answer. And that's what I like to see - meeting needs creatively and growing my developers.
So are the "Microsoft questions" important? The answer has to be "yes". They show that while you may not have the skills, you have the mindset to attack problems from a variety of directions. It shows you're tenacious and don't give up. That you have a variety of ways of framing a problem. To me, they're not just important - they are pretty much the entire interview.

PS - If you're interested in the answer the Sherlock Holmes problem, just post a comment and I'll vet your solution or send you the correct answer.

Continuing Hurdles

As I've posted previously, there are some things I really appreciate about Microsoft's approach to supporting its developers (at least back in the day when I was writing Windows code). Primary among them is that Microsoft gives you the source code to their framework, the Foundation Classes. You get to see everything that the framework does, all the way down to the Win32 calls. And even then you can see the disassembly if need be. Apple has taken the opposite approach - they hide everything. I was talking with my mom tonight and I likened it to a server in a restaurant. You tell her your order - "I'd like to put a button in this location with this text" - and then she runs off, makes your order, and delivers it to you, but you never get to see how the secret sauce is made or if the cook spit in your food. Well, right now I'm feeling like Apple's spitting in my food.
I had been working diligently on getting my Alpha 2 completed. iOS 4 had just been released and I figured I'd get A2 out and then upgrade to the new Xcode version that supported iOS4. Then I got my new phone - iPhone 4, yay! (except for the antenna problem - boo!) - but it had iOS4. *sigh* So while I could install my iOS 3.1.3 version of software on my iOS4 phone, I couldn't debug it. And wouldn't you know, I experienced a crash. So I figured - well, maybe I'll just upgrade, recompile for iOS 4 and things will magically work! Okay, I didn't really think that, but I figured I was really close and this upgrade was: a) ultimately necessary, and b) worth the investment. So I bit the bullet and upgraded. And compiled. And fixed some problems.
But then I tried to run it. And found that now it crashes, but in a very unusual way - the stack is getting blown somewhere. Not that I changed anything that would cause that - it's just the combination of the code I had written for 3.1.3 apparently had a bug or there was a feature of the compiler that made it play nice. And this is where the first paragraph comes into play. The crash is happening deep inside Apple's code and I can't figure out where it's crashing.
Because of the crash, I've been unable to actually locate the place where the stack goes "kaboom". I've run into this a couple of times in the past on Windows - unallocated memory in release mode that overwrote the call stack pointers - but this is in debug mode, which should be a lot nicer and friendlier. But because I can't quite figure out where in the framework code it's crashing (because I don't have the source code), I'm stuck now doing another task that I'd postponed until after Alpha 2 and redesigning part of the code to help identify the general area that's causing the problem.
So, while I'm actually pretty close on having everything complete, I'm spending more time refactoring something that I'd planned to do later and am being forced to do now. I guess I should be looking at the glass as half-full as I now don't have to do this in the future, but at the same time my general timeline for Alpha 2 has gone out the window.
So because of a bug that I couldn't track down on the new OS I had to do two additional tasks that I'd planned on doing later. This has actually been the general story of my experience with iPhone development. Of course, Apple does tend to schedule all of their upgrades around the June timeframe (because of WWDC), so maybe I should just stop starting apps in April. And then maybe I'll feel like Apple's not spitting in my food.

Differences Between Windows and Mac Development

Well, after beating my head against a problem for like 6 hours today, I have finally gotten back to where I was... 6 hours ago. *sigh* Okay, it's not that bad. I do have some other work that happened in that 6 hours that's still around, but I made one change in the program and Bam! I felt like Elzar cranked my head up a notch with a spice weasel.

I was creating the character creation screens which are shown only if it's your first time running the game. I need to make it so that it's modal - meaning you can't avoid it - so I needed to do it before you had access to the tab bar. And things were going along well. I had a root view controller that was handling both character creation screens. I got my locations displaying for people to select where they wanted to start... It was going along great. And then... BAM! Spice weasel.

I had added the root controller's view to the main window as a subview. This seemed reasonable and rational and worked wonderfully. But I couldn't seem to remove it and add the tab bar. The tab bar simply refused to display. So I went down a whole clutch of rabbit holes trying to figure out a way to get the tab bar to display AND have the character creation pages come up. And then I managed to get so far down the rabbit hole I got stuck and couldn't find the way out. I hit up a friend of mine who's on Facebook - Don Metzler. He owns his own consulting business and we've known each other for almost a decade now. He's a Mac programmer AND a Windows guy, so he's familiar with the benefits and detriments of both platforms. He and I went looking at the code and tried to get it back to where it was semi-working. And, thanks to the chat, we got it back there. Yay.

What this pointed out to me, though, was one of the things that I really have to laud (that's approve) Microsoft for doing. They make all of the MFC (Microsoft Foundation Classes) available as source code. So when you're deep in the bowels of a combo box you can figure out why your particular hook isn't getting called, you have the proverbial snowball's chance to figure out why. With Apple, on the other hand, there's a sort of mystique to the internals. You don't get to know what happens in there and some things happen so automagically you can't possibly figure out how to replicate it.

Case in point: when you attach a tab bar controller to a MainWindow.xib file, there's some special magic that happens inside Apple's foundation code that hooks everything up. You get all of your view controllers laid out, the tab bar looks good, and things happen without having to write any extra code. If you try to replicate that, though, things kinda go south quickly. I found a few people online trying to do what I was doing (albeit slightly differently), but they ran into the same frustration I did. Had I access to the source, I could have replicated it and avoided the spice weasel. Instead? BAM! Spice weasel.

I've finally gotten back to where I was 6 hours ago in terms of the main game play. I need to spend tomorrow morning going through trying to hook up the character generation screens but at least they're done - I just need to get them to display and that will hopefully not involve a spice weasel and my eyes. :)

Progress and Pakled-ness

One of the pitfalls of technology is that you kind of get used to things working automagically. You don't have to do anything particularly difficult or, in many cases, that require much thought to do some pretty amazing things. A perfect example of this is my recent experience trying to get my application to install via iTunes 8 on Windows.

When developing an app, you need to create what are called "ad hoc distributions" - builds that are not loaded from the App Store and people just just drop them on iTunes and then magically appear on their iPhone or iPod Touch. There are two things required to make this happen. One is a provisioning file that tells iTunes that your device is allowed to load this program and the other is the program itself (which is a directory containing all of your files). It's a simplistic but effective way of distributing applications.

There are two quirks to this process. The first that I ran across was something I had known but forgotten - Mac ZIP files are different from Windows ZIP files. They have extra files that make uncompressing them normally impossible. You have to actually uncompress them by hand (the curtain begins to reveal the real Wizard of Oz). But that's no big deal - I'll just have to repackage them for Windows distributions. The second is that the provisioning files can't just be "dropped onto iTunes" on Windows. Drag and drop on Windows is a relatively hand-crafted experience and files ending in ".mobileprovisioning" don't make the cut for "drop targets". :) What this means is that you can't drop the provisioning files onto iTunes, you need to add them to the Library manually. (Perhaps you can drop them onto the Library itself, but File | Add to Library worked better for me). And now we can see the short man behind the curtain.

So while I was spooked that Windows and iTunes 8 weren't going to work, they do. Because I'm an idiot sometimes who doesn't try more than a few paths to get something working. Because I've become dependent upon the magic working. And I've become more than a little Pakled sometimes.

Regardless of all of that, I do now have things working from Windows and I can stop messing around with iTunes on my Mac (which was taking for-freaking-ever to add songs to the library). And with alpha only 4 days away, I have LOTS to do - especially since I'm taking the 4th off to go to Elitch's with the family and fireworks with my parents. Cogito ergo sum. And I'm a little scared by that. :)