Every once in awhile I'll stumble upon various posts that I'll have an opinion on, but won't bother blogging or otherwise commenting on. I've seen a few posts lately that got me thinking, so I figured a consolidated post was in order. Eric recently blogged about some technical questions (such as Big-O and data structures) during a Microsoft Interview (generally targeting industry pros who have been in the field for awhile):http://blogs.msdn.com/jobsblog/archive/2006/07/18/670121.aspx
at Microsoft are answering challenging design questions everyday and MUST keep
efficiency in production at the front of their designs. That's why these
questions are so important."
In general, I'm a fan of technical questions. It is, after all, a good way to measure a candidate's ability to perform the basic job functions. But all too often, this is overemphasized. Why? Here's one example: Vista. Awhile back, I worked on modifying an existing project that was coded very well. I was actually impressed with the technical knowledge the coder had. This person, I could tell, would easily pass these "Big-O" and similar questions. The design, though? It sucked. Too many tight couplings; and while the application was efficient microcosmically, it was a disaster macrocosmically. The application as a whole did not perform or scale. (And, that's why I went in: to solve some performance issues.) Elegance and simplicity are as important as Big-O when it comes to efficiency.
One of the top qualities Microsoft will should
look for is passion. That je ne sais quoi
that says, "this person will do great things and can see the big picture."
I've been on so many interviews over the years (including a few internal) and, to my surprise, rarely get asked high-level architectural decisions. I was really
surprised when, while on an informational interview for an internal position (an informational is an informal 2-way interview as a precursor to a formal interview), I wasn't asked about my passions, my resume was never looked at, my review history was never looked at or asked about ... it was a brief conversation and then an algorithm to solve. Thanks, but no thanks.
Don't get me wrong, every field has "hamster in the wheel" positions, but it's not a job I would want. I mentioned Vista earlier to point out that a project can have thousands of bright engineers working on a problem -- all acutely aware of their code's performance -- and still have the project fail and fall apart. That's why the "Longhorn reset" happened.
Anyway, that's my 2 cents. On a not-so-different note, up until a few days ago, I didn't know who Niall Kennedy
was, but his departure was mentioned by Scoble
and a few others. That's too bad ... this is exactly the kind of je ne sais quoi
that we need around here. Though, some interesting points regarding his departure and short stint have been made by Vijay Anand
In thinking about how short is too short of a stint (in Niall's case, it was a few months) I'm recalling a recently interview Guy Kawasaki did with Libby Sartain at Yahoo (here
). Point number 5 is interesting, as Libby mentions that she likes to see longevity in a candidate's work history. That's certainly an interesting and valid point, but to argue a different point, having a diverse work background is extremely valuable. Obviously, there's a balance to be had.
OK! I think that clears out the OneNote links I've been building up...