Technical Writing Sample For Job

What Actually Gets You Hired

A Technical Writing Sample For Job isn't a polished essay. It's a piece of documentation that shows you can make complicated things readable for people who don't have time to be confused. I spent six years doing this before anyone asked me to prove I could do it. The industry doesn't care about your writing credentials. It cares whether your diagrams parse, whether your API reference works after the third revision, and whether a junior engineer can follow your onboarding doc without pinging you at 4pm on a Friday.

How I Build a Sample That Actually Represents Me

When I was hiring, I'd glance at the resume, then immediately check the sample. Most samples were either marketing copy disguised as technical writing or raw code dumps with a table of contents slapped on top. Neither tells me anything useful. My approach: I write the sample the same way I write production docs. Pick a realistic scope, document a real system, show the process artifacts. The sample itself becomes proof of work. Here's what that looks like in practice. I start with a small API or tool that someone might actually use — a billing endpoint, a deployment script, a configuration file format. I write the getting-started section first because that's what hiring managers read. If the getting-started section works, the rest usually holds together.

I include screenshots or annotated diagrams where they clarify something a paragraph can't. A screenshot of a successful curl response with the important fields highlighted is worth more than 200 words of explanation about JSON structure. But I also cut screenshots when they're redundant. Duplicate the content, not the visual. I write the table of contents after the content, not before. This sounds backward, but it keeps you from creating a structure that doesn't match what you actually wrote. The structure follows the work. Not the other way around.

Technical Writing Sample For Job: The One I Actually Used

The sample that got me my current contract was seven pages. It covered a fictional internal CLI tool called "deploy-kit" — nothing more elaborate than that. Here's what was in it: The whole thing took me about four hours. Not because writing documentation is fast, but because I'd done this enough times to stop second-guessing every sentence. The sample wasn't meant to be literature. It was meant to be functional. Officially, job postings say they want "clear communication skills" and "ability to translate complex topics." Unofficially, they're checking five specific things, usually in this order:

The fifth point is the one most candidates miss. You can document an API perfectly and still fail if you can't demonstrate that you understand why the API exists, what constraints shaped it, and where it breaks in practice. I learned this the hard way on a sample I wrote for a payments company. I documented their webhook system flawlessly — endpoints, headers, retry logic, signature verification. The hiring manager asked me a single follow-up question: "Walk me through what happens when the customer's TLS certificate expires mid-processing." I couldn't. My sample was technically correct and completely hollow. I didn't get the offer. After that, every sample I write includes at least one section that addresses failure modes, not just happy paths. It's cheaper to show you understand the broken cases than to claim you only document the working ones.

The Process: From Topic to Finished Sample

Here's the actual workflow I follow. It's not glamorous, but it's consistent: Day one: Scope and outline. Pick a topic that demonstrates the specific skills the target job requires. If the job posting emphasizes API documentation, don't write a user guide about data visualization. Map out the sections before writing a single word. The outline is a contract with yourself — if it feels loose, the final document will be too. Day two: Draft the core content. Write the quickstart first. Then the reference. Then the overview. This order feels wrong but it works because the quickstart forces you to understand the system well enough to explain it simply, and the reference gives you the detailed material to expand from.

Day three: Diagrams and examples. Add visuals where they solve a problem text can't. Write examples that cover the common case, the edge case, and the case everyone forgets. Test every example. An example that doesn't run is worse than no example — it signals carelessness. Day four: Review and cut. Read the document aloud. Sentences that make you stumble need rewriting. Delete anything that doesn't help the reader complete a task. This is where my samples lose about thirty percent of their first-draft word count. The survivors are the ones that matter. Day five: Peer review. Send it to someone who knows the domain but hasn't seen your draft. If they get stuck on anything, fix it — don't explain why it's obvious. Then format everything consistently: heading hierarchy, code block styles, link conventions, timestamp formats. Inconsistency in formatting reads as inconsistency in thinking.

Common Mistakes That Sink Samples Instantly

I've reviewed hundreds of technical writing samples. The same failures keep appearing: Over-documenting the trivial. A sample that spends three pages on "what is Python" when the job is for a senior API documentation role. The reader assumes you don't understand audience segmentation. This is the most common error by far. Under-documenting the non-obvious. Skipping error handling, authentication flows, or dependency requirements because "any developer would know that." They wouldn't. Document what you wish someone had documented for you when you were starting out.

Inconsistent tone shifts. Switching between second person ("you configure") and third person ("the user configures") mid-document. It creates cognitive friction. Pick a voice and stick with it. First-person plural ("we recommend") is acceptable in internal docs but avoid it in samples — it reads as corporate padding. Broken example dependencies. Example three assumes the reader completed example one, but example one is buried in section five. Structure your examples as a linear sequence or explicitly mark them as independent. Linear is better for samples — it shows you understand progressive disclosure. No visual hierarchy. Walls of text with no spacing, no bolded key terms, no callout boxes for warnings. The eye needs somewhere to land. Use whitespace, bold, and callouts deliberately. Not decoratively — functionally.

What Your Sample Should NOT Include

Samples often fail because candidates include everything except what matters. Avoid these: Don't include a biography section. Your name and contact info are sufficient. Personal history doesn't make your documentation better. Don't include samples that are too large. A fifty-page reference manual looks impressive until the reader realizes you padded it. Seven to fifteen pages is the sweet spot for most roles. Longer if the role specifically demands it.

Don't submit untested examples. I once received a sample where the Python code imported a module that didn't exist. The candidate had copy-pasted from Stack Overflow without verifying. That single error eliminated them from consideration regardless of how good the surrounding writing was. Don't include placeholder text. "Lorem ipsum" or "[insert explanation here]" signals that you don't care enough to finish the job. If you can't write the explanation, say what the explanation would cover and move on. Gaps are better than fakes.

Measuring Whether Your Sample Is Ready

Before submitting, ask these questions: These checks take roughly twenty minutes on a well-formed sample. They catch about eighty percent of the errors that make samples look amateurish. The remaining twenty percent shows up only after submission, when reviewers spot domain-specific inaccuracies you missed. The tool you use to produce the sample matters less than the final output. Markdown to HTML, Sphinx, GitBook, a Google Doc, a Word file — pick what matches the company's stack. If you don't know their stack, Markdown with a clean HTML export is the safest choice. It demonstrates technical literacy without making assumptions about their infrastructure.

Avoid tools that add unnecessary overhead. Don't build a custom static site generator for a sample. Don't use a CMS. Don't create interactive elements unless the role specifically requires them. The sample should demonstrate writing, not engineering. Source control matters more than people expect. I once reviewed a sample that was clearly a collaborative edit with conflicting styles merged together. The author hadn't used version control, so the inconsistencies were baked in. A simple git log showing commits for outline, draft, examples, and review would have told me everything I needed to know about their process.

The Real Question Behind Every Sample Request

When companies ask for a Technical Writing Sample For Job, they're not really asking whether you can write. They're asking whether you can think systematically about information architecture, audience awareness, and the gap between what experts know and what beginners need. Writing is the vehicle. Thinking is the cargo. The best samples I've ever written weren't the most elaborate ones. They were the ones where a reader could complete a real task without encountering a single moment of confusion. That's the standard. Everything else is decoration.