I interview people as part of my job. Many times I know of someone who's looking for a good developer and I interview people every so often. I'm not by any means an expert interviewer, but I've learned a few things. Here are some notes for both sides of the table. These apply to technical interviews.

My goal as an interviewer is to determine what you know, and what you do not know.

1: Be honest
It's ok to say your an expert in a certain area, but know where you are not. Unless you wrote the entire system in question from start to finish, there's probably a few areas you are unsure in. Take .NET for instance. .NET is huge. It's impossible that you are a guru and know every IL and x86 instruction in every single class. You might have worked on many different parts, but don't try to say you aren't weak in any of them. The interviewer will find an area you're weak with, and you'll be forced to make a retraction “Oh well, actually, I've never touched remoting or Windows Forms.” It's not BAD to not know something. During an interview, the goal is to find if you're smart and will work well. If a question is asked and you have no clue, *say so*. I try to ask a question like that every time (some esoteric thing). Good candidates will answer with “Well, I believe this is related to that, but I'd have to look this up to be sure.“ or “I'm not familiar with that.“ Bad candidates will try to make up some BS answer, perhaps thinking that you have no clue what it is either. In other cases, the interviewer just wants to know your limitations.

If you are interviewing, and feel like you're getting BS'd, start drilling down. Perhaps the interviewee misunderstood the question or is unsure of what you want. I like to give people a second chance if they start something, just to show that BS isn't going to fly. However, if the second answer to “So, you have no weaknesses?“ is “No...“ -- red flag.

2: If your resume says you know something, you better know it
Don't copy and paste the .NET Framework class library reference into your resume unless you truly understand how to use each class in detail. If something's on your resume, we'll pound you on it. That's how we determine how well you know technology. The specifics aren't important. If you write “.NET Remoting”, you better be able to tell me what MarshalByRefObject does and how statics work in this context. If you have a CS degree you better sure be able to tell me what a binary tree is. And by all means, don't say you're a C# expert, and go on to describe that C# is actually just a mix between JavaScript and Visual Basic. (Yes, that really happened.)

When interviewing, many times a great candidate won't have experience with the particular technology you're using. That's ok, provided they can learn and are good in other areas. The problem is always trying to find something you can quiz them on. I look to their resume and see. Whatever they list, I ask them to rate themselves in it. If they still say they are experts in it, then I'll drill in with a few questions on that technology. “How good is their best?“ -- that's what I want to answer.

3: Know some basics
Everyone who can type can use Visual Studio. Saying you built a data-driven app with ASP.NET only tells me that you have basic mouse and keyboard skills. You better be able to handle some fundamental *thinking*. Traverse a tree, reverse a string, add items into a sorted array. Don't bother trying to defend saying “these are impractical -- when's the last time you used BinarySearch in a real app“? Umm, let me think... yesterday. You won't get hired for *real* work if you are just a IDE groupie. Sure, you can make cool things happen, perhaps even get paid. But I'm also interested in that the code you generate is decent. Sure, in many cases you might be able to go allocation crazy and box 1 million ints for fun. In other situations, you'll need to write better code, and you need to know how to do that. If you don't want these questions, say you dropped out of school and have been just programming for years. While it might not save you if you're an idiot, at least it gives the interviewer a frame of reference. At least that's better than saying you have a CS degree, but not knowing what a BinaryTree is, how to sort an array, or so on.

Interviewing people for .NET positions can be hard, because Microsoft's done the hard work for us in most cases. One red alert is “Well, perhaps I'm not that good in that, but I know my way around .NET.“ That's like a mechanic saying “Well, hmm, I'm not sure of the difference between these fluids and those hoses, but I've got 101 power tools and a lot of rags, so I can get it working.“ You don't want people who just “get stuff working“. You want people who are going to build something nice, something you don't mind working on later on.

4: Ask for clarification
If you are unsure about something, ask to clarify it. If you think there could be something else, ask. If you have to write a function, get some context. Is this part of a realtime process and needs to execute with a given amount of resources? Or is this a drag-n-drop application that runs once a year? Sometimes it won't matter, but when it does, you've saved yourself the trouble of saying “Oh, I didn't know you wanted *efficient* code. Let me go rewrite that.“.

Sometimes it's a good idea to hold details back to see what the interviewee does. Good candidates will try to gather requirements or probe you to see what's going on. Not so good candidates just start blasting away. On the job, that means they might be likely to just write some code without much forethought of how it's going to work with everything else. Or it means that they might spend 10 hours writing a super-efficient algorithm in x86 for something that's only called once a day or will never be a bottleneck, thus lowering productivity. Try to see what balances they strike out, what trade-offs they make. If a candidate seems hestitant, volunteer some information. On interviews, people react differently than they will on the job. Hesitation might just mean they want to ask, but are afraid of negative points.

5: Have a good attitude
Almost always, you'll be joining a team and have to work with other human beings. While it might be “right” to get the smartest person ('cause intelligence is all that matters, right? :)), even if they are arrogant, it probably won't happen. You'll want to show that you will get along with other members on the team.

When interviewing, I try to make sure that this person is going to cooperate. Are they going to write code while getting feedback from others? Or will they write their “own” code and defend it at all costs? Will they help out other team members, or try to fight for the “top”?

Anyways, those are just a few notes I've realised when interviewing people. Hope it helps someone!