This month ‘s event is hosted by the fabulous DBA/SQL-consultant (& part time cartoonist) Kendra Little ! Go check out her blog, podcast , and training at sqlworkbooks.com really great stuff.
DBA interviews are tricky.The problem isn’t so much that the role is vaguely defined. Although, depending on the size of the IT org and the tech stack, it can vary widely from a jack-of-all (DB Dev, report writer, production ops, the works) to a highly specialized performance tuner who works with 7 other teammates, each of whom has a unique surgical specialty in the data platform. But that’s not the problem ― well, not the main problem. It is a problem in the sense that the business folks, especially HR, are notoriously and astonishingly ignorant of what a DBA or related role actually involves. But you get past that once you start talking to the tech leads and IT directors.
No, the problem is that, like most higher level technical roles, you don’t really know how a candidate is going to function in it (the role) without actually seeing him or her.. IN it . Do they keep a cool head when production goes down? Do they have a solid plan of attack for the dreaded “ everything is slow !” complaint-storm? Do they have a good handle on HA & DR architecture & implementation? Can you rely on them to actually practice and follow thru with those strategies? Can they be a continuous learner and keep abreast of new developments while still tempering that with wisdom & maturity, applying the correct tools to the proper problems? Do try add value to the team and organization by both teaching and learning from others?
These are truly difficult, complex questions that are nearly impossible to deeply assess and fully answer during an interview process. Largely because the only real evidence of their answers lies in actual experience . Sure, a cert here or an MVP there definitely helps your case. But at any rate, we try our best to chip away at the boulder.
To end on a more positive note, I’ll share some of the better questions that I’ve experienced during my career so far.
Some good examples.How would you design and build a data copy/sync process across/between tiered environments, say DEV-QA-PROD?
Really great question. This is a common problem is small-to-medium enterprises with legacy systems where DevOps hasn’t quite reached down to the depths of the internal application stacks and people are still dealing with “refresh cycles” on the order of months, quarters, or even years. You can approach it purely from a tooling perspective, but that’s not the whole picture. Thus, it calls for some thought and team-culture ideas as well as “knowing the nerd-knobs”.
We have a complex process flow that involves a lot of stored procedures, say 50 total. Some of these are non-sequential, meaning they can be executed in arbitrary order, while others need to be sequenced with each other in “blocks”. This is a vendor product, so ultimately, the customer gets to decide the schedule and order of execution of this flow. The solution needs to be maintainable by field engineers. How would you handle this?
Woah. Talk about diving down a rabbit-hole. This is interesting in the sense that it exposes a bit of the architecture and some of the potential pain-points that the team is hoping to solve, while leaving enough room for improvement and experimentation by the hopeful candidate. More to the point, it’s just an example of a more general technique, which to me is very effective: taking an architectural problem that actually comes from the “real world” (the company/team that’s interviewing) and asking for the candidate’s ideas on how to solve it. You don’t need to get in-the-weeds super-detailed about it, but outlining your ideas helps indicate how you think about complex challenges and shows what kind of value-add you would bring to the team.
And finally, a perennial favorite:
Tell me about a time you broke production , and more importantly, how you addressed and resolved it.
So many stories from the trenches involve downtime and mistakes, it’s good to ‘bond’ over them. It helps bring the egos back down to earth, and reminds us that we’re all just meatbags, making technology to do our bidding, occasionally to our own regret. It shows the candidate’s “pressure cooker” mentality, or at least, what they tell you about it.
In conclusion.If you’re a DBA, Dev, or IT pro, help your managers better understand your team’s needs when it comes to hiring. Get involved in the job description write-ups and screening process questionnaires. Barge your way into those ivory towers, if you have to ― or you’ll regret the time you waste on candidates who really belong in a different role than the one you’re after.
If you’re a manager, PLEASE LISTEN to your reports and tech leads. They know what makes a good team member, they’ve been doing it for a long time. Don’t dismiss their advice or block them from being part of the hiring process ― yes, they are busy, and yes, they can be crotchety, but their input is highly valuable toward bringing in effective & productive talent.
That’s all folks!
PS: I know I missed the “deadline” by about an hour..ish. I blame DST. Heck, it’s still Tuesday for the majority of the Western hemisphere. I’m not biased, but I write in English, so… ya know. Take it as you will. Now excuse me while I go hide from the blog-police in my ASCII-bunker.
<insert ascii-art bunker here>