Hiring Guitarists

  • Andrew..Peterson - Tuesday, August 15, 2017 1:53 PM

    Interesting, but I've found that many focus on "what" someone knows, rather than understanding if someone can think.  One of the comments about Glen Campbell, who passed away recently, was that he could not read music.  So, it is a good chance he would fail many music tests.  And I've worked with others who would probably fail many of the tests that are given today. Still, they knew how to solve a problem.  And, yes, I've worked with many who knew all the "what" but were terrible.  Anyone can google how MERGE works. Bottom line, stop using tests that focus on syntax, and spend more time on understanding if someone can think.  If they can think and are motivated, they will succeed.

    I think this is one of the major failings of interviewing. In fact, I saw this post today: https://circleci.com/blog/interviewing-as-an-outsider-how-i-finally-got-seen-in-tech/?utm_content=buffer9d44b&utm_medium=SCC&utm_source=SSC
    We too often focus on do you know x or have been to/worked for/a part of Y, but rarely look forward to how will you work here and do you consider new problems differently.

  • Steve Jones - SSC Editor - Thursday, August 17, 2017 9:21 PM

    Andrew..Peterson - Tuesday, August 15, 2017 1:53 PM

    Interesting, but I've found that many focus on "what" someone knows, rather than understanding if someone can think.  One of the comments about Glen Campbell, who passed away recently, was that he could not read music.  So, it is a good chance he would fail many music tests.  And I've worked with others who would probably fail many of the tests that are given today. Still, they knew how to solve a problem.  And, yes, I've worked with many who knew all the "what" but were terrible.  Anyone can google how MERGE works. Bottom line, stop using tests that focus on syntax, and spend more time on understanding if someone can think.  If they can think and are motivated, they will succeed.

    I think this is one of the major failings of interviewing. In fact, I saw this post today: https://circleci.com/blog/interviewing-as-an-outsider-how-i-finally-got-seen-in-tech/?utm_content=buffer9d44b&utm_medium=SCC&utm_source=SSC
    We too often focus on do you know x or have been to/worked for/a part of Y, but rarely look forward to how will you work here and do you consider new problems differently.

    Thanks Steve, the posting is a great example of the right way to interview.  Major points for the interviewer taking the time to learn about the candidate before the interview.  I am amazed how often the interviewer fails to take the time to get prepared.  Hiring the right staff that fit the company is one of the most important, yet many approach the task like they are taking out the garbage.  And we wonder why so many companies fail!

    The more you are prepared, the less you need it.

  • patrickmcginnis59 10839 - Wednesday, August 16, 2017 11:32 AM

    "The "what", "why", "when", and "how" is important to being able to do the job and people need to learn how to do those things without constantly having to hit up on Yabingooglehoo" before they apply for a job that requires it."

    I'd probably mess up in Jeff's interview if I were interviewing for a job unless I crammed for it. Even for the servers that I still had that required using t-sql backup jobs, I used a parameterized template to create the procedure on the destination server, and in a few cases we were moving to commercial packages that made backup administration a point and click affair. I would routinely restore to test servers using macro looking techniques to restore giant stacks of tlogs to get to a particular point in time so I could debug a button push on an app, and heck for that matter isn't the gui pretty handy for backing up or restoring databases on an adhock basis? I've had success in developing a generic restore that included generating the move statements so restores themselves could be scheduled. Yet, I simply can't remember the last time I've typed a backup or restore command from scratch. Is that a bad idea on my part if I were job hunting? Is this sort of thing worth practicing in case I interview somewhere?

    No... you' probably wouldn't mess up in one of my interviews.  I don't expect someone to actually remember a backup or restore command off the top of their heads because, if you've done things correctly, then you've only ever had to write the command once or twice in your entire employment for a given company.  If my question were "What can you tell me about the backup and restore process?", your answer above would have been perfect.

    Instead, I get things like "I use a 3rd party product to do my backups.".  My follow up question then is, "Which one"?  The answer I get from that is frequently "I don't remember".  Either way, I then ask "How do you use that product to do a Point-in-Time restore"?  I frequently get, "I've never had to do one".  Taking a final shot at it, I ask "if you had to do a Point-in-Time restore, what are the steps you would take either using your 3rd party product or an SQL Server native restore"?  A couple of people asked me why I was asking a DBA questions about backups and restores.  A couple told me they'd call the 3rd party product helpline.  A couple told me they'd never done a restore but they were told the GUI would make it easy.  A couple told me they didn't actually know where the backup files were stored.  One guy told me that he was leaving because I was asking hard questions just to show off.  One guy told me he wouldn't be able to work with me because I was too concerned with details.  The list goes on.

    None of these people know how to get the current date and time, either.

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

  • skeleton567 - Wednesday, August 16, 2017 8:05 AM

    I always felt that it's not as important to know all the answers as it is to know and understand how to find them.  It's like art.  Lots of folks recognize good art when they see it, but far fewer know how to get from the paint pallet to the finished canvas.  It's always amazed me that the most vocal critics can't themselves produce the work.  Sort of sounds like politics and protesters also.

    I agree to some extent but when you claim to have been a DBA or developer or performance tuner for 10 years, there's a whole lot of stuff you should just know off the top of your head.

    --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 4 posts - 61 through 63 (of 63 total)

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