Interview questions for database developers.

July 24, 2007 5:30 PM

What useful interview questions can I ask to candidates for a Data Analysis/Database Developer position ?

Our marketing department has organised some interviews for a Data Analysis position. There's an expectation that this will involve some database/app design and development too.

I've been pulled in to the interview process because I'm an IT Manager, but frankly other than my own development tinkering, I have no experience of formal development methodologies.

I'm really looking for a couple of questions which will help us make a good choice.

Thanks

posted by matholio to computers & internet (11 comments total)

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.
posted by mrbugsentry at 5:36 PM on July 24, 2007

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 ?
posted by matholio at 5:47 PM on July 24, 2007

What is Normal Form? What Normal Forms are there? Why are they important? When would you denormalize?

What is referential integrity? Why is it import?

What is a join? What kinds of joins are there?

What is a correlated subquery? What is a non-correlated subquery? What's the difference between a correlated subquery and a join?

Why is a group by useful? What's the having clause do? (For what you're looking for, these will be particularly key questions.)

What's a view? are views useful?

Given a salesperson table (id, boss_id) and a sales table (product_id, salesperson, sales_date) , how can I find out the total sales per salesperson? The total sales by salespersons by quarter by sales team? (A team has a boss in common.) The top selling salesperson and sales team per product, per product per month?

Retail stores often use a "454" fiscal calendar. How can I determine a date's "454" fiscal year and period? Write a view that shows the sales table's salesdates as "454" years and periods.
posted by orthogonality at 6:09 PM on July 24, 2007 [4 favorites]

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.
posted by mrbugsentry at 6:14 PM on July 24, 2007 [1 favorite]

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.
posted by lubujackson at 7:05 PM on July 24, 2007 [1 favorite]

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".
posted by southof40 at 8:14 PM on July 24, 2007

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.
posted by bystander at 8:32 PM on July 24, 2007

I think it's really important to give them a logic puzzle 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.
posted by Pants! at 9:25 PM on July 24, 2007 [1 favorite]

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.
posted by matholio at 10:16 PM on July 24, 2007

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.
posted by mikw at 12:13 AM on July 25, 2007 [1 favorite]

You might want to ask marketing how technical they want the analyst. Should the analyst be real technical (db designer and admin) or understand enough to be able to make understandable requests of the IT group in putting together a data warehouse (you sure don't want to do data stuff off your live server). For an analyst I would want to know:

1) can they problem solve -- because you can look up SQL commands or use the GUI of Crystal Reports just fine once you know what the issue is and how they want to go about it;

2) Do they understand querying to the level they need to do the projects assigned -- knew admins who could only do base level querying and did not understand business/executive needs or what was really being sought;

3) Can they convey their analysis in both oral and written communications to the various stakeholders;

Now if they want someone with a lot of technical DB and DB Warehouse skill then Orthoganility's post is good for the technical grit BUT you will be paying to have the skill set of a DB person AND an analyst who can research, have a feel for your firm's data, write, edit and present material at the enterprise level.
posted by jadepearl at 5:57 AM on July 25, 2007