Sorting the Sheep from the Goats

  • I don't have a chance to do interviewing now, but at my previous company we had a test that had a few multiple choice questions, but was mostly free form. I do like the idea of putting a candidate in front of a computer and have them accomplish a task.

    I would, however, be a little worried about interviewing with those who ask how to strip the minutes out of a date time. I don't have to use that very often. When I do, I go to my T SQL folder, find the Strip Minutes file, which has four different ways to do it along with the results of someone else's performance test and a comment from me indicating that one of the ways is unreliable if it's past noon despite it's fastest performance, and use that. So despite the fact that I can create tables, SPs, using temp tables, derived tables and quickly figure out the joins, how to find dups quickly, I suppose I would have problems with that particular interviewer. I don't really see that as too different from having memorized a battery of built-in functions.

  • I give people I interview a test of SQL questions, four that I expect that anyone worth hiring can solve, and one that I expect most people will not be able to solve to my satisfaction. If they miss the easy ones, they don’t get hired.

    I use the hard one as a starting point for a conversation: I point out the problems I see with their solution and see what they come up with, or if they even understand what my objections are. It helps to see how they react to an initial failure and if they can use new information to come up with something better. I have yet to interview someone who came up with the optimal solution on the first try.

  • There are some interesting responses here! In a former life I managed a medium sized construction company and was responsible for 98% of new hires. My interviews were directed more towards finding out how the individual thinks. How do they approach a problem. Do they systematically and logically evaluate the problem to arrive at a reasonable conclusion? I deliberately conducted interviews that required the interviewee to question me to get the information they needed. If they didn't have the gumption to go after the information, then I didn't have a place for them on my crews.

    You can rein in an energetic colt, but you can't push a rope!

    ----------------------------------------------------------------------------
    "No question is so difficult to answer as that to which the answer is obvious." - George Bernard Shaw

  • Michael Valentine Jones (5/27/2008)


    I give people I interview a test of SQL questions, four that I expect that anyone worth hiring can solve, and one that I expect most people will not be able to solve to my satisfaction.

    If someone has already had to solve all of the problems that you are presenting, then they will be able to answer all of your questions without a problem. Once again, you are testing previous knowledge/experience without testing the ability to learn.

    Having the interviewee then have to sit there and listen to you tell them all of the things wrong with their answers sounds like a painful after-shock. Going through an interview is difficult enough for an introverted techie without having to deal with a question dissection afterward.

    In essence, you may be hiring either a) a person that has already done what you need them to do. Or b) a person that smiles at her/his boss and can take criticism gleefully.

    If/when you need to come to either of these individuals for a new concept, you may still be disappointed.

    Mia

    Mia

    I have come to the conclusion that the top man has one principle responsibility: to provide an atmosphere in which creative mavericks can do useful work.
    -- David M. Ogilvy

  • mhaskins (5/27/2008)


    Michael Valentine Jones (5/27/2008)


    I give people I interview a test of SQL questions, four that I expect that anyone worth hiring can solve, and one that I expect most people will not be able to solve to my satisfaction.

    If someone has already had to solve all of the problems that you are presenting, then they will be able to answer all of your questions without a problem. Once again, you are testing previous knowledge/experience without testing the ability to learn.

    Having the interviewee then have to sit there and listen to you tell them all of the things wrong with their answers sounds like a painful after-shock. Going through an interview is difficult enough for an introverted techie without having to deal with a question dissection afterward.

    In essence, you may be hiring either a) a person that has already done what you need them to do. Or b) a person that smiles at her/his boss and can take criticism gleefully.

    If/when you need to come to either of these individuals for a new concept, you may still be disappointed.

    Mia

    I agree that my first four questions are not designed to test their ability to learn; they are meant to test their ability to solve basic SQL problems that anyone I want to hire should be able to do. It is unlikely that they have answered any of these problems before, since I wrote them all myself.

    Some people may find it uncomfortable to find their solutions criticized, but I am not really concerned with how much they enjoy or hate it. I am only trying to see how well they do when they encounter a problem with a solution and are asked to find an alternative.

  • Mr. Davis' editorial had me a bit confused at first.

    Personally, I use a border collie to sort sheep and goats, but as intelligent as she is, I don't think she would be able to tell a good DBA from a bad one :). BTW, Sheep and goats don't have to be sorted in the real world, they flock separately. "Separating wheat from chaff" is a better metaphor.

    Seriously, I think testing is problematic when trying to evaluate managerial, organizational, and analytical skills. Maybe there is a way to identify people who enjoy being technically challenged, and possess the curiosity to pursue independent research. I am suspicious of the "Send me to be trained" mentality. A well designed job interview process is the cornerstone of our selection process.

  • Robert A. Schottland (5/27/2008)


    Personally, I use a border collie to sort sheep and goats, but as intelligent as she is, I don't think she would be able to tell a good DBA from a bad one :).

    She's still probably better than some hiring managers I know!

    BTW, Sheep and goats don't have to be sorted in the real world, they flock separately.

    Actually, this is true in the DBA world also, but that doesn't help in an interview. πŸ˜€

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.
    [/font]
    [font="Verdana"] "Performance is our middle name."[/font]

  • Being in a DBA role which supports a lot of customers...

    we used to have a great test for anyone interviewing for a position. over the phone walk someone through tieing their shoes. First question should be: 'Do you have shoelaces' πŸ™‚

    You get a great idea of their thought process, troubleshooting capabilities, quick acting, etc.

  • rbarryyoung (5/27/2008)


    Robert A. Schottland (5/27/2008)


    BTW, Sheep and goats don't have to be sorted in the real world, they flock separately.

    Actually, this is true in the DBA world also, but that doesn't help in an interview. πŸ˜€

    Yeah. Flockin' DBAs - who'd have 'em πŸ˜‰

    Semper in excretia, suus solum profundum variat

  • Robert Hermsen (5/27/2008)


    Being in a DBA role which supports a lot of customers...

    we used to have a great test for anyone interviewing for a position. over the phone walk someone through tieing their shoes. First question should be: 'Do you have shoelaces' πŸ™‚

    You get a great idea of their thought process, troubleshooting capabilities, quick acting, etc.

    Like it. Did anyone come out with "Well, your right shoe's got nice new laces, but it seems your left one's still on version 1. You might get some compatibility issues until you upgrade both to the same level..."?

    Oh, no; I forgot. We're hiring a DBA, not a consultant. My mistake πŸ˜€

    Semper in excretia, suus solum profundum variat

  • All very good points. When I was a consultant, I was constantly interviewing. I hate interviewing. Now, I'm a fulltime employee. I occasionally go out on interviews, just to keep myself familiar with the process and prevent rust. I highly recommend it.

    A note to the interviewers, take some pity on the candidate. I don't interview well, I get nervous, which isn't good. I speak slowly and deliberately, albeit prone to tangents. I'm often concerned with intimidating the interviewer. No, not a concerted effort, and not in a menacing way either. (One of the compliments I received during college was from an old Indian, I've forgotten the tribe, that told me: "In a former life, you were a grizzly bear...":w00t:)

    On occasion, I've been asked to do a technical screen for consultants being considered. We had one gentlemen come in with MULTIPLE Phds. This immediately raised my suspicion, considering the candidate appeared to be my junior (age). A friendly conversation revealed to me he didn't know the slightest thing about EE, CS, or Math. Then again, another candidate came in with his only real qualification being he's a CPA. That guy has been here ever since.

    RE: Testing.

    I have to agree with many of the posters. I took the Brainbench tests. Passed them with very high marks, but I think the only point they serve is to get the attention of a headhunter / HR screener. They're worthless when it comes time for the interview.

    Honor Super Omnia-
    Jason Miller

  • majorbloodnock (5/28/2008)


    Oh, no; I forgot. We're hiring a DBA, not a consultant. My mistake πŸ˜€

    Heh... some of us consultants ain't so bad... πŸ˜€

    ... but I do understand what you mean.

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

  • majorbloodnock (5/28/2008)


    Robert Hermsen (5/27/2008)


    Being in a DBA role which supports a lot of customers...

    we used to have a great test for anyone interviewing for a position. over the phone walk someone through tieing their shoes. First question should be: 'Do you have shoelaces' πŸ™‚

    You get a great idea of their thought process, troubleshooting capabilities, quick acting, etc.

    Like it. Did anyone come out with "Well, your right shoe's got nice new laces, but it seems your left one's still on version 1. You might get some compatibility issues until you upgrade both to the same level..."?

    Oh, no; I forgot. We're hiring a DBA, not a consultant. My mistake πŸ˜€

    Oh no - as a DBA - you'd probably have to describe tying the shoe, from the perspective of BEING in the shoe. Focus on how to tie it while it is in use, maintaining maximum uptime, and reliability (double-knots).:D

    Clustering your tied shoes might be tricky though.......:hehe::P

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Matt Miller (5/28/2008)


    Clustering your tied shoes might be tricky though.......:hehe::P

    He, he.

    Three-legged race, anyone?

    Semper in excretia, suus solum profundum variat

  • majorbloodnock (5/28/2008)


    Matt Miller (5/28/2008)


    Clustering your tied shoes might be tricky though.......:hehe::P

    He, he.

    Three-legged race, anyone?

    I guess that would be an inner join... and has the usual performance problems associated with joins on unindexed legs ... er ... columns.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Viewing 15 posts - 16 through 30 (of 40 total)

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