DBA Skills Checklist
After being on both sides of the recruiting & recruited fence, it seems like we need a simple, standardized checklist that DBAs and recruiters can use to quickly convey their skills and a job’s needs. I see this as a yes/no checklist that the DBA and the recruiter would fill out and score to see how close of a match the candidate is. Maybe we could even add a “years of experience” column.
Environment Size:
- 1-10 servers
- 10-100 servers
- >100 servers
- Databases under 100gb
- Databases 100-500gb
- Databases over 500gb
- Tables under 10 million rows
- Tables 10-100 million rows
- Tables over 100 million rows
- Single DBA working alone
- Worked in a team of 2-3 DBAs
- Worked in a team of more than 3 DBAs
High availability:
- Clustering
- Database Mirroring
- Replication
- Backups & restores
- Server monitoring (MOM, Tivoli, etc)
Performance tuning:
- Performance monitoring (Perfmon, Spotlight, etc)
- Performance tuning existing code (rewriting stored procs/views/etc)
- Index tuning
- Partitioning
- Triggers
- Storage tuning (RAID, SAN, filegroups)
Other skills:
- Data modeling
- SOX & HIPAA compliance
- Security specialists
- Application architecture
Other related products:
- SQL Server Integration Services (SSIS)
- SQL Server Reporting Services (SSRS)
- SQL Server Analysis Services (SSAS)
- DTS
- CLR programming with VB.NET, C#
That last group (Other related products) is tricky. My personal belief is that DBAs who work with the below tools are really specialized database administrators. They tend to create content rather than manage databases, and they’re a different breed. When someone says they’re a DBA, but they only do SSIS or SSRS work, then they’re more of a developer than a DBA.
I started this checklist earlier this year because I had some bad experiences with recruiters, and it wasn’t really their fault. In one case, a position was a perfect fit for me - except they wanted replication. I don’t have replication skills, and I shouldn’t go into a shop as their only DBA if replication is mission-critical to them. I can learn a lot quickly, but I don’t want to learn that particular skill the hard way. In another case, I was sold a “DBA” position interview only to find out I’d really be writing SSIS/DTS packages. Ugh.
What would you add to the checklist that would determine whether or not a DBA was right for a job?