As I noted before, as a Senior DBA I’m occasionally asked to participate in interviews for other prospective data professionals. I really do love doing this, and if you want to know why go ahead and read the first paragraph of my previous post on Curiosity.

Aside from technical knowledge, the other main thing I look for in an interview is some measure of integrity. As a data professional I want to find out if you’re concerned with solving problems or looking good. To the point: I’m not thrilled at the idea of working with people who want to look good.

If you work long enough with databases, and by that I mean even a few weeks, you’re going to screw up. You’re going to execute a DELETE without a WHERE clause. You’re going to create a new instance and forget to create backup jobs. You’re going to crush a production server somehow, some way in the middle of the day.

You’re going to do it. In fact, you probably already have done it. And you want to forget it.

But I want you to remember it.

If I am sitting across the table from you I’m going to ask you something like, “What would you consider one of your greatest technical success at one of your previous positions?” It’s an open-ended question designed to let you describe something in your database wheelhouse. It’s a chance to let you sell yourself, and it’s the biggest softball I’d ask.

But it’s also a bit of a setup because my next question will be, “What would you say was your greatest learning experience, where something you did went unexpectedly wrong?” Your answer to this question interests me more, because if you answer this question well there’s a good chance I’ll recommend hiring you straight away.

So how do you answer this well? It’s easy – embrace the pain. Show you can own a mistake. Think carefully about one of those moments you would rather forget, then describe what happened, how you realized what was wrong, and how you fixed it. If you can do those things I can tell you from experience you’re way ahead of most of the people I interviewed.

I think the natural reaction to this question is, to quote Admiral Akbar, “It’s a trap.” Maybe your initial thought process says this question is an attempt to goad you into telling me how stupid you really are. I can see that, but then again, I am interviewing you for a position to work with me. I want to be impressed by you, so I’m not trying to trap you. This why I use the words “learning experience;” I want to know what you learned from your mishap.

What often happens though is interviewees are reluctant to come up with an answer. “Uh, I don’t know. I can’t think of anything like that.” That kind of answer tells me something loud and clear: if you make a mistake you aren’t going to tell me. Pro Tip: don’t do that. Do you think I would rather work with a person who immediately tells me when they mess up, or with one who knowingly remains silent while the problems persist and the backup files age out?

I’ll put it another way: which type of person would you rather have on your team?

I am willing to give partial credit for someone who can give details about a time a coworker made a colossal mistake and they solved it, but understand that answer still makes you look like Mr or Mrs Perfect. And none of us is perfect. Moreover, I’m going to wonder if you’re going to pin your actual mistakes on someone else. Someone like me. Another Pro Tip: don’t do that either.

Don’t be afraid to answer the question. It shows humility, honesty, and an acceptance of responsibility. You want people to believe you have these qualities, right? See, it’s not a trap question at all.

In my experience I’ve found the best colleagues are the ones who weren’t interested in looking like they were smart enough solve problems. The best colleagues are interested in actually solving problems, even ones they inadvertently created.