Hiring Guitarists

  • Comments posted to this topic are about the item Hiring Guitarists

  • Seems pretty straightforward: During the interview process give the applicant for the senior position a challenge such as you have faced in the past. Which parameters do they check first? What references do they consult? Once they reply, respond with a little more information--just as you learned from experience as it unfolded. How do they respond? Did they make the same mistakes you made when you were in the situation? Do they have novel insights or testing/programming methods? I use specific scenarios, based on personal experience, for each: network, database, programming, and people management skills--these seem to work well. Since these were real-world experiences, I gain insight into thought processes, as well as how candidates handle frustration with stymies--since each of the scenarios unfold in about 6-7 iterations, and become seemingly more and more intractable with each step. I prefer doing this as part of the oral interview rather than some grand technical closed door challenge.

    Think back to your greatest challenges at work, I am sure you will remember a few doosies...if you haven't had any of your own DBA experiences and you are hiring a DBA, I really think you should consider outsourcing.

  • Depends on the nature of the DBA: is it a production position, or a development position? I've never been or known anyone who would (or even could) do both. The vetting is different. The work is different. For production, firefighting is what matters, and your particular fires, at that (the deep bowels your chosen engine are what matter). For development, it's much more about data structure, data control, and organizational commitment to relational principles. Lots of "database" shops use the RDBMS merely to hold flat files, while others take the time to actually design an integrated schema. The former let the client coders run the show, while the latter have the database developers do so. So, three different kinds of DBA, none compatible with the others.

  • Hiring and firing are the two worst parts of a supervisory position in my opinion. I never really liked doing either for all the reasons pointed out in the post. Some people have an amazing ability to interview really well and then not live up to the impression they gave in the interview. I think it is kind of like people that test well in school but don't really know how it applys in real life. I was also intrigued by the comments about wanting the senior person to point out mistakes and help with decisions. Especially liked the support when I choose to continue to make bad decisions. I am that person, I will tell you that you are making a mistake in a heart beat however I have found that a lot if not most people don't appreciate that and it is a quick road to getting fired or put in a position of very little influence. So that being said I think you need to tell the person up front that you expect that from them and that the results won't be disasterous to them. Most may have experienced bad results in the past and have made the decision to keep their head down. It could even be the reason they are available for you to interview them. Communication of expectations and truth are required when interviewing and ultimately hiring someone so that neither of you are disappointed.

    .02,

    DG

  • RobertYoung (7/11/2013)


    So, three different kinds of DBA, none compatible with the others.

    I absolutely agree that's true in most cases. However, some of us do wear multiple hats as "Hybrid" DBAs. Where I work, I'm the System DBA, the Production DBA, the Lead Database Developer, and one of two database designers and I do a pretty good job at all 4, if I do say so myself. 😛

    Shifting gears a bit, I think that hiring the right person as a DBA is actually easy compared to some other jobs. Usually you "just" need the proverbial guitar player when hiring a DBA. The most difficult type of person to find in our area is someone that's really good on the front end and even "just OK" on the database side. To carry the example forward, you need a guitar player that can also sing and actually hit the right notes. So many of the folks that we've interviewed for front end development positions can't even write a decent SELECT with a single join never mind doing something "complex" like a "joined UPDATE".

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

  • My sense, from reading his article, is that the difference between the senior and the competent levels has much less to do with technical knowledge and much more to do with experience, judgement, people skills and maturity.

    If you're picking a guitar player for a concert series, getting someone who can play proficiently is only part of the problem (there are plenty of those). You need someone who is reliable, consistent, emotionally up to the rigors of the road and nightly performances, someone who will reduce friction among the band members and not drag in issues of his own. In short, you need the same characteristics as the senior dba.

    I might add, that there is really NO way to test for these characteristics for either the guitar player or the DBA. You can rule out obvious clunkers, but a trial period is the only way to see if you're a good fit.

    ...

    -- FORTRAN manual for Xerox Computers --

  • Compentency aside, I think the only real test is on the job and under fire. My take is you'll really have to settle for verified credentials and compatiable personality keys. The response you recieve from employees will be the response you illicit. If an employee perceives that you are open to debate, the employee will likely speak up if they see something questionable. If your response is defensive, curt, or non-receptive-- or if there is a debate and you are proven correct, but become condescending in response to the attempt to debate, there will be fewer and fewer future debates.

    Work relationships are developed over time. It's unlikely you'll be able to determine what a future relationship will be during an interview and hiring process. We all are on our "best behavior" during the interview and hiring process. If you're not getting what you want from senior, qualified people then look carefully at your interactions with these people.

  • Sometimes people show their flaws early on and sometimes they develop over time. I've worked with plenty of people that have turned in to real jerks over a lengthy period of time. This article has a managerial tone so I'd say to forget about the inspire me this or that and expect those who you manage to follow rules/best practices and policies and above all, just do their job and do it well. Control freaks are bogged down by standing over the shoulders of those they manage. Do your best to hire good people and let them do what they were hired for. If it doesn't work out then handle it. I have a very good manager in that he does not micro manage and yet is never distant from a situation. He gets it - if he wanted to do all the work then why would he need me?

    Cheers

  • RobertYoung (7/11/2013)


    Depends on the nature of the DBA: is it a production position, or a development position? I've never been or known anyone who would (or even could) do both. The vetting is different. The work is different. For production, firefighting is what matters, and your particular fires, at that (the deep bowels your chosen engine are what matter). For development, it's much more about data structure, data control, and organizational commitment to relational principles. Lots of "database" shops use the RDBMS merely to hold flat files, while others take the time to actually design an integrated schema. The former let the client coders run the show, while the latter have the database developers do so. So, three different kinds of DBA, none compatible with the others.

    This may be true in large organizations where roles are well defined and are placed in their own silos. I have always worked in small organizations wearing many hats.

  • If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.

    So if you were hiring a sound engineer: They need to be demonstrably proficient, experienced and reliable. If they need to be performers or songwriters too then that's a strange set up and they will need qualities that might be diametrically opposed to those. Drummers and bassists also need to be especially reliable and not inclined to show off. I don't think you want a singer or lead guitarist doing the sound levels or lighting: their egos would get in the way.

    Sound engineers (DBAs) need to be able to lay down the law to the band (managers, sales and development) at times but still working with them to achieve the desired effect ("if we turn the guitars up any more it'll drown out the vocals and we'll start getting feedback. maybe we could layer the direct guitars with an aux send to get a bigger sound without making it louder"). I expect all the great bands had great sound engineers.

  • Vila Restal (7/11/2013)


    If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.

    And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.

  • When I interview people, I always ask somewhere during the interview if they play a musical instrument. Even if they say they dabble in tuba or oboe, that for me is a plus. I cannot explain it; but they usually make better decisions and are more flexible in finding solutions. I think it has to do with the mathematics of music and the improvisation skills from playing with others.

  • RobertYoung (7/11/2013)


    And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.

    I consider that a narrow view.

    I'm a production DBA. I need to know how to troubleshoot production data at both the DB/OS interaction level and what is a bug in the SW. My last company used primarily delivered SW. I found a bug that the delivered SW failed on the INSERT statement but the UPDATE statement worked.

    My current company is/was a SW producer. On the production end I still needed to know when the end-user failed versus a failed stored proc that I had to report as a bug.

    But at the same time I've done development work. So I know that sometimes the DB should be flat, or whether to build it in.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • RobertYoung (7/11/2013)


    Vila Restal (7/11/2013)


    If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.

    And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.

    I don't see why you would say that. Sound engineering is complicated, takes a lot of experience and isn't done to make the band happy: the sound engineer's duty is to the music and the listeners. Good sound engineers are hard to come by. The sound engineers you're thinking of are the jobsworths: just plug it all in, get the levels right, job done. (And in that sense the anology holds with the jobsworth DBAs.)

    If a DBA wants to be a 'performer' (strutting on stage) then I think they've picked the wrong vocation in life and I wouldn't want to hire or work with such a person as a DBA whatever the structure of the database.

  • Senior DBA's must be able to work under pressure while at the same time always maintaining their cool. If they can't do that then they are not the right person for the job, plain and simple.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

Viewing 15 posts - 1 through 15 (of 63 total)

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