evaluating resumes

[cellio]

On a tech-writing mailing list people were talking about red flags in resumes (for tech-writing positions, I mean). Most people were talking about content issues, so I raised formatting.

Specifically: if you send me HTML (or a URL) I will inspect your source, and if you send me a Word document I may examine the structure of your document. (Word isn't a core tool at this job, so I don't care as much -- but I still care a little.) This is because I care not just about what you write but whether you have some basic tools-usage clues. For example, I've seen resumes that claimed HTML proficiency, but when I looked at the source I saw that it was Word's generic export (which is really really awful HTML). If you and I (and the hypothetical other members of my team) are going to be working on the same source files, that won't do. Similarly, I'd like to know if you're using headings or hand-modifying those paragraphs to be bold and a bigger font. Stuff like that.

Someone complained that I put too much emphasis on tools, but I don't think I do. I haven't set the bar especially high, and it's one of several factors I consider. But I consider poor use of tools on the resume or submitted writing samples to be in the same broad category as awkward writing and grammatical errors -- everyone makes those mistakes at times, but if you do it on something as important as your job application, how much will you do it once I hire you?

If I were interviewing a programmer who showed me a really snazzy demo, but the source code was a tangled unmaintainable mess, I wouldn't care too much that he'd written snazzy code, because he wrote code that no one else will be able to maintain (and that he probably won't be able to maintain in six months). Doc source is no different. Your content and your methods have to be good or there will be long-term pain. If there's going to be long-term pain, I'd like you to do it somewhere else. :-)

I'm not saying that I'm going to reject the otherwise-perfect applicant who uses a hard-coded "bold + font+2" or whatever, but it's not the otherwise-perfect applicants who have to worry anyway. It's the folks who aren't clearly better than the rest of the pack.

As an aside, I personally don't send Word source files any more unless that format is specifically requested. I send PDF instead. Different versions of Word render differently, and I've seen some pretty bad formatting that I'm pretty sure the sender didn't see on his end. I don't want that to happen to me.

Comments

[ichur72.livejournal.com]

Even though I haven't been in your exact situation, I know what you mean. I have fought a similar battle trying to get my employers to hire people with solid writing skills. When you make your money by printing a newspaper or monthly reports, you need people who will not turn out gibberish that sounds like it was badly translated into English after being translated into Swahili by someone whose native language was Chinese. It is possible, if you have good editors, to clean up prose like that. But editors do better (and work faster) if they have good source material to begin with.

[cellio]

you need people who will not turn out gibberish that sounds like it was badly translated into English after being translated into Swahili by someone whose native language was Chinese.

It sounds like we've read some of the same documentation. :-)

Yes, editors help. But sometimes, in small groups for instance, you might not be able to afford the luxury of an editor, so it's even more important that you get it right in the first place. And besides, editing to fix a systematic mistkae is a PITA.

[ichur72.livejournal.com]

>> It sounds like we've read some of the same documentation. :-)

Perhaps -- are you familiar with the joy that is BBC Monitoring Service? Great material, if you're a journalist, but reading it will give you a headache or fits of giggles 9 times out of 10.

As far as editing goes -- I have also had difficulty convincing my bosses to adopt a company "stylebook". Personally, I think they're great -- it means you can check all writing against a standardized outside source. But the two bosses I'm thinking of both thought I was nuts, which left me in the position of doing things like trying to reconcile work from two people who used commas very differently and explaining repeatedly when hyphens were and were not necessary.

[cellio]

Perhaps -- are you familiar with the joy that is BBC Monitoring Service?

Nope, 'fraid not. Most of the documentation I've read that I would characterize that way comes with household appliances, now that I think about it. (So Japanese, not Chinese. :-) )

Style conventions are a good thing to have. Maybe you could start collecting candiate entries for an in-house one -- if you show your boss that you really do have inconsistency now, he might agree that acquiring a standard is easier than having you write one or spend valuable time marking up the same differences over and over again. At the very least, you can start building a FAQ so you only have to write the hyphen explanation once. (I did something similar when I was the style guru for my group at a previous company.)

[ichur72.livejournal.com]

>> Style conventions are a good thing to have.

Yes. I have tried suggesting an in-house style book to my present employers before but was shot down in flames. Part of the problem I run into is that many facilities in the Russian oil industry (companies, refineries, fields, etc.) have more than one "name". It depends on the transliteration, whether you go with abbreviations, all sorts of stuff. I use the same ones consistently because I've been doing this for nearly 9 years now. The people I'm dealing with don't have quite that much. (They're also British, which leads to other interesting differences.)