The Mind Map approach to interviewing

Interviewing is difficult. Technical vetting is even more difficult. You only have an hour to determine if the person knows his/her salt.

I’ve been doing a lot of these lately, and I seem to be getting slightly better at them. In my worry to make sure we don’t hire the wrong people, I eventually settled with this as a way to break the ice and start talking difficult problems. I call it the mind map method of technical vetting, or the Mind map approach to interviewing.

The problem

Basically, you only have an hour or two to completely technically vet someone on what may be 20 years of experience. Even if you yourself are very smart, there’s simply not enough bandwidth in the world to guarantee a level of competency. And certifications are usually no help, because none of the stuff in there tends to relate to real world experience for your particular type of position.

The other problem is that the candidate is likely to be nervous at their best and sometimes plain scared out of their wits – even if they’re the perfect candidate. Not exactly conducive to your best thought processes. You don’t want to skip someone just because they’re nervous or the shy type.

So what to do? A little workshop with a mind map.

I thought about this originally when I interviewed a now-coworker. So he helped me test-drive it. Maybe part of the success is that it worked the first time I tried it? Anyway, I’ve been using it for a little while now on the technical vettings and it seems to have worked so far.

technorati tags:
interviewing

Mind Mapping an Interview

Basically the idea is to create a quick mind-map, based on circles, of the technologies you can ask good questions on (not necessarily of the ones you actually know yourself, you just need to know enough to ask questions, even if they’re just “tell me about X”‘). Your mind map may be different values to mine (indeed mine seems to be different every time I write it down).

Here’s a very small example, just to give you an idea (I use many, many more circles than these, including “Database” and “OOP” circles, put “rails” off ruby, that kind of thing):

Note there’s not a lot of logic to it. You’re not writing an outline here, just a map. Even the thinnest association is probably fine.

So you start with small talk, what they’ve done on their last position, let them get comfortable. Depending on how comfortable the person seems with eye contact (some geeks are actually less comfortable than others – you can gauge it usually within the first couple of minutes), stand up and start the mindmap, asking them to continue telling you about the position (it’s amazing how quick you can get at these once you did it once – it’s probably one of those “memory recall” features). If not, wait until the end of that question then stand up and start it – if they’re the hyperactive type they can join in as soon as you create the first couple of circles.

What you will instruct them to do is simple. They are to stand up next to you and put a dot with the red pen on the stuff that she feels very comfortable in, a green pen on the stuff he feels okay in, and leave blank the stuff she’d rather not be asked questions about. Also she can feel free to add circles for stuff you may have left out, or help you finish the map.

If you don’t have two markers, ask her to do a big dot, a little dot – in fact some people have spontaneously decided to use several sizes of dots, and sometimes it has actually work better than colors if you leave large spaces on the mind map circles.

What this seems to accomplish, in my experience, is the following:

• Gives Suzie Dev a feeling of initial control over the interview process, reducing stress. After all, she helped decide on the topics to cover!
• Gets her standing up and interacting on the whiteboard on something simple. So it sets the tone for feeling comfortable standing up again (in case she feels like coding along, drawing diagrams, etcetera).
• Provides you with a quick map of how they actually feel about the technical vetting, greatly increasing how much ground you can cover in such a short time. The resume may be bunk some “pro” wrote or have stuff that they used so long ago that it’s useless to try to get them to answer questions anymore, etcetera.

Inquisition Time

Now to asking the questions. This is up to you but basically (depending on the confidence of the candidate) I like to “go for the yugular” on difficulty and then step back. I try to concentrate on API usage and knowledge. If they know a lot of APIs and classes and what they’re for, and then can describe their usage and maybe write something on the board (java code, XML config stuff) that is more or less correct, I figure they’ve done it before.

If you are following this approach, be upfront about it, letting them know you go for difficult questions first then work backwards, and they should not feel self-conscious about their ability to answer. It’s important not to let the tension build to a point where now they feel like they don’t know anything and clam up due to nervousness.

Why do this? Questioning in reverse difficulty order tends to make it so they have to understand the building blocks that you would normally ask afterwards. This has the effect to accelerate the interviews of the “very smart people” and slow down the interviews of the “not so much there”. Within the first few minutes you are likely to get a feel if the person has what it takes to put up with reverse questioning, and it helps avoid the candidate flipping the Bozo Bit on you if you start too simple for their taste.

So what you want to do is start with the stuff they branded themselves as most familiar and go to the stuff they’re least familiar afterwards. If you notice them having trouble, jump around questions in their different areas of expertise (keep looking at the map and you’ll remember to go back to the original line of questioning).

What I have found, more often than not, is that I can use this method to cover enormous swaths of technology with an okay degree of confidence. They also feel like they got a real workout, no matter how experienced or inexperienced in a specific technology they are.