Normally I’d update the original post
But I wanted to add a bit more than was appropriate. For my interview question, I asked how you’d respond to a developer showing you progress they’d made on tuning a sometimes slow stored procedure.
While a lot of you gave technically correct answers about the recompile hint, and the filtered index, and the table variable, no one really addressed the fact that I was asking you to respond to a person that you work with about a problem on a system that you share.
To be honest, if I asked this question in an interview and someone started reading me a riot act of things that were wrong with the example, I’d be really concerned that they’re unable to work as part of a team, and that they’re not really a good fit for a lead or mentoring type role. I’m not saying you’re not technically proficient, just that I don’t want to hire the Don’t Bother Asking style DBA. I’ve been guilty of this myself at times, and I really regret it.
This is true about, and a problem for, us as a technical community. Very few people have learned everything the hard way. The nature of most SQL Server users is community and sharing oriented. Blogging, presenting, writing free scripts, etc. And that rules. If you’re interested in something, but don’t have direct experience with it, you can usually find endless information about it, or ask for help on forums like dba.se, SQL Server Central, etc. and so forth.
We’re really lucky to have way-smart people working on the same product and sharing their insights so that we don’t always have to struggle and find 10,000 ways to not make a light bulb. Or deal with XML. Whatever. Who else would have this much of an answer about making a function schemabound? Not many! Even fewer would ever find this out on their own. You would likely do what I do, and recoil in horror at the site of a scalar valued function. Pavlov was right, and he never invented a lightbulb.
Let’s look at this together
What I really wanted to get was some sense that you are able to talk to people, not just recite facts in an endless loop. When someone junior to you shows some promise, and excitement, but perhaps not the depth of knowledge you have, make some time for them. It doesn’t have to be the second an email comes through. Let’s not pretend that every second of being a DBA is a white-knuckled, F5 bashing emergency. You can spare 30 minutes to sit down and talk through that little bit of code instead of side-eyeing your monitoring dashboard.
That’s far more powerful than just telling them everything that’s wrong with what they’ve spent a chunk of their time working on.
Acknowledging effort is powerful
“Hey! You’ve really been cranking on this!” or “Cool, those are some interesting choices.” or at least leading with some positive words about their attempt to make things better is a far more appropriate way to start a conversation with a co-worker than pointing out issues like you had to parse, bind, optimize, and execute the thing yourself.
They may not be right about everything, or maybe anything, but if you just shut them down, they’ll start shutting you out. That does not make for good morale, and they won’t be the only people who notice.
Make an effort
When you spend most of your time in front of a computer, you start to forget that there are actual people on the other end. If they’re coming to you for help, guidance, or even just to show you something, it’s a sign of respect. Don’t waste it by being Typical Tech person.
Thanks for reading!
Angie says: As the only team member to most recently be a Junior DBA, I’d like to point out how much I appreciated it when my mentors came to MY desk to watch me try and do something, or when they locked their computer when I was at their desk with questions so it was clear that I had their full attention. It’s the little things that make the most impact sometimes!