Crazy Interview Questions

  • Comments posted to this topic are about the item Crazy Interview Questions

  • What kind of car are you and why?

    I was asked this in an interview and really liked it.  I picked a car which I thought was reliable, dependable and was easy to live with.  I think it gives the interview panel some kind of insight as to how the person being interviewed sees themselves.

    Absolutely keep a test in there, we need the technical skills, but it's a balance between how well can we code and how well will we fit into a team.  Both are important.

  • I actually got caught by the question where they ask what steps you would take if a client asked for a change.

    The actual answer is "I would forward it to my supervisor because it's not my responsibility."

     

  • Very relevant topic. I've interviewed at Amazon once I think. They ask the toughest technical questions.

    Where I work now, I've been asked to sit in some interviews for candidates applying for software developer positions. Even at a senior software engineer level, all interviews last only an hour. It's hard, in such a short interview, to try and determine if the candidate would be a good fit or not, especially if they're pretty much the same. In such situations it really turns into a popularity contest. But all the technical questions are trivial in nature. Normally something like determining if the candidate understands the scoping of variables with the same name, defined outside of a function and within a function - nothing that anyone wouldn't get, unless they were inexperienced.

    Steve, the idea of asking candidates tough technical questions to see how well they might fit within one's group, is a new one to me. I've got to think about that for a while.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • The best question of them all also comes from "Star Trek"...

    "How do you feel"?

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

  • We've got a series of questions we go through whenever we are interviewing a new potential DBA (hasn't happened in awhile).   There are a few "how would you do this" types, as well as some "give us an example of how how you solved this kind of issue in the past" which are there to get at how the candidate thinks.  Our technical "test" type questions are looked at as a group.  Less "did they get every question right" than "do they know what they are talking about at all".  There are also a few technical questions which were rather vague where the answer was really what questions the candidate would ask us in clarification.  Back when we did a lot more hiring it was not uncommon to run into a candidate whose resume said DBA, but whose responses to the technical questions said "took a bunch of certification exam practice tests".

  • I was asked how I liked to report to my manager?

    I responded that I liked to respond to my manager in the manner in which they would like to me to report to them.

  • Here is a good one. Not only does it reveal a lot of the candidate's experience and problem solving skills, but it can lead to an even more revealing back and forth discussion. The more challenging and novel the problem, the better. Bonus points if I learn something new from candidate.

    "Tell me about the most difficult SQL Server related problem that you encountered in the past year, and describe how you resolved it."

     

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • At my last company we had two aspects to interviews - both some canned HR type stuff and the technical side.

    For the technical part, I'd modified an existing list of questions to be answered on a company laptop (alone, would be unfair pressure to sit and watch). It wasn't so much to score people - and I made this clear to interviewees to put them at ease - but to probe different areas to see strengths and weaknesses - so a bunch of easy questions, a bunch on different topics (HA/DR, performance etc) and a couple of quite difficult internals questions that I didn't expect most people to answer correctly. I thought it worked pretty well - if people failed the easy questions then it's a red flag, then for the rest of them, we got a good overall picture of knowledge and what kind of further training someone might need in an individual area. Bonus points for the intentionally hard questions.

    Aside from that, I liked to ask about how people would approach solving a problem, looking for them to ask the right kind of questions - like how important an environment is, has it happened before, do we have monitoring already, collaboration with other teams i.e. networks/windows etc. Again, I stressed there was no 'right answer' we were looking for, just anything they could say about their thought process.

    I also liked to ask if they followed any SQL bloggers or websites as in my book that says a lot. I was surprised at some applicants who had never heard of SSC, Brent Ozar, Pinal Dave etc. There's nothing stopping someone being a great DBA without, but it seemed like pretty much all the people who technically impressed were also familiar with at least some these resources.

    https://sqlrider.net - My technical blog

  • I agree interviewers love to ask tricky questions. I have gone through many interviews throughout my life, and only a few were successful. I work in the banking industry, where interviewers like to ask tough and tricky polls. Then a friend of mine advised me on one free guide, Investment Banking Technical questions. I can say that this guide helped me a lot, and I was finally able to pass the interview and get my dream job adequately.

    • This reply was modified 1 year, 8 months ago by  stasikpasik.
  • stasikpasik wrote:

    I agree interviewers love to ask tricky questions.

    Heh... wait for it...

    --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 11 posts - 1 through 10 (of 10 total)

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