evaluating resumes
Oct. 21st, 2004 05:25 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cellioOn 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.
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.
(no subject)
Date: 2004-10-22 09:41 am (UTC)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.)
(no subject)
Date: 2004-10-22 11:55 am (UTC)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.)