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

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)