The Resume Is Not Enough

Why traditional resumes fail to capture the true value of experienced engineers, and how technical blogging, conferences, and open source contributions create more meaningful signals of technical capability.

  ·   6 min read

I’m at a phase of my career where most of my mid-to-senior engineer friends are looking to switch after a few years of working at their first companies after college.

And this got me thinking about how technical personas actually demonstrate their capabilities in a free market.

The average hiring manager spends 7.4 seconds reviewing a resume 1.

In that brief window, they’re supposed to evaluate years of complex technical work and make a judgment about your capabilities. This impossible compression is why the traditional resume format utterly fails experienced engineers.

As your career progresses and your work grows in depth and complexity, the disconnect between what you actually do and what a resume can capture grows a lot.

A resume that’s meant to be scanned in seconds utterly fails to capture what makes mid-to-senior engineers valuable.

When you’re starting out, a resume works fine, it’s better if you have a portfolio of projects, but still, you list your education, maybe an internship or two.

But once you’ve spent years solving complex problems in a specific business context, a single page of bullet points becomes a laughably inadequate compression format for your actual capabilities.

The Problem #

Resumes are reductive by design.

They force you to distill years of complex problem-solving, architectural decisions, and technical growth into a handful of terse bullet points.

What’s worse, they’re optimized for the wrong audience – ATS systems and non-technical recruiters scanning for keywords.

Let’s be honest about what a resume actually captures:

  • Project descriptions that are too shallow to be useful
  • Buzzwords
  • Marketable metrics without context
  • Sanitized accomplishments stripped of all nuance

What it fails to communicate:

  • Your thought process when solving hard problems
  • How you navigate technical trade-offs
  • The depth of your technical knowledge in specific domains
  • Your ability to communicate complex concepts
  • The way you approach designing systems
  • How you collaborate with teams
  • Your engineering philosophy and values

Being in a hole and just working for your company and then coming out years later with just a resume is not enough.

Better Signals #

So if resumes aren’t enough, what actually works?

How do you demonstrate technical competence in a format that actually preserves the signal?

Blogs #

Writing technical blogs is probably the most accessible way to demonstrate your capabilities.

A well-written technical post does several things simultaneously:

  1. It shows your ability to communicate complex concepts clearly
  2. It reveals how deeply you understand a topic
  3. It demonstrates your thought process and technical reasoning
  4. It provides tangible evidence of your experience solving specific problems

The best technical blogs aren’t sanitized marketing pieces – they’re honest explorations of problems you’ve encountered, solutions you’ve implemented, and lessons you’ve learned. They contain the messy details that make engineering interesting.

Confusion is a great muse for technical writing.

A good technical blog is a window into that person’s engineering mindset.

I can see how they think, how they approach problems, and what they value. No resume bullet point gives me that insight.

Speaking at Conferences #

Speaking at conferences is another great way to demonstrate your technical knowledge.

Not only are you presenting your technical knowledge, but you’re also showcasing your ability to structure your thoughts around a problem and communicate them to an audience.

This is a critical skill for senior engineers who need to influence without authority.

The most valuable talks aren’t just about showcasing technical prowess – they’re about providing genuine value to the audience.

A talk that helps other engineers avoid pitfalls you’ve encountered or understand complex concepts more clearly demonstrates both your technical depth and your commitment to the wider community.

Open Source Work #

Contributing to open source projects might be the highest-density signal of actual technical capability. It’s your engineering skills operating in the wild, visible for anyone to evaluate. There’s nowhere to hide when your code, pull requests, and issue discussions are public.

Open source contributions reveal:

  • How you write code when others need to read and maintain it
  • How you collaborate with other engineers
  • How you respond to feedback
  • How you tackle real problems in complex systems

Even small, meaningful contributions to projects you use can provide stronger evidence of your capabilities than the most impressive-sounding bullet point on a resume.

If we think about these signals in terms of their signal density and effort required, they form something of a pyramid:

  • Base Level: Technical Blogs – Accessible starting point with high ROI
  • Middle Tier: Conference Talks – Higher barrier to entry but stronger signal
  • Top Tier: Open Source Contributions – Highest-density signal of actual capability

Additional activities like participating in CTFs, hackathons, or building public side projects can supplement these core signals.

Breaking The Loop #

Beyond just signaling your capabilities and increasing your surface area for opportunities, developing these external outputs creates a virtuous cycle that makes you a better engineer.

This breaks you out of the closed loop that traps many engineers: work on proprietary code, solve interesting problems, learn valuable lessons, and then… watch all that knowledge disappear behind NDAs and closed repositories.

As Simon Sarris writes about creating “breadcrumbs”, the public artifacts you create become a trail that represents your own path of growth.

You also end up creating a binge bank of work that you can draw on for your next role.

The most valuable aspect might be how these signals compound over time.

A resume is ephemeral – it gets updated every few years and then discarded. But a body of public work builds on itself, creating a comprehensive picture of your growth as an engineer that no resume could ever capture.

To be clear, I’m not suggesting you abandon your resume entirely. It still serves as an important summary and checkpoint in most hiring processes. But for experienced engineers, it should be the starting point of how you demonstrate your capabilities, not the entirety of it.

The resume gets you past initial filters. Your broader body of work is what actually demonstrates whether you can do the job 2.

Thinking Long Term #

Building these signals takes time.

It’s a marathon, not a sprint. But the compounding benefits make it one of the highest-leverage activities for your career growth.

When you look back after five or ten years of consistent technical writing, speaking, or open source contributions, you’ll have built something far more valuable than just an improved resume.3

You’ll have created a body of work that demonstrates not just what you’ve done, but who you are as an engineer.4

And that’s something no resume alone could ever capture.