Hiring Guitarists

  • Even with all that I have seen I remain amazed at some of the tales that we all appear to be able to recall. It is quite shocking at how bad some people, even organisations can be. Delusions of adequacy!!!

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Only thing I don't agree with it this:  "If I insist on making poor choices, I want their support, but if they can influence me to do better, I'd prefer they did." 
    If you really insist on making poor choices, I'm not in your boat.  Best you know that up front.  And if you fire me for that, it may just reinforce my position. 
     

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • Wow, a four year old rerun.  I now understand an interview I had two years ago better.  I left that interview feeling like I was a bad fit for a manager who did not understand the evolution of the stream.

    For a senior level DBA, performance optimization is the pinnacle of the art, and I would start there.

  • seebert42 - Monday, August 14, 2017 5:17 AM

    Wow, a four year old rerun.  I now understand an interview I had two years ago better.  I left that interview feeling like I was a bad fit for a manager who did not understand the evolution of the stream.

    For a senior level DBA, performance optimization is the pinnacle of the art, and I would start there.

    "It Depends" on the type of DBA that you're looking to hire.  Although I agree that performance optimization is incredibly important for the system, it may have absolutely nothing to do with what the job description is for the "DBA" position.  You also need to define what "performance optimization" is.  Some think that it's setting up SQL Server with the right Trace Flags, the correct number of TempDB files, and deciding which type of RAID should be used for which drives and possibly include some form of DR replication that keeps the RPO very high and the RTO very low.  Others think that it's finding and fixing performance challenged code.  Some include the "pipe" itself.

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

  • Gary Varga - Thursday, July 18, 2013 8:50 AM

    Even with all that I have seen I remain amazed at some of the tales that we all appear to be able to recall. It is quite shocking at how bad some people, even organisations can be. Delusions of adequacy!!!

    Agreed.  Having done work for quite a few organizations, I've found a few that were well managed, and many more that seem to succeed despite their disfunction. And a few that do not succeed.

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

  • I still think it's horrible that 20 out of 22 "guitarist" applicants we had don't know what a fret is or where the neck of the guitar actually is.

    --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 have always found that those with either musical or foreign language abilities tend to brr good at coding/databases as tthey have more logical thought patterns. For some reason football fans seem the worse; chaps interested in cricket and rugger performing better!  🙂

  • Jeff Moden - Monday, August 14, 2017 1:22 PM

    I still think it's horrible that 20 out of 22 "guitarist" applicants we had don't know what a fret is or where the neck of the guitar actually is.

    You post this quite a bit and its got my curiousity up, do these applicants come in with any sort of credentials and job history sufficient to make it past the HR filter? Because while I personally don't know how to get the current date out of the database right offhand (besides getdate()), I certainly would learn a chord or two before calling myself even a beginning guitarist 🙂

    I know you gotta keep details private, but I would love to hear some paraphrased examples of how bad the resume / interview gap could really get.

    I remember one individual saying when discussing graphical programming that they liked drawing buttons and grids but didn't like all the typing that went on in the "other windows".d That was a student tho, so you have to expect a certain lack of experience in that case. Actual job applicants on the other hand...

  • Jeff Moden - Monday, August 14, 2017 1:22 PM

    I still think it's horrible that 20 out of 22 "guitarist" applicants we had don't know what a fret is or where the neck of the guitar actually is.

    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.

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

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

    Jeff Moden - Monday, August 14, 2017 1:22 PM

    I still think it's horrible that 20 out of 22 "guitarist" applicants we had don't know what a fret is or where the neck of the guitar actually is.

    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.

    To continue with the music simile, despite the fact that he had difficulty reading music, he knew a whole lot of "what".  He knew what frets were and what they were for.  He knew what the neck of the guitar was and how to use it.  He knew what cords were and how to play them.  He knew what sounded good and even knew the name of the common tool he used to help him play.  He was, indeed, brilliant in the music world.

    And, yet, if the job that I had open required someone that could "read music", I wouldn't hire him for that position because 1) he couldn't do the job immediately, 2) after he learned, he wouldn't be able to do the job as well as someone that had actually been doing it for 10 years, and 3) since he did have a couple of decades to learn it and didn't, probably wouldn't like the job if he got it because he avoided learning that basic requirement for a reason... he didn't like it.  Don't get me wrong... if I had an opening to take advantage of the skills that he did have, I'd do it.  But, first, I need someone with experience reading music that can do it very well right now.

    Compare that with some candidate that claims 10 years of being a production DBA or Developer and doesn't know how to get the current date and time using T-SQL (never mind what a "capo" is ;)).  Consider a 10 year production DBA that doesn't know how to do a backup or restore even with his tool of choice mentioned on his resume.  Consider a DBA that has 10 years of "performance tuning expertise" that claimed to not know what a clustered index was because he never had to use one because he never worked on clustered servers.  Consider a Developer that can't count from 1 to some number in code.  Consider a Developer that can't join two tables to do an UPDATE and wrote a cursor instead.  And, yes... all of those things have really happened in the interviews I've conducted.

    Programmers and DBAs get paid a whole lot of money.  I wish people would stop making excuses for the folks that put buzzwords on a resume but  don't actually know anything about the job they're actually applying for and will be expected to do.  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.

    Either that or take up playing the guitar by ear and hope they get lucky. 😉

    --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 imagine those who were in a group or orchestra make better team players  🙂

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

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • Jeff Moden - Tuesday, August 15, 2017 9:38 PM

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

    Jeff Moden - Monday, August 14, 2017 1:22 PM

    I still think it's horrible that 20 out of 22 "guitarist" applicants we had don't know what a fret is or where the neck of the guitar actually is.

    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.

    To continue with the music simile, despite the fact that he had difficulty reading music, he knew a whole lot of "what".  He knew what frets were and what they were for.  He knew what the neck of the guitar was and how to use it.  He knew what cords were and how to play them.  He knew what sounded good and even knew the name of the common tool he used to help him play.  He was, indeed, brilliant in the music world.

    And, yet, if the job that I had open required someone that could "read music", I wouldn't hire him for that position because 1) he couldn't do the job immediately, 2) after he learned, he wouldn't be able to do the job as well as someone that had actually been doing it for 10 years, and 3) since he did have a couple of decades to learn it and didn't, probably wouldn't like the job if he got it because he avoided learning that basic requirement for a reason... he didn't like it.  Don't get me wrong... if I had an opening to take advantage of the skills that he did have, I'd do it.  But, first, I need someone with experience reading music that can do it very well right now.

    Compare that with some candidate that claims 10 years of being a production DBA or Developer and doesn't know how to get the current date and time using T-SQL (never mind what a "capo" is ;)).  Consider a 10 year production DBA that doesn't know how to do a backup or restore even with his tool of choice mentioned on his resume.  Consider a DBA that has 10 years of "performance tuning expertise" that claimed to not know what a clustered index was because he never had to use one because he never worked on clustered servers.  Consider a Developer that can't count from 1 to some number in code.  Consider a Developer that can't join two tables to do an UPDATE and wrote a cursor instead.  And, yes... all of those things have really happened in the interviews I've conducted.

    Programmers and DBAs get paid a whole lot of money.  I wish people would stop making excuses for the folks that put buzzwords on a resume but  don't actually know anything about the job they're actually applying for and will be expected to do.  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.

    Either that or take up playing the guitar by ear and hope they get lucky. 😉

    Sounds like we are in agreement!  No doubt, one who is good at doing interviews would flush out the "resume - fakers" fairly quickly - they do exist.

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

  • "Programmers and DBAs get paid a whole lot of money. I wish people would stop making excuses for the folks that put buzzwords on a resume but don't actually know anything about the job they're actually applying for and will be expected to do. 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."

    Interesting first statement about 'a whole lot of money'.  It' all relative.  True, there are some, and I've known them, who are paid more than they are worth.  Same with management. 

    Anyway, back to my thought:  I found that honesty was always best.  And knowing that if you set expectations lower, you look better.  One interview in particular I was asked if I knew a certain programming language.  I didn't, so my response was 'No, I don't, but I can guarantee that by the time I begin this position I will know it.'  Got the offer, and by the time I started, I had bought the language compiler, had been through two books on how to develop with the language, and immediately began to support the systems for a technical department at my new company.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • Andrew..Peterson - Wednesday, August 16, 2017 8:33 AM

    Jeff Moden - Tuesday, August 15, 2017 9:38 PM

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

    Jeff Moden - Monday, August 14, 2017 1:22 PM

    I still think it's horrible that 20 out of 22 "guitarist" applicants we had don't know what a fret is or where the neck of the guitar actually is.

    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.

    To continue with the music simile, despite the fact that he had difficulty reading music, he knew a whole lot of "what".  He knew what frets were and what they were for.  He knew what the neck of the guitar was and how to use it.  He knew what cords were and how to play them.  He knew what sounded good and even knew the name of the common tool he used to help him play.  He was, indeed, brilliant in the music world.

    And, yet, if the job that I had open required someone that could "read music", I wouldn't hire him for that position because 1) he couldn't do the job immediately, 2) after he learned, he wouldn't be able to do the job as well as someone that had actually been doing it for 10 years, and 3) since he did have a couple of decades to learn it and didn't, probably wouldn't like the job if he got it because he avoided learning that basic requirement for a reason... he didn't like it.  Don't get me wrong... if I had an opening to take advantage of the skills that he did have, I'd do it.  But, first, I need someone with experience reading music that can do it very well right now.

    Compare that with some candidate that claims 10 years of being a production DBA or Developer and doesn't know how to get the current date and time using T-SQL (never mind what a "capo" is ;)).  Consider a 10 year production DBA that doesn't know how to do a backup or restore even with his tool of choice mentioned on his resume.  Consider a DBA that has 10 years of "performance tuning expertise" that claimed to not know what a clustered index was because he never had to use one because he never worked on clustered servers.  Consider a Developer that can't count from 1 to some number in code.  Consider a Developer that can't join two tables to do an UPDATE and wrote a cursor instead.  And, yes... all of those things have really happened in the interviews I've conducted.

    Programmers and DBAs get paid a whole lot of money.  I wish people would stop making excuses for the folks that put buzzwords on a resume but  don't actually know anything about the job they're actually applying for and will be expected to do.  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.

    Either that or take up playing the guitar by ear and hope they get lucky. 😉

    Sounds like we are in agreement!  No doubt, one who is good at doing interviews would flush out the "resume - fakers" fairly quickly - they do exist.

    "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?

Viewing 15 posts - 46 through 60 (of 63 total)

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