Archive for November, 2011

How do I make my resume stand out?

November 29, 2011

All the time I hear people asking “How do I make my resume stand out?” It’s a great question to ask, because your resume is one of dozens or hundreds of others. The problem isn’t that you want your resume to get noticed, but that you want the reader to be interested in what you say and call you in for an interview. How do you do that?

Remove fluff

Do you have an objective? Don’t. It’s filled with meaningless fluff. “I want to leverage my skills to add value to the bottom line of a forward-thinking blah blah blah bullshit bullshit bullshit.” That says nothing other than “I want this job.” No kidding. Never use an objective.

Do you make meaningless claims like “Excellent written and verbal communication skills.” Crap. It means nothing. Anyone can say that. Give just the facts, not your own assessments. “Excellent written and verbal communication skills” is not a fact. It is an opinion, a self-assessment. Leave it off.

Those are all vague, meaningless generalities. Give details!

Add numbers and other details

Use numbers in everything you can. Numbers draw the eye and give detail. You should have at least one number on every bullet line in your resume.

Let me repeat: Every bullet point in your resume should have a number that gives size of the job.

Instead of saying “Worked on the help desk, answering user questions” you say you “Worked on the help desk, answering an average of 30 user questions per day.”

“Proficient with MS Office, Windows suite and all around tech savvy” is hopelessly vague and uninspiring. Tech savvy according to who? Your grandma? Oooh, you know Windows. So does my dog, and he died six years ago.

Now, if you’ve done amazing presentations in PowerPoint, then say that. “Created three presentations in PowerPoint in a year for area sales directors.” That says much more than “I know Office.”

Remove fluff. Add numbers and details. That’s 90% of the battle right there. If you can do that well, you’re ahead of the pack.

Looking for ideas on how to add details to your bullet points? Post them in the comments and I’ll see if I can help.

Advertisements

Track your professional stats like a pro athlete to give your resume power

November 14, 2011

Let’s say that you’re Chicago Bears quarterback Jay Cutler and you’ve got to submit a resume to the next team you want to play for. If he wrote a resume like most resumes I see, he’d write something like this:

Chicago Bears, 2009-current
Quarterback

  • Responsible for directing on-field offense of professional football team.
  • Called plays, led huddles before each play.
  • Play-to-play responsibilities include handing ball to running back, throwing passes, and running with ball as necessary.

Hardly inspiring, is it? It tells what his job responsibilities were, but not what he actually achieved. Let’s rewrite some of those bullets with some of his statistics.

  • Lead Bears offense to 11-5 season, and to the NFC championship game in the postseason.
  • In 2010, threw for 7.58 yard passing average with a 60.4 completion average.
  • etc etc etc

See how the second resume is focused on results, not responsibilities? Your resume should be thought out the same way. When you talk about results, you need numbers to tell the story. Plus, numbers draw the eye and give your resume the detail that makes it interesting.

“But Andy,” I hear you saying, “we’re just humble programmers and graphic designers and system administrators. We don’t have the collective power of the NFL stats keepers keeping track of all this for us!” Indeed you don’t, which is why you have to do it yourself.

Start keeping track of your own stats. Start today and look around you. Think about “how many” for all the things that are part of your workday, and put them on your resume. (You ARE keeping your resume current, right?)

  • How many people on your team?
  • How many lines of code in the codebase?
  • How many users use your software?
  • How many users on your network? How many servers? How much storage?
  • How many support calls do you take per day? Per week?
  • How much money has your work saved the company?
  • etc etc etc

Your goal should be to have at least one number in each bullet point, supporting the story that the text tells.

So few resumes have any sort of numbers or statistics on them, you’ll put your resume ahead of 90% of the other applicants’ resumes.

Credit for this way of thinking about resumes goes to Rich Stone, in his blog post Resume and Interview Preparation Tips. Thanks, Rich!

Making Your Tech Conference Presentation, and Experience, Not Suck

November 11, 2011

Tech conferences are incredibly expensive, and not just in dollars. Even free conferences like BarCamps incur the expense of the attendee’s time. Taking time off from work or family is a hassle at the very least, and it’s time that isn’t billable. The draw of the conference boils down to those 45 minute sessions, and speaker and attendee alike should make the most of it.

Read the rest of the article at Software Quality Connection.

How can I help my 50ish sysadmin brother find a job?

November 9, 2011

A reader wrote me yesterday:

I just finished your great book Land the Tech Job You Love. I wish I’d had this to refer to when I was job searching over the years. This afternoon I’m going to give my highlighted copy to my brother who is currently in his 4th year of his search for a UNIX Sys Admin job.

My brother’s situation is the reason behind this email. He has 14 years of programming experience (at [big technical company]) and 14 years of UNIX Sys Admin experience (mostly at [company] but the latest 4 years were various short term contract positions). We’re in [big tech city] so there are jobs available. He seems to be able to get phone screens and some interviews but hasn’t been able to land a job. The brutal fact is that he is not very verbal and doesn’t interview well. I also suspect his Sys Admin experience lacks some breadth. It doesn’t help his cause that, even though the subject is taboo, he is in his early 50s (see: The graying of the long-term unemployed).

I would appreciate any thoughts you might have specific to my brother’s situation.

You say he doesn’t interview well, and his experience lacks breadth. Sounds like you have the two things to fix right there! 🙂

As far as his lack of experience, I’d do as much on my own as possible. I don’t know what he has NOT done, but I’m guessing you have some ideas. What do employers in the area want that he’s lacking. Do people want him to know LDAP? Set up an LDAP server on your home box. Does he not know enough languages, or maybe the last “new” language he learned as C++? Get a copy of a book on Ruby or Perl or Erlang and start writing some apps. Set up Ruby and Rails on a local server and start learning. Pragmatic has many introductory Ruby titles.

The perception of “This guy is too old” is, I suspect, a vicious cycle. They see him as “an old guy”, and then it turns out he knows old skills, which reinforces the “old” part. So he’s got to know new skills even more than a kid fresh out of school.

As to interviewing well, I can only suggest practice practice practice, and help him identify the areas that he’s weak. Again, I get the feeling you have an idea what these are. Does he not answer questions with enough detail? Then help him practice giving longer answers that focus on business. Or is it just that he doesn’t keep good eye contact or speak clearly? Again, practice is key. Maybe you could record a mock interview, with you as the interviewer. Afterward, the two of you can identify and discuss where he can improve. I’ve also heard wonderful things about Toastmasters for helping people get better at speaking with others.

Let me know how it goes!

Readers, have you had to deal with the perils of job hunting in tech later in your career? How did you handle it? Please let me (and the rest of us) know in the comments.

Mark Jason Dominus on the importance of giving fish

November 2, 2011

By Mark Jason Dominus, from a talk in 2003, reprinted here with permission. Sadly, it’s still relevant today.

The #perl IRC channel has a big problem. People come in asking questions, say, “How do I remove the first character from a string?” And the answer they get from the regulars on the channel is something like “perldoc perlre“.

This isn’t particularly helpful, since perlre is a very large reference manual, and even I have trouble reading it. It’s sort of like telling someone to read the Camel book when what they want to know is how to get the integer part of a number. Sure, the answer is in there somewhere, but it might take you a year to find it.

The channel regulars have this idiotic saying about how if you give a man a fish he can eat for one day, but if you teach him to fish, he can eat for his whole life. Apparently “perldoc perlre” is what passes for “teaching a man to fish” in this channel.

I’m more likely to just answer the question (you use $string =~ s/.//s) and someone once asked me why. I had to think about that a while. Two easy reasons are that it’s helpful and kind, and if you’re not in the channel to be helpful and kind, then what’s the point of answering questions at all? It’s also easy to give the answer, so why not? I’ve seen people write long treatises on why the querent should be looking in the manual instead of asking on-channel, which it would have been a lot shorter to just answer the question. That’s a puzzle all right.

The channel regulars say that answering people’s questions will make them dependent on you for assistance, which I think is bullshit. Apparently they’re worried that the same people will come back and ask more and more and more questions. They seem to have forgotten that if that did happen (and I don’t think it does) they could stop answering; problem solved.

The channel regulars also have this fantasy that saying perldoc perlre is somehow more helpful than simply answering the question, which I also think is bullshit. Something they apparently haven’t figured out is that if you really want someone to look in the manual, saying perldoc perlre is not the way to do it. A much more effective way to get them to look in the manual is to answer the question first, and then, after they thank you, say “You could have found the answer to that in the such-and-so section of the manual.” People are a lot more willing to take your advice once you have established that you are a helpful person. Saying perldoc perlre seems to me to be most effective as a way to get people to decide that Perl programmers are assholes and to quit Perl for some other language.

After I wrote the slides for this talk I found an old Usenet discussion in which I expressed many of the same views. One of the Usenet regulars went so far as to say that he didn’t answer people’s questions because he didn’t want to insult their intelligence by suggesting that they would be unable to look in the documentation, and that if he came into a newsgroup with a question and received a straightforward answer to it, he would be offended. I told him that I thought if he really believed that he needed a vacation, because it was totally warped.

Mark Jason Dominus has been doing Perl forever. He is the author of Higher Order Perl which belongs on the shelf of every Perl programmer. Follow him on Twitter at @mjdominus.