short takes

[cellio]

Yesterday's mail brought a lovely magnet from browngirl based on the Kipling poem "Helen All Alone", which I had not previously read. Good call and beautiful art!

We're playing D&D this Saturday, which means we can have a longer session than when we play on a weeknight. I'm looking forward to it.

And now a few links:

A really interesting article on how to interview candidates for software jobs (link provided by goljerp).

Buy T-shirts and more from the Total Information Awareness store! This is the Orwellian logo they don't use any more. (Link provided by a co-worker.)

Everyday etiquette hell (source forgotten). Put the Coke down first. Really. Either that, or plan to clean your monitor.

Comments

[jducoeur]

Actually, on thinking about it more, I'll point out one thing that the article misses: personality mesh. The reason we tend to do the design-session interviews is partly to see how the candidate thinks on his feet, but there's another important reason: to see how the candidate interacts with the rest of the team in practice. We've found several people who either wilted in the group situation (since the rest of the team are fairly strong personalities), or proved abrasive when working with others.

When you're interviewing someone high-power, it's very important to know if they will fit in well with the team, since interacting regularly is critical...

[cellio]

When you're interviewing someone high-power, it's very important to know if they will fit in well with the team, since interacting regularly is critical...

Excellent point. And while having lots of people meet the candidate is all fine and dandy, there's probably no better way to evaluate fit than to drop the candidate into a real discussion and see what happens. It's important that the discussion run long enough for the candidate to get the lay of the land, but I think it's worth the investment.

When I interviewed for my current position, which is an excellent fit, we spent a while talking about their product and exactly what I would be doing to improve its documentation. I was pretty much leading this discussion, which was novel for me in a job interview. (I suspect we went longer than we should have before I signed the NDA, but oh well.) I was their first, and so far only, programmer-focused tech writer, and I suspect they were a little unsure how to evaluate me. We did what amounted to a high-level requirements analysis and design, in about an hour. That was cool, and it gave all of us a good feel for what it would be like to work together.

I wish I had a better handle on how to inspire that sort of thing from the other side of the table. I'm not very good at conducting interviews, though part of that is presumably that I don't get much practice.

[jducoeur]

It's important that the discussion run long enough for the candidate to get the lay of the land, but I think it's worth the investment.

Yes. Our rule of thumb for second interviews (which is when we do the design-discussion thing) is that we slot an hour of the entire team for it, and we let it run long if it's going well. (Since, if it's going well, it's probably producing useful food for thought anyway.)

I'm not very good at conducting interviews, though part of that is presumably that I don't get much practice.

It is actually not as hard it might seem. Over the past couple of years, I've begun doing a lot more interviews (partly because my title's gotten a bit fancier, and partly because I've been in small startups where most of the team does interviewing). I've found that being organized is about 75% of it -- thinking in advance about what you want out of the interview, and some appropriate leading questions. A good interview is more of a conversation than a grilling, and a good candidate for most positions is someone that you can converse with well. So if you have fodder to start with, a good interview will often take care of itself.