Software Dev Interviwing

On my second full day of interviews a Microsoft, I walked into the interviewers office – typical office at the time (desk with two monitors, window with a nice view, and a few white boards).  After a 10-minute intro, the dev doing the interview ask me a question that he wanted me to white-board code for.  It took him about 35 mins to describe the problem in detail – at the end of the long description he asked me to start coding (had about 15 mins to do it).  

I wasn’t sure if I should laugh or cry at that point.  I ended up trying to white board the fairly complex requirements that he’d given me, and managed to start to at least give a high-level flow of the code (which probably wasn’t correct as I really didn’t fully understand the problem).  I ended up bombing that portion of the interview – I hadn’t started really coding up a solution, so the interviewer wasn’t happy.  Neither was I, as it seemed like a pointless and frustrating hour. 

As I had about 16 hours of interviews and did well on the rest, I ended up getting an offer to join Microsoft Research (which I happily did) – but that experience just reinforced my questions about how technology interviews are done, especially at the bigger tech companies.  It didn’t really seem to have a point, beyond stressing the candidate and possibly seeing that they could write a bit of code.  A lot of the other questions I’d seen were algorithms – but even those were things I didn’t normally DO as a dev – like, use bit manipulation to reverse a string.  These were interesting questions, and when I was fresh out of school I’d likely be able to code away at them (doing it on a white board would be WEIRD, but I had at least solved similar problems recently).

The odd thing about this was that, as someone who had been building and running dev teams for years, I didn’t want to know if someone could write a quick sort algorithm – as a matter of fact, if one of my devs actually wrote a quick sort algorithm as part of the job I would be, at the very least, annoyed – why hadn’t they use a library? Do they really thing something they wrote in a few hours or days would be as robust, fast, etc. as Array.Sort in C#?   Did they REALLY want to take on maintenance of that complex piece of code? Is this something the team and company also wanted to now maintain!? The answer would generally be NO…

I’d ask this question to other Microsofties doing interviews – was the white board coding interview useful? Did it really help know if the candidate would be a good hire? The majority said “NO!”, and would gladly rant on the absurdity of it.  When asked why they still did it, most responded with “because that’s how it’s done” or “that’s what I had to do”. 

Ugh!

So I started to look at another way to do it.  I tried to step back and really figure out what question I was trying to ask. 

Was it:

“Can the candidate write code on a white board?” (NO)

“Can the candidate write complex algorithms on the fly, by memory, that I’d never want them to do for the job?” (NO)

“Can I stress the candidate out to the point where the break down and cry? (NO – even though I’ve seen some companies where this would be a good idea to at least test, as they’d have to deal with it on a daily basis)

Or

“Is this someone who can do the projects the company needs done” (YES!)

“Is this someone I want to work with?” (YES!)

I don’t believe a white board interview coding up a Levenshtein function really answers these questions well very well.  So, when I started to build my own team at Microsoft, I stopped doing the norm and experiment with ways to really answer these two questions – Project day, and the Take Home.