jump to navigation

Algorithms on whiteboards 2013-Mar-21 at 19:18 PDT

Posted by Scott Arbeit in Blog.
Tags: ,
7 comments

I grew up in New Jersey, and until I joined Microsoft in 2008, I spent my entire career between Washington, D.C. and Boston, MA. I’ve applied for more jobs and had more interviews than I can remember in that time. I’ve done more interviews for candidates than I can remember.

In all that time, I was never asked, and I have never asked, a single “code this algorithm on the whiteboard” question. It wouldn’t even occur to me to ask that kind of question in an interview. I don’t think it proves anything really, other than that you’re young enough to remember the college course where you learned it. It’s not something that’s done in the Northeast (or, at least, it wasn’t before I left in 2008).

The whole thing isn’t natural. Writing on a whiteboard is something that 1) no programmer I’ve ever worked with does on a regular basis; 2) does not come naturally to someone who isn’t a visual thinker (which I’m not); and 3) lacks the amazing tools that you get when you work in your regular integrated development environment (IDE), something like Visual Studio 2012.

Let me try to give an example. If you’re a writer, you might like to write on yellow legal pads, and then type it into your computer. Or maybe you prefer to dictate into a recorder, and then transcribe it (or have someone transcribe it for you) later. Maybe you prefer to type in OneNote, and then, when you’re done, copy it over to Word. If you’re like me, you just fire up Word (or Windows Live Writer 2012, since this is a blog post) and start typing. All of those things work, they’re really a matter of taste and habit.

The number of developers that I know who prefer to write their code on paper or on a whiteboard before they type it into an IDE approaches zero. I can’t think of a single person I’ve ever worked with who, when given coding work to do, starts by writing the code they’re going to write on the whiteboard, and then, after they’re satisfied with it (and their messy hands from erasing and rewriting – remember there’s no cut-and-paste and no “insert” on a whiteboard), goes to transcribe that into an IDE. In the age of mainframes and batch processing, where testing your program consisted of submitting a job that only printed results on paper that had to be brought up from the huge printers in the basement to whatever floor you’re sitting on, I understand about slowing down, writing things out, making double-sure, because one run could take anywhere from fifteen to sixty minutes to get the results. That’s how I started my career. (Forget about punch-cards… even worse.)

But since, oh, the mid-1990’s, we’ve had magic things called IDE’s that let us create, compile, test, and deploy our code. These tools (unless you’re a hardcore vi or EMACS person) help immensely in structure, exploration, and comprehension of code, and, in the case of Visual Studio with Intellisense, actually help you to type code much, much faster than you otherwise could because they know what you’re about to type and auto-complete it for you. Whiteboards and pens-on-paper can’t do that.

And then there’s algorithms. Of course, all computer code implements some sort of algorithm… do this, then do that. But what I’m talking about are basic college-course example algorithms. Things that you might have learned in CS201 if you took it. They’re fundamental, and they’re lovely to know, but I’ve had a successful over-twenty-year career in IT and I have never, ever, ever seen a case where I had to know or implement one of them.

There are definitely places where knowing the fundamentals is a good thing. If I were applying for a job in the Windows kernel team, hell yes, I’d expect to be grilled for that. If I were doing some sort of sophisticated financial analysis for a Wall Street quant group, sure. If I’m analyzing Facebook data, absolutely. But for the 99.9%+ of the rest of the coding that we need done in the world, things like web sites and internal applications and mobile apps… yeah, no. I’ve never used a linked list. I’ve never used a binary search tree. I’ve certainly never had to create one… if I ever want one, they’re provided (in the .NET Framework they’re found in System.Collections.Generic).

Now that I’m in Seattle, the entire interviewing regime is geared to questions about algorithms. You could be applying for a job writing a user interface for a web site, and you’ll get these questions out here. This is, I assume, due to the prevalence of ex-Microsoft and ex-Amazon people all over here, who were taught that the “right” way to interview is to ask these questions.

I remember one interview where the guy asked me the third complex question about linked-lists in a row. This was for a job on a fairly straightforward “show the UI and store the data in a database” application, the kind of thing we all use all the time. I asked him, “Is there a single linked-list anywhere in this application?” He stuttered back, “Uh… well… I’ve used them before.” In other words, no. Sigh.

And it’s not like I suck as a programmer. Please. (And I would have gotten through that, no problem, when I was 18 and it was fresh.)

And now… back to writing said algorithms on said whiteboards. Really?!? Is there a job interview in another field that I’m not aware of that goes like, “The way that I’m going to evaluate your fitness for this job is by your ability to do something that you’re never going to be required to do, ever on the job that I’m hiring you for, and by the way, I want you to do it using a tool that you’re likely never ever going to use again”?

Really?!?

It’s like saying, “I’ll interview you for a job delivering packages, but I won’t give you the job unless you can go into a garage and rebuild the engine in the truck you’ll be driving.”

So, what can I do? I’m here… I have to interview… and thanks to a friend reminding me about it, I’ve just signed up for Coursera’s Algorithms I course. I already own the previous edition of the textbook (and I used to own the first edition when I was in college), and the course is fortunately taught by the excellent author of that textbook, so, that’s all lovely. I already was going to self-teach myself using the book… thanks to Coursera, I get some guidance along the way.

Why am I doing this? One reason: just to get through the interviews. When I’m done, like so much else we all learned in college and high school, I’ll forget it, not because I don’t think it’s interesting, but because I won’t be using it, ever.

At least, not until the next time I have to interview.

Advertisement