Tag: Resume

My Job Search at 50+: The Data Behind Landing a Tech Job in 2025
Author: Nicholas Hart
Date: Thursday, October 16, 2025
Reading time: 8-9 minutes

Tech Job Seeking in 2025

After 8 months and 90 applications I finally landed a job! I have never experienced a job market this tough during my whole career in software engineering–either as an individual contributor or manager. Anecdotally I see a lot of posts on LinkedIn about people struggling with the job market. I’ve never been out of work more than a month or so until now. It feels like this period in 2025 is different.

What’s different? Is it a realignment within tech spurred by AI and shortsighted tech CEOs chasing after more profit? Is it the fact that I’m over 50? Perhaps a bit of both. I don’t have all the answers, but I will share my data and offer some advice.

My Data

I submitted 90 job applications over eight months.
- 5 Director of Engineering
  - 1 interview (via referral) – 20% interview rate
  - 3 ghosted – 60% ghost rate
  - 0 pending
- 25 Senior Engineering Manager
  - 3 interviews (1 via recruiter, 1 via referral) – 12% interview rate
  - 3 ghosted – 12% ghost rate
  - 2 pending
- 37 Engineering Manager
  - 9 interviews (1 via recruiter, 3 via referrals) – 24% interview rate
  - 7 ghosted – 19% ghost rate
  - 8 pending
- 2 Software Architect
  - 1 interview – 50%
  - 2 ghosted – 100% ghost rate
  - 0 pending
- 11 Staff/Principal/Founding Engineer
  - 0 interviews – 0% interview rate
  - 5 ghosted – 45% ghost rate
  - 5 pending
- 7 Senior Engineer
  - 0 interviews – 0% interview rate
  - 0 ghosted – 0% ghost rate
  - 3 pending
- 3 Engineer
  - 0 interviews – 0% interview rate
  - 0 ghosted – 0% ghost rate
  - 1 pending
(A note on the numbers above–I still have 19 applications that have received no response yet, but I haven’t moved to ghosted yet, so those ghost rates may still go up!)

In total, I landed 14 interviews from these 90 applications–a 16% conversion rate.

It definitely helped to have a referral, although the job I ended up getting came from outreach from a recruiter. One other promising opportunity which I withdrew from (after receiving the offer I accepted) also came from a recruiter. The difference between these opportunities and all the others were that the recruiters were engaged, transparent, communicative, responsive, and reliable.

One of the opportunities I was pretty excited about, but the recruiter took weeks to get back to me after completing a final round of interviews. They repeatedly promised dates by which they’d have news, and when those dates passed without communication I would follow up after several days and get put off another week. It was very frustrating and eventually led to a rejection when I let them know I had another offer.

A few opportunities had a significant “homework” aspect–a presentation to create and present, or a take-home coding project. I probably spent too much time on these projects–I never got to a final round of interviews for any of them.

One that stung was an Engineering Manager role at a Seattle startup whose mission I was really excited about. They wanted a very hands-on manager and had me do a coding test, which I bombed–not because I’m a lousy engineer, but because I’m not a seasoned React engineer–I still look things up and rely on examples. It also didn’t help that I was told the coding would be focused on Typescript–which I am much stronger at.

I was rejected out of hand by a recruiter for one role that I was referred for by a former employee. It seems they were looking for someone with 8 years of hands-on React engineering experience. I almost wrote a blog post about this one. React 8 years ago looks nothing like React today! Any talented engineer can pick up a new technology. Setting arbitrary requirements on experience means you’re going to miss out on smart, motivated, experienced talent. Their loss!

My New Job

The role I ended up accepting is a Senior Engineering Manager role–which was my prior title at Sonos. The comp ended up being pretty close too. One of the huge bonuses is that the role is 100% remote. I won’t waste several hours of my time each week commuting to an office. I’ve demonstrated the ability to successfully lead distributed and remote software teams and am excited I get to continue to do so. (Here’s me thumbing my nose at all the “return to office” deadenders who argue this is the only way to go.)

The astonishing thing about this job is that the recruiter found me and reached out. Their posting had escaped my job search. I’m still curious to know why they reached out to me among a sea of candidates. I have no illusions about being well known, but I like to think I have a reputation among those who know me as a manager who does right by his employees (I always had above-average engagement scores from my teams at Sonos). When I’m on-site for orientation I hope to ask the recruiter about why I stood out.

Apply Early and Often

I was more likely to get traction on an application if I applied within a few days of the role being posted. Recruiters are overwhelmed by bot applications and genuine candidates are getting lost in the system. When searching LinkedIn make sure you look for posts within the past week (at most). Create job searches for roles posted in the past 24 hours and set alerts–when a new role of interest drops prioritize it, don’t wait!

(Sorry I wish I had kept more data on the age of job postings that I applied to!)

Focus on quality over quantity. You might want to have a few slightly different resumes–especially for a manager or senior engineer who is capable of leading in more than one specialization. Re-read and tweak your resumes–you may figure out some ways to improve them over time. Over the months I evolved several versions of my resume: mobile engineering leader, full-stack engineering leader, and staff engineer/architect in mobile.

I made sure to craft a personal cover letter for each application. Over time I evolved this process as well, so that I had a standard template for a manager or staff engineer role–a couple of concise paragraphs that tell a story about my technical and leadership expertise. Then I’d write a custom intro paragraph that had some sort of hook that connects me to the company and the specific role. I might tweak the other standard paragraphs if there was a particular aspect of my experience worth emphasizing.

I aimed for 2-4 quality applications per week. If I couldn’t see myself connecting to the role in some way and write an intro paragraph for a cover letter, then I simply passed on it. There are certain toxic companies (including several of the FAANG) that I simply avoided–personal preference as well as disrespectful past interview experiences. Perhaps this also reflects upon my over 50 attitude–I’ve done jobs for a paycheck before and at this point in my life finding a meaningful opportunity is of critical importance to me.

Keep the applications going, even when you’re interviewing. You want to keep your pipeline full, even if you made it through the final round for your dream job. They might pick someone else, and when you need a paycheck you can’t afford a lull in the job search process.

Referrals Are Key

Work your network. Reach out to former colleagues, friends, and family and get those referrals in. It helps! I had the best luck getting an interview via connections that I knew well. Those 2nd degree connections, not so much. Be sure to connect with people you’ve worked with, and don’t just slide into their DMs with “hey remember me from 10 years ago when we occasionally were in the same meeting? Could you refer me please?” Put in some effort, re-establish the connection, find out how they’re doing–ask about the company and if they have any insight. Build genuine connections and referrals often follow naturally.

Sometimes the job posting on LinkedIn has a recruiter or hiring manager you can reach out to. I tried this a few times and never got a response, nor an interview. They’re probably inundated with requests. It probably doesn’t hurt your chances, but don’t toss some clearly AI-generated message their way, or a form letter with misspellings. I think the thing here is to come across as a real human, with some sort of connection to the role that will make them want to bother fishing your application out of the thousands in their system and give it a look.

Job Searching Over 50

I’m afraid I don’t have any data here, just anecdotes from LinkedIn (I sure see a lot of people talking about ageism), and my own experience. My best advice is:
- Remove work experience older than 20 years from your resume. Chances are it’s not relevant to what you’re doing today and it’s taking up valuable real estate.
- It’s ok to leave the graduation date off your education.
- Actively learn new technologies and practice your coding skills. It’ll help with your interview conversations and look good on your GitHub profile.
Keep Your Skills Fresh and Relevant

One of the things that kept me going was working on personal projects–many of which I made public. I have no idea whether this factored into getting hired or not, but if a recruiter or hiring manager bothered to look at my GitHub profile they would see that I am writing code and learning. Plus if anyone wanted to drill in to my projects they’d see well-organized code with tests and automation. This regular practice will also help in interview conversations and technical screenings.

Expect to be Ghosted

Kudos to the recruiters who took the time to reach out with a personal message. I know you’re swamped! When I get a personal response, that is a company I will want to re-apply to someday. It’s nice even to get the automated rejections so I can cross one off my list. Applications that linger in limbo with no response are frustrating, but the reality is that many of one’s applications will never get an acknowledgement beyond the initial automated “thanks for your application” email. If it has been more than 4 weeks with no contact I move an application to the “ghosted” pile and move on.

Keep Your Chin Up

This process is demoralizing, frustrating, and filled with disappointment.
- That role you thought you were perfect for and got an automated rejection…
- The interview loop you thought you nailed but they’re moving forward with other candidates…
- The recruiter you had a promising conversation with and never heard from again…
I see a lot of people posting a lot of negativity on LinkedIn about how broken the hiring process is, how frustrated they are, how unfair it all is. I see the recruiters who are frustrated and overwhelmed too. The thing is, I don’t think posting negativity is going to help you in the long run. I do enjoy reading some of the more creative and humorous posts about how rough the job search is, and I hope it works out for them!

If you’re an engineer my advice is to keep busy, show off what you’re building, put a positive spin on your public posts, and find some friends and family with whom you can commiserate with privately.

This is all my own data, personal experiences, observations, and advice. I hope others find it helpful. Your mileage may vary.

About the Author

Nicholas Hart is a software engineer and technical writer passionate about sharing knowledge and helping others learn. You can find more of my work at:
- Website: nickhart.com
- GitHub: github.com/nickhart
- LinkedIn: linkedin.com/in/seanickhart
October 16, 2025
Automating Job Applications with Markdown: From 60 Minutes to 20 Minutes
Who This Is For: This workflow is designed for developers and technical professionals who are comfortable with command-line tools, enjoy working in code editors like VSCode, and who prefer markdown for writing (or are willing to give it a try). If you’re already using git for version control and don’t mind a bit of setup for long-term efficiency gains, this approach could save you significant time during your job search.

Introduction 💡

Job applications are tedious. Between customizing resumes, writing cover letters, tweaking formatting, and tracking applications, I was spending hours on administrative work instead of finding and responding to great opportunities–or working on side projects which I find infinitely more interesting.

A little while ago I wrote a blog post on writing with markdown, which has greatly sped up my writing process. I’ve been using it for several weeks now and have made a bunch of automation improvements which enable me to quickly create a job application, customize a resume, draft a new cover letter, and track each application’s progress.

I also took this opportunity to give Claude Code a test drive and see how it could help me build out some new automation scripts. In the past I’ve found agents like Cursor to be too aggressive–cranking out code faster than I can wrap my head around it. If I’m trying to learn something I want to go slow, ask questions, and understand what’s being built. Agents can’t reason but they’re good at replicating patterns, so I want to make sure it stays on track. (I’ll write more on Claude Code later–but so far I really like it!)

The result of this collaboration is my new workflow, which I wanted to share with others: Markdown Writer. It’s still a work in progress, but if you like working in an IDE and are comfortable with a CLI you might find this a good way to manage your job applications.

Why not use existing job tracking tools? TBH, I didn’t even research what’s available–I just knew I wanted to stay in my IDE where I’m most comfortable and productive. As developers, we often build our own tools not because existing solutions don’t exist, but because we have specific workflows and preferences. I wanted something that felt like coding: version-controlled, scriptable, and integrated with my daily development environment. Plus I wanted a small project to experiment with AI.

Get Set Up ⚙️

I use VSCode because it has great integration of file/project navigation, editing, helpful extensions, terminal integration, key bindings, snippets, and custom command integration. However this will also work with your favorite code editor and either zsh or bash in your terminal.

This project is available as a GitHub template repository, making it easy to create your own private copy with one click. Simply visit the Markdown Writer repository and click “Use this template” to create a new repository in your GitHub account.

If you prefer to clone and experiment first, you can use the repository directly:
```
git clone git@github.com:nickhart/markdown-writer.git
```
However, for ongoing use, I recommend creating your own repository from the template so you can customize it and track your applications privately. When there are updates to the main Markdown Writer repository, you can use the included script (scripts/sync.sh) to copy updates from the upstream repository to your own, or manually copy specific files you want to update.

Requirements 📋
- zsh or bash
- VSCode or other code editor
- clone Markdown Writer
Installing ⬇️
```
git clone git@github.com:nickhart/markdown-writer.git
cd markdown-writer
./setup.sh
```
NOTE PDF formatting is supported, but requires installation of a LaTeX package. Out of the box Markdown Writer works great for creating DOCX files.

Configuring 🔧

Edit .writing.yml with your information. You can see an example .writing.yml here.

Edit your resume and cover letter templates:
- templates/resume/default.md
- templates/cover_letter/default.md
If you wish to customize your document formatting you can edit the styles in the files located below. Be sure to modify the standard styles (Heading, Heading 2, Body, etc…), then save the changes to reference.docx. Pandoc will use these reference files and use the styles in them when generating your formatted resume or cover letter.
- templates/resume/reference.docx
- templates/cover_letter/reference.docx
You should now be ready to go. The system supports multiple resume templates. For many people “default” might suffice, but I find myself applying to a few different kinds of roles and have one tailored more towards mobile, frontend or fullstack… so I have resume templates with each of those names.

Workflow 🔄

Applying To a New Job 📝

When I want to apply to a new job from the terminal I run
```
job-apply Acme "Engineering Manager" default "http://acme.com/jobs/engineering-manager/1234"
```
Or if I want to use a specific resume template other than default:
```
job-apply Acme "Engineering Manager" fullstack "http://acme.com/jobs/engineering-manager/1234"
```
This creates a new job application in the applications/active/acme_engineering_manager_20250624 directory. It copies my “default” resume template and standard cover letter and performs the variable substitution using my .writing.yml. It downloads the job description at the provided URL and saves it as an html file (job_description.html). It creates a metadata file (application.yml) which contains the company name, role, job description URL, and date created.

Then I go in and tweak the resume as needed (perhaps just the title, maybe the intro blurb), and then crank out a few brief paragraphs for the cover letter. Usually I want to customize the intro to the cover-letter, but often I’ve already got some good content from prior cover letters which addresses particular needs/requirements in the job description. The organization of the applications makes it super easy for me to find a prior cover letter, lift a few sentences and add them into my new cover letter.

Then I run job-format acme_engineering_manager_20250624 and it automatically formats my markdown resume and cover letter into DOCX format, using reference template files with my preferred styles and page format. The formatted versions go into a formatted subdirectory of the application. The .gitignore automatically excludes the formatted docs from being committed–but if one wished they could tweak that and commit the formatted files too.

From here it’s a matter of uploading the DOCX files to the job application and filling out the rest of the application information.

Some applications require some essay-style questions, in which case I add another markdown file to the application folder (eg: application_questions.md) and use my same editing process. I don’t bother formatting these into DOCX but it’s nice to have a record of my responses and then it’s easy to copy/paste them into the application form.

Submitting and Tracking the Application 📤

When I’m satisfied with the application I have a helpful command to commit it to my repo:
```
job-commit acme_engineering_manager_20250624
```
Once I’ve submitted the application, and as it moves through the review process I have a command to update its status:
```
job-status acme_engineering_manager_20250624 submitted
job-status acme_engineering_manager_20250624 interview
job-status acme_engineering_manager_20250624 offered
job-status acme_engineering_manager_20250624 rejected
```
Each of these statuses has its own sub-folder inside the applications folder in the project root. The job-status command moves the application from one folder to another and updates the status in the application.yml metadata file.

If I get to the interview stage (w00t!) I take notes in a markdown file which I keep in the application’s folder, eg:
```
applications/
  interview/
    acme_engineering_manager_20250624/
      recruiter_notes.md
      hiring_manager_notes.md
      interview_loop_notes.md
```
I also have a job-log command which will show a summary of all my applications, or just ones in a certain status. Right now the summary is terse, but I intend to make it a bit fancier in case someone in the state unemployment office decides to challenge me. It will be trivial to take the metadata and generate a log of each job application in DOCX format to prove I’ve exceeded their “three job activities a week” requirement.

VSCode Integration 🛠️

I mentioned in my prior post about how I like to use VSCode for my markdown writing. For those who are also using VSCode it will recommend some extensions that I find handy:
- Markdown All in One
- Code Spell Checker
- markdownlint
- Word Count
- YAML
The VSCode configuration adds some helpful settings for Markdown and YAML editing, as well as allowlisting some common words that the spell checker might flag.

It also adds some commands to the command palette. With a simple cmd-shift-p to open the command palette, select Run Tasks, and choose one of my commands like Create Job Application. It’ll prompt me for the company name, role, which resume template (or use default), and the URL for the job description. It’ll run the command in a terminal and show me the output!

Wrapping Up and Next Steps 🚀

In my last post on this topic it was taking me an hour to do what now takes me 20 minutes–and most of that time is me thinking about what I want to write and entering it into a markdown file. I still only apply to a few jobs a day, but I can focus on applying to the roles that really interest me, take the time to craft a thoughtful cover letter, and then have more time to work on my other projects or write a blog post.

I will continue to use the Markdown Writer to craft my job applications. I also use it for blog posts and format the results into HTML which I can copy/paste into WordPress. No doubt I will continue to refine this aspect of my writing workflow.

And if you’re curious about some of the other features I’m planning for my job application workflow, take a look at the TODO!
July 1, 2025
Markdown Writing Workflow: How I Write 3x Faster
The Power of Writing Everything in Markdown First

I’ve been writing tons of resumes, cover letters, and blog posts lately. Word processors felt cumbersome—too much time formatting, too much repetitive work. Then I realized: why not approach writing like an engineering project?” Instead of jumping straight into WordPress, Google Docs, or Apple Pages, I now write everything in VSCode using markdown.

Blog posts, resumes, cover letters, interview notes, writing assignments… they all go into markdown first. Then I use Pandoc to convert them to whatever format I need.

The results? I’m faster, more focused, and my content is way more portable.

Why Markdown Makes Sense 📝

I find writing in a word processor to be distracting—there are so many formatting choices. I just want to focus on the content and have a standard format for the output. This is why markdown appeals to me. It’s simple and consistent.

Perhaps it’s the engineer in me, but I feel like I have more power and control over the structure of my writing. It’s easier to “refactor” the structure of my prose and move ideas around for a better flow.

Markdown gets all the formatting out of the way. You focus purely on content and structure. The syntax is dead simple: **bold**, *italics*, # headers, - lists, and [links](url) — but nothing more.

Why VSCode? ⚡

VSCode helps keep my files organized, easy to find, easy to search, and fast to switch context. It’s a fast, flexible text editor, and extension support for Markdown and other formats is a huge time saver.

All of my files are organized into folders in a single project. When I’m done writing a resume I can quickly switch to my cover_letters folder, create a new markdown file, copy/paste my boilerplate contact info, salutation, and start writing.

Also VSCode has a great built-in preview that lets you see how the markdown will render. The stroke of a few keys (Cmd + shift + V on macOS) and you can see the results instantly.

The Secret Sauce: Pandoc 🔧

I use Pandoc to do my conversion. It’s a simple command line tool that you can run from the terminal inside VSCode. I used to keep Terminal windows open all over the place to run command line tools, but using the terminal integrated into VSCode helps keep everything organized and in one place.

Project Structure 📂

I mentioned using VSCode to keep my files organized. Here’s a rough sketch of my project structure:
```
writing/
├── blog/
│   └── formatted/
├── assignments/
│   └── company_x/
│   └── company_y/
├── resumes/
│   └── formatted/
├── cover_letters/
│   └── formatted/
└── interviews/
    └── company_x/
    └── company_y/
```
I keep the markdown organized into top-level folders (blog posts, assignments, resumes, interviews, etc.) and for interviews and assignments I use sub-folders for each company. Any place I want to generate a formatted version from markdown I use a formatted sub-folder.

On occasion if I feel the need to do some custom formatting in a wordprocessor I add some notation to the edited filename (eg: resume_company_x_edited.docx) as a reminder not to blow it away by re-generating from the markdown.

Version Control with Git 📋

Since I’m treating writing like an engineering project, I use Git to track all my markdown files. This gives me powerful revision history, the ability to see exactly what changed between drafts, and easy restoration if I mess something up.

VSCode’s Git integration makes this even better—I can see at a glance which files have changes, view diffs right in the editor, and commit directly from the IDE without switching to the terminal.

I keep a .gitignore file that excludes the generated content:
```
# macOS
.DS_Store
._*

# Ignore generated formatted files
*/formatted/
*.pdf
*.docx
*.html

# But keep the reference template(s)
!reference.docx
```
This way my repository stays clean with just the source markdown files, but I can still track my reference templates. The formatted outputs are disposable since I can regenerate them anytime with pandoc.

The Workflow 🚀

Here’s what my typical workflow looks like now:
1. Open VSCode and create a new .md file in the appropriate folder
2. Write the entire piece without worrying about final formatting
3. Preview the markdown in VSCode and make sure it looks good
4. Convert to whatever format I need (HTML for WordPress, DOCX for resumes, etc.)
5. Proofread the formatted version (check fonts, margins, spacing, etc.)
6. Upload the formatted version to WordPress, a job application, or anywhere you need it
I have a bunch of aliases for pandoc that make the conversion process a breeze. Add these to your ~/.bashrc or ~/.zshrc file to make them available in your terminal.
```
# HTML for blog posts (clean, WordPress-friendly)
md2html() {
    pandoc --no-highlight --wrap=none -t html -o "./formatted/$(basename "$1" .md).html" "$1"
}

# DOCX with reference template
md2docx() {
    pandoc --reference-doc=reference.docx -o "./formatted/$(basename "$1" .md).docx" "$1"
}

# PDF via LaTeX
md2pdf() {
    pandoc -o "./formatted/$(basename "$1" .md).pdf" "$1"
}
```
Each format serves a specific purpose: HTML works perfectly for pasting into WordPress or web platforms, DOCX is what most job applications expect for resumes and cover letters, and PDF is ideal for sharing finalized documents that need to look identical everywhere. You can use PDF for resumes and cover letters, but I have read that some ATS scanners can choke on it, which is why I stick to DOCX.

Making a Reference DOCX Template ⚙️

To create a reference DOCX template, start by generating a basic one from any markdown file: pandoc sample.md -o reference.docx. Then open this file in Microsoft Word (or your favorite word processor which can export to DOCX) and customize all the styles you care about: fonts, margins, headings, paragraph spacing, etc. The key is to modify the actual Word styles (like “Heading 1”, “Normal”, “Strong”) rather than just formatting individual text, since pandoc maps markdown elements to these named styles. Save the file, and now every time you use --reference-doc=reference.docx, your converted documents will inherit this formatting. You only need to set this up once, and it works great for making professional-looking resumes and cover letters that maintain consistent branding across all your materials.

You can also put this file somewhere central like ~/.pandoc/reference.docx so you can easily access it from anywhere. However, for my workflow I like to keep a separate reference.docx in each project folder so I can easily customize the formatting depending on the type of content.

The Portability Game-Changer 🎯

The portability of using markdown and Pandoc is incredible. I usually generate my resumes into DOCX format because I think ATS scanners sometimes choke on PDF, but if you want it in PDF it’s just a one line command.

The learning curve for Markdown is minimal too (although if you’re an engineer you’re already probably familiar with it). If you can remember that # makes headers and **text** makes things bold, you’re 90% there. GitHub has a great tutorial on using Markdown. It’s very handy if you need a quick reference or refresher.

Future Automation Ideas 🔮

I’m planning to automate this even further. Git hooks could automatically regenerate formatted versions whenever I commit changes. Imagine pushing a blog post update and having the HTML automatically ready for WordPress!

I’m also thinking about a simple script that can create new WordPress posts directly from my markdown files and leveraging WP-CLI.

The best workflows are the ones that get out of your way and let you focus on what matters: the actual work.

Have you tried writing in markdown? I’d love to hear about your workflow experiments.
June 6, 2025