Guide to Hiring and Getting Hired¶
Welcome! This guide aims to help those looking to hire documentarians find the perfect candidate, and to help job-seeking documentarians find the perfect position. Its content focuses on tricky points in the process of hiring a documentarian.
A great place to start on your hiring or job-seeking journey is by posting to or browsing the job board. Check it out over at https://jobs.writethedocs.org/.
Note
This is a living (and growing) guide that is missing some topics. If you want to contribute, you can do so by creating issues and pull requests in the GitHub repository.
Community Spotlight¶
These interviews are meant to be a resource for new documentarians looking to gain insight into the work of technical writing by sharing the stories of our diverse community. Each interview tells the story of one community member and what they’ve learned over the course of their career so far, along with providing some practical advice for new documentarians.
If you are willing to share your story with the community, you can contact jobs@writethedocs.org.
- Interview with Aaron Thayer
- Interview with Alex Ball
- Interview with Ashley Newton
- Interview with Celeste Horgan
- Interview with Christian Bahnweg
- Interview with Gaurav Nelson
- Interview with Lana Brindley
- Interview with Liz Harris
- Interview with Mandy Morgan
- Interview with Rachael Stavchansky
- Interview with Ravind Kumar
- Interview with Sarah Moir
- Interview with Swapnil Ogale
Interview advice¶
The following are a list of potential job interview questions collected during the writing day at the Write the Docs Prague, 2018.
This list is divided into three sections:
- What are good questions that an interviewer can ask that will elicit information about the candidate’s personality, experience and approach to documentation (organized by the attributes you may want to learn about).
- What are poor questions that you may be tempted to ask as an interviewer, and how can you reframe these to be informative about a documentarian’s skills.
- What can a candidate ask to learn about the interviewer’s expectations of the role, how the successful candidate will be treated/valued, and the workplace culture (also around documentation).
Some recommended interview questions¶
Self-starter:
- How would you approach [a typical task for the role]?
- Can you tell me about a time you initiated a project?
- What would you do if you want to perform a project but don’t get support from your teammates?
Team player:
- What do you imagine your ideal team being?
- How would you go about teaching a new skill to your team?
Experience in an organization:
- If this were a new department/you were the first technical writer, where would you start?
- Can you tell me about a time you showed leadership changing a process/procedure?
- Do you think a writer should only write, or should they also edit existing texts/play additional roles?
- How would you deal with the situation when senior staff members keep sending you (too many) emails to proofread/edit?
- What’s the thing you’re most proud of in your professional life?
- What’s the hardest lesson you’ve had to learn at work?
Dealing with feedback:
- How would you deal with a senior member of your team who is giving you substandard text but you know they can do better?
- How would you deal with feedback from a senior writer about your style when they are criticizing it but you believe you’re right?
- If a developer comes to you and they have to write a document, e.g. a readme, how would you get them started?
- How do you keep up your concentration when you have a monotonous task?
Personality:
- How would your colleagues describe you (in one word)?
Technical skills:
- (Of the technologies named on their CV), can you tell me about your experience using this technology?
- (Of a complex/feature-rich technology), can you tell me about some features you might use to manage a large volume of content/multiple different audiences/efficient updates…
Interview questions better avoided (and alternatives)¶
- Very in-depth questions about the subject matter, not about the writing skills.
- Who are you as a person and what’s your passion? -> Can you tell me about a project you worked on that you are proud of?
- What’s your five year plan? -> What’s the next thing you want to learn?
- What’s your favorite food? (or other arbitrary ice-breakers) -> Anything more relevant to the job/workplace! Perhaps there’s a social group in the office/common hobby to mention?
- What would be your superpower? -> Would you rather be able to fly or be invisible? (to elicit their reasoning)
Questions for curious candidates to ask of interviewers¶
- What do you think a tech writer/documentarian does?
- How much influence do you see the writer having within the team? How would you help achieve this if it doesn’t happen organically? Are they allowed to give input in other places?
- Would you support the writer suggesting process changes/UX changes if they see the need?
- How would you evaluate the success of a TW/documentarian?
- Could you describe your company culture - from the perspective of a new graduate hire and a new joiner with 15 years’ professional experience?
- What value do you think (improved) documentation will bring to your company? Who will your audience be? How will you measure this value?
- What training would you provide to educate a new employee about the context of the business (departments, the product, existing systems)? -> Red flags: they do not know or not going to tell!
- What training would you provide/support for professional development?
- Where do you see the main focus of this role sitting, seen on a triangle with Users, Business, and Technology as the points?
- What tech/business resources would you allocate to support the documentation?
- Would you prefer an employee with deep knowledge or broad knowledge?
Useful skills for a technical writer¶
Develop your capabilities with these professional skills and tools.
Skills and Knowledge:
- Be bold. Own what you do. This does not specifically have to be a techwriting skill, but in this field we often need to prove the importance of our work.
- Be a team worker. You definitely need to communicate with others to get the information required to perform your job. Experts usually have strong personalities; you’ll need to find a path to their hearts and minds.
- Be curious. Don’t hesitate to ask questions even if you think they are “stupid”. These questions may lead to unexpected and useful answers.
- Be open to new technologies. The more you know, the more your marketability increases.
Tools and Environments:
- Git or GUI for Git (such as SourceTree)
- DITA and Markdown
- Madcap Flare, Adobe Technical Communications Suite, or AuthorIt
- HTML and CSS
- Command line skills. CLI is very useful for working with Git (can be easier than GUI), when writing Linux or Unix-related documentation, and as a common language with developers and QA engineers.