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.
Re: Sad
Date: 2004-10-22 06:04 am (UTC)IDEs for programmers have become more common, too. There are some nice things about both (IDEs and doc tools), such as having the set of valid options presented to you so you don't have to remember or check the DTD or whatever. But the price of a little bit of convenience can be a little bit of knowledge and versatility. Next time I'm learning something new I'll try the handy tool, but for domains I already know (HTML, Java, etc), I'll stick with the editor I've been using comfortably for (eek) almost 25 years.
Re: Sad
Date: 2004-10-22 01:38 pm (UTC)Indeed, this discussion reminds me of a point I read some time ago -- might have been from Joel on Software, but I'm not sure -- about interviewing programmers. It recommended not just asking them to program something on the fly, but *watching* them write the program, because experienced programmers tend to work differently. The specific point it made was that longtime programmers will usually write a block by putting in both the opening and closing braces first, whereas novices will usually not add the closing brace until the end. And an experienced Visual Studio programmer almost never types full variable names -- he begins typing the name and lets it autocomplete without breaking stride.
Very subtle point about tool use, and how you can use it to figure out someone's real level. It isn't just knowing which tools to use, or what output to get -- the experienced user often picks up very specific habits, to optimize their usage...