Tag: interviews

Share Your Mistakes

I wrote the other day about a culture of allowing mistakes. We know mistakes are going to happen, so we ought to accept them. Even stupid ones. I make them at times, my wife does, my kid does, so I have been working to not get upset and emotional about them. Instead, hold someone accountable, let them fix things, and try to do better in the future. It’s what I’d want, and what I am trying to do with my family, friends, kids I coach, and others.

Many of us share knowledge and information. One of the reasons I love events like SQL Saturday is that others share their knowledge. I especially appreciate is when someone shares a solution and how or why they build it. Hearing their stories, the reasons for their decisions, and what works well is great. I learn in a similar way from blogs, which is why we syndicate blogs at SQL Server Central and include them in the newsletter.

By the way, if you have a blog and want to syndicate it (full feeds, please), contact the webmaster or submit an article.

We want to share knowledge, but we should also remember to share mistakes. We make wrong turns, and sometimes others might not take our advice because we recommend them. Instead, they might go down the same wrong path as we did previously. They might make the same mistake we did. Sharing and showing how a decision didn’t work well can be a powerful and valuable story. We all respond well when we empathize, and most of us can empathize with a mistake.

Almost every interview I’ve been in has asked me about a mistake, misstep, or other error that I’ve corrected or learned from. Usually, there is some variation on “tell me about a difficult situation” that you need a story about. In a technical interview, this might be based on a programming or database administration problem. In other interviews, this might require you to think about interactions with others.

In any case, I encourage you to keep stories handy for interviews or reviews. I’d certainly also suggest that you blog about them. Writing is a valuable communication skill we all need, especially in these days of mostly remote interactions. Practice writing, get better at presenting your thoughts, and learn to share stories that will help others in their journey to be a better professional.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

July 22, 2022
Evaluating a DBA (or AI)

Interviewing is difficult for many organizations. Often they don’t have a consistent process, and very often the people that do initial screening don’t know much about what a DBA does. Many of the somewhat trivial questions I see on Internet lists (what’s a clustered index?) are suited for someone getting started in the business, not for hiring an experienced DBA.

Sure, an experienced person ought to be able to answer those questions, but the real world often requires more nuanced questions that relate to the situations we find ourselves in. I found a list from Joey D’antoni recently, which has lots of open ended questions, designed to allow someone to talk about what they know and think, giving the interviewer the chance to gauge their level of expertise.

I especially like the questions around tuning and configuration. Tell me what you’ve done in the past and why. That way someone can tell you a story about their experience and then relate this to practice solutions. There is no good way to talk about these situations if you haven’t lived them. You might read someone’s blog, but a few follow-up questions on details will show whether you really understand the solutions or not.

Of course, you need a good interviewer that knows something about these topics to understand whether the answers make sense or not. An HR person or manager isn’t likely going to be able to judge how a candidate performs. While a developer or sysadmin might be able to gauge whether the person has spent time with SQL Server, if you need a really experienced person, you need someone equally experienced to interview them. That can be a challenge for some companies.

Hiring is difficult, but with more junior or intermediate positions, it might not matter as much. Evaluate whether the person has some knowledge and fits with your team. Can they work with others, which isn’t the same as just agreeing with them. Maybe more importantly, can they learn. Do they learn from your questioning, or have they shown they are learning.

For more senior people, references and networking matter a lot. If others recommend them (or don’t), that says a lot. It’s good to initially decide if this person is a good fit, and then engage someone like Joey or Glenn Berry (or Tim Mitchell in the BI space) that might provide a better evaluation of your short listed candidates.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

June 18, 2021
Interviews: Covering index

Performance seems to be a part of every DBAs job. It should be a part of every developer’s job, but I understand the focus to build software is different and many developers aren’t sure how much a feature or option they work on will be used. They don’t think too much about performance because at small scales, perhaps performance doesn’t matter a lot these days with multiple cores and many GB of RAM. I’d disagree with that, but I understand the perspective.

What’s interesting to me is that in many interviews I’ve had over the years, I’ve not often been quizzed on specific scenarios that might help improve performance for queries. It seems many interviewers like to ask trivia questions such as the difference between a clustered and non-clustered index or what configuration knobs should I change. Code questions might be how to find duplicates in a table or deal with NULLs in aggregates.

I hope that’s changing and more interviewers are giving candidates scenarios, and looking for ways to ensure that candidates think about performance. I hope someone asks how a candidate looks at an execution plan or structures code to remove RBAR concerns. I wondered about this since I chatted with someone recently that had been asked about covering indexes in an interview and was struggling to understand how a covering index might be different than a clustered, nonclustered, filtered, or other type of index.

This might seem like a trick question, and perhaps it is for some interviewers. After all, if you don’t know, you might correctly guess what this means, but will you know this isn’t a special type of index? Perhaps you’ll try to bluff your way through the answer and hope you get close.

Answering interview questions should be a discussion, as your answer can reveal as much about how you work as it can about your knowledge. Do you probe to understand the boundaries of the question or confirm that you know what’s being asked? Do you admit when you don’t know something or perhaps reason out loud? Do you give details that make sense, or do you launch into a lecture?

In this case, you should understand that this index covers a query. This isn’t a type of index, but rather a characteristic of an index against a particular query (or set of queries). To learn more, you might want to read a bit about adding included columns or how to evaluate your choice. If you don’t know much about indexing, get started with an introduction or go through our Stairway to Indexing.

Future versions of SQL Server will include automatic index tuning, but I think we’ll always need to balance the number of indexes we have. We’ll also often want to build some indexes that will ensure the system works fairly well when it’s first installed. That means data professionals (DBAs ans developers) need to understand how indexes work and ensure they can choose a good index most of the time.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.8MB) podcast or subscribe to the feed at iTunes and Libsyn.

March 21, 2018

Hiring Heterogeneously

I wrote recently about tech interviews and hiring, and even on an interesting interviewing technique for senior people. However we need to hire more than just senior people. We need to hire junior people, and intermediate people. Those roles are important for both growing the experience of your staff, and not getting caught with a “” as a bottleneck or single point of failure. Not that’s not Brent Ozar, though someone with his talent might be the single point of failure in many organizations.

Not everyone can be a superstar-expert-architect that decides how the system is built. Not all architects should spend time coding basic insert/update/delete code or adding clustered indexes to tables. We need a variety of talent levels that can get complete different types of tasks. There is tedious administrative work, supporting roles, necessary, though unexciting work like reviewing security, logs, audits, and more. While you can automate much of this busy work, there are still tasks that we must assign to people.

There’s another consideration as well in hiring that all too often people overlook. Hiring too many people that are too similar, who may think alike, who may view problems the same way can lead to an environment that doesn’t grow and expand, that loses it’s creativity over time. There’s a great quote that says “Where all men think alike, no one thinks very much” (Walter Lippmann). It’s important to have a diversity of opinions, and when you hire new people, you should consider this. You want talented people, and people that get along, but not necessarily all thinking about problems in the same way.

The world is a richer place for the diversity we have, and varying opinions, thoughts and ideas. We don’t all get along, but many of us can work together with mutual respect, considering each others’ viewpoints as we work to build solutions to the problems we face.

Steve Jones

Video and Audio versions

Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.