http://www.jroller.com/page/SKI_BUM/20030626#how_to_interview_a_programmer
How-To interview a programmer
There has been some interesting discussions on this issue here.
I've recently conducted a large number of programmer interviews and here's a list of typical questions I've asked (in random order):
- Pick one or more Java API's/Class libraries and critize them (both good and bad).
This is an interesting question to ask. It's interesting to hear how people relate to the things they're working with.
Some have the attitude that they just work with what's given to them, others haven't really thought about it whereas others are very critical about what they use. This gives a good impression of what kind of programmer you are faced with. - How do you participate in a team?
Again, it's interesting to see how the person participates in the work. Some are very anonymous whereas other are very aggressive. I want a team player, that can both give and take. - If you have a problem in the team, for example a design problem that you can't agree on, how do you usually solve the problem?
People are quite different. Some let the arguments decide the solution, others try to enforce their own opinion no matter what others think and others again just go with the flow. - When you design a system, what are your objectives (for instance do you care most about performance, the users, etc.)?
It's important to figure out what kind of developer you're faced with. Is it a performance freak that goes for optimizing everything (even when it isn't required) or is it someone that's very interested in what it is the user wants. - Can you draw me the design/architecture of the last project you participated in (looked from above, not in details)?
This shows the persons dedication for the craft and a what level they are at. They might not be an architecht, but I like that programmers show an interest in what it is they're working with. We've had quite a few that said they actually didn't know what it was they were working on and didn't care, others tried to understand or at least get an overview of what it was they were a part of. - In case the person wasn't a lead/architect on the project I would ask this question: If you were lead on the project, how would the design have looked like?
Does the programmer have an opinion about what they're doing and do they have an interest in putting their finger print on the software they're building. This can also show how far their technical skills goes. Depending on what kind of programmer you're looking for, this might be interesting (I mean if you're looking for a maintenance programmer this might not be all that interesting) - What books on software or programming have you read lately?
Here I hope they're reading books like Design patterns, Refactoring, UML destilled, The Pragmatic Programmer and books like that, and not Learn Java in 21 days. - How do you keep up with what's going on in the industry?
Does the person have an interest in what they're doing or are they just 9 to 5 programmers? - What's your experience with design patterns, refactoring and test-first development?
Again this shows how far the programmer has progressed and if they have interest in improving their skills to the better. - How do you design in UML? Do you design everything in details and the code mechanically afterwards?
I wanna see what kind of programmer I'm faced with. Does the person believe that all design is done in UML and then the coding done afterwards in "just" mechanical (which I don't believe in). - What's your attitude towards code standards, best practices, etc?
This is an interesting question. Some have very emotional opinions about coding standards, where as others simply don't care or code in their own way (so there's no unification). I prefer people who has an opinion and state it, but still will code after the standard we decide upon. All standards can be broken. In my opinion the code standard serves the purpose of make the code look the same no matter who programmed it. I don't believe in strict standards that can't be bend or broken (given the right argument). - If we specifically are looking for a Web programmer, I'm interested in hearing how familiar with the flow Web applications follow and the challenges there are
- How do you feel about learning new API's?
This is in my opinion a good question that helps me spot how people feels about change. Some charge new stuff and have already read about it or worked a little with a new API, whereas others prefer working with what they know. This tells you about what level and dedication the programmer has.
I don't give programmers a test they have to complete while at the job interview. I don't believe in these test, as they're not realistic. Few people design under extreme preassure (which some interviewees undergo). Instead I ask the API critique and Architecture/design questions. They give a clue as to how the person is as a programmer.
We usually conduct two interviews and I've considered given those that make it through to the second interview a home assignment that they can bring to the interview. But still this is just in the inception phase and might not be implemented. Any comments on that?
How to interview a (Java) programmer
meta