The live coding interview, but for writers

When I was starting out in my career, I did a lot of live coding interviews for software engineering and product management roles. I’m old enough that they happened on a physical whiteboard and usually involved some kind of string manipulation. (Today I do string manipulation for a living! That’s a tech writer joke.)

I thought back to those interviews when I started building out the writing team at Copytree. I was in a bind: I didn’t want to rely only on work samples and good vibes, but I also didn’t want to ask people to spend hours writing a test piece. I needed something like a coding interview.

Unlike designing a function to reverse a linked list, though, writing an essay on the spot is too open-ended, the set of potential solutions too large. Enter the editing exercise.

The Copytree editing exercise

When we interview writers at Copytree, we ask them to spend around 40 minutes editing a piece they’ve never seen before, in Google Docs, live on the call.

We adapted the exercise from a real engineering blog post published years ago, something a client sent my way when I was freelancing. It’s a good example of the kind of work we often do at Copytree. A subject matter expert in engineering has written a first draft, mostly stream-of-consciousness, and we’re asked to help shape it into a compelling narrative.

Most engineering blog posts follow the same structure: introduction, background/motivation, then solution. In the interest of time, we only ask candidates to read and edit the introduction and background/motivation sections, less than 400 words. There’s enough context there that candidates don’t need to know what the solution is to do a good job editing the piece.

Why it works

Editing is not exactly the same as writing from scratch. But, especially when the piece needs a lot of improvement (and this one does), how someone edits tells you a lot about how they write.

Style: What do they rewrite, and how? What do they let stand, and why?
Structure: How do they improve the logic and flow of the argument in the piece?
Approach: How do they balance asking questions and gathering context vs. getting work done in a limited amount of time?
Technical proficiency: How well do they understand the engineering concepts at hand?

When I worked at Google, the most seasoned interviewers had spent years honing their questions and guarded them with pride. I now understand the attachment. I won’t share our test piece, but I’ll share some of the things I appreciate about it:

Errors that technical candidates will spot instantly, while those with less experience may fix them incorrectly or pass them over (my favorite: “technical dept”)
Story beats familiar to writers experienced with B2B SaaS engineering, with gaps and inconsistencies that require astute questions and educated guesses to resolve
A quirky tone, letting us see how candidates think about authorial voice in engineering articles (there’s no right answer here, but it’s important to have an opinion)

What we look for

Here’s a peek into our interview rubric at Copytree.

Confidence, energy, and alacrity

A good sign is when candidates instantly see many avenues to improve the work and have fun doing it. They think and write quickly. They may voice strong opinions about what they’re writing in real time: ”Wait, no, that’s not quite right. Let me make it better.” Ultimately, we look for candidates who are invigorated by tech writing, because that’s who we’d want to have working with our clients.

Thoughtfulness and collaboration

Context is everything—candidates who do well have a lot of questions. They don’t start making changes right away, they get their bearings first. Although we expect candidates to be familiar with the technical concepts, we aren’t exclusively looking for experts—tech writers are often generalists who have to learn on the job. What matters is that you know enough to ask the right questions (and understand the answers).

Comfort with ambiguity

Your success as a tech writer largely depends on how you handle and fix murkiness—whether due to the curse of knowledge (an SME thinks something is so obvious it needn’t be stated), a confusing brief, or some tech that’s still being developed as you’re writing about it. For some candidates, ambiguity turns this editing exercise into word quicksand. The best writers grasp onto what’s there. When they’re missing something, they invent a rope.

A sparkle of craft

You can have fun, be thoughtful, and thrive in uncertainty, but to get an offer, we need to see something in your writing that shines in a surprising way. I’m looking for a moment where I think: yes, that’s clever, or that’s a really good way of putting it. Nobody could expect you to do your best writing on a Zoom call in 40 minutes, but give me a glimmer, baby!

To wrap it up, at Copytree, we take a page from the engineering interview handbook and go beyond writing samples and “soft” questions to see how someone actually writes, live. We’re actively hiring, too, so if this sounds like your kind of challenge, please reach out and apply.