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