It’s not magic

Last time on FAIC I reran my 2004 article on tips for coding on whiteboards for interviews. This time, a rerun from 2009 article on a similar topic. Next time, some more thoughts on this subject.

Interviewing job-seeking candidates is probably the most impactful thing that I do at Microsoft as far as our business is concerned. Sure, the day-to-day work of implementing the compiler is of course what I am specifically there to do. But ultimately nothing impacts the bottom line of our division more than preventing bad hires and encouraging good hires. The dozens of people that I've interviewed who got hired will collectively deliver much more value (or do much more damage!) than I can alone. So I think about it a lot.

I find it interesting to notice the common threads that show up in the surprisingly disparate group that is Microsoft interview candidates. A big red flag for me that I see fairly often I jokingly characterize as a form of magical thinking. Now, as someone who values diversity and cherishes the inalienable human right to believe in any old crazy thing you want, I of course do not care at all if candidates engage in magical thinking on their own time. But magical thinking about software concerns me greatly. For example, I should never be allowed anywhere near network drivers, as my beliefs about routing are clearly magical in nature.

The trouble is that I occasionally see this sort of thing in people who are not making silly jokes about it.

The technical interview question I usually ask is a deliberately vague and abstract version of a real problem that I had to solve back when I was working on the VBScript engine. The details aren't germane to this particular discussion, but suffice to say that every candidate quickly figures out that a necessary step in solving the problem is the automatic generation of a guaranteed-to-be-unique "cookie" value of some sort. The "cookie" is used to track and control the progress of a "task" being performed by a "server".

You can learn a lot about a candidate from their approach to this sub-problem. Candidates, sensibly enough, always try to solve the unique cookie problem by using an off-the-shelf tool that they are familiar with, like:

• a GUID
• a timestamp
• a global threadsafe counter
• a random number
• an auto-generated primary key field of a database table

There are pros and cons to all of these approaches; none of them is necessarily "right" or "wrong". (And we explore the pros and cons as the interview continues.) Where I start to see magical thinking though is when I ask the candidate to assume that their chosen solution is simply not yet implemented on their platform. Rather, they are the developer who needs to implement the tool if they want to use it in the overall solution.

I fondly remember the moment of dawning comprehension when I asked a particular candidate "But suppose you had to write the code in the database implementation that auto-generates the primary key on the table you are using to solve this problem. How would that code work?" The candidate was completely taken aback, and just stared at me for a moment before saying "wow, I never before thought about the fact that someone had to write code that does that." Apparently in his world creating primary keys is done by the primary key pixies who live in the b-tree forest. And it turns that out a lot of people think that GUIDs are generated by the GUID goblins, that random numbers are created by the RNG ogres, and so on.

In reality, all of these tools I mentioned were implemented by writing code. And therefore someone had to analyze the problem space, weigh the costs and benefits of possible approaches, design a solution, implement a solution, test it, document it and ship it to customers. No magic involved!

Of course this is not to say that we shouldn't treat abstractions as abstractions. You don't want to be relying upon the implementation details of an abstraction, and you don't want to waste mental cycles understanding precisely how every tool does its job right down to the movement of the electrons. Moreover, there's nothing wrong at all with being a developer who takes existing tools and strings them together to make something new; we all do that. But what I want to know is can the candidate make their own tools? Because that's the business my team is in: making tools.