November 4, 2017 at 5:23 pm
Gary Varga - Wednesday, November 27, 2013 2:06 AMI am in shock.With all that has been posted here I am either a SQL Server god (because the majority are rubbish - thanks for the ego boost Jeff) or a SQL Server bottom feeder (because I haven't used some of the techniques - come on Jeff, I'm not that bad).Even I would be able to answer the current time questions (I'd expect people to offer that there was a UTC equivalent too).BTW You get the same sort or nonsense for .NET developers too e.g. actual telephone interview incident:Me: "How do you make a property of a class read only?"Interviewee: "Erm. Erm. It's here somewhere. Erm. I mean it's on the tip of my tongue."[Sound of pages being flipped.]Me: "No problem. Let's move on and you can tell me if it comes to you."...[Other questions and...well, other questions.]...Interviewee: "I've found it!!! Erm. I mean I remember now. [Very stilted] To make a class' property read only..."
In the unlikely event that I was to do a telephone interview and was asked a question to which I don't know the answer I'd probably say "I don't know but I can easily look it up if I need it". I don't know why anyone would pretend to know it, look it up obviously, and then pretend to have remembered it - the chances of that fooling the interviewer are much smaller than the chances of it deciding that the interviewee was dishonest and was therefor unemployable.
Tom
November 4, 2017 at 7:36 pm
TomThomson - Saturday, November 4, 2017 5:23 PMGary Varga - Wednesday, November 27, 2013 2:06 AMI am in shock.With all that has been posted here I am either a SQL Server god (because the majority are rubbish - thanks for the ego boost Jeff) or a SQL Server bottom feeder (because I haven't used some of the techniques - come on Jeff, I'm not that bad).Even I would be able to answer the current time questions (I'd expect people to offer that there was a UTC equivalent too).BTW You get the same sort or nonsense for .NET developers too e.g. actual telephone interview incident:Me: "How do you make a property of a class read only?"Interviewee: "Erm. Erm. It's here somewhere. Erm. I mean it's on the tip of my tongue."[Sound of pages being flipped.]Me: "No problem. Let's move on and you can tell me if it comes to you."...[Other questions and...well, other questions.]...Interviewee: "I've found it!!! Erm. I mean I remember now. [Very stilted] To make a class' property read only..."In the unlikely event that I was to do a telephone interview and was asked a question to which I don't know the answer I'd probably say "I don't know but I can easily look it up if I need it". I don't know why anyone would pretend to know it, look it up obviously, and then pretend to have remembered it - the chances of that fooling the interviewer are much smaller than the chances of it deciding that the interviewee was dishonest and was therefor unemployable.
Lordy... not sure why but that reminded me of that I got into a bit of a short but heated debate with some folks over on LinkedIn. This world is going to hell in a rocket propelled hand basket. Basically, I was told by some people that I'm very unprofessional when I say that people either lie or seriously embellish their resumes especially for the more senior positions. They also told me how cold and heartless I was because I actually expected people to answer technical questions correctly during the interview. One guy even told me "Well, someday you'll be looking for a job and that will change your mind" not knowing that I have been in that position before and, oddly enough, it was the fact that I could answer technical questions to quite some detail that got me the job.
I've also interviewed people by telephone and have the same experience to share as what Gary cited. Many of the folks are obviously (like Gary said, you can tell) beating Yabingooglehoo to death trying to find the answers to the questions I'm asking. The questions I ask aren't difficult. I don't ask trick questions and I don't ask manhole cover questions. I start out with only core questions and usually end up having to cut the interview short because of the nearly total lack of knowledge about core skills be they DBAs or Developers.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 4, 2017 at 8:20 pm
Jeff Moden - Saturday, November 4, 2017 7:36 PMLordy... not sure why but that reminded me of that I got into a bit of a short but heated debate with some folks over on LinkedIn. This world is going to hell in a rocket propelled hand basket. Basically, I was told by some people that I'm very unprofessional when I say that people either lie or seriously embellish their resumes especially for the more senior positions. They also told me how cold and heartless I was because I actually expected people to answer technical questions correctly during the interview. One guy even told me "Well, someday you'll be looking for a job and that will change your mind" not knowing that I have been in that position before and, oddly enough, it was the fact that I could answer technical questions to quite some detail that got me the job.I've also interviewed people by telephone and have the same experience to share as what Gary cited. Many of the folks are obviously (like Gary said, you can tell) beating Yabingooglehoo to death trying to find the answers to the questions I'm asking. The questions I ask aren't difficult. I don't ask trick questions and I don't ask manhole cover questions. I start out with only core questions and usually end up having to cut the interview short because of the nearly total lack of knowledge about core skills be they DBAs or Developers.
Anyone who claims that it's unprofessional to say that people lie or seriously embellish their resumés is an idiot. A lot of people do that, and anyone who has had to try to recruit people for anything but trainee positions (and most certainly anyone who has recruited for senior positions) and hasn't noticed the lies and embellishment is either unbelievably lucky or amazingly stupid.
Saying that it's cold or heartless to expect people to answer technical questions during an interview is utterly stupid. I've always asked technical questions. when I've been interviewed, I've always been asked technical questions.
One thing I differ from you on is that I do sometimes did ask difficult questions (even very difficult questions) when I was interviewing; I was happy with someone who said "I don't know, I'd have to spend some time finding out" to one of those questions, but sometimes followed up with questions about how they would go about finding out. Someone who tried to evade answering a difficult question was not going to get the job. I would be fairly happy with someone who said "I don't know, and I'd have to ask for guidance on where to look for an answer" except when I was looking for someone to manage a team that did a serious amount of genuine research as well as development. Of course my biggest problem tended to be finding candidates that it was worth interviewing, and the second biggest was to find enough time to trawl through enough of the resumés forwarded by the agencies to find even a single candidate worth talking to (but I never had that problem in the early and mid 70s, when I was recruiting more than I ever was since then - computing/IT recruitment wasn't dominated by agencies who (a) wouldn't filter properly and (b) would doctor resumés back in those days).
Tom
November 4, 2017 at 9:15 pm
TomThomson - Saturday, November 4, 2017 8:20 PMJeff Moden - Saturday, November 4, 2017 7:36 PMLordy... not sure why but that reminded me of that I got into a bit of a short but heated debate with some folks over on LinkedIn. This world is going to hell in a rocket propelled hand basket. Basically, I was told by some people that I'm very unprofessional when I say that people either lie or seriously embellish their resumes especially for the more senior positions. They also told me how cold and heartless I was because I actually expected people to answer technical questions correctly during the interview. One guy even told me "Well, someday you'll be looking for a job and that will change your mind" not knowing that I have been in that position before and, oddly enough, it was the fact that I could answer technical questions to quite some detail that got me the job.I've also interviewed people by telephone and have the same experience to share as what Gary cited. Many of the folks are obviously (like Gary said, you can tell) beating Yabingooglehoo to death trying to find the answers to the questions I'm asking. The questions I ask aren't difficult. I don't ask trick questions and I don't ask manhole cover questions. I start out with only core questions and usually end up having to cut the interview short because of the nearly total lack of knowledge about core skills be they DBAs or Developers.
Anyone who claims that it's unprofessional to say that people lie or seriously embellish their resumés is an idiot. A lot of people do that, and anyone who has had to try to recruit people for anything but trainee positions (and most certainly anyone who has recruited for senior positions) and hasn't noticed the lies and embellishment is either unbelievably lucky or amazingly stupid.
Saying that it's cold or heartless to expect people to answer technical questions during an interview is utterly stupid. I've always asked technical questions. when I've been interviewed, I've always been asked technical questions.
One thing I differ from you on is that I do sometimes did ask difficult questions (even very difficult questions) when I was interviewing; I was happy with someone who said "I don't know, I'd have to spend some time finding out" to one of those questions, but sometimes followed up with questions about how they would go about finding out. Someone who tried to evade answering a difficult question was not going to get the job. I would be fairly happy with someone who said "I don't know, and I'd have to ask for guidance on where to look for an answer" except when I was looking for someone to manage a team that did a serious amount of genuine research as well as development. Of course my biggest problem tended to be finding candidates that it was worth interviewing, and the second biggest was to find enough time to trawl through enough of the resumés forwarded by the agencies to find even a single candidate worth talking to (but I never had that problem in the early and mid 70s, when I was recruiting more than I ever was since then - computing/IT recruitment wasn't dominated by agencies who (a) wouldn't filter properly and (b) would doctor resumés back in those days).
Heh... I meant to say that the reason why I only ask the core questions is because most people don't make it to the difficult questions. 😉 It appears that the core questions are difficult for them and they don't handle it well at all.
I've only had the pleasure of interviewing 2 people that actually made it past the basic core questions and they were totally amazing.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2017 at 2:00 am
Jeff Moden - Saturday, November 4, 2017 7:36 PMTomThomson - Saturday, November 4, 2017 5:23 PMGary Varga - Wednesday, November 27, 2013 2:06 AMI am in shock.With all that has been posted here I am either a SQL Server god (because the majority are rubbish - thanks for the ego boost Jeff) or a SQL Server bottom feeder (because I haven't used some of the techniques - come on Jeff, I'm not that bad).Even I would be able to answer the current time questions (I'd expect people to offer that there was a UTC equivalent too).BTW You get the same sort or nonsense for .NET developers too e.g. actual telephone interview incident:Me: "How do you make a property of a class read only?"Interviewee: "Erm. Erm. It's here somewhere. Erm. I mean it's on the tip of my tongue."[Sound of pages being flipped.]Me: "No problem. Let's move on and you can tell me if it comes to you."...[Other questions and...well, other questions.]...Interviewee: "I've found it!!! Erm. I mean I remember now. [Very stilted] To make a class' property read only..."In the unlikely event that I was to do a telephone interview and was asked a question to which I don't know the answer I'd probably say "I don't know but I can easily look it up if I need it". I don't know why anyone would pretend to know it, look it up obviously, and then pretend to have remembered it - the chances of that fooling the interviewer are much smaller than the chances of it deciding that the interviewee was dishonest and was therefor unemployable.
Lordy... not sure why but that reminded me of that I got into a bit of a short but heated debate with some folks over on LinkedIn. This world is going to hell in a rocket propelled hand basket. Basically, I was told by some people that I'm very unprofessional when I say that people either lie or seriously embellish their resumes especially for the more senior positions. They also told me how cold and heartless I was because I actually expected people to answer technical questions correctly during the interview. One guy even told me "Well, someday you'll be looking for a job and that will change your mind" not knowing that I have been in that position before and, oddly enough, it was the fact that I could answer technical questions to quite some detail that got me the job.
I've also interviewed people by telephone and have the same experience to share as what Gary cited. Many of the folks are obviously (like Gary said, you can tell) beating Yabingooglehoo to death trying to find the answers to the questions I'm asking. The questions I ask aren't difficult. I don't ask trick questions and I don't ask manhole cover questions. I start out with only core questions and usually end up having to cut the interview short because of the nearly total lack of knowledge about core skills be they DBAs or Developers.
Really just depends. I mean, I agree and disagree on this so much lately. I'm more dead set on the ability to solve a problem, see how people talk out a problem, than just trying to see if they can remember this and that. This is because at the end of the day, even the juniors who can't answer all the basics can still exceed because those basics are easy to solve. Get the current system time? Sure, let me look it up and solve that problem. The issue I have is the junior or senior or whomever who doesn't know WHEN to use those basics. For example, a junior saying, "I would need to get some sort of indication of the current time to solve this problem, but I don't know the syntax, but I know it exists!"
Thus, I've come to the conclusion that the WHEN is more important than the WHAT. But, the WHAT still matters too.
November 5, 2017 at 6:46 pm
xsevensinzx - Sunday, November 5, 2017 2:00 AMJeff Moden - Saturday, November 4, 2017 7:36 PMTomThomson - Saturday, November 4, 2017 5:23 PMGary Varga - Wednesday, November 27, 2013 2:06 AMI am in shock.With all that has been posted here I am either a SQL Server god (because the majority are rubbish - thanks for the ego boost Jeff) or a SQL Server bottom feeder (because I haven't used some of the techniques - come on Jeff, I'm not that bad).Even I would be able to answer the current time questions (I'd expect people to offer that there was a UTC equivalent too).BTW You get the same sort or nonsense for .NET developers too e.g. actual telephone interview incident:Me: "How do you make a property of a class read only?"Interviewee: "Erm. Erm. It's here somewhere. Erm. I mean it's on the tip of my tongue."[Sound of pages being flipped.]Me: "No problem. Let's move on and you can tell me if it comes to you."...[Other questions and...well, other questions.]...Interviewee: "I've found it!!! Erm. I mean I remember now. [Very stilted] To make a class' property read only..."In the unlikely event that I was to do a telephone interview and was asked a question to which I don't know the answer I'd probably say "I don't know but I can easily look it up if I need it". I don't know why anyone would pretend to know it, look it up obviously, and then pretend to have remembered it - the chances of that fooling the interviewer are much smaller than the chances of it deciding that the interviewee was dishonest and was therefor unemployable.
Lordy... not sure why but that reminded me of that I got into a bit of a short but heated debate with some folks over on LinkedIn. This world is going to hell in a rocket propelled hand basket. Basically, I was told by some people that I'm very unprofessional when I say that people either lie or seriously embellish their resumes especially for the more senior positions. They also told me how cold and heartless I was because I actually expected people to answer technical questions correctly during the interview. One guy even told me "Well, someday you'll be looking for a job and that will change your mind" not knowing that I have been in that position before and, oddly enough, it was the fact that I could answer technical questions to quite some detail that got me the job.
I've also interviewed people by telephone and have the same experience to share as what Gary cited. Many of the folks are obviously (like Gary said, you can tell) beating Yabingooglehoo to death trying to find the answers to the questions I'm asking. The questions I ask aren't difficult. I don't ask trick questions and I don't ask manhole cover questions. I start out with only core questions and usually end up having to cut the interview short because of the nearly total lack of knowledge about core skills be they DBAs or Developers.
Really just depends. I mean, I agree and disagree on this so much lately. I'm more dead set on the ability to solve a problem, see how people talk out a problem, than just trying to see if they can remember this and that. This is because at the end of the day, even the juniors who can't answer all the basics can still exceed because those basics are easy to solve. Get the current system time? Sure, let me look it up and solve that problem. The issue I have is the junior or senior or whomever who doesn't know WHEN to use those basics. For example, a junior saying, "I would need to get some sort of indication of the current time to solve this problem, but I don't know the syntax, but I know it exists!"
Thus, I've come to the conclusion that the WHEN is more important than the WHAT. But, the WHAT still matters too.
I definitely have a soft spot for people, especially juniors, with the right attitude. However, when someone hands me a resume for a senior position that pays in the high 9 figure to low 6 figure pay range and that resume says that they have 10 years of deep experience in all things having to do with SQL Server, there's no way I'm going to hire them if they don't know how to (for example) do a simple 2 table joined update without having to look it up and I'm certainly not going to hire them if they haven't memorized how to get the current date and time. The "core" items that I start interviews off with are definitely "junior" questions but these aren't junior positions that I'm hiring for.
It's actually pretty disgusting as to how low the bar has been set in this industry.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2017 at 2:10 am
Jeff Moden - Saturday, November 4, 2017 9:15 PM:unsure:
I've only had the pleasure of interviewing 2 people that actually made it past the basic core questions and they were totally amazing.
What were those questions again Jeff :unsure:
Oh doesn't matter not looking for a job anyway 😛
Phew!!! :laugh:
Far away is close at hand in the images of elsewhere.
Anon.
November 6, 2017 at 6:00 am
Jeff Moden - Sunday, November 5, 2017 6:46 PMI definitely have a soft spot for people, especially juniors, with the right attitude. However, when someone hands me a resume for a senior position that pays in the high 9 figure to low 6 figure pay range and that resume says that they have 10 years of deep experience in all things having to do with SQL Server, there's no way I'm going to hire them if they don't know how to (for example) do a simple 2 table joined update without having to look it up and I'm certainly not going to hire them if they haven't memorized how to get the current date and time. The "core" items that I start interviews off with are definitely "junior" questions but these aren't junior positions that I'm hiring for.It's actually pretty disgusting as to how low the bar has been set in this industry.
I put too much emphasis on juniors in my response. What I was trying to say that even for a senior, I'm leaning more towards putting much more stock into knowing when to do an UPDATE JOIN in response to a real world problem than trying to recite the exact syntax over the phone. The act of solving a complex problem with the right approach even at a high level (i.e.: able to explain) is much more important to the business in many cases in my experience than knowing the exact syntax over the phone if that makes sense.
The reason I say that is because while I understand, you're trying to measure the candidate and truly understand if their years of experience really add up, at the end of the day, most of this is not rocket science and easy to reference. For example, I have a terrible memory and I'm pretty sure I cannot remember all the core syntax (or core TSQL) that you would ask on your interview. It doesn't change the fact that I planned, built, and managed a large data infrastructure for dozens of fortune 500 companies in the past 5 years that were successful and proven by references.
And I have to say, now that so many new data technologies are spawning and being adapted. I for one am becoming more and more separated from TSQL on a daily basis. Many of us are being spread across many languages and many different ways of solving problems that only lead to more forgetting the mundane concepts of TSQL that you would expect a senior level to recite. But then again, that may be a negative to you if you're purely looking for a specialized SQL Server expert to only stay within that little bubble, which I could understand. 🙂
November 6, 2017 at 8:24 am
If you don't know T-SQL; meaning if you can't write your own T-SQL scripts to automate things, or analyze execution plans and advise developers on proper T-SQL coding and data modeling techniques, then you are limited in terms of being a DBA. In fact, I wouldn't call you a true DBA, you're more like a general system administrator who manages the network and storage with SQL Server being an occasional side hustle. There is nothing wrong with that; keeping SQL Server running in an enterprise environment requires a broad spectrum of roles, I'm just saying that, if you don't know T-SQL, you're not really a "Database Administrator"; that's not what you do.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 6, 2017 at 10:41 am
Eric M Russell - Monday, November 6, 2017 8:24 AMIf you don't know T-SQL; meaning if you can't write your own T-SQL scripts to automate things, or analyze execution plans and advise developers on proper T-SQL coding and data modeling techniques, then you are limited in terms of being a DBA. In fact, I wouldn't call you a true DBA, you're more like a general system administrator who manages the network and storage with SQL Server being an occasional side hustle. There is nothing wrong with that; keeping SQL Server running in an enterprise environment requires a broad spectrum of roles, I'm just saying that, if you don't know T-SQL, you're not really a "Database Administrator"; that's not what you do.
That strikes me as a badly thought out, Eric. Knowing T-SQL at the level where one knows what can be done using what constructs but not the exact syntax of everything doesn't mean that the person with that level of knowledge doesn't know T-SQL and can't be a competent DBA.
My approach is to know what can be done and how to find out how to do it, then use that to script all the routine stuff so that I can forget all that detailed syntax. Oddly enough this approach made colleagues and customers rate me as a top class relational database expert and enabled me to introduce vast amounts of change in such a way that the people who had to use our systems found the changed system much more user-friendly, reliable, and secure than what they had had before, because it allowed me to have a much more comprehensive view of the overall system than spending my learning time rote-learning detailed syntax would have, and that allowed me to find the sources of problems that students of the detailed syntax of just one progrmming language could never understand . I don't see any point in remembering detailed syntax of something that I will probably use for a brief period once every couple of years (with a good chance that microsoft will have changed the feature by next time I use it so that learning the detailed syntax would have been pointless anyway). This approach allows me to have a good understanding of a much broader slice of what's going on than just what the database is doing, which is extremely valuable, far more valuable than remembering exact syntax that is rarely used. For things that I use often, I will learn the syntax.
And of course knowing the detailed syntax doesn't help knowing when to use a feature and when not, or what that feature can do. A nice example is overriding the system limit on parallelism when rebuilding an index. It's far more important to remember that ALTER INDEX provides a means of doing and that the system will ensure that the rebuild doesn't hog the processing power enough to wreck other activity despite any overriding of the hard parallelism limit that has been configured for the optimiser to use as the limt when the norm isn't explicitly overridden than it is to know the exact syntax needed to do it. I know that some competent people who do know the exact syntax for that do think (mistakenly) that they can only overide it downwards, not upwards, while others have the impresion that overriding the limit means that the parallelism limit specified by the over-ride would be actually be used as a fixed level of parallelism rather than the override just telling the optimiser that it was required to observe a different (higher or lower) upper limit for the current operation than the hard-configured limit - and I think that by knowing what the override actually means and being able to find the exact syntax in almost zero time (google for alter index transact-sql, then the locate mentions of MAXDOP on the first result page, and there it is) rather more useful than knowing the exact syntax but having to spend distinctly non-zero time searching for documentation that clearly states what the override actually does.
Tom
November 7, 2017 at 1:26 am
Eric M Russell - Monday, November 6, 2017 8:24 AMIf you don't know T-SQL; meaning if you can't write your own T-SQL scripts to automate things, or analyze execution plans and advise developers on proper T-SQL coding and data modeling techniques, then you are limited in terms of being a DBA. In fact, I wouldn't call you a true DBA, you're more like a general system administrator who manages the network and storage with SQL Server being an occasional side hustle. There is nothing wrong with that; keeping SQL Server running in an enterprise environment requires a broad spectrum of roles, I'm just saying that, if you don't know T-SQL, you're not really a "Database Administrator"; that's not what you do.
Knowing SQL and having its syntax memorized are not at all the same thing. I'd much rather have someone who knows what they're doing, but has to look up details, than someone who has every detail memorized, but doesn't know what to do with it. In fact, having trivia memorized is only a slight speed advantage for a coder, and none at all for a designer or administrator.
November 7, 2017 at 6:31 am
pdanes - Tuesday, November 7, 2017 1:26 AMEric M Russell - Monday, November 6, 2017 8:24 AMIf you don't know T-SQL; meaning if you can't write your own T-SQL scripts to automate things, or analyze execution plans and advise developers on proper T-SQL coding and data modeling techniques, then you are limited in terms of being a DBA. In fact, I wouldn't call you a true DBA, you're more like a general system administrator who manages the network and storage with SQL Server being an occasional side hustle. There is nothing wrong with that; keeping SQL Server running in an enterprise environment requires a broad spectrum of roles, I'm just saying that, if you don't know T-SQL, you're not really a "Database Administrator"; that's not what you do.Knowing SQL and having its syntax memorized are not at all the same thing. I'd much rather have someone who knows what they're doing, but has to look up details, than someone who has every detail memorized, but doesn't know what to do with it. In fact, having trivia memorized is only a slight speed advantage for a coder, and none at all for a designer or administrator.
My thoughts exactly. I mean, T-SQL is not the hardest part of my job. Having a that foresight and holistic vision to come up with a solution is much more difficult.
November 7, 2017 at 7:08 am
TomThomson - Monday, November 6, 2017 10:41 AMEric M Russell - Monday, November 6, 2017 8:24 AMIf you don't know T-SQL; meaning if you can't write your own T-SQL scripts to automate things, or analyze execution plans and advise developers on proper T-SQL coding and data modeling techniques, then you are limited in terms of being a DBA. In fact, I wouldn't call you a true DBA, you're more like a general system administrator who manages the network and storage with SQL Server being an occasional side hustle. There is nothing wrong with that; keeping SQL Server running in an enterprise environment requires a broad spectrum of roles, I'm just saying that, if you don't know T-SQL, you're not really a "Database Administrator"; that's not what you do.That strikes me as a badly thought out, Eric. Knowing T-SQL at the level where one knows what can be done using what constructs but not the exact syntax of everything doesn't mean that the person with that level of knowledge doesn't know T-SQL and can't be a competent DBA.
My approach is to know what can be done and how to find out how to do it, then use that to script all the routine stuff so that I can forget all that detailed syntax. Oddly enough this approach made colleagues and customers rate me as a top class relational database expert and enabled me to introduce vast amounts of change in such a way that the people who had to use our systems found the changed system much more user-friendly, reliable, and secure than what they had had before, because it allowed me to have a much more comprehensive view of the overall system than spending my learning time rote-learning detailed syntax would have, and that allowed me to find the sources of problems that students of the detailed syntax of just one progrmming language could never understand . I don't see any point in remembering detailed syntax of something that I will probably use for a brief period once every couple of years (with a good chance that microsoft will have changed the feature by next time I use it so that learning the detailed syntax would have been pointless anyway). This approach allows me to have a good understanding of a much broader slice of what's going on than just what the database is doing, which is extremely valuable, far more valuable than remembering exact syntax that is rarely used. For things that I use often, I will learn the syntax.
And of course knowing the detailed syntax doesn't help knowing when to use a feature and when not, or what that feature can do. A nice example is overriding the system limit on parallelism when rebuilding an index. It's far more important to remember that ALTER INDEX provides a means of doing and that the system will ensure that the rebuild doesn't hog the processing power enough to wreck other activity despite any overriding of the hard parallelism limit that has been configured for the optimiser to use as the limt when the norm isn't explicitly overridden than it is to know the exact syntax needed to do it. I know that some competent people who do know the exact syntax for that do think (mistakenly) that they can only overide it downwards, not upwards, while others have the impresion that overriding the limit means that the parallelism limit specified by the over-ride would be actually be used as a fixed level of parallelism rather than the override just telling the optimiser that it was required to observe a different (higher or lower) upper limit for the current operation than the hard-configured limit - and I think that by knowing what the override actually means and being able to find the exact syntax in almost zero time (google for alter index transact-sql, then the locate mentions of MAXDOP on the first result page, and there it is) rather more useful than knowing the exact syntax but having to spend distinctly non-zero time searching for documentation that clearly states what the override actually does.
To me and as you say, there is no question in my mind that a good DBA not only knows what could be done but how to dig up enough information and the correct syntax to do it. However, there is some core functionality that should be known to actually be a good DBA of virtually any type possibly excluding only those so-called "Pure Systems DBAs", especially in today's environment of "consolidated employee footprint".
For example and, again, IMHO, if a DBA or Developer has to look up the syntax to do a simple joined UPDATE between two tables, that person hasn't worked with SQL Server enough to be called a DBA or even a Developer. Certainly, you should know at least 2 of the many functions that will get the current date and time and what the differences are and you'd damned sure should be able to properly describe the differences between a FULL, DIF, TRN, and COPY_ONLY backup and how each of those file types comes into play when doing a restore. To your point, I wouldn't expect a DBA to be able to write code off the top of their head to do such a thing but they better know the rest.
Any DBA or other person that claims 10 years of performance tuning of queries, stored procedures, etc, had damned well better be able to describe at least Clustered and Non-Clustered indexes to a great depth. DBAs don't necessarily have to know those to such a level unless they claim performance but they should know what a FILL FACTOR is even if they can't write a CREATE INDEX or ALTER INDEX off the top of their head.
If someone claims skills in stored procedures and other SQL Server code objects, then they better know a whole lot more than simple SELECT, INSERT, UPDATE, and DELETE and I expect them to know a great deal of syntax off the top of their head.
Remember that when hiring and interviewing that the position of DBA and Sr. DBA aren't rookie positions and while I certainly and high value the ability to science things out, you do have to know the core items and a whole lot more even at the code level.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2017 at 8:19 am
Eric M Russell - Monday, November 6, 2017 8:24 AMIf you don't know T-SQL; meaning if you can't write your own T-SQL scripts to automate things, or analyze execution plans and advise developers on proper T-SQL coding and data modeling techniques, then you are limited in terms of being a DBA. In fact, I wouldn't call you a true DBA, you're more like a general system administrator who manages the network and storage with SQL Server being an occasional side hustle. There is nothing wrong with that; keeping SQL Server running in an enterprise environment requires a broad spectrum of roles, I'm just saying that, if you don't know T-SQL, you're not really a "Database Administrator"; that's not what you do.
That strikes me as a badly thought out, Eric. Knowing T-SQL at the level where one knows what can be done using what constructs but not the exact syntax of everything doesn't mean that the person with that level of knowledge doesn't know T-SQL and can't be a competent DBA.
...
So, I'll explain further my point. A [database] is essentially a logical container hosted inside a service. To be a database administrator, one must know the fundamentals of relational database architecture: Data modeling, indexing, SQL, ETL, execution plans, etc. One doesn't need to be an expert in SQL, no need to know the SQL constructs from memory, but one does need to know a badly constructed statement when seen and know how to correct it.
However, if all one knows is the infrastructure and platform that SQL Servers runs on (ie: hardware, operating system, disk storage, network, etc.) and maybe a few maintenance tasks like backups, logins, scheduling, and creating an empty database container for use by the application developers, then they are not really a [database] administrator, they are more like a general [system] administrator who knows how to manage a SQL Server instance in the same way they know how to manage Exchange Server and Active Directory.
You go to a system administrator when you need more disk space or a new server provisioned, and you go to the DBA when you need to know why your query is taking 10x longer to run today than it was yesterday or a request to setup replication.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 10, 2017 at 8:30 pm
Jeff Moden - Tuesday, November 7, 2017 7:08 AMTo me and as you say, there is no question in my mind that a good DBA not only knows what could be done but how to dig up enough information and the correct syntax to do it. However, there is some core functionality that should be known to actually be a good DBA of virtually any type possibly excluding only those so-called "Pure Systems DBAs", especially in today's environment of "consolidated employee footprint".For example and, again, IMHO, if a DBA or Developer has to look up the syntax to do a simple joined UPDATE between two tables, that person hasn't worked with SQL Server enough to be called a DBA or even a Developer. Certainly, you should know at least 2 of the many functions that will get the current date and time and what the differences are and you'd damned sure should be able to properly describe the differences between a FULL, DIF, TRN, and COPY_ONLY backup and how each of those file types comes into play when doing a restore. To your point, I wouldn't expect a DBA to be able to write code off the top of their head to do such a thing but they better know the rest.
Any DBA or other person that claims 10 years of performance tuning of queries, stored procedures, etc, had damned well better be able to describe at least Clustered and Non-Clustered indexes to a great depth. DBAs don't necessarily have to know those to such a level unless they claim performance but they should know what a FILL FACTOR is even if they can't write a CREATE INDEX or ALTER INDEX off the top of their head.
If someone claims skills in stored procedures and other SQL Server code objects, then they better know a whole lot more than simple SELECT, INSERT, UPDATE, and DELETE and I expect them to know a great deal of syntax off the top of their head.
Remember that when hiring and interviewing that the position of DBA and Sr. DBA aren't rookie positions and while I certainly and high value the ability to science things out, you do have to know the core items and a whole lot more even at the code level.
I totally agree , Jeff.
What I was concerned about was a few posts which seemed to be heading for the extremely silly idea that a DBA or Developer writing T-SQL should know the detailed syntax of everything available in T-SQL. That idea is I think about as silly as the idea that DBAs and T-SQL developers don't need to know a lot of syntax.
I think there are a lot of things where both DBA and developer should know the detail (updating through joins is an obvious example, getting the date and time is another, using Isolation Levels properly is another). Both have to know what clustered and non-clustered indexes are and what they are useful for and how they work, and understand how non-clustered indexes differ depending on whether the target is a heap or has a clustered index, but that isn't syntax. Of course they should both know how to create indexes at a basic level (maybe having to look up the syntax for adding non-key material to the index is acceptable - I have created such an index only 3 times in the last 18 years - or maybe someone working on a collection of databases where such material is often needed might need to learn it). And of course they should know about the different types of backups and how to use them, but provided they have built the necessary scripts they probably don't need to remember all the detailed syntax; but of course if they haven't scripted the recovery stuff (or don't run the recovery stuff regularly and check that it actually works) they are nowhere near up to scratch.
But during the 9 years I worked with SQL Server 2000 I never learnt how to write an Extended Stored Procedure with main content in C++. I got the impression that some people writing here might think that disqualified me as a T-SQL developer, hence my earlier post; probably it was a reply to the wrong person (Eric), some earlier posts had got me somewhat disturbed and I think I misinterpreted his as being more of the same.
Tom
Viewing 15 posts - 91 through 105 (of 105 total)
You must be logged in to reply to this topic. Login to reply