23/11/2013
A while ago, we were trying to recruit a member for our team. At OutSystems the position is called Academy Engineer, at Google they call it Technical Writer, and at Microsoft Developer Writer.
Since I don’t like to reinvent the wheel, I started searching job descriptions from other companies to understand what Google, Microsoft, and other top players look for in technical writers. I also went searching for interview questions used to interview the candidates to this position. Unfortunately, I didn’t find anything useful.
So I went ahead and created our own set of interview questions for a technical writer. After a while I thought that this might be relevant for other people, not only to improve their interview process, but also to explain a technical writer job description. That’s what gave origin to this post.
Since every company and team has its nuances, it makes sense to explain the responsibilities of an Academy Engineer at OutSystems. Most of the activities of an Academy Engineer revolve around: knowledge transfer, training, and certification.
Knowledge transfer is anything related with learning the OutSystems platform. This covers error messages and menu options displayed in the IDE, methods and parameter names in APIs, and of course reference helps and operation manuals.
Training is anything related with training new or existing users. Be it online using videos, tutorials, how-to's, or on-site, using demos or power points.
Finally, certification is anything related with the OutSystems certification program. Just like Cisco, Oracle, Microsoft, and others, OutSystems has its own certification program. This means that an Academy Engineer is responsible for developing the process itself, but also for developing and maintaining the exams to test the candidates knowledge and experience.
Now that you understand the responsibilities of an Academy Engineer, lets jump to the interesting part. What to search for in a technical writer, or a position like it, and how to access it in an interview that takes less than 2 hours.
If you work in the software industry, then you are in an international company, whether you like it or not. So when interviewing a candidate, you should start by checking if they are able to read and hold a conversation in English.
I’m not saying that they need to write and talk at a native level, because if you only recruit English natives, you are missing out on the potential the rest of the world has to offer. What I’m saying is they should be able to convey their ideas in English. This is important since most of jobs in the software industry require discussing complex topics with several of people. And of course you can skip this part if the candidate is native.
I’ve listed this test as first, because you can screen candidates via email or phone interview, and save yourself some time.
Testing reading and speaking skills is easy:
To really understand if the candidate is a fit, you need to understand what are their motivations. Why are they applying. If they intrinsically motivated in the job they will be doing, or do they have some external motivations, like an higher salary, parking spot, whatever.
If you work in a part of the world where it’s usual for candidates to submit a cover letter with their CV, you already are ahead on this. But even if candidates send you cover letters, you should probably dig deeper on a the email or phone interviews.
There are a couple of questions that you can do to check if the candidate is intrinsically motivated to be part of your team:
If the candidate passes these questions with flying colors, you can even dig deeper and ask for details:
Yes, not every good candidate will know this, but if you find two candidates that have the same technical experience, whom would you hire? Someone who did not take the time to learn what you do or what technologies you use, or someone that not only knows what do you do, but also took the time to learn some of the tools you use?
The latter is perhaps more proactive and intrinsically motivated than the first.
Before getting to the technical interview, you should also check if the candidate matches your company’s culture. Sometimes you’re better off if you don’t hire someone that is able to pass the technical interviews, but just does not match the company culture.
If they are not able to adapt, they will not only produce less, they will also be less happy which might lead to conflicts within the team.
If you’re not sure how to test if someone fits the company culture, you should try to distill the company’s culture in five bullets. Then you can focus on making them testable. I could invent some examples of these to show you, but what is a better example than OutSystems’ own culture?
Basically the OutSystems culture revolves around:
Notice that I’ve numbered the behaviors. This means that OutSystems places more importance on asking why, tan on being helpful.
After you found out the five behaviors that describe your company’s culture, it’s easy to check if candidates display this behaviours. It might be difficult to measure this during a screening interview by email or phone, but it’s easy to be on the look out for them during an on-site interview.
This is the part were you evaluate if the candidate has the technical skills to do the job.
I don’t believe that anyone can do a good job as technical writer, without really understanding the things they are documenting. If you don’t understand something, how will you be able to communicate it to the customers that need to learn how to work with the product?
So you should validate if the candidate understands some of the core concepts in the area you work for. If your product is a database, test them to see if they know how to model data, and perform some SQL queries. If you make REST APIs, test to see if they understand how the web works, how to invoke the service, and how to test the responses.
The technical skills are simple to evaluate, since a candidate either passes or not. There is no grey area here. You can present an algorithm, or SQL script and ask the candidate what does it do.
You should however, refrain from asking questions that are very specific for the product you are developing. You should not expect that candidates know the ins and outs of your product and the tools you use to make it.
Since a technical writer will also be publishing content on the web, it might make sense to test whether the candidate knows HTML, CSS, and Javascript. You should also test if they know how to use a version control system. Again, I’m not telling that they should master these tools and technologies. But even if you use a CMS system, or something that generates HTML on the background, if they know HTML, CSS, and Javascript, they’ll be able to use it without much assistance. They’ll also be able to perform customizations to the look and feel autonomously.
Again, this is easy to test. You can either give the candidate a mockup and let them implement it in HTML, or give them an HTML and ask them to change certain parts.
Since most of times, a technical writer has to explain complex topics using day-to-day vocabulary, you also need to test the candidate knowledge transfer skills.
For this, you can ask the candidate to explain a complex topic in a way that non-technical users would understand. There are so many complex topics out there. Here are a few examples that you can use:
Since you don’t work in the vacuum, after creating your interview script, you should share it with your team and ask for feedback. This will help you tune some details. If you are either being too soft or too hard on the technical questions, your team will tell you, and you can iterate on that.
It will also help to build a consensus among the team, since in a way you’ll be involving the team in the interview process.