Where are the good Senior Level DBA's?

  • Tim Parker (10/15/2010)


    I believe the industry as a whole may place too much emphasis on the years of experience, versus the actual aptitude of the individual they are interviewing. By putting the scenario exercise in place during the interview process, this bias can be erased from the industry.

    Bingo, this and certs are an issue.

  • Tim Parker (10/15/2010)


    That hits the nail on the head. I agree with you 100%.

    I personally feel that I get discriminated against because of my time in grade as a SQL Server DBA. I have been exposed to a lot of facets in the world of SQL Server, and feel like I have a decent skill set. I've had a recruiter tell me that due to my 4 years experience, I did not posses the edge that the more seasoned (aka. 7+ years experience) SQL Server DBA's had. I told him to put me up against one of your seniors and I will show you what I can do.

    I believe the industry as a whole may place too much emphasis on the years of experience, versus the actual aptitude of the individual they are interviewing. By putting the scenario exercise in place during the interview process, this bias can be erased from the industry.

    In my little corner of the world, this has atleast been my experience.

    Write articles for sites like this one. Once published, put it on your resume. You may be surprised how big an edge "being published" can give you, even with a dearth of years. Then prepare to dazzle with tech screening answers.

    I just finished job hunting a few weeks ago. I got 6 interviews in one week, and every single manager mentioned that having published articles mentioned right near the top of my resume was one of the key reasons they wanted to interview me. Got me past a lot of people who would otherwise have rejected my resume because I don't have a degree.

    And in every interview, I made sure I didn't give "stock" answers to the technical questions. Give memorable answers. (This works best if your memorable answers are accurate, of course.) Never brush off a question. Even the standard "what's the difference between table variables and temp tables" can make you memorable if you can quote some data about "there are DBA urban legends that table variables are faster because they're stored in RAM, but Microsoft says...". The other twenty people who interview will give the stock answers, half of them will give the wrong data. You say something accurate, memorable, and that shows a deep understanding of the subject, and you'll stick out in the interviewer's mind.

    You don't have to be memorable on every answer you give. You just have to be memorable at least once. Marketing research shows that most people can only keep the top three brands in mind when asked about any given product, and it'll be based on "flash", not "substance". You are the product that you're selling, and your answers and conversation are your "flash". People will even misattribute positive qualities to the most recognizable/memorable brand name, even when clearly advertised about a less well-known brand. (Works conversely too. People will read a news article about a problem with an Apple product, and will answer that it was about Microsoft if asked about it the next day.) This doesn't work as well with people who are themselves experts on the subject, but still applies.

    Engage the interviewer in a conversation, and not a dull, routine one. Nobody will remember the DBA interviewee who says that "there are three types of backups: Full, Diff, and Log", they will more likely remember the guy who says, "there are three main types of backups: Full, Diff, and Log. Did you know that SQL 2008 can natively compress backups, and that it's actually faster when they do that on most servers? I/O is more of a bottleneck than CPU, so the extra work the CPU has to do to compress the backup is more than made up for by the reduction in I/O bottleneck because you're writing less to the disk. Kind of cool, isn't it?" Even better yet, "Full, Diff and Log. Have you had a chance to try out the new backup compression in SQL 2008?" That lets the interviewer engage, instead of just listening to you ramble.

    When they ask if you have any questions, at the end of the interview, ask "Am I leaving you with any questions or concerns about my ability to do the duties of the job?" Clear anything up at that point.

    I followed those rules, and I got offers from all 6 companies I interviewed at. Your milleage will vary. But do try it.

    - 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

  • GSquared (10/15/2010)


    I'm a performance tuning expert, and last I heard, profiling is politically incorrect.

    You made my day 😀

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
  • Senior DBA is a title. That's all it is. Companies have job titles for each position. Regardless of whether it is called Senior DBA, Lead DBA, or Super DBA...it usually just means the one who's been at the job longest or the most knowledgeable. It only relates to that company and the co-employees.

    However, it can give a starting place in an interview. I worked for a company where my job title was Senior DBA. Was I the senior DBA - yes - I was the ONLY DBA. Was I an experienced DBA, no way, it was my first job after I got the training. But I was a Senior DBA.

    Just because someone's resume says their job title is Senior DBA doesn't mean their experience matches.

    But another thing to consider, someone who has 7 years of experience could be a 'senior' DBA - it just might be in SS2000. So saying a person isn't a 'senior' DBA because they aren't a guru in SS2008 really isn't fair. Not every company upgrades to the greatest and latest.

    Anyways....names can mean anything - that's why interviews are done.

    -SQLBill

  • To add to SQL Bill's point, nobody is going to put "Junior DBA, 10 years" on their resume, even if that was their job title that whole time.

    - 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

  • "Anyone doing a backup/restore with SSMS wizzard will have a (very) bad point (unless he uses it just to generate the script, then he's lazy -> good point)."

    What is wrong with right clicking and restoring through SSMS? The whole idea of using it to generate a script which is seen as a good point is beyond me i'm afraid.

    Why would you need to use a script if you can do it through the provided interface? Obviously there are lots of occasions where you need to use a script but simply restoring a database is certainly not one of them.

    Or are people just being elitist?

  • I think there's a little elitist mentality, but someone ought to know how to do this in scripting. It's much more efficient, especially when you start getting lots of logs to restore. Or you want automation.

  • Couldn't agree more Steve.

  • Steve Jones - SSC Editor (10/19/2010)


    I think there's a little elitist mentality, but someone ought to know how to do this in scripting. It's much more efficient, especially when you start getting lots of logs to restore. Or you want automation.

    Maybe, but if you've been asked in an interview to do a single restore, I don't see that it's unreasonable to use the GUI to do it. If the question explicitly asks, "Restore a database in the way you'd do it if you had a dozen restores to do" then I'd see your point. To my mind, if you have a GUI then you should be allowed to make use of it; if they're expecting you to work entirely without it then they should fire up SQLCMD and expect you to know the correct command to get the list of databases on the system!

  • paul.knibbs (10/20/2010)


    Maybe, but if you've been asked in an interview to do a single restore, I don't see that it's unreasonable to use the GUI to do it.

    Absolutely. It's how I'd do it for one restore. Faster than typing backup and database file names, especially if it's a system I'm not familiar with.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • paul.knibbs (10/20/2010)


    Steve Jones - SSC Editor (10/19/2010)


    I think there's a little elitist mentality, but someone ought to know how to do this in scripting. It's much more efficient, especially when you start getting lots of logs to restore. Or you want automation.

    Maybe, but if you've been asked in an interview to do a single restore, I don't see that it's unreasonable to use the GUI to do it. If the question explicitly asks, "Restore a database in the way you'd do it if you had a dozen restores to do" then I'd see your point. To my mind, if you have a GUI then you should be allowed to make use of it; if they're expecting you to work entirely without it then they should fire up SQLCMD and expect you to know the correct command to get the list of databases on the system!

    Every DBA wannabe can use the GUI to restore a DB, sadly, way less can write down the 5 words and 1 path script for a simple restore, the whole point of the test is to see what you can do and your objective is to show it to me.

    I don't expect you to work without the GUI (intellisense make things quicker to write) but without some of the wizzard.

    Sure you can use the GUI all you want, but in an interview you should show you know exactly what to do and not rely on a wizzard.

    It's a little bit like the FizzBuzz test, i'll ask you to do it up to 100 but i expect you to do something that'll work for millions of rows, all i want to know is how you work.

    I'll never expect you to know all the syntaxes, i'll even be happy if you open the books online in front of me (so i can see how you find stuffs in it), but i do expect you to know how to spit out a simple restore script (no move, no force, no stripe, one backup file and no backup device) at a moment's notice, even if you have a few typos in it.

  • I think there are better ways of determining if someone is a wannabe DBA than with something as simple as a restore command, to be honest, but if it works for you there's little point in arguing otherwise! 🙂

  • Oliiii (10/20/2010)


    paul.knibbs (10/20/2010)


    Steve Jones - SSC Editor (10/19/2010)


    I think there's a little elitist mentality, but someone ought to know how to do this in scripting. It's much more efficient, especially when you start getting lots of logs to restore. Or you want automation.

    Maybe, but if you've been asked in an interview to do a single restore, I don't see that it's unreasonable to use the GUI to do it. If the question explicitly asks, "Restore a database in the way you'd do it if you had a dozen restores to do" then I'd see your point. To my mind, if you have a GUI then you should be allowed to make use of it; if they're expecting you to work entirely without it then they should fire up SQLCMD and expect you to know the correct command to get the list of databases on the system!

    Every DBA wannabe can use the GUI to restore a DB, sadly, way less can write down the 5 words and 1 path script for a simple restore, the whole point of the test is to see what you can do and your objective is to show it to me.

    I don't expect you to work without the GUI (intellisense make things quicker to write) but without some of the wizzard.

    Sure you can use the GUI all you want, but in an interview you should show you know exactly what to do and not rely on a wizzard.

    It's a little bit like the FizzBuzz test, i'll ask you to do it up to 100 but i expect you to do something that'll work for millions of rows, all i want to know is how you work.

    I'll never expect you to know all the syntaxes, i'll even be happy if you open the books online in front of me (so i can see how you find stuffs in it), but i do expect you to know how to spit out a simple restore script (no move, no force, no stripe, one backup file and no backup device) at a moment's notice, even if you have a few typos in it.

    Why?

    Maybe I'm the exception, but I don't spend a significant portion of my time running restore scripts on a day-to-day basis, hence I haven't bothered to even begin to memorize the syntax. I can read it out of BOL and type from scratch, but what I'm more likely to do if I need it, is open up the wizard, build the basic restore I need, click the "Script This" button, and then modify the resulting script, while confirming my modifications in BOL.

    I have scripts in my daily backup jobs that test the backups for me. Every backup gets a test restore. I wrote those scripts years ago and haven't touched them since. They do the job I need.

    Does the fact that I do my work in that fashion, which I find significantly more efficient, make me a non-Senior DBA?

    I would expect a newbie DBA to be able to run a restore from the wizard. I would expect one to be able to read BOL and piece together a restore script of the sort you're describing. I would expect a senior DBA to be able to explain why you use certain restore options, when to use them, and what the differences are between them. I'd expect a senior DBA to know that checking the "test after backup" option isn't anywhere NEAR adequate to be sure your backup is restorable, and why, and what to do to make sure they really are restorable.

    I would expect a senior DBA to know that a "backup plan" is essentially useless, since backups are pointless unless what you really have is a "recovery/restore plan", with backups as a reasonable part of it.

    But being able to type up a restore command out of BOL as a test to see if someone is a "senior DBA" or not? That makes no sense to me at all.

    - 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

  • I think not respecting a DBA that uses the GUI is an old DBA thing. In SQL 6.5 and to a lesser degree 7.0 (and earlier) the GUI was very unreliable so DBA's of this generation didn't trust it and didn't trust DBA's that seemed to trust it. I write scripts that "discover" everything I need to know about a backup. All I need to know is the database name and the bath to the backup. I seldom use MSSQL backup anymore because third party tools make good use of scripting as well. I have been a SQL DBA for over 13 years and I still use BOL for things I don't do on a regular basis, I go use the GUI for attaching databases though and give MS high marks for how easy that part of the GUI is to use. I use to use the GUI for replication while I was working on making scripts to do it, as the only DBA in most of the companies I have worked for I have to make jobs so non-DBA's can make them work.

  • Oliiii (10/20/2010)


    Sure you can use the GUI all you want, but in an interview you should show you know exactly what to do and not rely on a wizzard.

    If you ask me in an interview to restore a single database from backup, I'll use the GUI cause it's the fastest way to do a single restore.

    If you ask me to put something rough together that could be used to schedule the restores of 20 databases every night, I'll write a script.

    Appropriate tool for the job

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

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

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