How do I make my resume stand out?

November 29, 2011 Job hunting 2 comments , ,

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.

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

November 14, 2011 Job hunting 1 comment , , ,

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 Uncategorized No comments

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 Ask Andy, Career, Interviews, Job hunting 1 comment ,

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 Communication, Open source, People 2 comments , , , ,

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.

How to deal with busybodies at work

October 17, 2011 Work life 5 comments , ,

They’re young or old, male or female. Every workplace has them. They’re the busybodies who want to tell you how to live.

  • “I can’t believe you’re using an iPhone.”
  • “Are you and Kathy going to get married some time?”
  • “Another diet Coke? That aspartame is no good for you.”
  • “You’re going out without a coat?”
  • “You’re eating THAT?”
  • “Your kids shouldn’t be watching that much TV.”
  • “Why wouldn’t you drive an American car?”
  • “Have you thought about exercising?”

The busybodies at work can find anything to discuss and let you know what we should be doing differently. They tell us that we should be doing things their way. The right way.

As geeks, we are good at discussing the merits of an argument. We think we can explain our point of view and the other person will leave us alone, having seen the logic of our answers. We might think that explaining “I’m well-versed in vi, I have a large ~/.vim directory of plugins, and it fits my work style” will leave the emacs fan satisfied that we’ve made the right choice for us.

But it doesn’t work that way. The busybody comes back with an answer that takes ours into account, but still tells us we’re wrong. “Sure, but emacs probably also has all those plugins, and it can also…” For every argument we make, the busybody has a counter-argument.

It’s an interesting game, but the only way to win is not to play.

The way I don’t play this game is with a simple, non-judgmental response of “Thanks, but I don’t care to discuss that.” It doesn’t give the busybody any foothold to argue further. If he comes back and says “Oh, I know, but don’t you think you’d feel a lot better if you just smoked less?” I can reply, unchanged, with “Thanks, but I don’t care to discuss that.” If he still comes back, I can say “Thanks, but I don’t care to discuss that. I need to get back to work now.”

I’ve also found that providing justifications for our choices in life has a negative effect. Explaining our actions to others who have no business in our lives tells the busybody that he is right to be meddling in our lives. This is the wrong message to send, as no justification is necessary. It only encourages him in the future.

If you’re old enough to have a job, you’re old enough to make decisions about your life by yourself.

I don’t begrudge the nosy their motivations. I like to assume that they’re only looking out for what they imagine are my best interests. It doesn’t make their comments any less rude, but it does make it easier for me to not feel insulted by them.

On technical issues, I have to give the busybodies a little leeway, but not much. If a co-worker wants to turn me on to a new tool or technique, then that’s certainly OK. What’s not OK is badgering me about it after I’ve made my choice. I typically will say something like “I see that there are merits to using zsh over bash, but I prefer bash. If you think that zsh should be mandated in the department, why don’t you take it up with Dave and we’ll see if we should set shell choice as a standard.” That often gets the busybody to back off because he doesn’t want to risk losing his own freedom to choose.

Dennis Ritchie, pioneer of programming, has died

October 13, 2011 Programming, Unix 1 comment , ,

Dennis Ritchie, pioneer of programming, creator of the C programming language and one of the creators of UNIX, has died.

Tim Bray said it best: “It is impossible — absolutely impossible — to overstate the debt my profession owes to Dennis Ritchie. I’ve been living in a world he helped invent for over thirty years.”  If you’ve written a program on any computer in any language since the mid-1970s, you’ve been influenced by the man’s work.

In his honor, the choir will now sing one of my favorite programming songs, “Write in C”.

When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom:
“Write in C.”

And as the deadline fast approaches,
And bugs are all that I can see,
Somewhere someone whispers:
“Write in C.”

Write in C, write in C,
Write in C, yeah, write in C.
Don’t even think of COBOL
Write in C.

If you’ve just spent 30 hours
Debugging some assembly,
Soon you will be glad to
Write in C.

I used to write a lot of FORTRAN,
For science it worked flawlessly.
Try using it for graphics!
Write in C.

Write in C, write in C,
Write in C, oh, write in C.
BASIC’s not the answer,
Write in C.

Now, let’s move forward with our lives, and remember to always place the opening brace of a block on the same line as the control statement, as he would have wanted it.

Which of my PostgreSQL indexes are getting used most heavily?

October 10, 2011 Open source, Programming No comments , , , ,

Ever since we got the fast new database server with SSDs, I’ve been monitoring which tables are getting heavy traffic and should go live on the SSDs. We have two tablespaces, “fast” which is faster but smaller, and “slow” which is bigger but slower. I’ve been using this query to determine which indexes should live in which tablespace. There are different forms of this query around the web, but I needed to see the tablespaces, too.

SELECT
    i.idx_scan,
    i.idx_tup_read,
    i.idx_tup_fetch,
    i.indexrelname AS index,
    it.spcname AS index_tablespace,
    i.relname AS table,
    tt.spcname AS table_tablespace,
    pg_size_pretty(pg_relation_size(i.indexrelname::text)) as index_size
FROM pg_stat_all_indexes i
    INNER JOIN pg_class ic ON (i.indexrelid = ic.oid)
    LEFT OUTER JOIN pg_tablespace it ON (ic.reltablespace = it.oid)
    INNER JOIN pg_class tc ON (i.relid = tc.oid)
    LEFT OUTER JOIN pg_tablespace tt ON (tc.reltablespace = tt.oid)
ORDER BY 1 desc, 2 desc, 3 desc

The output looks like this (in \x mode because of the width):

-[ RECORD 1 ]----+----------------------------------------------------
idx_scan         | 395974172
idx_tup_read     | 432974893
idx_tup_fetch    | 426070104
index            | testbook_pkey
index_tablespace | fast
table            | testbook
table_tablespace | fast
index_size       | 289 MB
-[ RECORD 2 ]----+----------------------------------------------------
idx_scan         | 133416135
idx_tup_read     | 133441801
idx_tup_fetch    | 133413399
index            | lists_listid_custid
index_tablespace | fast
table            | lists
table_tablespace | fast
index_size       | 7096 kB
-[ RECORD 3 ]----+----------------------------------------------------
idx_scan         | 50310975
idx_tup_read     | 1286116
idx_tup_fetch    | 742639
index            | listdetail_bkkey_listid_where_ctr2_is_zero
index_tablespace | fast
table            | listdetail
table_tablespace | fast
index_size       | 682 MB

I have one case where a heavily-trafficked table is still staying on the slow tablespace. It’s a log of user login history that is only ever appended to, and is searched only a few times a day. SSDs are great at random reads, but not much faster than physical spindles on sequential writes. Therefore, my login history would not benefit much from moving to the SSD tablespace, and I can allocate that precious space to another table or index instead.

You’re not a genius? Says who?

October 10, 2011 Open source, People, Social 2 comments , , , , ,

Who says you’re not a genius?  Who are any of us to say?  And why would anyone bother telling someone that?

In my last blog post, I talked about how it was unnecessary and counterproductive to justify your projects to your detractors. It only wastes time that could be spent doing something positive, and it’s not going to change anyone’s mind.  One of the commenters took issue with my premise, basing his disagreement on the glib comment “You ain’t Steve Jobs.”

Of course I’m not, but so what? How much of a genius do I have to be before I no longer have to justify myself to others? (Don’t answer that; it only encourages them.)

The unspoken corollary to comments like “You ain’t Steve Jobs” seems to be “Therefore, you must listen to how others want you to be.” Fortunately, even in the absence of a Jobs-level genius, we’re all able to stand on our own, to live and work as we see fit, without having to take mandatory guidance from others.

I wonder at the thought process that it takes to tell someone “You’re not as _____ as you think you are.”  Near as I can figure, comments like these have one or more of these subtexts:

  • “You need to be more like me.”
  • “I’m trying to save you wasting time or risking failure.”
  • “I have taken it upon myself to take you down a peg and put you in your place.”  (This one often appears with the phrase “I’m just saying…”)

Fortunately, none of these are valid, none of them need concern you.  You can, and should, ignore them.  Ignore them for your own sake, and for the sake of the awesome things you have in you to share with the world.

I wonder how many Jobs-level brains are out there but never flower because the person was told too many times that he (or more likely, she) isn’t as good as he thinks he is. Neil deGrasse Tyson makes a brilliant point about how we teach children, that parents spend the first years of a child’s life teaching him to walk and talk, and the rest of his life telling him to shut up and sit down, quashing their sense of wonder and thirst for knowledge. “You ain’t Steve Jobs” is the adult version of “shut up and sit down.”

Whatever your level of genius, one thing we can all share with Steve is his perseverance.  He kept working at what he believed in, despite public derision about his public failures.  Before the success of the Macintosh, Apple released the Lisa, and before the iPad, the Newton. How much poorer the world would be if Jobs had listened to his critics and packed it in!

I’m not saying that there isn’t value to be found in criticism, even unsolicited criticism, about your work.  I’m not suggesting that you shut out the world around you.  If you can take what you find useful and leave the rest, then do it.

I am suggesting that you shut out those who tell you you’re no good, or who want to put you in your place. When people tell you you’re not awesome, ignore them.  Who are they to say?  And why does it matter if they think you’re awesome or not?  Eventually, you’ll prove them wrong.

 

There’s only one useful way to handle your detractors

October 6, 2011 Open source, People, Social 8 comments , , ,

Here’s a Reddit/Slashdot/whatever thread that never happened:

Internet crank on Reddit: “Hey, Steve Jobs, I guess that new iPad looks cool, but I think iPad is a stupid name, it makes me think of sanitary napkins.”

Steve: “Yeah, well, here’s why we called it that. (Long explanation justifying his choices)”

Crank #2: “Well, why didn’t you call it the iTablet? I think that would have been a good name. What does everyone else think?”

Crank #3: “What does it have to be iAnything? I’m tired of the i- prefix.”

Steve: “We thought about that, but … (More explanation about his choices)”

Crank #1: “And really, isn’t it just a bigger iPod Touch? I would never carry that around with me. And come on, you’re just trying to redo the Newton anyway LOL”

Steve: “My logic behind the iPad is (vision, business plan, blah blah blah)”

Can you even  imagine Steve Jobs in this sort of time-wasting and emotionally draining tit-for-tat in a thread on Slashdot? On reddit? In some blog’s comment section? Of course not. Justification of his plans would take away from the amazing things that he needed to achieve.

Naysayers are part of every project. How many people do you think pissed on Jimmy Wales’ little project to aggregate knowledge? Nobody’s going to spend their time writing encyclopedia entries! And yet there it is.  On a personal level, if I listened to everyone who thought I was wasting my time improving on find + grep you’d never have ack.

We all have to persevere in the face of adversity to ideas, but there’s more than that.  We need to ignore our detractors. Despite how silly and time-wasting it is to argue your motivations and reasons for undertaking a project, many of us feel compelled to argue with everyone who disagrees with us.  I suggest you not waste your time.

On the Internet, the attitude is “Why wasn’t I consulted?” Every anti-social child (measured by calendar or maturity) with a keyboard thinks it’s his responsibility to piss on everything he doesn’t like. They’ll be there always. You can no more make them go away than you would by arguing with the rain.

What are you hoping to achieve by arguing with someone who doesn’t like your project? Do you expect that he’ll come around to your way of thinking? It won’t happen through words.

Not only does arguing with your critics waste your precious time, but it tells them, and every other crank reading, that you’re willing to engage in debate about what you’re doing. Don’t encourage them! Let them find a more receptive target.

I’m not saying that factual misstatements need to be ignored.  If something is provably incorrect, go ahead and counter it with facts.  However, most of the time these message thread pissing wars get down to “I would not be doing what you are doing, and therefore you are wrong for doing so.”

The only thing that has a chance of silencing your critics is success at what you do. Arguing with the naysayers doesn’t get you any closer to that.