Latest / The Career Change Podcast with Fexingo: Switching Fields, Bootcamps, and Reskilling / How Bootcamp Grads Can Pass Technical Writing Assessments
Transcript
- Lucas: So you've built a solid portfolio project, you've got your GitHub repo looking clean, you've practiced your whiteboarding till you can reverse a linked list in your sleep — and then the company sends you a take-home assignment that's not code at all. It's a writing task. Luna: Wait — like, an essay? Lucas: Not an essay — a technical document. A README file, an API endpoint guide, or a bug report write-up. More and more companies, especially in developer-tools and platform teams, are using technical writing assessments to filter candidates. And bootcamp grads, who are often stronger on the building side than the documenting side, can really stumble here. Luna: I've seen this. I remember interviewing at a dev-tools company a few years back and they asked me to write a quickstart guide for a fake API. I thought I'd bombed it. Lucas: And how did it go? Luna: I got the job! But I definitely spent more time on that writing sample than on the coding challenge. It forced me to think about audience — like, who's reading this? Is it a junior dev or an experienced engineer? Lucas: That's exactly the skill they're testing. Technical writing is a proxy for how you think, how you communicate, and how you empathize with the person who'll use your code. A messy, jargon-filled README suggests your code might be messy too. A clear, structured one signals professionalism. Luna: Do you have a concrete example of what a good versus bad README looks like for a bootcamp project? Lucas: Yeah — let's take a typical capstone project, say a weather dashboard that hits an API and displays forecasts. A bad README might just say: 'Weather app built with React.' That's it. No setup instructions, no API key note, no explanation of what it does. A good README starts with a one-line description: 'A weather dashboard that displays five-day forecasts for any US city using the OpenWeather API.' Then a table of contents, installation steps, a screenshot, and a section on how to get your own API key. Luna: And that last part — the API key — that's where I see bootcamp grads slip up. They assume the reviewer knows how to get one. Lucas: Right. The reviewer might not be familiar with that specific API. Or they're evaluating your ability to onboard a new developer. That's the whole point of a README: it's your project's front door. Luna: So what about companies that specifically send a technical writing task as part of the interview? Which companies are known for that? Lucas: Stripe is a famous one. They've had a take-home that asks candidates to write internal documentation for a fictional feature. Dropbox too — they've asked for a design doc outlining the trade-offs of a storage sync feature. And even if a company doesn't have a formal writing assessment, your pull requests and commit messages are being read. Luna: Oh, commit messages — that's a huge one. I've seen bootcamp grads write commit messages like 'fixed stuff' or 'update'. That's a red flag. Lucas: Exactly. A good commit message is a mini technical document. It says what changed and why. For example: 'Refactor API call to use async/await — resolves race condition on weather data load.' That tells the reviewer you understand both the code and the context. Luna: Okay, so for a bootcamp grad who's getting ready to apply, what's the single best thing they can do to practice technical writing? Lucas: I'd say: pick one of your existing projects and rewrite the README from scratch as if you're handing it to a junior developer who knows nothing about it. Time yourself — aim for under an hour. Then ask a friend to read it and tell you if they can run the project using only your instructions. That feedback loop is gold. Luna: And if they don't have a friend who's technical, they can post it on a forum like r/technicalwriting or even GitHub's discussion boards. Lucas: Great idea. Another tactic: find a popular open-source project and read its README. Look at how they structure it. Then write a small contribution, even if it's just fixing a typo in the docs. That's a way to get practice and build a record of documentation contributions. Luna: That reminds me — I've actually reviewed a few pull requests from bootcamp grads in open source, and the ones that stood out had clear descriptions of the change and a link to the issue they were fixing. Lucas: That's a great point. And that kind of writing is exactly what employers want to see. So let's talk about the writing assessment itself. You get an email with a prompt: 'Write a developer guide for our new authentication API.' Where do you start? Luna: First, I'd ask clarifying questions if the prompt allows. Like, who's the audience? What's the time estimate? Can I use screenshots? Lucas: Good — and if you can't ask, assume a mid-level developer who's new to your company. Then outline: overview, prerequisites, step-by-step with code snippets, common errors, and a quickstart example. Keep it skimmable with headers and bullet points. Luna: And be honest about what your code does — don't gloss over edge cases. If the API returns a 429 rate-limit error, mention it. Lucas: That level of thoroughness is what separates a good guide from a great one. It shows you've actually used the API and thought about the user's experience. Luna: I want to pivot slightly — because technical writing isn't just about documentation. It's also about how you communicate in code reviews, in Slack messages, in emails. All of that is being evaluated. Lucas: Absolutely. And that's actually a good segue to something. You know, we've been doing this show for almost 50 episodes now, and a lot of what we talk about — how to improve your communication, how to present your work — it comes from conversations we have with listeners and from our own experience. And I want to be transparent: this show is ad-free and listener-supported. A small group of listeners already chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what keeps us going. Luna: Yeah, we don't have sponsors or ads, so it's really the support from our audience that makes it possible to keep producing episodes like this one. If this show has helped you in your career journey, joining that community is a great way to give back. Lucas: And it helps us stay independent — we don't have to tailor our advice to please an advertiser. So thank you to everyone who's already part of that. Now, back to technical writing: one other thing bootcamp grads should consider is writing blog posts or tutorials on Medium or Dev.to. That's a public portfolio of your communication skills. Luna: I've seen hiring managers say that a candidate's blog post about how they built a project was more impressive than the project itself. Lucas: Because it shows you can explain your thinking. And in a remote-first world, clear written communication is probably the single most underrated skill in tech. Luna: So to wrap up, what's the one takeaway you want listeners to remember? Lucas: Treat every line of text you write — in a README, in a commit, in a code review comment — as a job interview. It's being read, and it's shaping someone's impression of you. Write clearly, write with empathy, and you'll stand out from the crowd. Luna: Good advice. Thanks, Lucas. Lucas: Thanks, Luna.