Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««12345»»

Interview Questions Expand / Collapse
Author
Message
Posted Friday, June 6, 2014 3:15 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:54 AM
Points: 37,867, Visits: 34,743
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1578526
Posted Monday, June 9, 2014 9:41 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 10:12 AM
Points: 7,291, Visits: 15,324
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.


“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

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
Exploring Recursive CTEs by Example Dwain Camps
Post #1578887
Posted Monday, June 9, 2014 2:21 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:54 AM
Points: 37,867, Visits: 34,743
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1578973
Posted Thursday, May 21, 2015 4:05 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, June 30, 2015 2:45 PM
Points: 175, Visits: 88
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.
Post #1687861
Posted Friday, May 22, 2015 1:11 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: 2 days ago @ 2:36 AM
Points: 3,614, Visits: 3,909
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
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
Post #1687925
Posted Friday, May 22, 2015 5:47 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 9:35 PM
Points: 215, Visits: 888
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.
Post #1687995
Posted Friday, May 22, 2015 8:39 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:54 AM
Points: 37,867, Visits: 34,743
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1688073
Posted Friday, May 22, 2015 8:46 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:54 AM
Points: 37,867, Visits: 34,743
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1688078
Posted Friday, May 22, 2015 8:58 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 7:02 PM
Points: 898, Visits: 6,394
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?
Post #1688085
Posted Friday, May 22, 2015 9:00 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 8:07 AM
Points: 1,890, Visits: 9,405
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.




Alvin Ramard
Memphis PASS Chapter

All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.
Post #1688088
« Prev Topic | Next Topic »

Add to briefcase «««12345»»

Permissions Expand / Collapse