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

[siderea]

Teehee. Back when I was a "word processing" temp and a resumé was something on nice bond paper, I did my resumé in LaTex. At the bottom it said, "This resumé typeset in LaTex X using emacs Y." I had the source code printed on the back. It was sooooo cool to hand an interviewer my resumé, burble about it a bit, and then say, "And, of course, the source code is on the back" taking gently from their hands and turning it over. The look of total awe on their face was usually priceless. :)

[cellio]

That's great!

Back when I did my resume in Scribe (this was before I encountered LaTeX) I did once note that fact at the bottom, but I never thought to include the source on the other side.

Ah, the memories of those days, back when there were serious debates about optimal paper weight and color. I'm glad to be done with that part of the resume dance.

[steven.livejournal.com]

God bless Adobe Acrobat. It has allowed me to send Quark-created documents to everyone. And now that Quark can export directly to PDF, I'm giggling like a schoolgirl.

Okay, not quite like a schoolgirl, but you get the picture.

[cellio]

Indeed. The person at the other end shouldn't have to know or care what tool you used to produce your resume. And if you can demonstrate that you know the difference between source material and delivery vehicle, and when to hand over which, so much the better. (A fine point to be sure, but I notice when people seem to know it.)

[zare-k.livejournal.com]

I think that's perfectly reasonable and would do the same if I were hiring someone. But then, some people think I'm weird because I still do HTML coding by hand.

[cellio]

I always hand-write my HTML (and XML). Why force a tool to guess what I want when I already know what I want?

I had a few conversations at SIGDOC that went like this: "What tool do you use to write your XML?" "Emacs." "Is that like NotePad?" "Better."

Sad

[caryabend.livejournal.com]

I had a few conversations at SIGDOC that went like this: "What tool do you use to write your XML?" "Emacs." "Is that like NotePad?" "Better."

Lemme get this straight:

1) You went to a technology conference about the design of communication.
2) It would follow that participants would either know about or wish to learn about tools and methods to facilitate or improve communication.
3) You have indicated in this forum a preference for writing your markup by hand, though others at the conference may not have this knowledge.
4) When asked about the tool you use, you mention a very well known and powerful *nix based program.

To this point, I'm good, but it goes on.

6) The questioner does not recognize the package.

Strange, but still within acceptability. Not everybody gets the chance to use *nix-based systems, so there's still a very real non-negligible chance that the questioner has little or no exposure in this area.

7) The questioner the asks for a clarification of the unknown software package by making a comparison with a known one.

This is good. It shows promise.

8) For the known quantity, the questioner chooses the lowest common denominator, most bare-bones text manipulating tool available (within a certain subset), rather than a well regarded, or recognized tool.

It got off to a shaky start, almost looked good in the mid-game, but then goes down in a giant fireball in the end.

To be fair (and generalized), emacs is a text editing tool, albeit a really powerful one.

This must have become mind-numbing shorty after the questioner starts to speak.

Now for the SAT:

Notepad is to emacs as leaky faucet is to Niagara Falls.

Of course, any minute now, somebody will claim to use tin cans and fishing line for the express purpose of Trans-Pacifc phone calls.

Sheesh, Abraham lincoln was right about the "open your mouth" part. Washington claimed to have never told a lie. But I bet that's because people seem too stupid to get it right. :)

Re: Sad

[cellio]

Near as I can tell, most people out there -- including most people at this conference -- either don't do markup explicitly (e.g. they're doing WYSIWYG, not semantics) or use tools that do the details of the markup for them (so they indicate a semantic characterization for a block of text and the tool fills in all those messy angle-brackets and dependencies and stuff). The proportion of people doing our own markup seems to be decreasing. Granted, tools like this lower the barrier to entry, and that's not a bad thing if there are talented writers joining the ranks this way, but it's just not my style.

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

[jducoeur]

It's funny -- I still write most of my HTML by hand (unless it's tabular data, which is too much of a pain in the ass), but I will almost always go for an IDE for my programming these days. I think it all boils down to convenience. A WYSIWYG HTML editor speeds me up only marginally for my content-heavy pages, and usually produces such bad (and sometimes incompatible) HTML it makes me wince. But a good IDE saves me a huge amount of time and hassle, just by doing on-the-fly syntax and type checking.

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...

Re: Sad

[sethg]

I suspect that the vast majority of tech writers in the Windows universe use MS Word (plus RoboHelp, if they do online help). A significant minority use FrameMaker (plus WebWorks, ditto) or perhaps DreamWeaver. A very very small number, these days, might be using XML-specific WYSIWYG tools.

If this is all you're familiar with, then the closest point of reference for Emacs is NotePad.

[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.)