Lorem Ipsum

I've interviewed a lot of tech writer candidates in my past few jobs, and it occurs to me that it might be worth posting some notes about things to do and think about when you're applying for a tech-writing job. I am, of course, making these recommendations only as myself, and not speaking for my employers or anyone else. Other interviewers may disagree.

Also, this is not a comprehensive guide on how to apply for tech writing jobs; it's just a discussion of a few common problems I see in applications.

Before the interview: Resume, writing samples, and other prep

Have a friend look over your resume.

Your resume is the first thing an interviewer is going to see about you. If you want them to hire you to communicate with the written word, your resume should demonstrate your ability to do that.

I've seen people screening resumes who'll immediately discard any tech-writer resume that has a typo on it. I don't do that, because I know that resumes are hard to write; even really good tech writers often seem to struggle with writing clear, brief, coherent, typo-free sentences in a resume. I know I do; last time I applied for a job, my own resume got much better when a friend gave me feedback on it. But be aware that some people (especially some tech writers) have very little tolerance for mistakes in resumes.

So don't rely only on yourself to get your resume right, no matter how great a writer you are. Have someone else look it over, ideally someone who (a) is a good editor, and (b) has done interviewing or resume screening before. At the very least, make sure there are no typos or grammatical faux pas in it; but beyond that, if possible, also make sure it does a good job of clearly but briefly describing your work and your skills and your accomplishments.

Demonstrate your writing skills with your samples.

When you're asked for writing samples, submit samples that are appropriate for the job you're trying to get. If you don't have such samples, then be upfront about that and give some other indication that you can do the work. The purposes of a writing sample include (a) showing that you can write well; (b) showing that you're good at technical stuff; and (c) showing that you can do the particular job that you're applying for. So (for example) if you're interviewing for a position as a developer-doc writer, then your samples should be documents aimed at a developer audience if at all possible.

Also, take a look at each sample you're submitting. Does it have obvious typos in the opening sentence? If so, then clean it up, or explain it in a cover letter, or use a different sample.

Also, re-familiarize yourself with the general idea of your samples, even if you wrote them a while ago; some interviewers will want to ask you about them.

One more thing about samples: They should be comprehensible to non-specialists. If you have a document that brilliantly explains how to do something, but nobody outside a tiny subfield even knows the vocabulary, then your sample doesn't achieve its goal as a sample. (Unless you're applying for a job in that subfield.) I've seen a lot of samples that were incomprehensible to me because I was outside of the target audience. If the only samples you can provide require domain knowledge that your interviewers may not have, then consider providing an introductory paragraph giving some background and context for each sample.

Take a look at some of the documentation produced by the company before you come in for an interview.

There are two main reasons to look at the company's docs: (a) If it turns out that the kind of docs you'll be asked to write for this job aren't a kind that you like writing or are good at writing, then maybe this isn't the job for you, and you should probably find that out before you interview. (b) The interviewers may ask you what you think about the company's docs, and you should have an answer ready, including any criticisms you might have.

Attribute other people's work.

If some part of a document you're providing with your job application was written by someone else, then say so. For example, if you copied and pasted some sample code from somewhere, then make clear that you did that; otherwise, a casual web search for the unusual variable name you copied (for example) might lead the interviewers to wonder whether you cribbed the whole document from someone else.

During the interview: answering questions

Demonstrate your technical abilities.

During an interview, if someone asks you questions about a technical topic, don't be afraid to get technical in your response. Your job as a tech writer is, in essence, to provide technical information in a form that makes sense to your audience. So do that, right there in the interview: figure out who your audience/interviewer is, and present technical information to them in a way that makes sense to them. In particular, part of what they're probably looking for is evidence that you really understand the topic, so be sure to include technical details as appropriate.

Be prepared to think on your feet.

Chances are pretty good that an interviewer will ask you some sort of question that requires some creativity on your part. Obviously you can't memorize answers for that kind of question; I'm just saying be prepared for it, and don't be thrown when it comes up.

Take your time.

There's this standard interview-candidate technique where as soon as the interviewer is done asking the question, the candidate starts talking about any old unrelated thing that pops into their head, while they figure out the answer to the question, and then when they've figured it out, they say it. Don't do this start-talking-immediately-about-unrelated-stuff thing. It doesn't make you look clever or quick; it makes you look like you have a hard time staying on-topic, and/or like you're dodging the question. Instead, think in silence for a moment, or say something like ”Good question, let me think about it for a minute.”

Or else talk through your thought process. Chances are pretty good that if they've asked you to solve some kind of problem, they're at least as interested in your thought process as in your getting the right solution. So in that context, talk through what you're thinking. Don't be afraid to use a whiteboard, or paper, or a computer screen, or whatever other tools are at your disposal.

Be guided, at least to some degree, by the interviewer

In some fields, I'm sure it's a good sign when the candidate repeatedly takes control and steers the interview into what they want to talk about. In tech writing, that's not a good sign. If you take every opportunity to insert your rehearsed talking points about how great you are, the interviewer will probably notice; that's not as subtle or clever a thing to do as it may seem. The interviewer, like a reader of your documents, probably has things they want to find out; you can choose how best to present that information (it's fine to be natural and friendly and to volunteer relevant information that wasn't requested and so on), but do help them get the information they want, and don't try to change the subject to talk about the things you want to talk about if they're irrelevant.

Again, this is by no means a comprehensive guide; just some assorted topics. I may add stuff over time, if I think of more.

Note: By a sort of corollary to Hartman's Law of Prescriptivist Retaliation, it seems quite likely that I've made some writing mistakes in this discussion. So it goes.