Every DBA interview I've ever had, what they actually wanted was "master of all trades", but what they'll settle for is "jack of all trades, master of the ones that really matter the most". Of course, what "matters the most" is subjective.
Most employers seem to want at least familiarity with the common aspects of SQL Server. Very few will care if you're familiar with CLR integration, since (per MS) only about 3% of the installations of SQL Server even use that. Every single one of them will want to know that you can run a backup and restore a database from a backup. If they don't care about that, then it's even more important that you know it well, because they're probably not backing up their databases and don't realize that's a problem.
So, know these areas at least enough to get by:
Backup/Restore (point-in-time through the GUI is good enough, scripting is nice, but nobody will actually care HOW you do it, just that you can)
Database corruption, at least how to detect it and some vague idea of what it is
Performance tuning, minimally you should be able to tell what just brought the server to its knees so you can tell a dev what to fix, and some of the most common performance-killers (cursors, bad/missing indexing, views nested in views nested in views nested in views ..., pick your top 10 all time favorites)
Normalization, even if you can't recite the levels, memorize "the key, the whole key, and nothing but the key, so help me Codd" and know what it means
For extra points, know the differences between temp tables and table variables
If you know at least those things, call yourself a Junior DBA, and you'll be honest. Know those well, and a few other areas reasonably well, and you'll be a Mid-level DBA. Common bits on that might be:
Expand out knowledge on all of the above till you understand them, the pros and cons of options on them, and have some experience in each
Know what traces and extended events are and have some familiarity with them, even if not mastery of them
Replication/Mirroring/Log-shipping and other DR/BC concepts; minimally, know what a "co-location" is and what it's for
Some level of server architecture: Clustering, virtualization, SAN vs local disks, how parallelism relates to CPU cores and threads, RAM options (AWE, 64-bit, etc.), and what an I/O channel is; Not mastery of this, just aweness of these things and some idea of what they mean in the world of databases
More advanced performance tuning
Senior level DBA is a subject of a lot of debate, but what it usually boils down to, for most employers, is the ability to do all the above things reasonably well, and the ability to educate others on them. Can you explain to a dev why his recursive UDF with nested cursors is a bad idea? Can you tell the IT server admins why SQL Server shouldn't run under Network Admin privileges AND be exposed through the firewall at the same time? Can you cleanly behead a dev who creates SQL Injection vectors in public-facing web pages without getting blood-splatter on your boss' suit? That kind of thing.
Of course, there is one other version, which is "Mega-Authority DBA". This is the guy who can spout all the latest buzzwords, can obfuscate why the databases are both corrupt and have no backups so well that the managers give him a raise when the database goes down, and has everyone in the company running and hiding whenever he walks past because they're so intimidated that they don't care that all the databases perform like continental drift and are only accurate when measured by how many parsecs the data is off by.
Pick which you want to aim for, and go for 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