November 5, 2015 at 10:54 am
Sean Lange (11/5/2015)
xsevensinzx (11/4/2015)
Jeff Moden (11/4/2015)
Brandie Tarvin (11/4/2015)
Jeff Moden (11/3/2015)
Man o man... yet another self-proclaimed DBA bites the dust in the interview process as has another self-proclaimed "expert" Database Developer. It amazing how they don't know what they don't know. I'm not asking difficult questions so far because none have gotten that far, yet.I am curious. How many people have you interviewed who (though unqualified for this specific posting) know more than they realize they know?
Actually and as impossible as it seems, there have been two and they're both wicked sharp. One was one of those self-trained Ninja's that never thought of herself as a "DBA" and yet she knew more about SQL Server and T-SQL than the last 8 candidates combined. It was a real pleasure to interview her. I also had the pleasure of interviewing Geoff Albin.
I'm also curious! What is it about the candidates that is really turning you off? I mean, are you generally looking for people with high capacity of knowledge on the phone or in person? No one trainable or anything like that? I heard you talk about this before when mentioning candidates failing to answer questions about date functions or something along those lines.
I ask because I generally fail at a lot of capacity questions like that too when on the spot. There is a wealth of information out there on every piece of technology. In most interviews, a lot of the common stuff gets asked and sometimes forgotten by the candidate because they are generally so simple and easy to reference it slips beneath the cracks like knowing every formatting code to a function or something like that versus how to restore to a point in time.
One being critical to the job to know where the other is not critical. 😀
I can't speak for Jeff but I can recall some of the things he has mentioned in the past that a shocking number of people can't answer. The date part was something like "Name at least one way to get the current date". Nothing tricky or memory required. If you can't come up with at LEAST one instantly you obviously don't have any real world experience. He has made it clear at least in comments that his questions are not the kind of thing the require memorization, instead the require basic knowledge of t-sql.
Jeff and I have had numerous conversations about this and you're right, Sean. The basic question is "What is the SQL required to get the current date and time?" Nothing more and nothing less than that. I'd be looking for the trick because it's too simple. 😉
The lack of knowledge is pretty impressive. We all have things were we don't have the syntax down, so we refer to BOL or previous code we're written (like me and PIVOT), but not everything. I know people who say they have "10 years of experience" when what they really have is 6 months of experience repeated 20 times. There are those who are going to lie on resumes. It's just a fact of life. But some of the absurd stuff I hear about makes me wonder what's become of the DBA profession.
We all have
November 5, 2015 at 11:31 am
Brandie Tarvin (11/5/2015)
Grant Fritchey (11/5/2015)
GilaMonster (11/5/2015)
Grant Fritchey (11/5/2015)
I'd strongly suggest looking at Excel and, maybe even more importantly, PowerBI. the technology is wildly different from what we think.PowerBI is very pretty, and it's pretty easy to use. Hell, I can produce useful graphs in it and I can't even spell BI.
This!
The fact that I can create a useful set of graphical presentation of information pretty much sums up the power of the tool. Now, the real issue is the quality of your data. The tool can't help that at all.
Okay. Now I have a new toy to look at.
Yes, same here. I'm intrigued and will have to give it a closer look.
November 5, 2015 at 11:43 am
Ed Wagner (11/5/2015)
Sean Lange (11/5/2015)
xsevensinzx (11/4/2015)
Jeff Moden (11/4/2015)
Brandie Tarvin (11/4/2015)
Jeff Moden (11/3/2015)
Man o man... yet another self-proclaimed DBA bites the dust in the interview process as has another self-proclaimed "expert" Database Developer. It amazing how they don't know what they don't know. I'm not asking difficult questions so far because none have gotten that far, yet.I am curious. How many people have you interviewed who (though unqualified for this specific posting) know more than they realize they know?
Actually and as impossible as it seems, there have been two and they're both wicked sharp. One was one of those self-trained Ninja's that never thought of herself as a "DBA" and yet she knew more about SQL Server and T-SQL than the last 8 candidates combined. It was a real pleasure to interview her. I also had the pleasure of interviewing Geoff Albin.
I'm also curious! What is it about the candidates that is really turning you off? I mean, are you generally looking for people with high capacity of knowledge on the phone or in person? No one trainable or anything like that? I heard you talk about this before when mentioning candidates failing to answer questions about date functions or something along those lines.
I ask because I generally fail at a lot of capacity questions like that too when on the spot. There is a wealth of information out there on every piece of technology. In most interviews, a lot of the common stuff gets asked and sometimes forgotten by the candidate because they are generally so simple and easy to reference it slips beneath the cracks like knowing every formatting code to a function or something like that versus how to restore to a point in time.
One being critical to the job to know where the other is not critical. 😀
I can't speak for Jeff but I can recall some of the things he has mentioned in the past that a shocking number of people can't answer. The date part was something like "Name at least one way to get the current date". Nothing tricky or memory required. If you can't come up with at LEAST one instantly you obviously don't have any real world experience. He has made it clear at least in comments that his questions are not the kind of thing the require memorization, instead the require basic knowledge of t-sql.
Jeff and I have had numerous conversations about this and you're right, Sean. The basic question is "What is the SQL required to get the current date and time?" Nothing more and nothing less than that. I'd be looking for the trick because it's too simple. 😉
The lack of knowledge is pretty impressive. We all have things were we don't have the syntax down, so we refer to BOL or previous code we're written (like me and PIVOT), but not everything. I know people who say they have "10 years of experience" when what they really have is 6 months of experience repeated 20 times. There are those who are going to lie on resumes. It's just a fact of life. But some of the absurd stuff I hear about makes me wonder what's become of the DBA profession.
We all have
Some day I will meet Jeff in person and perhaps on that day I'll have him do a mini interview just so I can get an idea of the type of questions he asks for the positions he helps fill. I want to do this just to see how I might fair in an actual interview with him.
November 5, 2015 at 12:07 pm
Lynn Pettis (11/5/2015)
Some day I will meet Jeff in person and perhaps on that day I'll have him do a mini interview just so I can get an idea of the type of questions he asks for the positions he helps fill. I want to do this just to see how I might fair in an actual interview with him.
We should totally do Google Hangouts and interview each other just for fun (and practice).
November 5, 2015 at 12:52 pm
Ed Wagner (11/5/2015)
Sean Lange (11/5/2015)
xsevensinzx (11/4/2015)
Jeff Moden (11/4/2015)
Brandie Tarvin (11/4/2015)
Jeff Moden (11/3/2015)
Man o man... yet another self-proclaimed DBA bites the dust in the interview process as has another self-proclaimed "expert" Database Developer. It amazing how they don't know what they don't know. I'm not asking difficult questions so far because none have gotten that far, yet.I am curious. How many people have you interviewed who (though unqualified for this specific posting) know more than they realize they know?
Actually and as impossible as it seems, there have been two and they're both wicked sharp. One was one of those self-trained Ninja's that never thought of herself as a "DBA" and yet she knew more about SQL Server and T-SQL than the last 8 candidates combined. It was a real pleasure to interview her. I also had the pleasure of interviewing Geoff Albin.
I'm also curious! What is it about the candidates that is really turning you off? I mean, are you generally looking for people with high capacity of knowledge on the phone or in person? No one trainable or anything like that? I heard you talk about this before when mentioning candidates failing to answer questions about date functions or something along those lines.
I ask because I generally fail at a lot of capacity questions like that too when on the spot. There is a wealth of information out there on every piece of technology. In most interviews, a lot of the common stuff gets asked and sometimes forgotten by the candidate because they are generally so simple and easy to reference it slips beneath the cracks like knowing every formatting code to a function or something like that versus how to restore to a point in time.
One being critical to the job to know where the other is not critical. 😀
I can't speak for Jeff but I can recall some of the things he has mentioned in the past that a shocking number of people can't answer. The date part was something like "Name at least one way to get the current date". Nothing tricky or memory required. If you can't come up with at LEAST one instantly you obviously don't have any real world experience. He has made it clear at least in comments that his questions are not the kind of thing the require memorization, instead the require basic knowledge of t-sql.
Jeff and I have had numerous conversations about this and you're right, Sean. The basic question is "What is the SQL required to get the current date and time?" Nothing more and nothing less than that. I'd be looking for the trick because it's too simple. 😉
The lack of knowledge is pretty impressive. We all have things were we don't have the syntax down, so we refer to BOL or previous code we're written (like me and PIVOT), but not everything. I know people who say they have "10 years of experience" when what they really have is 6 months of experience repeated 20 times. There are those who are going to lie on resumes. It's just a fact of life. But some of the absurd stuff I hear about makes me wonder what's become of the DBA profession.
We all have
I guess I have a diverse opinion on it. I mean, there are a number of ways to get the current time in multiple database engines. Syntax that is insanely simple to reference and discover that is NOT AS critical to your job. I don't think I know them all as much as I may know for SQL Server. But ideally, I think having a great idea of how to solve a problem is good such as knowing you need to get the current system time versus not knowing how to solve a problem and not knowing YOU NEED to get the current system time.
I would be more likely to disqualify someone for failing to explain a good solution to a problem that may need the current system time without needing them to explain the exact syntax. That's because simply knowing the exact syntax is not the same as how and why it's applied in a real world problem they may face on the job in most cases.
That's just me though. :hehe:
November 5, 2015 at 2:06 pm
Lynn Pettis (11/5/2015)
Ed Wagner (11/5/2015)
Sean Lange (11/5/2015)
xsevensinzx (11/4/2015)
Jeff Moden (11/4/2015)
Brandie Tarvin (11/4/2015)
Jeff Moden (11/3/2015)
Man o man... yet another self-proclaimed DBA bites the dust in the interview process as has another self-proclaimed "expert" Database Developer. It amazing how they don't know what they don't know. I'm not asking difficult questions so far because none have gotten that far, yet.I am curious. How many people have you interviewed who (though unqualified for this specific posting) know more than they realize they know?
Actually and as impossible as it seems, there have been two and they're both wicked sharp. One was one of those self-trained Ninja's that never thought of herself as a "DBA" and yet she knew more about SQL Server and T-SQL than the last 8 candidates combined. It was a real pleasure to interview her. I also had the pleasure of interviewing Geoff Albin.
I'm also curious! What is it about the candidates that is really turning you off? I mean, are you generally looking for people with high capacity of knowledge on the phone or in person? No one trainable or anything like that? I heard you talk about this before when mentioning candidates failing to answer questions about date functions or something along those lines.
I ask because I generally fail at a lot of capacity questions like that too when on the spot. There is a wealth of information out there on every piece of technology. In most interviews, a lot of the common stuff gets asked and sometimes forgotten by the candidate because they are generally so simple and easy to reference it slips beneath the cracks like knowing every formatting code to a function or something like that versus how to restore to a point in time.
One being critical to the job to know where the other is not critical. 😀
I can't speak for Jeff but I can recall some of the things he has mentioned in the past that a shocking number of people can't answer. The date part was something like "Name at least one way to get the current date". Nothing tricky or memory required. If you can't come up with at LEAST one instantly you obviously don't have any real world experience. He has made it clear at least in comments that his questions are not the kind of thing the require memorization, instead the require basic knowledge of t-sql.
Jeff and I have had numerous conversations about this and you're right, Sean. The basic question is "What is the SQL required to get the current date and time?" Nothing more and nothing less than that. I'd be looking for the trick because it's too simple. 😉
The lack of knowledge is pretty impressive. We all have things were we don't have the syntax down, so we refer to BOL or previous code we're written (like me and PIVOT), but not everything. I know people who say they have "10 years of experience" when what they really have is 6 months of experience repeated 20 times. There are those who are going to lie on resumes. It's just a fact of life. But some of the absurd stuff I hear about makes me wonder what's become of the DBA profession.
We all have
Some day I will meet Jeff in person and perhaps on that day I'll have him do a mini interview just so I can get an idea of the type of questions he asks for the positions he helps fill. I want to do this just to see how I might fair in an actual interview with him.
Let us know if you ever find yourself around Michigan. Same goes for you as for Steve - I'll buy lunch.
November 5, 2015 at 2:10 pm
xsevensinzx (11/5/2015)
Ed Wagner (11/5/2015)
Sean Lange (11/5/2015)
xsevensinzx (11/4/2015)
Jeff Moden (11/4/2015)
Brandie Tarvin (11/4/2015)
Jeff Moden (11/3/2015)
Man o man... yet another self-proclaimed DBA bites the dust in the interview process as has another self-proclaimed "expert" Database Developer. It amazing how they don't know what they don't know. I'm not asking difficult questions so far because none have gotten that far, yet.I am curious. How many people have you interviewed who (though unqualified for this specific posting) know more than they realize they know?
Actually and as impossible as it seems, there have been two and they're both wicked sharp. One was one of those self-trained Ninja's that never thought of herself as a "DBA" and yet she knew more about SQL Server and T-SQL than the last 8 candidates combined. It was a real pleasure to interview her. I also had the pleasure of interviewing Geoff Albin.
I'm also curious! What is it about the candidates that is really turning you off? I mean, are you generally looking for people with high capacity of knowledge on the phone or in person? No one trainable or anything like that? I heard you talk about this before when mentioning candidates failing to answer questions about date functions or something along those lines.
I ask because I generally fail at a lot of capacity questions like that too when on the spot. There is a wealth of information out there on every piece of technology. In most interviews, a lot of the common stuff gets asked and sometimes forgotten by the candidate because they are generally so simple and easy to reference it slips beneath the cracks like knowing every formatting code to a function or something like that versus how to restore to a point in time.
One being critical to the job to know where the other is not critical. 😀
I can't speak for Jeff but I can recall some of the things he has mentioned in the past that a shocking number of people can't answer. The date part was something like "Name at least one way to get the current date". Nothing tricky or memory required. If you can't come up with at LEAST one instantly you obviously don't have any real world experience. He has made it clear at least in comments that his questions are not the kind of thing the require memorization, instead the require basic knowledge of t-sql.
Jeff and I have had numerous conversations about this and you're right, Sean. The basic question is "What is the SQL required to get the current date and time?" Nothing more and nothing less than that. I'd be looking for the trick because it's too simple. 😉
The lack of knowledge is pretty impressive. We all have things were we don't have the syntax down, so we refer to BOL or previous code we're written (like me and PIVOT), but not everything. I know people who say they have "10 years of experience" when what they really have is 6 months of experience repeated 20 times. There are those who are going to lie on resumes. It's just a fact of life. But some of the absurd stuff I hear about makes me wonder what's become of the DBA profession.
We all have
I guess I have a diverse opinion on it. I mean, there are a number of ways to get the current time in multiple database engines. Syntax that is insanely simple to reference and discover that is NOT AS critical to your job. I don't think I know them all as much as I may know for SQL Server. But ideally, I think having a great idea of how to solve a problem is good such as knowing you need to get the current system time versus not knowing how to solve a problem and not knowing YOU NEED to get the current system time.
I would be more likely to disqualify someone for failing to explain a good solution to a problem that may need the current system time without needing them to explain the exact syntax. That's because simply knowing the exact syntax is not the same as how and why it's applied in a real world problem they may face on the job in most cases.
That's just me though. :hehe:
It isn't a syntax check. Keep in mind this is a senior type of position. Anybody who is at that level and can't rattle off at least one way of getting the current system time is clearly NOT a senior level person. This isn't about knowing all the possible ways in every DBMS. This is about knowing any of several ways in the system they claim to be a senior level in. If you can't come up with at least one of these you have not written enough t-sql to be considered senior. Knowing how to get the current system date is fundamental in sql period. Anything less is like saying it is ok for a senior level sql person to fumble with the syntax for a basic select statement. Or that a senior level C# developer doesn't remember they have to terminate the line with a semicolon.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
November 5, 2015 at 7:23 pm
Sean Lange (11/5/2015)
xsevensinzx (11/5/2015)
Ed Wagner (11/5/2015)
Sean Lange (11/5/2015)
xsevensinzx (11/4/2015)
Jeff Moden (11/4/2015)
Brandie Tarvin (11/4/2015)
Jeff Moden (11/3/2015)
Man o man... yet another self-proclaimed DBA bites the dust in the interview process as has another self-proclaimed "expert" Database Developer. It amazing how they don't know what they don't know. I'm not asking difficult questions so far because none have gotten that far, yet.I am curious. How many people have you interviewed who (though unqualified for this specific posting) know more than they realize they know?
Actually and as impossible as it seems, there have been two and they're both wicked sharp. One was one of those self-trained Ninja's that never thought of herself as a "DBA" and yet she knew more about SQL Server and T-SQL than the last 8 candidates combined. It was a real pleasure to interview her. I also had the pleasure of interviewing Geoff Albin.
I'm also curious! What is it about the candidates that is really turning you off? I mean, are you generally looking for people with high capacity of knowledge on the phone or in person? No one trainable or anything like that? I heard you talk about this before when mentioning candidates failing to answer questions about date functions or something along those lines.
I ask because I generally fail at a lot of capacity questions like that too when on the spot. There is a wealth of information out there on every piece of technology. In most interviews, a lot of the common stuff gets asked and sometimes forgotten by the candidate because they are generally so simple and easy to reference it slips beneath the cracks like knowing every formatting code to a function or something like that versus how to restore to a point in time.
One being critical to the job to know where the other is not critical. 😀
I can't speak for Jeff but I can recall some of the things he has mentioned in the past that a shocking number of people can't answer. The date part was something like "Name at least one way to get the current date". Nothing tricky or memory required. If you can't come up with at LEAST one instantly you obviously don't have any real world experience. He has made it clear at least in comments that his questions are not the kind of thing the require memorization, instead the require basic knowledge of t-sql.
Jeff and I have had numerous conversations about this and you're right, Sean. The basic question is "What is the SQL required to get the current date and time?" Nothing more and nothing less than that. I'd be looking for the trick because it's too simple. 😉
The lack of knowledge is pretty impressive. We all have things were we don't have the syntax down, so we refer to BOL or previous code we're written (like me and PIVOT), but not everything. I know people who say they have "10 years of experience" when what they really have is 6 months of experience repeated 20 times. There are those who are going to lie on resumes. It's just a fact of life. But some of the absurd stuff I hear about makes me wonder what's become of the DBA profession.
We all have
I guess I have a diverse opinion on it. I mean, there are a number of ways to get the current time in multiple database engines. Syntax that is insanely simple to reference and discover that is NOT AS critical to your job. I don't think I know them all as much as I may know for SQL Server. But ideally, I think having a great idea of how to solve a problem is good such as knowing you need to get the current system time versus not knowing how to solve a problem and not knowing YOU NEED to get the current system time.
I would be more likely to disqualify someone for failing to explain a good solution to a problem that may need the current system time without needing them to explain the exact syntax. That's because simply knowing the exact syntax is not the same as how and why it's applied in a real world problem they may face on the job in most cases.
That's just me though. :hehe:
It isn't a syntax check. Keep in mind this is a senior type of position. Anybody who is at that level and can't rattle off at least one way of getting the current system time is clearly NOT a senior level person. This isn't about knowing all the possible ways in every DBMS. This is about knowing any of several ways in the system they claim to be a senior level in. If you can't come up with at least one of these you have not written enough t-sql to be considered senior. Knowing how to get the current system date is fundamental in sql period. Anything less is like saying it is ok for a senior level sql person to fumble with the syntax for a basic select statement. Or that a senior level C# developer doesn't remember they have to terminate the line with a semicolon.
Precisely. I couldn't have said it better myself. It's a bit like interviewing a mechanic. If they can't describe the difference between and open end and box wrench, they're not a mechanic. The simile here is that I'm taking mechanics out into the parking lot and asking them to point to a car and then to a pickup truck and they can't do it. It's that bad.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2015 at 10:05 pm
Grant Fritchey (11/5/2015)
BWFC (11/5/2015)
I mentioned the Excel BI tools and apparently they don't want use 'spreadsheets'. I'm pretty sure though that's down to a lack of understanding of the capabilities.
I've no idea about staging and IT involvement. As I said, a user could be anybody from the cleaner up. We're not even sure whether user means the client as an organisation, that would put a whole different slant on it of course.
I'd strongly suggest looking at Excel and, maybe even more importantly, PowerBI. the technology is wildly different from what we think.
+1
😎
PowerBI is much like a SaaS version of PoverPivot, takes the 'spreadsheets' out of the equation and properly designed PowerPivot models go way beyond the capacity and capabilities of Excel, almost like Excel on steroids.
November 6, 2015 at 12:59 am
Jeff Moden (11/5/2015)
Precisely. I couldn't have said it better myself. It's a bit like interviewing a mechanic. If they can't describe the difference between and open end and box wrench, they're not a mechanic. The simile here is that I'm taking mechanics out into the parking lot and asking them to point to a car and then to a pickup truck and they can't do it. It's that bad.
I hear ya. I just don't make the connection as easy I guess. I'm not a 10-year veteran of SQL mind you. I just have written thousands and thousands of lines of code in TSQL myself and have not used the alternatives you speak of yet as much as maybe you have. It's not ideally set in my mind and I don't think that's the same as not identifying a car from a truck as a mechanic. And I could go on the next 3 to 5 years not following the same as you may want and you toss out all my years of writing thousands of thousands of code for failing to give the alternatives to system time? That's a bit silly IMHO.
I think a better comparison would be not knowing the differences between DDL and DML when referencing the differences between a car and a truck. Surely the simple basics of a SELECT statement is also going to be a better comparison than alternatives to simple functions that is just not as widely used as say ALTER versus SELECT.
November 6, 2015 at 2:53 am
Grant Fritchey (11/5/2015)
BWFC (11/5/2015)
Greg Edwards-268690 (11/5/2015)
xsevensinzx (11/5/2015)
Brandie Tarvin (11/5/2015)
BWFC (11/5/2015)
Woolly nebulous request of the month alert.I've been asked to look into ad-hoc reporting solutions so users can create their own reports.
All I know is it's a SQL Server back end.
I don't know:
- The level of the users skills; is it a BI person or anybody from the cleaner upwards.
- What level of reporting i.e. whether it's operational 'did this happen', whether it's month by month figures or both.
- How ad-hoc it will be; is there going to be data there to be queried or is the user (see above) going to have to bring it in themselves.
The client is also in Australia and isn't to know that I'm looking into this.
Any suggestions?
At risk of being lynched: Crystal Reports is probably the easiest ad-hoc reporting tool a user with no experience can learn to use.
I have not used Crystal Reports. But, I work in the data science and BI side of things for my company.
We primarily use MicroStrategy or Tableau. Most analyst love to use Tableau for it's easy and visual appeal. It's super easy to use, hooks up to any data source and is the current top visualization tool out there outside of just Excel.
MicroStrategy was used for their MOLAP technology. You can build in-memory cubes that allow you to fully model a data set for the end user to build reports on top of. Unfortunately, this approach has been popular for technical people like myself, but not as popular for non-technical people who just want to hit the ground running like they can in Tableau. The server tech for Tableau has been improved with better caching options to really surpass MicroStrategy performance with larger datasets.
PowerBI from Microsoft if you were looking for a good transition from Excel to a new similar visualization option from Microsoft. Some users I've talked to liked it. Others who work with bigger data dislike it and opt for Tableau with Tableau Server for the caching.
Part of it is the amount of data in SQL, along with the structure.
How much IT involvement to do any staging is also important.
You want to make it easy to get the same answer.
Excel / Power BI is very flexible, and some users will likely be fairly familiar with this.
If SSAS is available, pivot tables in Excel can be very flexible.
Even in an ad hoc environment, some power users should work with IT.
And some standard report templates likely should be created.
I mentioned the Excel BI tools and apparently they don't want use 'spreadsheets'. I'm pretty sure though that's down to a lack of understanding of the capabilities.
I've no idea about staging and IT involvement. As I said, a user could be anybody from the cleaner up. We're not even sure whether user means the client as an organisation, that would put a whole different slant on it of course.
I'd strongly suggest looking at Excel and, maybe even more importantly, PowerBI. the technology is wildly different from what we think.
I think we have a winner. The key bit is that you don't necessarily need to be able to write a query to get data in from the database. On the users-from-cleaner-upwards basis that alone might swing it. I'll keep playing but from what I've seen already I might try and get it into use for our contract as well as Australia.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
November 6, 2015 at 4:25 am
xsevensinzx (11/6/2015)
Jeff Moden (11/5/2015)
Precisely. I couldn't have said it better myself. It's a bit like interviewing a mechanic. If they can't describe the difference between and open end and box wrench, they're not a mechanic. The simile here is that I'm taking mechanics out into the parking lot and asking them to point to a car and then to a pickup truck and they can't do it. It's that bad.
I hear ya. I just don't make the connection as easy I guess. I'm not a 10-year veteran of SQL mind you. I just have written thousands and thousands of lines of code in TSQL myself and have not used the alternatives you speak of yet as much as maybe you have. It's not ideally set in my mind and I don't think that's the same as not identifying a car from a truck as a mechanic. And I could go on the next 3 to 5 years not following the same as you may want and you toss out all my years of writing thousands of thousands of code for failing to give the alternatives to system time? That's a bit silly IMHO.
I think a better comparison would be not knowing the differences between DDL and DML when referencing the differences between a car and a truck. Surely the simple basics of a SELECT statement is also going to be a better comparison than alternatives to simple functions that is just not as widely used as say ALTER versus SELECT.
But how hard is it to come up with one function? The most basic function that everyone uses?
I save a lot of queries off so that I don't have to remember how to do things (like finding the text of a job step or searching procs and functions for a specific string). But a "SELECT TheOfficialMSFunction()" is one of the first things I learned.
And if I don't remember that one, shame on me.
November 6, 2015 at 4:56 am
Brandie Tarvin (11/6/2015)
xsevensinzx (11/6/2015)
Jeff Moden (11/5/2015)
Precisely. I couldn't have said it better myself. It's a bit like interviewing a mechanic. If they can't describe the difference between and open end and box wrench, they're not a mechanic. The simile here is that I'm taking mechanics out into the parking lot and asking them to point to a car and then to a pickup truck and they can't do it. It's that bad.
I hear ya. I just don't make the connection as easy I guess. I'm not a 10-year veteran of SQL mind you. I just have written thousands and thousands of lines of code in TSQL myself and have not used the alternatives you speak of yet as much as maybe you have. It's not ideally set in my mind and I don't think that's the same as not identifying a car from a truck as a mechanic. And I could go on the next 3 to 5 years not following the same as you may want and you toss out all my years of writing thousands of thousands of code for failing to give the alternatives to system time? That's a bit silly IMHO.
I think a better comparison would be not knowing the differences between DDL and DML when referencing the differences between a car and a truck. Surely the simple basics of a SELECT statement is also going to be a better comparison than alternatives to simple functions that is just not as widely used as say ALTER versus SELECT.
But how hard is it to come up with one function? The most basic function that everyone uses?
I save a lot of queries off so that I don't have to remember how to do things (like finding the text of a job step or searching procs and functions for a specific string). But a "SELECT TheOfficialMSFunction()" is one of the first things I learned.
And if I don't remember that one, shame on me.
I think that hits the nail on the head, Brandie. Getting the current datetime is T-SQL 101. It's a "Hello World" type of thing.
November 6, 2015 at 6:27 am
Brandie Tarvin (11/6/2015)
xsevensinzx (11/6/2015)
Jeff Moden (11/5/2015)
Precisely. I couldn't have said it better myself. It's a bit like interviewing a mechanic. If they can't describe the difference between and open end and box wrench, they're not a mechanic. The simile here is that I'm taking mechanics out into the parking lot and asking them to point to a car and then to a pickup truck and they can't do it. It's that bad.
I hear ya. I just don't make the connection as easy I guess. I'm not a 10-year veteran of SQL mind you. I just have written thousands and thousands of lines of code in TSQL myself and have not used the alternatives you speak of yet as much as maybe you have. It's not ideally set in my mind and I don't think that's the same as not identifying a car from a truck as a mechanic. And I could go on the next 3 to 5 years not following the same as you may want and you toss out all my years of writing thousands of thousands of code for failing to give the alternatives to system time? That's a bit silly IMHO.
I think a better comparison would be not knowing the differences between DDL and DML when referencing the differences between a car and a truck. Surely the simple basics of a SELECT statement is also going to be a better comparison than alternatives to simple functions that is just not as widely used as say ALTER versus SELECT.
But how hard is it to come up with one function? The most basic function that everyone uses?
I save a lot of queries off so that I don't have to remember how to do things (like finding the text of a job step or searching procs and functions for a specific string). But a "SELECT TheOfficialMSFunction()" is one of the first things I learned.
And if I don't remember that one, shame on me.
Are we talking about people failing to know the basic function or people failing to know alternatives to the basic function? I thought the questions were to name the alternatives? Knowing the basic and knowing the alternatives are two different things. :w00t:
November 6, 2015 at 6:27 am
Ed Wagner (11/6/2015)
Brandie Tarvin (11/6/2015)
xsevensinzx (11/6/2015)
Jeff Moden (11/5/2015)
Precisely. I couldn't have said it better myself. It's a bit like interviewing a mechanic. If they can't describe the difference between and open end and box wrench, they're not a mechanic. The simile here is that I'm taking mechanics out into the parking lot and asking them to point to a car and then to a pickup truck and they can't do it. It's that bad.
I hear ya. I just don't make the connection as easy I guess. I'm not a 10-year veteran of SQL mind you. I just have written thousands and thousands of lines of code in TSQL myself and have not used the alternatives you speak of yet as much as maybe you have. It's not ideally set in my mind and I don't think that's the same as not identifying a car from a truck as a mechanic. And I could go on the next 3 to 5 years not following the same as you may want and you toss out all my years of writing thousands of thousands of code for failing to give the alternatives to system time? That's a bit silly IMHO.
I think a better comparison would be not knowing the differences between DDL and DML when referencing the differences between a car and a truck. Surely the simple basics of a SELECT statement is also going to be a better comparison than alternatives to simple functions that is just not as widely used as say ALTER versus SELECT.
But how hard is it to come up with one function? The most basic function that everyone uses?
I save a lot of queries off so that I don't have to remember how to do things (like finding the text of a job step or searching procs and functions for a specific string). But a "SELECT TheOfficialMSFunction()" is one of the first things I learned.
And if I don't remember that one, shame on me.
I think that hits the nail on the head, Brandie. Getting the current datetime is T-SQL 101. It's a "Hello World" type of thing.
This statement illustrates the problem:
I just have written thousands and thousands of lines of code in TSQL myself and have not used the alternatives you speak of yet as much as maybe you have.
When someone says something of this nature, and then cannot provide even the most basic answer of "getdate()", then their experience is, at best, very limited.
This article describes it very well. http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner%5B/url%5D
Like Jeff, I have also interviewed far too many people who advertise themselves as senior level who cannot provide a simple answer to a question such as that.
We're not looking for every permutation in detail. Using Brandie's example, if a candidate said I can't give you that syntax because I have these things saved in a file, or I just look it up, then that would work. Along those same lines, don't ask me to type out a RESTORE DATABASE query. I can't do it. What I can do, is open one of my saved queries, fill in the blanks, and go from there.
These folks do not know how to fill in the blanks, or even recognize that a blank exists!
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
Viewing 15 posts - 51,256 through 51,270 (of 66,738 total)
You must be logged in to reply to this topic. Login to reply