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.
Hi Eric – I went to read your “routing is magical” post from a few years ago. The comments are hilarious! One comment asked if wireless packet carrying had been outsourced to fairies instead of pigeons, which reminded me of a story about how slow networking in South Africa really is (though things have improved somewhat since 2009): http://www.news24.com/SciTech/News/Pigeon-beats-Telkom-20090909
I remember commenting on this post when you submitted it originally, and I read your last entry too at some point. To think I’d still be reading your blog after all these years — actually more surprising is that you’re still active, as most blogs don’t last this long.
I was in Oxford once, visiting a friend studying there, and asked one of the gardeners how they got their lawns so nice. It’s easy, he said. Rake it every morning, mow it every week, run a lawn roller over it every month, for four hundred years, and you too can have a nice lawn.
People often ask me how to get a lot of blog followers. It’s easy: just write consistently good articles every week for ten years. Much easier than maintaining a lawn.
Thanks for the loyal readership and good comments; I appreciate it!
I firmly believe the GUID gnomes are out there, malevolently making code impossible to debug and its configuration impossible to inspect. Is there anything less readable than a GUID? Except for maybe two GUIDs?
I would not have chosen a GUID if you were interviewing me.
I’ll grant that possibly some GUID gnomes are human, or have human form.
Suppose YOU have to write the code for the network router work…
Very interesting article.
If I understood it right, a good approach would not have been to either:
– Propose an “abstract” solution where tools could not be available
– Propose a solution relying only on their code which could be very expensive
They should have asked details on the context, like:
– What tools are already available?
– Which tools will be implemented on next release? (to prevent writing code doing exactly the same job that another developer will write)
– What is the deadline?
Then, considering all the elements, they would have proposed an optimal solution matching all requirements, instead of “blindly” guessing it.
Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1875
I think it’s really easy to take a lot of the functionality in frameworks and tools for granted, and forget that someone else actually had to write the code, but I think ‘magical thinking’ is ok if it drives people’s natural curiosity to figure out how their tools work. I guess the problem is when the magical part isn’t all that interesting!
In some systems, it may be reasonable for programmers to assume the existence of a random-number fairy; such things are called hardware random number generators. On the other hand, not all hardware random number generators behave as perfect random number fairies. There are many cases where it may be reasonable for a programmer to say, e.g. “We need 100 devices, each with a hardware random generator, to come up with unique IDs within 5ms of powering up. Using 64-bit IDs should yield an acceptably-low likelihood of collision if the generator yields reasonable quality randomness. There’s no reason to believe that a generator with a defect that prevents it from producing the desired quality of randomness will be able to yield any useful randomness, and if exactly one device has such a defect there’s no reason it shouldn’t be able to coexist with everything else. Thus, the hardware random number generator should, from the standpoint of the code, be presumed to “just work”.
Pingback: [Перевод] О собеседованиях (от Эрика Липперта) | Malanris's site
Pingback: [Перевод] О собеседованиях (от Эрика Липперта) - Терещенко. Просто. Профессионально
Pingback: [Перевод] О собеседованиях (от Эрика Липперта) | IT-News
Pingback: Недвижемость и стройка » [Перевод] О собеседованиях (от Эрика Липперта)
Pingback: MethodImplOptions.InternalCall | Code and a glass of wine
Pingback: A Little Bit of Magic – willmurphyscode