OK, one more that I found in my archives from the Visual C++ group from 1995. No milk involved this time. Once again, names removed to protect the innocent, except for the one name that’s obviously a joke…

——————– ACTIVE – 01/30/95 – XXXXXXXX ———————–
Visual C++ makes an audible signal when a build completes. When no developer is in the room, this signal doesn’t make a sound. To reproduce:

1) Start a build.
2) Leave the room.
3) Note that the chime does not make a sound.

We should find a way to make the build bell make a sound even if nobody is there to hear it.

This philosophical issue may need program management’s attention before being resolved.
————— ASSIGNED to XXXXXXXX – 01/30/95 – XXXXX —————–
Can we use the telepathy support in Win95 to contact whomever is logged into the machine doing the build? Maybe we should just detect when the developer is leaving the room and prompt for a phone number where s/he can be reached. How about disabling leaving the room during a build?
————— RESOLVED – BY DESIGN – 01/31/95 – XXXXXXXX ————–
——————– ACTIVE – 02/01/95 – XXXXXXX ————————
Actually, we can’t do this either. The problem is that while you’re out of the room your build is neither finished nor unfinished. It stays in a state of flux until you return and collapse the quantum uncertainty by observing it.

Perhaps we could link the build finished event to a cat in a box?
————— ASSIGNED to HEISENBERG – 02/01/95 – XXXXXXX ———–
————— RESOLVED – NOT REPRO – 02/03/95 – HEISENBERG ——-
I cannot repro this. I tried standing just outside my door and it made the beep. Do I have to go further from my office? Would the mailroom do?
——————– ACTIVE – 02/03/95 – XXXXXXXX ———————–
The relative position of the mailroom and your office are relatively uncertain to me, Doctor.

Please try again:

1) start a build
2) leave your office
3) go down the hall
4) wait until you don’t hear the beep
5) return to note that the build is done

I think this is how I first repro’ed the problem, but I can’t remember what I was doing to make it happen.

The idea of disabling leaving the room might be the best possible solution, I think. When a build starts, the IDE should pop up a message that says “There are no more Fritos” or “The kitchen has closed early” or “The bathroom is being cleaned” so the developer will not be tempted to get up and wander around.

With minimal rebuild in place, we should consider diversions that won’t take as long to remedy: “You’re expecting a phone call” or “Someone will stop by to see you soon”.

We need to think of messages that are easy to localize for VC++3.0J.
————— ASSIGNED to XXXXXXXX – 02/13/95 – XXXXXXX —————
To do this we’ll need to avoid messages about the bathrooms and vending machines for external releases. Perhaps some customer research is needed to find out exactly *why* Visual C++ users leave their keyboards.

Some suggestions (including MB_ types)
Get a drink :
(i) You’re out of coffee
(i) You’re out of tea
(i)(i) YYoouuvv”ee hhaadd eennoouugghh

Get something to eat :
(?) You have no food, remember
/! You need to lose weight, fatso. Sit your ass down

Exercise etc :
(?) Did You Know – sunlight causes skin cancer
(i) With a Nordik Trak you can get a workout in front of your monitor. Call for home delivery
/! I didn’t mean that about your weight

See family :
(i) They already know you love them
/! They’ll only want money for something
/! Your in-laws have arrived

Call of nature :
This could be difficult. Consider supplying bed-pan or similar
————— ASSIGNED to XXXXXXXX – 02/16/95 – HEISENBERG ————
I attempted to repro this once more:

I placed my machine in the forest at the edge of the campus.
I started a ‘rebuild all’ and ran out of the forest towards my mailroom.
My build normally takes 3 minutes. After 5 minutes I had not heard anything,
so I returned to my machine. Unfortunately a tree had fallen on it. I had not heard that, either.

Adam Barr posted a comment on my entry on Joel’s now obviously massively ancient article on interviewing at Microsoft, with some amplified comments in response to Scoble and even more amplified comments in his review of “How Would You Move Mount Fuji?” on Slashdot. (Whew. Way too much hyperlinking going on there.) It seems like there are some deeper issues between Adam and Microsoft that are going on in the background – I’m not quite sure how one jumps from my entry to the idea that I believe that “I work at Microsoft therefore I’m a genius at all things including evaluating talent” – but it is worth noting that I actually agree with many of the points that Adam brings up. Since I was just riffing on a thought I had about Joel’s article, I didn’t really cover everything I think about interviewing. So here are a few more thoughts that I think are worth saying…

To start with the practical side of things, I’ll cop to the fact that I don’t think I’m a great interviewer or all that good a judge of talent. I’m a pretty good programmer and a decent writer (I hope) but I make no claims to be Lamont Cranston. To be even more honest, interviewing people has always kind of terrified me. After a lot of conscious work I’ve gotten to the point where I can do it and feel reasonably secure in doing it, but if SteveB called me up tomorrow and told me he’d written me a Get Out of Jail Free card for interviewing from now until doomsday, I wouldn’t be sad.

Anyway, despite the stories I’ve heard on the web, all of the people who I’ve been on interview loops with at Microsoft have been genuinely interested in the candidates and have tried pretty hard to be being fair, open and honest. But Adam’s right that Trust Your Instinct by itself is hardly sufficient to conduct a decent interview. Too much belief in your own instincts can easily lead to arrogance and condescension. That principle always has to be counterbalanced with the equally important principle of Be Humble or, put an even better way, There But For The Grace…. (This applies not only to interviewing, obviously, but to the rest of work and life. Hubris has destroyed many a Microsoft competitor, and we’ve certainly had our share of near-misses.) The trick is finding the right path between Scylla and Charybdis – too much self-confidence or too little self-confidence can be equally deadly. Do I always get the balance right? Suuuuuuure I do…

One of the things that Adam will probably find most surprising is that I tend to agree with Poundstone’s “fifteen second” evaluation insight. More often than not, the initial impression I get from the very beginning of the interview is pretty much where I end up at the end of the interview, even though I consciously put my first impressions out of my mind. (One is certainly free to draw the conclusion that I do not really succeed at putting them out of my mind, but I would assure you I’ve gotten pretty good at it.) I’ve thought for a long time that the first thirty seconds of the interview are often the “real” interview and then the other fifty nine minutes and thirty seconds are follow-up to catch those times when the first impression is wrong. Which happens, certainly – sometimes people take a little while to get “warmed up” or may be having a bad day of it. But it is amazing how much the non-verbal cues that we’re hardly even aware of can say so much about a person. (I would point to another excellent Malcolm Gladwell piece from the New Yorker on this subject.)

And, finally, I’d completely agree that Microsoft’s style of interview is not a good intelligence test, mainly because that’s not what it’s intended to be. When I interview someone for Microsoft, I don’t really care whether they’re brilliant. I don’t really care if they’re an incredibly hard worker. I don’t really even care if they like computers and/or Microsoft and/or their old bosses. All I care about is, in order: a) can they do the job?, b) can they do the job well?, c) can they do the job well at Microsoft? The goal of the interview, in my eyes, is to figure that out and nothing more. There are really smart people who are nonetheless completely unable to get anything practical done. There are really hardworking people who nonetheless lack the creativity needed to solve difficult problems. Choosing for a single skill or talent or way of working is a really, really, really bad idea. The important question, indeed the only question, is whether the person is a good fit for the job and the company.

OK, one more point. In the case of the intern interview, Adam wondered aloud whether it would really be so bad to “give the kid a chance” and if he didn’t work out then “kick him to the curb and no permanent harm done.” The problem with that is pretty simple if you think about it for a moment. My team gets one intern for the summer (if we’re lucky) and we interview a bunch of college students for that position. It’s not a question of whether the kid is smarter than me or smarter than Bill Gates (in the case of the former, it’s often an even bet), it’s whether he’s going to do a better job than the rest of the kids who are vying for the position, pretty much all of whom are deserving of a break one way or another. I’d love to give ’em all a tryout, but there’s only so much one team can do…

[Hmmmmmm…. “Mr. Stud Interviewer.” I like the ring of that… Darn, now I’ll have to get some new business cards printed up!]

For once I get to out-Raymond Raymond and post something from the way-back machine. I’m not sure what it is with Microsoft employees and milk, but here’s another bug report from Excel from 1994 that I saved because it was funny. Aliases removed because a surprising number of them still seem to be around. (The T: indicates the person was a tester, I believe, while D: was for developer and P: was for program manager.)

——————– ACTIVE – 05/12/94 – T:XXXXXX ———————–
: Go to the kitchen
: Grab a Darigold chocolate milk carton
: Read the ingredients list

–! Either Darigold has discovered a chocolate cow, or something’s missing from the ingredients list. It only lists milk, vitamin A, and vitamin D. So where does the chocolate/sugar flavor come from?
——————– ACTIVE – 05/12/94 – T:XXXXXX ———————–
Moo info:

: Grab a Darigold 2% milk carton (NOT chocolate)
: Read the ingredients

–! Says it contains Cocoa, Sugar, Guar gum… Looks like the Chocolate and 2% ingredient lists have been swapped.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXXXXX ————-
looks like an internals problem?
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
UI Problem. I’ll take it.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
They don’t make milk at the Issaquah Darigold. Calling Ranier Ave.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
I can’t repro. Do you have the wrong MILKINTL.DLL?
————— ASSIGNED to D:XXXXX – 05/12/94 – T:XXXXXXXX ————-
By design? I think new US health labeling went in to effect this month.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
Wrong Department. Transferred from Distribution to Production. Left voicemail for “Frank”.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
Reproduces in the Development Kitchen. Need a native build of the Kitchen…
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXXX —————-
This is a feature. IntelliSense labeling knew that you didn’t want to feel guilty about the chocolate in the milk, so it didn’t list it on the box.
————— ASSIGNED to D:XXXXX – 05/12/94 – D:XXXX —————-
Recommend postpone. Reading the ingredients is not a common user scenario.
————— ASSIGNED to EXCEL – 05/12/94 – D:XXXXX ——————
By Design. However, there’s another bug that should be entered:
They got the calories correct on the chocolate milk (190). I still feel guilty.
————— ASSIGNED to EXCEL – 05/12/94 – D:XXXXXXXX —————
I think postpone for after mac release. Also keep the buggy samples fully intact with debug symbols and map file till this one gets reactivated for the next release.
————— ASSIGNED to EXCEL – 05/12/94 – D:XXXXX ——————
Please make sure a copy of the above is stored on \cashcow for future reference.
————— RESOLVED – WON’T FIX – 05/12/94 – P:XXXXX —————
Fixing the package is just a band-aid. We need to come up with a solution that addresses the real problem in 96. My recommendation is chocolate cows.

Please close and assign to DARIGOLD.
————— ASSIGNED to T:XXXXXX – 05/12/94 – T:XXXXXXXX ————
I thought the latest drop of ole2 manager supports insitu ingredient srvr
——————– CLOSED – 05/12/94 – T:XXXXXX ———————–
——————– CLOSED – 05/12/94 – T:XXXXXX ———————–

Maybe we all just drink a little too much milk…

…when ordering business cards, order the smallest batch possible. I’ve thrown out tons of perfectly serviceable business cards in my career so far because the cards failed to keep pace with whatever I happened to be doing at the moment. So this time when I ordered, I ordered as few as I could. They’ll still probably mostly get thrown out, but at least that saved some paper.

Joel recently posted “The Guerrilla Guide to Interviewing” on his site, and it describes almost perfectly the whys and wherefores of my own interview process. This isn’t too surprising, since Joel and I both started at Microsoft a few years apart and in teams that were not so distant, so we probably both got very similar kinds of indoctrination. I don’t follow every point that he outlines, but it’s pretty close.

I’d have to say that even after eleven years at Microsoft one of the hardest, hardest, hardest things to do is follow his dictum to Make A Decision. Most people at Microsoft are generally nice people who want people to feel good about themselves, so even at a company renowned for its hard-headed competitiveness people are sometimes very reluctant to say “no hire” about someone if they managed to seem not totally unqualified. Case in point, at the beginning of the summer we did a round of interviews for summer interns, and one of the interviewees was a very nice guy who seemed pretty smart but wasn’t so strong that he just jumped out as an obvious intern hire. For various reasons I had to call the recruiter before I had the chance to write up feedback in email and they asked, “So, is it hire or no hire?” And my immediate reply? “Well, I think he’s kind of a weak ‘hire’.” The recruiter was good enough to shoot back, “What does that mean?” and I came to my senses and said “Oh, yeah, right. Sorry. He’s a no hire.” As they say about pregnancy, you can’t hire somebody “just a little bit.” Either they’re working for you or they’re not. There’s no in-between.

Any time I start to get mushy on this point, I just remind myself of an experience I had a long time ago, back when I had done only a few interviews and was very insecure about making hire/no hire calls. My group at the time was interviewing for a position that had opened up on our team, and we interviewed this guy I’ll call Fred. Fred’s resume looked good, with lots of relevant experience. He sailed through the coding question, no problem. However, during the interview something nagged at me about him, something that was just not right, something that made me doubt that he was going to be a good hire for the team. Being young and insecure, I overrode my concerns and gave him a ‘hire’ recommendation. Everyone else on the team who interviewed him gave him a similar recommendation, and he was hired.

As it turns out, Fred was a disaster. I realized later that my nagging doubts had probably been caused by some subtle negativity on his part towards his current management during the interview. Once he was on the team, this subtle negativity blossomed into a full-blown bad attitude towards authority in general. As far as I could tell, Fred didn’t really give a crap what other people thought he should be doing or how they felt about what he was doing. As you might imagine, this made the quality of his work wildly uneven and also made him a generally unpleasant person to work with a lot of the time. Somehow this had worked out OK on his previous team, but it didn’t fly so well on my more functional team. Fred’s tenure with the team was not that long, thankfully, and after he left the team most of his code ended up being tossed out of the product and completely rewritten (much of it by me).

In the end, no permanent damage was done, but it was a very valuable learning experience for me personally. The experience taught me that the most important thing you can do in an interview is Trust Your Instinct. Had I listened to my instinct, I could have perhaps questioned Fred more closely about his views on management. Or I could have raised red flags that later interviewers could have honed in on. But I didn’t, and I (and the rest of the team) ended up paying the price. So now when I interview people, I look at the resume, I look at the coding question, I look at all the other factors Joel outlines, and then I do a gut check: is this someone I can see working closely with for the next three years? If they fail the gut check, that’s usually a pretty good indicator of a “no hire” recommendation.