Tag: T-SQL Tuesday

This month is a great topic to me. I think growing and improving your career is a skill that most of  us could improve, especially in our younger years. The invitation from Kevin Feasel is a good one from which you can learn a lot.

I am looking forward to the responses from others.

If you want to host an invite one month, ping me and request a date. Most of 2024 is full, but I have a few months, and I certainly am happy to schedule you into 2025. This is a great way to participate in the community, meet others, and challenge yourself. You just need a blog.

In this post I’m going to give two questions, one as an interviewer and one as interviewee.

My Favorite Interview Question for Candidates

When I interview someone, I usually have a list of things to ask them to better help me compare candidates, but these are associated with digging into knowledge, however this question really helps me.

What have you learned recently?

I don’t expect candidates to know everything. I expect to have to teach them quite a bit about my environment. However, what I want from them is an effort to learn. My view is that some people are constantly learning things and others are content to rest on their previous knowledge/experience.

If someone hasn’t learned anything recently, I don’t necessarily write them off, but I might probe about what they have been doing, as well as how they prepared for a new job or the interview. Perhaps they’ve been busy with something (crisis, illness, etc.) and haven’t been improving in the short term, but if someone hasn’t learned anything in the last year they’re proud of, or they can’t remember when they last invested in themselves, I have a hard time investing in them as an employee.

Note, I will dig into ensure you learned something and aren’t just giving me an answer.

My Favorite Question as an Interviewee

In a lot of my jobs as a technologist, or a data professional, the job is the job. It’s very similar in many places. These days I do more architecture and advocacy, but if I were approaching a new job, I’d ask this:

What are the expectations around working hours?

I’d add context to this, but what I’m looking for are information for these items:

• core working hours
• on-call/non-core hours
• punctuality

I don’t mind working hard, but I don’t expect to work a lot of non-core hours every week, or even too regularly. I don’t mind 40 or even 50, but beyond that I’m not going to be happy.

I’m also not someone that punches a clock. If you expect me to be online (or in an office) every day at 8am, you’re going to be disappointed. I might be there at 7:45 or 8:15. I don’t avoid work, and I do my best to be early for meetings, but if nothing is scheduled, I will vary my start time. I usually warn a potential boss about this.

I used to ask about travel, but I’m over that. I don’t mind or worry about travel too much.

It’s that time of the month for a new blog party at T-SQL Tuesday. This month we have Brent Ozar hosing, and it’s a good topic. I wondered what he might ask when he agreed to host and he has surprised me.

If you haven’t participated in this, start a blog, start building your brand, and write a post that answers Brent’s invitation. If you enjoy this and want to host, ping me for a date.

Closing Tickets

I don’t get tickets per se. I get copied on a few of them from customers, but often the things that I fix are things I’ve broken at SQL Saturday or T-SQL Tuesday or one of the sites I run.

However, I do consult with customers and our Solutions Engineers at Redgate on architectures and challenges that customers are facing. Sometimes I even come up with a solution. This was the most recent one, which I found interesting.

I walked into a conversation at a Redgate office one day. A few engineers were talking about a requirement that a customer had to stop a deployment if a particular configuration file had changed. They allow changes, but by few people, however, the configuration file is in the repository with other code and controls some of the deployment parameters.

Our engineers were looking at git hooks or  moving the file to another repo, or rearchitecting the pipeline to change the configuration. There were other solutions, but all of them were adding complexity to the situation.

Having grown up in the era of limited RAM and unreliable networks, I immediately thought about detecting changes with a file checksum. It’s a computer science technique used in lots of places, including many database drivers. I thought the simple thing is to store the checksum in a variable in the pipeline, and then add a step that runs something like Get-FileHash and compares that to the variable. Then fail the pipeline if it’s wrong.

If the file needs to change, the privileged users can change the file, run this, and update the variable with the results.

A simple way to detect changes and limit them inside the repo, from outside it.

I have to say I haven’t seen this particular issue before, but I have seen lots of people worry about how to ensure deployments don’t happen in prod if they haven’t happened in test. That’s another whole issue, and a complex solution that I saw a customer implement. It worked great, but that’s for another day.