Interview Questions for Advanced DB Engineer Candidates

  • Many years ago, a recruiter called me about a job, and the company had given her a list of seven screening questions to ask potential candidates.  At this point, I can only remember one question:  "When diagnosing performance problems with STATISTICS IO, which is more important to consider, Physical Reads or Logical Reads?"

    As I recall, my answer to the question started something like, "Oh, gosh ... that's a really good question.  Let me think about it for a second...".  Then I gave my answer and explained why I chose that answer.  This strikes me as a really good screening question to give a recruiter.  It is a simple question.  It has a simple answer.  I can explain the correct answer briefly and in simple language an educated non-programmer can understand.  However, giving the correct answer requires that you understand something significant about SQL Server internals (in this case, SQL Server's data caching mechanism).

    I am looking for more questions like this:  deceptively simple questions with simple answers that require fairly deep understanding of SQL Server internals in order to answer correctly.  The questions should require some thought in order to answer, but should be simple enough to explain in a paragraph or two, even to a non-professional.  They should not be the sort of "SQL Quiz Show" questions that you can Google in five seconds.

    Can you help me with questions of this sort?  You need only provide the question, not the answer.

  • Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • With the understanding that this is nothing against you, if we posted such questions and the answers here, that would eventually render them useless in interviews because people will do their homework when going for such a good position.  Soon a dozen people would publish them on LinkedIn, StackOverflow, etc, and BOOM!  useless questions that anyone can answer.

    I honestly hope that my peers take that same suggestion to not publish such questions and answers.

    --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)

  • I would take Jeff's advice here. Plus, the question about if logical or physical reads are more important to performance tuning can be found by doing a google for "performance tuning statistics IO" and the very first link brings you to a SQL Server Central post on the topic. Plus I have seen a lot of "SQL Server interview questions" pop up in my twitter feed (I mean X feed or whatever they are called now) and linked in plus TONS of results in google. These questions pop up ALL over the place and are EASY to find. But as soon as they are published on a "top questions for SQL interviews" (or similar sites), the questions become irrelevant in an interview. Basically, you just find out if they are good at google.

    My opinion, a better approach is to ask "discussion" questions, not questions that you can get an answer to right away. So rather than asking "what are the different types of joins?" ask a question where the answer would require them to mention joins, and if you ask a good question, you can even lead them to answer with a specific join type. And rather than asking "what are windowing functions and where would you use them?" ask them about a specific use case where you would want to use them in a query and see if they take the bait or they try to explain it in a more complex manner. Just don't ask them to write the SQL by hand/memory when hiring for anything other than a Jr. position (my opinion).

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

  • Fair enough.  There are certainly enough worthless lists of interview questions on the internet.  After much labor, I came up with a list of screening questions that I felt met my criteria.

    Unfortunately, when I tested them on my team, I found that they eliminated 90% of my current colleagues.

    That might be a tad more selective than I can afford to be in screening candidates.

  • "My opinion, a better approach is to ask "discussion" questions, not questions that you can get an answer to right away. So rather than asking "what are the different types of joins?" ask a question where the answer would require them to mention joins, and if you ask a good question, you can even lead them to answer with a specific join type."

    Here is the problem I am trying to solve.  We have a pretty good team (in my opinion) and we want to be selective about who we add.  However, we have a corporate recruiter who does not get paid unless we hire the candidates he submits.  The candidates he submits are mostly pretty bad.  He then screams bloody murder to his bosses when we don't hire them.

    He has asked for a list of screening questions he can use to better filter out candidates.  We will still interview the candidates that pass through the screen.  Coming up with a good list of questions is harder than it might seem.  The typical "SQL Quiz Show" questions are terrible.  Thus, I am trying to come up with a list of questions that meet a stringent set of criteria.

    • It is a simple question.
    • It has a simple answer.
    • I can explain the correct answer briefly and in simple language an educated non-programmer can understand.
    • However, giving the correct answer requires that you understand something significant about SQL Server internals

    Of course, I understand where you are coming from.  Consider the question withdrawn.

    • This reply was modified 11 months, 2 weeks ago by  David Moutray.
  • I've been through that with a recruiter before.  The recruiter wanted the questions and the answers so that they could do the filtering.

    The damned recruiter gave the candidates both the questions and the answers.  I know this because I added a "hairball" question with a totally made up answer and when I asked the candidates that same question, they provided the hairball answer.

     

    --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)

  • "The damned recruiter gave the candidates both the questions and the answers.  I know this because I added a "hairball" question with a totally made up answer and when I asked the candidates that same question, they provided the hairball answer."

    I must be an honest man (or a stupid one) because I never thought of that.  It makes sense, though.

    Yeah, I'll push back on providing screening questions and save any technical questions I have for the main interview.

  • David Moutray wrote:

    "The damned recruiter gave the candidates both the questions and the answers.  I know this because I added a "hairball" question with a totally made up answer and when I asked the candidates that same question, they provided the hairball answer."

    I must be an honest man (or a stupid one) because I never thought of that.  It makes sense, though.

    Yeah, I'll push back on providing screening questions and save any technical questions I have for the main interview.

    I'm incredibly honest.  I won't even provide a fake phone number just to see a webinar that I'd like to see that requires a phone number.  I'll just skip the webinar rather than lie.

    The reason why I did that was because it seemed to be something that recruiters were doing and I needed a way to prove it.  In other words, I'd been burned before and didn't want to be burned again.  This thing about trust but verify?  Things like this have made me so I trust no one up front and it takes a long time for someone to earn my trust.

    --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)

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply