In most technical writer interviews I’ve had for an organization with public-facing docs, I’ve been asked, “Did you get a chance to read our docs,” which they invariably follow with, “So, what did you think of them?” How should you answer? Here’s what I’ve learned, the hard way.
The answer to the first one, should be a confident (and honest), “Yes!” For, hopefully, obvious reasons. When I’ve interviewed candidates, I have to admit that I wonder why anyone would answer no (and some have). I don’t expect a detailed content inventory but opening a web site and flipping through a couple of pages seem like the least a candidate who is interested in writing them could do—if for no other reason than to see what they’d be getting themselves into.
As to the second one, that has always felt like a bit of trap. For good reason! Here are some possibilities and the traps that lie within.
Their docs are great!
They might be. If so, that’s a good place to start and you should keep going. Saying, “they’re great!” and then smiling politely tells me you either didn’t look at them and don’t want to sound rude or you did but weren’t looking at them with a very critical eye.
What can you say if they really are impressive? Talk about what makes them great and be specific. Some things to talk about include (in no particular order):
- The visual design: Is it attractive? Is it functional? Does it help you find the information on the page?
- The content on the pages: Is it easy to read? Is there sufficient white space? Does it have illustrations? Does it have code samples? Can you understand it? …even if you’re not familiar with the topic?
- The organization and navigation: Are they clear and helpful?
- The performance: Is the site responsive?
These are some generic qualities that apply to almost any type of documentation. To get more specific, you’ll need to find out more about their audience and documentation goals.
Don’t assume you know what they’re trying to accomplish with their docs! (This is the mistake I used to make. Every time.)
Rather, this is where you turn the conversation back to them and have them describe things like their:
- product goals
- documentation goals
- audience
- product
- competition
- work/task scheduling
These are important aspects of the context in which the documents are produced and used, so you’ll want to know about them before continuing your critique.
The way to impress your interviewer with what you know is by the questions you ask as much, if not more than, the answers you give.
These contextual aspects are also the things that you might find yourself dropped into the middle of if you end up working for them. It’s good to get them out on the table before you consider any offers.
Their docs are good, but could be better
This is where most documentation sets are—and the person asking already knows this. After all, they’re probably interviewing you for the job of making them better.
So, do you tell them this? Pro tip: NO! At least not yet.
Answer by asking questions about the documentation’s context I listed in the previous section. After hearing this, you can describe what’s working towards their goals. Then, frame your feedback in the context of how you could help them take their docs from where they are to where they’ve described they want them to be.
This is also another place to identify some red flags in your conversation. Some examples:
- Is the content poor because the subject matter experts don’t talk to the technical writers? Is that a situation that you’re ready to work with? You might be the diplomat they’ve been waiting for.
- Is the content boring because no one on the current team has any graphics skills or tools? Do you? This could be a perfect fit for you.
- Does the technical content lack programming examples because the current writers have very little development experience, which you have? That could be something to talk about.
These “red flags” could be warning signs, or they could be opportunities. That’s for you to decide. Either way, find out enough to make an informed decision.
Their docs are horrible!
It should go without saying, that you wouldn’t give this as the answer during the interview (but I said it, just in case)—even if they are and the interviewer tells you as much. Turn this back into a search for more information.
Consider these two possibilities:
- The docs are horrible (in your estimation), and they think they’re just fine. Perhaps documentation quality isn’t even a priority to them. Strange as it might sound, there are a lot of reasons this could be the case.
- The docs are horrible, and your job will be to fix them.
To me it’s a red flag when documentation isn’t a priority because they might not recognize your efforts as valuable to them and you might get only the bare minimum of support as a result. If there aren’t any technical writers interviewing you, be especially curious about this. I’ve seen some people thrive in this type of environment, and you’ll know if you’re one of them. For many, especially those early in their career, this situation could be quite stressful.
The second path tends to be much more hopeful. As with the previous sections, use this to explore what they’re hoping you’ll do and whether it looks like you’ll have the support to deliver that for them.
There are any number of other possibilities, and what they have in common is that you want to find out more about their documentation environment. (Seeing a pattern, here?)
How do I answer, now?
I answer, “Yes. I looked them over, and…” I ask them questions to start the conversation.
Any answer I’d give beyond that would be based on many assumptions. I realize that now, I’m more likely to make incorrect assumptions and then have them point that out to me (as has happened in the past).
The key is to start a conversation.