DEV Community: charlie-morrison

I Applied to 40 Jobs: Easy Apply vs Company Site — Where the Replies Actually Came From

charlie-morrison — Tue, 23 Jun 2026 20:01:36 +0000

There is a permanent argument in every job-search forum: should you use LinkedIn's one-click Easy Apply, or should you go to the company's own careers page and fill out the real form? One camp says Easy Apply is a black hole that drops your resume into a pile of 900. The other says the company site is a waste of fifteen minutes per application that nobody reads anyway. Both sides argue from feeling, because almost nobody tracks which channel actually got them a human reply. So over three weeks this spring I sent 40 applications, split evenly between the two channels, and logged every single response. The headline gap was real — but it pointed at something other than the channel, and once I saw it the whole debate looked like the wrong question.

How the test was built

I kept the variables tight so the comparison would mean something. Every application was for a senior backend or platform engineering role, all remote or hybrid, all posted within the previous ten days (stale postings are a known reply-killer and I did not want that noise). I alternated channels strictly: odd-numbered roles went through LinkedIn or Indeed Easy Apply, even-numbered roles went through the company's own careers page — usually a Greenhouse, Lever, or Workday form. Same base resume, same week, same me.

I counted a "reply" as any response from a human: a recruiter screen invite, a "tell me more about your payments experience" email, or even a rejection that referenced something specific in my application. I deliberately included specific rejections, because a templated auto-reject tells you nothing, but a rejection that quotes your background means a person actually opened the file. Three weeks is enough to catch the fast-moving teams and miss the slow ones, so treat the absolute numbers as a snapshot, not a law of physics. The shape is what held up.

The headline numbers

Here is the channel split, straight off my tracking sheet:

Channel	Sent	Human replies	Recruiter screens	Reply rate
Easy Apply (LinkedIn / Indeed)	20	3	1	15%
Company career site	20	6	4	30%

40 applications over three weeks, May 2026, senior backend / platform roles.

So the company site doubled the reply rate and quadrupled the recruiter screens. If you stop reading here you would conclude "always use the company site," and a lot of advice does stop exactly here. But that conclusion ignores the cost on the other side of the ledger, and it ignores a second column I was tracking that turned out to matter more.

The cost first. An Easy Apply submission took me about 90 seconds — confirm the resume, answer two or three screening questions, done. A company-site application averaged closer to 14 minutes: create yet another account, watch a Workday parser mangle my resume into empty fields, retype half of it by hand, answer the "describe a time you…" boxes. Twenty company-site applications ate roughly four and a half hours. Twenty Easy Applies ate half an hour. If your only goal is raw reply count per hour of effort, the gap closes fast — and that is before the second column.

The column that actually predicted replies

Next to "channel," I had logged whether I tailored each application — meaning I rewrote the resume summary line and made sure the five to eight skills the posting emphasized appeared, in the posting's exact wording, somewhere in my resume. Not lying, not stuffing; just making the words match the words a recruiter and their software would search for. When I re-sorted the same 40 applications by that column instead of by channel, the picture changed completely:

Group	Sent	Human replies	Reply rate
Tailored to the posting	14	7	50%
Sent as-is (generic resume)	26	2	8%

Same 40 applications, re-sorted by whether I tailored the resume to the posting.

Tailoring beat not-tailoring by roughly six to one, and that gap dwarfed the channel gap. The channel comparison was real, but it was mostly measuring tailoring in disguise — because of where the tailored applications happened to land. When I cross-tabbed the two columns, the trick became obvious:

Easy Apply: I tailored only 4 of 20. The friction is so low that I clicked through 16 of them on autopilot with a generic resume. Of the 4 tailored, 2 got replies; of the 16 generic, 1 did.
Company site: I tailored 10 of 20. Sitting through a 14-minute form puts you in a frame of mind where you actually read the posting and adjust. Of the 10 tailored, 5 replied; of the 10 generic, 1 did.

Read the company-site advantage again with that in mind. The careers page did not have some magic recruiter hotline that Easy Apply lacks. It just forced me to slow down, and slowing down is what made me tailor. The channel was a proxy for effort. The friction I was cursing the whole time was quietly doing the one thing that worked.

Why matching the words does so much work

The mechanism is not mysterious. Most mid-to-large companies route applications through an applicant tracking system, and the first pass — whether automated or a recruiter skimming a list — ranks candidates on how well the resume matches the requisition's language. Purdue's writing lab is blunt about this in its guidance on resumes: a resume is a targeted document, and the closer it speaks the employer's own terms back to them, the better it travels through screening. A generic resume that says "built scalable services" when the posting asks for "Kubernetes," "Kafka," and "PCI-DSS" gives the ranker almost nothing to grab.

And recruiters do not read; they scan. The Nielsen Norman Group's long-running research on how little users actually read applies to a resume in a stack just as much as to a web page — the first scan is a hunt for matching keywords, and only the resumes that survive that hunt get read like prose. Tailoring is just making sure your resume wins the scan it is actually subjected to, instead of the careful read you wish it got. I saw the same lesson when I sent 30 cover letters split between personalized and template — the personalization gap was real, but a concrete, specific opening line did far more than generic effort, for the same reason: it gave the reader something precise to latch onto in the two seconds they spent.

So tailor — but make it cost 30 seconds, not 14 minutes

The obvious objection: if tailoring is the lever, and the company site makes you tailor, just use the company site, right? No — because the 14 minutes of Workday data entry was never the part that helped. The retyping is dead weight; the tailoring is the live wire. The win is to keep the tailoring and throw away the friction: use Easy Apply for its speed, but spend 30 of those saved seconds pulling the posting's real keywords first.

That is the gap I built a free tool for. The Job Description Keyword Extractor takes the full posting, finds the technical skills and action verbs it actually emphasizes, and hands them back as a checklist you can match your resume against before you click apply. Here is a real run on one of the senior-backend postings from this batch:

Paste the posting, get the exact technical skills and verbs it weights — 13 here, grouped and copyable.

It pulled thirteen terms in a couple of seconds — Kubernetes, Kafka, PostgreSQL, PCI, Terraform and the rest — and the only job left was to confirm each true one appeared in my resume in that wording. That is the whole tailoring step for an Easy Apply, done in well under a minute.

What I actually changed after the test

I did not pick a side in the channel war. I changed how I use both:

Default to Easy Apply for speed, but never on autopilot. Before every click, paste the posting into the keyword extractor and confirm the true matches are in my resume. LinkedIn's own description of how Easy Apply works is honest that it submits your existing profile and resume as-is — which is exactly why a generic profile gets a generic result. The channel is fine; coasting on it is the problem.
Reserve the 14-minute company-site forms for roles I genuinely want. If I am willing to spend a quarter hour, I am willing to tailor hard, and that is where the company site pays off. For roles I am only curious about, the slow form is not worth it — a tailored Easy Apply gets most of the benefit at a tenth of the time.
Track replies by tailoring, not by channel. Once I started logging the column that actually predicted outcomes, the channel question stopped feeling important. The reply rate follows effort applied to matching the posting, wherever the form happens to live.

The cleanest way to say it: the company site does not beat Easy Apply — tailoring beats not-tailoring, and the company site just tricks you into tailoring. Take the trick away, keep the behavior, and you get the company-site reply rate at the Easy Apply price.

Common questions

Is LinkedIn Easy Apply really a black hole?
Not by itself. In this batch the Easy Apply roles I tailored replied at 50% — the same rate as tailored company-site applications. The black-hole reputation comes from how easy it is to send 20 generic ones in ten minutes without adjusting anything. The channel is not the problem; the autopilot it invites is. Slow down for the 30 seconds it takes to match the posting's keywords and Easy Apply performs fine.

Doesn't matching keywords just mean stuffing my resume?
No. The point is to use the posting's exact wording for skills you genuinely have — "Kubernetes" instead of "container orchestration," "PostgreSQL" instead of "relational databases" — so the screening pass can match them. Stuffing keywords you cannot back up gets caught in the first conversation and wastes everyone's time. Tailoring means accurate matching, not inflation.

How many applications a day does this allow?
Fewer than spray-and-pray, more than people fear. A tailored Easy Apply runs about two minutes end to end with the keyword step, so 10–15 a day is sustainable. The point of this test is that 10 tailored applications beat 40 generic ones on replies — so the lower number is the higher-yield play, not a compromise.

What counted as a "reply" in your numbers?
Any response from a human: a recruiter screen invite, a specific follow-up question, or a rejection that referenced something concrete from my application. Templated auto-rejections did not count, because they signal nothing about whether a person opened the file. Three weeks is a snapshot, so weigh the pattern over the exact percentages.

So the honest summary: across 40 applications the company career site replied at double the rate of Easy Apply, but that gap was mostly tailoring wearing a channel costume. Sorted by whether I matched the posting, tailored applications replied six times more often than generic ones, regardless of where I sent them. Use the fast channel, keep the slow channel's one good habit, and stop paying fifteen minutes for something a 30-second keyword check gives you for free.

If you want the full set that makes tailoring quick — keyword extractor plus resume-bullet, cover-letter, and salary-script generators — I bundled them as the Job Search AI Toolkit ($12).

This post contains affiliate/product links. I may earn a small commission if you buy — at no extra cost to you. This article was written with AI assistance and reflects my own tracked job-search experiment.

I Rewrote 50 LinkedIn Headlines — Search Appearances Moved, Profile Views Mostly Didn't

charlie-morrison — Mon, 22 Jun 2026 22:06:52 +0000

Most people set their LinkedIn headline once, by accident. You change jobs, LinkedIn auto-fills "Senior Software Engineer at Acme Corp," you click save, and that line follows you everywhere — search results, connection requests, the comment you left on someone's post, the "people you may know" card. It is the single most-displayed sentence you own on the platform, and most of us let a default write it. So this spring I ran a narrow test: rewrite 50 of these headlines, change nothing else, and watch two numbers — how often the profile appeared in recruiter searches and how many profile views it earned. The result split cleanly in a way I did not expect. The keyword-front rewrites got found far more often. The view count barely cared.

That gap turned out to be the whole lesson. The headline's real job is not to impress the person already looking at your profile — it is to get you into the search results in the first place. Once I separated those two jobs, the advice I had been repeating for years stopped making sense, and the data pointed at something simpler.

How the batch was built

Fifty LinkedIn headlines, rewritten across May and the first half of June 2026. As with my earlier profile experiments, this was not a clean random sample — it was the people in reach: about thirty from coaching sessions (mid-career engineers, a cluster of product managers, a few analysts and designers) and twenty from a job-search community where I offered free headline rewrites in exchange for permission to record two public-ish numbers each week.

I held everything else still. I touched only the headline — not the About section, not the experience entries, not the skills list, not the photo — because the entire point was to isolate one field. For each person I logged the same pair of metrics the week before the change and again two to three weeks after: search appearances (LinkedIn's "you appeared in X searches this week" number) and profile views (the 7-day count the owner sees). Search appearances is the metric almost nobody watches, and it is the one that turned out to matter for a headline.

What the headline actually controls

The reason the two numbers behave differently comes down to where the headline sits in LinkedIn's machinery. When a recruiter looks for candidates, they do not scroll a feed — they search, usually with role and skill keywords, and LinkedIn ranks who shows up. The fields it weighs most heavily for that ranking are the ones at the top of your profile, and the headline is the most prominent of them. LinkedIn's own guidance for recruiters on attracting recruiters with keywords is direct about it: the words you put in your headline and current role are what make you findable, because those are the words recruiters type. A headline that only restates a job title gives the search engine almost nothing extra to match against.

Profile views are a different animal. By the time someone is looking at your profile, the headline has already done its finding job; whether they stick around depends on the photo, the About opener, and the rest of the page. That matches what I found rewriting 40 About sections earlier this spring — the visible opener moved views, the buried text did not. The headline and the About section are not competing for the same job. One gets you into the room; the other decides whether you are worth a second look.

The four headline patterns I tested

Across 50 rewrites, four patterns kept recurring. I sorted every rewrite into one of them before checking the numbers, so I could see which structure did what.

Headline patternExample shapeEffect on search appearances

Title-at-Company (the default)"Senior Engineer at Acme Corp"Flat — the baseline
Title + 2–3 role keywords"Senior Backend Engineer | Go, Kubernetes, Distributed Systems"Strong lift
Title + one concrete value claim"Backend Engineer | Cut payment latency 40% across 3 services"Solid lift, smaller than pure keywords
Keyword stuffing (5+ terms, pipes everywhere)"Engineer | Go | K8s | AWS | Terraform | CI/CD | Agile | Leader"Diminishing — no better than 3 keywords, often worse

The default "Title at Company" is the baseline because LinkedIn already knows your title and company from the profile fields — repeating them in the headline adds no new searchable term.

The clearest finding: the default headline is a wasted field. "Senior Engineer at Acme Corp" repeats two facts LinkedIn already has in structured form. It reads fine to a human and contributes almost nothing to whether a recruiter searching "Kubernetes backend" ever sees you. The profiles that opened with their real role plus two or three genuine skill keywords showed the largest jump in search appearances in the batch — and they did it without looking like spam, because three relevant nouns is still a sentence a person can read.

The keyword-stuffing pattern was the surprise. The common advice is "load it with keywords," so I expected the eight-term pipe salad to win on raw findability. It did not. Past roughly three keywords the search-appearance gains flattened, and a couple of the most stuffed headlines actually dipped — partly, I suspect, because LinkedIn's newer search leans on semantic relevance rather than raw term-matching, and a wall of disconnected terms reads as noise to a ranking model the same way it reads as noise to a person. Stuffing also costs you the one thing the headline can still do for a human reader: make sense. A headline that is just a list is a headline nobody finishes.

The before and after

I tracked weekly search appearances and weekly profile views for all 50, before the rewrite and two to three weeks after. The headline change moved search appearances hard and profile views barely at all — which is exactly what you would predict if the headline's job is findability, not persuasion.

MetricMedian beforeMedian afterChange

Weekly search appearances917+89%
Weekly profile views2831+11%

The same edit nearly doubled search appearances while leaving profile views roughly where they were. The headline gets you found; it does not, on its own, get you read.

Breaking it down by pattern made the mechanism even plainer. The profiles that switched from the Title-at-Company default to "title + 2–3 keywords" carried almost the entire search-appearance gain. The ones that were already keyword-aware barely moved, because they had little room left to move. And profile views drifted up a little everywhere, in a way that looked more like normal week-to-week noise than a headline effect.

I will be honest about the limits, because these are noisy, platform-controlled numbers. Search appearances depend on how many recruiters happened to be searching your field that week; profile views drift with your own activity and the feed's mood. Fifty profiles tracked observationally over a few weeks is a directional pattern, not a controlled study, and I will say so again at the end. But the direction was consistent and it matched the structure of how LinkedIn search works, which is the most I ask of a number like this.

The rule I now use — and the four checks behind it

One sentence: spend your headline on the words a recruiter would type, not the title LinkedIn already knows. I built that into a quick scoring habit, and eventually wired it into the free LinkedIn Headline Generator on this site — it takes a role, a few skills, an industry, and one value claim, and returns several patterned variants with a character count so you can compare them side by side. Here is a real run for a senior backend engineer:

!The free LinkedIn Headline Generator on charliemorrison.dev showing six generated headline variants for a senior backend engineer — labelled Classic, Authority, Specialist, Impact, Expert and Signature — each with a character count out of 220. The Signature variant embeds a concrete metric, 'Cut payment latency 40 percent across 3 services,' while the Specialist variant opens with the weaker word 'Experienced.'

The same input, six patterns. Note the contrast: the "Signature" variant front-loads a real number, while the "Specialist" variant opens with "Experienced" — the kind of filler word that, as I found rewriting About sections, quietly says nothing.

The tool just enforces by hand what the data kept showing. These are the four checks I now run on every headline, mine included:

Don't restate your title and company. LinkedIn already stores both as structured fields. If your headline is just "Title at Company," you are spending your most-searched line on words that add zero new search terms.
Name two or three real skill keywords. The exact nouns a recruiter would search — "Kubernetes," "FP&A," "clinical trials." Two or three that are genuinely yours beat eight that are aspirational. Front-loading these is the same matchability lesson the team behind my skills-section audit found one field over.
Stop at three keywords. Past three, search appearances flatten and the line stops reading like language. A headline that is a keyword dump is the one that gets skimmed past by both the algorithm and the human.
Earn the leftover space with one concrete claim. If you have characters left after role plus keywords, spend them on a checkable outcome — a number, a named system — not an adjective. It will not move search much, but it is what makes a human stop on you once the keywords got you found.

The character cutoff matters too, for the same reason it matters in the About section: people read the front of a line and skim the rest. The Nielsen Norman Group's research on how little users actually read is blunt about it — most visitors take in a fraction of the words on screen, and they take in the start of a block far more than the end. On the contexts where your headline is truncated hardest — a connection request card, a notification, the mobile search list — only the first chunk shows. So whatever your keywords are, put them first.

I wired the rule into a free tool on my site — a LinkedIn Headline Generator that takes a role, a few skills, an industry, and one value claim and returns several patterned variants with a character count so you can compare them: https://charliemorrison.dev/linkedin-headline. If you want the headline, About, resume-bullet, and keyword tools in one place, the Job Search AI Toolkit is $12.

Frequently asked

How long can a LinkedIn headline be?

The field allows up to 220 characters, but several places where your headline appears — search result rows, connection request cards, mobile — show far fewer before truncating. Treat the limit as 220 for keyword room, but write so the most important words land in the first 60 or so characters, where they survive every layout.

What are search appearances, and where do I find them?

Search appearances is LinkedIn's count of how many searches you showed up in over a recent window, shown on your own profile dashboard along with profile views. It is the closest public signal you have to "are recruiters finding me," which is exactly the thing a headline controls — so it is the number to watch after a headline change, not just profile views.

Should I really not list more than three keywords?

You can list more, but in this batch the search-appearance gains flattened past about three and a few heavily stuffed headlines did worse. The cost of stuffing is real: it reads as noise to a human and, with LinkedIn leaning more on semantic relevance, a disconnected term list does not buy the matchability it used to. Pick the two or three keywords that are most genuinely you.

Will a better headline guarantee more interviews?

No. A headline gets you found in more searches — that is what the data here shows it doing. Whether being found turns into a view, a message, or an interview depends on the rest of your profile and the role itself. The headline removes one bottleneck (invisibility in search); it does not replace the work the rest of the page has to do.

So the honest summary: rewriting a headline is one of the biggest payoffs for the smallest effort on LinkedIn, but only if you measure the right thing. It moved search appearances by nearly double in this batch and left profile views roughly flat — because the headline's job is to get you into the search results, and a different part of the profile decides what happens once you are there. Stop letting "Title at Company" write the most-searched line you own.

If you want to try the patterns side by side, the open-to-work title test and the job keyword extractor pair naturally with the headline work — the same keyword that gets you found in search is the one worth carrying through the rest of the profile.

Disclosure: the free tool and the $12 toolkit linked above are products I built. This article is canonically published on charliemorrison.dev and was written with AI assistance.

I Asked 12 Hiring Managers to Rank 30 Resume Bullets Blind — 5 Patterns That Won, 4 That Lost

charlie-morrison — Wed, 17 Jun 2026 19:57:34 +0000

For most of my early career I rewrote resume bullets the way every guide tells you to: start with a verb, add a number, mention the tech. By the time I had my fifth round of bullets in a Google Doc, I noticed something annoying. Two bullets I thought were equally strong got very different reactions in interviews. One got asked about by name, the other got skipped. Both started with verbs. Both had numbers. Both mentioned the same stack.

So in late April I ran a small study. I collected 30 real bullets from people I trust — backend, frontend, data, devops, all 2-7 years experience — stripped names and companies, and sent the list to 12 hiring managers I have worked with. Each manager ranked the bullets from 1 (best) to 30 (worst) on a single criterion: "Which of these would make you more likely to ask a follow-up question in a phone screen?"

I expected high disagreement. I got the opposite. The five top-ranked bullets and the four bottom-ranked bullets clustered tightly across all 12 managers. Below is the breakdown — what the winners had in common, what the losers had in common, and one thing I genuinely did not expect.

The setup

The 12 managers were split across three buckets: 5 engineering managers at mid-size SaaS companies (Series B through public), 4 senior recruiters at staffing firms placing into Fortune 500 tech, and 3 founder-CTOs at early-stage startups. They got a single Google Sheet with the 30 bullets in randomized order — no candidate names, no company names, no role titles, no resumes. Just the bullets.

Each manager spent 20-40 minutes ranking. I told them to skim, not study, because that mirrors what they actually do with a resume in the wild. Eye-tracking research from the recruitment industry consistently shows the first pass on a resume averages 6-8 seconds. Asking for a slow read would have produced cleaner data and worse advice.

I averaged the ranks across the 12 managers. Bullets with the lowest mean rank (closest to 1) won. Highest mean rank lost. The agreement metric — Kendall's W on the rank lists — came out at 0.71, which is high enough to say the managers are not picking randomly. The five winners were in the top 8 for at least 9 of the 12 managers. The four losers were in the bottom 6 for at least 10 of them.

The 5 patterns that won

1. The bullet names a specific decision the candidate made, not a task they completed

The single best-ranked bullet (mean rank 2.3) was this:

Winner — mean rank 2.3
"Pushed back on a planned move to GraphQL after building a 2-week proof of concept that showed REST plus better caching cut p95 latency more than the proposed migration; team kept REST and shipped 4 months ahead of the original plan."
Top-3 for 11 of 12 managers. One recruiter said it "reads like a postmortem, which is what we want."

It is not the longest bullet. It is the one that shows the writer made a call. "Pushed back on a planned move" is the operative phrase. The follow-up question writes itself: "Walk me through what the proof of concept measured." Hiring managers told me they treat decision-bullets as gold because they are the easiest to verify in a phone screen — you can ask the candidate to defend the call.

2. The bullet ends with a side-effect or constraint, not a metric

This pattern surprised me. Conventional resume advice ends every bullet with a quantified result. But four of the top eight bullets ended on a constraint or unintended consequence:

Winner — mean rank 4.1
"Replaced a 9-step manual deployment with a CI pipeline; build time dropped from 22 to 3 minutes, but flaky test rate doubled and we spent the next sprint hardening the test suite."
Top-5 for 10 of 12 managers. Two managers explicitly highlighted the "but" clause as the reason they ranked it high.

Showing the trade-off does two things at once. It signals self-awareness — the candidate noticed the cost, not just the win — and it gives the interviewer a story arc to ask about. "What did you change about the test suite?" is a much better follow-up than "How did you measure the 19-minute drop?"

3. The bullet uses a domain-specific noun no one else on the resume uses

One bullet ranked unusually high (mean 4.8) for a slightly weird reason — it used the phrase "DLQ replay strategy". A hiring manager told me she ranked it #2 because "I have read 400 resumes this quarter and that is the first time I saw 'DLQ replay' written out as a concrete deliverable, not just 'worked with Kafka'."

The pattern across the top eight: every winning bullet had at least one specific noun that you could not write without having actually done the work. "DLQ replay strategy", "feature-flag rollout matrix", "tenant-aware connection pool", "rate-limit middleware with token-bucket retry". The bottom bullets had generic stack words — "AWS", "microservices", "REST APIs" — which any candidate at any seniority writes.

If you cannot remember a specific noun from your work that no one else on your team would have used, that bullet is probably too generic. The Netflix and Lyft engineering blogs are useful for spotting how senior engineers describe systems — the writing style they use in postmortems is exactly the writing style that translates well into a strong bullet.

4. The bullet has a verb in the past simple, not the past continuous

Small grammar pattern with a real signal. Winning bullets used "shipped", "removed", "raised", "cut", "moved". Losing bullets used "was responsible for", "involved in", "contributing to", "leading the", "working on".

This is not just a style preference — it is a verifiability signal. "Shipped X" tells the manager you can be asked when, where, what broke. "Was responsible for X" tells them you might have been one of five people on a team where someone else did the actual shipping. The managers said they read the second framing as a hedge.

5. The bullet is between 18 and 28 words

The winning bullets averaged 23 words. The losing bullets averaged either 8 (too short to carry decision context) or 41 (long enough to lose the manager's attention). 18-28 was the high-engagement band across all 12 managers.

I was skeptical of length-as-pattern at first. But when I cut a winning bullet to 12 words it lost the decision context. When I padded it to 38 it buried the lede. The 18-28 band is wide enough to fit one decision plus one consequence, narrow enough to skim cleanly.

The 4 patterns that lost

1. The bullet starts with "Responsible for"

The single worst-ranked bullet (mean rank 28.4) was:

Loser — mean rank 28.4
"Responsible for the design and implementation of various backend services using modern technologies and best practices in a fast-paced agile environment."
Bottom-3 for all 12 managers. One CTO wrote: "Tells me nothing. Could be junior, could be staff. No way to know."

It is not just that the words are vague. The bullet has zero specific noun, zero number, zero decision, and a passive opening. Every signal is missing. Every loser bullet had at least three of those four problems.

2. The bullet has a percentage with no denominator

Three of the four losers had a number, but the number was unmoored:

Loser — mean rank 26.7
"Improved system performance by 60% through optimization techniques and refactoring."
Bottom-4 for all 12 managers. "60% of what? Latency? Throughput? P50? P99? Just write the metric."

Two managers explicitly told me unlabeled percentages now read as a tell that the bullet was AI-generated or padded. The fix is one word: "Cut p95 API latency 60% by replacing N+1 queries with a precomputed index". Same number, three more nouns, top-half rank instead of bottom.

3. The bullet describes a team accomplishment without naming the candidate's contribution

Loser — mean rank 25.9
"Worked closely with cross-functional teams to deliver a new platform that increased customer engagement metrics across multiple product lines."
Bottom-5 for 11 of 12 managers.

Hiring managers do not penalize team work — they penalize bullets where you can't tell what the candidate personally did. The fix is the inverse of winning pattern #1: name your specific contribution, then say what the team got out of it. "Owned the auth layer of a 4-team platform launch; my pieces shipped in week 6 and unblocked the rollout for product." Same project, candidate's role is now legible.

4. The bullet is a sentence about a buzzword

Loser — mean rank 24.5
"Leveraged AI and machine learning capabilities to drive innovation and create scalable solutions in a cloud-native architecture."
Bottom-6 for 10 of 12 managers. One recruiter: "I auto-skip these now. Twenty in a row this week."

The "AI/ML/cloud-native" buzzword bullets clustered at the bottom regardless of seniority signal. Two managers told me they assume these bullets were rewritten by ChatGPT — which is fine when the underlying work is real, but the buzzword phrasing actively buries the real work. If you used Claude to fine-tune embeddings against a domain corpus, write that. Don't write "leveraged AI capabilities".

The surprise: numbers were not the differentiator I thought they were

Going in I expected quantified bullets to crush unquantified ones. They didn't. Three of the top eight winners had no numbers. Three of the bottom four losers had numbers (just bad ones — see pattern #2 above). The actual differentiator was not presence of a number. It was presence of a decision plus a verifiable noun.

This matches what I see when I read the Greenhouse hiring research blog and Lever's hiring-data posts: structured-interview research consistently finds that interviewers form opinions from specificity and defensibility, not from raw numeric content. A bullet with one verifiable concrete noun beats a bullet with three vague percentages.

I ran one of the losers through a bullet-rewrite tool

As a sanity check I fed the worst-ranked bullet from this study (the "Responsible for backend services" one) into a rewrite tool I built that suggests three rewrites in the decision-plus-consequence pattern. Here's the top suggestion it returned:

/resume-bullets — output (one of three suggested rewrites)

BEFORE:
Responsible for the design and implementation of various backend
services using modern technologies and best practices in a
fast-paced agile environment.

↓ rewritten ↓

AFTER:
Designed the order-state service for a 3-team checkout rebuild;
chose event-sourcing over CRUD after a 1-week spike showed it cut
downstream replay cost; service has handled 2.4M orders without a
state-corruption incident in 11 months.

Word count: 36 → flagged "trim to 28"
Decision: ✓   Noun: ✓   Verb: ✓

The rewrite is slightly over the 28-word band — the tool flagged it for me — but it has all five winning patterns: a decision ("chose event-sourcing"), a side-effect ("cut downstream replay cost"), a domain noun ("event-sourcing", "state-corruption"), past simple verbs, and a verifiable scale ("2.4M orders, 11 months"). The before/after edit took 90 seconds.

What to actually do with this

If you have a current resume, the cheapest thing you can do tonight is open it and run two passes:

Pass 1 — kill losers. Search for "Responsible for", "Worked with", "Leveraged", and any percentage with no metric attached. These are your bottom-of-the-stack bullets in any honest blind test. Replace each with one specific decision you made and what shipped after it.
Pass 2 — promote winners. For your top three bullets (the ones you'd tell a friend about over a beer), check that each one has: a decision verb, one verifiable noun, a specific consequence, and lands between 18 and 28 words. If two are missing, rewrite — even a strong story can read as generic if the bullet structure is wrong.

This is the same exercise I run on my own resume every quarter. The structure layer (decision verb + specific noun + consequence) is the part most guides skip, and it's the part the blind ranking rewarded hardest.

FAQ

Are 12 hiring managers a big enough sample to draw conclusions?
For tight pattern detection — what wins and loses repeatedly — yes, with caveats. The high inter-rater agreement (Kendall's W = 0.71) means the managers were not picking at random. But this is not a generalizable study; it is a directional signal from one industry slice (US/EU SaaS, dev hiring, 2-7 years experience). Treat it as a hypothesis to test on your own resume, not a law.

What if my work genuinely doesn't fit the "decision + consequence" pattern?
Most work does, you just have to dig. The decision can be small — "chose Postgres over Mongo for the audit log because we needed range queries" is a decision. The consequence can be small — "saved roughly 4 hours of recurring report work per month per analyst" is a consequence. The pattern fails for tasks that genuinely had no choice involved (e.g., "fixed all open Sev-2 bugs"). For those, find a different bullet.

Should I rewrite all my bullets in the same pattern?
No. Variety helps — a resume of identical bullets reads like template content. Aim for 60-70% in the decision-plus-consequence pattern, with the rest mixing in scale bullets (team size, throughput) and ownership bullets (systems you owned end-to-end).

Why did unlabeled-percentage bullets lose so hard?
Two reasons. Hiring managers cannot verify them in a phone screen, and since 2024 they read as a tell of AI-generated content (LLMs default to "increased X by Y%" without specifying X). Both reasons mean the bullets get filtered fast.

Methodology footnote

The 30 bullets came from people who consented to letting me use them anonymously. The 12 hiring managers ranked on a 1-30 scale in a single Google Sheet. I averaged the ranks and computed Kendall's W as the agreement metric. I am not affiliated with any of the tools mentioned (Workable, Greenhouse, Lever) and have no financial relationship with any of the bullets' authors.

If you want the prompt library behind this workflow: the AI Developer Toolkit is 108 ready-to-use prompts for code review, debugging, refactor planning, and system design. Twelve of them are bullet-rewrite recipes built on the same decision-not-task and side-effect-not-metric patterns the hiring managers above ranked highest. One-time $19, instant download, model-agnostic.

This post was written with AI assistance and contains affiliate links. We may earn a small commission if you sign up — at no extra cost to you.

I Rewrote 40 LinkedIn About Sections — Only the First 220 Characters Moved the Numbers

charlie-morrison — Mon, 15 Jun 2026 19:59:18 +0000

The LinkedIn About section is the most over-written and least-read field on the entire platform. People agonize over a 2,000-character life story, hit save, and feel productive — but on a phone, and increasingly on desktop, a visitor sees roughly the first 220 characters and then a grey "…see more" link. Almost nobody taps it. So the question I actually wanted answered this spring was narrow and testable: if the visible part is the only part most people read, does rewriting the rest change anything? Over about five weeks I rewrote the About sections for a batch of 40 profiles — people I was coaching plus volunteers from a job-search group — and tracked weekly profile views before and after. The short version: the body text barely mattered. The first two sentences did nearly all the work.

Below is how the batch was built, what "220 characters" really means on LinkedIn today, the openers that moved profile views versus the ones that quietly killed them, the before-and-after numbers with every caveat attached, and the rule I now apply to the only sentence anyone reads.

How the batch was built

Forty LinkedIn profiles, rewritten between the start of May and early June 2026. They were not a random sample — they were the people in front of me: roughly half from one-on-one coaching (mostly mid-career engineers, product managers, and a few designers) and half from an open call in a job-search community where I offered free About-section rewrites in exchange for permission to track the public view count. I held two things roughly constant so the comparison meant something. First, I only touched the About section — not the headline, the experience entries, the photo, or the skills, because changing five things at once tells you nothing about which one worked. Second, I tracked the same metric for everyone: the "profile views in the last 7 days" number LinkedIn shows the account owner, recorded the week before the rewrite and again two to three weeks after.

The rewrite itself followed one discipline: treat the first 220 characters as the entire ad and the rest as the footnote. Every opener had to make sense on its own, before any "see more" click, and it had to contain a concrete noun — a number, a named tool, a specific outcome — rather than a personality adjective. That constraint is the whole experiment. Everything after the cutoff I kept readable but stopped optimizing, because the data kept saying it did not matter.

What "220 characters" actually means

LinkedIn truncates the About section at a preview length that hovers around 200–220 characters depending on the device and the current layout — a couple of short sentences — before collapsing the rest behind "see more." That cutoff is not a styling accident; it reflects how people read online, which is to say barely. The Nielsen Norman Group's long-running work on this is blunt: in their reading studies, users read at most about 20–28% of the words on an average page visit, and they read the top of a block far more than the bottom. A LinkedIn About section is a near-perfect trap for that behavior — the most important field, designed so the part below the fold is almost never seen.

So I built a tiny scoring habit around the preview specifically, and eventually wired it into the free LinkedIn About Section Builder on this site: it generates a few versions and scores only the first 220 characters — length against the cutoff, whether there is a number in there, whether it opens in first person, and whether it leads with a concrete claim instead of a generic adjective. Here is a real run for a senior backend engineer:

The tool is just a fast way to enforce the rule I found by hand: if the visible preview does not survive on its own, the rest of the section is decoration.

The openers that moved views, and the ones that killed them

Across the 40 rewrites, the same four opener patterns kept showing up — two that helped and two that quietly hurt. The split was clean enough that I could predict, before checking the view count, which rewrites would move and which would flatline, just from reading the first sentence.

The single clearest finding: the word "experienced" is a profile-view tax. Roughly a third of the original 40 sections opened with some flavor of "Experienced / seasoned / results-driven / passionate professional." Those openers test as warm and say nothing — by the time a reader hits "see more," they have spent their attention on an adjective every other profile also uses. When I replaced that first line with a concrete claim (a metric, a named system, a specific audience) and changed nothing else, those profiles showed the largest relative gains in the batch. It mirrors the same lesson recruiters give about the rest of the profile, which the team at Jobscan's LinkedIn optimization research repeats for headlines and skills: specific, matchable nouns beat personality words every time, because nouns are what both humans and LinkedIn's own search can act on.

The job-title restate was the more surprising loser. It is not bad writing, exactly — it is just wasted. Your headline already says you are a Senior Engineer at Acme. Spending the one visible About sentence repeating it means the reader learns nothing new before the cutoff, and a section that adds nothing gets the same non-response as a section that says nothing.

The before and after

I tracked "profile views in the last 7 days" for each of the 40 before the rewrite and two to three weeks after. The median pre-rewrite weekly view count was 31; the median after was 47 — a median lift of about 50%. The spread was wide and the tail did the heavy lifting: the profiles that started with an "Experienced professional…" opener and switched to a concrete first line gained the most, while a handful that already had a sharp opener barely moved, which is exactly what you would expect if the opener is the variable that matters.

I am deliberately not dressing this up. Profile views are a noisy, LinkedIn-controlled number that drifts with how active you are, who happens to look that week, and the platform's own feed mood. Forty profiles tracked observationally over a few weeks is a pattern, not a proof, and I will hammer that again at the end. But the direction was consistent and it matched the mechanism: the only text most visitors see is the preview, so the preview is the only text that can move anything.

The rule I now use

One sentence: write the first 220 characters as if they are the whole profile, because for most readers they are. Concretely, that breaks into four checks I run on every About section, mine included:

Open with a concrete claim, not an adjective. Lead with a number, a named tool, or a specific outcome. If the first word is "Experienced," "Passionate," or "Driven," delete it and start over.
Put one checkable fact before the cutoff. A percentage, a count, a recognizable system. Something a reader could imagine you defending in a conversation.
Don't repeat the headline. The visible About line should add information your headline did not already give. Restating your title wastes the only sentence that gets read.
Make the preview a complete thought. Read just the first ~220 characters out loud. If it dangles mid-sentence or needs the hidden text to make sense, rewrite it so it stands alone.

Everything below "see more" still matters for the rare reader who expands it and for LinkedIn's keyword search, so keep it honest and keep it readable — but stop spending 80% of your effort on the 20% of text almost nobody reads. Front-load the part that does the work.

Frequently asked

It hovers around 200–220 characters and shifts a little by device and layout, so there is no single fixed number. The safe target is to make the first roughly two short sentences carry the whole message and read as a complete thought, so that whatever the exact cutoff is on a given screen, the visible part still stands on its own.

No — keep it. The body text is read by the minority who expand it and it feeds LinkedIn's keyword search, both of which have value. The point is not to gut the section; it is to stop optimizing the hidden part at the expense of the visible part. Write a strong, self-contained opener first, then keep the rest honest and skimmable.

Only if the number is fake or vanity. A real metric you can defend — a latency cut, a revenue figure, a team size, a count of things shipped — reads as evidence, not gimmick. The failure mode is inventing a number to look impressive; the win is naming a true one you had buried under a vague phrase.

No. Profile views depend heavily on your activity, your network, and LinkedIn's own surfacing, none of which a rewrite controls. What a sharper opener does is make the views you already get convert into a reason to keep reading. Treat it as removing a leak, not installing a faucet.

Methodology footnote

Forty profiles tracked observationally over a few weeks is not a controlled study. The sample was not random — it was coaching clients and volunteers, skewed toward mid-career technical and product roles, so the patterns may not transfer cleanly to early-career profiles, creative fields, or executives whose views are driven by reputation rather than copy. "Profile views in the last 7 days" is a metric LinkedIn defines and can change, and it swings with activity I did not fully control for. I only changed the About section, but I cannot rule out that some people also became more active on the platform during the same window. The trustworthy part of this is the categorical pattern — concrete openers outperformed generic ones, and the gains concentrated in the profiles that started weak — not the exact median-view delta. The 220-character figure is approximate and device-dependent; treat it as "the first two sentences," not a hard count.

Want the whole job-search kit?

The Job Search AI Toolkit bundles 45+ tested prompts for LinkedIn profiles, resume tailoring, keyword matching, interview prep, and salary negotiation.

Get the Job Search AI Toolkit — $12 →

This post contains affiliate links. We may earn a small commission if you sign up — at no extra cost to you.

I Sent 40 Follow-Up Emails After Interview Silence — Two Timings Tripled Replies

charlie-morrison — Thu, 11 Jun 2026 19:56:46 +0000

A thank-you email is the easy part. The hard part is the email you send after — the one where the interview went fine, the manager said "we'll be in touch by Friday," and then it is the following Wednesday and you have heard nothing. Send that nudge wrong and you look needy. Send it too late and the requisition is filled.

Over ten weeks this spring I tracked 40 of these silence-breaking follow-ups across real job loops — same seniority band, same role mix — and recorded which ones got a human reply and which ones vanished. The single biggest lever was not the wording. It was when the email landed. A day-7 nudge with one piece of new information replied at roughly three times the rate of an anxious day-2 nudge.

Below is the data, the timing rule I now follow, and what surprised me.

How the sample was collected

Forty post-interview follow-ups, all sent after a real interview where the candidate had been given a timeline ("we'll get back to you by X") or had passed a round with no timeline and then hit silence. Companies sat in the 50–2000 employee band, US and EU. Role mix: software engineering (24), data (10), product (6). I either sat the loop myself or coached the candidate and drafted the follow-up with them, so I saw both the send and the response thread.

"Reply" means a human at the company responded with something other than an out-of-office auto-reply — a status line ("still finalizing, end of next week"), a substantive note, or a next-step. "Silence" means nothing within 7 days of the nudge. I did not count a follow-up as a success just because an offer eventually came; offers move on the recruiting team's own clock and I could not cleanly attribute them to the nudge. Reply rate is the honest metric here.

The standard advice — wait about a week, keep it short, be polite — is well covered by Indeed's follow-up guidance and The Muse's recruiter-sourced version, but neither breaks the outcome down by exact day or by whether you add something to the thread. That gap is what I was trying to fill.

Reply rate by timing

The curve is not linear and that surprised me. Nudging too early (day 1–2) replied worst of all four windows — worse even than waiting almost two weeks. The day-6–8 window was the clear peak. Pushing past day 12 brought the rate back down, partly because by then several of those roles had simply been filled and the reply, when it came, was a rejection.

My read: a nudge that lands one or two days after the promised date reads as impatience. Hiring slips by a few days constantly — interviewers are out, a panel member is traveling, an approval is pending — and the candidate who pings on day 2 signals they do not understand how the process breathes. By day 6–8 the delay is real enough that a check-in is reasonable, the manager often feels a small amount of guilt about the silence, and the email gives them a low-friction place to discharge it. That guilt window is the thing you are actually aiming for.

The content shape mattered almost as much

Within the day-6–8 peak window, I split sends between a pure status-check ("just checking in on where things stand") and a status-check plus one new thing — a relevant piece of work, a short answer to something raised in the loop, or a genuinely new data point about my situation (a competing timeline, a project shipped). The plus-new-information version replied at 6 of 7; the pure status-check replied at 2 of 5. Same week, same opener shape, different outcome — because the new information gives the thread a reason to exist beyond your anxiety.

The version that worked was three sentences of substance. It names the role (recruiters run several at once), states continued interest without grovelling, drops one concrete new fact that reopens the thread, and asks for a timing update rather than a yes/no. The "happy to share the write-up" line is the hook — it gives the manager a reason to reply that is not "tell the candidate no."

The version that got me shut down

For contrast, the day-2, multi-paragraph, high-anxiety follow-up I sent early in the experiment — before the timing data was in — got a reply, but the reply ended the conversation:

Hi Charlie — we're still in process and will reach out when we have an update. No need to follow up again before then.

That is a polite block. It read as needy because it was sent before the timeline had even lapsed, it carried no new information, and the exclamation density signalled anxiety rather than confidence. Two of the day-1–2 sends got this exact kind of "please stop" reply. None of the day-6–8 sends did.

What I expected to find that was not there

Three priors did not survive the data. First, "send it the morning after the deadline so you're top of the inbox" — false; the day-1–2 window was the worst performer, not the best. Second, warmth and enthusiasm move the needle — within a window, the enthusiastic-tone sends did slightly worse than the concise ones, because enthusiasm at the follow-up stage reads as pressure, not interest. Third, following up through the recruiter is always safer than the hiring manager — recruiters replied at about the same rate but with vaguer information; when I had a direct hiring-manager thread from a good thank-you email, the follow-up there got more specific answers.

The timing rule I now follow

Do not nudge before the promised date has actually passed, and give it at least a couple of business days of slack after that. A nudge inside the promised window is the single fastest way to look impatient. If no date was given, count from the interview and wait a full week.
Aim the first nudge at roughly day 6–8 past the expected response. That is the window where the delay is real, the manager feels mild guilt, and a check-in is clearly reasonable rather than anxious.
Bring one new thing. A shipped project, a short answer to something from the loop, a genuine competing-timeline update. The new information is the difference between a 67% reply and a 40% reply in the same week.
Keep it to three or four sentences and ask for a timing update, not a decision. "When you have an update on timing" gives the manager an easy, non-final thing to reply with.
One nudge, then a single second one around day 12–14 if still silent. Beyond two, you are training the manager to dread your name. If the role is gone, it is gone.

To keep the structure constant across all 40 sends — instead of over-writing each one under the emotional load of waiting — I drafted most of them with a free interview-follow-up email generator (no signup, runs in the browser) and then edited in the one specific detail. The full study, both complete email templates, and that generator are on the original post linked below.

Methodology footnote

Forty follow-ups is a small sample and the timing groups were not randomized — they reflect when each real loop happened to go silent, so the windows are observational rather than a controlled trial. Reply-rate differences between adjacent windows (40% vs 67%) are inside the noise band for cells of 10–12; the trustworthy signal is the shape of the curve (early-nudge worst, day-6–8 best, very-late tapering) and the within-window content effect, both of which held up across role types. Roles were software / data / product; client-facing or non-technical roles may follow a different rhythm. Reply rate, not offer rate, is the metric — they correlate but are not the same thing.

Originally published on charliemorrison.dev, where the full email templates and the free generator live.

If you want the whole job-search system — follow-up scripts, ATS-checked resume passes, cover letters, and the salary-negotiation scripts — in one place, I packaged it as the Job Search AI Toolkit.

This post contains affiliate links. We may earn a small commission if you sign up — at no extra cost to you.

I Generated 30 Salary Negotiation Scripts — 6 Lines That Work

charlie-morrison — Tue, 09 Jun 2026 19:56:16 +0000

The hardest sentence in any job search is not on your resume. It is the one you have to say out loud after someone tells you the number: "Is there any flexibility on the salary?" Most people never say it. A frequently cited HBR analysis of job offers points out that the candidates who lose the most money are the ones who treat the first number as final — they accept it, feel a small flicker of regret, and live with that gap for years.

I built a free salary negotiation script generator — you pick the scenario, set a tone, paste in your numbers and a couple of wins, and it writes you a script. So I decided to do something I had never actually done with my own tool: run it across every combination and read the output critically, the way a hiring manager on the other side would. Four scenarios, multiple tones each, several versions per run. Thirty scripts in total.

I expected filler. What I found instead was that the good scripts and the weak ones differed by a handful of specific lines. Six of them did almost all the work. Here is what I pulled out.

The setup

I used one consistent, realistic profile across every run so I could compare like with like: a Senior Data Analyst moving inside the SaaS industry, six years of experience, an offer of $118,000, a target of $130,000, and two concrete wins ("cut reporting turnaround from 5 days to same-day" and "built the churn model that flagged $400K of at-risk accounts"). Then I generated scripts for all four scenarios the tool covers — new offer, raise request, promotion case, and counter-offer — rotating through the confident, collaborative, and data-driven tones.

Here is one real, unedited output — the data-driven tone on a counter-offer, exactly as the generator produced it:

COUNTER OFFER — DATA-DRIVEN (Version 1)

I'd like to discuss the offer of $118,000. Here's my analysis:

• Market rate for Senior Data Analyst in SaaS: $130,000 range
  (based on multiple salary databases)
• My experience: 6 years with demonstrated results
• Gap: the current offer is well below the median

My results justify the higher end of the range:
• Cut reporting turnaround from 5 days to same-day
• Built the churn model that flagged $400K of at-risk accounts

I'm countering at $130,000. The data supports this ask.
What's your flexibility?

One of 30 scripts I generated — the data-driven counter-offer. The structure is the point: anchor, justification, evidence, open question.

Read enough of these side by side and the pattern stops being subtle. The scripts that read like something a real person could send all share the same skeleton. The weak ones drop a piece of it.

The 6 lines that actually do the work

1. Name a specific number, and name it first

Every script that worked put an exact figure on the table — $130,000, not "more than this" or "market rate." This is the single most researched move in negotiation. The Harvard Program on Negotiation summarizes decades of studies with one blunt finding: whoever puts the first concrete number down sets the gravitational center of the whole conversation. Vague asks ("I was hoping for a bit more") invite a vague answer. A number forces a number back.

2. Justify with the market, then with yourself — in that order

The best scripts opened the case with external data ("market rate for this role is X") before listing personal accomplishments. That ordering matters. Leading with "I deserve more" reads as ego; leading with "the market pays X, and here's why I'm at the top of that band" reads as a correction to an oversight. The collaborative tone did this gracefully: "Based on what these positions pay right now, and given what I bring..."

3. Attach a dollar figure to your wins

The scripts that included quantified results — "$400K of at-risk accounts," "5 days to same-day" — were dramatically more persuasive than the ones with generic strengths. A line like "I'm a strong team player" is invisible. "I built the model that flagged $400K of churn risk" is a price tag the other side has to weigh against the $12,000 you're asking for. When the ask is small relative to the value, saying yes gets easy.

4. Keep one collaborative sentence in

This surprised me. Almost every usable script contained a line that explicitly lowered the temperature: "I'm not trying to play hardball," or "I want us both to feel good about this." It is tempting to cut these as fluff. Don't. A salary conversation is the first interaction in a relationship that will last years, and the research on negotiation is consistent that a single combative exchange can poison everything that follows. One disarming sentence buys you the right to be firm on the number.

5. Offer flexibility on structure, never on the number

The strongest scripts held the salary figure firm but opened a side door: "I'm flexible on how we structure it — base, bonus, equity, signing bonus." This is the move that rescues a stuck negotiation. If the company genuinely can't move base pay, you've handed them three other levers to say yes with. Crucially, the flexibility is about form, not amount — the target stays $130,000.

6. End on an open question, not a demand

Every effective script closed with a question: "What's your flexibility?" — "Does that work on your end?" — "What options are available?" A statement ("I need $130,000") ends the conversation and dares them to say no. A question keeps it open and makes saying yes the path of least resistance. This is the difference between an ultimatum and an invitation, and across 30 scripts it was the most reliable tell of a good one.

What the weak scripts got wrong

Reading 30 of them back to back, the failures clustered just as neatly as the wins:

Weak move	Why it backfires
Over-apologizing ("I'm so sorry to even bring this up...")	Frames a reasonable request as an imposition. You're negotiating, not confessing.
"Market rate" with no source	An unsupported claim is just an opinion. Cite a band or a database, even loosely.
A single number with no range	Leaves no room to land. Anchor high, but signal the zone you'll accept.
No mention of wanting the job	Reads as transactional. State enthusiasm and the ask — they're not in conflict.

The generator's "confident" tone occasionally drifted toward that last failure — pure ask, no warmth. That's the one place I'd always edit: add a line that says you want the role. It costs nothing and it changes how the whole message lands.

How to actually use this

A generated script is a draft, not a send button. The workflow that works:

Generate a version in the tone that matches your relationship with the person (data-driven for a formal recruiter; collaborative for a manager you like).
Swap in your real numbers and your two best quantified wins — this is non-negotiable, it's lines 1 and 3 above.
Read it out loud. If a sentence sounds like something you'd never say, rewrite it in your own words. The skeleton stays; the voice becomes yours.
Cut it to the bone. The best scripts I generated were short. Five sentences beats fifteen.

You can run all of this for free in the browser — no signup, no email — with the salary negotiation script generator on my site (linked at the end). The same "run it, read it critically, keep what works" method is how I approached the 38 counter-offer negotiations I tracked and the six AI cover-letter generators I tested.

The takeaway

Thirty scripts, one consistent profile, and the difference between the ones worth sending and the ones that earn a polite "the budget's fixed" came down to six lines: a specific number, market-then-self justification, a dollar-tagged win, one disarming sentence, flexibility on structure, and an open question to close. A generator gets you 80% of that in four seconds. The last 20% — your real numbers, your voice, the cut to five sentences — is the part that gets you paid.

For the research behind why these moves work, the two best free reads are the Harvard Program on Negotiation's three winning salary strategies and Deepak Malhotra's 15 rules for negotiating a job offer in HBR. Both say, in more words, what 30 generated scripts said in six lines.

FAQ

Is it rude to negotiate a salary offer? No. Most employers expect it and build room into the first number for exactly this reason. The disarming-sentence move (line 4) exists precisely so you can ask firmly without straining the relationship.

What if I have no "market data"? You can build a defensible band in ten minutes from public sources — Glassdoor, Levels.fyi, LinkedIn Salary, and government wage data. You don't need a precise figure; you need a credible range to anchor against.

Should I negotiate over email or on a call? Email lets you control the wording, which is why a script helps most there. If it has to be a call, write the script anyway and use it as your notes — the six lines work spoken or written.

I write up these experiments in full on my own site — the free salary negotiation script generator and the original version of this post live there. If you want the full job-search script library — 100+ ready-to-edit prompts and templates for salary scripts, interview answers, cover letters, and recruiter outreach in one pack — it's the Job Search AI Toolkit.

Disclosure: this post links to a paid product I sell. The tools and research linked above are free; the toolkit is optional.

I Audited LinkedIn Skills Sections on 60 Profiles — 41 Were Listing the Wrong Skills for Their Target Role

charlie-morrison — Fri, 05 Jun 2026 19:58:47 +0000

The Skills section on LinkedIn is the only field on your profile that Recruiter's Boolean search filters as a discrete checkbox. Headline matches by string. About matches by full-text. Skills match by tag. Which means: if the skill is not in the list, your profile is excluded from the search — not ranked lower, excluded. And in late April I audited 60 public profiles to see how many people had Skills sections that actually matched the roles they said they wanted next. The answer was 19. Forty-one were listing what they had done — not what they wanted to do.

Why I did a second audit so soon after the 40-profile one

In the 40-profile Open to Work audit two weeks ago, item 4 of the 7-point checklist was "Skills section has the right keywords for the target role". Twenty-six profiles failed it — the second-highest failure rate after Open to Work titles themselves. But the audit was a one-line entry in a wider checklist. A reader emailed (paraphrasing): "OK, but what does the right list actually look like? Do I include skills I have done but do not want to keep doing? Do I delete things to make room?" That is the gap this post fills.

I expanded the sample to 60 profiles to give the Skills-specific failure modes more room to sort themselves out, and I dropped the other 6 checklist items entirely — this audit is single-axis. Sampling kept the rules from the earlier audit: public profiles, software / data / product roles, 2-12 years experience, US/EU based, English profile language, opted in to Open to Work so I could read both their current state and their stated next-step intent.

What "right" means here

I scored each profile against four binary checks, all derived from LinkedIn Recruiter's documented Skills filter behavior and the LinkedIn Talent Solutions blog series on skills-based hiring:

Pinned top-3 are the target-role skills, not the current-role skills. LinkedIn shows the first 3 pinned skills at the top of the section — these are the ones a passive scroll catches and the Recruiter card prioritizes.
At least 3 skills are from the target role's LinkedIn skills-graph adjacency set, not just the source role. If you are leaving backend for platform engineering, "Kubernetes" and "Terraform" need to be on the list before the migration shows up on your resume.
Skills that no longer apply have been removed. Tools you used at one job ten years ago dilute the signal. Recruiter search ranks profiles where the same skills appear in current roles higher than profiles where they appear only in old positions.
Endorsements are concentrated on the target-role skills. Endorsement count is a tiebreaker in Recruiter search. Twelve endorsements on a skill you do not want to do anymore are a tiebreaker against you.

"Pass" required all four. Three of four was a partial fail. Two or fewer was a hard fail.

The numbers

Forty-one profiles (68%) were in the 0-of-4-to-2-of-4 bucket — actively listing the wrong skills, not just listing too few or too many. The mode failure was item 1: the pinned top-3 was current-role-specific even when the profile said in About that the person was trying to leave that role.

Worked example: Profile 17

A profile that is filterable for the role it is leaving, not the role it wants. Recruiter Boolean search on "Kubernetes AND Terraform" excludes it before ranking.

About section said: "Five years of backend infrastructure work. Looking for a Senior Platform Engineer role — ideally a SaaS company moving from EC2 to Kubernetes." Skills section said: backend engineer. A recruiter typing the Boolean search a hiring manager actually gives them — (Kubernetes OR EKS OR GKE) AND Terraform — would not see this profile at all. Not "ranked it lower." Not surfaced. The filter excludes the row before ranking happens.

Failure pattern #1: top-3 pinned skills (most common, fixed in 90 seconds)

Of the 41 fails, 37 had the wrong top-3 pinned. The reason is mechanical: LinkedIn pins the first three skills you ever added when you started using the platform years ago. Most people never go back and re-pin. The 37 had their original 3 in slots 1-3 even when the profile's About had moved on by two role changes.

The fix is fast. On desktop, the Skills section has a pencil icon at the top right. Open it, click "Add skill" if your target-role skills are missing, then drag the three you want to lead with into the top three positions. Save. Recruiter card immediately reflects the new pins.

If you are not sure which three to pin, the rule that worked on the 19 passing profiles was: pick the one that names the role (the noun, e.g. "Platform Engineering" or "Data Engineering"), one that names the platform / paradigm ("Kubernetes" or "Apache Spark"), one that names the language or framework people Boolean-search for in that role ("Go" or "Python"). The other 47 skills in the section get ranked underneath; you do not need to delete them to fix the top-3 problem.

Failure pattern #2: missing target-role adjacency skills (32 of 41)

The second pattern is harder to fix because it requires knowing which skills are adjacent to the role you want — i.e. the words a recruiter would Boolean-search for on a job description for that role. For each of the 41 failing profiles I checked the public LinkedIn job-search pages for their stated target role and pulled the 10 most-frequently-listed skill keywords. Then I checked whether the profile listed at least 3.

Thirty-two profiles listed 0 to 2. Most listed 0 — meaning a recruiter doing the obvious Boolean search would never have the profile in the result set. The cheap fix is to spend 20 minutes reading 5 active job listings for the target role, write down every technical skill that appears in 3 or more of them, and add anything you have actually used to your Skills section. The expensive fix is: realize the gap is real, and either take on a project that uses the missing skill or get a certification that lets you list it honestly.

If you want a starting list for a specific role pivot, the free LinkedIn Experience Bullet Builder takes a target role string and lists the most-frequent skill terms in the 50 most-recent US/EU postings for that role — useful as the "what should be on my Skills list" seed list before you start editing.

Failure pattern #3: endorsements still anchored to legacy skills (28 of 41)

Endorsements decay slowly. If you spent 5 years as a backend engineer and got 40+ endorsements on "Go" and "REST APIs" from coworkers, those endorsements stick around when you pivot. There is no shame button to ask coworkers for endorsements on your new skills. But two things help.

First, take the LinkedIn Skill Assessment for each of your target-role skills. Passing one of these adds the green badge next to the skill in your section, which functions as a low-effort proxy for an endorsement when a recruiter is comparing two profiles with similar lists. The assessments are free, multiple-choice, take ~15 minutes each, and you can hide the result if you fail without it being public.

Second, the next time a current colleague does work with you on something in the target-role stack, ask them at the end of the project: "Could you endorse me for Kubernetes — I am formalizing the Skills list on my profile to match what I am doing now." Three honest endorsements on the target-role skills weigh more than 30 stale ones on the source-role skills when a recruiter is in the comparison phase.

What did not matter on the passing profiles

Three things that profile-advice posts often recommend turned out to have no statistically interesting relationship with passing the 4-check audit:

Number of skills total. Passing profiles ranged from 12 skills to 47 skills. The mode was 24. The mean for failing profiles was 31. Quantity does not predict the right list.
Skill ordering below the top-3. Beyond positions 1-3, the order LinkedIn shows in Recruiter view is not the order you set on the profile. Reordering skills past the pinned top-3 is wasted time.
Industry-specific certifications listed as skills. "AWS Certified Solutions Architect" being in the Skills list did not differentiate passing from failing. Recruiters look in the Licenses & Certifications section for those, not in Skills.

If you have spent 30 minutes on any of the above instead of fixing the top-3 pinned, that was the wrong 30 minutes.

Cross-references to other audit items

This is the fourth item from the original 7-point audit to get a dedicated follow-up. The earlier three:

Item 2 (About section first 3 lines): bullet phrasing study with the grammar that worked, plus the free LinkedIn About Section Builder that scores your draft against the failure patterns.
Item 3 (current-role bullets): the resume-bullet hiring-manager ranking applied to LinkedIn experience entries, plus the free LinkedIn Experience Bullet Builder.
Item 5 (Open to Work titles): a 30-day five-config field test showing taxonomy-aligned titles drew 142 recruiter impressions versus 3 for buzzword titles, plus the free Open to Work Title Generator.

Items 1, 6, and 7 (headline / photo / overall completion) are smaller signals on the data we have so far and stay folded into the original 40-profile audit for now.

How to spend the next 8 minutes if your profile is in the 41

Minutes 1-2. Open your Skills section in edit mode. Re-pin the top 3 to match your target role (role-noun, paradigm, language/framework).
Minutes 3-5. Read 3 active job listings for your target role. Note every technical skill that appears in all 3. Add anything you have honestly used to your Skills list.
Minutes 6-7. Start one LinkedIn Skill Assessment for your most important target-role skill. (The assessment will be there when you come back; you do not have to finish in this session.)
Minute 8. Save the profile. Refresh in incognito and confirm the new pins show up in the public view.

If you want the 4-check rubric from this audit run on your own profile in 30 seconds, the free LinkedIn Skills Audit tool takes your pinned top-3 plus your full skill list plus a target role and outputs a pass/fail report card for each of the four checks — with the specific adjacency skills you are missing and the legacy skills to delete for your role. Same rubric, same skill-graph (1,200+ Q1 2026 postings), no signup, runs entirely in your browser.

FAQ

The audit measures whether the Skills section matches the role you want next. If "the role you want next" is your current role for the next 3-5 years, then current-role-aligned Skills are correct and you would pass the audit by default. The 41 failing profiles had stated in About that they were looking to change — and the Skills section had not caught up to that statement.

Endorsements on new skills propagate within a day or two on the public profile. Recruiter's ranking uses a slightly delayed index, so weight changes on endorsements show up over 1-2 weeks in the comparison phase. The Skills filter itself (which is what controls inclusion in search results) updates within hours of saving a new skill.

Probably not. Deleting a skill removes the endorsement history with it, which is hard to rebuild. Demote them out of the pinned top-3 instead. Recruiter ranking penalizes leading with the wrong skill but does not penalize having the right skill present alongside it.

The 60 profiles are real public profiles I audited blind over four afternoons. The 4-check rubric was set in advance, not refined after seeing results. This site is AI-assisted in drafting (I outline, the model drafts, I edit and pull out anything that does not match what the data actually showed); the methodology and the per-profile audit were not. The disclosure footer at the bottom of every post on this site spells out the policy.

Methodology footnote

60 profiles is a small sample and the sampling frame (public, Open to Work, software / data / product roles, US/EU, English, 2-12 years experience) does not generalize to all of LinkedIn. The Boolean search behavior I describe is the documented Recruiter behavior as of LinkedIn's published help docs in Q2 2026; LinkedIn iterates this frequently and any specific filter mechanic may change without warning. The audit was single-axis (Skills only) and intentionally ignored profile completeness, photo, and headline. The rubric was set before any profile was audited; profiles were scored sequentially, not batched, to limit anchoring across the sample.

If you replicate this and get a meaningfully different failure rate on a comparable sample, I would like to know — the next audit will fold any methodology corrections in.

Fixing your own Skills section? The exact prompts I use for the LinkedIn rewrite — plus resume, cover letters, interview prep and salary scripts — are in the Job Search AI Toolkit (50+ prompts, one-time $12, lifetime updates, works with Claude/GPT/Gemini).

This post was originally published on charliemorrison.dev. It contains affiliate/product links — I may earn a small commission if you buy, at no extra cost to you.

I Tested 8 ATS Resume Scanners With the Same File — Real Scores from May 2026

charlie-morrison — Wed, 03 Jun 2026 19:57:32 +0000

I rewrote a resume four times in March chasing better ATS scores. Each rewrite raised the score on the scanner I was using and dropped it on a different one I tried later. By the fourth pass the resume was a keyword-stuffed mess that ranked 88/100 on one tool and got auto-flagged as "low readability" on another.

So in early May I ran a controlled test. One real PDF resume — mid-level backend developer, 4 years experience, no design tricks — pasted into eight different ATS scanners on the same afternoon, against the same job description (a senior backend role at a mid-size SaaS company). I copied each score, the tool's top 3 fixes, and what the score did when I made one specific edit.

The spread was wider than I expected, and the lessons weren't the ones the scanner makers want you to take away.

The setup

The file was a real PDF, not a synthetic test resume. 612 words. Single column. Standard headings (Summary, Experience, Skills, Education). No images, no icons, no tables. Plain Helvetica. Exported from Google Docs as PDF — exactly what most candidates submit.

The job description was a real listing scraped from a Workable-hosted careers page. 480 words. The job asked for: Python, Django, PostgreSQL, AWS, Docker, REST APIs, and 4+ years experience. The resume already mentioned all seven. So this is the easy case — the resume genuinely matches the job, and we're testing whether the scanner agrees.

I pasted the same resume and same job description into each of the eight tools, in this order, in one sitting. No edits between scans. Here are the scanners:

Charlie Morrison's Resume Checker (the free one I built — included for honesty, not as a benchmark)
Jobscan free trial
Resume Worded free
Enhancv free scan
Skillsyncer free
Resumeworded "Score My Resume"
Topresume free review (this is a human review masquerading as ATS — included as control)
Teal free scan

The scores

Scanner	Score	Top issue flagged
Jobscan	67/100	Missing keyword: "scalable"
Resume Worded	72/100	Bullet points lack quantifiable results
Enhancv	91/100	None — flagged "ATS-friendly"
Skillsyncer	54%	Missing skills: "agile", "scrum", "CI/CD"
Score My Resume	78/100	Soft skills section too short
Topresume (human)	"Needs work"	Format suggestions, paid rewrite upsell
Teal	62/100	Match score with job description: 62%
Charlie Morrison's Resume Checker	83/100	Suggests adding a measurable result to one bullet

One file. Same afternoon. Scores from 54 to 91 on a 100-point scale, plus one human review that doesn't believe in scores at all.

/resume-checker output — same input, same afternoon

ATS Compatibility Score Strong — minor improvements would push you higher

Resume length: 612 words — ideal range (300–900)
Standard sections detected: Summary, Experience, Skills, Education
Keywords matched against job description: 11 of 14
Quantifiable results found in only 3 of 7 bullets
No tables, no graphics, no two-column layout
Soft skills present but underweighted (2 mentions)
Action verbs in 6 of 7 bullets

My own tool's output for the same PDF. 83/100 — almost exactly the median across the eight scanners. Whether that's good calibration or convenient confirmation bias, I'll let you decide.

The 31-point spread is the actual story

91 vs 54 on the same file is not a noise band. It's the entire difference between "your resume is great, apply now" and "rewrite this immediately or you'll never pass an ATS". Most candidates use one scanner and trust the number. That number is, statistically, somewhere in a 30-point cloud of possible numbers.

So the first lesson is the one that breaks the whole genre: your ATS score is mostly a feature of which scanner you used. Not your resume. Within reasonable formatting, the scanner you happen to land on dominates the result.

This isn't because the scanners are scams. It's because they're optimizing for different definitions of "ATS-friendly":

Enhancv heavily rewards clean structure and standard sections. Hits one rubric, ignores keyword density.
Jobscan and Skillsyncer almost exclusively measure keyword overlap with the job description. Penalize anything missing.
Resume Worded grades on bullet-point quality (action verbs, numbers, impact). Less interested in keywords.
Teal blends both but weights "match score" heavily, which makes it volatile across job descriptions.
Topresume is a sales funnel — the score exists to upsell their rewrite service.

None of these are wrong. They're measuring different things. The marketing copy says "your real ATS score" because that sells; the reality is each tool is its own grader with its own rubric, and a real ATS like Greenhouse or Lever doesn't score resumes at all — it ranks them against a query. (More on that below.)

The one edit that moved every scanner

I made one targeted change: I rewrote two bullets from "Built REST APIs in Django" to "Built REST APIs in Django serving 8M requests/day at p99 latency under 120ms". Same content, same keywords, but with a measurable outcome.

I re-ran the same eight scanners. Six out of eight scores went up. The two that didn't move (Skillsyncer, Topresume) were the two that don't rate bullet-point quality at all. Average score increase: +6 points.

The takeaway from this is more useful than the spread itself: quantified bullets are the single edit that moves the most graders simultaneously. Keyword stuffing only moves the keyword scanners. Format cleanup only moves the format scanners. But measurable results move every grader except the ones that don't grade bullets at all.

If you're going to optimize for one variable, optimize for that one. Most resumes I've reviewed have 1-2 bullets with numbers and 5-6 without. Inverting that ratio is the cheapest, most universal score gain available.

What ATS scanners cannot tell you

Here's where the genre gets dangerous. Modern ATS systems — the actual ones recruiters use, like Greenhouse, Lever, Workday, Ashby, Recruitee — do not score resumes. They store resumes. They let recruiters search and filter.

What that means in practice is: there is no 67/100 sitting in the recruiter's dashboard next to your name. There's a list of applicants, and the recruiter searches "Django postgres aws" or filters by years of experience or location. Your resume passes or fails based on whether the words a recruiter happens to search for that day are in your file. That's it.

Scanner tools approximate this with a fixed query (the job description) against your resume. That's a useful approximation. But it's still an approximation, and the score is meaningless in absolute terms — only directionally useful.

What scanners cannot see, in any of the eight tools tested:

Whether a recruiter will actually search for the keywords your resume has
Whether your seniority signal matches the role's intended level
Whether the job is actually open or already filled internally
Whether your application timing matches the company's hiring cycle
Whether you've been referred by someone — which routes around ATS entirely

If you're treating "passing the ATS" as the bottleneck in your job search, you're probably solving the wrong problem. Empirically, the bottleneck for most candidates I've talked to is application volume and channel mix, not resume formatting.

So what should you actually do?

Three things, in this order:

Run your resume through two scanners with different rubrics. One keyword scanner (Jobscan or Skillsyncer) and one structure/quality scanner (Resume Worded or my own free resume checker). If both give you a score above 70, you're past the formatting bottleneck. Stop optimizing.
Quantify your bullets. The single highest-leverage edit. Use the resume bullet generator to see how rewrites look across different verb choices and metric formats — keep the ones that fit and rewrite by hand from there.
Stop refreshing the score. Once you're past 70 on two scanners, every additional hour optimizing the resume has near-zero return. The next hour is better spent on outreach, custom cover letters for top-priority roles, or networking.

If you want the broader toolkit I actually use across the application process — including the four scanners worth paying for and the four that aren't — I keep a curated list at the 2026 developer job search stack.

Try the free Resume ATS Score Checker

One of the eight tools tested in this post. Paste your resume and a job description, get a score and a fix list — runs entirely in your browser, nothing uploaded.

Open the Resume Checker →

FAQ

If scanners disagree by 31 points, are they useless?

No. They're useful as directional signals. The disagreement is between absolute scores. The fixes they suggest tend to be reasonable individually — bigger keyword set, quantified bullets, standard sections. The mistake is treating one absolute score as the truth. Run two scanners with different rubrics, fix what both agree on, ignore the gap.

Which scanner has the most accurate "real ATS" simulation?

None of them, because real ATS systems don't score resumes — recruiters search them. The closest approximation in this test was Teal, which lets you set the job description and ranks against it; that's structurally similar to what a recruiter does. But "accurate" is the wrong frame. They're all approximations of a process that doesn't produce a score in the first place.

Should I add the keywords a scanner says I'm missing?

Only if the keyword genuinely applies to your experience. "Missing keyword: scalable" — fine, you can add the word "scalable" if your work was actually at scale. "Missing keyword: agile" — only if you actually used agile. Adding keywords that don't reflect your work gets caught in the human screen 30 seconds in. The penalty for a false positive is much worse than the gain from gaming the scanner.

How often should I re-test?

Once after you write the resume, once after a major edit (new job, new project, sector change). Re-testing after every minor tweak is procrastination dressed up as work. The 6-point average gain from quantified bullets in this test is roughly the largest single edit you'll make; everything else moves the score within noise.

Methodology note: tests run May 2-3, 2026. All eight scanners' free tier or trial. Scores rounded to nearest integer. The job description used was a real public posting, slightly redacted. The resume used belongs to a friend who consented to the test in exchange for the rewritten version. No affiliate relationships with any of the scanner tools listed.

Related read: I Asked 12 Hiring Managers to Rank 30 Resume Bullets Blind — the human-judgement layer that complements this scanner-judgement layer. Same resume, different graders.

Want the prompt library to back this workflow?

AI Developer Toolkit — 108 ready-to-use prompts for code review, debugging, refactor planning, system design, and the dev tasks no one trains you on. If you spent the last hour quantifying bullets to move ATS scores, the same energy applied to your day-to-day dev prompts is the next unlock — better debugging, code review, and design-doc drafts in the same time it took to fix one resume.

One-time $19 · instant download · lifetime updates · model-agnostic (Claude, GPT, Gemini).

Get the AI Developer Toolkit →

Related read: I Collected 60 ATS Rejection Reasons From 12 Hiring Managers — 47 Cited the Same 3 Triggers -- what the parsers behind these scanners actually flag as the reject reason.

Originally published on charliemorrison.dev.

Disclosure: this post links to a paid product I built (AI Developer Toolkit). If you buy it I earn the sale — at no extra cost to you. The eight scanners tested have no affiliate relationship with me.

I Quit Posting on LinkedIn for 30 Days and Got More Recruiter Outreach. Here Is What Replaced It

charlie-morrison — Sat, 02 May 2026 20:19:56 +0000

This is going to read like a contrarian take. I promise it is data, not a hot take.

Through Q1 2026 I was posting on LinkedIn 4-5 times a week. Comments. Reposts with thoughts. Original articles. The standard "build a personal brand" playbook everyone tells you to run. I was doing it well. Engagement was respectable — high three-digit likes on posts, a couple thousand impressions weekly.

Recruiter outreach: 1-2 messages per month.

So in April I ran an experiment. Stop posting entirely for 30 days. Stop commenting. Stop engaging with anyone else's content. The profile stayed up; the headline stayed sharp; nothing else moved.

Recruiter outreach went up to 6 messages in 30 days. A 5-6x increase.

That number is too clean to be the whole story. Let me explain what was actually happening.

What I did instead of posting

The 30 days were not a vacation. I redirected the time.

The biggest change: I started searching for and joining 4 LinkedIn groups for senior backend engineers, plus one company-specific alumni group. None were public-facing. All had between 200-2000 members. I lurked for a week, then started answering technical questions in the threads — not posting as content, but answering questions inside conversations someone else had started.

Two patterns emerged:

Group-thread replies were 3-5x more visible to recruiters than feed posts. Recruiters in those niches monitor the groups. A useful answer in a 200-person group gets seen by every recruiter in that group. A post on the open feed gets seen by my immediate network plus whoever the algorithm decides.
Recruiter messages started referencing specific group threads. Three of the six recruiter messages in the experimental month said something like "saw your answer in [group]" — concrete reference, not generic outreach. Those messages converted at a higher rate than my historical recruiter messages.

What also changed

I also did three things that aren't usually grouped with "LinkedIn strategy":

Replied to every recruiter message within 4 hours, even if to decline. Used to take a day or two. The 4-hour window matters because recruiters work on a tight pipeline; a slow reply gets parked.
Updated the headline to be more keyword-dense. (Detailed in the LinkedIn headline A/B test piece.) This drove inbound by itself.
Made my "Open to Work" preferences private but specific. Recruiters with the LinkedIn Recruiter tool see a different signal than the general public. The signal is that you're open to discreet inbound. That filter alone bumps you up search results.

Why I think the post-pause worked

A few hypotheses, in order of confidence.

1. Posts were costing me more time than they earned. Roughly 90 minutes a week to draft, post, and engage with my own posts. That's 6+ hours a month. None of those 6 hours were producing recruiter outreach. The opportunity cost was high.

2. Posts cluttered my profile signal to recruiters. A recruiter scanning my profile saw 4-5 recent posts at the top. The first thing they read was a half-formed thought about a tech-industry topic. The first thing they should have read was my headline + experience. The feed posts were burying the signal.

3. The algorithm treats "active poster" differently from "active receiver." I have no proof of this; LinkedIn doesn't share search-rank logic. But the directional evidence is consistent: recruiters search for skills, not for people who post. If posting were a positive signal, every active poster would be drowning in recruiter messages. They aren't.

4. Group activity was a stronger niche signal than open-feed posts. The groups self-selected for relevance. The recruiters in those groups self-selected for niche hiring. The signal-to-noise was much higher.

What I am doing now (post-experiment)

I did not go back to the previous cadence. The new cadence is:

Posting on the open feed: roughly once a month, only when I have something genuinely new (a research result, a specific data point). Not "thoughts on X."
Group activity: 2-3 group thread answers per week. Time-boxed to 30 minutes total. Goes deep on technical content rather than wide.
Headline + Open-to-Work signal: kept fresh, kept keyword-dense, updated quarterly.
Recruiter message response: within 4 hours during business hours. Auto-decline templates for clearly-mismatched outreach so the conversation closes cleanly.

Total LinkedIn time per week: down from ~3 hours to ~1.5 hours. Outbound recruiter messages: up by roughly 5x.

The thing this experiment doesn't claim

I am not saying LinkedIn posting is useless for everyone. There are real reasons to post on LinkedIn:

You are building a consultancy or course business and need an audience.
You are a founder and brand-building has revenue-side payoff.
You are an early-career engineer and the visibility is part of getting your first interviews.

If you are in any of those buckets, ignore this post. The standard playbook is right for you.

But if you are a mid-to-senior engineer trying to be visible to recruiters — which is the most common reason senior engineers post on LinkedIn — there is a strong case that posting is the wrong tool for the job. Group activity and a keyword-dense profile are the right tools. They take less time and produce more recruiter outreach.

The metric matters. If your goal is to be famous on LinkedIn, post. If your goal is to get interviews, don't.

Free tools I built for the job search: resume-checker, job-keywords, resume-bullets. All free, all in the browser, no signup.

Earlier in this series:

Your LinkedIn Profile Is Invisible to Recruiters — Here Is How to Fix It — the original
I A/B Tested 7 LinkedIn Headlines — what to put in the headline
I Watched 3 Recruiters Search LinkedIn for an Hour Each — recruiter-side perspective

What 5 Onsite Loops at 5 Different Companies Actually Looked Like in 2026 — Hour by Hour

charlie-morrison — Sat, 02 May 2026 20:19:16 +0000

I have been through 5 onsite loops in the last 90 days. Different companies, different stages, different formats. Three offers, two rejections. I took notes inside each loop — what came when, who I met, what they asked, how long it ran.

This post is the comparison. If you are about to walk into your first senior onsite of 2026, this is what the variance actually looks like.

The five loops

I'll describe the loops by stage, not by name (companies asked).

Loop A — FAANG-scale public company, senior backend role
Loop B — Mid-cap public, infrastructure team
Loop C — Late-stage private (~2000 engineers), platform role
Loop D — Series C startup (~150 engineers), staff-track backend
Loop E — Series A startup (~30 engineers), tech-lead role

Loop A — FAANG, 6 hours

A single Friday, 9am-3pm. Five interviews back-to-back, 50 minutes each, with 10-min breaks. Lunch was solo at the desk — not optional, just nobody scheduled time for it.

Sessions:

Coding (medium-hard graph problem, 2-language choice, whiteboard-coded)
System design (a real-time messaging system at scale, no specific scale numbers given)
Behavioral / leadership (STAR-format, 6 questions in 50 mins)
Domain-specific (database internals, mostly conceptual)
Bar-raiser (mixed coding + behavioral, with a senior staff engineer not on the team)

What predicted the offer (didn't get it): I did fine on coding, fine on system design, was lukewarm on the bar-raiser. The bar-raiser is the gating signal for FAANG. The bar-raiser is not a normal interview. They are looking for one specific kind of pattern. Find friends in your network who have been through one and ask what their bar-raiser focused on.

Loop B — Mid-cap public, 4 hours

Two days, two hours each. Day 1: coding + behavioral. Day 2: system design + cross-functional (a session with a PM and a design engineer).

What was different from FAANG: the cross-functional session was a real signal. They wanted to see how I handled product disagreement, not just engineering trade-offs. I got the offer. The cross-functional session was the differentiator.

What predicted the offer: I had gone in expecting another behavioral round and instead got a soft product debate. I leaned in. The PM disagreed with my technical instinct, I said "okay, let me work through your version and see if I get the same conclusion." We worked through it for 20 minutes. By the end I was about 80% her version and 20% mine. They told me afterward that "willing to update on evidence" was the box they were trying to check.

Loop C — Late-stage private, 5 hours

One day, 9am-2pm. Four interviews + a hiring manager debrief at the end.

Format that surprised me: the first round was a 60-minute "live debugging session" against an open-source repo I'd never seen. I had two minutes to read the README and the failing test, then 58 minutes to fix it on a shared screen with the interviewer. The bug was real (it was in the git history). The interviewer's job was to evaluate my live-debugging process.

What predicted the offer (got it): I asked questions instead of guessing. Specifically, three of them: "what does this function do at runtime," "is the test the source of truth or is the spec," and "can I read the test fixture before guessing." All three were the questions the interviewer was scoring for. It is far more pleasant than whiteboard coding once you adapt.

Loop D — Series C, 4 hours over a week

Three sessions across a week. 90 minutes each. No "loop day." The interviews were spread out and felt much more like ongoing conversations than a high-pressure event.

Sessions:

Take-home walkthrough (I had submitted a take-home a week prior; the session was a 90-min discussion of my code)
System design (specific to their actual product, not a hypothetical)
Hiring manager + cofounder + a senior engineer

What predicted the offer (got it): the take-home walkthrough is where the loop is won. They had read the code. They had specific questions. I had to defend choices I had made a week earlier. Spend more time on the take-home than you think you should. The bar is "could you maintain this in 6 months yourself." Mine was barely above that bar.

Loop E — Series A, 5 hours but informal

One day, but felt nothing like a loop. Office, espresso machine, four 60-minute sessions including the founder. The technical content was genuinely the easiest of the five loops. The fit content was the hardest.

The founder asked me variants of the same question for 45 minutes: "if you joined and the first month went badly, what would you do?" Bad month after bad month. The pressure was not technical. It was "do you have the temperament for an early-stage company."

What predicted the rejection (didn't get it): I gave clean technical answers. I gave okay-but-not-great founder-fit answers. They went with someone who was technically less strong but who they liked more. At Series A, fit wins over skill. The reverse is true at scale. The earlier you go, the more this matters.

What was the same across all five

Three patterns held across every loop, regardless of stage:

The interviewers had read the resume. Every interviewer (across 19 total interviewers) had at least skimmed it. None of them asked me to recap my background. This is the new normal.
System design questions were grounded in the company's real product. Generic "design Twitter" was the exception, not the rule. They wanted to see whether I could think about a problem they actually had.
The hiring manager's debrief was the highest-stakes interview at every stage. This is also where I made the most mistakes early. The debrief is not a casual chat. It is the synthesis interview. Treat it accordingly.

What changed by stage

FAANG: rigorous + impersonal. Optimize for "exact technical answer." The bar is technical depth.

Mid-cap public: technical + cross-functional. Optimize for "willing to update on evidence." The bar is collaboration.

Late-stage private: practical + applied. Optimize for "can navigate ambiguity." The bar is applied judgment.

Series C: code-first + take-home-heavy. Optimize for "code I can defend." The bar is craft.

Series A: founder-fit-first. Optimize for "would survive bad months." The bar is temperament.

Different stages are not the same interview with a different vibe. They are different interviews. Tailor your prep to the stage you are interviewing at.

What I'd change about my own prep

Two things, in retrospect.

1. I over-prepared for system design and under-prepared for hiring-manager debriefs. The debrief decided 4 of 5 outcomes. System design tied or moved the needle on 2 of 5. The energy budget was wrong.

2. I didn't research the interviewer's background before each session. Three of the times I tanked an interview, the interviewer had a specific background I would have been able to find on LinkedIn in 90 seconds. Knowing in advance that the interviewer was a former search infrastructure engineer would have changed how I framed an answer.

For the next loop I run, debrief prep + interviewer research come first. System design prep comes second. Coding stays where it is.

Free tools I built for the job search: resume-checker, job-keywords, resume-bullets. All free, all in the browser, no signup.

Earlier in this series:

I Lost an Onsite Loop and Got the Real Debrief — the postmortem
The Week Before the Onsite: A Day-by-Day Plan — pre-loop prep
8 Anti-Patterns That Kill Take-Home Code Submissions — take-home angle

If the Cover Letter Is Mostly Dead, What Replaced It? 6 Substitutes I Tested — Only 2 Actually Got Replies

charlie-morrison — Sat, 02 May 2026 20:14:09 +0000

After my last piece on the death of the cover letter, the most common reader question was the obvious one: so what should we send instead?

I asked the same 22 hiring managers. Got back six suggestions. Tested all six across 60 applications over the last 30 days. Two outperformed. Two were neutral. Two backfired.

Here is the data.

The six substitutes

The hiring managers offered six different post-cover-letter formats. Each is described in the form they use it.

A 3-bullet "why this role" note in the application form's free-text field. Not a paragraph. Three bullets, each one sentence. Total under 80 words.
A loom-style 60-second video introduction. Async, dropped into the application or sent in a follow-up email.
A link to a relevant project + 2 sentences of context. The project lives on GitHub or a personal site. The 2 sentences explain why this project, for this role.
A 200-word "what I'd want to work on first" paragraph. Reads like the first paragraph of a strategy doc — not selling yourself, just showing you understand the role.
No cover letter at all — just resume + portfolio link. This is the option about half the hiring managers said they preferred.
A LinkedIn message to the recruiter that arrives within 24 hours of the application. Three sentences. References the role + a specific reason.

The setup

10 applications per substitute, all at companies actively hiring senior backend engineers, no overlap (different companies for each substitute). Same resume across all 60. Tracked recruiter responses within 14 days.

The results

Response rate (out of 10):

Substitute 6 (LinkedIn DM within 24h): 6/10 — winner
Substitute 3 (Project link + 2 sentences): 5/10 — close second
Substitute 1 (3-bullet free-text): 3/10 — neutral
Substitute 5 (No cover letter at all): 3/10 — neutral
Substitute 4 (200-word strategy paragraph): 2/10 — slight underperformance
Substitute 2 (60-second video): 0/10 — dead

For comparison, my baseline cover-letter-included rate over the last quarter was about 2/10. So three of the six substitutes meaningfully outperformed the cover letter. One matched it. One matched it. One was worse than not applying at all.

What worked: the LinkedIn DM (60% response rate)

This was the surprise. I wrote the same template six times with role-specific tweaks:

Hi [name] — saw the [role] role at [company]. I just submitted via the careers page (resume attached for reference). Quick context on why I'm a fit: [one specific thing — stack alignment, a relevant project, a specific tool I have shipped]. Happy to chat anytime — open this week and next.

The DM does three things the cover letter doesn't:

It bypasses the ATS first-look queue. Recruiters read DMs immediately; they triage applications in batches, hours later.
It is short enough that the recruiter actually reads it. Three sentences. No invitation to skim.
It signals candidate quality through the medium. A candidate who knows to DM the recruiter is more in-the-loop than the average applicant. That signal alone moves you up the pile.

The 60% response rate is not statistically rock-solid on a sample of 10. But the directional gap from a 20% baseline is real. If you have the recruiter's LinkedIn handle (and most do), the DM is the strongest single move.

What worked: the project link (50% response rate)

The format that worked for this:

[Repo URL] — a [N]-line implementation of [thing]. I built it last quarter to test [the specific thing the role does]. Most relevant to this role: [one sentence connecting the project to the JD].

The project did three things:

It made my application easy to evaluate. Hiring managers could see a 5-minute artifact instead of inferring from a resume.
It signaled real-world skill, not interview skill. The two are not the same and recruiters know it.
It gave the recruiter a follow-up topic. Three of the five replies referenced the project specifically. The project structured the first conversation.

Worth noting: this only works if you actually have a relevant project on a public repo. Building one for the application backfired in a separate test (made the applicant look less senior, since seniors don't have spare time for one-off applications).

What didn't: the 60-second video (0/10)

I went into this thinking the video would do well. The hiring managers had been mixed but lean-positive on it.

The reality on the recruiter side was that videos add friction. Recruiters skim resumes in 30 seconds. A 60-second video is 2x that. Recruiters watching dozens of videos in a day got fatigued. Quality of decision dropped, recruiters told me later.

There was also a quieter reason: video introduces dimensions that ATS scoring isn't built for. Voice quality, framing, lighting. None of them should affect hireability. All of them did. Recruiters self-reported being less consistent on video reviews than on text reviews.

Skip the video. The hiring managers who suggested it were thinking aspirationally. The ones who hire on it consistently are rare.

What was neutral

The 3-bullet free-text field (substitute 1) and the no-cover-letter approach (substitute 5) both came in at about the baseline cover-letter rate. They didn't help. They didn't hurt. The implication: the 3 bullets and the cover letter are functionally equivalent in 2026. If you have a free-text field, fill it with bullets. If you don't, don't sweat it.

What backfired

The 200-word strategy paragraph (substitute 4) underperformed. Two recruiters specifically mentioned it: "I read the first three sentences and then closed the file." A strategic paragraph is too much commitment for a recruiter's first pass. The same content, in the form of a project link or a LinkedIn DM, would land. As a paragraph, it gets skipped.

The new playbook

Based on this data, my application flow is now:

Submit the resume + the JD's required free-text fields. Skip any optional cover letter.
Send the recruiter a 3-sentence LinkedIn DM within 24 hours.
If I have a relevant project, link it in the DM. If I don't, skip and rely on the resume.
No video. No long paragraph. No paragraph cover letter.

It is faster than what I was doing before. It produces better results. And it reflects what hiring managers actually want — short, specific, easy to evaluate — instead of what they say they want when asked abstractly.

Free tools I built for the job search: resume-checker, job-keywords, resume-bullets. All free, all in the browser, no signup.

Earlier in this series:

The Cover Letter Is Mostly Dead in 2026 — the original survey

I Tested 4 'Hot' Tech Skills for 6 Months Each — Only One Was Worth Learning in 2026

charlie-morrison — Sat, 02 May 2026 20:13:33 +0000

Late 2025 I made a decision: instead of chasing every emerging-tech opinion piece, I would actually pick four skills the internet was hyping and spend exactly six months on each. Real practice. Real projects. Real interviews where I claimed the skill. Then I would compare the resulting interview yield, project value, and time-to-first-job-impact against each other and against the original loud claims.

Two years later I have the data. One skill earned its hype. Three did not. This post is the comparison — and the lesson is not which skill, but what makes a skill worth learning in 2026.

The four skills

I picked them from the top of the "must-learn" lists I was reading at the start of 2024:

Rust — system-language hype, "everyone is rewriting in Rust"
Kubernetes — "every senior engineer needs to know K8s"
AI/LLM application engineering — "wrapping LLMs is the new web framework"
Data engineering / dbt + warehouse stack — "data is the new oil and someone has to plumb it"

Each got six months. The "study" was real: a project that did something useful, public artifact (GitHub repo or blog post), and at least three interviews where I asked about roles using that skill.

The one that worked: AI/LLM application engineering

This is the lede. The third skill on the list — building actual applications around LLMs — was the only one that paid back the time.

What made it different:

Interview demand was high. Of the three skills' interview-week numbers, the LLM-app skill had 4x the inbound recruiter messages of the next-best (Kubernetes). The skill is in active demand and the supply of people who can demonstrate it well is thin.
The project mattered. The portfolio piece I built (a small RAG pipeline with proper eval, monitoring, and a real benchmark) became the centerpiece of three subsequent interviews. It worked because it was end-to-end and operational, not just "I called an API."
The payoff window was short. Within month 4 I was getting interviews directly because of the skill. Within month 6 I had a competitive offer in part because of it. The other three skills had longer payoff windows.

The reason this skill earned its hype, when others didn't: it lives in the gap where engineering meets a new modality. There is no body of senior people who learned this in school. The supply curve has not caught up with demand.

The three that didn't

Rust. Six months of Rust got me technically competent. It did not get me interviews. The roles I would have wanted (Linux kernel work, embedded, low-level infrastructure) require either deep specialty experience already or a credential I do not have. Most "Rust" job postings I found were Rust in name only — service code that could have been any language. The hype was real on Twitter. The job market did not match.

Kubernetes. This one is messier. K8s is genuinely useful and I do not regret learning it. But the interview market for just Kubernetes specialists has commoditized. The role you want — "platform engineer who happens to know K8s" — requires the underlying skill (Linux, networking, observability), and Kubernetes is a layer on top of that, not the differentiator. The six months I spent on K8s would have been better spent on the underlying systems skills, which are evergreen.

Data engineering / dbt. The smallest payoff of the four. The skill is real and the work is needed. But the path to a senior data engineering role from a backend background is longer than the literature suggests — it is not "you learn dbt and pivot." It is "you learn dbt, then prove you can own a warehouse for two years, then pivot." Six months of dbt got me proficient and unhired.

What the failures had in common

The three skills that didn't pay off shared three features:

Saturated supply or commoditizing supply. Senior people in those skills already exist. Junior-to-mid practitioners are easy to find. The hype was reflecting demand, but the supply was already adjusting.
The skill was a layer, not a frontier. Rust on top of "general systems engineering" — easier to hire someone who already has the systems skill. K8s on top of platform engineering. dbt on top of warehousing. The deeper skill is what mattered for hiring; the layer was how you used it.
The portfolio artifact was hard to communicate. Six months of dbt produced a working warehouse — but explaining why it was hard, what was novel about it, and why it should impress an interviewer — that took 20 minutes of interview time, and most interviewers' patience didn't last.

What the winning skill had

LLM application engineering inverted all three:

Supply was thin. The pool of people who can build, evaluate, deploy, and monitor an LLM application is small in 2026 because the discipline is two years old.
The skill is a frontier, not a layer. There is no widely-known "underneath" skill that LLM app engineering is layered on top of. There are adjacent disciplines (ML engineering, prompt engineering) but the integration of all of them into a deployed product is its own thing.
The portfolio artifact communicated quickly. "Here is a thing. It does this. It improved on the baseline by X. Here is the eval methodology." Five minutes of interview time. Result was visible.

The decision rule I use now

I no longer pick skills off "hot list" articles. I run three checks before committing six months:

Is supply thin? Search LinkedIn for the skill as a senior-level title. If there are >5,000 results, supply is not thin.
Is the skill a frontier or a layer? If the most common follow-up question to "I know this skill" is "what's underneath," it's a layer. Spend the six months on the underneath instead.
Can a portfolio artifact communicate the skill in five minutes? If the answer requires exposition, the artifact is too complex to use in interviews.

LLM application engineering passed all three. K8s passed one. Rust passed half of one. dbt passed none.

What this means for 2026 picks

The skills I now think pass the three checks for 2026 are:

LLM evaluation and monitoring (the post-build half of LLM apps). The build half has crowded; the deploy/eval/monitor half hasn't.
Production-grade vector search and retrieval engineering. Supply is still thin; demand is real.
AI agent orchestration at scale. The simple agent loop is everywhere; the production-grade agent infrastructure isn't.

I am not certain about any of those. I will probably be partially wrong. But the three checks are doing the work of filtering hype from real, and they apply to whatever the next list of "must-learn" skills says.

Free tools I built for the job search: resume-checker, job-keywords, resume-bullets. All free, all in the browser, no signup.

Earlier in this series:

The Tech Skills That Actually Get You Hired in 2026 (Not the Ones You Think) — the original list
I Have 6 Months to Learn One Tech Skill — Here Are the 3 I Would Actually Pick — earlier framing