The most common questions I get on my blog are questions about finding jobs in technical writing. While looking for jobs the other month, I realized a few things that I haven't actually recommended before. Here are a few notes from my recent job search:
Large companies often select candidates to interview based on employee recommendations. I have a lot of connections with tech writers (784 on Linkedin), so I had quite a few people who helped connect me with interviewers. I could have reached out to many more connections than I actually did. (Linkedin, by the way, is hands-down one of the most important tools in a job search.)
Once you get an interview, it doesn't mean you'll get the job. You need to have the required skills -- usually advanced technical skills involving the ability to read programming languages. Many companies are SaaS companies (meaning, they offer services in the cloud) and need documentation for developers to tie in to their services via an API. If you can read programming code and have API experience, you'll be extremely marketable.
Not everyone reads my blog. In fact, far fewer than I sometimes think. Because of this, it was great to have MindTouch's ratings about influence to refer to. It gave me a way to pitch the value of my blog. Some people were impressed by this, while others didn't seem to care too much.
More than having a blog, being able to speak to challenges employers are facing about documentation gave me an edge. I felt I could address nearly any issue with some insight. I have more than 1,700 posts on my site, and I've written about such a variety of topics that I can't imagine being surprised by anything. Still, communicating this knowledge is a challenge.
In order to speak to documentation-related issues and challenges, it's important to study the company's documentation beforehand. You can gather a lot of insight and questions by looking over the way a company does documentation. If the documentation isn't accessible, you can still gather a lot of information by reading about the company. I like to look at the way a company organizes their content, as well as any visual communication, user engagement, short guides, online help, and other documentation efforts the company is engaged in.
It seems that most companies aren't entirely happy with their documentation process, from the tools they're using to the formats they publish to the way they deliver it to customers. And there isn't a single standard process everyone is following. Employers are definitely looking to improve on the way they do documentation. This is something I noticed in various interviews. From systems and tools to methods and strategies, companies want to do documentation better.
If you're looking for work out of state, one strategy is to target a specific area, line up as many interviews as you can, and then plan a visit to the area for a week — at your own expense. It may take about two or three weeks of preparation to line up the interviews, since most companies do phone interviews first. But companies may be more willing to interview if you'll be in the area.
Recruiters can be extremely helpful in job searches, since recruiters know which companies have active needs. If a recruiter believes in your ability to do the job well, the recruiter's trust and rapport with the company can go a long way in getting you the job.
Before you interview with five people in a row in an on-site visit to a company, be sure you get a good night's sleep. Seriously. I like talking with people about documentation, but after about 2 hours, I'm ready for a break. When you're on site for half of a day, it's grueling. A good night's sleep helps your endurance.
Large companies often have slow hiring processes. There may be multiple stages, such as an initial HR interview, a writing questionnaire, another interview with the team, and then an on-site interview with everyone. This process can stretch out to 2-3 weeks. However, once you get an offer, it accelerates everything.
The Value of Blogging?
In looking for a job, one of my main questions was whether writing this blog was worth it professionally. To some hiring managers, the blog seemed irrelevant. The employer would have preferred me to know Java than to be the "#1 most influential tech comm blogger." I wondered whether I should have spent my time learning more technical skills instead of writing blog posts.
Ultimately, I think both activities are important. Writing this blog is key to maintaining my interest and passion in the industry. When I combine the branding that comes from this blog with strong technical skills, it's a powerful combination.
In the end, though, a blog has no meaning in itself. In job searches, a blog is only relevant when it gives you interesting ideas and strategies that you can communicate to others, especially as these strategies relate to challenges companies are facing.
So yes, blogging is worth it. The blog is a powerful tool for building industry-specific knowledge, innovating in interesting ways, and connecting with other professionals. But you can't assume everyone has read your blog. You have to communicate the knowledge articulated in relevant blog posts to hiring managers.
As a side note, I haven't published a new post for about two weeks, because I've been so busy relocating and settling in. Having gone so long without writing and publishing feels odd. It makes me feel like a part of me is missing or dormant. I guess that means whether the blog is professionally helpful or not, it's an activity integral to who I am.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here.