Tech writing hiring freeze
I hope the title caught your attention, because if you are in the market to get hired as a technical writer, keep a watch on your calendar. In general, most companies stop hiring around the end of October (sometimes weeks earlier), and start again around mid-January. This often has to do with approved budgets for headcount, and also businesses just start hunkering down as the holidays approach.
What should I do about it?
I’m glad you asked. If you want to get into technical writing, maybe you have some past experience, have relevant skills without the experience, or just want to take a stab at it, I would recommend these action items (the other AI):
Update your resume. Add skills, any volunteer experience, a link to your portfolio website, or any new certifications related to tech or tech writing. Then format it carefully and proofread it again and again until it’s as perfect as you can get it. Remember, this is the first piece of writing your future employer may ever see. Ideally, have someone take a look at it, because they will often find mistakes you miss. Don’t take it personally, even the best make writers mistakes.
Upload your resume to LinkedIn internally. This is more complex than you might think. There are two places to do this. There is a place in settings which is only used internally to help with recommendations for jobs and connections.
In order to locate the internal upload page from their website:
Click on your picture where it says Me. Then Settings and Privacy > Data Privacy (on the left sidebar) > Job seeking preferences (also on the left sidebar) > Job application settings.
On the phone app, do this:
Click on your picture in the top left (the small one). Then…Settings > Data Privacy > Job application settings (under Job seeking preferences) > Job application settings.
You can upload your resume as a Doc, Docx, or PDF.
Upload your resume to your profile page (external facing). This can be seen by people in your network (who may have jobs available), or any recruiter or other possible employer. This is the real deal, the one people will actually see. Here are the directions to do this from LinkedIn.
Get the rest of your LinkedIn page in order. I’m not going to go into detail here, but update your intro, skills, possibly photo, about, experience, etc. Besides being an introduction to your experience and skills, this is again a writing sample, so go over it with a fine-toothed comb. Having someone else read through your profile page and your resume would be a good idea as well.
Once it’s all set, on your LinkedIn profile page, at the top, select the “Open to” button and choose that you are open to “Finding a new job.”
Then get back to work. If you’re learning new skills such as programming, get back to it. Just check your LinkedIn account from time to time (not 10 times a day) to see if you have a bite. Be careful of recruiters from outside your area who tend to be more of an annoyance, and could even hurt your chances by over submitting to companies on your behalf. If you go with a recruiter, find one that knows the business and actually has contacts in the companies they submit to.
I hope this helps you get ready before companies batten down the hatches, because winter’s on it’s way!
The Shakespeare Effect
When I was in college, working my way towards a BA in English, I took a Shakespeare class. Besides all that we learned during lecture times, we were required to read six Shakespeare plays outside of class. So, several nights a week I found myself reading through a Shakespeare play, and most of the time I was utterly confused. Many of the words were modern words, but many were also new to me. Since it was written as poetry, the phrases were odd and didn’t make much sense. Some ideas or historical references were also opaque. However, for these I had helpful notes in my textbook.
Night after night I sat down to read and got almost nothing for my labor…or so I thought. After about six weeks of continuous frustration, one night I remember reading as I usually did, but this time it seemed to make sense. This time I could follow the story, and I even understood the dialogue. It wasn’t that I understood every single word or reference, but I understood the bulk of the meaning, and the change occurred all of a sudden, not slowly. At least that’s the way it seemed. From that point on, I felt I could read any Shakespeare play and make sense of it, and for the most part, I did.
I have had this happen in other areas of my life, where I was trying to learn something completely new and somewhat difficult. Whether it was something about programming, or another subject, I found that if I pushed through when I was confused, there came a time when the light came on and it just “got easier.”
This happened to me a couple weeks ago when I was slogging my way through the Android course. Much of it has been foreign to me, and I find myself copying and pasting code I do not understand. Then one day a couple of weeks ago I felt like it was starting to make sense. But the truth is, I was still very confused. What happened? Here are my best guesses.
Putting things in boxes
I think I started to categorize things over all that time I was confused. While I didn’t understand anything specifically, I started to realize that some things could be lumped with other things. This became more clear over time. Strangely enough, just putting things in categories, makes them feel less overwhelming.
Part of the wonder of compartmentalizing knowledge is being able to wall off sections that are more confusing with the promise that I will revisit that area again and master it. Then I can focus on some parts I am starting to understand.
Accumulating what I know
I could just break everything about this course down into two areas. Things I know, and things I don’t know. At first everything was in the “I don’t know that” category. Now, over time I have started to put some things in the “I think I get this” area. This is an area I hold closest to my chest, because it gives me hope. Now I can say, “I may not know much, but at least I can say I know yada yada.” As that area grows, my hope increases.
Seeing patters
Having gone through a number of sections of this course now, even if I am confused, I can now say that I am noticing reoccurring patterns. There are ideas that are repeated, common terms being used, and procedures that come up again and again. When I see something multiple times, I start to realize that maybe the knowledge needed to master this course is not infinite, because they are already repeating themselves.
Seeing the larger picture
At the same time, I am starting to see the larger picture of Android development. How to think like a developer, the things I need to consider when creating an app, and how to troubleshoot apps as a whole to get things done. It’s all part of the larger picture. Most of the specifics are still fuzzy, but seeing the overall process and getting familiar with that makes me feel like I’m on secure ground. I may not get all the pieces and what they are made of, but I’m starting to see how they fit together as a whole.
Finishing an area of study to find that that’s all there is
This may be related to putting things in categories, but I have finished whole sections of the course now. Once at the end of a section, I realize that to understand that area of knowledge, I only have to understand those few lessons. It’s not infinite, it’s only three days of study. And I can go through those lessons as many times as I need to to understand them. Coming to the end of a section gives me hope that there is an end to come to. And that’s all there is to that topic. It has a beginning and an end, and I can always revisit it until I understand everything in-between.
At least I know Android Studio
Even if I don’t know what I’m doing in the code most of the time, I am starting to get quite comfortable with Android Studio. This by itself is a real accomplishment, and it’s an area of study in itself. It is one of the goals of the course as well. I can add this to one thing I can do, and it makes things seem more possible. Trying to learn both a software package and incomprehensible code at the same time is overwhelming, but now it’s just the code that’s a mystery, and that already feels better.
Conclusion
I’m still in the dark about a lot of what I’m doing right now, but I feel like I turned a corner. This feeling like I can do this comes in degrees. In a couple of months I will probably have such an epiphany moment happen again, but not until slogging through the hard stuff for awhile. It happens in stages, like steps. Strangely enough, it doesn’t seem to be so gradual though. It’s sudden realizations that “I’m getting this,” or “I can do this,” that make all the difference when learning a difficult piece of technology. We can only get to this point if we don’t give up. It takes pushing through for these epiphany moments. It’s how we learn the hard things to become something new. Or as Shakespeare said, “We know what we are, but know not what we may be.”
How do you handle the frustration?
Here’s the thing. I’m completely lost in this Android course. I’m copying and pasting code, and sometimes it compiles and works and sometimes it doesn’t. I get some of the concepts, but most are over my head at this point. I know if I slow down too much, I will get bogged down and feel like I’m going nowhere. With enough repetition, this will get better in later iterations. As long as I don’t stop. So how do I deal with this frustration? Feeling lost is normal when trying to learn something really complex. But I have gained confidence in recent years that I can learn almost anything if I do not give up. Here is what I found helps me keep going.
Keep the goal in mind
My goal is to get to the end and get this certification. It will be a big help at my current job, and opens up new possibilities. It is worth the trouble. Having that certification, and the knowledge from this course, can be a real help for my future. I imagine mentioning in on my list of skills in LinkedIn, on my resume, and my portfolio website. I can see it as a real boost to my career. Keeping that in mind is a real help.
Remember other times I’ve been here
This isn’t my first rodeo. I’ve been here several other times. Learning Java was really hard. I beat my head against the concept of object oriented programming especially. I had to read a number of articles and tutorials, and watch videos to get these concepts. But eventually, things started making sense. Learning Java was hard, but I did it. And I can do it again.For you this may be from the more distant past. I’ve mentioned how we all learned how to read, but at the start it was likely very confusing. We learned how to do fractions, but it was probably frustrating at first. Maybe it was even learning how to drive, or to play the guitar. The key is that we got through it that because we didn’t give up. If we could do it then, we can do it now.
Pace yourself
You have to know yourself. There comes a time when you have to step back. When the frustration increases exponentially as you try to push through, take a break or come back to it tomorrow. No problem, as long as you do come back to it tomorrow. I’ve found if I put it off for longer than a weekend, a feeling of hopelessness starts to settle in. I have to keep going, but at a pace I can sustain. Making regular progress gives me hope. It’s a kind of dance between moving forward, and not pushing when the frustration gets too high.
Remember the river rock
An author I read (Patrick Rothfuss) once mentioned how he revises his novels. He said the reason his novels seem so well crafted is because they are like river rocks. He revises a book over and over and over, a thousand times, until every rough edge is worn smooth. Learning something difficult is like that. Every time I go over this tutorial, something more will makes sense. I will add one more tool to my toolbox. And it won’t take me a thousand times to get there. Maybe just five. Eventually, the mysteries that are Android development will be mine!
Learning the hard stuff
The thing about getting into technical writing, is that most employers care more about your technical mastery than they do your writing ability. For that reason, one of the best ways to show your value is to prove your technical skills. The list of what you can learn is just about infinite, and choosing what will impress employers can be difficult. (See my spreadsheet if you are looking for how to narrow this down.)
Recently, I heard about Google’s Certificates (see my post on this), and decided that completing this course might really boost my current job value, as well as open up future possibilities. Since my employer, Amazon, is really supportive of this, I am currently working through the Associate Android Developer Certification course, also called Android Basics in Kotlin for some reason.
My goal here is to give you some thoughts on my learning journey, and how I approach learning difficult technical subjects in general. First of all, learning is hard. I don’t mean it can’t be fun, but learning something like a programming language can be difficult. My rule of thumb is to do everything three times.
The rule of three
When I first tried to learn Java, I realized I had no idea what I was doing. I read tutorials, some easier to follow than others, but mostly I was lost. I decided that maybe confusion was just a part of the process. We all learned to read. And it was hard. Someone showed us a letter and we were supposed to know what sound went with that letter. But wait, some letters have more than one possible sound. And some letter combinations can have more than one possible pronunciation. It was hard, but we did it because we had to. Eventually, those sounds made sense, but not because it got easier. It was because we didn’t stop with the confusion. We did it again and again. We pushed through.
If you are reading this, you can learn to program. I know this because you learned to read. But it’s the kind of thing that takes pushing through when you have no idea what you are doing. The rule of three for me means that I have to go through a complete course three times before I feel like I’m getting a handle on it.
My favorite tool for learning programming is Sololearn. You can use it as an app on your phone, or use the website version, or both (premium is best if you are willing to pay a little bit). When I tried to learn Java with the app, I had no idea what I was doing. I muddled through the quizzes, and tried their code a little. I was not writing code on my own. I was completely confused.
The second time, I took their existing code examples, and started making small changes to see what would happen. It was cool because I felt like I understood small pieces of things. Some puzzle pieces were fitting together for me. Still, much of it was a mystery, especially ideas like object oriented programming concepts.
The third time through the complete course, I pushed myself to try writing small programs on my own. Sometimes I would start with their examples, but then I would add other ideas from other sections of the course. I read people’s comments, or short articles on confusing topics. This time I felt like I was getting it. Even after this third time through, I never felt like I had it completely, but I felt like I was able to do this thing called programming. I felt capable, and less lost.
This pattern has repeated itself again and again. Later, I learned Python. It took three times before I felt I was getting it. And now, it’s the Android Development Course. Right now, I am going through it for the first time. I am copying and pasting the code they put in the examples. Eventually I get the code to compile and run on Android Studio, but sometimes I have to copy the completed code at the end because I missed something in the steps, or put something in the wrong place.
In truth, out of one thing I understand, there are at least four I do not. I am copying code that is a complete mystery to me. Some explanations make sense, and some go completely over me head. My hope, according to my experience, is when I do this the second time through, I will understand a lot more. I’ll let you know how that goes.
The important thing is to be okay with being confused. The ability to be confused and not give up is perhaps one of the superpowers of a good technical writer. None of us were born knowing this stuff. We have to look up things every day. The point is not to give up. Sometimes you have to walk away because the frustration is too great. I get that. Take a break. Go for a walk. Spend time with friends and family. Then tomorrow, do it again. Which leads me to my next point.
Do some every day
I have found the best way to do this, and not give up, is to do some every day. For me, working on this for up to 1 ½ hours is good. Sometimes I only get in 45 minutes. More than 2 hours and my brain is fried and I get frustrated, which makes it harder tomorrow. Less than 30 minutes and I feel like I’m not moving forward. If you have a day job, 30 minutes is great though, or maybe even 20 minutes. Not 5. But do it every work day, 5 days a week. Take weekends off. Then hit it again on Monday. If you do this, you will make it. Don’t rush it. It’s not a sprint. And it’s not exactly a marathon either. It will take a few months, but not years. You will see progress by the week, not by the day. At the end of a month you will be surprised at how far you’ve come. At the end of three, you might even start seeing yourself as a programmer. The important thing to understand is that it is doable. You’ve got this!
Google Certificates & Sololearn
As I have said before, when getting into technical writing, experience is king. But when you might have difficulty getting experience, the next best thing you can do is gain technical know-how. I’ve recently stumbled upon Google Certificates. These are courses that are offered either through Google or through a partnership with Google and Coursera, and they are intended to help people get into high-growth technical jobs.
According to their site, 82% of Certificate graduates report a positive career impact in six months, though so far, these statistics mostly come from the IT Support course, which was their first. Also, over 50% of those those who took these courses did not have a college degree and no experience is necessary for any of these courses. They assume no prior knowledge.
Here is what they currently offer:
- IT Support
- Data Analytics
- Project Management
- UX Design
- Android Development
Android Development is the only one that doesn’t go through Coursera. While the Coursera classes are $39 per month, they say most people finish within six months, at 10 hours per week. The Android Development course is offered free on Google’s own site, but it costs $150 to take the exam at the end for the certification.
I think this is a great idea. For someone trying to get into technical writing, or who wants to improve their future prospects, I would highly recommend these certificates. I am taking the Android Development course now, and find the material thorough and mostly easy to follow. As I tend to do with any learning course like this, I will likely go through the material three times before I feel confident enough to pass the exam. Another recommendation I would give for the Android course is that you also add some extra Kotlin practice, especially if it is your first programming language. I read reviews where it was pointed out that the hardest part of the exam for those who had only gone through the course materials was knowing enough Kotlin. And just so you know, the exam is eight hours long.
I recommend Sololearn for learning Kotlin. There is both a free version and a paid version ($6.99 per month or $3.99 if you buy a year subscription). I would definitely get the paid version, as they give you short practice projects for what you learn along the way, which is immensely helpful. Sololearn has a website, which is great, and an app you can download. I love the app, and do short 10 minute lessons when I get the chance. The lessons are very bite-sized, and if you are stuck, you can read comments by others who have been on that section, or ask questions yourself. The community is very helpful! So far, I have used Sololearn to get a basic understanding of programming in Java, Python, and JavaScript, and have gone through their courses in HTML, CSS, and some Git.
Back to the Google Certificates. One of the great benefits of these courses is that if you pass and get the certificate, they connect you to a consortium of 130 companies, including Google, that have agreed that they would take seriously candidates who have earned a certificate. It may be that you use it to get into a more technical field like programming or data science, or use it to bolster your technical writing career, or get into one. Remember, when it comes to technical writing, what employers often scrutinize the most is not your writing ability, but your technical skills. I’m sure it couldn’t hurt your chances by adding this to you LinkedIn account and portfolio website.
Start with a good resume
This post will not go into resume writing basics. There are some great guides out there for free already on that topic. Here I will just cover what is specific to technical writing.
Keywords are key
According to Josh Hrala at careerminds.com, 17% of all resumes submitted are never read by a human being. Instead, they are processed by an ATS (applicant tracking system), which searches for certain keywords that match the job description. If these words are not in the resume, they will never be forwarded to the hiring manager.
So here is what you can do:
Look at job descriptions for positions you might like. Find the most common keywords and write them down. Compile a list over a number of jobs you find. Likely a lot of these words are regarding certain technologies. Now try to use as many of these words in your resume as possible. But don’t do this dishonestly. That will likely backfire, preventing a company from even considering you for future positions.
For example, let’s say you are looking for a tech writing job on LinkedIn and you keep finding that most of them require some knowledge of HTML. If you do not know HTML, then write that down on a list as something to learn. There are a great many HTML tutorials online for free, such as sololearn.com or w3schools.com. HTML can be learned in a couple of weeks. Once you get the hang of it, including some real-life practice, put it on your resume under “Skills.” If you use it somewhere you volunteer, or for your own website, that’s even better.
Sections to include:
A resume for technical writing should include any experience related to the job. Since I used to do technical support, I made sure to include that. I also volunteered for a startup and wrote a white paper for them. I put that on my resume as well.
Here’s what you can include in your resume:
- Objective
- Skills
- Work Experience
- Education
If your work experience is unrelated to technical writing, include any parts of it that might have some relation if you can. Perhaps at your last job you did a fair amount of writing, or you used Photoshop or InDesign, or helped update the website. Put these in a Skills section above your Work Experience if you have lots of skills related to tech writing, but little experience.
Keep building over time
This is a process. A journey. Each time you learn a new technology, put it under Skills on your resume. If you gain some experience, volunteering somewhere, or writing something in your current job, put it in the Experience section of your resume. Keep learning and developing. As you build your resume, you will also want to build your LinkedIn profile, but I’ll talk about that another time. You will also need to write some good customized cover letters, which will be the topic of my next blog post. Feel free to leave comments below.
Technical skills trump writing skills
If you are trying to get into technical writing, you may find it is a sad fact that much more emphasis is placed on your technical skills than your writing skills. It seems it is assumed that writing is easier to pick up than technical skills. Or perhaps the assumption is that everyone can write, but not everyone has technical know-how. Take a look at this list of requirements for a fairly low-level technical writer position I found (really, it was the first one that came up on Indeed).
Requirements:
- Expert in MS Word/Open Office
- Experience with Adobe InDesign cross-references
- Experience with Adobe Illustrator or equivalent illustration software
- Able to perform basic graphic design tasks, such as arranging information, creating icons, finding artwork etc. to create attractive layouts
- Able to work with non-native English speakers and deliver multiple assignments in parallel
- Able to work with both planned and last-minute assignments
Notice that the word “write” is not even included in the list of requirements at all. However, there are several software titles they want you to know.
Here is another more technical role, also from a search on Indeed:
Requirements:
- Bachelor’s degree. Advanced degree preferred.
- 6+ years of technical writing experience, including experience researching and writing excellent developer documentation.
- Working knowledge of two or more of following:
- Application development (Javascript, JSON, DSL)
- Web user interface development (HTML, CSS, Javascript)
- Extract, Transformation, & Load (ETL) techniques
- Machine learning concepts (linear regression, PCA, decision trees, k-means clustering)
- Ability to read code and write code examples.
- Skilled in use of documentation development tools & methods. (DITA, XML authoring tools)
- Experience working in a range of delivery and media formats—including online help, printed guides, HTML—knowledge of wiki’s a plus.
- Ability to work in an agile development environment.
- Strong communication skills with that ability to work across functional units.
- Self-motivated, organized, and able to work independently and make independent judgments.
First, I want you to notice that years of experience are the second in the list. In my last post I discussed how experience is king, and that certainly comes up here. Now notice the list of technologies required to get this job. They want you to be knowledgeable in application development (programming), web development, machine learning, DITA, and agile development practices. Each of these is its own world of learning, and can be broken down into specific technologies and disciplines. The only line in this list of requirements about writing at all is combined with the candidate’s years of experience.
These two jobs demonstrate some of the range of what is available for technical writers. However, little attention is given to the skill of writing itself, while there is a great deal of concern for the technical skills involved. As an ex-English teacher, this is maddening! It takes many years to learn to write well, whereas some technical skills can be learned in a short bootcamp or tutorial. I can attest to this myself, since I learned the technology almost entirely on my own.
So what can you do? Before the Internet, it would have been difficult to learn each of these disciplines, but not anymore. In another post I will go into much more detail about how you can learn these skills, but I don’t want you to go away empty-handed. Here is a list of places to get started.
Resources to improve your technical skills
- sololearn.com (my favorite free place to learn programming languages).
- agilemanifesto.org to understand the basics of agile (hint: it’s more of a philosophy than a technology).
- learningdita.com if you want to learn DITA and XML.
- w3schools.com/html to learn HTML and other web technologies.
- helpx.adobe.com/creative-cloud/tutorials-explore.html to learn Adobe InDesign, Adobe Illustrator, or Adobe Photoshop.
- idratherbewriting.com to read a great blog on in-the-trenches technical writing, or go through his free API documentation course.
This is a good start. It really depends on the type of work you want to do and what you’re interested in. If you find you are especially drawn to one technology, it may be you want to look for a technical writing job in that area. Have fun learning!
Experience is King
As I said in the last post, How to get a job in technical writing, there are two main obstacles that you have to overcome to get into technical writing.
1. Experience is king.
2. Technical skills trump writing skills.
Before I go into each solution in detail, I want to give you an idea of how problematic these obstacles are. I had a number of phone interviews that began and ended with the phrase, “How many years of experience do you have as a technical writer.” Unwilling to lie, I told them I had worked with a startup some, and then tried to point them to my skills, as well as my extensive portfolio. I had the mistaken idea that if they knew what I could do, years of experience would be less of an issue.
I couldn’t be more wrong. Most interviewers would not be dissuaded by any list of skills or accomplishments. They only wanted to know how many years of experience I had as a technical writer.
I want you to notice the wording here. They often used that exact phrase. They didn’t just ask me how much experience I had, but how many years of experience. I learned that until I had at least one year under my belt, I had no satisfactory answer to give.
The worst case in point was when I had gone through four interviews for one company. I met with the current technical writers, took a writing test, which I passed. They asked me some technical questions, which I also passed. It seemed they thought highly of me because they passed me on to the hiring manager. So far, so good. The manager was the guy who could actually make an offer, so I thought I had a good chance.
From the moment we started it was clear he had not read my resume because he never asked me about anything on the resume. He also never referred to my online portfolio. Immediately he asked, “How many years of experience do you have as a technical writer?” I told him about my experience with the start up, but that it was never full-time. From that point on, the interview was essentially over.
I know I’ve painted a bleak picture here. One that has been confirmed by other technical writer colleagues I’ve talked to. But just because it is hard does not mean it is impossible, and I did eventually get a job from someone who valued my skills and the experience I was able to gain. Here are some practical ways you can gain experience.
Help out a startup. Even if there is no pay involved, getting some experience this way can change everything. My little expense writing a white paper for my friend’s startup got me into a number of interviews. And you’d better believe I listed that on my resume and on LinkedIn. One good place to search for startups is through AngelList. They specialize in startups and recruiting for startups.
Volunteer. This is similar to the startup idea. Often charities cannot afford for someone to rewrite their employee manuals or technical manuals like how to install and use certain kinds of software. Often this can be geared towards new employees. Offering to learn about, and then create, a step-by-step guide for new employees might be a real help. You could do this for an animal shelter, church, public radio station, or relief organization. Keep in mind, you want to help with something technical enough that it will be similar to jobs you might apply for.
Find an internship. This mostly applies for those of you who are getting a degree in technical writing. If that’s you, an internship is a great way to go. Many companies offer them for recent gradates or those still in a college program for technical writing.
Contribute to an open source project. This may be very difficult or almost impossible. In fact, I hesitate to add it at all. Logging into GitHub and contributing to anything in a meaningful way is very difficult. The existing documentation is often so poor that it is hard to find a foothold to get a start. Other contributors might not reply to you if you ask questions. When they do reply, they often want you to read the code like a programmer and make sense of it yourself. It might take months to get a handle on what is going on at all. Now, if you have such expertise or experience to do this successfully, then this might really work out for you. There are innumerable projects that need documentation and they would welcome the help. But for most, this is a path to the most frustration with the least to show for it.
Another time, I will discuss creating your own work samples that could land you a job. But that will be when I talk about portfolios. For now, consider getting some experience with a startup or nonprofit. If you have the skills or experience to tackle an open source project, then go ahead with that route.
If you have any other ideas for getting experience in technical writing, feel free to leave a comment.
How to get a job in Technical Writing
There are two categories of people interested in technical writing. Those who have received a degree or certificate in technical writing, and those who want to make the switch from another career. While you might think those with a degree or certificate have all the advantages in the job market, that is simply not the case. Without experience and a good portfolio, employers will seldom even consider a candidate.
Since I recently made the switch into technical writing, I thought I’d pass on what I learned along the way.
Observations from my experience
Before I get into what you can do to get a job in technical writing, let me give you a couple of disappointing realizations I had as I was looking for my first technical writing job.
Experience is king. Companies will act as if they want passion and skills, but over and over I was passed over because I did not have work experience in technical writing. In fact, many hiring managers did not even glance at my portfolio or resume, but only asked me how many years of experience I had as a technical writer. Getting through this barrier was difficult, and is one reason I am writing this blog.
Technical skills trump writing skills. This was frustrating. As an ex-English teacher, I would have hoped my writing skills would carry more weight, but in interviews, my writing ability consistently came second to my technical skills. By the way, really technical technical writing jobs pay more. Writing API documentation for software developers pays more than writing procedural manuals for HR. Search through a job board to discover what kinds of technical writing jobs are available in your area.
What you can do
Having said the above, the market is great to get into technical writing. Here are some things you can do to get your foot in the door.
Start with a good resume. Even with all the online tools available, employers still want to see a resume (in Word or PDF). It should include any experience you have related to technical writing. Make sure to list any skills you have learned that apply as well.
Write custom cover letters. Since a hiring manager often struggles to match your resume to the job description, write a custom cover letter that you send with each application. The letter should point out how your experience or skills match their job description point-for-point, at least as much as possible.
Update or create a LinkedIn account: This will likely be how many companies will find you. Come back to your LinkedIn profile often to update it. Spend as much time on this as your resume. Stay away from job boards such as Indeed, Glassdoor, Monster, etc. About 2% of people find jobs through these, but a lot of low paying recruiters will find you here and fill up your inbox and voicemail.
Create an online portfolio. Portfolio samples are often requested before an interview. Putting it online makes it easier to discover and share. I did a presentation a while back on how to do this, and my notes and resources can be found here. Create a tutorial or other technical writing docs and put them on this site. Here’s an example of mine.
Build up your skills. Use a job board such as Indeed and do a search for “Technical Writer” and see what skills are most in demand. Then start training yourself in these skills. If it’s a piece of software you don’t know, see if you can get a free trial version of it and learn the basics. Then create something you can put on your portfolio to demonstrate your skill with that program.
Build up your experience. I found a startup that needed some technical writing and wrote a white paper for them (I had to first learn how), and I also made them a tri-fold brochure. You can volunteer for a non-profit and write a manual. Any experience is useful.
Don’t do it alone. Find technical writers on LinkedIn and add them to your connections. Attend a local STC chapter meeting or a Write the Docs meetup near you. Ask for advice, make connections, and find out about job openings.
I will expand each of these points above in more detail in the coming weeks, but this is a start. Feel free to leave comments below about your experience in searching for work in, or getting started in technical writing.
