Tech writer interviewing: basic algorithms

Filed under: Software, Tech Writing
1 Comment

When you’re interviewing for a developer-docs-oriented tech-writing job in the software industry, chances are fairly good that at some point in the process, you’ll be asked to read some code and explain what it does.

So before you apply, I strongly recommend familiarizing yourself with some common simple things that a brief code sample might do.

For example, I recommend having a general sense of how the following things work (in simple implementations), and more or less what they look like in code in at least one common programming language:

  • sorting an array
  • merging two arrays
  • reversing a string or an array
  • computing a factorial
  • recursion in general
  • finding prime factors of a given number
  • searching in a string or an array
  • searching in a binary tree
  • storing and retrieving data in a hash

[Note added in 2020: I feel like that list may be kind of scary-looking to people without a math or CS background; apologies for that. But all of those items turn out to be pretty simple; in the kind of implementation that you might see in a tech writer interview, each of them can be done in just a few lines of code. So if there’s anything on that list that you don’t understand the general idea of, then don’t be worried, just go look it up.]

(I also recommend being familiar with the data structures that underlie those algorithms and concepts, such as strings and arrays and hashes and trees. And being familiar with coding structures like function calls and loops. But I feel like familiarity with simple data structures and control flow is more common among tech writers than familiarity with simple algorithms.)

If you’re familiar with any C-like programming language, then you can probably trace through a given simple code sample and figure out what each line does. But recognizing conceptually what the code sample is meant to do is a huge step up over just being able to describe what each line does.

Here’s a made-up example to demonstrate what I mean (but please don’t focus too much on this example; I just made it up off the top of my head):

If you see code that says this (this is pseudocode, not any particular language):

array a[2, 3, 5, 7, 11, 13];
foreach i in (1..length(a)):
  print a[i];

you could certainly describe it accurately by saying “The first line initializes an array with the numbers 2, 3, 5, 7, 11, and 13, and then there’s a loop, and the loop prints the first number in the array, and then it prints the second number, and then…” And so on. And that would demonstrate that you’re familiar with the general syntax of the programming language in question, which is a fine thing to demonstrate.

But it would probably be more useful and informative to describe that code sample in higher-level conceptual terms, such as: “This prints out the first six prime numbers.”

Of course, even after you recognize the general pattern of the code, you still need to analyze it carefully to make sure it really does what you think it does.

(In a live interview, you might want to do both the detailed talk-through and the general conceptual description, so the interviewer can hear your thought process. “Hmm. First it initializes an array, and I see that those are prime numbers, and then there’s a loop that prints out the items in the array in order, so I guess what it’s doing here is printing out the first six primes.” That way, even if you get the concept wrong, at least you’ve shown how you approach the problem.)

I know that recognizing the concept of what the code is doing may be easier said than done. For example, if you don’t have a computer science or math background, then you may not know what computing a factorial looks like, nor what prime numbers are.

But that’s why I recommend doing some research before your interview. Learn about some basic algorithms. (You could even do a web search for [basic algorithms].) You don’t have to memorize them, and you don’t have to be able to implement them yourself, and you certainly don’t have to be able to recognize and name a specific algorithm like Quicksort or a specific hash function or the Sieve of Eratosthenes. But being able to recognize the general concept of sorting or hashing or primes (for example) is a good idea.

(See also my 2013 post about applying for tech writing jobs.)

One Response to “Tech writer interviewing: basic algorithms”

  1. Jed

    In the Facebook version of this post, various people were distracted by my primes example. I ended up adding another example in comments on that post, but in retrospect I don’t feel like that was a great example either. But here’s what I wrote about that example, which is relevant even without the example itself:

    If you’re asked to explain what the code does, you could give a very detail-focused explanation. You could describe what each line does, to demonstrate that you understand the syntax of C-like programming languages. You could say that the code starts by initializing some variables, and then there’s a loop that calls a function and passes the values of some variables to it, […] and then and then and then….

    Alternatively, you could give a very general description, like: This code calls a function repeatedly, changing some variable values along the way.

    Both of those approaches would be accurate, but they wouldn’t be very descriptive. If you want to explain what this code does in a more useful-to-an-audience way, it might be more helpful to the person you’re explaining it to to give a description of what goal the code is trying to accomplish[…].

    My point is that if you’re not thinking in terms of what the code’s high-level goal is, then you may end up giving an answer that the interviewer may find unsatisfying. And even if you are thinking in terms of the code’s high-level goal, if you aren’t familiar with some simple CS- and math-related algorithms, you still may not be able to give a high-level answer, because you may not know why someone would want to do what the code seems to be doing.

    reply

Join the Conversation