On Resumes

I have debated for months whether I should actually publish this post.  

I've finally decided to do it.  

--dave

In my role I'm often asked to do initial phone screens for potential job candidates.  I also have plenty of experience on the other side of the table/phone as the phone screenee.  This is going to sound like braggadocio, but...if I submit my resume to a potential client I always at least get a phone screen.  And there's only been a few times where that hasn't led to a face-to-face interview and an offer.  That's my street cred.  

I've never seen resumes as horrendous as the ones I've seen lately.  In this post I want to give tips for writing a better resume.  I won't regurgitate the same tired tips you'll find with a google search.  My tips are a bit more controversial, but they work...see my street cred above.  These tips are in no particular order.  All resume screenshots are from actual resumes (identifying information removed) for the following job title:  Experienced/Senior data development/architecture.  These aren't Jr DBA positions or internship opportunities.  These are good paying jobs.  

On with the tips. 

I've read that an employer will spend less than 15 seconds reading a resume.  

Bunk.  I spend less than 3 seconds reading a resume.  You have 3 seconds to either wow me or suck me into your world so that I want to read more.  A resume that starts off like this...

...gets discarded immediately.  Do you think I care that you have experience with three different versions of MS Office?  I don't.  And neither does anyone else.  

Unfortunately you *might* need those terms SOMEWHERE on your resume

Most recruiters and employers scan your resume using OCR into a candidate database and then search for keywords the hiring manager wants.  So you need to have these ridiculous "terms" (skills, languages, tools) on your resume to get past the automated gatekeeper.  But there are ways to retain the "terms" and get past the automated screening, yet not bore the human who will only spend a few seconds vetting you further.  There are simple solutions to solve this that I'll leave as an exercise to the reader.  Use your imagination.  (Hint...don't put your laundry list of "languages and tools" at the top.)

And don't use a "term" incorrectly because a recruiter said you need to have it on your resume:

Clearly our candidate wants to include "DDL" and "DML" somewhere on her resume.  However, it would be much better if you could tell me how you used DDL to retrieve data, otherwise I'll assume you don't really know what DDL is.  

If you read this far I'm going to give you my best tip...your resume should tell me a story

I lot of the screenshots of resumes in this blog post are boring.  Don't bore me.  Tell me a story.  Spin your work experience into something prosaic that I want to read.  Use fewer bullet points.  Here is an example of a resume that tells a story, albeit a bit boring:  

Here the candidate wanted to tell me about what the company did in the first sentence and her project in the second.  I don't need to know nor care about a global insurance company.  I'm not hiring the insurance company...I'm hiring YOU.  Here's how I would've written it:  

The lifeblood of Blah-Blah Insurance Ltd is accurate data.  I was brought in to improve the timeliness and quality of that data.  The existing OLTP systems were notorious for bad data.  By the end of my tenure I created an ETL architecture that scrubbed the data and gave the users confidence in the reports.  Here's how I accomplished that:  

• I worked with the BA's to gather requirements
• I designed a flexible ETL architecture with SSIS where...

This tells a story.  It is engaging.  The reviewer will want to read more.  

Listing years of experience

Take this first paragraph of a resume I've just been given.  

I spent LESS THAN 3 seconds reading this...honestly, I didn't make it past the third word.  I have a saying that I think I invented, but I probably heard it somewhere else:  

There are those with 7 years of experience and there are those with one year of experience repeated 7 times.

Listing your (recent) employment history will tell me your "years in the business".  I'll gauge your "years of experience" by looking for progressively more challenging work throughout your work history.  

A Quick Story on "Experience"

I worked at a Big Four as a developer around 2002.  One of the "server build jockeys" in the data center was tired of tracking server assets using spreadsheets so he created a website.  He had no experience with programming or webmastering.  He was 22...his first job right out of college.  People loved his asset tracking website and he was asked daily to add new features to the system, which he did.  Soon the feature requests were taking away from his time spent building new servers.  I was asked to look at his code, help him, and determine if we could pass this work off to a proper development team so he could focus on his real "bare metal install" work.  

His code was the most elegant code I had ever seen, especially from someone with no formal training or experience.  It was ASP.NET and since no one would buy him Visual Studio he wrote the code with Notepad and compiled it on the command line.  As they say, "the cobbler's children have no shoes"...often, people who develop the best software use the poorest tools to do the job.  

That's hardcore!

His code was so beautiful that I did not have a single suggestion for improvement.  Instead, I suggested that the firm find this guy a position on a real development team because his true talents were being wasted racking servers.  Everyone thought I was crazy...there was no way this guy could be this talented.  

Well, he soon quit.  He is now the chief architect for a mobile app that you probably have installed on your smart phone.  

He had ZERO years of experience when I had 10 years of experience, and he already showed more experience, maturity, and talent than anyone I've ever known.  

Moral of the story:  I don't care about years of experience and most GOOD hiring managers don't either.  

Avoid Fluff Words

Let's look at that sample opening paragraph again:  

Words like "extensive experience" and "strong experience" are fluff.  Too many very, very, very wordy adjectives here.

Is there really a difference between "T-SQL Scripts and Batches"?  Do you write them differently?  This entire paragraph is fluff and tells me nothing about what you did for 7 years.  

Another example:  

Wow.  Are there that many jobs requiring highly proficient knowledge of "Cursors"?  Also, I must assume you have ZERO knowledge of Views since you didn't bother to mention that, but did mention every other object type you could think of.  This is all fluff.  This resume is 4 pages of fluff.  

Your resume should never be more than 2 pages

If you're middle aged then you probably have a lot of positions, projects, and years to list on your resume which will take more than 2 pages, right?  Wrong.  Don't bother listing positions that are older than, say, 10 years.  The technology you used that long ago is dead anyway, unless I happen to be hiring for a COBOL guy.  If the average hiring manager spends a minute reading your resume, is it really worth anyone's time to have a resume longer than a couple pages?  

Less is more.   

You want to stand out as a candidate.  One simple way to stand out is to have a short resume with stories and fewer bullet points.  You'll be the only candidate with a resume like this.  

Spelling and Grammar

We've all read that a resume is tossed if there are grammar and spelling mistakes.  

Bunk!

I would never toss the resume of a good candidate just because there grammar was bad (oops, I meant "their"...or is it "her"?).  Lousy grammar is the nature of our cultural melting pot these days.  However, all things being equal, I'd prefer a candidate with good communication skills.  Here is a resume with horrendous grammar and spelling:  

But I'm much more concerned that this sentence took me a full 2 seconds to read and told me absolutely nothing of value.  Why only 10 tables?  Is 90 million "recorders" considered big to you?  Why SSIS?  Here's a rewrite:  

The Finance group had the difficulties in their runnings the reports on the OLTP system.  I created a simple star schema of 10 tables that they loved because it was easy to comprehend and manipulate in Access, Crystal, and Excel.  The largest table had 90 million recorders, which doesn't seem like much, but to the Finance group this meant reports could be generated with the most time-critical data in sub-second response times.  They really loved it when I showed them how to use the SSRS and the data cubes.  

It still has the same bad grammar, but I can overlook it.  

I'm not impressed with Big Numbers

People like to put Big Numbers on their resume to impress people.  Take this:  

Wow, I'm supposed to be impressed that you created over 60 reports.  That's just like "90 million recorders".  Instead, tell me why 60 was good?  Maybe the old COBOL system had 250 reports returning similar data, with redundant code and parameters, and you distilled it to 60.  That's far more impressive. Now I can understand your reasoning as a developer.    

I also see lots of resumes that tout Lines of Code, Numbers of Concurrent Users, Years of Experience, Sizes of Databases in Terabytes.  These are all big numbers meant to impress people.  They never impress me.  

A story about BigData

I once worked for an ISV that wanted to use SQL Express to avoid passing huge licensing fees to customers.  At the time the db size limit of Express was 4GB.  The challenge is how to make tiny 4GB databases look impressive to Big Corporate Employers:

As an ISV, MyCorp needed to keep every penny of revenue it earned.  Why should we share our licensing revenue with third parties?  My mandate was to squeeze as much data and performance as possible within the 4GB limit of SQL Express.  Instead of a BigData problem we had a SmallData problem.  I designed the database to be as storage-stingy and performant as possible:  

• I created an aggressive data archiving process which archived data to XML structures stored in FILESTREAM objects.  
• The data was dynamically sharded across multiple databases on the same Express instance
• We used Service Broker to...

I'm not impressed with your company or industry-specific buzzwords

Example:

I have no idea what NMR spectra data analysis is.  

How about telling me about the problem you were given and how you solved it?  Why did you use a macro?  Most folks would laugh at using a VBA macro to solve any problem, but I wouldn't.  I've been in situations where the circumstances meant your only choice was a VBA macro solution.  (It's actually a great story).  

Examples, Examples, Examples

This is so typical of what I see on resumes for experienced data professionals:  

Why are you excellent?  Why do I need someone with experience with SQL Agent?  Give me an example of something you optimized.  Here's how I might write it:  

Our application experienced periods of terrible performance and using Profiler I determined the cause to be processing that we could make asynchronous during off-hours.  I wrote SSIS packages and scheduled them with SQL Agent and alerting with SQL Mail.  We experienced much less downtime because of this.  

Don't be Captain Obvious

If you've worked with databases at all, even as a lowly jr developer, you've probably dealt with backups.  That's assumed.  Don't bother listing it:  

And why weekly backups?  Tell me the story.  I once worked at a place where the Oracle db was so large they only did hot backups once per year.  And then hourly redo log backups.  If a restore was needed in the middle of November it was going to take forever, but that was a trade-off that was well-understood by the stakeholders.  The story behind that decision was fascinating.  But this post is getting long.  If it's an obvious skill, don't list it.

Title Inflation...OK...Responsibility Inflation...NEVER OK

Let's say your official title was "DBA".  You decide it sounds better to put "Senior DBA" on your resume.  That's called title inflation.  That bothers lots of people but most GOOD hiring managers, and me, don't care.  We've all held jobs where our title was not reflective of our responsibilities.  I once held the title of Junior Programmer even though I was a Senior Data Architect.  The politics of this company mandated that any title with "data" in it had to reside in a particular branch of the org chart.  My boss wanted ME to report to HIM.  So I was given a silly title.  I didn't care and it made me look great to my boss.  

What annoys me is when your title is not reflective of your work.  Rarely are background checks done to confirm dates and titles.  So saying you were a "data architect" when you were really a "junior DBA", while unethical, is OK if you really did do data architecture-type work.  

What is unforgivable is Responsibility Inflation.  Example:  

I believe the candidate was honest and truly held the title of "Data Analyst/Product Developer".  Yet it sounds like she designed and coded the whole data warehouse.  Sorry but I'm not buying it based on how that sentence is worded.  I believe she worked ON a data warehouse that someone else designed and implemented...as a data analyst...but the verbiage just doesn't sound right for me to believe she DESIGNED it.  Again, if the candidate told me the story about the data warehouse and her role, then I'd believe it.  If you designed and implemented a DW then you'd be proud of it and it would be half of your resume.  Why?  Because designing and implementing something of the scale of a data warehouse takes years.

Responsibility inflation is blatantly falsification meant to deceive.  Title inflation may simple be a case of wanting to be recognized for doing more than you should've been responsible for.  

Recruiters and Resumes

Recruiters have a habit of reformatting your resume to make it look how they think it should look.  In most cases this is a wise idea.  Recruiters know their clients and they know what gets the best technologists hired.  However, kindly ask your recruiter to allow you to see any edits before they submit them for an open req.  

When you get to the face-to-face interview take a few copies of your unadulterated resume and distribute it to any interviewers.  This version should have less buzzwords, skills, software packages, networking tools, etc and should have more stories.  You've made it past the automated gatekeeper, now wow the interviewers.  They've already seen your buzzword-laden snoozer...give them a really great resume now that they've met you.  

Final Thought...tool-based knowledge

I can teach anyone tool-based knowledge.  What I want to know is that you know when you should and should not use those tools.  That's the story you are going to tell me.  For instance, if my company is an ERWin shop and your experience is solely with Embarcadero I won't discard your resume.  Both ERWin and Embarcadero are modeling tools that anyone can learn...quickly.  What can't be learned quickly is the underlying concepts that you MUST possess to use these tools effectively.  

You have just read "[[On Resumes]]" on davewentzel.com. If you found this useful please feel free to subscribe to the RSS feed.