Interview questions for database developers.

My guess would be that whether they know the difference between Scrum and XP is less important than how they solve real world problems, assuming that they are not entering a process-heavy organization. When we interview candidates, our most useful test (may Google never find this post!), is to describe a business problem and ask them what kind of database schema/classes they would build and how some operations would work. If they can't whiteboard a non-disastrous solution, we aren't interested. Stuff like how to divide your entities into reasonably normalized units (and when not to), where primary keys should live and how they should be created, etc. is going to be relatively agnostic. On preview, orthogonality's are all good questions.

The problem with testing technical people, usually the first thing people do is find some tiny properties of something no one uses and quiz them on their deep recollection of it. I think that's a horrible way to test techies. Personally, I can't remember half the stuff I do every day, but I always have Google on-hand, and I have a strong understanding the core ideas, even if I flip my PHP and Perl syntax from time to time. The reality is, you need someone who can go out and figure out what's needed and do it efficiently much more than someone who knows everything right now... Technology changes too quickly. So what's a better way to test? I've always liked questions that are more about getting you to explain your reasoning and their thinking process rather than coming up with a yes/no answer. Real world problems are the best, since you can gauge what they think of first - are they asking for more information? Are they trying to understand the uses of the database so they can build it better, or make it flexible in the right ways? The most important thing to know is every technical person is doing some form of customer service - since every technical project is meant to, in the end, be used by humans. The more human interaction their code will undergo, the more important it is to find a technical person who asks the right questions and is interested in the use of their code/database.

I think it's really important to give them a http://www.everything2.com/index.pl?node=hard%20interview%20questions or two. It's a good way to demonstrate how someone solves problems. Secondly, asking details about specific projects they've done in the past is a good way to go to get their technical skills. Ask what the business purpose of the project was, how it was developed, challenges, things that went wrong, etc. Finally, if you want someone that has an understanding of your business, you could talk to them about the business or your competitors. But this is probably least important. In fact, I'd say the questions I have are probably ranked in order of importance.

Ask a high level design question that doesn't necessarily have all the information required. Make sure they are willing to ask questions and probe deeper to find answers and clarify the problem. One they've figured out the general design (this should really be a 2 way conversation - remember, you'll have to work with them as well) pick one portion and get them to dig in and write some specific code or schemas just to make sure they haven't been completely pulling the wool over your eyes. If you don't have specific technologies you require them to use then let them do it in whatever they feel comfortable with. A good programmer doesn't necessarily need to know everything off the top of his / her head, that's what google is for. Far more important is knowing what questions to ask, knowing how to make design choices and tradeoffs, and being a successful communicator. Good luck with your search, finding good people is hard.

In an outfit where the marketing department organizes a developer search would knowledge of formal development methodologies be a blessing or a curse? You might be best served by simply throwing some real world problems at them and seeing if their solutions are sensible or completely insane.

I have voiced my concerns about this role sitting with Marketing, rather than being a service IT provides, but so far I've not been encouraged to elaborate. Is it reasonable to expect data analysis and db design to be platform/tech agnostic? I mean, is experience of MS SQL 2005, Oracle or Mysql, really important ? Isn't it more useful to understand database schema, know how to use query/report tools and have some development cycle methodologies ?

I'd go with orthogonality's questions. Although I think there is truth in the 'how do they approach problems' line there's some basics which if missing are going to cause a whole lot of pain (well if my understanding of what this role involves is correct). I mean, is experience of MS SQL 2005, Oracle or Mysql, really important ? If it's marketing that's driving it (by which I mean it's clearly not a super-heavy-duty role) specific product experience comes third (IMHO) after the orthogonality questions, followed by "how does s/he think out problems".

Joel on Software has some good stuff on interviewing for programmers, the general ideas might help here if you are looking to judge their tech merit. http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html In my opinion, the problem solving is the key. I've known good data analysts who could write no SQL, just use a report generator in Access or whatever, but they were able to ask the insightful questions to get the real data. Your marketing crew are probably looking for more than someone to take their commands, they want someone to lead the analysis, and insight in that trumps being able to rattle off an SQL string from memory.

The trouble with detail specific questions suggested by orthogonality is, I'm unlikely to be able to confidently know the answers myself. (I now have several tabs stacked for reading, thanks) Generally, I'm more interested in how staff arrive at their solutions, so real world questions will be useful there. As the role is likely to have a degree of freedom to design solutions, I'm keen for them to be able to document their work and comment any code in a useful form. I know as soon this role starts, various department will be asking for work to be done, and this resource may end up being managed by me, once Marketing have their stuff done. It's a weird situation.