How can we better determine an editor’s skill before hiring? Further clarification.

What am I looking for in tech editor candidates? Let me get a little more concrete.

Recently, I made the case for bringing an editor on for a trial run, at the very least to complete a full (and, naturally, also paid) editing assignment. Why? My experience over the years has been that a test, the samples, the interview — no matter how investigative, no matter how clever — do not measure up to actually working with a person. Most particularly because we ask so much of our tech editors. In no other domain is one person expected to do it all. (Though recent changes in publishing are beginning to explode the established models, and editors in that arena are being asked, more and more, to stretch their roles.)

To make my case more clearly, I’m thinking I need to explore this business of what is required of a technical editor.

Here’s a writeup that attempts to get at those skills.

 

 

So what is it I’m looking for? Why is it I say that I’ve not found the test yet that can cover it all?

Because . . .

I want to see in a 40- or 80- or 120-page document that they’ve caught every serial comma that needs to be added. Because engineers often leave them off, but in tech writing we like them in. I want to see that they’re keeping track, in at least one pass through the doc, of all the various terms and initialisms that might be spelled or capped differently, and making sure that all such terms are treated consistently throughout. I want them to check that every occurrence of an initialism with its spelled-out version coincides with the introduction of that term and that that term is never again re-introduced. Unless, of course, circumstances call for it, such as when the term appeared only once previously, quite some time ago, and the abbreviation is not a common one in this context. I want them to be aware of audience and not to introduce initialisms that it would be laughable (for that audience) to introduce. I want them to catch any extraneous British English spellings, even if they are few and far between. Or seeing one, to know to search for such spellings methodically. And to catch any flagrant Britishisms as well. I want them to catch (when they’ve access to our style guide) improperly used product names. I want them to catch any extraneous sets of double spaces after the periods or between words. I want them to notice when smart quotes are mixed with straight. Ditto with apostrophes. I want all the hyphens that need to be in, in. None there that shouldn’t be. And hanging hyphens used correctly.

In other words, I want them to be able to edit at this basic level of mechanics without using a tool like PerfectIt as well as they would with. I want sharp eyes.

And that’s just the warmup.

I want them to know that when a singular subject phrase is followed by an and and another word or phrase, with the whole of that phrase enclosed in commas, the predicate remains singular. And to know that when a subject phrase is compounded with or, the predicate follows the number of the word or phrase closest to the verb. I want them to know that terms introduced with so-called are not set off in any way. That when two words are repeated side by side, a comma separates them. That when a series of phrases without a concluding and forms the subject phase, a comma follows the last. And other like observances.

I want them to understand periods and colons and semicolons and the distinctions between them. How each connects thought, the signals sent, the tone imparted. I want them to recognize the effective use of polysyndeton and asyndeton, whether or not they recognize the terms. I want them to catch when in an in-sentence series a governing word should be repeated across the series and when not. When that series should instead be a displayed list and when not. I want them to catch every dangling modifier, even the less obvious ones. And I want them to be able to explain why the construction dangles, why that’s a problem, and how one might, in various ways, fix it. I want them to know that with correlatives the construction is both/and, not both / as well as, and to catch when the either and the or are misplaced.

I want to see that they understand the difference between actual issues of syntax and faux rules. I don’t want to see “corrections” that follow the superstitions of the latter, which would tell me that this person has no acquaintance with professional editing. Likewise, I don’t want to see a religious adherence to commonly accepted guidelines such as that of not breaking a compound predicate when adhering to such guideline would interfere with a more fundamental point such as clarity, style and voice, or tone. I want to see that they catch when an introductory sentence or two merely repeat the information already perfectly clear from the section title and that section’s place in the hierarchy. Or when the intro promises more than the section actually delivers. Or less. Or when it’s off-topic in any way. I want to see that they catch that single subsection, those unparallel sibling section heads, the subsection in this section that really belongs in that one.

I want to see that they catch when a passage in second person active shifts awkwardly and unnecessarily into the passive. I want to see that they’re attuned to the language, that they hear when the harmony and the logic of a passage is broken in this way. I want to see that they catch bad passives throughout, and that they leave the good ones alone. I want to see, too, that they catch when the writing suddenly shifts to take a different stance towards the audience. Is the text neutrally (or perhaps rather distantly) third person? Is it personably second person? Is it cloyingly first person? Does the stance taken match the doc’s content and purpose? Is it consistent throughout?

I want to see that they’ve a solid grasp of the syntax of comprehension. That they can edit the awkwardly written lengthy sentence into a perfectly comprehensible, yet still lengthy, one. Or that where doing so is either necessary or useful, they break it. That they know about modulating sentence length throughout, about the best use of long sentences, the best of short. And that where a sentence is perfectly fine, they leave it alone.

I want to see editing not only for clarity, but for cohesion and coherence, for rhythm and pacing, for voice — in a given passage, in a section, across the doc. I don’t want to see ruthless editing for concision where “concision” is taken as synonymous with “short” or “brief.” It is not.

I want to see, as they work through a doc with something inherently illogical about its structure, that they catch it. That they can query the issue or issues effectively, that they can suggest corrective changes, that (where doing so would be helpful or where it’s expected) they can rearrange and rewrite to demonstrate. I want to see them reading with purpose and audience in mind throughout, and querying when the doc seems to go awry on either.

And you know I want to see — for any of this work with logic and structure, for any of this work in the guts of the doc overall or down in the text — that they can explain the moves they’ve made or suggested, even to someone who may not be a native speaker of English, even to someone who may never have studied writing. Because as tech editors, we often work with polyglots and we often work with SMEs.

Overarching that skill on that page, I want to see a clear understanding of the idea of “guidelines” (with respect to mechanical style) and “principles” (with respect to good writing). Of the power of that universal editorial mantra: it depends. Of what to follow when, what to disregard when. And where there are differences of approach in something I’d do and something they’d do, I want to see an awareness of style issues commonly treated differently, an awareness of the range of corrective strategies in the particular circumstance, and the ability to intelligently defend the choice they’d make.

And where there’s not enough time, because there rarely is, I want to see thoughtful prioritization regarding what to tackle, what to let go. There’s all the skill in an editor’s toolbox and then there’s what tools can be applied, given the timeframe and the need or the ask.

What this all amounts to is — I want to see stellar editing, across all the levels of edit. I want expertise and judgment, deep analytical skills, knowledgeable flexibility, great communication skills. Because that’s what’s required of a technical editor, daily.

p.s.
Of course, there will be some lapses. Of course, this editor, as do we all, will sometimes miss something. That’s often down to the schedule. And the fact that we’re human and fallible.

But it should never be down to lack of skill.