T-SQL Tuesday #175: Old Tech, New Tech, Bold Tech, Blue Tech

Invitation from Andy Leonard.

Microsoft Build 2024 was just last month (at the time of this writing) and the sheer number of announcements is almost overwhelming! You can read about the announcements from the Build Book of News and view selected sessions online.

I am honored to host this month’s T-SQL Tuesday and the topic I chose is: How do you balance the benefits and liabilities of older, existing data and software platforms compared with newer platforms? What factors do you consider? Which features motivate you to switch or stay? I’m almost positive the answer is, “It depends,” and I certainly understand because that’s also my answer! I ask that you complete that sentence, though; what does “it depend” upon?

“It Depends on…”

I spend most of my time with data platforms. I focus on data engineering so I pay particular attention to the field. My answer is: I weigh the pros and cons and (attempt to) measure the inertia of switching against sticking with the existing platforms. There’s objectivity and subjectivity in this approach. Where’s the line between the two? Excellent question.

Regarding Data Engineering

Although I continue to provide ADF and SSIS training and consulting, I am all-in on Microsoft Fabric – specifically Fabric Data Factory.

I looked at Fabric Data Factory after Fabric entered public preview during Microsoft Build 2023. I poked around a bit and decided, “Not yet.”

I looked again in November 2023 and concluded: “Huh. Ok. Time to tinker.” Since I was busy with client work, I really didn’t have time to tinker until January 2024, and what I saw impressed me mightily. I cannot recall the specific features and improvements I saw, but they weren’t there in November and they were there in January. I was hooked. Since that time I’ve been paying attention to the posts of Fabric people at Microsoft as well as the Microsoft Fabric Updates Blog (yes, there’s a blog focused solely on Fabric updates… that’s a clue).

I noticed Microsoft is investing a lot of time and energy (i.e. money) into Fabric. In fact, I’ve never witnessed Microsoft develop so much so fast in my experience, and my experience dates back to when the years began with a 1. Having years of experience isn’t good for many things, but it’s great for identifying trends that span decades.

That’s why I’m all-in.

How About You?

  1. How do you balance the benefits and liabilities of older, existing data and software platforms compared with newer platforms?
  2. What factors do you consider?
  3. Which features motivate you to switch or stay?

T-SQL Tuesday #174: Your Favorite Job Interview Question

Invitation from Kevin Feasel.


If you’re reading this, there’s a pretty good chance you’ve been on a job interview before. You might even have received a job at some point!

Or maybe you’re on the other side of the hiring table: you’re searching for the best possible candidate for your company’s Paper Shuffler 3 opening (with a possibility of promotion within the next 5 years to Paper Shuffler 4).

Today’s question applies to both sets of people: interviewers and interviewees. The question is, What is your favorite job interview question? There’s a lot of latitude in how you answer this, and as a spoiler, that’s the type of question I like a lot.


Job interviews are a strange and awkward dance, where interviewers and interviewees are trying their best not to embarrass themselves too badly while simultaneously attempting to suss out whether there’s a mutual fit. Along the way, the interviewers tend to ask a bunch of questions, listen to the interviewees’ responses, make affirming noises on occasion, and quietly write down their lunch orders because they already know this person’s a hard pass but they feel like it would be rude to cut the interview short.

But what actually goes into these interview questions? Are you simply googling “DBA job interview questions” and asking people whatever pops up at the top of that list? Or maybe asking your favorite chat bot to do your job for you, like an even-more-dystopian version of Wall-E?

Hopefully not! Because this is your chance to shine, dear interviewer. And dear interviewee, as well: remember, you’re interviewing the company at the same time that their agents are interviewing you. You can and should have questions of the company and the job.

Now that I’ve given you the rough idea of the task at hand, I’ll share some of my favorite questions, both as interviewer and interviewee.


I’ll split this two ways, once as interviewer and once as interviewee.


Because I struggle to come up with just one question in this section, I’ll give you a few. And it’s only happenstance that none of the questions in this section actually come in the form of a question.


As an interviewer, I love open questions, some of which don’t necessarily have correct answers. For example, here’s an idea I stole from Brent Ozar. I really like showing a picture to an interviewee and asking what they see, similar to a Rorschach test but hopefully with fewer psychological hang-ups. I’ll show a person a picture like the following:

Clearly, this patient has Oedipal issues. I recommend he blind himself and go into exile.

While showing the image, I tell the interviewee something like, “I would like you to tell me what you see in the picture. There are no right or wrong answers, but I would like to hear what you find interesting about this.”

What’s important is, these pictures are simulations of real code and processes. This is a picture from Azure Data Studio that includes some T-SQL. If I’m hiring a person to be a T-SQL developer, I’ll want to hear about the code itself—with bonus points for telling me a horror story about the performance of PERCENTILE_DISC() or PERCENTILE_CONT() over large datasets and how you’ve had a great time working with APPROX_PERCENTILE_CONT() in SQL Server 2022—and recognition of the tool. This may spur on some further conversation. But what’s important is, I don’t necessarily have some set of right or wrong answers, such as “You must point out these six things on the image in order to pass.” For example, if the interviewee hasn’t used the WITHIN GROUP clause before, we might chat about that. Or maybe I’ll hear a story about using SQL Server ML Services and calculating five-number summaries in R instead. What I want to get out of this is your level of familiarity with the most important tools and code concepts that we’d expect a person to have based on our job description.


This question I stole from Sean McCown. It’s simple but powerful: “During this interview, we certainly didn’t cover everything there is to know about this field. What I’d like you to do is, ask yourself a technical question. Then, provide the answer to it.”

Sometimes, during an interview, a candidate has a rough time of it. You’re mentally ticking a lot of “wrong answer” boxes and ready to write this person off. But you could be missing something. Suppose the candidate is a replication savant, but you didn’t ask anything about replication at all during the interview. This gives the candidate a chance to talk about replication and gives you a chance to drill into the topic further. Even if your company doesn’t use replication at all and you still pass on the candidate, what this question can do is change the feeling of the interview from “How did this person possibly get past the screening?” to a more positive outcome. And there have been cases in which I’ve recommended a person for hire who didn’t do a great job in some of my questions but opened up an entirely new avenue of discussion with this question, where it helped me learn that the person was erudite but in a somewhat different field, and so we could pivot the line of questioning and even expectations for the position based on this.

From the interviewee side, there’s a bit of risk here. The candidate could, of course, ask something like, “What is 2+2?” and then provide the answer. That’s pretty weak. As an interviewer, I’ll take it as an answer, but it’s a red flag. On the other side, there’s risk from trying too hard to impress the interviewer, asking yourself a question whose answer you don’t actually know. If the interviewer does happen to know that answer and you get it wrong, that’s a self-inflicted oopsie.


The final question I like to ask during an interview is, “Tell me something you have learned recently, with one caveat: it can be about anything except SQL Server [or whatever the job entails].”

I ask this for three reasons. First, I like to learn new things, and I have a captive audience candidate in front of me. Second, it’s a direct opportunity for the type of person who talks about “life-long” learning to walk the walk. Learning isn’t just about the job, so if learning is a passion, you’re (hopefully) picking up on things outside of your day-to-day job. Third, this gives even a junior-level interviewee an opportunity to explain a topic, allowing me to listen to this candidate’s ability to frame and explain an idea under some pressure.

Along the way, I’ve had discussions with candidates about the right way to load flatware in dishwashers, the best chicken noodle soup recipe, historical events, and characters in a then-recent anime. Did any of these questions or answers cause me to hire someone I wouldn’t otherwise have hired? No. But I will point out a correlation: 100% of the people I’d already planned to recommend for hire have had an answer to this question. Well under 100% of the people I’d already planned not to recommend for hire had an answer.


As the interviewee, I want direct answers to some of the most important aspects of the job. The job description may say one thing, but what you get from interviewers may be a different story. Here are some of the types of questions I’m liable to ask at almost any job interview:

  1. What expectations do you have around hours per week worked? For me, any number over 40 is a red flag, though your mileage may vary depending on industry and job.
  2. When is the last time people on your team worked overtime? What was the reason for that? I’m trying to determine what the overtime demands are. Sometimes you do need to put in extra hours, but it’d better be temporary and for a good reason.
  3. Is there a budget for continuing education and training? If so, how much is available?
  4. A train is heading eastbound from Lincoln, Nebraska at 68 miles per hour. Simultaneously, a train leaves a station in Chicago, heading west at 61 miles per hour. What is the nearest town (with a population of at least 5,000 people) from the point at which these two trains pass each other? If the interviewers ask me dumb riddles about irrelevant topics they got from a Google search or job hiring book from the ’90s, I get to counter-ask similar questions.

T-SQL Tuesday #173 – Has AI Helped You with Your SQL Server Job?

Invitation from Pinal Dave.

Hello, SQL Server enthusiasts! It’s time for another exciting edition of T-SQL Tuesday, and I’m thrilled to be your host for this month’s episode – Has AI Helped You with Your SQL Server Job?

As database professionals, we’re always looking for ways to improve our efficiency and effectiveness in our daily tasks. With the rapid advancements in artificial intelligence (AI) and machine learning (ML), many of us have started exploring how these technologies can assist us in our SQL Server jobs.

Your task for this month: write a blog post about how AI has helped you in your role as a SQL Server professional, and schedule it for next Tuesday, April 9.

Here are some ideas to get you started:

  • Have you used AI-powered tools to optimize your SQL queries? Share your experience and the results you achieved.
  • Has AI assisted you in detecting and resolving performance issues in your SQL Server environment? Tell us about the tools you used and the insights you gained.
  • Have you leveraged AI to improve your database design or data modeling processes? Discuss the techniques you employed and the benefits you observed.
  • Has AI helped you automate routine tasks, such as index maintenance or backup management? Share your automation journey and the time savings you achieved.

Remember, the goal is to share your personal experience and insights on how AI has impacted your work as an SQL Server professional. Don’t worry if you haven’t had a groundbreaking AI project; even small improvements and efficiency gains are worth celebrating and sharing with the community.

T-SQL Tuesday #171 – Describe the Most Recent Issue You Closed

Invitation and roundup from Brent Ozar.

Your readers wonder what kinds of jobs are out there in the database world, what exactly it is that you do, and what your daily grind is like. While it’d be cool to cover all of that, let’s start with something simple.

Your mission for this week: write a blog post about the last ticket you closed, and schedule it for next Tuesday, February 13.

It doesn’t have to be T-SQL. T-SQL Tuesday has evolved to cover all kinds of data topics.

The task/issue doesn’t have to be indicative of your overall career. Our database jobs cause us to do all kinds of oddball things through the day. Go into your ticket system, help desk system, list of Github issues, or task list right now, look at the last task you checked off, and blog about that.

Don’t include company specifics or anything that might get you in trouble. Just talk in general terms about:

  • Why the task was created (an error popped up, a user had a problem, your boss had an idea, whatever)
  • General terms about work you had, what online resources you found helpful, how long it took
  • How often that kind of task pops up in your queue

T-SQL Tuesday #170 – Learning from Abandoned Projects

Invitation and write up from Reitse Eskens

appy new year to all of you avid bloggers! I hope most of you had a great time during the past weeks, though most of you have seen the sad news of the loss of an excellent member of the Sql Family. Let’s keep Leila in our minds and send strength to Reza.

I was having a nice chat with Steve last year on possible subjects for this fun monthly blog event. And my initial inspiration was “what have you learned from abandoned SQL projects”. Yes, let’s kick off the year on a happy subject, talk about failures.
But wait, you should look on this one in a positive way, like Buck Woody (T) does

We all learn by doing stuff, but we learn most by ‘failing’, working on things that are less than optimal. If you have the time to look back on projects, to review them, you usually see where things went wrong. I think that most of us have been in projects like that and have learned from that.

Let me give you an example. A few years ago we started a project where we had to use an Azure Sql database as the target database. Sources were on-premises and with some magic wizardry, the data landed in the Azure database. But the performance was less than expected. Because deadlines we had to rush through a number of options and ended up with a database we had to reconfigure a number of times after the project finished. When we did the review, this was a bit of a sore point because I felt (and feel) responsible for this part.
During the review, I decided to dig into the different tiers and sku’s of Azure Sql databases and find out their differences in behaviour. This lead to a series of blog posts (that have to be revised as a lot of things changed since writing them). But the key is, I can now give a better advice and reduce the number of reconfigurations.

Now, I could go on, but the main intent of this blog is to trigger your stories; what projects did you abandon but learn a lot from OR what’s your favourite learning from a failure.

As it’s january, I’ll give you some slack on the subject and how much you digress.