I've been interviewing for technical writing/documentation roles partly to improve my interviewing skills and see what opportunities are out there.

In this article, I talk about what most technical writer interview processes are like and some of the most common questions I've been asked during these interviews.

Note: What you're about to read is based on my personal experience and may not totally apply to your own scenario. Regardless, I still believe that the information contained in this article will prove helpful to you if you're interviewing for a technical writing role.

Summary of a typical technical writer interview process

The interview process begins either when a recruiter contacts you or when you send in your resume and/or cover letter. If the recruiter thinks you're a good fit, they'll usually invite you to a 30 mins introductory/informational chat to get to know you better, tell you more about the company, and understand your background and your expectations for the role. They'll also ask questions about the experiences listed on your resume, as well as questions to determine if you're a good culture fit.

After the chat, the recruiter will most likely ask you to send your technical writing samples or your technical writing portfolio. Sometimes you may be asked to submit your samples alongside your resume ( I have a very detailed article on how to create a tech writing portfolio). At this stage, endeavor to submit writing samples that tally with the kind of document the role requires.

If the recruiter feels like you might be a good fit, they'll forward your resume and writing samples to the hiring manager (who will most likely be the team lead). If the hiring manager likes what they see, you'll be invited for a more technical interview with them.

During this technical interview, the hiring manager will most likely ask questions about your writing process and your knowledge of technical writing. Sometimes, you may be given a take-home assignment after the technical interview (or even during the introductory call phase),.

Most of my take-home assignments have been on structure and information architecture. This might be because I've been applying for mid-level technical writer roles. Three of the companies I interviewed with asked me to look at a piece of documentation and propose better structural solutions. One of them phrased the task like so: "I'd like to ask you to either look at the documentation as a whole or pick one specific page and list things that you don't like about it, how you would change it, and why (to improve readability, UX, aesthetics, etc.)." Here's one of my sample solutions for such a task.

After reviewing your take-home assignment (if any) and your performance, if the hiring manager feels like your skill set matches the experience they're looking for, you'll be invited to a final interview with the rest of the team you'll most likely be working with. Questions you'll be asked will usually be team culture-fit questions.

During this whole interview process, you'll always be given a chance to ask your own questions. Never say you do not have any questions. Your interviewer could sometimes interpret such response to mean that you've not done your research about the company or you're just uninterested. Always have your own questions to ask.

Now that I've summarized the entire process let's get into some of the common questions I was asked and some questions you can ask too.

Common technical writer interview questions

Q: Have you had the chance to take a look at our documentation? What did you like about it, and what do you think can be improved?

Before any interview, always take the time to go through their documentation or whatever section of content you'll be working on. Make a list of things you liked and why you like them, and also a list of things you think can be improved on and why. This can be as little as a typo, making a header shorter, or adding more whitespace to the layout.

Check this Bob Watson's article for more tips on how to answer this question.

Q: Why did you choose to become a technical writer?

My answer to this question is personal and probably wouldn't be the same as yours. Talk about your motivations and what you enjoy the most about tech writing.

Q: Assume the engineering team just completed work on a feature, and you're expected to document it. How would you go about that?

My answer to this question is that I would first try out the feature myself using whatever readme that the engineering team had already prepared. I'll note any frictions or difficulties I run into, so I ask questions about them later on.

After that, I would request a 30-minute or an hour chat with the engineers who built the feature so that I can learn more about the feature and clarify my questions.

When I feel like I have learned enough about the feature, I will consult my notes to come up with an outline based on the type of doc we're looking to create. After that, I'd discuss the outline with my manager and other key members. Once we come to an agreement, I'd write the first draft.

Q: What would you say is the most important skill for a technical writer to have?

I always answer that the most important skill for a technical writer to have is empathy and making an effort to understand who the users of the documentation are. Because at the end of the day, we're not creating documentation for ourselves. We're creating it to help users, and you can't create something helpful for a particular audience if you do not take the time to understand them and their pain points.

Q: How do you perceive and handle feedback?

My answer to this question is that getting negative or critique feedback hurts, but I've learnt to disassociate any feedback I get as a reflection of my ability as a writer. Instead, I've learned to accept and even appreciate feedback because input from editors and others is how I've been able to hone my craft and become a better writer. Regardless, I also know when to ignore some sort of feedback and follow my gut.

Q: Can you give an example of a time you collaborated with people to create a doc?

The instances I provide as answers to this question are personal and are about different projects I've had the opportunity to work on. Simply think of a time you worked with someone else to create a document. This person could be an editor, a technical reviewer, or what have you.

Q: How do you handle conflict between you and other team members? For example, let's assume you believe that task x should be done in a particular way, but most of your team members think it should be done a different way. What would you do in such scenarios?

My answer to this question is that I focus on the collective goal instead of what I believe is right. I would share my thought, but I would still be open to hearing what others have to say. And if the majority votes for a particular approach, I'd be willing to execute it because I know there are no definite rules in tech writing. It's an iterative and experimental process, and the only thing that matters is serving users' needs.

Q: What's one failure/disappointment you've recently experienced inside or outside work, and how did you handle it?

Interviewers ask this question to see how you handle failures, mistakes, or disappointments. This is because, in most organisations (especially startups or teams at their early stages), nothing is set in stone; projects can be discontinued out of the blue.

They want to know if you're the kind of person who would just sulk over a disappointment or one who would pick up the lessons and move on? Tell a story about a time you made a mistake and were able to apply the lessons from that event to future uses.

Q: What metrics do you think should be tracked across documentation?

I'd say some of the most important metrics to track in documentation are:

• Clicks and impressions: This will help understand what kind of info users are looking for when they land on a particular doc page. By doing this, we may be able to improve the discoverability and findability of content, as well as provide better answers.
• Pageviews: This helps understand what doc pages should be considered a priority because of the number of page views and session duration.
• User flow or journey: This will help us understand the entire journey of the readers and the kind of information they're looking for.

In my opinion, regardless of these metrics, nothing beats making provision for direct feedback in doc pages or asking your users about your docs to get a sense of if it's fulfilling its purpose.

Q: What's a writing project you worked on recently that you're proud of?

Think about a writing project that was seemingly difficult but which you later delivered on. Talk about the challenges you faced, how you overcame them and what you learned from the entire process.

Questions you can ask

As I previously mentioned, when your interviewers ask you if you have any questions for them, do not say no. Not only does it put you off as uninterested, but it also robs you of the opportunity to spot any red flags in the company's culture and truly determine if the role and company are right for you.

Here are some of the questions that I usually ask, alongside some recommended by my friends.

• What are the KPIs for this role? And what does success look like in this role?
• How does the company support the technical writing team to enable them to do their best work? If you sense that a company does not have systems that show that they clearly value the work that technical writers do, run. It can get very frustrating trying to convince management of the value of your work or existence.
• What's your favorite thing about working here, and if given the opportunity, what's one thing you'd want to change?
• What are some exciting projects that the team or the company is currently focused on?
• What's the revenue model of the company? This is especially important for startups to help you guage their level of stability.
• How does the company encourage team bonding both within and between teams?
• Can you tell me about a time that you made a mistake and how your team and leadership responded?
• In what ways does the team or company encourage, support, and plan for the growth of their employees?
• How did this position become available?

While asking these questions, pay good attention to the answers you get. They'll help you really understand the company's culture. Listen to your instincts and how comfortable you feel. If something is not right, then it's not right. Better to turn down a job than to join a toxic organisation.

Conclusion

I hope these few tips help you with your upcoming interviews. If you do get the job, congratulations!!

If you don't, don't fret. Ask for feedback and apply that feedback to your next application and see it as an opportunity to get more interviewing experience. Read their documentation, blog articles, social media field, and anything that can help you build a better understanding of the company, product, and its users. You don't want to walk into an interview unprepared.

If you have questions or anything you'd like me to add to this article based on your own experience, please reach out to me on Twitter.