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.
