Over the past few years I’ve talked to a number of people who are interested in getting into the technical writing field. After years of meaning to do this, I finally took some time to write up the thoughts and resources I typically share with people looking to get into the field. This is far from a comprehensive guide and notably doesn’t include much specific resume or cover letter advice.

I worked as a technical writer at Google for almost 7 years. (And wrote this blog post for Google’s The Keyword back in 2021, which captured my own journey into technical writing.) During that time, I interviewed a lot of candidates, including some people who were switching careers. Now, I’m a freelance technical writer and have spent a lot of time refining my resume and applying to jobs.

What even is technical writing?

At a very basic level, technical writing is writing instructions for users. Those users might be software developers trying to build something or regular people trying to log into their email account.

My experience is working for tech companies making software products. But technical writers write for and often specialize in other fields: biotech, financial tech, edtech, nonprofit, hardware…and a bunch of others, including ones I’ve probably never even heard of. I’m most familiar with software, and within this field there are further divisions: do you write for internal or external audiences? Do you write for technical (like software developers) or nontechnical users? Endless divisions, but also endless ways of specializing. There are also lots of opportunities for people getting into technical writing from a wide array of different fields.

Technical writers have a big range of technical abilities. Some are literally ex-engineers. Others have very little experience writing code, but write for nontechnical users so that works.

Resources

Here are some general resources on the technical writing field:

  • Write the Docs community. The site has some good resources on the field (including salary information and a hiring guide). The Slack group is super prolific and contains a ton of channels on topics like AI, jobs, resume review, etc.
  • I’d Rather Be Writing blog, written by technical writer Tom Johnson. Pretty much every technical writer I’ve ever met knows about this blog. There’s lots of information on the field of technical writing. There’s also a free API documentation course. While I haven’t taken this course myself, I’ve heard it can be good for producing writing samples or just learning about API docs (a popular speciality within technical writing).I read this blog religiously when I was a technical writer intern almost a decade ago. I still check in now and then to keep up with trends.

Framing your experience

A lot of technical writers are on their second, third, or fourth careers. I know technical writers who used to be journalists, professors, teachers, and engineers. To successfully switch into technical writing, you need to have (and, perhaps more importantly, prove you have) two main things:

  • Writing skills – can you write?
  • Technical skills – can you do things with technology?

These definitions are intentionally vague because you can demonstrate these skills in so many different ways. One job might require Python; another might require Java; another might be okay with any common language because it demonstrates that you can learn new technologies.

Web development (Markdown, HTML, CSS, GitHub/version control) skills are broadly applicable to many technical writing jobs because many technical writing jobs use these technologies to publish and update their docs. (Not all, though! I interviewed with a company that used Microsoft Word to write all of their docs.) I think the best way to approach technical writing as a field is to figure out what you’re good at, what skills you already have, and what skills you can refine or add. Then, look for jobs that align.

You will probably be able to frame some of your past work as relevant technical writing experience. Of course, it’s not all about framing. You also might just not have the background. You might decide you need to go back to school, or do a certificate program, or teach yourself some new skills. But if you have some kind of experience doing something technical and some kind of experience writing, I’d think you’d probably be able to make a go of it:

  • If you’re a software engineer looking to break into technical writing, you’ve probably written documentation in previous roles. This is technical writing experience, and you can emphasize it in your resume. Lots of tech writing roles are specifically looking for people with engineering experience.
  • If you’re an English teacher who took one Python class in college, you could start by brushing up on your Python skills and maybe making a simple app. Maybe you could look for opportunities in the edtech space. You could focus on curriculum developer or instructional designer jobs, which typically fall under the technical writing umbrella but require more extensive learning design and teaching experience.

…and there’s a lot more examples. I’m going to leave it at that because technical writing is a huge field, and I only consider myself really familiar with technical writing for software developers. Also, framing your experience is really personal and I don’t consider myself a resume expert by any means.

Besides thinking about your background and what skills you bring to the table, I don’t think there’s any way to get better at learning about what kind of jobs you should focus on than literally just looking at a ton of job postings. Technical editor, technical writer, science writer, curriculum developer, content strategist, technical content writer – and there are so many more variations. Search a lot on job sites. Look at people’s LinkedIn profiles who have job titles you think are cool. What kind of skills do they have? Figure out what kind of companies you think are interesting. Even as an experienced technical writer, I did all of these things to figure out what kind of position I wanted next.

Getting writing samples together

After you have a rough understanding of the kinds of jobs you’re looking for but before you start actually applying to jobs, it’s crucial to have writing samples. Many (most?) technical writing jobs require writing samples, typically alongside the initial application. (Though some companies ask for them later in the process.) Especially if you’re new to technical writing, writing samples are the number one way you can demonstrate your skills. Yes, there’s interviews and often take-home assignments, but you need to prove your skills before you even are able to get to those stages.

If you’re just getting into the field, you might not have a relevant writing sample. When I was going through the application process for Google back in 2017, I literally submitted an academic paper I wrote as one of my writing samples, though I had a couple more relevant samples from my tech writing internship the prior summer. When I left Google in December 2024, I once again found myself in need of writing samples. The tutorials I wrote for my internship in 2017 were too old (in my own opinion). Plus, I’d grown so much as a writer since then. However, almost all of my work at Google was for internal engineers and thus wasn’t shareable.

My own writing samples

After a bit of trial and error (error = getting a lot of rejections!), I wrote a few samples that I’ve had pretty good success with. (Success to me is getting to the initial interview for a job that requires writing samples upfront.) Here they are:

These aren’t really traditional “technical documentation” and I didn’t write them for a company, but they show a couple of critical things:

  • The Kobo library books sample shows that I can write a tutorial about something (sort of) technical. I wrote about managing library books on my e-reader because I constantly struggle with its slow interface and various quirks. When people ask me where to start with writing samples, I recommend writing about some kind of technical problem they faced, their process, and ultimate solution.
  • The LLM sample shows that I can effectively teach myself a new technology, implement something real with it, and then write about it. Sometimes, people I talk to about technical writing can’t think of a technology or product they know well enough to write a tutorial on. Or, maybe the things they can think of are already thoroughly documented. In that case, I advise people to teach themselves how to do something technical and then write about it. I personally used Claude to teach myself something because I wanted to demonstrate technical ability AND the ability to use AI (an important, of-the-moment skill for technical writers) as a tool.

Even better, I published these samples on this site, showing my experience with GitHub, web development, and version control.

Looking for jobs

To actually find jobs:

  • Join Write the Docs Slack group, and the job-posts-only channel specifically. You just have to be interested in technical writing to join. The job-posts-only channel is really active and I’ve gotten a number of interviews from it.
  • I saw this post on LinkedIn recently about contract job boards at some of the big tech companies.
  • Indeed and Dice are good for contract jobs, perhaps better than LinkedIn although most things are cross-posted against all channels.

I’m not a huge LinkedIn user, but Sarah Goose and Brenna Lasky are two people I follow on LinkedIn. They have direct experience with tech recruiting, and provide good insight on the job market, who is hiring, and how to frame your experience in interviews. Like me, their backgrounds are in Big Tech.

Takeaways

  • Technical writing is broader than you might think. You don’t need to be an ex-engineer writing API docs. Many careers that involve some amount of writing and working with technology can translate well to technical writing, which brings me to the second takeaway…
  • Your experience is more relevant than you realize. Whether you’re a teacher, marketer, or engineer, you likely have transferable skills. The key is learning to frame documentation you’ve written, teaching experience, or technical problem-solving as relevant technical writing experience.