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

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