Resume Writing Tips
With the economy looking so bad, you might be updating your resume. We often review resumes for friends and offer advice. Here are the suggestions that I generally give out.
Tips for Technical Resumes
With the economy looking so bad, you might be updating your resume. We often review resumes for friends and offer advice. Here are the suggestions that I generally give out.
Tip 1: Know the audience
First of all, then writing it is important to play to your audience. Steven King always includes the elements that his fans expect. An action film is expected to have an explosion or something major in the first scene. A romance is expected to introduce at least one of the main people in the first 5 minutes. A resume has to be written for its audience too.
What are the audiences of a resume? What makes writing a resume difficult is that there are two audiences. First is the low-paid, non-technical HR clerk that receives the resume. If it gets past the clerk, it will arrive at the desk of the person that will be your future boss. Your resume has to have the elements that will please both of these people.
- The HR clerk -- The first person to see your resume, sadly, is a non-technical, (usually low-paid), clerk. He is given 10,000 resumes a day and a list of what positions are open. This person then has to make a pile for each of those positions, and toss the rest. Your job is to make sure you get into one of those piles. The problem here is that this person doesn't know the difference between UNIX and Solaris, or that if someone knows Solaris 2.5 then they are hirable for a Solaris 2.6 job. Luckily, this person only reads the top part of every resume, so you can play to that: make make sure that you have an Objective and a "Skills" section that are customized for him. Don't say "Solaris 2.6", say "Solaris 2.x" or just "Solaris" (people have forgotten about Solaris 1.x by now).
- The Hiring Manager -- Each pile that the clerk created is handed to an appropriate "Hiring Manager." This person does understand the technology (or at least thinks they do) that you'll be working with. So the rest of the resume must be in their language.
The most common mistake that I see is that people don't write anything for the clerk. Therefore, their resume never gets to the hiring manager. The "Objective Statement" at the top of your resume is what the clerk reads. Make sure you resume has one, and make it a good one.
Tip 2: A good Objective statement:
A good objective statement tells a plainly-state title you would like ("UNIX programmer", "CGI Developer", "Project Manager", "Prostitute") and a couple skills that you have ("excellent writing skills", "experience with digital audio technology", "excellent oral skills", etc.).
You can also specify what industry or department you want to be in ("financial services", "telecommunication", ".COM", etc.).
Here are some good ones that I've seen:
- Objective: A position as a Senior UNIX/Linux Developer that lets me utilize my years of experience in the TDM cellular technology.
- Objective: A position as a Project Manager in the EDA industry that lets me utilize my excellent communication and presentation skills.
- Objective: A position as a Junior UNIX/Solaris Sysadmin (SAGE Level II) in the financial services industry that lets me utilize my superior Solaris knowledge.
- Objective: Experienced web-developer looking for projects that let me expand my HTML, VB.NET, MS-CMS2k skills.
In that last example "expand" sets an expectation of being a little green at VB.NET, etc. Replace it with "utilize" if you want to set an expectation of already being an expert. Companies do hire both, so don't set unreasonable expectations.
A sample bad objective statement (this is a real example):
- Objective: I am an expert in building large, scalable services based on open protocols.
That person didn't get any calls back, even though he had built .COM infrastructures that served literally millions of users email, web services, etc. The person was quite brilliant with technical things, but didn't write a resume that would get past the clerk: It didn't include any buzzwords or technology that the clerk could recognize nor a tangible position/title that was open. How could the clerk classify such a resume? It has to get past the clerk to get to the hiring-manager.
A better statement would have been: "A senior architect of UNIX-based (Solaris, Linux) email and web services that lets me utilize my experience in building extremely scalable systems with high up-times." He did change his resume to something similar, and soon started getting phone calls.
Tip 3: Buzzwords:
Use 'em. There is a reason for them, it makes communication faster. I hate "buzzword compliant" presentations, but only when they aren't adding any value to the statement. When they appear on a resume they do add value because the clerk uses them (whether or not they know what they mean). Better-trained clerks are given a list of synonyms.
For example: they might be told "We need a Solaris sysadmin... but that means anyone that mentions Sun, SunOS, or UNIX should be considered. Oh, other synonyms for UNIX are: AIX, Linux, IRIX... a person that knows any of those but wants to learn Solaris is fine for this position." However, that doesn't always happen, so I am a little redundent: I include the word UNIX in addition to the name the vendor uses.
List your strongest skills first. People evaluating resumes only read the first 3-4 items. I see many "skills" sections that list 20 operating systems or 20 languages or 20 vendors and that's a fine way to show that you have a lot of experience over many years. However, the person reading your resume is only going to read the first 3-4, so make sure those are the ones you want to work in. Don't list them in chronological order: that just emphasizes out-of-date technology.
A friend listed the languages she knew in the order she learned them. Which of the these two would a clerk find most useful if he/she was told to find a "Windows C++ programmer".
- BASIC, Pascal, C-64 BASIC, AppleBasic, Cobal, Fortran, C, awk, C++, Visual C++, Perl
- Perl, Visual C++, C++, awk, C, Fortran, Cobal, AppleBasic, C-64 Basic, Pascal, BASIC.
Number 2 is the more appealing, right? List the technologies you want to work with first.
Delete the super-old technologies like Commodore 64 and Apple II.
A concise way to list skills is to group them:
- Operating systems: Unix (FreeBSD, Solaris, Linux), Windows 95/98/2000/NT, and others.
Tip 4: Use industry classification like certifications and SAGE Job Classifications:
Who cares about certifications? I don't, but the clerk does. If you have any certifications, list them. Consider getting certified on topics that you feel you could pass without studying very hard. It will help you get past the clerk.
If you are a sysadmin, use the SAGE Job Classifications to describe yourself and/or the position you are looking for. More and more HR departments are using them, and certainly the cool companies that you want to work for are using them. However, explain enough so that someone that hasn't read http://www.sage.org/pubs/8_jobs/ will understand what you mean. That's why the above example was redundant: "a Junior UNIX/Solaris Sysadmin (SAGE Level II)". Also good would be "A SAGE Level II (Junior) UNIX System Administrator".
Tip 5: Never lie
I shouldn't have to say this, but don't lie on your resume. Don't exaggerate your skills. Don't claim you have certifications that you don't have. Companies would rather know that you don't know something but are willing to learn than be surprised to discover that you misrepresented yourself.
I had rather poor grades in college so I didn''t include my GPA on my resume. I was honest when asked for my GPA during interviews: the first interview was with someone that didn't complete college, and was unconcerned with GPA: he thought experience was more important.
I once interviewed someone that claimed they had designed LANs and WANs only to discover that they had talked about it with friends, usually while drinking at parties. If he had said he is looking to get started in LAN/WAN design, I might have hired him and enjoyed teaching him the rules of the road. Instead, I ripped up his resume after he left.
If they don't discover you are misrepresenting yourself (google is a great thing), then they'll be surprised when your job performance isn't what they expected and end up terminating you after a few months. Don't waste their time. There are jobs out there for every skill level no matter where you are.
Tip 6: Your filename:
Never use a filename like "resume.doc" when sending your resume as an attachment. Name the file something like "resume_tom_limoncelli.doc" so that if the HR person saves it, s/he will be able to easily tell yours from someone else's...and your resume won't be overwritten the next time someone else sends them a file called "resume.doc". (Thanks to Tina for that tip!)
Here's the beginning of my resume, altered slightly to demonstrate the above tips:
THOMAS LIMONCELLI
123 Main Street
Townname, ST 12345
+1 123 456 7890 mail@example.com
Objective: An architect-level senior system administrator (SAGE Level IV ) UNIX or Network administration position that uses my technical and inter-personal skills; or a role evaluating new technologies especially in the security and networking marketplace.
Skills:
- Operating systems: Unix (FreeBSD, Solaris, Linux), Windows 95/98/2000/NT, Cisco IOS 7.x-12.x, plus some experience with AIX, HP-UX, OpenVMS, NetBSD, OpenBSD and others.
- Programming Languages: Perl/CGI/mod_perl, C/C++, HTML, Unix shells and tools, awk/sed, SQL, Python, Pascal, BASIC.
- Network Products: Cisco Routers, Cisco Switches, Cisco PIX Firewalls and Cisco IP Telephony equipment (ICS7750); Checkpoint FW-1; Linux/Unix firewalls (IPFilter, IPFW); Avaya Cajun products; Network General Sniffer, tcpdump, Ethereal, Snort.
- Network Technologies: FastEthernet, Gigabit Ethernet, FDDI, OSPF, BGP, ATM.
Education:
Work History:
Director of Operations, Lumeta Corp, Somerset, NJ
Senior Network Architect (MTS), Lucent Bell Labs, Murray Hill, NJ
...
...
...
...
References available on request.
Outsourcing problems not avoided
TPOSANA's discussion on outsourcing tries to give guidelines about when (and when not) to do it. The worst possible situation is when the people signing the contract are ignorant of the issues needed to understand such a contract. The larger the contract, the more likely it is that this will happen.
Robert X. Cringely's new column on EDS and the Navy and Marine Corp Intranet (NMCI) contract shows that the problem can go both ways. EDS's contracting people were commissioned on getting the contract signed, and were disconnected from the people that would do the work. As a result, they signed an unprofitable contract:
[former EDS CEO Dick Brown] "was gobbling up contract after contract on the way to making EDS a $80 Billion company by the end of 2002. Remember that? Secure the contract. Worry about the details later. Now, it's later."
Sadly, this is hurting the U.S. Navy as well as EDS. Costly "shadow helpdesks" are being created to fill in the gaps that EDS creates. Tom experienced this kind of thing first-hand at a previous employer (oh wait, he ran such a shadow helpdesk!).
Worse yet, this dysfunctional contracting culture seems to be the rule, not the exception, for these large desktop workstation outsourcing contracts that were so popular years ago. It's hurting companies, it's hurting our governments, and now we learn that it's hurting companies like EDS.
Sources at Wal-Mart say something we should all heed:
And those sources were clear: there is no way Wal-Mart would entrust its IT services to an outside contractor or even to several outside contractors. Doing so would threaten the entire organization. If costs are out of control and services are inconsistent, that's something to be dealt with internally, not by hoping some outside organization is smarter or more disciplined. "We have suppliers, sure, but the ultimate responsibility always remains here in Bentonville," said my Ozark IT guy. "We centralize it, we control it, we know what we are buying and what we are doing with it. Anything less is just too much of a risk."
I wish we had said it so clearly and concisely in TPOSANA: If costs are out of control and services are inconsistent, that's something to be dealt with internally, not by hoping some outside organization is smarter or more disciplined. Read the full article here: http://www.pbs.org/cringely/pulpit/pulpit20040325.html
New web site up!
Welcome to our new web site! We've modernized the format, added a blog (one that permits comments), and imported all the old content. Tell us what you think?Career change for Chris
While writing the book, Chris was doing a PhD in Aeronautical Engineering at Imperial College London. With the PhD complete, she is now starting work at the Sauber Formula 1 motor racing team as an Aerodynamicist.Usenix2004: June 28, Boston
We're proud to announce that Tom will be speaking at a panel called "System Administration: The Big Picture" at Usenix 2004.
Session: System Administration: The Big Picture
The Human Big Picture
Tom Limoncelli
Imagine rolling out a security patch, a new application, or a new operating system to 40,000 PCs�it's 70% communication, 25% technical work, and 10% ego management. System administration on a large scale becomes a study of human relationships: managing large teams of people on a project, managing expectations and resources with upper management, and coordinating with a user base. Psychology and public relations become just as important as technical prowess. Why aren't those skills taught to CS majors?
