There's a million different articles out there on how to hire developers, or if you're a developer, how to get yourself hired. I'm not going to bother with a top ten list of questions, be they technical apocrypha, logic puzzles, or what not. When it comes right down to it the thing that I'm often making my final decision upon is a combination of the candidates comfort level, his confidence, and my respect and faith in his answers. It's hard to explain, but it's also almost impossible to fake.
Let me try putting it another way. When I'm interviewing someone who is supposed to be a technical person, I find that they tend to fall into four basic camps. I'm not going to number or label them, this is just an observation based on experience.
- Someone who has no meaningful, relevant technical skill. They've either lied on their resume, or they can't back up what they have done. They fall apart under questioning. Hopefully you don't have to see many of these, as properly preparing your recruiter with exactly what you're looking for can cut way back on the posers.
- Knows the technology but "not enough." Sometimes I'll get someone who I believe can write the code to get the job done. But they don't show any kind of deeper understanding, they're just parroting back what they've learned. They won't, I feel, be able to creatively move forward on their own when it's needed. More importantly, maybe they can move forward, but maybe I'm worried that they don't have the vision for such decisions and I'll constantly have to watch over their shoulder and micromanage them to make sure that they're not getting themselves into situations where yes, the code works, but that doesn't mean it's not completely the wrong way to do it.
- Alpha geeks. These are the guys that have got so much experience that *they* are doing *me* a favor by even showing up for the interview. Normally they have at least as much experience as me, if not more. The biggest problem with these folks is can they get over the fact that they didn't build the product, and they're not being asked to rebuild it? I used to work for a company that prided itself on only hiring this sort of superstar coder. The in-house joke was that every new hire spent his first week trying to figure out which part of the system he could singlehandedly rewrite in order to make his mark. No one ever successfully implemented such a thing, to my knowledge - but lots of them talked about doing it.
Personally I don't want to spend my time telling people why they can't rewrite large hunks of the code. Sure, a geeky conversation over lunch or in the hallway. But if there are specific projects to get done and I've got somebody saying, "If we only took 3 months to rewrite this whole portion over here, this project that's due in 2 days would be even easier!"
- Peers. This is the goal. I find one of these I can't get on the phone fast enough to the recruiter to say "Love him." A peer is somebody that I'm not going to have to argue with, nor am I going to have to micromanage. It's somebody who I can share the technical design with. Sure, at the end of the day somebody has to make the final decision, and I'm the one with the seniority, but my ideal development environment is to put three people in a room with a big whiteboard and not come out until everybody is on the same page. It is quite possible that this person does not have a spectacular pedigree of technical skills. What's important is that they have the foundations that enable them to work with what they've got, and learn new things as needed.
How do I know I've stumbled upon a peer? I have a simple test that may not be perfect, but it gives me a very big clue. I walk up to the whiteboard and I draw a problem. Or, I encourage the candidate to go up and draw something. Because in the real development world, you're going to be in front of a whiteboard with your fellow programmers and you have to be able to work together. Does this candidate have the understanding of my business enough, as well as the confidence, to offer suggestions on what I'm doing? Likewise is he confident enough in his own designs that if I ask questions about it he won't see them as an attack and go into defense mode?
I want somebody that I can collaborate with, bottom line. Whether I'm hiring somebody on the same level as me, or someone who will report to me, I use the same test. I want this person to be comfortable in the environment he's (or she's, I shouldn't be so politically incorrect) walking into. It takes a little longer, and it's much harder to explain to the recruiter what I'm looking for and why a candidate doesn't have it, but it's worked very well for me in all situations I've used it. Where I've personally been the one responsible to say "Yes, hire this person," I've almost never been disappointed.