The Human Side of Technology
The Narrative Résumé Needs an API
At the end of Part 1, I did something potentially foolish.
I shipped it.
After weeks of applying for jobs with carefully tailored, conventional resumes, I submitted the first production version of my narrative resume for a Principal DevOps Engineer position.
It began like this:
I got tired of pretending a 30-year engineering career is best explained as a chronological collection of bullet points.
It's better explained by the problems solved.
Then, instead of walking through my career employer by employer, it walked through problems.
Building new machinery beside old machinery that couldn't be turned off.
Removing operational toil.
Making complex infrastructure problems legible.
Building platforms engineers could eventually own themselves.
It still contained the technologies. The companies. The outcomes. The evidence.
It just wasn't organized around chronology anymore.
I liked it.
More importantly, for the first time in a long time, I thought it represented me pretty well.
Then I uploaded it to a Workday application portal.
And Workday said, essentially:
Cool story. Now where did you work?
Well...
Huh.
Naturally
This should have been obvious.
Job application systems have spent decades being trained to expect something like:
Employer → Job Title → Start Date → End Date
Maybe a location.
Maybe a description.
Then the next employer.
And the next.
My shiny new narrative resume had deliberately stopped using that as its organizing principle.
For a human reader, that was the point.
For a machine trying to populate an employment-history form?
Not so much.
Workday wanted to parse my resume and save me the trouble of entering all of that information manually.
The resume wasn't giving it a clean interface for doing that.
We had found our first production bug.
And I loved it.
Don't Fix the Wrong Thing
The obvious response would be:
See? This is why resumes have to be chronological.
I don't think that's the lesson.
The human problem hadn't changed.
A hiring manager still learns more about me from:
Here's a difficult problem. Here were the constraints. Here's how I approached it. Here's what happened. Here's what I learned.
than from:
Constant Contact, blah blah to blah blah. Here are eight bullets.
But Workday has a legitimate problem too.
It isn't sitting down with coffee and deciding whether I'm someone worth talking to.
It's trying to answer questions like:
Who employed this person?
What was the job title?
When did they start?
When did they leave?
That's structured data.
And my new resume wasn't structured particularly well for that consumer.
So we didn't need to undo the narrative resume.
We needed to give it an API.
Different Consumers Need Different Interfaces
This is where the whole experiment became suspiciously like engineering.
One artifact.
Multiple consumers.
Different requirements.
The hiring manager needs context.
The recruiter needs recognizable signals.
The application system needs structure.
An AI-assisted matching system needs enough conventional language to connect experience with requirements.
And I need the thing to remain true.
Those aren't necessarily competing requirements.
They just shouldn't all be forced through the same interface.
So the next baseline version of the narrative resume gets something intentionally boring:
Employment History
Newfold Digital Actual Job Title Start Date – End Date
Constant Contact Actual Job Title Start Date – End Date
Fugro Actual Job Title Start Date – End Date
And so on.
No clever formatting.
No columns.
No graphical timeline.
No creative role names replacing the titles HR actually had on file.
Just:
Employer → actual title → dates.
The machine gets exactly what it needs.
The human doesn't have to consume the career that way.
Or, put another way:
Narrative for humans. Structured chronology for machines.
No, This Doesn't Mean Hiding Keywords
Whenever resumes and applicant tracking systems come up, somebody eventually recommends tricks.
Put keywords somewhere the reader can't see them.
Use white text.
Stuff every technology from the job description into the document.
Change titles to match what the employer wants.
Build one thing for the machine and another thing for the human.
No.
That's not what I'm talking about.
A compatibility interface should expose the same underlying truth in a form another system can understand.
It shouldn't lie about the underlying system.
If my Infrastructure as Code experience has centered on CloudFormation and the job description says Terraform, then the résumé says that. I’ve done some Terraform. I have not spent years using it in production.
CloudFormation.
Not Terraform.
Could I learn more about Terraform and how to use it?
Sure.
Have I spent years using it in production?
No.
Those are different statements.
The whole point of career archaeology was to stop turning careers into collections of optimized claims.
I'm certainly not going to spend all that time digging up the truth and then hide it under keyword stuffing.
Then There Was AI
There was another wrinkle in this application.
The company in question disclosed that it uses HiredScore to help identify relevant skills, experience and qualifications and compare them against the job description.
AI-assisted recruiting.
I opted in.
That may seem slightly odd coming from someone writing an article called:
AI is Preventing Me From Getting a Job.
But this experiment was never really about whether AI is good or bad.
I use AI every day.
I used AI to help create the resume I was submitting.
The interesting question is what we ask the AI to do.
I don't want AI inventing a better version of my career.
I don't want it deciding that CloudFormation is close enough to Terraform that nobody will notice.
I don't want it manufacturing metrics, leadership scope or experience because those things would make me rank better.
But if an AI system can look at:
AWS.
Kubernetes.
Jenkins.
Ansible.
Infrastructure as Code.
Platform engineering.
PCI.
Production migrations.
Developer enablement.
And the actual stories connecting those things...
...and make a better determination about whether there might be a useful conversation?
Great.
Have at it. I'm all for it.
In fact, that became another part of the experiment.
Could we write something more useful to a human without making it unintelligible to a machine?
I don't know yet.
That's why you ship experiments.
This Is Starting to Look Like Software
The more we worked on this, the more familiar the process became.
We didn't begin by choosing formatting.
We started by understanding the domain.
My career.
We gathered existing evidence.
We interviewed the subject-matter expert.
Also me.
We discovered requirements we hadn't understood at the beginning.
We modeled recurring patterns.
We separated the underlying information from the way different consumers needed to see it.
We built a baseline artifact.
Then a real job appeared.
And it became our first production use case.
We derived a targeted version from the baseline rather than rebuilding everything from scratch.
We deployed it.
Production exposed an assumption we'd missed.
Workday wanted structured chronology.
So we revised the interface.
That's not a failure of the experiment.
That's the experiment working.
Build.
Ship.
Observe.
Learn.
Revise.
Apparently I accidentally turned my resume into a software project.
Naturally, right?
The First Artifact Still Isn't the Resume
This is the part I don't want lost in the mechanics.
Adding structured employment history doesn't change the original conclusion.
The first artifact still isn't the resume.
The first artifact is the model underneath it.
The understanding of the career.
What problems have you repeatedly solved?
What constraints shaped your decisions?
Where did things go wrong?
What did you do when they did?
What changed because you were there?
What did you learn?
What patterns appear across companies that you couldn't see when every job was sitting inside its own chronological box?
What do you believe now because you earned the right to believe it?
Once you have that, you can produce lots of things.
A narrative resume.
A conventional employment history.
A targeted resume.
A LinkedIn profile.
A portfolio.
Interview stories.
A professional bio.
Articles.
Maybe even a better answer to:
Tell me about yourself.
They're different interfaces to the same underlying career.
That, I think, is the thing we've been missing.
So I Captured the Process
There was one final problem.
This worked because my AI collaborators and I have spent a lot of time together.
The coach knows when I'm hand-waving.
The coach knows when something sounds interesting enough to pull the thread.
And the coach has learned that turning every interesting thing I say immediately into polished resume language is a very good way to kill the interesting thing.
That's useful for me.
It's not particularly useful to anyone else.
So I documented the process.
We called it:
Career Archaeology.
It is not a resume prompt.
In fact, one of its first instructions is:
Do not begin by writing the resume.
Instead, the AI is instructed to act as interviewer, investigator, skeptical collaborator, pattern finder and eventually editor.
Ask what was happening.
Ask what wasn't working.
Ask why it mattered.
Ask what went wrong.
Ask who else was involved.
Ask for receipts.
Ask for the counterexample.
Ask what happened after the person left.
Don't polish too early.
Don't turn every answer into a bullet.
Don't invent precision.
Don't turn collaboration into individual heroics.
And don't optimize the person into somebody they aren't.
The process is designed to produce too much material.
That's intentional.
Excavation first. Editing later.
Only after the career has been understood do you build the baseline narrative.
And only after the baseline exists do you target it to a particular opportunity.
And you don't have to take my word for any of this.
Here's the ridiculous ten-page version that came out of the excavation:
Download Narrative Résumé v0.1
And here's the five-page version I actually shipped:
Download Narrative Résumé v0.5
Both have been scrubbed of personal information.
That's excavation and editing, side by side.
Never excavate the career again just because a different job description arrived.
One Career. Several Interfaces
We're still experimenting.
Version 0.5 went into production.
Workday found the bug.
I fixed it.
Version 0.6 shipped.
There will undoubtedly be a 0.7.
Maybe the whole thing turns out to be a terrible idea.
That's allowed.
But I know this much already:
I understand my own career better than I did when we started.
I can explain why certain projects matter instead of merely listing that they happened.
I can see engineering principles that followed me across companies, technologies and decades.
I have a much richer collection of stories for interviews.
And I finally have a resume that feels less like a document designed to survive a filing cabinet and more like an explanation of the engineer who might show up on Monday morning.
The chronology still matters.
The keywords still matter.
The machines still matter.
They just don't get to decide what the career means.
Narrative for humans.
Structured chronology for machines.
Truth underneath both.
And if you'd like to try excavating your own career instead of asking AI to rewrite your resume one more time, I'm giving away the instructions I used.
Hand them to your AI collaborator.
Then don't ask it to write anything.
Not yet.
Start digging. Ask it to interview you using career-archaeology as a guide.
And please, let me know what you think.
Postscript: I considered putting this in a repository you could clone, but decided a downloadable Markdown file was simpler. If the download gives you trouble, find me on LinkedIn and send me a message. I'll send it to you directly.
Postscript, September 2:
I was finishing this article this morning when this arrived.
So.
The narrative résumé went through Workday. It went through an AI-assisted recruiting process. It confused the employment-history parser badly enough that we discovered the résumé needed an API.
And now I have a recruiter screen.
Does that prove the narrative résumé works?
Nope.
One data point does not make a trend.
But it does mean our little production experiment just produced its first interesting result.
Stay tuned.