NOTE: If anyone out there is interested in an ASP.NET development position in the Grand Rapids, MI area, let me know. I know about a pretty good opening. In case you're wondering, it's not with Sagestone (this time). And if you are, you can continue reading, but I won't be doing the interview, so it won't help you any!

Back to your regularly scheduled blog entry.

I've been in seven interviews for technical positions, and haven't gotten a single programming question. On the other hand, I've heard stories about Microsoft interviews where the first interview is a purely technical test. I can't verify, but that's what friends told me who interviewed with Microsoft at Michigan State's campus.

So when I interviewed, why wasn't I asked those types of questions? Well, for one, it was obvious. I was recommended by a friend, and was pretty much hired on the spot. The boss and I got along well, and that was it. But that was back in college, for a tech support position. In another one (and I didn't realize this at the time), there were no technical questions because the person doing the interviewing wasn't technical.

But those were "fluff" interviews for temporary jobs. On campus, when interviewing for my "real" job, I went on two interviews (which turned into a total of 4 interviews). No technical questions at all. Maybe it was different because I only interviewed at consulting companies. Maybe not. Either way, the questions were more about how I would approach a problem, rather than what a solution would be. Can I work with others in a team? What past experiences can you draw from that prove this? How do you best learn? How do you go about handling difficult situations? Things like that. They wanted to know that I could handle myself in front of a client, that I could work on a team, and that I knew how to learn.

That last part is the key. They didn't care what I knew. Most people come out of college not knowing what to expect from the real world, so what you know isn't as important as how you learn. In reality, that's what college is for - to teach you how to learn. These companies (to borrow a bad cliche) were looking for Mr. Right, not Mr. Right Now. Yeah, they could have found a stud who knew VB 6 and ASP (what most of my initial work was done in), but how do you know that someone can adjust to the ever changing landscape? Would someone who's a stud in VB 6 be appealing today? Probably not. But someone who can pick up concepts quickly and think on their feet would be.

So how do you interview someone, and find the right fit? To me, college recruiting is about finding someone who you (as a company) can shape and mold into what you need. Know you'll invest some time and effort to get them there. But most hires probably aren't right out of college, and for those, most times, you need a balance between finding someone who can fill in right now, and someone who can help you in the future.

So what questions can you ask to get both?

For the future question, you really need to dig into their past accomplishments. What have they shown in their background? If they aren't used to working on a team, then they probably aren't a good fit for a team oriented company. If they have past experiences that show they can adjust to the changing technological landscape, you can be pretty sure they are going to be able to adjust as things change. What other things do you need to look for?

The technical questions seem to be almost more difficult. For example, if you want an ASP.NET developer, what's one targeted question you can ask that you can be confident that if they answer it correctly, they are good, and if they fumble it, they aren't the right fit? I have no idea - because everyone's experiences are different. For example, if you ask someone to explain the difference between user controls and server controls, does answering that mean you're a stud? Does answering wrong mean you are a dud?

Some things to consider the next time you need to hire a new developer. Or, if you're a developer, things to think about before you go into an interview.