Developer Interview Questions

I've had the occasion over the past few years in my capacity as a long-time developer to interview candidates for jobs within my company and for clients I've contracted for. As a result, I've had some time to formulate some opinions about what questions to ask developers who are applying for a position, and the types of answers to expect from a candidate that you'd want to hire.
Sadly, I think the market of good developers is far, far too small. I do subscribe to the philosophy that great developers are born, not made, although I also believe that you can produce adequate developers with good training and persistent oversight. It is really unfortunate that coders who want to get jobs aren't as versed in what makes a great developer great, and it's a frequent topic of discussion when hiring rounds begin.
I'd like to share a few of the qualities I like to look for in a web developer to both educate would-be coders as to what I expect, and educate would-be interviewers who wouldn't know a good developer if he hacked into his bank account and stole all his cash.
Great developers keep their skills fresh. Technology moves too fast to focus on a single skill for too long. Unlike some other industries, where I assume you can learn a trade and be good at it without refreshing your skills too frequently, changes in software development are so fast that staying too long in one place can put you out of skill quickly.
Plus, the trademark of a great developer is one who has not finished learning and has a voracious appetite for new things. Showing interest in new technologies implies that developers will have interest in new challenges, like your projects.
Do determine if a developer has been keeping his skills fresh, you could ask directly, "What are you doing to keep your skills fresh?" That's pretty succinct.
Another similar question could be, "What new languages are you interested in?" While not entirely applicable to your specific work environment, knowing that a developer is learning things about other languages ensures that they both have that hunger for a challenge, and that the knowledge they gain from a wide experience is applied to your projects.
Incorrect answers to these questions include sentiments such as "I already know Java and C++, so I don't need to learn more." Yes, you were taught those in school, and now you've learned just enough of anything else to get your work done. Expect short work hours and unimaginative code.
Another bad answer is "I haven't had the time, because my clients keep me too busy." Bull. I don't know of any developer that hasn't tried to sell a client who's flexible on new technology because it was new.
Great developers don't work alone. This doesn't mean that you should hire coders in pairs. What I'm getting at here is that no single developer can know everything. And no matter how good a developer is, there are going to be times that he just can't solve a problem. So what does he do?
There are a lot of angles to this aspect of a great developer. First, who is your support network? When you can't figure something out, what do you do; who do you go to?
Good answers include participation in developer organizations. Local professional groups are a great resource. Open source projects are a great resource, too. By building up contacts via these loosely-joined projects, a developer can quickly get insight into issues that are beyond his current knowledge. A cheese-out answer to this one includes talking over the problem with co-workers. It's a good option, but in the work environment isn't that an obvious answer?
Bad answers to this topic include, "I'd keep working at it until I got it." Yes, that works. Note the sarcasm.
The other main angle to this question concerns actually working together with other people. Presumably, development doesn't go on in a vacuum, and other people will eventually be looking at the code of someone new.
Once again, open source projects are a great answer, because these force developers to earn their place within the project by working with a wide variety of people of different backgrounds.
Answering, "I usually work alone, but I'm willing to work with others" isn't great.
I really believe that involving yourself in a community of developers is a great way to get the pulse of the industry. In software development, there are other ways to keep abreast of this, but learning what people think, learning about new things, and possibly even influencing them are more powerful when done in person. Certainly, this is more impressive in an interview, and is the characteristic of a great developer.
Great developers are opinionated. This is harder to quantify to non-coders, but real codemon keys will instantly know what I'm talking about.
As a sample question, "Which do you prefer and why: Spaces or Tabs?" Surprisingly, there is only one correct answer to this question, and that answer isn't "Spaces" or "Tabs". The answer is an adamant, ravenous, blitzkrieg of a response one way or the other. Great developers will not waffle on this issue. Sure, they won't argue about it (much) if they're forced to do it another way due to existing code standards, but they will have an opinion and they will stick to it. This is one of those crazy areas that becomes more firm with experience.
Incorrect answers to the "spaces vs tabs" question include: "I learned to use spaces in school, so that's what I use." No, you need an opinion. If you're just doing it because you were told to, you haven't explored you work well enough.
Another incorrect answer is, "I don't know what you mean." End the interview right there.
In this vein, you should also ask questions about tools. Developers are picky about their tools. And you should have some idea about what tools you like to use in your organization and what is accepted in the industry as a good tool.
Once again, it's not entirely an answer about the tools themselves, but that a good coder is going to be partial to certain tools. Some will say that a good developer won't care what they have to use, that they'll be able to build using whatever they're given. That's true. But they're going to prefer certain tools, and that's the important part.
Some specific examples to ask about include what editor they predominantly use. Emacs and vi are acceptable, FrontPage, no matter how adamant they are, is not. Developers who suggest that they do all of their work in Notepad are suspect, simply for the fact that if you had done any serious development on Notepad, after the first day you'd wonder what tools exist that are better. It's hard to believe that anyone with enough experience at development wouldn't have stumbled their way to free tools like Eclipse or PSPad.
Also keep in mind that free tools are just as if not more functional as a paid tool. Just because a coder doesn't own the latest Mirosot dev studio, that doesn't mean their skills are inadequate.
Great coders use source control. I had trouble figuring out whether to put this in the collaboration section or the tools section, so I gave it its own, because it is that important.
If you expect a developer to be able to work with another developer on the same code, then they must be fluent in source control. If you ask, "What source control tools are you familiar with, and what do you like the best?" you can learn a lot about a potential hire.
If they don't have any answers, then they're potentially not as experienced working with other developers. At some point, working with other people, the date-based file names and periodic shared-file overwrites are going to become a serious problem. Developers will look for a solution to this problem, even if they're unfamiliar with source control. The only people who won't are the ones that don't need to or don't want to work with other people - which may be fine if you only intend to hire a sole developer.
If they tell you they use cvs or svn, then you're getting somewhere. You get additional points for using SourceSafe, which means that you were coding Microsoft languages and were so desperate for source control that you'd try anything. You also get extra points for git or bazaar, since those are the bleeding edge tools these days. Use and familiarity of tools like Trac are a plus, too.
Great developers code in their free time. Here's a neat one. I don't know any developers who do not have a site of their own. None. Even if it's just for fun.
If you're hiring someone new, this can be a great determinant for how enthusiastically they will approach your projects. If they're willing to spend their own time doing "work" - whether to learn new skills, try things out, or keep practiced - then you know you have a developer who is at least interested in what he does.
Nothing bugs me more than kids who take the computer science program at their college just because "there's money in computers". People who love their work do it better. There are a lot of coders who love their work enough to do it in their of time. Find one and reap the benefits.
Great developers can work without a lot to go on. What this leads to is a very well-rounded developer, since they'll have skills of both developer and a designer. But how do you discover if a developer has these skills?
Ask questions like, "How would you approach a problem where...?" Provide some scenario of an application that you might ask them to build. The correct answer will talk more about the process than the implementation. An incorrect answer will focus solely on the implementation, without any thought of how to assess requirements, implement, do testing, and stage releases so that the project stays on track and on budget.
Great developers are great communicators, too. A great developer is going to have a personality that gets along with the rest of your team, and can relate his skills in a way that makes sense. If you can't understand what your developer is doing, then how are you going to resolve what needs to be developed?
Do see if a developer suits your needs, have him explain some of the more complicated projects he's worked on, and work through in detail what the complications were. Make sure you listen and try to understand. If you don't, then you're in trouble.
This isn't the complete list of things you should screen for in a great developer, but hopefully it'll open up a conversation that is meaningful in learning more about your inerviewee. Remember that no all developers are perfect, and even if they fail to perform well in all of your interview questions, they may still be able to perform well with a bit of training in the areas that they fall short.