Junior

  • Apprentice

    I was listening to a recruiter talk to a user group a few weeks ago and the young lady presented a few jobs and requirements to the group, just to see if anyone was interested. Having a short discussion of open jobs is something that I think is a good thing at a user group to help networking, but that's not what caught my ear.

    Someone in the audience asked the question, which I thought was a good one, so I decided to appropriate it for a Friday poll.

    What's a Junior DBA?

    Actually, I'll be covering other levels in the next few weeks, senior then mid-level, so be thinking of that.

    So what makes a junior DBA? To me the low side is easy, it's the person that has no experience and may never have even heard of SQL Server before. This is the person that you start from ground zero.

    It's the upper end of this level, the stuff you think a junior should know, but after which you start to consider them a mid-level DBA, that's a little harder to quantify.

    I'd have to say that I think that a junior DBA is definitely anyone with less than a year of experience. Even if you pick up SQL and basic administration, you really need to spend some time working with the product for awhile. Just having time to discover problems, get asked questions, and poke around the product is necessary. So I'd say 0-2 years experience is the first criteria. Sometime between 1-2 years I'd be thinking that someone would move to the mid-level.

    Or wash out.

    On the technical side, someone should be able to install SQL Server, at least a basic installation. Since my 8 year old could probably handle this with a day of instruction, I'd certainly expect a junior DBA to do get that working. They should also be able to start SSMS/EM, connect to a server and check on job status, users, find a blocking connection and kill it, create a database, add a login and user, and grant permissions to a user or role. I'd also expect that they could write simple queries, including at least a 3 table inner join, understand what the WHERE and ORDER BY clauses mean. I'd expect basic aggregation queries as well, maybe one non-aggregated column along with the totals. I'd also expect a junior to be comfortable with using the import and export wizards.

    And I'd certainly expect the ability to backup (and of the 3) and restore a database from a full backup.

    Anything I'm missing?

  • If that's what you expect from a Junior, what do you call them if they can't even do those tasks? "Un-employed"?   

    The humouress version would probably be "general dogsbody", though I'd like to think of them as being someone who's training and with the potential to be a mid-level DBA.

    Note: this sort of separation could apply to any role in IT, really.

     

    PS: I'm no DBA, just a developer who's had to maintain the company's database because there's no official DBA.

    Paul

  • What do you expect from a real DBA then? Using a cross join?

  • These aren't necessarily the tasks a junior does on day 1, but they're the basic skills. And they apply to basic cases.

    Being able to find a blocking connection doesn't necessarily mean I expect them to kill it right away. Usually I'd have them find it, figure out who the person is and then contact them to find out what they're doing. They'd also grant permissions I told them to grant, not figure that out on their own.

    Lastly, if you did these tasks as an admin/developer, then I'd hire you in as a junior DBA. These are simple tasks and next week I was going to poll you on more senior levels.

  • Maybe this should be approached by determining the minimum knowledge necessary to be a mid-level DBA; someone that doesn't have that knowledge would be a junior DBA.  I would certainly expect a mid-level DBA to be able to write basic deletes, updates, stored procs and views.

     

  • Makes you wonder - what are the "Day 1" skills a Junior DBA should have?  I would imagine it's difficult to walk into a company anywhere and try to get any level of DBA job if you've worked only as a salesperson at the Gap, and your exposure to technology is limited to Cell Phone IM's and logging into AOL chat rooms.

    I'm no DBA myself - I'm a developer, but like Paul the line between developer/DBA gets blurred an awful lot these days

  • I have a few ideas about what a mid-level should know:  RAID, index tuning, virtual servers, load balancing, proper database design techniques (normal forms anyone?), security configuration and administration, T-SQL DDL and DML, the difference between declarative languages and imperative languages, maybe even some client connectivity info, etc.  If the mid-levels are teaching the juniors, then basically by mid-level it would seem they need to pretty much know it all

  • When I think of orgnizations that need DBA's I think of two types. 

    1. Orgs that use SQL with Apps they design and develop.

    2. The rest of them that use some App that runs on SQL.

    See,  most orgs are in 2.  Maybe the people that go to this fourm are more likely to be from type 1 orgs. What this means are DBA's are responciable for SQL to run as best it can with out any failures.  So RAID, backups, and general performance issues are at the top of the lists.  Then maybe they have to deal with problems that can only be fixed from a table level.  Finally they might need to modify or add to the DB's for reporting or other reasons.  But there not developers and not doing on a day to day basis what was mentioned by the editors post.

    Granted there are a lot of DBA's from type 2 orgs and then all those requirments start to makes sense. I aggree with a lot of people that Developers start to become DBA's in a lot of places because they don't want to pay DBA money.  To me the problem with this cirteria is  it only matters what type of org you work at.  Type 1 orgs pay DBA's to keep SQL running, backedup and patched.  They would be responcaible for SQL upgrades and security to some degree.  They may be wearing a dual hat admining the apps that use the SQL server or maybe not.  But a DBA from a type 2 org would most likely be more proficient using "advanced" features or tasks from a DBA from the type 1 org.  Maybe it's not fair that they share the same title and pay?   (actually type 1 might pay even more)  From enterprise enviornment most IT companies want DBA's and developers to be very diffrent.  So problems with the SQL past down situations are actually the developers problem.  Unless there also the devloper or admin for the app.  So being a DBA of whatever level is a cakewalk for those people.  They might have 10 or 1000 SQL servers to keep track of but if it's running slow it might fall on the developer to fix that.    

  • I'm a software developer and consider myself to be a database developer as well (as opposed to a db administrator).  As a developer, I'm comfortable doing the following tasks from Steve's list:

    §         Install SQL Server, at least a basic installation.

    §         connect to a server  

    §         create a database  

    §         write simple queries, including at least a 3 table inner join

    §         understand what the WHERE and ORDER BY clauses mean

    §         basic aggregation queries, perhaps one non-aggregated column along with the totals

    §         comfortable with using the import and export wizards

    I am not experienced with the other tasks on his list.  However, I'm also comfortable with db design (including data types, relationships and constraints) writing queries with complex joins (multiple tables), stored procedures, views, functions, triggers, .  Of course, inserts, updates and deletes are no problem either.

    Truth be told, I enjoy the db development work as much if not more than the software development work (which I also enjoy) and sometimes consider exploring the possibility of becoming a full-time (junior) dba, or even better, a full-time db developer (if such a position exists).

    I'd be curious to know if anybody, including Steve, had any thoughts about whether my current skill set would be in demand for one or both of these positions??? (I think this question ties in with Steve's original question).

    Thanks.

     

  • Excellent question!  The last company/boss I worked for struggled with this question.  I hired in as a Jr. DBA despite the fact I had 10 years of DBA experience.  The money was “decent” and I had other reasons for accepting the position.  In addition to myself, there were 4 other DBAs; 2 senior and 2 junior.  Within a few months, one of the other Jrs quit and I was given more responsibility with no promotion or pay increase.  The next year, one of the Srs and the other Jr were reassigned to another department and I was given more responsibility with no promotion or pay increase.  A year after that, they fired the remaining Sr DBA leaving me with ALL of the responsibility and no promotion or pay increase.  I was told they’d like to promote me, but that they’d expect more out of me.  When I asked what more they would expect, my boss said, “Well, I don’t know but I’d expect more out of you.”

     

    So, the answer to your question depends on who is asking.  A DBA expects a reasonable, logical, quantifiable answer.  A greedy, slave driving boss expects as much as he can legally coerce for the least amount of money.

    Take care,

    Bert

    "Speculations? I know nothing about speculations. I'm resting on certainties. I know that my Redeemer lives, and because He lives, I shall live also." - Michael Faraday

  • Chris,

    I think for sure you'd qualify as a junior DBA or be able to get hired as one.

    I'm sure that there skills are all over the board for some people, and I'd love to have more people give me an idea of what they consider is a junior DBA.

    Bert, you should get a raise after a few years and more responsibility or look for a new job. I'd be leaning towards a new job if the boss was seriously not recognizing your increase in skills and responsibility.

  • Bert,

    I worked for a company that treated its people that way. They were software developers, mostly. A lot of people got "promotions" that added the word "acting" to their title. For example, a "Programmer" would get promoted to "Acting Team Leader." The promotion came with the responsibilities of a team leader (which were mostly to do the dirty work and take the blame for upper mgmt) but no pay raise. I've seen people who were good programmers "promoted" to acting team leader, given incompetent subordinates, told to teach them to program, than given a lousy review for being a "bad manager" when things didn't work out so well.

    Very few employees stuck around for that treatment. Most quit the usual way, with two weeks notice--a few quit spectacularly. You know, throwing a screaming fit, saying, "I'm quitting" and then leaving. Never to come back. No desk clean-out, no notice, no status of what they're working on, nothing. And the rest of us just wished we could do that too...

     

  • Oh, that job is now just a distant night mare.  My only point was, the answer to your question can radically different, depending on who's giving the answer.  As for me, I think an established junior DBA should be able to:

    install and configure the database engine

    create databases and all objects contained therein

    set up logins and user and give them rights/permissions

    create routine maintenance tasks

    import/export data

     

    and begin branching out into the more complex features and functions of all of the above.

    Take care,

    Bert

    "Speculations? I know nothing about speculations. I'm resting on certainties. I know that my Redeemer lives, and because He lives, I shall live also." - Michael Faraday

  • Here is one further distinction to further muddy the waters, a development DBA versus a production DBA.

    What do I see the differences to be? Well first off you get to stop being schitzophrenzic and so do you. From a development point of view, generally designing databases (if there isn't a database architect), writing stored procedures, triggers, code, and some optimization.

    A production DBA keeps the box running, backups, disaster recovery, performance tuning, security (although this blends with development), upgrades/patches etc, and 24x7 on-call support.

    It takes a very large organization to support a database architect, developmet dba, and production dbas, so quite often you develop schitzophrenia, and so do you because you HAVE to support multiple functions.

    Just my thoughts,

    Brian

  • Thanks for the response, Steve.  It's good to know that I might have opportunities if I decide to go in that direction.

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

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