June 6, 2014 at 3:15 pm
thomashohner (6/6/2014)
kimberly_lehman (6/6/2014)
Ask "Using T-SQL, how do you get the current date and time"?
So would you consider this a valid answer? "I think it's CURRENT TIMESTAMP but if I was blanking on it I'd google it to be sure."
I've worked with so many language that sometimes I mix them up, so I often google things even if I know them. And sometimes even when I "know" something, a quick search reminds me of something I forgot. IMO, knowing how to find the information you need is just as valuable as already knowing it. And double checking yourself is a good skill too. If you've never forgotten a simple piece of syntax, then you never had a baby who didn't sleep through the night.
I believe GETDATE() is specific to T-SQL and CURRENT_TIMESTAMP is ANSI SQL function.
I think still learning
Now, that's the kind of answer that I'd expect from someone applying for a Senior position. I'd also expect them to just automatically cough up some extra info about UTC dates and times, etc. If they just say "GETDATE()" or just "CURRENT_TIMESTAMP", then they're probably not at the level I'm looking for for a Senior SQL Developer or a Senior DBA. Either is fine for a front-end developer position but they'd better know one of the two for a Senior front-end position that requires "some knowledge of SQL".
Like I said, you can tell a whole lot by asking questions at the start.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2014 at 9:41 am
Jeff Moden (6/6/2014)
ChrisM@Work (6/6/2014)
julian.fletcher (6/6/2014)
.. I should have said that we're looking for developers to work on all parts of a particular product; both the C# and the SQL. We're not big enough to be able to have separate teams for each...Shame...I'm nice, I work bl00dy hard, I'm available in two weeks and I'm 25 minutes from Oxford 😉
And bloody damned good at SQL, to boot!
I'm not ashamed to admit that last week was tough. We lost our mognificent rescue cat Ziggy last Monday night to a diversion which increased traffic on our street about 20-fold for a whole month. Damn, two hours after we lost him, the main road was reopened. This statement from you Jeff, and knowing how much you like your moggies too, absolutely made my day. Thank you.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 9, 2014 at 2:21 pm
ChrisM@Work (6/9/2014)
Jeff Moden (6/6/2014)
ChrisM@Work (6/6/2014)
julian.fletcher (6/6/2014)
.. I should have said that we're looking for developers to work on all parts of a particular product; both the C# and the SQL. We're not big enough to be able to have separate teams for each...Shame...I'm nice, I work bl00dy hard, I'm available in two weeks and I'm 25 minutes from Oxford 😉
And bloody damned good at SQL, to boot!
I'm not ashamed to admit that last week was tough. We lost our mognificent rescue cat Ziggy last Monday night to a diversion which increased traffic on our street about 20-fold for a whole month. Damn, two hours after we lost him, the main road was reopened. This statement from you Jeff, and knowing how much you like your moggies too, absolutely made my day. Thank you.
Guh! I'm so sorry to hear about that, Chris. We lost 4 almost one right after the other. Two finally succumbed to FIP (it happens a lot with moggies at about 3-4 years of age) and two to the rigors of old age (both more than 16 years old). Had to put all 4 down in a period of about 6 weeks. Debbie was a train wreck of emotion and I had to play the part of an anchor for her. One of them was an absolute favorite of mine so I definitely understand the pain of losing Ziggy.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2015 at 4:05 pm
I have had dozens of interviews in the past few years - am currently working a 1-year contract, so must have done something right.
IMHO the idea of 'asking technical questions' in an interview is just plain wrong! I have seen websites that have lists of such questions, plus a list of recommended 'answers' (most of them are wrong) - job applicants also see these sites and too frequently use them as a resource. Same is true for employers.
Here is one technique that IMHO should always be used, but never is - I even suggested it in several interviews but no employer was willing to try it - 'outside the box' or something.
Connect a PC to the office network in the interview room and display the screen on the wall. Connect to an instance you are having problems with and have the interviewee stand by the wall and, with him/her pointing to various things, display appropriate information and listen carefully as he/she goes through a troubleshooting process.
This will tell you more in just a few minutes about the candidate's abilities than asking 200 technical questions. It will also show you whether the candidate really knows how to troubleshoot.
NOTE THAT you do not actually change anything on this instance during the interview. You will instead see if the candidate knows things like 'examine the instance settings' (right-click name, then Properties). Or whether he/she knows how to use the Activity Monitor and what the different tabs mean - what is significant about the Resource Waits, for instance? Would the Processes tab show deadlocked SPIDs? And so on.
A candidate who can NOT do this kind of thing is not the one you want - no matter what your job description may say. Also, candidates who have memorized answers to all the 'technical questions' may fall apart with this exercise, because it reveals who really knows how to do things, and who does not.
Something as simple as asking them what version of SQL Server the instance is will reveal whether they really know how to obtain that rather simple information from the instance name line.
I have lost job offers to candidates who 'knew all the answers' but did not know how to find problems - how do I know? Because I saw the same job postings months later from the same employers - same job descriptions, even.
I really wish employers would get smart and try this instead of gathering lists of 'technical questions' from the internet.
May 22, 2015 at 1:11 am
rsgardner2 (5/21/2015)
. . . .Here is one technique that IMHO should always be used, but never is - I even suggested it in several interviews but no employer was willing to try it - 'outside the box' or something.
Connect a PC to the office network in the interview room and display the screen on the wall. Connect to an instance you are having problems with and have the interviewee stand by the wall and, with him/her pointing to various things, display appropriate information and listen carefully as he/she goes through a troubleshooting process.
. . .
I've had an interview that was like that. Along with the standard "tell me about the most interesting parts of your job" type questions, I was given a "server" (laptop) and told that application x has stopped working - what can you find wrong? I actually enjoyed that more than any other interview and was disappointed when that part of the interview finished - I wasn't done! I also got the job.
-------------------------------Posting Data Etiquette - Jeff Moden [/url]Smart way to ask a question
There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand (the world). There is no such thing as a dumb question. ― Carl Sagan
I would never join a club that would allow me as a member - Groucho Marx
May 22, 2015 at 5:47 am
rsgardner2 (5/21/2015)
I really wish employers would get smart and try this instead of gathering lists of 'technical questions' from the internet.
Paraphrasing Google here: It's not about finding a master who can do something amazing, it's about finding good problem solvers because eventually, they will figure it out.
I really agree with that statement to some extent. While it's cool that someone can answer a lot of standard technical questions, it's really important to know if the candidate is willing to tackle as well solve complex problems.
If giving someone a computer and a problem helps get you to that answer, then it should be done. And personally, I was given access to a dev environment when I interviewed for the position I had now just to prove that I could do the basics in SQL Server having only MySQL experience. My boss was not looking to hire a master. He was trying to both validate I knew the basics of what I said I did as well how my thought process was to a complex problem he was currently facing.
My role was not to fix the problems directly. My role was to have enough experience and knowledge to find the right people to fix it, which I did. Then later, I slowly took it over completely because my boss saw I had the foundation to do so if given the right opportunities and support to solve those complex problems over time.
May 22, 2015 at 8:39 am
rsgardner2 (5/21/2015)
I have had dozens of interviews in the past few years - am currently working a 1-year contract, so must have done something right.IMHO the idea of 'asking technical questions' in an interview is just plain wrong! I have seen websites that have lists of such questions, plus a list of recommended 'answers' (most of them are wrong) - job applicants also see these sites and too frequently use them as a resource. Same is true for employers.
Here is one technique that IMHO should always be used, but never is - I even suggested it in several interviews but no employer was willing to try it - 'outside the box' or something.
Connect a PC to the office network in the interview room and display the screen on the wall. Connect to an instance you are having problems with and have the interviewee stand by the wall and, with him/her pointing to various things, display appropriate information and listen carefully as he/she goes through a troubleshooting process.
This will tell you more in just a few minutes about the candidate's abilities than asking 200 technical questions. It will also show you whether the candidate really knows how to troubleshoot.
NOTE THAT you do not actually change anything on this instance during the interview. You will instead see if the candidate knows things like 'examine the instance settings' (right-click name, then Properties). Or whether he/she knows how to use the Activity Monitor and what the different tabs mean - what is significant about the Resource Waits, for instance? Would the Processes tab show deadlocked SPIDs? And so on.
A candidate who can NOT do this kind of thing is not the one you want - no matter what your job description may say. Also, candidates who have memorized answers to all the 'technical questions' may fall apart with this exercise, because it reveals who really knows how to do things, and who does not.
Something as simple as asking them what version of SQL Server the instance is will reveal whether they really know how to obtain that rather simple information from the instance name line.
I have lost job offers to candidates who 'knew all the answers' but did not know how to find problems - how do I know? Because I saw the same job postings months later from the same employers - same job descriptions, even.
I really wish employers would get smart and try this instead of gathering lists of 'technical questions' from the internet.
I understand that asking technical questions is not what a lot of people want to do but, IMHO, it's an absolute must. For example, if someone doesn't know how to get the current date and time in T-SQL (always my first question), how well do you think they're going to do on any sort of a practical test or even on the rest f the interview?
And to be sure, I really do ask "How do you get the current date and time using a query?" as the first question right after I explain that I never ask trick or esoteric questions nor any that require rote memorization and that the first couple of questions are going to be easy to get them to loosen up a bit. I've stopped keeping track of how many couldn't answer that question but it was something like only 2 out of 20 "developers" and 2 out of 10 "DBAs" that supposedly had a minimum of 10 years of experience and most of them claimed "tuning" experience as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2015 at 8:46 am
xsevensinzx (5/22/2015)
rsgardner2 (5/21/2015)
I really wish employers would get smart and try this instead of gathering lists of 'technical questions' from the internet.
Paraphrasing Google here: It's not about finding a master who can do something amazing, it's about finding good problem solvers because eventually, they will figure it out.
I really agree with that statement to some extent. While it's cool that someone can answer a lot of standard technical questions, it's really important to know if the candidate is willing to tackle as well solve complex problems.
Again, I have to disagree, for the most part. While finding a "master" is not my goal, it would be nice to find someone (anyone at this point) that isn't going to glaze over and start drooling on themselves when presented with a 3 table join or even how to get the current date and time.
As for "standard technical questions", they are a must. The difference is that you don't just sit there and listen to the applicant... you must interact with the applicant during the applicant's explanation and after. When I interview someone, every "standard" question is nothing more than a segue into a possible hierarchy of related questions and discussions on a give subject, the purpose being to find out if it's simple rote memorization on their part or if they've really done something, not to mention their ability to communicate and their general disposition.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2015 at 8:58 am
Jeff Moden (6/6/2014)
thomashohner (6/6/2014)
kimberly_lehman (6/6/2014)
Ask "Using T-SQL, how do you get the current date and time"?
So would you consider this a valid answer? "I think it's CURRENT TIMESTAMP but if I was blanking on it I'd google it to be sure."
I've worked with so many language that sometimes I mix them up, so I often google things even if I know them. And sometimes even when I "know" something, a quick search reminds me of something I forgot. IMO, knowing how to find the information you need is just as valuable as already knowing it. And double checking yourself is a good skill too. If you've never forgotten a simple piece of syntax, then you never had a baby who didn't sleep through the night.
I believe GETDATE() is specific to T-SQL and CURRENT_TIMESTAMP is ANSI SQL function.
I think still learning
Now, that's the kind of answer that I'd expect from someone applying for a Senior position. I'd also expect them to just automatically cough up some extra info about UTC dates and times, etc. If they just say "GETDATE()" or just "CURRENT_TIMESTAMP", then they're probably not at the level I'm looking for for a Senior SQL Developer or a Senior DBA. Either is fine for a front-end developer position but they'd better know one of the two for a Senior front-end position that requires "some knowledge of SQL".
Like I said, you can tell a whole lot by asking questions at the start.
So would I be correct in presuming that a reason to use CURRENT_TIMESTAMP instead of GETDATE() would be code portability? Making it (somewhat) easier if you need to migrate / run the query against say a SQL server and an Oracle server?
May 22, 2015 at 9:00 am
I agree with Jeff on the need for the technical questions.
I remember seeing a resume for a DBA that seemed to have good experience. I was eavesdropping on the phone interview with this person. From the way he answered the technical questions, which were all based on his resume or a previous answer, it was obvious that most of the items on his resume probably referred to projects where he was a member of the team that did whatever, but he was not the person who did it.
Without asking the technical questions, we would not have known he knew much less than he was implying.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
May 22, 2015 at 9:21 am
jasona.work (5/22/2015)
Jeff Moden (6/6/2014)
thomashohner (6/6/2014)
kimberly_lehman (6/6/2014)
Ask "Using T-SQL, how do you get the current date and time"?
So would you consider this a valid answer? "I think it's CURRENT TIMESTAMP but if I was blanking on it I'd google it to be sure."
I've worked with so many language that sometimes I mix them up, so I often google things even if I know them. And sometimes even when I "know" something, a quick search reminds me of something I forgot. IMO, knowing how to find the information you need is just as valuable as already knowing it. And double checking yourself is a good skill too. If you've never forgotten a simple piece of syntax, then you never had a baby who didn't sleep through the night.
I believe GETDATE() is specific to T-SQL and CURRENT_TIMESTAMP is ANSI SQL function.
I think still learning
Now, that's the kind of answer that I'd expect from someone applying for a Senior position. I'd also expect them to just automatically cough up some extra info about UTC dates and times, etc. If they just say "GETDATE()" or just "CURRENT_TIMESTAMP", then they're probably not at the level I'm looking for for a Senior SQL Developer or a Senior DBA. Either is fine for a front-end developer position but they'd better know one of the two for a Senior front-end position that requires "some knowledge of SQL".
Like I said, you can tell a whole lot by asking questions at the start.
So would I be correct in presuming that a reason to use CURRENT_TIMESTAMP instead of GETDATE() would be code portability? Making it (somewhat) easier if you need to migrate / run the query against say a SQL server and an Oracle server?
If you believe in the myth of code portability, then yes... it would be one less thing to change.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2015 at 11:08 am
Jeff Moden (5/22/2015)
If you believe in the myth of code portability, then yes... it would be one less thing to change.
Having worked on SQL and Oracle here, I believe in code portability like I believe in the Easter Bunny, the Tooth Fairy, and winning lottery tickets (Santa Claus I do believe in, he attends the occasional Detroit SPID meetings, I've seen him at a few I go to :hehe: )
May 22, 2015 at 11:34 am
Jeff Moden (5/22/2015)As for "standard technical questions", they are a must. The difference is that you don't just sit there and listen to the applicant...
This is exactly the key when asking technical questions.
"How do you get the current data and time using T-SQL" is not a good question.
A better way to ask the same question may be something like "You need to record the date and time of when a row is inserted into a table. What mechanism would you use?"
That is open ended.
A person may answer "Use a default with getdate()". Another person may answer that question with a number of other questions.
Which one gets the position?
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/
May 22, 2015 at 12:38 pm
Michael L John (5/22/2015)
Jeff Moden (5/22/2015)As for "standard technical questions", they are a must. The difference is that you don't just sit there and listen to the applicant...
This is exactly the key when asking technical questions.
"How do you get the current data and time using T-SQL" is not a good question.
A better way to ask the same question may be something like "You need to record the date and time of when a row is inserted into a table. What mechanism would you use?"
That is open ended.
A person may answer "Use a default with getdate()". Another person may answer that question with a number of other questions.
Which one gets the position?
Not quite my meaning. Asking how you get the current date and time is perfect because, if they've done it before, they will answer it correctly. Of course, they might answer it correctly even if they haven't done it before and you can normally detect that because they'll state the answer with questioning tones. "ummmm... GETDATE()???".
Whether they answer that question correctly or not or with questioning tones is the segue into a similar line of questioning. For example...
1. Is that the only way you can do this?
2. What is the difference between the function(s) you mentioned and GETDATE().
3. When would you use those functions instead of GETDATE() and why?
4. How would you strip the time off of GETDATE() and why would someone need to do such a thing?
5. Given a StartDate and an EndDate, how would you calculate the duration/elapsed time the two dates represent? Is that same method possible with DATETIME2? Why or why not?
What's actually the best is when I don't have to pull such information out of the applicant. I love it when I ask the simple current datetime question and the applicant tells me 6 different functions, the datatype for each function, the advantages and disadvantages of the functions, and when/not when to use the various datatypes/functions, all without asking and all within about 5 minutes and that includes actual experience instead of just rote book knowledge.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2015 at 8:37 pm
Jeff Moden (5/22/2015)
Michael L John (5/22/2015)
Jeff Moden (5/22/2015)As for "standard technical questions", they are a must. The difference is that you don't just sit there and listen to the applicant...
This is exactly the key when asking technical questions.
"How do you get the current data and time using T-SQL" is not a good question.
A better way to ask the same question may be something like "You need to record the date and time of when a row is inserted into a table. What mechanism would you use?"
That is open ended.
A person may answer "Use a default with getdate()". Another person may answer that question with a number of other questions.
Which one gets the position?
Not quite my meaning. Asking how you get the current date and time is perfect because, if they've done it before, they will answer it correctly. Of course, they might answer it correctly even if they haven't done it before and you can normally detect that because they'll state the answer with questioning tones. "ummmm... GETDATE()???".
Whether they answer that question correctly or not or with questioning tones is the segue into a similar line of questioning. For example...
1. Is that the only way you can do this?
2. What is the difference between the function(s) you mentioned and GETDATE().
3. When would you use those functions instead of GETDATE() and why?
4. How would you strip the time off of GETDATE() and why would someone need to do such a thing?
5. Given a StartDate and an EndDate, how would you calculate the duration/elapsed time the two dates represent? Is that same method possible with DATETIME2? Why or why not?
What's actually the best is when I don't have to pull such information out of the applicant. I love it when I ask the simple current datetime question and the applicant tells me 6 different functions, the datatype for each function, the advantages and disadvantages of the functions, and when/not when to use the various datatypes/functions, all without asking and all within about 5 minutes and that includes actual experience instead of just rote book knowledge.
I can respect that for sure.
I think the issue for me is that you're simply referring to understanding the language rather than solving a complex problem. To put that into context, it's like asking someone in America what's the definition of a word and asking if there are any similar words and when would you use them?
Those are in my humble opinion easier to fix than someone who crumbles under pressure or can't tackle big problems that we face every day on the job. Figuring out the difference between functions is not one of those big problems IMHO.
On the other hand, time is a very critical part to what we do too. When having a similar conversation with a senior like yourself, we talking about how years of experience and knowing a vast amount of information was so critical to a senior level role he was filling versus using reference materials on Google and ETC. I had mentioned that most issues he could face are pretty well documented these days. The community around SQL Server is pretty robust and active. He smiled and responded with, "You're looking at the problem all wrong. Yes, you could eventually come to the answer using referenced materials. What separates those guys from me is speed. While they are referencing, I'm already fixing it."
Which makes all the sense in the world 100%.
Viewing 15 posts - 31 through 45 (of 47 total)
You must be logged in to reply to this topic. Login to reply