malvasia bianca

I talked with a friend of mine at Agile Open California a couple of weeks ago who was bemused by an interview he’d had recently: the company had asked him to do a programming exercise in advance, which he enjoyed and was looking forward to talking about with them during the in-person portion of the interview. But when he showed up, they didn’t talk about that exercise at all, his interviewers just threw whiteboard coding questions at him. Which didn’t impress him: why would they pass up an opportunity to discuss programming in more depth and in a more concrete way in favor of an exercise that is shallower and less representative of real programming work?

I’ve always been at companies that spend most of their interview time doing whiteboard coding; but I’ll have to agree, that doesn’t make a lot of sense. I do spend some time asking behavioral questions, and some time asking questions about architectures of systems that people have been involved in; but the latter also feels artificial to me, because when I get an answer that I don’t find informative, I’m never sure if it’s because the person in question just isn’t good at explaining things or if they don’t really understand the pros and cons of the system in question in depth. Also, we want to let a good number of people talk to the candidate and to be respectful of the candidate’s time (both in person and at home); both of those lend themselves to relatively short questions. So I’ve found it too easy to end up with whiteboard coding, and if I’m not careful, with pretty simplistic whiteboard coding at that.

So yeah, I should try to be a more thoughtful interviewer. But I should also try to be a more thoughtful interviewee! Because: I’m in general quite good at whiteboard coding, and I also tend to think I’m a good programmer, but I’m not at all convinced that my programming strengths have much to do with my ability to do whiteboard coding. I think I’m a good programmer because I’m good at refactoring, good at testing, good at incremental development, good at getting at underlying structures in code; whereas I’m good at whiteboard coding because I had lots of practice with math contests teaching me to quickly come up with simple algorithm answers. I enjoy whiteboard coding fine on its own, and I also enjoy performing well on tasks, which means that I come out of interviews like that with a bit of a buzz; but I’m not at all convinced that companies which fill their interviews with questions like that are ones where I’d be happiest or where I’d learn the most.

So maybe the next time I’m looking for a job, I should pay closer attention to the kinds of questions I’m asked in interviews. Because if I don’t do that, I’ll end up selecting for companies that are, in turn, selecting for a very narrow profile. (“Top” schools in a conventional sense, thinks quickly on their feet in a sort of jousting fashion, has a startup pedigree.) And the fact that I happen to fit that profile well doesn’t mean that that’s the sort of job I should be looking for, whether for enjoyment reasons or for “stretching myself” reasons.