T-SQL Tuesday #176: One piece of advice you wish Past You had

Invitation from Louis Davidson.

The challenge

One of the things I tend to do when I am working on a project is to think of myself over three time periods. The past, present and the future. The past version of me made lots of mistakes. Current Me is living through the mistakes Past Me made and does not want to repeat the same mistakes again and Future Me suffer.

As data professionals we know that what we do is crazy hard at times, and if you remember back in August of last year, Josephine Bush’s T-SQL Tuesday entry’s replies answered the question “what do all the database job titles actually mean?” There are more and more tasks and titles for what we do in the data field every year.

Hopefully this month I will get some people who got their start using SQL Server 1.0 on O/S 2, some in Data Science and even some who just started in tech pretty recently, maybe even starting with Microsoft Fabric. All replies are welcome because your mistakes are mostly non-unique.

So, what I want to know is:

What advice do you wish Current You could go back and give past you as you were starting your first data platform job?

Note: even with this fantastical scenario, let’s keep it realistic. No “invest in Microsoft, Apple, and Amazon” replies, but using the years, and perhaps even decades of experience we gather have, let’s hear it.

Your advice might be technical, like compiling isn’t testing, backups don’t always work. But I bet a lot of you have experiences that led to some major issue that younger you didn’t think of and failed in a way that your blog might help them avoid.

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.

I’VE GOT A JOB FOR YOU

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.

I HAVE A QUESTION, BY WHICH I MEAN I’M GOING TO STAND AT THE MICROPHONE FOR FIVE MINUTES AND RAMBLE ON ABOUT MY OWN PERSONAL INTERESTS TO THE EXCLUSION OF WHATEVER WE’RE ACTUALLY GATHERED HERE TO DISCUSS

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.

A SET OF QUESTIONS

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

Interviewer

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.

TELL ME WHAT YOU SEE

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.

ASK YOURSELF A QUESTION

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.

TEACH ME SOMETHING

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.

Interviewee

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 #165: What Do All The Database Job Titles Actually Mean?

Invitation and roundup from Josephine Bush

Earlier this year, when I was looking for a new job, I realized that there are a lot of conceptions about what different database jobs do. I was perplexed about what should be part of what job. These job titles could include other job title tasks, depending on what a company wants. The more I Googled what each of the job titles would include, the more it seemed there was no real standard for what each job title does. For example, if a company doesn’t have dedicated DBAs, that job function is lumped into another job title. You might be doing all of them at many companies because you are the db person, period.

My Conceptions or Misconceptions

Here’s what each job title means to me, whether accurate or not:

  • DBA – This is backups, restores, HA, DR, index maintenance, integrity checks, patching, upgrade, and maybe some performance tuning definitely at the server level, maybe at the query level
  • Database engineer – This is more coding and getting into the meat and bones of db design. This could also include building data pipelines. Also, it would include more query tuning.
  • Database reliability engineer – This is more DevOps-y than DBA, so it’s more about automation and creating CI/CD processes.
  • Database architect – This is designing database systems, such as architecting the infrastructure and making diagrams.
  • Data architect – This is intimately knowing the data inside and out and maybe designing data flows.
  • Data warehouse architect – This is a separate domain because DW OLAP differs greatly from DBA OLTP work. I don’t put this with DBRE or DE because it’s its own domain.
  • Data warehouse engineer – Is this a thing? Or is that lumped into a database engineer job title? But again, as I said with database architect vs. data warehouse architect, data warehouse engineer could be separate from database engineer.
  • Data scientist – This is modeling/predicting with datasets.

Kendra did an amazing post covering some of this last week. It was like she was reading my mind because I was preparing this post as she published hers! I hit her up about her post, and she suggested including data scientists in my post.

If you have other database job titles you want to include, please feel free. I thought up whatever I could based on what I saw or thought should be there. I’m excited to see what you all think!

T-SQL Tuesday #163 Invitation – What is the best piece of Career Advice you ever received

Invitation and round up from Gethyn Ellis

There is no right or wrong answer here.  It might be some technical advice like, “OK, so you got backups. You really need to be able to restore them, though have you tested that”

Or it might be something around the non-technical skills you need in this profession, like “Find a mentor”

We ask this question to our guests on our Putting the Human into Technology podcast, and the answers are always intriguing some of the short answers to the question include

  • Find a mentor
  • Be curious
  • Do what you love
  • Own the customer

These are just some of the answers we have had. There are many more

Feel the fear and do it anyway

This quote is now the title of a book. I googled it when writing this invite. I’ve not read the book, but the book was published in 2017. I got this advice circa September 2003. I think it’s a good title for a book. I might need to get a copy and have a read. Update the book Feel the Fear and do it Anyway by Suzan Jeffers was first published in 1987. So there is every chance that this came from that book. You can find the book here

So, Let me give some background. It was September 2003, and I worked for a local authority in Wales. I had just graduated from university.  My Job title was Community Outreach Worker. Essentially, this was working on an online portal that the authority would use to promote local businesses and community organisations and their activities. It also allowed the council to bring some of their services online.

With this job I was working with technology and people, and that was always something I wanted to do, and in the round, I really enjoyed it. However, part of my role was phoning up people running community groups, asking them if they wanted to become involved in the session. It wasn’t quite cold calling, but it was close. I’ll be honest I didn’t look forward to doing this, I probably did anything else to get out of it, and I think this was obvious to most people on the team.

Let me Introduce Andy Wilson

I sat next to my colleague in the office, We’ve lost touch over the years, but his name was Andy Wilson. Andy doesn’t seem to be on social media or I’d tag him here. He was probably twenty years older than me with lots more experience. He was a great person, funny and good at his job.  He could see I wasn’t having fun. So, he turned to me and said, “Look Geth, I can see you don’t like doing the phone calls. Why?” I explained that I didn’t like phoning people, and it made me feel a little nervous phoning up strangers. Andy turned to me and said, “Well, you have three calls to make. Why don’t you make them now, and they are done for the day, and you get on with the stuff you do enjoy doing… I got some advice from my old boss years ago when I worked in sales and had to make cold calls. He said to  ‘Feel the Fear and do it anyway’ What’s the worst that can happen? They hang up on you? Which they won’t. They’ve signed up for a call back”

Did I make the calls?

So, I made the calls. Once I’d done one, I’d done two and ended up doing several more than the three on my list and feeling quite good about myself.

I’ve used this advice, mindset and how I felt afterwards that morning on many other occasions since. Whether changing jobs or moving into a DBA role for a large police force. Implementing a technical fix for a problem that you have been called out for at 3 am, and there is no one to escalate it to, you have to do something,  and you’re in the land of do it now and ask for forgiveness in the morning and get the business working again or the business is stuck until 9 am when the rest of the business will be awake. I used the advice when making the Jump and started my own consulting business. It definitely helped when I was about to teach my first multi-day training class or deliver my first, second, third, and fiftieth conference sessions. When the nerves (or fear) kick in, I feel the fear and do it anyway! The feeling afterwards when you have done something out of your comfort zone is pretty amazing.

I’d say it’s had quite an impact on my career.

Summary – Over to you

I’d love to hear answers to the question, whether it’s around a technology choice, a career path, a company to work for, or whatever piece of advice you received that had the most significant impact on your career in the data profession, why I’d love to hear about it. You might help someone new to the data profession and give them an extra tool in their armoury to succeed on their path.

T-SQL Tuesday #153 – The Conference That Changed Everything For Me

Invitation and roundup from Kevin Kline.

My invitation is about the social side of life as an data professional, specifically conferences and events. As one of the original nine founders of PASS and an early president of the association from 2004-2010, I always looked forward to the fall and the yearly PASS Summit. The leadership of PASS always worked hard to make the event feel like not only the best SQL Server and Azure SQL training event, but also like a big family reunion. (Check out the #sqlfamily hashtag on social media. It’s a thing!) Many bloggers have already written about #sqlfamily goodness from their attendance at the PASS Summit. Maybe we will see a couple of those blogs reposted?

With the last couple years pandemic lockdown behind us, we might not have many recent examples from the past two years. On the other hand, we have so much to look forward to with anticipation this fall! For many of us in this industry, conferences and events are the highpoint of our yearly business cycles. And with good reason, because we attended an event that had a lifelong positive impact on us. The invitation –

Tell us the story of how attending an IT conference or event resulted in an amazing career or life opportunity.

Of course, job and career opportunities readily jump to front of mind. But I ask you not to limit yourself to stories solely focused on career opportunities or job changes. I’ve seen so many other great outcomes happen for people who attended events like the PASS Summit, SQLBits, and others. I’ve even seen people meet, fall in love, and begin their journey as a couple because they both attended the same event. How wonderful is that?!?

Here are some other ideas. Did you connect with a new group of friends who are now a constant part of your life? Maybe you found a mentor who helped you in a multitude of ways? Perhaps you attended an event that started as the launch point of your own personal advancement as a speaker, blogger, writer, mentor, or community leader? Or maybe you learned an entirely new set of skills that amplified your success at your current job? It could be something even simpler, like finding out about a new musical act, writer, or artist who now is your favorite! Whatever your story might be, I would love to read your blog post about the conference that changed everything for you.

I hope I have inspired you to participate. Your action might then inspire others, starting a virtuous cycle of continued improvement for our community. Now, read the blog party rules below and get started!

T-SQL Tuesday #150 – Your First Technical Job

Invitation from Kenneth Fisher.

This month for TSQL Tuesday I’d like to hear about your first technical job(s). I know most DBAs don’t start out working with databases so tell us how you did start. I’m generally thinking of your first tech job, but if you had a job early in your career that wasn’t technical at all but still makes for a good story feel free to share! I can’t wait to hear about it.

T-SQL Tuesday #148 – Advice on Running a User Group

Invitation from Rie Merritt.

For this edition of T-SQL Tuesday, I’d like to ask everyone to write about all the various aspects of running a user group.  I’m not asking you to write a James Michener novel that starts at the beginning of time and includes everything a user group leader needs to know. Specifically, I’m asking people to pick one or two things and go deep on what works for you, what didn’t work for you and lessons learned.   Running a user group is a large umbrella of tasks and duties: be it in-person, virtual or hybrid.  My goal this month is to break that up into small bite sized pieces of knowledge for people.  There are so many directions you can go here: finding speakers, growing your membership, utilizing technology to make things easier, finding sponsors, finding a venue, picking a pattern to when you meet, etc.  The possibilities are almost endless!  

The Azure Data Community is building a How to run a user group wiki and we’d love to link to your post to offer new and old user group leaders some great resources to build and maintain a successful, healthy community.  

Special thanks to Steve Jones for running T-SQL Tuesday and finding a spot for me, thanks to Kenneth Fisher for being flexible with when he sponsors T-SQL Tuesday and finally to John MorehouseAnnette Allen and Josh Smith for all of the sweat equity they’ve already put into building the wiki.  

T-SQL Tuesday #119 – Changing your mind

Invitation and write-up from Alex Yates.

Bringing people together

I’m excited about DevOps. I first heard the term as a sales person at an IT company. I recognised the gulf between the sales and tech silos at my company and I could observe conflicts with many of my customers between developers and DBAs. I had a lightbulb moment when I realised the potential – if you could just get all these different people and teams to work together effectively with a shared vision.

I’m also increasingly aware that we aren’t just conflicted in our work lives. I live in the UK and my society is increasingly polarised. I know the same is true in lots of other places. Our community tends to communicate through social media, most commonly on Twitter, where we create echo chambres for ourselves as we follow people who share our views and we consciously or unconsciously unfollow or block anyone who disagrees with us. Even if we try to avoid it, the algorithms tend to show us the content we like to read anyway.

It seems to me that at work, online, and in society at large we are becoming more stubborn and less open to exploring ideas that challenge us. It’s my belief that if we were all (myself included) more open, not just to talking, but to genuinely challenging our existing ideas, we would all benefit. I believe that’s true both in our professional and our personal lives.

The challenge

I would like you to write about something in your IT career that you have changed your mind about. What was your original opinion? Why did you believe that? What do you believe now? Why did you change your mind?

You are welcome to discuss technical or non-technical topics. Feel free to go as deeply technical or as personal and human as you like. Brain-melting technical posts about the inner workings of the SQL engine or effective machine learning architectures in Azure are great. SQL 101 posts or perspectives on age old debates such as tabs and spaces or where to put your commas are great too. Human posts about effective teamwork or diversity or wellbeing in tech are also great.

I hope that if we think hard about the ways we have changed our minds in the past, and if we read about how and why other people have changed their mands, it will help us to have better conversations in the future. I hope this will help us to work together more effectively at work – and maybe in other parts of our lives as well.

T-SQL Tuesday #115 – Dear 20 Year Old Self

Invitation and roundup from Mohammad Darab.

Yesterday was my 41st birthday. Twenty years ago, I remember my best friend asking me, “Where do you see yourself when you’re 40?” My reply was something like, “I can’t see myself as a 40 year old.” For some weird reason my mind went blank at 40. It wasn’t like I thought I’d be dead by 40, but I remember thinking of 30 or 35, but not 40. Maybe because 40 was twice my age and just too “far into the future” to think about?! But in a “blink of an eye” here I am twenty-one years later. Funny enough, now I can see myself as an 80 year old. Weird.

Time sure does fly by.

Introspection

This past weekend I presented at SQL Saturday Dallas. Unfortunately, I had lost my voice when I landed Thursday afternoon. I did all I could to get it back by Saturday morning by drinking lots of liquid and getting rest. I got enough of my voice back to do my session (which was first thing in the morning) but had to leave shortly after for some much needed rest. I spent the rest of Saturday in bed and some of Sunday before I had to head to the airport. To top it off, I had 5 flight delays and ended up spending 7 hours at Dallas airport.

During those long hours at the airport, I had some time to introspect. I went over my session. I noticed how over the past couple SQL Saturdays I’ve spoken at, the younger attendees approach me asking questions at the end. The elder attendees mainly say, “thanks!” and the young attendees stick around and ask questions. I absolutely admire and respect that. A lot their questions are very easy to answer. But it’s easy *now* since I have more years of experience.

That brings me to this month’s T-SQL Tuesday idea…

This is my invitation to you this T-SQL Tuesday: Write your 20 year old self a letter. If you could go back in time and give yourself advice, what would it be?

Here are a few potential ideas:

  • Things you would have done differently
  • Any words of encouragement
  • A “Do” and “Don’t Do” list

Obviously we cannot go back in time and live all over again. However, we can write down our advice so that way we have it ready for the next young aspiring technical professional (or any profession for that matter) who comes seeking advice.

As the saying goes, “learn from your mistakes.” I say, it would be even better to “learn from the mistakes of others so you don’t even have to make them.”

Remember to have fun during this process. I can’t wait to share my letter next week!