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

Ask me anything!

The nice people at the programmerchat section of reddit have asked me to do an Ask Me Anything, and of course I am happy to do so. Thanks to reddit for the invitation.

For those of you unfamiliar with the AMA format, it goes like this. On the morning of Friday May 29th I will create a new topic on reddit where users can post questions as comments. At 4 PM Eastern / 1PM Pacific, I’ll start posting answers to those questions as fast as I can, for about an hour. Continue reading

A different copy-paste error

I briefly discussed copy-paste errors in code earlier; though this is a rich area of defects that I will probably at some point go into more detail on, that’s not for today.

Though this is a trivial little issue, I think it is worthwhile to illustrate how to think about these sorts of defects.

What is the defect?

Last week Jon Skeet “tweeted” humorously that in his work on the ECMA committee that is standardizing C#, they had found a mistake in the specification that was probably my fault; some commenters suggested that perhaps hell had also frozen over.

Continue reading

When everything you know is wrong, part two

What if I told you everything you know is wrong — would that be… cool?

Now that we’ve looked at a bunch of myths about when finalizers are required to run, let’s consider when they are required to not run:

Myth: Keeping a reference to an object in a variable prevents the finalizer from running while the variable is alive; a local variable is always alive at least until control leaves the block in which the local was declared.
Continue reading

When everything you know is wrong, part one

Finalizers are interesting and dangerous because they are an environment in which everything you know is wrong. I’ve written a lot about the perils of C# finalizers / destructors (either name is fine) over the years, but it’s scattered in little bits over the internet. In this series I’m going to try to get everything in one place; here are a bunch of things that many people believe about finalizers, all of which are wrong.
Continue reading

Wizards and warriors, part five

We’ve been struggling in the last four episodes to encode the rules of our business domain — which, recall, could be wizards and warriors or papers and paycheques or whatever — into the C# type system. The tool we’ve chosen seems to be resisting our attempts, and so maybe it’s a good time to take a step back and ask if we’re on the right track in the first place.

62103645

The fundamental idea in the first and second episodes was use the type system to detect and prevent violations of the rules of the business domain at compile time. That effort has largely failed, due to the difficulty of representing a subtype with a restriction, like “a Wizard is a Player that cannot use a Sword. In several of our attempts we ended up throwing exceptions, so that the rule was enforced by the runtime rather than the compiler. What is the nature of this exception?
Continue reading

Wizards and warriors, part four

Last time we saw that in order to decide what code to call based on the runtime type of one argument — single dispatch — we could use virtual dispatch. And we saw that we could use the inaptly-named Visitor Pattern to emulate double dispatch by doing a series of virtual and non-virtual dispatches. This works but it has some drawbacks. It’s heavyweight, the pattern is difficult to understand, and it doesn’t extend easily to true multiple dispatch.

I said last time that C# does not support double dispatch. That was a baldfaced lie! In fact C# supports multiple dispatch; you can dispatch a method call based on the runtime types of arbitrarily many arguments. Here, let’s dispatch based on the runtime types of two arguments:
Continue reading