The sample that makes the role concrete
A beautifully written article about artificial intelligence is not automatically a technical-writing portfolio. A stronger sample might help a student import a small CSV file, identify an invalid row, correct it and export a usable result. The difference is observable: one explains a subject; the other enables a task. For an internship application, pick a task you can actually perform and document it precisely enough that someone else can repeat it.
GitLab's public Technical Writer role describes researching and editing software documentation, improving product language, and working with engineering-style tools and workflows. That is one employer's job family, not a universal internship checklist. It does, however, explain why a reviewer might care about Git, command-line comfort, review comments and release changes as well as grammar. Google also offers technical-writing courses that can support preparation without establishing that a Google internship is open.
Decide whether you want developer documentation, customer help content, hardware instructions or internal process documentation. The audience changes the evidence you should show. An API tutorial needs working requests and useful error explanations. An equipment guide needs approved procedures and technical supervision. Do not create instructions for unfamiliar machinery just to obtain a more impressive-looking sample.
Search for the audience as well as the title
Start with technical writer intern, technical documentation intern, information development intern and developer documentation intern. Add the product or audience you want to serve. Software documentation, engineering documentation and customer education can lead to different teams even when each posting uses the word content. Search the employer's careers site and retain the exact requisition rather than assuming a general writing program contains technical work.
Read responsibilities before preferred tools. A posting centered on release notes, tutorials, documentation reviews and product changes is different from one centered on promotional articles and search traffic. A knowledge-management role might mainly organize internal information. A developer-relations role might combine documentation with demos and community events. Neither is inherently better; the question is which work you intend to practice and can explain convincingly.
Check the actual enrollment rule, location, term and working arrangement. Do not borrow an experienced technical writer's education or years-of-experience requirement and treat it as an internship rule. Conversely, a strong writing sample does not override a stated technical prerequisite. When the posting asks for a portfolio, send a small set of relevant, readable samples, not a folder containing every essay you have written.
Build a small documentation system, not one long essay
For a software sample, use a tool you can run legally in your own environment and a harmless synthetic dataset. Define the reader in one sentence: a first-time user who understands spreadsheets but has never used this importer. Then define the outcome: import ten expense rows, isolate two invalid entries and save eight valid records. Those assumptions stop the document expanding into an encyclopedia of file formats.
Create four connected pieces: a short start-here page, one end-to-end tutorial, a reference page for the required fields, and a troubleshooting note. Each piece should answer a different question. The tutorial explains what to do in order. The reference explains what a field means. Troubleshooting starts with a symptom and leads to a check. Repeating the same explanation in all four places creates maintenance work and makes the sample harder to review.
Use actual commands, screenshots or interface labels from the version you tested. Where a step depends on a setting, name it before the user reaches that step. Include the expected output, not just a command that appears to succeed. If the software changes, record the tested version and revise the affected instructions. A dated test note is much more informative than calling a tutorial always up to date.
Replace vague instructions with a recoverable sequence
Consider the instruction: upload your data and fix any errors. It leaves the reader to discover the file requirements, validation behavior and recovery path. A better version explains that the sample accepts UTF-8 CSV files with date, category and amount columns; shows one valid row; identifies the upload control; and tells the reader where rejected rows appear. The exact labels belong to your chosen tool, not a made-up interface.
Now introduce an intentional error into your synthetic file. A row has an amount of twelve instead of 12.00. Document what the application actually does. Does it reject the whole file, omit the row, or create a warning? Does the reader download a rejection report or edit the original? Test the correction and repeat the import. Avoid an example in which the happy path works but recovery depends on information absent from the guide.
Include a note distinguishing sample data from production data. Do not place private account details, credentials or customer records in a public example. Use a reversible local workflow rather than instructing a reader to overwrite a real database. Technical credibility comes partly from recognizing the consequences of an instruction, not just knowing the syntax of a command.
Test whether readers can finish the task
Ask a few volunteers to follow the instructions without coaching them through every step. Tell them what you are observing and use a sample account or local environment. Record where they pause, which terms they misunderstand and whether they reach the expected result. This is a small usability check, not a representative study of all users or a formal accessibility certification.
Suppose five volunteers attempt four predefined tasks, producing twenty task attempts. In the first round, twelve attempts succeed without help; after revision, seventeen do. Those are 60% and 85% observed task-completion rates, a 25-percentage-point difference. But the same volunteers may have learned the workflow, and the twenty attempts are not twenty independent people. Report the descriptive improvement and the limitations instead of claiming the edit caused a universal 42% productivity increase.
A useful revision log might show that you moved prerequisites above the first command, replaced an ambiguous field name and added an error example. Pair one before-and-after excerpt with an explanation of the observed problem. This gives the reviewer a view of your editing judgment that a polished final page alone cannot provide.
Package the evidence for a busy reviewer
Make the portfolio entry readable without an account wherever possible. Its landing page should state the audience, task, tool version and what you personally produced. Link directly to the tutorial and the revision log. When using a repository, include a clear README and preserve meaningful commit or review history rather than uploading a single unexplained archive. A reviewer should not need to reverse-engineer your project to find the writing.
An accurate résumé line could say that you created and tested an importer tutorial with five volunteer readers, documented four common failure paths and revised unclear prerequisites. Use the exact counts from your own work. Do not turn the fictional numbers in this guide into personal achievements. If you submit a documentation contribution to an open-source project, describe it as submitted until it has actually been accepted.
For an interview, prepare a two-minute explanation of one choice: why the tutorial starts with a sample file, why troubleshooting is separate, or why you removed background material. Then show how you validated the underlying instructions. A candidate who can explain what was omitted and why often gives a clearer signal than someone who merely says they are detail-oriented.
Choose an internship with access to the product and reviewers
Ask who reviews technical accuracy, whether interns can use a test environment, and what documentation will be maintainable after the internship ends. Also ask whether the team can approve a public work sample or a sanitized account of the project. A project that never becomes public can still be valuable; the restriction simply changes what you may show later.
Separate tools from learning. A role that mentions Markdown and Git may provide substantial product access, or it may involve repetitive migration work with little explanation. Ask for an example of a recent intern deliverable and the feedback it received. You are trying to understand the assignment, not extract confidential documents or persuade someone to reveal an internal roadmap.
Your first application does not need a miniature documentation department. One accurate tutorial, one reference page and a thoughtful revision can be enough to demonstrate the relevant process. Finish a sample that a reader can use, tailor its introduction to a specific opening and submit while the role remains available. Add complexity only when it helps explain a real task.