The technical writing interview – Part 2

In this second post on the technical writing interview, I’ll focus on the technical section of the interview itself. For behavioral interview advice, as well as how to prepare for other general interview questions, see The technical writing interview – Part 1.

This post will be based on the kind of technical writing I do. It’s what I’ve heard some refer to as technical technical writing. Specifically, it uses the docs as code approach to technical writing. 

Most interviews I went through had five different sections, an hour each, with a different person doing each section. Yes, that’s five hours of interviews. One person was dedicated to the technical portion. For Amazon, I did this twice, going through the whole process for two separate teams. In these interviews, sometimes it was a software engineer who gave the technical portion, and sometimes it was a technical writer with a coding background.

What technical subjects to know for the interview

Reading code

First and foremost, they require you to be able to read and understand code at a basic level. This is true for virtually all jobs using a docs as code approach, or anything related to APIs or developer documentation. For that reason, knowing some basic programming is the number one skill to develop if you do not already have a programming background. 

During an interview, often someone would show me a simple program in my preferred programming language, usually letting me pick from Java, Python, or JavaScript. After I viewed the short program, they would ask questions such as (examples for Java):

• Tell me about the parts of this program. What is this?
  • Example answer: a class. And here’s a method.
• What is wrong with this program?
  • Example answer: It’s missing a semicolon at the end of the statement.
• What does this program do?
  • Example answer: It stores a list of animals in an array and then prints out the third item.

The most in-demand programming language

When reading job postings for a technical writer, Java, Python, and JavaScrip probably come up the most.

• Java – An object oriented language that can be a bit difficult to learn, although much easier than C or C++. It has also been around a long time, and is slowly fading in popularity due to Kotlin, a language created to replace Java. It still has quite a following as a powerful, multipurpose language. A lot of financial institutions still use Java.
• Python – An easy to learn language. With Python, you can program in a functional or object oriented paradigm. It is among the most popular languages, and is used especially for data science, AI, and machine learning.
• JavaScript – Developed for the web, it has grown to include desktop applications as well. JavaScript can be very complex and has many frameworks, modules, and other parts to learn to be well versed in its use. Above all, it is still used for web applications.

If you are just now deciding to learn a language, I would recommend Python. It is very popular and comes up all the time in job descriptions. It is also the easiest to learn at a basic level for an interview.

Just so you see some code here. I have below the same simple program written in Java, Python, and JavaScript.

Java

public class Program {
   public static void main(String[] args) {
       int a = 2+2;
       System.out.println(a);
   }
}

Python

a = 2+2
print(a)

JavaScript

var a = 2 + 2;
alert(a);

Output for all three programs:

4

What do you mean to learn these at a basic level?

If you use Sololearn, which I will recommend in a moment, you should make sure you are especially comfortable with the the material in most sections in the course. The sections I would especially encourage you to learn include:

Java

• Basic Concepts
• Conditionals and Loops
• Arrays
• Classes and Objects
• More on Classes
• Exceptions, Lists, Threads & Files

Python

• Basic Concepts
• Strings & Variables
• Control Structures
• Functions & Modules
• Exceptions & Files
• More Types
• Functional Programming

JavaScript

• Overview
• Basic Concepts
• Conditionals and Loops
• Functions
• Objects
• Core Objects

While I consider these sections to be the most important for an interview, from my limited experience, you may want to finish the whole course just in case. Also, my experience is that to feel comfortable with a programming language, I have to go through the entire course three times. Here’s how it usually goes for me:

As I mentioned before, my favorite resource for learning a programming language is Sololearn. You can use the website, or my preference is to use the phone app. There is a free version, or you can upgrade to the premium version, which I recommend if you can. Either way, it’s a great place to learn a programming language. The cool thing about it is that as you learn, you can play with live code and even create your own programs from scratch and save them. Sololearn offers courses for all three of these languages, as well as several others.

Other technical subjects to know

Each of these only came up in one interview, but I’m sure if I had more, they might have come up more often.

Git

I was asked about certain Git commands. For example:

• What command do you use to see the state of your work when using Git. Answer: git status.
• What does git branch -a do? Answer: It gives you a list of branches in your repo.

Here is a great place to learn Git. If you get about halfway through this, you should know enough, not only for an interview, but for most jobs.

Command line

At one job interview I was asked about certain command line tools. For instance:

• How do you list something at the command line? Answer: ls
• How do you forcefully remove a directory along with all the files in that directory from the command line? Answer: rm -rf 

The easiest way to learn the command line is to look for a good cheat sheet and then try it on your computer. Keep in mind, Windows has different kinds of command line tools, and some of the commands are different on some. For Windows, PowerShell is probably the best, since it is the closest to what you would also use on a Mac or Linux. The commands are mostly the same, and it’s already built into Windows.

HTML

A basic knowledge of HTML is needed for technical writing, so at one interview I was asked about HTML. For this, I was given some text with notes such as:

• Make this line a large header
• Here is a paragraph
• Add a line space here
• Make this into a table. Tables are the most used HTML for technical writers

Then I had to write out the HTML for doing this. 

Sololearn has a course for HTML, but there are thousands of good HTML tutorials online to learn this. Just do a search for “HTML tutorial” and go for it.

Know the lingo

I have one other piece of advice, and it’s not quite as technical as the rest of this post. Learn technical writing lingo. You should know what an SME (Subject Matter Expert) is. Also, know that your Stakeholders are those who would benefit from the work you do. This is usually a manager or department that requested the work, or it may be your customers. 

Read a few articles online to familiarize yourself with the lingo. A good book that helped me with some of this, even though it wasn’t specifically for a docs as code approach was Technical Writing Process, by Kieran Morgan. The book was also helpful for learning to think more like a technical writer, especially in how to organize information, and how to create a procedure for the work itself.

Spend time writing out your answers to Part 1 of this series, and prepare for the technical knowledge section, and you may just get the job you’re interviewing for. Good luck!

The technical writing interview – Part 1

Congratulations, you got the interview! So, how do you prepare for it? You are going to prepare for it, right?

Preparation matters

One of two fates will befall you if you don’t prepare for your interview. When a question is asked, especially something open ended…

• You have nothing to say and meander around searching for the right words to use, or the right story to tell. There are awkward silences throughout the interview. You lose confidence, and your interviewers have the feeling you lack communication skills in general. You also come off as someone who really doesn’t know their subject well.
• You won’t stop talking, but get off topic easily, sometimes even forgetting the question. You waste everyone’s time, and by the end, some of the most important questions were skipped due to lack of time. You might come off as flighty, and unfocused. You also come off as someone who really doesn’t know their subject well.

On the other hand, if you prepare, your answers will be concise and accurate. You will have evidence for every claim you make, and will come off as someone who has deep insight into your line of work, the company, and this position. You also sound confident when you speak. 

So, how should you prepare for the interview? 

Write it out

It is imperative that you write this out. I use Google Docs, but use anything you like. My notes in preparation for my last interview, from which I got my job offer with Amazon, was 23 pages long.

Write out answers to the following questions, abundant notes, and more. Then go over them again and again, rewriting sections, and adding to your document. As the interview approaches, read it from beginning to end every day for at least 3-5 days, so answers come to mind easily in an interview.

Questions you must be prepared for

These questions come up all the time in interviews, and there is no excuse for not being prepared for them.

Tell us about yourself

Another way to ask this is, “Why don’t you introduce yourself.”

For this question, write out a short, one paragraph summary of you. You might include:

• Married? Kids? No need for names.
• Where you grew up, lived, went to college.
• A few hobbies.

Do not start telling stories here. They didn’t really come to hear personal stories of your life, and time is precious. Just give them enough so they know you are human and have interests.

What are your strengths? 

Start with a list and then narrow it down. If you can’t think of anything, ask a friend or previous coworker. Once you have a list, narrow it down to your strongest traits, as well as those you know would be the most highly sought after for the job. For example: You have a couple of strong traits. You are very personable, able to start conversations easily. But you are also an excellent writer, with a degree in English and have done a lot of editing for publications. In this case, I would stress your writing rather than how personable you are, since it fits the main job qualifications better.

Write a list of strengths, but have a good top three ready for the interview.

What is one weakness you have?

This is always tricky. You want something that is true, but you don’t want to sound like a bad fit for the job. You also don’t want to sound like you don’t take the question seriously. “Sometimes I get sidetracked by learning the tech side of the job, and I have to focus again to get the writing done.” On the other hand, maybe yours would be, “I like my writing to be perfect, so sometimes I probably spend too much time getting every sentence just right.” Perhaps these aren’t too bad, especially the first one. There are lots of great articles online about how to come up with good weaknesses in interviews. I won’t belabor it here.

Why do you want to work at this company?

You’ll need to know what this company does and what makes them unique. I’ll talk more about background research later. Just make sure you know why you would want to work here compared to all the other companies out there. Make sure your answer makes them also feel good about what they do. “Because you are the largest manufacturer of silicon wafers in the country, and the industry has always interested me.” Another answer might be, “I love your motto that you want to be ‘the world’s most customer-centric company.’ ”

Why do you want this particular job?

Know why you like this line of work. Since we’re talking about technical writing, usually something about how much you enjoy technology, and also love to write would be appropriate. Also, how you love to learn new things, or be on the cutting edge of technological breakthroughs. You may mention your dual loves of coding and writing, if you know how to do both. These are just suggestions, but good ones you can use.

What is one of your greatest accomplishments?

This might also be worded, “What are you most proud of?” While you could talk about raising your two children, it might benefit you more if you can relate it to the job more. You could say, “I created an app in C++ that has been forked on GitHub over 200 times.” Or, “I helped write and publish a book on distributed computing last year.” Those are big ones, but it could be something like, “I wrote a tutorial for how to make a simple game in JavaScript.”

If you have had even part-time or volunteer work as a technical writer in the past, you can mention a project you worked on. Maybe you wrote a white paper, or created a website.

Do you have any questions for us?

This is almost universal, and you should be ready with a reply. It’s often the last part of the interview. Don’t ask about pay. It’s not time yet. Also, don’t tell them how much you’ve made in the past, or how much you expect in this job. 

If nothing comes to mind, what I use most is, “When will I hear from you about the results?” Then I slyly add, “I’ll be doing other interviews as well, so I want to know when I’ll hear from you.” It’s even better if you have an interview coming up and can say that you have an interview on Tuesday and want to know when they’ll give you their decision. 

One, this might speed up the process, because maybe if they don’t hurry, you’ll be gone with the first offer. Two, because it gives the feeling you are in demand, and they’d better move on this because other companies are starting to realize your value already.

Keep in mind that you don’t want to ask questions that you probably could have just looked up, like how many people are in the company, where you’d be working, what their top product is, etc. 

Background research

You should be good at this, since a lot of technical writing involves research. First research the company. Find their website and peruse it thoroughly.

• What do they do or make? 
• How did they start? 
• Who started the company? 
• Who is the CEO now? 
• Have they been in the news lately? Why?
• What are they focused on right now as a company?
• What are some of their most popular products?

Write out all these things and more. Then memorize it.

Behavioral interview questions

Behavioral interview questions are very common in technical writing interviews. They have to do with what you have done when you were in a certain situation, or what you would do in that situation. Questions are usually in the form of “What did you do when…? or “What would you do if…?” Work through these kind of scenarios ahead of time and write down your answers so you are ready. You can find lists of common behavioral questions online.

Common questions might include:

• What would you do if you had two managers who are giving you conflicting directives?
• What if you asked an SME (subject matter expert) a question in email, but they wouldn’t respond?
• What do you do if you have too many projects that are all due at the same time?

How do they hire?

Some companies have very specific kinds of people they are looking for. For instance, I recently read a post by someone who had worked at both Google and Amazon. They stated that both companies do their hiring with different overarching questions. Google asked, “How smart are you?” Whereas Amazon asked, “What have you done?” These are very different takes on what they are looking for.

Many of these companies have philosophies of hiring as well, or ways they go about it. Amazon uses the STAR format (Situation, Task, Action, Result). Google has certain Googleyness questions (thrives on ambiguity, values feedback, effectively challenges status quo, puts the user first, does the right thing, cares about the team), so you should prepare with those in mind. 

Write out all your experiences, skills, and accomplishments, and put them in these categories. Use the company’s framework to put your expertise into perspective. Spend a lot of time here, because these are the criteria the company uses when hiring. If you have limited, or no experience, insert your skills instead, or projects you created for your portfolio. Show that you meet every area of their requirements.

What’s their culture like (tenets, values, etc.)?

What philosophy guides their decisions? What’s their vision? What are their core values? What do they say about their culture? Copy these from their website and write out how all of your experiences fit in this list. Write down stories, maybe even from other unrelated industries, in the right section of the list. Write what values you like the most and why?

Amazon uses these leadership principles. Google says, “Our mission is to organize the world’s information and make it universally accessible and useful.” They also have the value of Googleyness, which I mentioned before.  

Meta (formerly Facebook), says for their culture: Move Fast. Be Bold. Be Yourself. If you want to know all of what they mean by that, I’m sure there’s a lot on their website about it.

Who are your interviewers?

If you are told ahead of time who will be interviewing you, see if you can find out a little about them online. I don’t mean to cyberstalk them. Don’t be creepy. Go ahead and find someone on LinkedIn, but don’t try to connect with them before the interview. Just see what is important to them. What’s their job title? Where are they an expert? Maybe get an idea of their personality. 

Mine the job description

To prepare, copy and paste the job description into your document. Read it carefully for everything they’re searching for in a candidate. For each item they want, write your skills and experience that relate to that next to the item. Then go to the next one on the list. You know this is what they’re looking for, so make it clear that you fit all, or most, of the things on the list.

That’s it for Part 1. A lot of qualified people don’t get the job because they have neglected to do their homework. Once everything is written out, revise it over and over, and also read what you have written at least once a day for several days leading up to the interview. Then relax and do your best. You’ve got this!

What kind of technical writing job should I get into?

If you’re looking for a technical writing job, it’s easy to get overwhelmed with all the possible job requirements. The truth is there are many types of technical writing jobs, and each has its own requirements. For that reason, there is no need to study all the requirements for every category of technical writing job. Picking a target type and working towards that kind of job can save you from being quite so overwhelmed and may get you a job faster.

While I’m not an expert in most of these, I can give you my take on what kinds are out there.

Keep in mind, I’m not going into subject areas much here. There are specialties in semiconductors, robotics, medical, networking, and more where I have no experience.

Basic technical writing

I call this basic, because it is not as technical as the next category. You won’t need to know any programming or have API experience or other really technical experience to do this type of writing. On the other hand, it’s not content writing either. Content writing is more like creative writing, mostly requiring writing skill and some interest in the topic. Basic technical writing requires some knowledge of, or interest in learning about, a technical subject, whether computer parts or bicycles, medical tools or washing machines.

It also requires some familiarity with certain tools. The most common writing tool used here is Microsoft Word, but might also include Photoshop, InDesign, Illustrator, and more. It would be good to know Google Docs as well, as it is used increasingly instead of Microsoft Word.

To prepare for these jobs, have a good writing portfolio using the tools listed above, as well as anything else you often see in job descriptions. Again, if the job description mentions reading code, DITA, or APIs, you are looking at a technical technical writing position, not a basic technical writing position. You can often get trial versions of most of these kinds of software, so pick one at a time (such as InDesign), and take a few weeks to learn it. YouTube videos and online tutorials may help, as well as anything already installed with the program itself. Then make a portfolio item using that tool and add it to your LinkedIn profile and your list of Technical Skills on your resume.

From what I can tell, basic technical writing pays about half of what a technical technical writer can make. For many, however, this is still plenty.

Technical Technical Writing

At my company, this is called Technical Writer Technical. These require more expertise in a technical subject, as well as a number of technical tools. For software companies, they usually want applicants to have programming experience or the ability to read code, or API and SDK experience. They also ask for specialized tools for the writing itself. There are different approaches to the writing workflow, and this determines which direction you might want your studying to go.

Since I mostly know the software industry, I cannot speak much about requirements for hardware technical writing.

DITA / single source / topic based

DITA stands for Darwin Information Typing Architecture. All sections of documentation are broken into these topics:

• Concept
• Task
• Reference
• Glossary

For this reason, another name for this is topic based technical writing.

One of the main tenets of DITA is that every topic should be reusable. In this way, everything written should be able to be used as needed in different articles. That’s why another name for DITA is single source. You write a piece of information once, say a concept. Then everywhere you need to introduce this concept, you can use the same concept topic you wrote earlier.

DITA is written in XML. The best free resource I have found for learning DITA is the free course at https://learningdita.com/. If I remember right, it took me 2-3 weeks to get through the course.

XML may be a bit cumbersome, but most people use software that writes the XML for them. FrameMaker is very popular, as is Oxygen XML, XMetaL, Easy DITA and a lot of others. To learn one of these, I first recommend you go through the above DITA course, and then see if there is a free trial version of FrameMaker. The last I checked, FrameMaker was the most popular on job descriptions, so I’d start there. Then try to write a tutorial using the software. Make sure you put that tutorial (in several formats) on your portfolio website. There are lots of YouTube videos and other resources online to get you started. There may be built-in resources to help you learn it as well.

After FrameMaker, maybe try some other kinds of software, so you can put that you have experience with it on your resume and LinkedIn too.

A note about Madcap Flare

MadCap Flare is an impressive software program that uses XML and is topic based. It has a lot of the important concepts of DITA, but is technically not DITA. My experience with it is that it is easier to use than FrameMaker, and can import DITA files. Here’s an article if you want to know the differences: What is DITA and How Does it Differ From MadCap Flare?

I recommend you get a trial version of Madcap Flare and write something for your portfolio website. Then add this experience to your resume and LinkedIn account.

As long as the subjects are technical enough, DITA and Madcap Flare technical writing can pay very well. It usually depends what you’re writing about. Both of these can be used for many subjects, both very technical and less technical. Of course the technical, such as software documentation, tends to pay more. If you are documenting software, make sure you learn a programming language. I have more about that in the next section.

Docs as code

The idea behind docs as code is that technical writers should use the same workflow and tools that software developers use. It is especially important that technical writers can at least read and understand a programming language at a basic level.

Other common tools to learn for docs as code are git, Markdown, HTML, basic command line navigation, Visual Studio Code or Atom, static site generators such as Jekyll or Hugo, and maybe GitHub.

If you don’t already know a programming language, you can learn one online or with a phone app. I recommend Sololearn (sololearn.com). For a beginner, Python is probably the easiest to learn and is in very high demand. You will notice it listed in job descriptions for technical writers often along with Java, C++, or JavaScript. But Python is the quickest to understand, and for most, I would recommend you start there.

You can learn Markdown in an afternoon. Learn it and put it on your resume, LinkedIn, and demonstrate something with it on your portfolio.

HTML is a little harder, but you can learn it in two or three weeks. Sololearn is a good place to learn it, but there are thousands of excellent HTML tutorials online for free. You will especially need to learn how to write tables for technical writing, since Markdown is really lacking in this area.

Learning git is required for docs as code work, and here is a very thorough and well written tutorial for git. You will not have to learn all of this to be very successful with git. If you get through the section on Merging (about half way through), you will do fine. Often for difficult git questions, people search the internet anyway.

To learn to use GitHub, you’ll need to create a GitHub account. To learn it, you can see many tutorials online as well as YouTube videos. It’s not hard to get started if you already have some git knowledge.

One benefit of learning git is you will already have begun to learn command line, since command line is a big part of git usage. In fact, navigating git and the directory structure for the files, is probably the main skills you will need for the command line.

The websites for Visual Studio Code and Atom have great tutorials already, and both programs are free. Use those tutorials and learn one of those programs, at least at the basic level. Learn how to write Markdown in one of them and see the output formatted correctly.

Static site generators all have websites with tutorials as well. As I said, Jekyll and Hugo are common, but there are others as well. Try installing one, and getting it to work. Create a page with Markdown and get it to publish. That’s a good start.

Docs as code tends to pay very high, since special knowledge of software development is required.
Docs as code is what I use for work, so you could say I am biased in this direction. Since it is not so strict with its format, like DITA is, I feel I can be more creative in the whole process. I’m sure DITA lovers, however, feel it has many advantages as well.