Having been working as a senior technical writer since 2001 (and hired many of them), I’m always astounded by the lack of software and developer skills in this trade craft.¬†Please note, this post isn’t intended to be critical.

Instead, I see the lack of technology skills of writers as a weakness supporting the SDLC. What’s the lurking cause? A sincere passion for fanatical learning.

#5 How Fast Do You Learn New Software?

The answer should be immediate: extremely quickly. Despite my expectations on the hiring side of the desk, I can tell you many technical writers rely purely on existing skill sets. Big mistake.

Back in 2012, I was approached by a large company to manage their technical hiring team. Because of my commitment to my existing client list, I was unable to accept the entire project myself. Therefore, I pitched in helping to sort out the good, the bad and ugly candidate skill sets for consideration.

I interviewed top prospects by phone. Their answers:

  • A few weren’t sure
  • A handful admitted they would require more information about the product
  • Some stated fairly quickly depending on the complexity of the tool
  • The top one replied with genuine excitement she could breeze through almost anything

Talk is cheap. But asking about learning skills will get your A team list well-defined quickly. These are the folks who you want to consider if they can produce results. We ended up hiring one writer full-time and three others as contractors. Doing so gave us a B plan if our top prospect was more enthusiastic than proficient.

#4 Can You Talk About Your Last Few Projects?

This is a trick question. Sample documents are nice. How they’re researched, assembled and published tells a far more profound story. My experience has been that the writing part is only part of the job. Interviewing techniques are mission-critical even before the drafts begin. Don’t forget about extensive product testing.

A fabulous answer is when he/she asks for more information. Personally, I’ve produced many projects for which I’m bound by NDA stipulations. So I’m legally restricted to share confidential trade content. However, projects they can chat to skirting the confines of NDAs should reveal:

  1. The target audience and access to SME resources.
  2. If previous templates were available or a new one was needed.
  3. Branding and navigation requirements.
  4. The types of style guides required for formatting.
  5. The output needs for publishing (i.e. online, PDF, PowerPoint).
  6. If online, the process it was published (i.e. CMS, XML, Framemaker (ouch), MadCap Flare).

#3 Have You Been Involved With Product Teams?

Any time you can learn about their involvement in product development, it’s a measurable indication they are truly team players. Some writers still hold on to the tradition of isolation. In our fast-paced technological world, communicating with developers, scrum masters and product owners is mission-critical.

Ideal candidates have a passion for product development. There’s not many in the industry. It takes a devotion to lifelong learning. Especially in programming and user experience management.

Another positive answer to look for is involvement in UAT. I’ve been involved with many projects stalled by a huge backlog of user stories and failed sprints. In these situations, diving in and contributing to user acceptance testing is smart for writers to:

  • Contribute to a team approach throughout the design process
  • Learning the finer nuances of product development
  • Becoming power users throughout the SLDC

#2 What Technology Trends Do You Follow?

This is an open-ended question. What you’re looking for is an interest in watching what technology companies are doing to streamline content production for a better user experience.

Here’s an example…

Back in 2013, I noticed both Stripe and Paypal were converting their API documentation into a three column UI format. Although simple and brilliant, it required a fine-tuned framework to manage the content.

Due to the need for speed, maintaining API interfaces isn’t common for your average technical writer. More than likely, a snowball’s chance in hell.

This one trend propelled my consulting business into a higher stratosphere. Soon I was suggesting the format to companies of all sizes to simplify their API code samples. Read more about it here.

Finding out if writers follow technology advancements proves their devotion to growing their value to scrum teams and employers.

#1 What Kinds of Solutions Do You Bring?

Ideas are nice. Solutions are game-changers. One of the things I believe in is getting to know how candidates help engineer blocker resolutions. Whether it’s product issues or building better content production processes, I expect writers to pitch in.

Unfortunately, remaining behind the scenes waiting for story points and research to land on our desk isn’t beneficial to the team approach. As a technical writer, I want to add value regardless if it’s in MS Word or with UI/UX design.

Another endless problem is time management. Rather than chilling with collaborators chatting, why not dive into product elaboration? I know, asking someone to become an SME can be a long shot.

But as writers, we’re also knowledge advocates. Therefore, becoming experts at subject matter is a beautiful method to the madness of becoming indispensable.

Depending on workload and duties, some of these questions may not be practical for your organization. I’ve served on some projects where my entire existence was to execute enormous reams of product content adhering to highly-refined style guides. Concise writing skills combined with the ability to shift gears in multiple projects is vital to meet deadlines creating exceptional content.