Hey now, you’re an all-star

What regular work activity has the highest impact on the organization in the least amount of time and effort?

I haven’t done any science on this, but anecdotally it sure feels like recruiting, interviewing and mentoring are all huge impact-per-time compared to technical stuff like writing code. I can think of people I spent a few hours convincing to interview who ended up making multiple decades of contributions to Microsoft, for instance. Encouraging good hires and then helping grow each other’s skills are multipliers.

Why then, are so many companies so bad at helping their employees recruit their talented friends?

I don’t know! There’s got to be some perverse incentive somewhere that makes these processes broken. I was asked recently by a reader to share a “war story” on this subject. (I think I have told this story before but if I did I can’t find it, so here you go again.) Today’s story takes place about twenty years ago, and I sincerely hope things have improved at Microsoft in the intervening decades.

A friend of mine, let’s call them B, who I knew to be a talented software engineer with great technical PM skills was looking to change companies; I happened to know of a team in devdiv that needed someone with their exact skill set, and so I submitted an employee referral into the system. B got an interview and accepted an offer, and I was very happy right up until a few weeks later when I got a package in interoffice mail. The package contained:

  • A single sticky-paper gold star, like a primary school teacher puts on a perfect quiz.
  • A flimsily-built off-brand miniature lava lamp knockoff. (For my younger readers: a lava lamp is a novelty lamp in which the bulb is below a conical closed glass vessel containing oil and wax; the lamp melts the wax which then circulates in a sort of psychedelic convection pattern. There was a lava lamp fad in the late 1960s and early 1970s; I remember my parents had a blue lava lamp when I was a very small child. There was a (very brief!) resurgence in this fad in the late 1990s and it was common at Microsoft for lava lamps to be given out as funny prizes. I had three in my office at one point.)
  • A poorly photocopied note. Obviously I do not recall the exact wording of the note but I can very easily give you the gist. It was something like:

“You’re a recruiting all-star! Thanks for your successful referral. Here’s a gold star to put on your office door to let everyone know that you’re an all-star! Please fill out a survey on your referral experience at [internal site]”

Sigh.

They invited me to give them feedback and so I did. Rather than filling out the survey, I sent the head of recruiting a personal email. That of course is lost to the mists of time, but again, I can certainly give you the idea. It went something like:


Dear X, thank you for the off-brand lava lamp and gold star. As requested, I’m providing feedback on my experience of referring B to the Z team.

I do not require either a reward or recognition for successfully referring a friend. The reward is that I now get to work with someone great who will help us achieve our division’s goals. But if you are going to reward that behaviour, you could do a lot better than a literal paper gold star, a photocopied form letter, and a five dollar junk store lamp.

You could, for instance, pay out a bonus for successful referrals. You know better than I do that sourcing talent is expensive. You would pay in excess of 10% of the salary of my new employee friend if they had been sourced by an outside talent agency. You could pay employees for referrals at, say 2% of salary. We’d feel genuinely appreciated and incentivized, and you’d pay a fraction of what it would normally cost. A cheap lamp and a sticky paper star makes it seem like the company cares very little that I put in this effort, and I know that’s not your intention.

You know what I would find even more motivating than a bonus? Instead of a photocopied impersonal form letter from recruiting, you could encourage the hiring manager to send me and my manager a personal email that says “Thank you so much Eric for helping recruit B to our team; we really needed someone with that skill set and I am looking forward to working with them. I will remember that you helped out our team in the next performance review cycle.” The documented goodwill of a hiring manager in devdiv is not something I can buy with money, but it is valuable to my career.


I was young and naive. I expected a reply to my thoughtful, well-intentioned, solicited critique; I got none. I also never got another gold star from recruiting, so maybe that message landed; I don’t know.

I’d be curious to know if any of my readers have received similar “awards” that send the opposite message as was intended. Leave a comment if you have!


Next time on FAIC: I have not forgotten that I said I’d blog more about Bean Machine, but before I do that I’d like to share some thoughts on a Python library I’ve been developing as part of that effort. I am a novice Python programmer and I’d love to get some feedback from the experts and novices among my readers alike.

Interviewing candidates

A quick note: I’m going to be traveling for much of the rest of June and I haven’t got articles queued up, so the blog will go dark for a bit; see you in July!


In the last two episodes I did reruns of earlier articles on the technical interview process. I thought I might go into a little more detail about how I structure interviews and what I’m looking to get out of them.

I have some primary goals:

  • Prevent bad hires
  • Make good hires
  • Leave the candidate with a positive impression of the company

Of course preventing bad hires is of far higher priority than getting good hires. If we fail to get a good hire, that’s too bad, but if we make a bad hire, that can drag down the productivity of a team for years.

That last point is also key; if we want to hire the candidate then obviously they need to have a positive impression. But I want all the no-hire candidates to have a good impression as well. They have friends who might want to interview. They may be in a position to make purchasing decisions or product recommendations now or someday. An interview is a very expensive “high touch” business process; if we don’t get a hire out of it, at least maybe we can get a customer, or if not that, at least some good will.

The actual interview goes like this.
Continue reading

It’s not magic

Last time on FAIC I reran my 2004 article on tips for coding on whiteboards for interviews. This time, a rerun from 2009 article on a similar topic. Next time, some more thoughts on this subject.


Interviewing job-seeking candidates is probably the most impactful thing that I do at Microsoft as far as our business is concerned. Sure, the day-to-day work of implementing the compiler is of course what I am specifically there to do. But ultimately nothing impacts the bottom line of our division more than preventing bad hires and encouraging good hires. The dozens of people that I’ve interviewed who got hired will collectively deliver much more value (or do much more damage!) than I can alone. So I think about it a lot.
Continue reading

Writing code on whiteboards is hard

I got an email from a reader in India recently asking me to talk a bit about thoughts on technical interviews. Here’s a rerun of my 2004 article on that subject. (Note that this was before I was on the C# team, so this has a very C++ flavor to it.)

Next time on FAIC I’ll post another rerun on the same topic.


I occasionally interview candidates for development positions on my team and other Visual Studio teams. Plenty of people have written plenty of web pages on interviewing at Microsoft, so I won’t rehash the whole story here. What I wanted to mention today was some words of advice for candidates for development positions. This is by no means complete — I want to concentrate on one important aspect of the interview.
Continue reading