My name is Nina Zolotova, I work as a technical writer at Parimatch Tech. Having been interviewed for the position myself many times and subsequently having interviewed for the position others, I, therefore, know the hiring process from both sides. Now I want to share how we do it at Parimatch, and what we pay attention to.
By now many people have understood who a technician is and why they need one, but not everyone knows how to hire such a specialist. This is especially true if the company has never had a technician before.
For example, one of the companies I interviewed for simply provided a link to an article on DOU (IT community portal) in the job description with such a comment: "We have exactly the same requirements as here". And as a test assignment, they asked me to write down any culinary recipe from memory in two languages right during the interview.
In another company, after my first conversation with HR, I was interviewed by an architect. We talked a little bit about the documents that I had prepared on previous projects, then I somehow intuitively asked what was the problem with documents in their company, and then I sat through the whole interview and just listening about what was troubling them at the time.
Who were we looking for?
Even before the interviews started, we discussed how we imagined the ideal candidate for the tech writer position. To put it simply, it was:
- someone with a technical background;
- at least minimum experience in the IT industry, not necessarily as a technical writer, we would be satisfied with a related profession, like a UX-writer or a tester. Preferably, he should have heard of markup languages and be able to draw at least some diagrams;
- ideally, the candidate should also have experience as an analyst;
- with good written Russian and English skills.
We were hoping to get a middle or a strong junior and were ready to train him if necessary. Why did have such preferences so? The point is that at that time we already had a small team formed, relatively established processes, selected tools, developed templates. We needed someone who would fit into the team, would quickly grasp what we were doing here, and would be quite independent and proactive, and would not need to be supervised at every step. We have developed a certain management style: we set an ultimate goal, but it is up to the employees how to achieve it, while the desire to define a task for themselves is encouraged.
So, knowledge of specific tools or standards has become a secondary concern. I think you can learn all this if you have the motivation and sound curiosity. Besides, tools and style guides may change from project to project. If a person knows them it's good, if not - no problem, he will figure it out in the course of the process.
If we had to write documentation from scratch or set up processes, the requirements would be different, but our case was like that.
The candidates who came to the interview
Forty-eight candidates applied for the position, among them were: technical writers, copywriters, technical support specialists, PMs, marketing analysts, business analysts, translators, and even a glossy editor. Of these, 10 were pre-screened by HR and got to the technical interview, 6 agreed to do the test task, four of them did it, according to the results of the technical interview two received an offer (not at the same time).
Among them was a girl who seemed to be the perfect candidate. Until then, I sincerely believed that it was impossible at all. She had technical writing experience, she has worked as an analyst in a startup, and from what she said, she has burned out on this job and has decided to resume the documentation writing. From the point of view of expert knowledge, experience, literacy skills, personal qualities – everything was great, she completed successfully the test, got the offer... and rejected it so politely that we even keep this letter as a reference for the most diplomatic rejection.
The test assignment
The question of whether or not to give a test assignment, whether or not to perform it, is very controversial, and there are opposing views on this subject. When we decided to offer candidates a test assignment, we understood and accepted the risks that some good candidates would drop out simply because they wanted to avoid doing it. Still, it's the written documents that speak best about the tech writer, and it's hard to evaluate a candidate without them.
If a candidate could show documents that he or she had written before, we certainly did not require a test assignment.
The test assignment we had was as follows:
- To write a user manual, how to place a bet on the company's website. The language was English.
- The optional part. Picture this process as a diagram/scheme in any chosen notation.
This is what we paid attention to when assessing it:
- a good technical document is literate, clear, logical, consistent in a single style;
- it is easy to find in it the information you need because it is structured, broken down into steps, has subheadings, and the important things are highlighted;
- there are screenshots or other illustrations, they are neatly designed;
- the instruction is working - if you do everything as it says in it, you will really be able to 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. A person who writes this way would definitely interest us (but he already works in our company).
In the test assignment for the candidate, who eventually got the offer, I was finally won over by the diagram: it was clearly far from ideal and drawn for the first time in life. This was important: the person the man sincerely tried in a very short time to figure out things that were new to him and did his best, even though it was not necessary at all.
An example of a test assignment, which I think illustrates the difference between a technical writer and a copywriter, is to write a comparative characteristic of wired and wireless security systems. The copywriter's text will most likely be beautiful, with references to the history of systems, mentioning the stylish design for the interior and a convenient control application.
The technical text will contain not so beautiful, but the useful table with the visual comparison on every point of characteristics and specific recommendations: if you have a glamorous office, this type of system will suit you, and if a metallic underground hangar, where you keep the nuclear reactor, then another type.
Interview questions
I think the most important quality for a good technical writer is sound curiosity. It is not necessary to understand all technical questions from the beginning, but they should at least arise interest in them, a desire to understand as much as possible, to learn as much as possible, even if the final document includes only 10% of the information received.
What questions we were asking:
- we tried to figure out the general technical level: what is frontend and backend, what is microservices architecture, what is HTML and XML, and how do they differ;
- can a person explain complicated things in simple words: for example, explain what an API is to your grandmother;
- what types of documents have you written before? What was the hardest part about working on them? What are the criteria for a good document?;
- how do you start working on a new document, a new task?;
- developers, architects, and other experts are often reluctant to talk or too busy. How will you get information from them if they refuse to talk?;
- how do you feel about vague and unclear tasks?;
- what do you like about the job and what you don't like? Are there any tasks that are generally unacceptable for you?;
- do you have any interests related to technical writing, e.g. knowledge management, UX-writing? If there are, this is a very positive signal.
There are no universally correct answers to these questions, their purpose is rather to understand the person's mindset, what he or she is, and how interested he or she is in all this. It was really interesting to observe how some people would get pesive when they realize that there is no universal definite answer, while others, on the contrary, light up, start thinking. In fact, I considered only people of the second type as my future colleagues.
Whom we eventually hired
So, we conducted all the interviews, then listed all the candidates in a column, each of the team members gave them their personal evaluation in points, compared the results, and gave an offer to the candidate with the most points.
Frankly, the result was different from what we imagined in the beginning. The selected 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 translator's tools and serious experience in working with legal documents in English). And most importantly, he had a sincere interest in our activity and a healthy perfectionism.
Now that almost half a year has passed since then, we can assess the success of the recruitment: the candidate passed the probation period perfectly well, quickly tightened up his gaps in knowledge, and strengthened significantly our team, single-handedly coping with some projects.
I hope that the story of our experience will help if you're looking for a technical writer. Of course, the perfect match will depend on the specifics of your tasks. If it is crucial for the candidate to have a certain skill, you shouldn't compromise on that, because it might not pay off.
Bonus
When you create a task in the task tracker called the Bible, it's just impossible to resist making jokes about it.
If you want to learn more about creating technical documentation, other than the Tom Johnson blog mentioned at the beginning of this article, I recommend an excellent lecture course on the documentat.io Youtube channel that gives a general understanding of what it is, covering basic tools and norms. Also, there is a Telegram channel Technical Writing 101 regularly publishes all sorts of useful stuff for technical writers.
