Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Hiring Guitarists Expand / Collapse
Author
Message
Posted Wednesday, July 10, 2013 8:22 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 12:49 PM
Points: 31,374, Visits: 15,842
Comments posted to this topic are about the item Hiring Guitarists






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1472416
Posted Thursday, July 11, 2013 12:44 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 15, 2013 1:27 AM
Points: 3, Visits: 27
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.
Post #1472451
Posted Thursday, July 11, 2013 5:21 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, September 11, 2014 12:01 PM
Points: 76, Visits: 232
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.
Post #1472508
Posted Thursday, July 11, 2013 5:28 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, October 7, 2014 6:53 AM
Points: 17, Visits: 49
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
Post #1472509
Posted Thursday, July 11, 2013 6:08 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 1:52 PM
Points: 35,847, Visits: 32,518
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1472531
Posted Thursday, July 11, 2013 6:23 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Tuesday, December 16, 2014 12:11 PM
Points: 771, Visits: 1,971
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 --
Post #1472541
Posted Thursday, July 11, 2013 7:09 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 15, 2013 12:17 PM
Points: 1, Visits: 12
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.
Post #1472560
Posted Thursday, July 11, 2013 7:55 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, December 18, 2014 12:55 PM
Points: 372, Visits: 989
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
Post #1472587
Posted Thursday, July 11, 2013 8:57 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, December 23, 2014 2:22 PM
Points: 2,672, Visits: 4,103
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.
Post #1472629
Posted Thursday, July 11, 2013 9:51 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 15, 2013 3:19 AM
Points: 22, Visits: 64
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.
Post #1472670
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse