Link Search Menu Expand Document

Application

Where to look for a job?⎹ How to search?⎹ What to expect from the interview?

Where to look for a job?

Networking can do wonders. Try to get in touch with the community in any way possible: open-source projects, conferences, courses etc. Don’t forget to make a LinkedIn profile and join the Facebook group Tworzenie dokumentacji.

You can look for job offers through dedicated websites:

Naming conventions for technical writing posts vary a lot. To find a job where your tasks should reflect what we cover in this guide, try searching for:

  • Technical writer
  • Technical author
  • Technical document writer
  • API writer
  • Specjalista ds. dokumentacji
  • Dokumentalista

To avoid unpleasant surprises, focus on listed responsibilities rather than on job titles alone. If an offer mentions common technical writing concepts or tools, then it’s probably a good bet.

There are other tech- and content-related jobs out there that you might consider: UX writer, marketing writer, content writer, copywriter, SEO writer, and so on. Who knows, maybe you’ll find them more interesting than technical writing proper (if it’s even a thing). Besides, any technology- or writing-related job could be a good starting point to get into technical writing later.

IMPORTANT: Some employers don’t get this quite right. You might see offers for “technical writers” when in fact they are looking for “content writers” (or “technical content writers”, confusing as it gets), which without enough context can mean many things. That is not to say content writing, marketing, SEO, and the like are bad career choices. Just make sure you and your recruiters are on the same page.

What to expect from the interview?

You can definitely expect stress, followed by a question on how well you handle stress. Then there’s the boilerplate “Where do you see yourself in five years?”, various “soft skills” questions, and so on. You know the drill. Here we will cover only those questions and interview tasks that are specific for technical writing posts.

Questions

Apart from questions about your motivations and experience, you can expect some field-specific and technical topics. Those will vary, so look for hints in the listed requirements. If it’s API documentation, you should probably know how endpoints work. If it’s writing docs for a web app, be ready to explain what HTML, HTTP, IP, or the Internet is (sounds easier than it is!). If it’s corporate process docs, find out more about the company you’re applying for: their policies, structures, management frameworks, and so on (whatever is publicly available). You get the idea.

Other questions may concern issues that technical writers deal with on regular basis. For example:

  • What types of deliverables do you know and what are they good for?
  • What would you start a documentation project with?
  • What do you do if your SME is absent and you need their input?
  • How would you deal with an SME who is busy or unresponsive?

If you have read the previous sections of this guide, you can probably answer these by now!

Tasks

In the process of your recruitment, you may be asked to complete certain tasks designed to test your skills. These can take the form of a short exercise during the interview, or a longer assignment for you to prepare at home.

An example of the former would be an “ELI5” (“Explain Like I’m Five”) description of a technical concept: API, single sourcing, or similar. Sometimes you may be asked to prepare short instructions for some obvious, everyday activities, e.g., “how to use a nutcracker?” or “how to search for images in Google?”. Silly as it may sound, such tasks help to determine how well you can recognize and break down steps in a process and how clearly you can organize and present your thoughts.

Longer assignments may concern a specific tool, standard, or technology. For example, you could be asked to use DITA in OxygenXML to recreate the TOC and folder structure of a PDF you get from your recruiters. An easier variant of that could be to rewrite a document in Markdown or HTML, for example.

Recruiters often check whether or not you can adjust your writing to a specific audience. You may be asked to prepare a user guide for two different personas: one for an engineer and one for a product owner, for example. In this sample scenario, the documented product could be some imaginary software, and your recruiters would give you a rough description of said software as an input.

The examples provided above come from actual, real-life interviews1. We considered junior positions here, though interviews for mid-tier posts could look similar. Take this as an encouragement. Don’t let job requirements scare you. Some employers list 1-3 years of experience, but they may still take you on as long as you have the right skill and something to show for it. It’s always worth trying. Hit them with your private projects for extra points!


  1. Hat tip to Michał Olender for sharing his experiences. 


Next section: Conclusion