@Andy... yes, I absolutely understand that. And it's all very well stated. What I'm getting at is that everyone is going to use this once they become aware of it and, according to the interviews I've conducted, very few are deserving of saying they're "above average". It's kind of like all those internet articles base on "If you say this one thing, the employer is going to hire you". Hopefully, people know better than that, as well.
It's damn hard to rate a candidate in the interview process. You don't truly know until they start work and you see them in action. This is why I try not to kneecap my interviews before I actually interview them. Everybody is above average until proven otherwise.
I'll have to totally disagree with that. There are certain basics that people must know to even have a chance of being a decent Database Developer or DBA. It's like asking a tennis player what type of racket they prefer. If they come back with "Ummmm.... what's a racket", then you can be pretty sure they're not a tennis player.
For most of the people I've interviewed, I'm not sure why they're even in the business... it's that bad.
And, no... we're not trying to hire rookies. We're trying to hire senior people that actually know things.
That's entirely subjective to the person conducting the interview on what those basics are. I've never interviewed someone who didn't know what a racket is for a tennis player for example unless their resume was entirely fabricated and or they really didn't play tennis as a tennis player.
I know from your past posts it's more along the lines that they did not play tennis as a tennis player in regards to for example, senior DBA's not knowing how to get the system time. But that's your professional opinion on what those basics should entail to be above average for that position. I used to think it was a huge deal. But now, I've come to realize that I personally do not care about memory capacity of mundane syntax that is insanely easy to lookup on your own. I myself could likely fail to know some basics you may find as a need-to-know for those basics as well. It doesn't negate the fact that I am a data architect who has developed complex data platforms from scratch because I have the ability to solve problems on my own. And therefore, be paid above average.
I'm sure you could tell that I am a type of interviewer who cares less about code tests, coding on whiteboards and all that jive. I'm more interested in what problems you have solved, if you could tackle the problems we need solving, and how you may have solved the problems in the past we are facing as a business. Then the difference between a DBA and a Senior DBA is just how much more exposure to those problems you have had along with your ability to move into a leadership role as your next career steps. I.e.: if the only difference between your seniors and your normal employees is one knows how to get system time and the other does not, then that's not enough to separate between a senior or not.
The trouble is, you can't solve the problems if you don't even have a handle on the basics. It do get that a person that is prone to being able to solve problems can solve just about any problem whether they know something or not. If we were hiring with the aim to train, things could be a bit different. But, then there's the subject of the resume. If you've advertised yourself as a DBA with 10 years of experience and you don't know things like how to get the current date and time using T-SQL or you don't know what a TailLog backup is, then either you've lived a very sheltered life or you're a liar. Either way, you're not Senior DBA material. The same holds true for Developers.
Of course, that's just my opinion but I wouldn't even think of letting the company pay even the low side of the salary range for a DBA that doesn't know the basics.
T-SQL is essentially a means to accomplish something; a tool. Knowing how to use a tool is nothing to do with knowing how to solve a problem. Plenty of people think of how to solve a problem first and then see if they have a tool that can help solve that problem. For example, I need to query a set of data for the past 7 days of the current date. While they may not know how to get the current date using T-SQL, they will likely need to know if their current tools support it, which will land them to the syntax of pulling the current system time in SQL.
However, I'm not trying to shoot you down here. You're better off making the stance that while you were Googling how to do a Point-in-Time recovery, the business lost 20 million dollars versus if you just knew it and recovered right away where the business only lost 5 million. :laugh:
I thought it (things like your last paragraph) was obvious that's one of the most important parts of the stance that I've taken, especially with Senior DBAs. Apparently it wasn't so obvious.
The other part is that we require the front-end developers to do a lot of development in T-SQL, specifically in stored procedures. If you don't know how to get the current date and time, then you don't know enough about T-SQL to satisfy the requirement for employment, especially if you've claimed that you've written stored procedures for the last 5 or 10 years on your resume.
Also and to reiterate, we don't end the interview if they don't know that first question. But, so far, it has been a litmus strip as to just how bad the rest of the interview will be if they can't answer it.