Adam Marcus

Fifteen resume writing tips

I’ve been doing a lot of recruiting lately, and there are a number of mistakes that I see again and again. Here are 15 tips for resume writing and two tips for the interview process.

Resume Formatting:

Always include your name, phone number, email address, and the city and state where you currently live on your resume. Resumes are often extracted from one system and transferred to another, and if you don’t include your contact details on your resume, a recruiter who realizes they need to go back into some other system to find it may just decide not to bother. Including your city and state allows recruiters to check what timezone you’re in so they know when to call you.
Run spell check! And make sure that you’ve set the correct language so spell check actually works.
Whenever possible, provide your resume in PDF format. If you provide it in another format (e.g. Microsoft Word or RTF), it’s likely that it will be reformatted and the spacing will get screwed up.
Test that your PDF resume doesn’t spit out a bunch of gibberish codes when converted to text, and that it include the important stuff like your contact info. A quick way to test this on Windows is to open your resume in a PDF reader, press CTRL+A to select all of the text, press CTRL+C to copy all of the text to the clipboard, then open Notepad and press CTRL+V to paste all the text. If you put your name and contact info in the header of the original document and it doesn’t appear in the pasted text, move that info from the header to the body of the document.
Make the filename of your resume your first and last name and then the word “resume,” e.g. “Adam Marcus resume.pdf.”

Resume Content:

Unless you’re applying for an academic position that asks for a CV, you should never submit a resume longer than 2 pages. When I’m reviewing resumes, if I see that it’s longer than 2 pages, I’m just going to skim it and will probably read less than if you just trimmed down the resume yourself. And I may not read the most important stuff. When cutting down a longer resume, you can either provide fewer details about individual jobs and/or consolidate multiple jobs into something like “January 2010 to July 2015 – Various Linux system administrator positions at small businesses in and around Detroit”. (And you can still include a bunch of bullet points under this single heading.)
If you mention specific products (e.g. Salesforce, PowerPoint, or 7-Eleven), make sure you capitalize the name and use punctuation correctly. Do a Google search to double-check.
If you refer to an application, department, or process that’s internal to an organization, don’t expect the reader to know what it is. This is especially true for acronyms. So instead of writing “Head of ABOG”, say head of school’s Academic Business Officer Group (ABOG).”
Don’t write things like “a few years of experience.” Give hard numbers.
Make sure you don’t have something like “Expected graduation 2016” when it’s 2018. If you can’t be bothered to update your resume, I can’t be bothered to read it.

Other Resume Tips:

Have someone else proofread your resume. If you really can’t find someone else, wait at least a day after you update it and then slowly and carefully read it again. If you don’t find any mistakes, try reading from the bottom up. There will be mistakes. If you don’t find them, I will. And I will think less of you when I do.
If you’re applying for a job that requires a security clearance or states that a security clearance is preferred, definitely mention if you have a clearance, even if it’s now expired. If you have never had a clearance, state whether you’re a U.S. citizen, which is a requirement for obtaining a clearance. This is especially important if you have a foreign-sounding name, attended a school in another country, or worked in another country. Stating that you’re a U.S. citizen may keep your resume from being discarded on the first review.
Don’t apply to positions you’re clearly not qualified for. If a job posting says you need 3+ years of experience as a cybersecurity analyst and you have zero experience, don’t waste your time or the recruiter’s time. But if you only have 2 years of experience, include a cover letter explaining why you think you should be considered in spite of your limited experience. Maybe you did two internships that should also be considered experience. Maybe you had additional training that should be considered.
If you have many years of experience, create a “master” resume that includes *everything* you think a potential employer may want to see, and then cut out the stuff that isn’t relevant to each different position you’re applying to.
If you’re applying for multiple different types of jobs at once, create a different resume for each type of job. Just be sure that when you update something in one resume, you update it in all of your other resumes too.

Interviewing Tips:

Other than scheduled interviews, don’t call the recruiter. If you realize that there’s something important you forgot to mention or ask during an interview call, send an email. If you haven’t heard back in two business days, send another email. If you still haven’t heard back after another day, only then should you pick up the phone.
Don’t ask a question that you can answer yourself by re-reading the job description and/or the company’s website (if you know who the employer is). It makes the interviewer think you haven’t prepared for the interview and are not interested in the job. Instead of asking what the job involves, ask if they can tell you the approximate percentage of time they expect the hired person to devote to the different aspects of the job. Instead of asking what the company does, ask what markets it targets (if that isn’t obvious from the website).

How I became a technical writer

As a kid, I read a lot of books. This began to develop my skill with language. But I was also fascinated with computers from a very early age.

When I started college, I planned to get a degree in Computer Engineering or Computer Science. In my introductory computer programming courses, I noticed that my classmates were way more into programming than I was, but that I was way better at writing and communicating with people. Maybe I had a bit of impostor syndrome, as I developed this silly fear that if I graduated with a computer degree, I would end up working in some windowless office with little human interaction. So after taking two English classes that seemed interesting (Chaucer and Film Studies), I changed my major to English.

My junior year of college, I took a technical writing course. Although it was a required course for engineers, by this time I had switched my major to English. I think I just figured it would be a good course to take. Because it was a required course for engineers and there were a lot of engineering students, it was one of the biggest courses at the school. The largest lecture hall on campus seated 680. The professor would lecture there in-person one day a week, and recording of that lecture was replayed again in the same room later the week for another 680 students. As I recall, the professor didn’t keep office hours and all communication withim had to be in written form. I hated the class.

My final semester, I got really lucky. One of my buddies from the computer science program who had graduated a semester early happened to be visiting and mentioned that the computer software company he had gone to work for, Citrix Systems, was looking to hire a technical writer. He also said two of his co-workers would be on campus the next week interviewing computer science/engineering students. Although I didn’t have an interview scheduled, I went to the info session. At the end of their presentation about the company, they mentioned that they had an open interview slow and if by chance anyone present didn’t already have an interview scheduled, they should come see them. I jumped out of my seat and said “I’ll take that interview slot!”

The interviewers were not planning to interview for the technical writer position and weren’t sure what to ask me. So they asked me the same questions they were asking of the computer science/engineering students and I did my best to answer them. I hadn’t heard anything from the company, but since it happened to be located in my home town, I emailed them before my spring break to say that I’d be in town and would love to meet with them. They invited me to do a second round of interviews, which would take most of the day.

I wasn’t in the best shape when I went in for the day of interviews. I had all four my molars removed two days before and was still taking painkillers. Then I started coughing about 10 minutes into my first interview. The only cups they had were little 12-ounce styrofoam coffee cups, so I filled two at the water fountain and walked back to the interview room. 10 minutes later, both cups were empty and I was coughing again. So the interviewer and I walked back to the water fountain so I could refill the cups, continuing the interview as we walked. This went on for 4 or 5 more interviews. Amazingly, a few weeks later they offered me the job.

I wasn’t sure I wanted to work as a technical writer, but I was about to receive a degree in English (with a minor in Sociology) and I didn’t have any other job prospects. Plus, since the company was in my home down, I could live at home at first and see if I liked the job. If I didn’t like it, I was free to move somewhere else at any time.

I spent 4 years working as a technical writer for Citrix. I loved the job, the company, and my co-workers. My job was to write the printed and online documentation for Citrix’s one product (at the time): a remote, multi-user version of Windows server.

I feel incredibly lucky to have landed such a good job right out of college. During my time at Citrix, the full-time editor whipped my writing into shape, I learned the ins and outs of the product, and I became an expert with the tools of the trade: Microsoft Word and RoboHelp (used to create online help for Windows applications). After a year or two, as we hired more writers, I became a mentor and team leader on various writing projects. I even got to travel to England to help another office with a project, and to Salt Lake City to learn more about the process of translating our software and documentation to other languages.

What’s a Technical Writer & what makes a good one?

What’s a technical writer?

Many jobs these days involve writing. Authors write books. Journalists write articles. And almost everyone writes emails. The Bureau of Labor Statistics defines technical writers as people who “prepare instruction manuals, how-to guides, journal articles, and other supporting documents to communicate complex and technical information more easily.” I jokingly describe the job as translating geeks to non-geeks.

There are lots of books that attempt to “communicate complex and technical information more easily”, but not every book does this. A novel isn’t a technical document, and technical writers don’t typically write book-length documents. If they do, they’re usually meant to be reference documents, not the sort of book you sit down and read cover-to-cover in one go and then never look at again.

A journalist can be thought of as a type of technical writer, but if they’re writing for a general-circulation newspaper, they’re not going into much detail and thus their writing isn’t very technical. On the other hand, a journalist working for a specialized publication like Astronomy Magazine would be much more technical. Another common difference between technical writers and authors is that authors are usually named and technical writers are usually anonymous. But let’s think of the line between journalism and technical writing as a fuzzy one.

Another thing that differentiates technical writers from other careers that involve writing is that the technical writer’s primary job is to communicate. A scientist who writes an article for a scholarly journal is primarily a scientist. But because so many jobs involve technical writing, it’s an important skill to develop even if your title isn’t technical writer.

What makes a good technical writer?

The basis for technical writing is writing, and the basis for writing is language. It should be obvious that you need to be very fluent in whatever language you’re writing in. That doesn’t mean you need to have a huge vocabulary, because you don’t want to use words that your audience doesn’t understand. But you do need to make sure you don’t misuse words and you need to use good grammar in your writing (i.e. you know the difference between there, their, and they’re).

Another really important trait of a technical writer is being able to learn new topics quickly. Many technical writers do not have a formal education in the field they’re writing about. Some do, and this can be tremendously helpful, but it can also pigenhole you into a certain field. It can also be harder to write for a general audience if you’re so enmeshed in a field that you don’t realize when you’re using jargon.

Your task in learning new topics will be aided by Subject Matter Experts (SMEs). These are the people (usually fellow employees) you go to with questions. Another skill that’s important for technical writers is to be able to develop a good rapport with SMEs. Invariably, a deadline will change and you’ll have to do something in a hurry. And if you need a question answered in a hurry, you want to have a good relationship with your SME(s).

Lastly, a good technical writer needs to have an eye for detail. Some technical writers may have the benefit of working with a separate editor. But an editor can’t be expected to know if you’ve explained something fully or correctly. It’s common practice to have SMEs review your work, but they are not always the most careful reviewers. Ultimately it’s you that is expected to notice that one strange checkbox in the Settings screen for the application you’re documenting, or to ask what happens if the expected input isn’t received.

If you’re a technical writer and think there are other traits that are important, please share them.