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%.