Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I am a software developer and am helping my team hire a MySQL DBA. The core challenges that we are facing are:

  • Slower queries and performance due to Hibernate.

  • Database management (backups, tuning, patches, security).

  • Scalability due to increase in data from new data sources and accumulation of older data.

  • We plan to start data mining and data warehousing in the future. Not sure how but that is the direction.

We usually have programming cases where we ask developers to build something for an interview, but it's a bit hard to do a DBA interview in the same fashion.

Can you give suggestions on how the interview should be conducted?

share|improve this question
1  
Seems like this would probably be better of Programmers.Stackexchange, but I'm new to this community so don't take my word for it –  DForck42 Sep 28 '11 at 19:10
    
Someone please protect this question. These are great answers !!! –  RolandoMySQLDBA Sep 28 '11 at 20:21
    
Wow! you managed to find a MySQL DBA? Good job! –  Jonathan Oct 1 '11 at 22:09
    
@RolandoMySQLDBA flag it next time ;) –  jcolebrand Oct 2 '11 at 5:31
add comment

4 Answers

up vote 8 down vote accepted

Not a complete list, but rough list of things I would try to cover. It also depends on whether he will be the first "true" DBA or in a DBA team. Whether the DBA is responsible for the machines, too, or only the database on top of that. etc.

  • what RAID configuration should be used
  • backup strategies for databases.
  • MySQL specific things like differences between MyISAM and InnoDB
  • backup strategies and recovery
  • Let them do some SQL queries and some query optimization (usage of explain etc. even when using hibernate. Sometimes it's good to bypass hibernate to gain performance)
  • did I mention backup strategies
  • For scalability a DBA should know about different replication modes (RBR, SBR, mixed mode replication, replication maintenance such as observing replication lag and binlog maintenance)
  • InnoDB tuning
  • What kind of files are being written by the DB (eg, ibdata and log files) and how they can be arranged (eg, one ibdata file per table, move them around on different partitions, InnoDB compression)
  • Discuss monitoring tools. What are you using, does he have experience with that tool or a similar one?
  • I'd also look into system tools like iostat/memstat/vmstat/whatever your OS provides. Give him a system with some load and let him find the cause
  • And maybe discuss issues in MySQL backup and especially restore ;-)

I'm sure others here can extend this list

share|improve this answer
    
Hey there Johannes ;) I like the backup/restore focus - really that's what matters. Would love to see someone give a MyISAM/InnoDB comparison I agree with though. –  Morgan Tocker Sep 28 '11 at 15:23
1  
+1 for importance of backups. –  geoaxis Sep 28 '11 at 15:28
    
Great answer for MySQL and non-MySQL issues. +1 !!! –  RolandoMySQLDBA Sep 28 '11 at 20:05
    
Thumb up! You could add something regarding backup+restore strategies to that list! ;-) –  Marian Sep 29 '11 at 21:02
add comment

I wrote about this a while ago, after I contributed to the interview process at Percona.

I think that to assess someone, you have to try and make them do what they would be doing in regular day-to-day activity. Random questions like "What is a serial data type in MySQL?" or intelligence questions like "why are man holes round?" do not achieve this.

You also want to make sure that you give everyone the same test. If you have an open-ended conversation only interview, the more confident and (slightly manipulative) people will stand out, as they can subtly skirt around your questions and change them into ones they are good at answering. You won't always realize when this is happening but it often contains something like "when I started as a DBA we had 2MB of RAM, and used tapes.. blah blah blah" :P

Having said that, here's my standard list of questions:

  • Describe the process by which MySQL replication works?
  • What does the D component of ACID mean in practical terms?
  • What does innodb_flush_method=O_DIRECT change? (Be careful with this one: the common understanding of this is often wrong.)
  • Say I write a query like "INSERT INTO my_table (a,b) VALUES (1,2)". Describe to me in as much detail as you can what happens inside MySQL.
share|improve this answer
    
+1 for the bit about random trivia-like questions not testing the abilities properly. –  Derek Downey Sep 28 '11 at 16:11
3  
If you're going to test them on what they're going to do day-to-day, is it going to be "open-book"? I mean, in my undergrad classes, a few of the teachers insisted on you memorizing everything, while others were realistic -- in the real world, you have reference manuals to consult; the important part was knowing where to find the answer, sometimes even more than thinking you know the answer, and being wrong. (and in some cases, things change, so checking the docs for the specific software version is important) –  Joe Sep 28 '11 at 16:24
    
+1 for open book. If you must do closed book, it may indicate your questions are trivia ones. –  Morgan Tocker Sep 28 '11 at 18:16
    
Read your article and your answer. Whoa !!! Great questions. I'd love to be fly on the wall and watch what happens when some is asked questions like these. I should use these question when interviewing candidates myself. Thank you big time !!! +1 !!! –  RolandoMySQLDBA Sep 28 '11 at 20:03
add comment

Although I agree that the many seemingly random interview questions (eg, the manhole cover one), aren't really that useful ... (except, maybe for an industrial designer, and just for that one case).

Once you get past the trivia aspect of many of them, they're intended to be stuff that you do not know the answer to, and so you'll have to describe how you'd go about finding the answer. Or not. Eg:

  • make up something plausible and/or try to bullshit your way through. (might be useful for sales & marketing? any other field, don't hire.)
  • estimate it based on other information
  • explain how you'd get the necessary information to solve the problem

...etc.

When I've been in charge of the hiring process in the past, I try to do a completely unscheduled 5 to 15 minute telephone interview (just call 'em up, as them if they could give you a couple minutes of time ... not all could, as some were at the job they were planning on leaving) ... just to assess how much I think they're bullshitting on their resumé.

Eg, when we were hiring for a senior PL/SQL programmer, I'd ask them what the parts of a PL/SQL block were. These days, it comes up first thing in Google ... that wasn't the case back in 2003. Most of the people we interviewed might've used Oracle before, they might've written SQL for Oracle ... but if you can't give me a clue that you know what a PL/SQL block looks like, you're not up for a senior PL/SQL programmer job.

...

And, that being said, my go-to question for any in-person interview is:

Star Wars or Star Trek?

In part, you get to see how they handle a situation where there's no best answer, if they're diplomatic in their answer, or if they think outside of the box (eg, Dr. Who or Firefly are valid answers). Where I currently work (a space physics lab), saying that you've never seen either might be a fail unless you're a foreigner. Saying you don't like either, and explaining why with a good reason would be a pass, though. Geeking out about either one too much might still be a fail (as no one wants to work with that person)

share|improve this answer
    
It's important to have the off the wall personal questions to see if they'd be a good fit for the team. +1 –  Derek Downey Sep 28 '11 at 19:22
    
@DTest : but you have to be careful about personal questions ... there are lots of classes of questions that you're not allowed to ask, at least not in the US : eeoc.gov/facts/qanda.html –  Joe Sep 28 '11 at 23:42
add comment

I'd suggest looking also at some already established lists regarding DBA interviews:

  • Top 10 SQL Server DBA Interview Questions - by our own Brent Ozar

    • favorite questions:
    • "Can you give me references from other DBAs and developers who aren’t at your company?"
    • "A project manager needs a new SQL Server. What do you ask her?"
  • Junior DBA Interview Questions - by our own Thomas LaRock

    • favorite question: "If I asked you to learn how to make a query faster, where would you go?"
  • Database Screening Questions - by Grant Fritchey

    • favorite question: "You’re the DBA. The phone rings. One of the users is on the line. They say “The database is slow.” Then they hang up. What do you do?"

They are all great SQL Server writers. I know that some of the questions might be SQL Server oriented, but most are not and can be used in a general DBA interview.

share|improve this answer
1  
Could you perhaps add your favorite question from each list here? That would give this answer a lot more value. –  Nick Chammas Sep 28 '11 at 16:10
    
My main motivation was also to see how these topics should be tested (ie ask about replication or hand a test system for them to set it up). I am going thorough the lists and I guess general DBA level questions would not find me a good MySQL specific candinate. –  geoaxis Sep 28 '11 at 16:21
1  
@Nick: thanks for the note, updated the answer. Geoaxis - a good DBA of whatever flavor will be able to catch the intricacies of MySQL. Eg: when hiring a Java developer do you ask only strict technical Java library questions or also general programming questions? –  Marian Sep 28 '11 at 20:50
add comment

protected by jcolebrand Oct 2 '11 at 5:32

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.