DEV Community

Cover image for Public Work That Compounds: Writing, Talks & Code Reviews as Signals
Muhammad Ali Mughal
Muhammad Ali Mughal

Posted on

Public Work That Compounds: Writing, Talks & Code Reviews as Signals

#career #writing #beginners #jobs

Last year two engineers I mentor applied for the same staff-level backend role. On paper they were close: similar years, similar stacks, both with solid resumes that passed the ATS. One got a call within four days. When the hiring manager later told us why, it was not the resume. It was a single line under "Selected Writing" that linked to a post-mortem he had published about a queue backlog that took down checkout for 40 minutes. The manager read it before the first call and said, "I already know how this person thinks under pressure." The other candidate had done harder work, but none of it was visible outside his employer's private repos.

I wrote this with help from AI tools and checked every example against real resumes and profiles I have reviewed. I am a Principal Software Engineer in Karachi with 9+ years across PHP/Laravel, Vue, Node and .NET microservices, and I build Smart Resume Analyzer, so I spend a lot of time looking at what makes a profile verifiable rather than just polished.

📚 Series Navigation — Standing Out in AI-Era Tech Hiring

Related earlier posts: The One-Story Resume Test: Building a Flagship Project Section · The 15-Minute Pre-Submit Resume QA Pipeline

Does public work like blog posts, talks and code reviews help you get hired?

Direct answer: Yes, when it is specific, findable and linked from your resume. Hiring managers use public work to check how you reason before the first call. One deep post-mortem, talk or merged review thread that matches the role beats twenty shallow posts. Link two or three pieces with a one-line outcome, and keep the wording consistent across your resume and LinkedIn.

Open notebook with handwritten pages beside a fountain pen and coffee, AI-generated

Why public work matters more now

When every cover letter and summary can be polished by an assistant in seconds, polish stops being a signal. What still separates people is evidence that someone else can check. A resume line says "improved queue reliability". A post-mortem shows the graph, the wrong first guess, the fix and the follow-up alert. That is hard to fake and quick to read.

There is a second effect that people underestimate: compounding. A useful post keeps getting found through search, gets shared in team chats, and gets cited in code reviews. A talk recording gets watched by the exact kind of engineer who later refers you. A thoughtful review comment on a popular open-source project shows up when someone checks your GitHub. None of this happens with work that lives only in a private Slack.

The three kinds of public work, compared

Signal type What a reviewer learns Time to produce How long it keeps working Best for
Technical writing (post-mortems, deep dives) How you reason, debug and explain trade-offs 4–10 hours per piece Years, through search Senior/staff, backend, SRE
Talks and meetups (recorded) Clarity, confidence, ability to teach 15–30 hours incl. prep 1–3 years, via recordings and referrals Lead, DevRel, consulting
Code reviews and OSS issues Code taste, collaboration, how you disagree 30–90 minutes per thread As long as the repo exists All levels, especially juniors
Small tools or demos Shipping ability and product sense 1–3 weekends Until it breaks; needs upkeep Frontend, full-stack

The cheapest entry point is code review. You do not need an audience. You need one well-reasoned comment on a project people use.

How to choose what to publish

I use a simple filter with the engineers I mentor. A piece of public work is worth doing if it answers "yes" to at least two of these:

  1. Does it match the roles you want? A Laravel queue post helps a backend application. A post about your home lab's RGB lighting does not.
  2. Does it show a decision, not just a tutorial? "Why we moved from database queues to SQS and what broke" is stronger than "How to set up SQS".
  3. Can you share it without leaking employer secrets? Strip customer names, internal hostnames and revenue figures. Keep the shape of the problem.
  4. Would you be happy to discuss it for 15 minutes in an interview? If not, do not link it.

Turning public work into resume lines

This is where most people lose the value. They publish good work and then list it as a bare URL at the bottom of the resume, or not at all. Treat each piece like a project with an outcome.

Before (weak):

Blog: medium.com/@someone
Spoke at local meetup
Open-source contributor
Enter fullscreen mode Exit fullscreen mode

After (verifiable):

SELECTED WRITING & TALKS
- "Why Our Queue Backlog Took Down Checkout" — post-mortem on Redis queue
  saturation in Laravel; 9k reads, cited in 2 internal runbooks. (link)
- "Idempotent Webhooks in Practice" — 25-min talk, Karachi PHP Meetup 2026;
  recording 1.2k views. (link)
- Reviewer on laravel/framework PR #4xxxx (queue retry backoff) —
  3 review rounds, change merged. (link)
Enter fullscreen mode Exit fullscreen mode

Each line names the topic, the stack keywords an ATS looks for, one concrete number you can prove, and a link. Keep it to three items. More than that and it reads like a content calendar rather than evidence.

Run the final version through an ATS resume checker to make sure the section header is parsed and the keywords count. Some parsers drop sections with unusual headings, so "Selected Writing & Talks" or "Publications" is safer than "Thought Leadership".

Making it consistent on LinkedIn

Recruiters often open LinkedIn before the resume. If your resume says "post-mortem on Redis queue saturation" and LinkedIn says "passionate about scalable systems", you lose the thread. A few rules:

  • Put your best two pieces in the Featured section, with the same titles as on your resume.
  • Mention the topic in your headline only if it is core to the roles you want, for example "Backend Engineer · Laravel queues & reliability".
  • Reshare each new piece with two or three sentences on what you learned, not just "New post!".

A LinkedIn profile optimizer is useful for checking that your headline, About section and Featured items use the same keywords as your target job descriptions.

Code reviews as a signal: how to do it well

Juniors ask me how to get public work when they have nothing to write about yet. Reviews are the answer. A good public review comment looks like this:

Thanks for this, the retry logic reads much clearer now.

One concern: with `backoff: [1, 5, 10]` and `tries: 5`, attempts 4 and 5
reuse the last value (10s). If the downstream API rate-limits per minute,
we could still hit it 3 times in 30s. Would exponential backoff with jitter
(e.g. `[2, 4, 8, 16, 32]` + random 0–1s) be acceptable here?

Happy to open a follow-up PR with a test if that helps.
Enter fullscreen mode Exit fullscreen mode

It is polite, specific, explains the risk, proposes a fix and offers to do the work. Ten comments like that on a project you care about say more about you than a certificate.

Avoiding the vanity trap

Public work stops compounding when it turns into volume for its own sake. Warning signs I see often:

  • Posts generated mostly by AI with no personal decision or data in them. Readers notice, and so do hiring managers.
  • A "100 days of code" streak with no single piece deeper than a tweet.
  • Talks that repeat the official docs.
  • Linking everything, so the reviewer cannot find the one good piece.

One honest post with a real graph and a real mistake beats a month of generic content.

Diagnostic checklist

  • [ ] I have 2–3 pieces of public work that match the roles I am applying for.
  • [ ] Each piece shows a decision or trade-off, not only a how-to.
  • [ ] No employer secrets, customer names or internal hostnames are exposed.
  • [ ] My resume has a parsed section ("Selected Writing & Talks" or "Publications") with one outcome per item.
  • [ ] The same titles appear in my LinkedIn Featured section.
  • [ ] Every link works and opens without a login or paywall where possible.
  • [ ] I can talk about each piece for 15 minutes, including what I would change.

FAQ

I have no time to write. What is the minimum useful public work?

One well-reasoned code review or issue comment per week on a project you use. Over three months that is a visible track record, and it costs less than an hour a week.

Should I publish on my own blog or a platform like DEV?

Both work. A platform gives you readers on day one; your own domain gives you control. Many people publish on a platform and link it from a personal page. What matters is that the link is stable.

Can I write about work I did for my employer?

Usually, if you remove confidential details and check your contract or ask your manager. Focus on the shape of the problem and the lesson, not customer data or revenue.

Do talks at small local meetups count?

Yes. A recorded 20-minute talk at a local meetup shows you can explain a topic clearly. The size of the audience matters far less than the quality of the content.

Is it okay to use AI to help write posts?

Using it for outlining, grammar or code checks is fine. The decisions, data and mistakes need to be yours, and you should be able to defend every sentence in an interview.

How do I know if my public work is helping?

Track it: note when a recruiter or interviewer mentions a piece, and watch search traffic on your posts. If nobody ever mentions it, it may not match your target roles, or it is not linked clearly. Comparing your resume against a target role with the resume job match tool helps you see which topics to write about next.

Next in this series, Part 5 covers skills half-life: repositioning your resume as your stack shifts.

Follow & Connect

Top comments (0)