How to break into the field of tech writing in the tech industry
A while ago I drafted some information on how to break into a career in technical writing in the tech industry, especially if you:
- Don’t already have software tech writing experience,
- Have limited experience as a software developer, and
- Know zero connections in the field.
I seem to have lost that draft in the Great Reshuffle, so here it is anew! This post describes my experiences in pursuing a career switch into software technical writing (in which I met all of the three points above) and participating in interviews for my current team. Despite not even being at my company for a year, I’ve had influence in hiring more than half the members on team!
Without further ado, how to ace your software tech writing interview.
Weave a story from your experiences
A good resume and cover letter can get you in the door for a phone screen. I didn’t write any cover letters but used the “Summary” section of my resume to explain how my varied background would contribute to my strength and potential as a tech writer. No experience should go wasted! Emphasize the most useful ones first.
Have software development experience? This helps you understand the lingo of other developers and bolsters the “technical” aspect of you being a tech writer. It also means you can read through the codebase, which can help you understand what goes on under the hood to convey to users.
Have research experience? So much of tech writing is about gathering the necessary information for the docs! Experience in research gives you the resourcefulness and perseverance to get access to notes, recordings, and face-to-face interviews to collect the information (sometimes completely out of your expertise) that you will later organize and write into coherent documentation.
Pro tip: In talking about your career journey, you’ll want to say where you’re coming from but also where you plan to see yourself. Hiring managers often look for someone who demonstrates interest in tech writing in itself rather than using the position as a stepping stone to another career.
If you don’t already have tech writing experience, it’s important that you weave your story into a concise, compelling elevator pitch on why you would be a great fit for a career in tech writing. Write it out, workshop it, and practice this in advance.
Prepare and polish your writing samples
Writing samples are key especially with limited career in tech writing. Hiring managers ideally look for samples similar to what they envision you writing, for example API documentation. If you have absolutely nothing to show, build a project! Everyone starts somewhere, even if it is a custom made potion shop application purely developed so that you can document it.
Some tech writing positions involve responsibilities such as putting together release notes, contributing to the company blog, or training developers to be better writers. If you have experience with product/project updates, blogging, or teaching (e.g., writing lesson guides), these can supplement your writing samples.
Boost your understanding of software tech writing
You might think: “I know how to code, and I know how to write. I’d be such a great tech writer!” While this might be true, there’s a lot more that goes into tech writing than meets the eye. Tech writing is more than just content authoring. You must also consider the following.
- Think about the audience, and multiple personas that comprise the audience (e.g., developer, administrator, product manager).
- Think about the tone and approach you take to present information. My favorite mindset for this:
Assume your audience has zero knowledge, but infinite intelligence.
I learned about this framework in grad school when preparing research presentations, and the same applies in technical writing. - Think about coherency and consistency with the rest of the docs. Keep all docs consistent in tone and style. Don’t take a conversational approach in one doc and a formal, rigid tone in another doc. I conducted an editing interview exercise in which the interviewee had half an hour to edit a poorly written doc. Over three interviews, only one person asked before editing: what was the tone of the rest of our docs. That guy is currently on the team. 🙂
- Think about the big picture of software documentation. Great technical documentation empowers users, not frustrates them. Technical documentation isn’t just about capturing information. It’s about presenting it in a way that’s easy to read, usable, and actually helpful for your audience. Documentation isn’t one size fits all. Sometimes you want a snappy how-to guide, sometimes you’ll want more information-dense reference guides. See The documentation system for more information.
Look for resources on software technical writing. Here are two that I found particularly helpful:
- Google Developers — Technical Writing One
- PluralSight — Technical Writing: Documentation on Software Projects
Differentiate what makes good and bad technical writing
Building from the section above, you should be able to describe what kind of writing makes for clear, concise, and helpful documentation. Once again, this wasn’t something I prepared ahead of time. But I used my previous experiences in scientific writing to be able to discuss this point.
Here are a few recommendations for good technical writing:
- Prefer active voice instead of passive.
- Refer to things clearly instead of using ambiguous pronouns (e.g., this, that, it).
You don’t need to be able to recite some style guide, but recognize and convey what makes writing easily digestible, especially as you will be covering concepts that may be highly technical in nature.
Have opinions on good and bad docs
Several hiring managers that I interviewed with wanted to know what I saw as good and bad docs. I didn’t know to look this up in advance! Fortunately, I was working on a side project with a start up in which I frequently referenced the API docs for some large social media companies. One of the doc sets was easy to navigate and pleasant to use, another was confusing and hard to understand.
You should be able to give examples of good and bad docs and explain your reasoning. It was through my interviews that I learned that Stripe docs are considered gold standard for reference docs. You can find information out there through Google (example). But you should also do you own homework and maybe even try out various doc sets, for example using Postman for API docs, to better form an understanding of what makes good docs. After all, if some docs are confusing for you as an aspiring tech writer, it might also be confusing for readers who actually want to use the product!
Research the company, research their docs
Most general interview advice includes a call to research the company that you’re interviewing at. Quiz yourself. You should be able to explain what do the company does, what is their major product, who are their customers, etc. It will be very obvious if you try to BS your way in answering “Can you describe our software stack?”
Before your tech writing interview, you should do additional homework in researching the company by going through their docs.
Specifically:
- What are your overall opinions of their docs?
- What do you think could use improvements in their docs?
- If there is a quickstart or entry level tutorial, do it!
Ask your own questions
Every place differs, but you should have a good idea of what you’re getting into. After all, an interview is as much as you interviewing the company as the company interviewing you.
Things to consider for a tech writing position:
- Will you work as the only tech writer or as part of a team?
- Who are the types of subject matter experts (e.g., engineers, product managers) that you’ll work with?
- What are the preferred methods of obtaining information (e.g., email, Slack, face-to-face interviews)?
- What is the documentation framework, and what tools will you use?
- If the company has an extensive software stack, what area of the product will you work on?
- Who do you see as the primary audience of the docs?
- How do you prioritize competing docs requests?
My experience, by the numbers
Here was my experience from interviewing for my first software tech writing position. I had no referrals or no connections for any of these job applications. Keep in mind that this was during a period of time in the labor market called the “Great Reshuffle” or “Great Resignation” so that may have improved job prospects. (In contrast to the last time I applied for jobs at the start of the global pandemic.)
- Applied to 25 companies over a 4 week period
- Heard back from 6 companies
- Conducted full interviews with 3 companies (including phone screen, hiring manager interviews, “virtual on-site” interviews, leadership interviews when included)
- Received offers from all 3 companies
- Withdrew from 3 companies (one due to budget constraints, two because I already had offers)
For the three positions for which I received offers, one did not list experience requirements, one listed 5+ years, and one listed 8+ years.
For the three offers, the salary range was between 110-150k. For the offer I accepted, I negotiated my salary an additional 5k. Talking about salary is iffy in our society, but I think we need to be more open about sharing this information, so we can address things like the gender wage gap.
Closing
That concludes my advice and experience! If you are looking to change fields in software technical writing, I hope this was helpful for you. If you are already working in the field, please share your own experiences in the comments below. For anyone who wants to chat further, my email is always open.