Job Hacking

Are words holding your search back?

Yesterday, I stepped smack dab into the middle of the healthcare debate, and got a lesson in words.

Words are important because they represent our thoughts. And, our thoughts become our actions. And, our words also become our stories and our myths.

For the healthcare debate, here are some of the phrases that are framing our thoughts:

• "Death Panel"
• "insurance rackets"
• "Big Government"
• "AstroTurf protesters"

The thing is, the same thing applies to looking for a job. There are words and phrases that candidates use, recruiters use, and hiring managers use, and it turns out they don't really match up.

For example:

• 5 years of experience doing...
• Rockstar Java Developer
• Team-oriented
• Experienced with C, C++, Java, CSS, HTML, MySql, Apache, Perl, etc.

Let's take the 'experience' question. It might be that you have been coding at college on in-class projects and some stuff on the side during break. You think this is experience. The hiring manager thinks that experience means that the ideal candidate has worked for some period of time on a commercial development team creating software for their desired market. 

Oh, and there's the whole question of how well you know how to program. This is one of the areas that creates the greatest amount of angst and humor in the recruiting process. Does memorizing the Knuth books qualify? Can you code different algorithms in the language of choice by the employer? Do you know how different compilers treat the same code differently? How do you make an algorithm more efficient in a given Development environment? How do you go about refactoring code? How many years does this all take to get right?

'Rockstar'. Oh my. Could be that the hiring manager thinks this is someone who knows the programming cannon and can code anything. Fast. Without question. And be able to synch immediately with the rest of the Dev staff. For the candidate, it could mean that you are a virtuoso coder, yes, and that you expect that there will be a nice bowl of blue M&Ms on your desk every morning, that there will be a nice cute thang delivering your Peet's Double-tall mocha every day at 10:30 am, and that all other Developers on the team will do your bidding without question. 

For y'all on the job hunt, I challenge you - cut the crap on broad-based assumptions linked to common phrases. Know what you can and cannot do. Use appropriate language to describe what you are. The same thing applies to recruiters and hiring managers, but they don't think it does because it's a buyers market. For now.

Be Bold!

There are so many ways to make your resume stand out.

For example, use an Objective Section.

You can also include short recommendations from key supervisors in your career.

And, of course, you should include a line or two at the end of each career entry to detail the technology used, such as: Java, Javascript, CSS, HTML, MySQL, Linux, C++

You should, of course, make the resume short. And use declarative sentences.

And above all, BOLD random words. Because that's what all the best developers do to help the really dumb recruiters see all the key items on their resume.

- or -

Focus on clean, crisp formatting. It makes it easier to pick up the phone and call you.

re: What does 'career growth' look like?

Got a good question in response to my post, Well then, what is time again?

NotLooking wants to know if there is career growth for those individual contributors in the Development world, from the eyes of the hiring manager or recruiter.

Dang straight there is.

For me, when I read a Developer's, or Tester's, or Program Manager's resume, and especially one where the candidate has been at it for more than 5 years, I want to see evidence of learning and maybe more importantly curiosity. Having said this, the evidence of these two items is different between a Contract Cowboy Coder and a Sr. SDE who jumps jobs after 2 or so major releases of a product.

The evidence I look for includes things like learning new languages, jumping into developing on new platforms, teaching adjunct programming classes, getting a degree. To me, this is evidence of self-directed growth.

One of the most remarkable interviews I conducted was with a very seasoned developer who had completed his J.D. a month or so before. I was interviewing this candidate for a Sr. SDE role, and of course I had to ask as to why he was pursuing a Development role when he had just completed his law degree. He said it was because he studied law to bring deeper understanding to his coding as he had noticed similarities in the construction of legal documents and software.

That's career growth.

Your resume on PDFs...

Got another question regarding pdfs, "Would you please explain why you don't like pdfs?  It is the only document format proven to be viewed exactly the same on any platform."

What's with this 'you don't like X' this week??? ;-)

I like PDFs fine. I just think your resume has no place being in one.

Why?

Because too many Applicant Tracking Systems, ATSs don't scan or read them properly. Which means that when our hard-working recruiting-types go a-searching, they miss your resume.

In this case, all that cognitively-based formatting, and that way-too-cool-for-school font are wasted.

So, if you want a job, put your resume in either Text format or a Microsoft Word format.

What is a result?

I've had a couple of job hunters asking me questions about what creates a powerful resume.

"Results", says I.

They respond, "I wrote everything in PARs format, and so it is ready to go!" (PARs stands for Problem - Action - Results, which is a good thing for a resume).

I look at the resume, and no, not so much. The problem is their description of the results. It's all about what they delivered.

That's not really results what a hiring manager cares about. They want to know that what you delivered improved the financial picture of the organization. They want to see how your past work history will improve their organization.

Now, you, as the proud candidate may think that the delivered results are great. The problem is that just delivering something is not good enough. Sure, you need to deliver the product, the service, whatever. Then you need to track the results. Did the product improve things? Did revenue increase? Did the costs go down? Was the process more efficient and save the firm from hiring a bunch of people?

Look at it this way, the way a recruiter sees things. Lots and lots of resumes that tell them what candidates delivered. And then, one or two that show the impact of the delivered items.

Guess which resumes stand out?

re: What Employers Want to See on Your Resume

Guy Kawasaki has a nice guest post from Glen Kelman, CEO at Redfin, What Employers Want to See in Your Resume.

It's a straight-ahead post, and it's got some great suggestions in it. There are a few bits I'd quibble with, like pdf-formatted resumes (just don't do them because too many ATSs don't read them straight), but 95% of it is G-R-E-A-T.

One thing that's tough to put into context for most job-hunters is understanding what makes for a "generic skill" (I agree with Glen completely about avoiding them). It's one of the reasons I H-A-T-E Summary sections. I've yet to see one that did anything positive in marketing a candidate because most everyone does not want to take risks on their resume so they say stuff that's safe, like:

• Experienced executive with 20 years background in mobile technology.
• Highly energetic coder with deep experience in Java.
• Multi-faceted Systems Engineer, with hands-on experience with Linux & Windows OS.

It's all safe, it's all bland, and it does nothing to move you forward in the eyes of the scanner, er reader.

A new take on video resumes

Let's start with a frame on this post: I hate video resumes.

They are a very bad idea for so many reasons.

Today, I saw a video via DefenseTech that made me think a bit about what a video resume is. Probably because I had just told someone that the whole purpose of a resume is to get an interview.

With that in mind, take a look at this video, and think about this: If you were a hiring manager and you saw this, would you want to hire him? So, now, what other kinds of work scenarious can you think of that, if recorded, would put you forward in a positive light?

It's not a resume - it's a sales & marketing tool.

This video has a lot of very foul language, so you've been forwarned.

You wouldn't write a bad resume, would you?

Everyone needs a resume.

Before you write, or re-write, your resume, what's the key consideration?

Your audience.

You have to ask yourself, "Am I writing this resume for me, or for the recruiter/hiring manager?"

This sounds like a silly question. Why would I write a resume for myself?

Probably 80 - 90% of the resumes I see are Vanity Resumes. They tell the reader a lot about why the resume's owner thinks they are great. They do not tell the reader why they should hire the resume's owner.

The first indicator of a Vanity Resume is an Objective Statement that looks something like this:

I'm looking for a technology leadership role that will provide me with an opportunity to continue to improve myself and further my career. The ideal role is at a well-funded, leading-edge startup where I can apply my current skillsets and make an impact while working with a group of bright, talented people who will continually challenge me.

Vanity is all about the self, so count the number of times "I", "myself", "my" and "me" are used.  Second, if you think this objective statement looks O.K., think about this: How does this help the hiring manager know that you are the ideal person for their key role? From a needs-based selling perspective, how does this so-called objective statement meet the needs of the reader? Finally, if you're not convinced yet, think about why this text could not be applied to everyone, so at minimum, it does nothing to differentiate yourself from any other candidate.

A better objective statement:

VP of Development

With this, the reader clearly knows what you've applied for, and possibly, how you'll help them.

Bad resume = Vanity resume

I bet you don't know how to describe organizational success...

Last Thursday, I had lunch w/a long-time friend/colleague of mine, Brad. During the course of our conversation, we spoke about some of the differences between the good ol' days of the early '90s and now. Particularly as it relates to starting up a company, and making great stuff happen.

What does this have to do with your ability to describe organizational success?

Back then, it took a LOT of money to get a venture off the ground. Multiple millions of dollars. Tens of Millions. This was reflective of the state of hardware/software technology and infrastructure of that time, and the challenges in getting it all to work together well.

Now, you don't need that much. Shoot, for some web startups, it's easily possible to do this with less than $1MM, and it's within reason to get something going for far less - under $100K (or under $10K in certain circumstances).

Still want to know what this has to do with your ability to describe org success?

You need to illustrate that you can not only grow a company, but you also need to illustrate that you can do so efficiently. Especially now!

If you're a leader of some sort, the ante to get into the game is being able to grow a team's headcount. What the hiring manager wants to know is what this growth looked like in the context of the business. If your org's growth was linear and parallel to the growth of the business, that's sort-of O.K. If your org grew at half the rate of the business, that's more interesting. If you managed to increase team size linearly while the business grew exponentially, then that's great.

That kind of result might just get you an interview.

And, if you're having trouble making your resume shine like this, let me know. I can help!

I can learn new things quickly. Really.

Back when, I was a Technical Support Engineer on a C library. And not too shabby at it, either. ;-)

One of the things we got used to was the lies (intentional or otherwise) that customers said on the phone:

• Sure I initialized the pointer properly...
• I'm certain that my make script has the switches you recommend...
• Of course I'm compiling in the Large Memory model...
• No really, I KNOW what I'm doing. I started programming before C was even imagined...

As a recruiter, I find that one big different between then and now is that the lies have changed. Here's one of my current favs I see on resumes all the frickin' time:

I can learn new languages and software very quickly.

Since it's Friday, I thought we'd have some fun with this and tear it up. Here goes:

• Define very.
• Define quickly.
• Define learn.
• Did you read the job description, and which of the languages that we require for this job on day 1 don't you know?

Y'all need to go into the bathroom, look at yourself in the mirror and repeat after me:

• I shall not use adverbs on my resume. (Adverbs = -ly ending. See "Lolly Lolly Lolly get your Adverbs Here")
• I shall not state that I own a skill in vague way on my resume.
• I shall always read the job description thoroughly. Twice. Only then shall I send my resume in to the recruiter/hiring manager.

Think about it this way: We work in an industry that is filled with smart people. Hiring Managers expect that the people they interview are smart. That they are quick studies. That they are creative. They also know that while most people can pick up the things that are similar between all languages, it's the nuances that will kick you and their team in the ass.

Instead of all this vague clap-trap, try something like this:

Adept at learning new programming languages. On a team of 10 developers who were told to learn and use Ruby on Rails to re-write a website, I was the first to write valid code for the project, and my code represented over 50% of the total code base at ship.

Indubitably!