I'm sorry to say there isn't a big enough facepalm emoticon for the current state of job advertising in our industry.  You're competing with employers looking for the most bang for their buck, HR firms/departments who know as much about tech as most techies know about oil rig equipment, local laws regarding job duty requirements, Visa (not the credit card) Renewal laws, and consulting/hiring firms who know more buzzwords then technology.  They've had more practice at this then you probably have, and it can be difficult figuring out what's good and what's not.

Let's review a concept I brought up in my previous article before we get started.  For SQL Server, there's 5 general areas of work: Administration, T-SQL Development, ETL, Reporting, and Architecture.  In most of these cases, you end up blending a few of these areas together, but a solid, 40 hr/week position is going to concentrate on one of these and incorporate a little bit of some of the others.  For example, reporting will need some T-SQL and some ETL.  Architecture requires a basic understanding of the other four.  ETL will probably require a little architecture to build staging structures and some T-SQL to optimize some tasks. 

What we don't want are two jobs, unless it's clear they're not simultaneous.  Being an architect for a project, then being the developer, then being the ETL coder, then doing the reporting... sure.  All four at once?  The first question you should ask in the interview is: "How big is the team I'm leading?"

So, how do you read a job posting to figure out what they're actually interesting in?  Well, I always start with the position overview.  This is the English version of the position, and is most likely written by the manager in charge of the position (after a little rewording by legal).  This means it's usually non-technical, and is you're best chance to infer the technical aspects and the human expectations required for the work by the person who's expecting you to do it.

Some good examples:

Let's start with the good examples, then go from there:

That's short and to the point.  They're looking for a senior so, unless they're overreaching for expected future need, they need someone who has a large volume of experience in the desired realm.  They mention clustering, replication, and performance tuning in the header.  You know what they're after.  The skillset is reasonable, if specific and reasonably high end.  They repeat themselves (VLDB and 5TB), but that's not uncommon for a jobsite because of keyword repetition.  From the skillset requirements you'll be working in a larger team getting the data warehouses fed, and they've got a lot of data moving.  They'd also like some skills with SSAS and SSRS to complement the primary duties.

This is an example of a good, high end position.  There's plenty of work in the primary duties, and they've got some BI work they'd like done (AS/RS) in the downtime if they can find the mix of skills.

Here's another good one, for a midlevel person:

They say senior, but the requirements list isn't really deserving of needing someone of that skill level.  40+ SQL Servers up to 600 gigs.  Alright, I'll agree with the original request that you need to know what you're doing, but again, a level III might be overpaying.  I would certainly apply for this job as a medium - strong II.  All of these tasks are centered around an administrative role.  Code Rolls, on call support, troubleshooting, some architecture for design, T-SQL to find problems and optimize, SSIS and error handling to deal with overnight failures, backup, recovery, and optimization.  Heck, this is about as perfect a laundry list of what any DBA past a junior should expect to do.  Volume of problems is the only thing that might take this up a level III requirement, just because they're better and faster... and more expensive.

As our final good example, a Junior/low-Mid role:

Here's one I could see as good for a self-trained Junior who knew what they were about.  You'd have to be pretty strong in SSIS, SSAS, and SSRS to cover the 3+ years role, though.  I say this is a good one for Juniors for two reasons.  One: it's aimed at a specific realm of knowledge, business interaction and data analytics/BI, with SSIS as an add-on.  They appear to be wanting to expand into that section, so demands may not be outrageous for a new person.  Two: it's a short term contract where you can get your professional feet wet as part of a directed project, as long as you can carry your own weight, with an opportunity to hire.  Both sides get a chance to check each other out and make a decision down the road.

I could be wrong, this might be too advanced for a Junior level employee.  It's certainly worth the time as one to make the inquiry, however.

Some problematic job opportunities:

Now, let's take a look at a few usual problems with job postings.  I'm going to walk you through a horrendous posting so you can see how a number of little problems can snowball into a mess. My hope is this longer evaluation will help walk you through how to think about a position you're reviewing when it's advertised.

Let's start with the title... what is a SQL Server Engineer?  They don't define it below, and it's a non-standard term.

The overview is pretty generic, looking at the list of requirements they ask for afterwards.  You're working with App, Web, and Network developers/administrators on multiple DBs.  They need you to supply robust and redundant HA Clusters.  So far, so good, we're certainly in the realm of an Administrator.  On call is nothing new for a DBA.  They're also looking to hire a new team lead instead of promoting from within, at least the way it's phrased.  That's a warning sign.  You're going to either get a group of hungry young pups looking for a mentor, or you've got some folks with knowledge and ability who were passed over.  The latter can be problematic.

Looking at the list of duties at a quick glance... ho boy.  Alright, SQL 2k5 and 2k8 administration.  No details, so assume you've got the end to end duties from backup/restores to tuning to clustering setups to troubleshooting production volume issues.  Remember, they have already mentioned this is a large environment, but without numbers, so you have to guess what's 'large' to them.  I've hidden the actual companies posting these items so it didn't take away from the content, but this is a large regional power provider, so I'm going to have to assume this isn't a 10 server shop.

Next up is architecture and tuning for transactional and merge replication.  This involves an intimate knowledge of the databases if you're going to do anything but broad strokes of the brush.  Depending on the actual desires here, this is either feasible, or another job entirely.  A topic that would need to be discussed in the interview if this wasn't clarified further on in the listing.

Aid in development of multiple dbs for a laundry list of app types.  The first question that pops to mind is "Why do I care what apps are utilizing my stored procedures?  .Net or Silverlight, they're going to access by Proc and login... right?"  Another topic to discuss in the interview, both for the amount of 'aid' expected (that's 5 apps, at least, I'm expected to be developer for), and what involvement they expect from the DBA beyond a base understanding of the tasks and what belongs at SQL and what belongs at App layer.  Also, it will require intimate knowledge of the database's data layer that you intend to develop for.  This is getting to be more then a job for one person, and I haven't seen mention of that 'team' I'm leading yet or any managerial skills.

Will manage internal and external MS/SQL database security.  Okay, Managing server security, sure, it's part of being the admin, no worries.  Including WinNT login groups in the server's security, sure.  Being a network security admin?  That's not a standard set of SQL skills.  Yet another interview question to simply clarify what they mean by 'external' security.  My first assumption on this item is that it's just poorly phrased.

Utilizing Data Architecture skills for Warehouse, acquisition (whatever that is, I would assume ETL from external sources), archiving, and recovery planning.  Okay, we've got poor phrasing again here.  Needing architecture skills for Warehousing makes sense and keeping up with changing ETL requirements added to that as a secondary task makes sense as an entire position, depending on volume.  Archiving is either partitioning, which requires developer involvement to utilize well, or data-transfer and backup.  That goes with recovery.  So, we've got some administrative duties mixed up in our architecture list.  This might be reasonable, but it would require another interview question to clarify the expected volume of work required for the warehouse architectures.

Understand, document, and tune the databases.  Errr... ummm.... errr.... okay, all my comments about broad strokes and skipping the fine details go out the window.  They desire a developing, architecting-in-OLTP-and-OLAP, administrative-in-their-spare-time SQL lead on all their projects.  I haven't seen a single thing requiring management skills so far, so I'm assuming I'm not getting any staff.  I saw five forms of programming earlier, so working with the assumption that they've got an average of two unique development applications in each, I'll be supporting a minimum of 10 applications as a developer.  In the meanwhile, I'll be supporting Replication (Merge specifically being a royal pain, because of data collision maintenance) to the warehouse, while optimizing all of the system.

That's around 4 real positions if you're planning a good solid 40-45 hour workweek, especially if they're overwhelmed at the moment, which is when you usually need to hire someone like this because your staff is now threatening mutiny.

At this point, if the job description stopped right here, I might make the phone call to find out the size of the environment and if all applications were in continuous sprint or if there were only two or three teams doing projects at a time across all the apps, find out how large the existing team is, things like that. It doesn't, though.  It just keeps going...

They want policies and procedures documentation, monitoring (both setup and reviewed), SSIS development using best practices (which means, at least to me, don't slap it together and move on, you've got error controls, etc...), manage and champion Reporting Services (Champion... champion?  Why am I being hired to CHAMPION this?), which is a skillset in its own right having little to do with adminstration and optimization, and Sharepoint integration and deployment.

Wow.

A quick scan of the minimum qualifications is even more disconcerting.  They need a multi-location High Availability Disaster Recovery administrator.  Be independent but know when to ask the right questions: that's highly subjective.  In depth knowledge of partitioning: that strikes me as kind of random since they want a jack of all trades, but I could see it being needed.

This list of desires and expectations is far too large for any one person to handle, or even two.  The documentation and tuning alone can be a full time job by itself.  Reporting Services expertise with Sharepoint deployment expertise is a skillset all its own.  Add some SSIS development to that and you've got another full-time position.  The administrative duties they've listed along with monitoring, policies and procedures documentation, and tuning for replication are a third position.

I don't have a pole long enough to touch this with.  This was either a "Job for Bob" posting- they've got someone in house that covers all these things and they're just staying on the sunny side of legality- or they're trying to get the best they can for the cheapest price, throwing the laundry list of possible duties out there to try to get as much as they can in one person, and they'll take the best of what applies. 

Now that I've showed you how I walk through the overview and the qualifications/duties listings for both good and bad jobs, let's take a look at a few more examples.

Let's show an example of the "Seeking MS SQL God".  There are a few of these out there, but you have to be able to recognize it.  A lot of these jobs are actually attempts to get more then they really need, like the above, and the extra 'requirements' are actually add-ons for your spare time, but they don't read that way and that can cause all sorts of hassle between you and a company's legal department.  One of the reasons for this is the company can point to the impossible job posting as a list of duties and fire you with cause for lack of ability to fulfill the duties of an impossible job.

My apologies for the inverted text on this sample, but I'm out of practice with my image manipulation skills and every time I tried to get this to invert, it looked worse.  *blush*

First, let's take a look at the overview.  Again, this is where the business or the manager gets to tell us what they really need from a generic standpoint.

The primary duties are administration related: rollouts, upgrades, installs.  We're good to go.  There's also some Business Analyst (or architect) duties involved.  They're looking for someone who is a jack of all trades, and likes it.  That's not a particularly unusual quality in smaller shops, so no red flags yet.  This is a great place to get involved for a year or two to decide if you want to explore other aspects of SQL Server in particular.

However, while the job responsibilities agree with the above concept, there's a LOT going on here.  I'll paraphrase a bit.

These pieces are pretty reasonable:

• Optimize SQL 2k, 2k5, and 2k8 views, procs and schema, while supporting DTS.  Note, that did NOT say SSIS.  Are you up on your VBScript?
• The following are on the same line:
• • convey application enhancement requests to programmers  :  Which means... what?  I'm first person in line for the business to discuss change requests?
  • and facilitate scheduled updates.: Of what?  I'm doing application rollouts, not just database scripts and updates?
• Support all departments with ad-hoc reports.  Depending on the volume this is actually somewhat standard for production support, helping the devs figure out if a specific piece of data fried the system.
• Maintain the import/export process.  This is either administrate the existing, or become a DTS/SSIS developer as well.  The difference is important, and goes along with item one regarding DTS.
• Support replication and Maintain replicated systems and disaster recovery. Sure, this is no biggie for an administrator.

Here's where it starts to go sideways:

• Develop new code.  Now I'm developing as well. Later they say: Work with app devs to support new code.  Hm, above you said I was developing.  Err?
• Maintain and develop scripts in Visual Basic.  Whoa whoa whoa.  I do SQL, Bub.
• Ensure a five nines system, flawlessly.  The actual requirement reads as: Ensure all developed SQL Server components function flawlessly in a production environment with stringent uptime standards. I wouldn't stake anything on this requirement until I had a month to work with the system to see what was going on before I got there.  If this isn't a 'nice to have' until you're quite sure of the system, this is a problem.  You have no idea what you've inherited.  The best you can do is try to guarantee your work won't break, and even then only if you're given the resources and time.  To add to that issue, this usually falls under teamwork between QA and the developers.  It landing squarely and solely on your shoulders should be disconcerting.
• Create and maintain documentation of all environments.  If they're not willing to give you ~20-25% of your work week dedicated to this, expect documentation to fall out the window.  It's always asked for, but rarely prioritized.

The last item that worries me is under the Qualifications, because it's legalese for we're screwed and need you to work late:

• Personal sense of urgency and proven business acumen

Now, nowhere in this description does it describe the size of the environment.  It's also posted by a consulting/headhunter firm, so they've hidden the client.  I can make no guesses as to the real client's needs here.  On paper, that's a lot of work.  If it's 4 or 5 applications on 6 servers, 3 of which are clustered failovers and one's the warehouse this is a great job to get involved in all the moving parts of SQL Server.  If it's much bigger than that, especially on the number of applications you're supporting, this can go from intense to ridiculous rather quickly.

This is worth an interview, but only because the overview shows a reasonable expectation of work as an administrator with an explanation of the rest of the requirements being a secondary item.  At least, that's how I read it, even if it's not said in so many words.  Without that overview, I'd be very leery of this position, especially with the random bit about Visual Basic scripts.  Mind you, I know a lot of SQL folks who know how to do scripting on the side.  That doesn't mean it's usually part of their job tasks.  Most high end db folks know some form of batch creation, but not all of them, and it's usually not more then Windows scripting.

Summary

As you can tell, there are a lot of things to consider when you're reviewing job opportunities, and there are different ways to read the same phrasing.  Unfortunately, due to length, I realize I've left out many examples of other things I've seen and found along the way.  There is no "right" way to understand a job description.  The exact same listing for two different companies can be the difference between a fulfilling job, doing a little bit of everything at a small firm, to being overwhelmed at a larger one.  Buzzwords litter the area, but don't let that distract you from what they really need.  You have to learn to read between the lines, see what the business is actually looking for, and then evaluate yourself to see if you fit what you envision at that company.

You'll find some of my concerns in the listings were borderline.  I use the words assume, I guess, and I estimate a lot when reviewing any job posting.  These usually bring up concerns I would need to reverse interview to clarify, or try to find out more about the company to check my assumptions about the volume of estimated work.  When you see these borderline opportunities, a 10 minute phone call or email to the person, if available, is your best shot at clarifying the meanings before you spend a few hours doing the necessary tailoring to resume and cover letter.  You'll help the company make sure they're clear, and you'll have a better idea of whether you should brush up on your skills, or just walk away.

The last and final advice I can offer you when looking for work:  Don't give up, and don't be afraid to try to open doors.  Never lie about your skills, but show you can learn and how you research.  Very few people in our industry have all the answers, but we know how to find out the answer to the questions.  Sometimes the question just happens to be about the job itself, the only place you can get the answer is from the potential employer.  Take the time, make the call, be personable, and ask.  It shows initiative, it's another 'touch' with the interviewer or gatekeeper (think HR filtering), and you are better prepared to handle both the interview, and the job afterwards, if you're armed with information.

Good luck, I'll see you out there.