by Mike Slavin (Rhetoric ’10), Technical Writer, Sailpoint
First and foremost, breathe a sigh of relief, because most people hiring entry-level tech writers are willing to consider any writing (technical or otherwise) you’re particularly proud of when reviewing an application. There just aren’t enough undergrad tech writing programs for recruiters/interviewers to get hung up on specifically relevant writing. I got my first tech writing job with 2 samples I wrote for Illini Media, and a spruced-up forum post explaining how I re-machined my motorcycle’s foot pegs to give a few more inches of legroom.
That said, the big programs out there (Iowa State, Texas Tech, etc.) will send undergrads out with pretty impressive tech writing capstone projects, and it’s worth it to remember they’re also applying for the same jobs.
That means two things:
First, if you’re pitching non-technical samples, you’ll want to really spell out what you want them to focus on. Make sure that when you send any sample, you include a sentence or two giving some context about what you were trying to accomplish in the piece, how you set out to do that, and why that might make you a good technical writer.
Second, it’s REALLY worth it to go out of your way to produce something technical if you haven’t done anything like that as part of your coursework. It’s very likely this will set you apart from a huge number of entry-level candidates.
About selecting non-technical samples:
The first hurdle is knowing what to excerpt. You probably won’t have the luxury of firing off an entire ENGL 427 term paper for consideration; you’ll likely need to select a ~300-word sample. Tech writing often breaks information down into a concept/process/reference trichotomy. Most of your academic work has probably been heavily conceptual, without explicit step-by-step procedures. That said, there is a process happening at broad levels, and excerpting sections where that’s most apparent will give you good talking points. Try to put together selections that introduce new concepts or definitions. Try to find sections where those concepts or definitions are applied. Try to pull in parts where you then draw a conclusion. You’re assuredly doing these things in your papers, you’ll just need to find a way to remix it into a “tight five.” When excerpting your work, don’t feel compelled to choose contiguous sections. While that might work for some papers, you might be able to cut/paste various smaller sections into a more comprehensible standalone sample.
A big part of tech writing is producing content based on interviews with Subject Matter Experts. If you’ve got any journalism background, it’s great to use samples that relied on interviews. You may also want to focus on selecting work where you’re working closely with sources you researched.
When selecting work, also watch out for especially florid language or the kind of tortured academic jargon we all love to try out in undergrad. Your audience will be other technical writers, managers, and the developers/engineers/SMEs you’ll work with. A few tactical flourishes to impress the more writerly folks can be nice, but keep in mind you might be writing for people who had a miserable time in the single English class their engineering school required of them. Err on the side of simplicity, especially if you’re interested in federal work where you’ll be held to Plain Language standards (Not familiar with them? Read about it!).
Your goal with non-technical samples should be to show you can systematically break down a complex topic into discrete ideas, and then use those ideas to accomplish something.
Obviously, triple-check your work for spelling and grammar. Whether or not that really matters in industry is a separate issue, but you don’t want to give interviewers any easy way to disregard your work.
Questions you may be asked about the samples you select, and which you may want to preemptively answer:
1.Who was the audience? How did that influence your writing?
2. What unique challenge did this piece present? How did you overcome them?
3. What was the process of writing this like? What changes did you make along the way? Did you get any feedback? How did you address it?
When it comes to technical samples, do your best to have something! If there are any BADM writing classes available to you, take one! There are also some CS classes available to non-engineers (UI Design used to be one). If coursework isn’t an option, look for extracurriculars. Look for an Open Source Software project that might want help. Write up some Instructables for hobbies you’re passionate about. Overhaul the Wikipedia articles for something you’re interested in or have unique knowledge about. None of these may wind up being the centerpiece of your portfolio, but they’re solid evidence you can learn something technical and transform that information.
Your goal with a technical sample should be to show that you can take an idea that might be familiar to an industry expert and use common language to express that idea to someone who isn’t an expert yet.
All of that generally focuses on how to choose samples based on content, but I’d also suggest you consider samples that might have a unique format, especially if you know anything about a potential employer’s toolchain. A lot of tech writers will use InDesign, Illustrator, FrameMaker, or some kind of HTML-based tool. Demonstrable layout skills aren’t necessary, but can be a nice perk. You might consider re-working your samples with the trial version of InDesign to make it look slick, with a neat pull quote or info box. Even hosting your resume/portfolio on Github Pages could demonstrate some technical/design aptitude.
The major concerns you’re trying to address with writing samples are:
1) Can you write?
This should be a non-issue. Of course you can.
2) Can you learn an entirely new subject?
You and I know you can; few of us roll into undergrad with much Milton in our brain. Show them that you took on something big, hairy, and new.
3) Can you talk about a new concept with an insider?
Tech writers take expert-level info, break it down, and build their readers into experts a layer at a time. You want to show that you can talk about a complex topic in a simplified, but not simplistic, way.
