My name is Nina Zolotova, I am a technical writer at Parimatch Tech, I have been interviewed for this position more than once, then I conducted interviews for this position, so I know the hiring process from both sides. Now I want to tell you how we do it and what we pay attention to.
Experience shows that many have already figured out who a technical writer is and why he is needed, but they don’t know how to hire him yet. Especially in cases when there were no technical writers in the company before.
“I was chatting with some engineers and PMs during a doc review today, and they were like, “This is the first time we’ve gone through this process — this is new to us.” It never ceases to amaze me how unfamiliar people are with tech writers and documentation. Maybe I am luxury”. — Tom Johnson, tech writer, author of the blog I’d rather be writing and developer of the API documentation course.*
As an example, in one of the places where I was interviewed, the job description simply contained a link to an article on DOU with the comment: “Everything is written correctly here, our requirements are exactly the same”. And as a test task, they asked me to write down any recipe from memory in two languages right at the interview.
In another company, after the first conversation with HR, I was interviewed by an architect. We talked a little about the documents that I prepared during my previous projects, then I instinctively asked: “What is your problem with the documents?”, and then I spent the rest of the interview sitting and listening with interest about their problems for that moment.
The candidate we were looking for
Before the interviews began, we discussed among ourselves the image of the ideal candidate. If we translate it from the language of job requirements to human language, we were waiting for a person:
- with technical education
- with at least a little experience in IT, and not necessarily as a technical writer, something related would suffice, for example, some experience as a UX writer or a tester. It was desirable for him to be acquainted with text markup languages and be able to draw at least some kind of diagram
- ideally, we also wanted the candidate to have the experience of an analyst
- with literate written Russian and English
We counted on a middle or a strong junior, and we were ready to teach if necessary.
Why so? The fact is that at that time we already had a small team, processes were relatively well-established, tools were selected, templates were developed (then we changed everything, but I will probably tell you about this some other time). We needed a person who would fit into the team, who would quickly understand what we were doing there, but who would be quite independent and proactive at the same time, who would not need to be controlled at every step. We developed the following management style: we set an ultimate goal, but the way of achieving it is completely at the discretion of employees, and the desire to find a task for yourself on your own is encouraged. Therefore, knowledge of specific tools or standards faded into the background. I believe that all this can be learned with enough motivation and healthy curiosity. Plus, tools and style guides can change from project to project. If a person knows them — great, if he doesn’t — it’s also not a problem, he will figure it out in the process. If he had had to write documentation from scratch or adjust processes, then the requirements would have been different, but our case was like this.
The candidates that came to us
48 candidates applied for the position, including technical writers, copywriters, technical support specialists, PMs, marketers, business analysts, translators, and even a glossy magazine editor. Out of these candidates, 10 people passed a prescreen with HR and got to a technical interview, 6 people agreed to do a test task, 4 people actually did it, and based on the results of technical interviews, 2 people received an offer (not at the same time).
Among them, there was a girl who seemed to be the ideal candidate — a mythical “unicorn” who met all the requirements. Before this case, I never believed that this could happen. She had technical writing experience, she worked as an analyst in a startup, in her words she burned out at this job and decided to get back to the documentation. From the point of expert knowledge, experience, literacy, human qualities, everything was fine, she completed the test, received an offer… and rejected it in such a polite manner that we even saved this letter as a standard of the most diplomatic refusal.
The question of to give or not to give a test task, to do it or not to do it is very controversial, there are different points of view on this issue. When we decided to offer the candidates a test task, we understood and accepted the risk of losing a number of good candidates, because they simply wouldn’t want to do it. But nevertheless, the documents were written by the technical writer speak about him the best, without them, it is difficult to evaluate the skills of the candidate.
If the candidate could show us the documents he had written earlier, then, of course, we did not require a test task.
We had the following test task:
- Write a user instruction on how to place a bet on the company’s website in English.
- Optional part. Display this process as a block scheme/ diagram in any chosen notation.
What aspects we paid attention to when evaluating it:
- A proper technical document — correct, understandable, logical, consistent, created in a single style;
- It is easy to find the necessary information in it, it is structured, divided into steps, contains subheadings, and the important information is highlighted;
- The document contains screenshots or other illustrations, they are presented smartly;
- The instruction is useful — if you follow it, you can place a bet.
An example of an amazing internal document with bingo of phrases that not a single tech writer would want to hear: “no one will write it down”, “it depends, it always happens in a different way” and “now everybody has forgotten”. The document itself is wonderful in form and content. We would be interested in a person who writes in such a manner (but he already works for a company).
The test task of the candidate who eventually received the offer contained a diagram, and it was the thing that impressed me — the diagram was certainly far from perfection and the person clearly had drawn it for the first time in his life. This is exactly what was important — the person actually put efforts, in a very short time he studied out something new for himself and did his best, despite the fact that it was an optional part.
The example of a test task that, in my opinion, perfectly illustrates the difference between the text of a technical writer and a copywriter, was shown recently in the technical writing telegram channel. The task was to write a comparative description of wired and wireless security systems. The text of a copywriter will most likely be written attractively, using references to the history of systems, mentions of stylish interior design, and convenient application for use.
And speaking about the text of a technical writer, it will contain a not so attractive, but very useful table with a visual comparison for each item of characteristics as well as specific recommendations: if you have a glamorous office, then a system of this type will suit you, and if you have a metal underground hangar where you keep a nuclear reactor, then you need a security system of another type.
I believe that the most important quality for a good technical writer is a healthy curiosity. He does not need to thoroughly understand all technical issues from the very beginning, but he should at least be interested in them, he should have a desire to understand as much as possible and learn as much as possible, even if only 10% of the information he has studied is included in the final document.
The questions we asked:
- We evaluated the level of general technical knowledge — what is frontend and backend, what is microservice architecture, what is HTML and XML, and what are the differences between them;
- Whether a person knows how to explain complex things in simple words — explain to your grandmother what an API is;
- What types of documents have you already written? What was the most difficult part of working on them? What are the criteria for a good document?
- How do you start working on a new document or a new task?
- Developers, architects, and other experts are often taciturn or too busy. How will you get information from them if they resist?
- How do you feel about the tasks like “go I know not whither and fetch I know not what”
- What do you like about your work, what don’t you like about your work? Are there any tasks that are unacceptable?
- Do you have any interests related to technical writing, for example, knowledge management, UX writing? If a candidate does, this is a good sign.
There is no only a correct answer to these questions, the goal is to understand the way of thinking of a person, who he is, and how interesting this job is to him. It was really interesting to watch how some people start to fade when they hear these questions and understand that there is no ready-made unambiguous answer, while others, on the contrary, light up and start thinking. In fact, I can only see people of the second type as my future colleagues.
Our final choice for hiring
So, after we had conducted all the interviews, we wrote out the names of all candidates in a column, each member of the team gave his grade to the candidates in points, we compared the results and gave a job offer to the candidate with the highest total grade.
To be honest, the result was different from the picture we imagined in our heads at the beginning. The chosen candidate had a non-technical education and, in general, a little less knowledge in the technical part than we expected, but at the same time, his strengths more than compensated for this (for example, excellent knowledge of translation tools and great experience in working with legal documents in English).
And what’s the most important — we saw a sincere interest and a healthy perfectionism. Now, when almost half a year has passed, we can evaluate the success of the choice for hiring — the candidate successfully passed the probationary period, quickly filled his gaps in knowledge and made our team much stronger, he manages to fulfill some projects completely on his own.
Hopefully, our experience will help you in the search for a technical writer. Of course, the perfect match will depend on the specifics of your tasks. If the availability of a certain skill in a candidate is fundamentally important, then there should be no place for a compromise, because such a compromise may not pay off.
When you create a task called Bible in the task tracker, it is impossible to refrain from jokes about this topic.
If you want to learn more about the creation of technical documentation, in addition to the blog of Tom Johnson mentioned at the beginning of the article, I recommend: