DEV Community: charlie-morrison

I Ran 4 Salary Negotiation Tones Through an AI Detector

charlie-morrison — Mon, 20 Jul 2026 20:04:51 +0000

Half the salary advice online now ends the same way: paste your role into some generator, pick a tone, copy the script it spits out, send it. I have nothing against that. A script beats freezing up when a recruiter asks what number you had in mind. But there is a quieter problem nobody mentions. Hiring managers read a lot of email, and in 2026 a growing share of them can smell a machine-written message from the subject line. If your carefully generated counter-offer reads like it came out of a chatbot, the number is not the thing that sinks you. The voice is.

So I stopped guessing and measured it. I took one free salary negotiation script tool, gave it a single scenario (countering a lowball offer) and generated the exact same negotiation in all four of its tones. Then I fed each result into an AI-text detector and wrote down the score. Same facts, same numbers, same person. Only the tone changed. The spread surprised me, and the tone I expected to sound the most robotic came out the most human.

The test: one offer, four tones, one detector

I kept every input frozen so the only moving part was tone. The scenario was "countering a lowball offer." The role was Senior Backend Engineer in tech, eight years of experience, a current offer of $120,000, and a target of $150,000. For the three achievement bullets I used real, specific wins: cut cloud spend 34% by re-architecting the billing pipeline, shipped a fraud-detection service now screening four million events a day, mentored three juniors with two promoted inside a year. Concrete numbers, because vague bullets are their own separate problem.

Then I generated the script four times, switching only the tone selector: Confident & Direct, Collaborative & Warm, Data-Driven & Analytical, and Humble but Firm. Each run produced two script versions plus a short tips block. I ran the raw script text of each tone through the same AI-writing detector I use on my own drafts before anything ships. It returns a 0-to-100 score where higher means more machine-like. Here is the data-driven run mid-generation, so you can see the tool and the inputs I am describing:

The free salary script tool generating the "Data-Driven" counter-offer, using the same frozen inputs, one of four tone runs.

The scores

Lower is better here. A low score means the text reads like a person wrote it.

Tone	AI-likeness (0-100)	Reads as…
Data-Driven & Analytical	2	Clearly human
Humble but Firm	23	Mostly human
Collaborative & Warm	28	Borderline
Confident & Direct	35	Most machine-like

I had it backwards going in. If you had asked me to guess, I would have said the "Data-Driven" tone, with its percentiles, market bands, and the word benchmarked , would read the most like a spreadsheet wrote it. It read the most human of the four, by a wide margin. And "Confident & Direct," the tone that is supposed to sound like a real person putting their foot down, scored the highest on the robot scale. The reason turns out to be simple once you read the two side by side.

Why "Confident" read like a bot

Here is the confident version, lightly trimmed:

Thank you for the offer of $120,000. I want to be straightforward: that's significantly below what I'm seeing for Senior Backend Engineer positions in tech… I need to be at $150,000 to accept. I'm not trying to negotiate for the sake of it -- that number reflects my market value and the results I'll deliver. Is there flexibility on your end?

Read it out loud and the tells stack up. " I want to be straightforward." "I have to be honest." "I'm not trying to negotiate for the sake of it." These are announcements of a posture rather than the posture itself, the verbal equivalent of a header that says TONE: CONFIDENT. Real confident people rarely narrate that they are being direct; they are just direct. Then it closes on a soft rhetorical question, " Is there flexibility on your end?", which is the exact hedge-after-a-bold-claim rhythm that AI detectors are tuned to notice. The message is trying to perform confidence, and performance is what reads as synthetic.

Why "Data-Driven" read human

Now the same offer in the data tone:

I'd like to discuss the offer of $120,000. Here's my analysis: market rate for Senior Backend Engineer in tech sits in the $150,000 range… The offer sits below the 25th percentile for someone with eight years of experience… My counter: $150,000, which is in line with the median. I'd rather we both start with a number grounded in data. Does this align with your internal bands?

There is almost no throat-clearing. It states a fact, attaches a number to it, and moves on to " below the 25th percentile," "in line with the median," "your internal bands." Concrete nouns crowd out the filler phrases, and the closing question is a genuine ask about the company's pay bands, not a rhetorical softener. Detectors key on generic connective tissue, the "I want to be honest with you" padding, and this version simply has less of it. The lesson is not "always pick the data tone." It is that specificity is what makes writing sound human , and the data tone happened to force the most of it.

What this actually means for your next email

You do not need to abandon script tools. You need to edit their output like a human would before it leaves your outbox. Three moves cover most of it:

Delete the posture announcements. Cut every "I want to be honest," "let me be straightforward," "I'm not trying to be difficult." If the sentence describes your tone instead of doing the work, it goes.
Replace one vague clause with a number. "Below market" becomes "below the 25th percentile for eight years' experience." Specificity reads as human and, separately, it is more persuasive. Harvard Business Review's long-standing negotiation guidance is that you justify the ask with evidence, not adjectives (HBR's 15 rules for negotiating an offer).
Kill the rhetorical closer. "Is there flexibility on your end?" is filler. "Can you match $150,000, or should we talk about the equity side?" is a real question that forces a real answer. Indeed's script guidance makes the same point: state the counter and the reason clearly and stop (Indeed's salary negotiation scripts).

Run whichever tone fits the relationship, then spend two minutes stripping it of the four or five phrases that scream "generated." That two minutes is the difference between a message a hiring manager reads as a candidate who did their homework and one they read as a candidate who pasted a template.

Generate the script, then make it sound like you.

The Job Search AI Toolkit is 100+ prompts for the whole offer stage: counter-offer language that avoids the robotic tells, the follow-up note after you send it, and the "what's your range" answer that comes before any of it. Built for editing, not blind pasting.

Get the Job Search AI Toolkit -- $12

One caveat about the number itself

An AI detector measures how machine-like the prose is, not whether the negotiation is any good. A perfectly human-sounding email that asks for a number with no justification behind it will still lose to a slightly stiff one backed by real market data. The tone test is about clearing a threshold, so you avoid tripping the "this is a bot" reflex. It is not about winning the negotiation on style. Get the message past the human filter first, then let the evidence do the arguing. If the underlying number is wrong, the smoothest wording in the world will not save it, which is a separate exercise in answering the salary-expectation question before you ever get to the counter.

FAQ

Do salary negotiation scripts really sound like AI to hiring managers?

Some tones do. In my test, the "Confident & Direct" script scored 35 out of 100 on an AI detector while the "Data-Driven" version scored 2, from the exact same inputs. The difference was filler phrases like "I want to be straightforward" and a rhetorical closing question, both patterns detectors flag. A hiring manager who reads a lot of email notices the same rhythm.

Which tone should I use for a counter-offer?

Match the relationship, but bias toward specificity. The data-driven framing read the most human in my test because it swapped vague adjectives for concrete numbers: percentiles, medians, your role's pay band. You can use any tone and get the same effect by editing out the posture announcements and adding one hard number to justify the ask.

How do I make a generated negotiation email sound less robotic?

Delete the phrases that describe your tone instead of showing it ("let me be honest," "I want to be direct"), replace one vague clause with a specific number, and turn any rhetorical closing question into a real one that forces a decision. Those three edits removed most of the AI-likeness in the scripts I tested.

Is it a bad idea to use a salary script tool at all?

No. A script is a good starting point, especially if negotiating makes you freeze. The mistake is pasting the output unedited. Generate the structure, then spend two minutes stripping the four or five generic phrases that make it read as machine-written before you send it.

Does an AI detector score tell me if my negotiation will succeed?

No. It only measures how human the prose reads, not whether the ask is justified. A human-sounding email with no evidence behind the number still loses to a stiff one backed by market data. Use the tone check to clear the "this is a bot" filter, then let concrete numbers carry the actual argument.

Related reading: I generated 30 salary negotiation scripts to see which openings recruiters actually respond to, and what happened across 38 counter-offer negotiations. Both use the same "test the advice, don't repeat it" approach as this post.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

The Recruiter Phone Screen: I Ran My Own Interview-Prep Tool and It Prepped Me for the Wrong Call

charlie-morrison — Tue, 14 Jul 2026 19:55:13 +0000

I build a free interview question generator. People use it to prepare for interviews, which is what it says on the box. Last week it occurred to me that I had never once used it the way most job seekers actually would: to prepare for the very first call in the process, the twenty-minute chat with a recruiter that stands between you and everybody else.

So I ran it. I pasted in a real posting, picked the level, and read what came back. Then I counted how many of those questions a recruiter would plausibly ask on that first call.

The answer was one. And it was not the one you would guess.

The setup

I used a job description close to something I would actually apply for, and I deliberately loaded it with the two things a screening call always covers:

Own payment settlement and reliability for a high-volume logistics platform. 5+ yrs backend, Go or Python, distributed systems, on-call. Remote (EU), occasional travel. Competitive salary.

Job title: Senior Backend Engineer. Industry: Technology. Level: Senior (5+ years). The posting names compensation and it names location. Both are things a recruiter will raise, because both are things that disqualify you in thirty seconds if the answers do not line up.

Here is exactly what the tool gave me.

My own generator, running live on the posting above. Note what it leads with: the STAR method.

What came back

Fifteen questions in four groups. Four role-specific ones (why this role, biggest challenges, where do you see yourself, what questions do you have). Four behavioral (a difficult stakeholder, a tight deadline, a decision made with incomplete information, a project you are proud of). Four technical, drawn from the tech bank and stitched to the posting. Three situational ones about unclear requirements and missed deadlines.

Above all of it sits a panel telling you how to answer: Situation, Task, Action, Result. Quantify if possible.

That is good advice for an interview. This is not an interview.

I went and counted properly, not just in the fifteen it happened to draw, but across every question the tool can produce. There are 53 in its banks. The number that mention salary, compensation, notice period, start date, availability, work authorization, visas, relocation, remote or onsite work, why you are leaving your current job, other offers, or the phrase "tell me about yourself":

Zero. Out of 53.

In the live run, exactly one of the fifteen questions belonged to the screening genre at all: " Why do you want to work as a Senior Backend Engineer?" That is a motivation question, and it is real. But the posting I pasted said Competitive salary and Remote (EU) , and my tool asked me about neither.

I wrote this thing. It has been live for months. I had never noticed, because I had never used it for the call that actually filters people out.

What the recruiter is doing instead

The mistake is thinking the phone screen is a small interview. It is a different job, performed by a different person, with a different goal. The hiring manager wants to know whether you can do the work. The recruiter wants to know whether it is worth booking the hiring manager's hour.

SHRM's guidance for recruiters running these calls is unusually blunt about what they are listening for. Sarah Greer, quoted in SHRM's piece on conducting effective phone screens, asks: " Can they carry a conversation easily or are they overly rehearsed?" and " Do they answer questions with direct and relevant responses?" Kara Freiburger, in the same article, describes probing for " what the candidate is really looking for, what motivates them, and what type of environment they thrive in."

Read that again with a STAR worksheet in your hand. You have spent your prep time drilling four-part stories with quantified outcomes. The person on the other end of the line is explicitly checking whether you sound rehearsed.

That is the trap, and it is a nasty one, because the preparation is not wrong. It is just early. Those stories will win you the second round. Deployed in the first, in answer to "so what are you looking for?", they read as a person reciting.

The one question you must not improvise

Of everything a recruiter raises, compensation is the one where thinking out loud costs real money. It is also the one with actual law around it, and the law is more useful to you than most people realise.

There is a difference between salary history and salary expectations , and it matters. HR Dive's salary history ban tracker counted 22 state-wide bans and 24 local ones as of its April 2026 update. Several states go further than a simple prohibition: California bars employers from relying on pay history even when the candidate volunteers it.

Expectations are a separate matter and are generally fair game. Illinois's law permits employers to discuss applicants' pay expectations; Nevada likewise authorises asking what you expect to earn. So the practical shape of it, in much of the US:

" What do you currently make?" -- frequently unlawful to ask, and you are under no obligation to volunteer it.
" What are you looking for?" -- almost always allowed, and it is coming.

Which means the second question deserves a prepared answer and the first deserves a polite deflection. Have a range. Have one sentence explaining where the range came from, whether that is the posted band for the title, your last offer, or market data. A range you can justify closes the topic in twenty seconds. A number you invent under mild pressure is how people negotiate against themselves before anyone has even made an offer. I went deeper on the phrasing in my test of 12 salary expectation answers, and the salary negotiation script generator will draft the range language if you want a starting point.

The five lines to write down before the call

Not stories. Lines. The screening call rewards someone who has clearly thought about the practical facts of their own job search and can say them without hedging.

Sixty seconds of background. What you do, at what scale, and the thread connecting your last two roles to this posting. Not your career from the beginning. The recruiter is matching you to a requisition, not admiring the arc.
Why you are looking. One honest, unbitter sentence. "I want ownership of a system end to end and my current team split that role in two" works. Anything that sounds like a grievance does not.
Your number. A range, and the reason for it. Decide it before the call, because you will not decide it well during one.
When you could start. Notice period, any holiday already booked. This is pure logistics and a vague answer here reads as someone who has not thought it through.
Where you can legally work. Time zone, right to work, whether the posting's "occasional travel" is fine. Two seconds to say, and the answer is disqualifying if it is wrong, so get it on the table.

That is the whole sheet. It fits on an index card, and it covers most of what the call is for. Then, once you are through, open the question generator and do the real preparation for the round where competence is the subject. That order is the point of this post.

Two bugs I found in my own tool

Running your own software as a stranger would is uncomfortable and worth doing. Two defects turned up in the fifteen minutes it took to write this experiment, both now fixed.

The technical questions contain placeholders like [specific feature from JD], filled from keywords scraped out of the posting. The scraper only recognises technologies, from a fixed list of about 45. My posting was about payment settlement and distributed systems; the only word it matched was Python. So the tool cheerfully asked me to " design a system to handle python."

Worse, the substitution ran only when at least one keyword matched. Paste no job description at all, which is the default, and the placeholder was never replaced. Users were shown the literal string [specific feature from JD] in the middle of a question. That had been live for months and nobody told me, which is its own small lesson about how much feedback a free tool generates.

Both are fixed. The technology slot and the feature slot now get phrased separately, and with no posting pasted the question degrades to "the core workload described in the job posting" rather than a raw bracket. If you used the generator before July 9 and saw something odd, that was me.

The bottom line

Interview preparation, as an entire genre, is aimed at the hiring-manager round. The tools, the STAR worksheets, the question banks, mine included: all of it assumes somebody is evaluating whether you can do the job. Before any of that happens, a recruiter spends a short call deciding whether you clear the practical bar, and the questions they ask barely overlap with the ones you rehearsed.

Prepare for both. Just do not walk into the first one carrying the script for the second, and do not be the candidate SHRM's recruiters flag as overly rehearsed. Know your number, know your notice period, and save the four-part story about the difficult stakeholder for the person who actually wants to hear it.

Prep the round that comes after the screen.

Once the recruiter passes you along, the questions change and so does the preparation. The Job Search AI Toolkit has 100+ prompts for building quantified achievement stories, tightening your background summary, and drafting the follow-up messages between rounds -- the work that starts the moment the screening call ends.

Get the Job Search AI Toolkit -- $12

Frequently asked questions

What does a recruiter actually ask on a phone screen?

Mostly things that filter rather than evaluate: a short version of your background, why you are looking, what you expect to be paid, when you could start, and where you can legally work. Competence questions come later, from the hiring manager. The recruiter is confirming you are worth that person's hour.

Should I use the STAR method on a recruiter phone screen?

Sparingly. STAR is built for behavioral questions in the hiring-manager round. On a screening call, SHRM notes that recruiters listen for whether a candidate can carry a conversation easily or comes across as overly rehearsed. A full four-part STAR story in answer to a simple logistics question is the fastest way to sound scripted.

Can a recruiter ask my current salary?

In much of the United States, no. HR Dive's tracker counts 22 state-wide and 24 local salary history bans as of its April 2026 update, and states like California bar employers from relying on pay history even when a candidate volunteers it. Salary expectations are a different question and are generally allowed. Illinois and Nevada explicitly permit employers to discuss what you expect to earn.

How do I answer the salary expectations question?

With a range you decided before the call, plus one sentence explaining where the number came from: posted ranges for the same title, your last offer, or market data. A range you can justify ends the topic in twenty seconds. Improvising a number is how people talk themselves down.

Is an interview question generator useless for a phone screen?

It is useful for the wrong call. Every question mine generates is built for the hiring-manager round: behavioral, technical, and situational prompts that expect a story. That is genuinely what you need for round two. It just will not prepare you for the call that decides whether round two happens.

Related reading: what actually moved the needle across 31 interview prep strategies, and what got replies from 40 LinkedIn recruiter connection notes -- the message that gets you the screening call in the first place.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

PDF vs Word Resume: I Tested Both Through an ATS Checker

charlie-morrison — Mon, 13 Jul 2026 20:05:42 +0000

If you have read more than two resume guides you have met the argument: send a PDF so the formatting never breaks versus send a Word doc so the robots can read it. Both sides say it with total confidence, and both quote the same vague authority: "the ATS." I got tired of the theology, so I ran the test myself. I took one resume, made two versions of what an applicant-tracking system would actually pull out of the file, and fed both to the ATS score checker on this site. The result surprised me, and it changed how I answer this question -- because my own tool gave the two versions the same score , and that identical number turned out to be the most useful thing in the whole experiment.

What the question is really asking

Here is the part almost every "PDF vs Word" article skips. An applicant-tracking system does not admire your file. It opens it, rips the text layer out of it, and throws away everything else -- the fonts, the colors, the neat little icons, the layout. Then it tries to sort that raw text into sections it recognizes: contact, experience, education, skills. If you want the full definition of what that software does, the Wikipedia entry on applicant tracking systems lays out the parse-and-rank pipeline cleanly. The practical takeaway is that the file extension is almost never the thing that breaks. What breaks is the order the text comes out in.

And the single biggest cause of scrambled text is the two-column resume: the pretty template with a slim left rail for skills and contact details and a wide right column for experience. On the screen it looks organized. To a text extractor reading top to bottom, the two columns collapse into each other line by line. Your phone number ends up glued to your job summary. A skill lands in the middle of a bullet about latency. That damage happens the same way whether the file is a PDF or a Word doc -- it is the layout , not the format. PDFs just get the blame because that is where people put their fanciest layouts.

The test: two extractions, one resume

I wrote a realistic senior-backend-engineer resume: a summary, one dated role with four achievement bullets, a skills line, and education. Then I made two text versions of it, the way an ATS would see each.

The clean version -- single column, top to bottom, exactly how a plain Word doc or a simple one-column PDF extracts. Headings sit above their content, bullets stay whole.
The scrambled version -- what you get when a two-column PDF is read by vertical position: the left-rail skills and the right-column experience interleave line by line. Redis ends up on the same line as a settlement-latency bullet. This is not me being unfair; it is the standard failure mode of column layouts, and you can reproduce it in ten seconds (I will show you how below).

I pasted each version into the free resume ATS checker on this site, with the same job description in the second box, and hit analyze. Here is the scrambled two-column extraction:

The scrambled two-column extraction, with skills and bullets fused into each other, still scored 78 and "Strong ATS compatibility."

The surprising result: both scored 78

The clean version scored 78. The scrambled version, with contact details welded to sentences and skills scattered through the experience section, also scored 78. Same "4 standard sections detected." Same 57% keyword match. Same "Strong ATS compatibility" badge. My own tool could not tell the difference between a resume a recruiter could read and one that had been through a paper shredder.

My first instinct was that the checker was broken. It is not. It is doing exactly what most free ATS checkers do, and understanding why is the actual lesson of this post.

A keyword-based checker searches for words. After a two-column scramble, all the words are still in the file -- "experience," "skills," "Python," "Kafka" -- just in the wrong order. So the checker finds them and reports a healthy score. It never asks the harder question a real ATS asks: which company goes with which title, and which dates go with which job?

That harder question is where a column scramble actually hurts you. A real applicant-tracking system does not just count words; it maps fields. When your dates and titles have drifted into the wrong column, the system files "2021-2026" under the wrong employer, or fails to associate your skills with any role at all. The recruiter searches for "Kafka, 5+ years" and you do not surface -- not because the word is missing, but because it is orphaned. A keyword checker, mine included, is blind to that.

So is PDF or Word actually safer in 2026?

With the layout myth cleared out, the format question gets a boring, honest answer: in 2026 the major systems accept both. Workday, Greenhouse, Lever, and the other big platforms parse .pdf and .docx text layers fine. The old "never send a PDF" rule dates back to a decade ago when many parsers genuinely choked on PDFs; it has aged into folklore. Harvard's career office, in its resume guidance, tells students to keep the document simple and readable rather than fixating on the extension -- because a clean single-column file survives either way.

There are only three real caveats, and none of them is the file type on its own:

Follow the instructions. If the job posting says ".docx only" or the application form accepts only Word, send Word. A parser cannot rank a file it refused to accept.
Never send an image-only or scanned PDF. If you exported to PDF from a design tool and the text is baked into a picture, there is no text layer to extract -- the ATS gets nothing. This is the one case where "PDF" genuinely fails, and it fails hard.
Kill the columns and tables. Whatever format you pick, use one column, standard headings, no text boxes, and no tables. That single change matters more than PDF-versus-Word ever will.

My default recommendation, when the posting does not specify: send a single-column .docx. It is the safest text layer, it re-opens cleanly on the recruiter's end, and it sidesteps the image-only-PDF trap entirely. If you love your PDF, fine -- just export it from a one-column source and check it before you send.

Test your own resume in ten seconds

You do not need a paid scanner to catch the failure that actually matters. You need a plain-text editor. Here is the exact check I use, and it is the practical payoff of the whole experiment:

Open your finished resume -- PDF or Word, does not matter.
Select all, copy, and paste it into Notepad, TextEdit (in plain-text mode), or any blank text box -- even the resume box on the checker.
Read what lands. If it reads top to bottom, in order , with headings above their content and bullets intact, an ATS can read it too.
If it comes out scrambled (skills fused to bullets, phone number mid-sentence, dates floating), your layout is the problem. Rebuild it in a single column and paste again.

That copy-paste test sees exactly what an extractor sees, and unlike a keyword score it cannot be fooled by a scramble, because you are reading the raw order with your own eyes. It is the one check I would run before sending any resume anywhere. Recruiters, remember, barely read the thing even when it parses perfectly -- Nielsen Norman Group's work on how little people actually read on screens is a good reminder that the important lines have to land where a skimming human expects them. A scramble buries them twice: once for the machine, once for the person.

Stop guessing at the format. Fix the whole resume.

The file type is the easy part. The Job Search AI Toolkit gives you 100+ prompts for rebuilding bullets into quantified achievements, tightening your summary into one clean column, and prepping the follow-up and interview messages that come next -- the parts that move the score after the parser lets you in.

Get the Job Search AI Toolkit -- $12

The bottom line

The PDF-versus-Word war is mostly a distraction. When I forced the question through a real tool, the format did not move the score at all -- and even a badly scrambled resume scored "Strong," which tells you a keyword score is a smoke detector, not an inspector. The thing that decides whether a machine can route you forward is whether your text extracts in order, and the thing that wrecks that is a multi-column layout, in any format. Pick one column, standard headings, a real text layer. Send .docx when in doubt. Then do the ten-second copy-paste test with your own eyes, because that is the check the free scanners -- mine included -- quietly fail.

Frequently asked questions

Should a resume be a PDF or a Word document in 2026?

Either works with the major systems (Workday, Greenhouse, Lever) as long as the file has a real text layer and a simple layout. When the posting does not specify, I send a single-column .docx -- it is the safest text layer and avoids the image-only-PDF trap. Always follow the posting's stated format when it names one.

Do ATS systems actually read PDFs?

Yes, modern ones read the text layer of a normal PDF fine. The exception is an image-only or scanned PDF (text baked into a picture), which has no extractable text -- the ATS gets nothing. Export from a text-based source, not a flattened image, and a PDF parses like any other file.

Why did the scrambled resume still score 78 on your checker?

Because that checker, like most free ones, searches for keywords, and after a two-column scramble all the words are still in the file, just out of order. It cannot see that dates drifted away from titles or skills detached from roles. A real ATS maps those fields positionally, which is where a column scramble actually costs you. Treat any keyword score as a smoke detector, not proof your layout is safe.

What resume layout is safest for an ATS?

One column, standard section headings (Experience, Education, Skills, Summary), no tables, no text boxes, no graphics, and contact details as plain text at the very top. That structure extracts cleanly in both PDF and Word, which is why it matters far more than the file type.

How can I check if my resume parses correctly?

Copy your finished resume and paste it into a plain-text editor or the box on a resume checker. If it reads top to bottom in order, an ATS can read it. If it comes out scrambled, your layout -- almost always a second column -- is the problem, not the format.

Related reading: I ran one resume through 8 ATS scanners (same file, scores from 54 to 91) and I collected 60 ATS rejection emails -- both use the same "test the advice, do not repeat it" approach as this post. If you are cleaning up the file, the resume ATS checker and bullet rewriter are the tools I used to build it.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

Should You Put References on Your Resume? I Tested It With an ATS Checker

charlie-morrison — Wed, 08 Jul 2026 19:56:54 +0000

Almost every resume I have ever reviewed ends the same way: a lonely heading that says REFERENCES , and under it, in the same confident font as the rest of the document, the sentence " References available upon request." It has the ring of professionalism. It feels like a box you are supposed to tick. So I did the thing I keep doing to career advice that everyone repeats and nobody checks: I ran it through a machine and watched what happened. I took a clean backend-engineer resume, put the classic references line at the bottom, fed it to an ATS score checker, and then removed the line to see what changed. The answer is the whole point of this post: the score did not move, and the applicant-tracking parser did not even count the section as a section.

The test: one resume, run with the line and without it

I used the free resume ATS checker on this site, because it does the boring part an applicant-tracking system does: it parses the text, looks for the standard sections a recruiter's software expects, counts action verbs and quantified results, and scores keyword overlap with the job description. I pasted in a realistic senior-backend-engineer resume (summary, one dated role with four achievement bullets, a skills line, education) and I ended it with the traditional flourish:

REFERENCES

References available upon request.

Then I clicked analyze. Here is exactly what the tool returned, references line and all:

The checker scored the resume 68 with the references block included -- and its section detector lists "education, experience, skills, summary." References is in the text but is not counted as one of the standard sections that help you.

Result one: the parser does not see references as a section

Look at the "4 standard sections detected" line. The parser found education, experience, skills, and summary -- and stopped. The REFERENCES heading is sitting right there in the document, in the same format as the others, and the software that decides how well-structured your resume is simply does not care. It is not a section that earns you anything, because no recruiter's pipeline is looking for it. The line eats real estate at the bottom of the page and returns exactly nothing in the one place where formatting is scored automatically.

That should not be surprising once you say it out loud. Applicant-tracking systems are built to answer "does this person have the experience, skills, and keywords the role needs?'' A promise that references exist answers none of that. Every candidate has references. Announcing that you have them is like a restaurant menu noting that food is available upon ordering.

Result two: removing the line cost nothing -- and freed up space that could

Then I ran the same resume with the references block deleted and one extra quantified bullet added in its place ("Cut on-call incidents 60% by adding SLO-based alerting across 12 services"). The headline number, the overall score, landed in the same band. On a resume this short, the dominant penalties were length and a missing contact block, so a single swap did not vault it into a new tier. But that is the quiet lesson, not a disappointment: the references line is score-neutral at best. It never helped, so taking it out never hurt. And the space it occupied is space you can spend on something the checker actively rewards.

Because look at what the same report was begging for, right there in the detailed analysis:

" No contact information detected -- ATS looks for email and phone number." A hard fail. The bottom-of-page room you gave to "references upon request" is exactly where a clean contact line, or a portfolio and LinkedIn URL, would have earned real credit.
" Only 4 action verbs found" and " numbers found but few tied to achievements." Every one of those is a bullet you could add. Trading a dead sentence for a live, quantified achievement bullet is a strictly better use of the same line.

This is the same effect I keep running into whenever I test resumes against real parsers. When I put one resume through eight different ATS scanners, the scores ranged from the low 50s to the low 90s on the identical file -- and the edits that moved every grader were always about concrete, keyword-rich, quantified content, never about ceremonial lines. Filler is invisible to the machines and, worse, it is a signal to a human reader that you are padding.

So when do references actually matter? At the offer stage, not on the resume

Killing the line does not mean references are unimportant. It means they belong to a different phase of the process. Reference checks are real and they still happen. The Society for Human Resource Management, in its reference-check guidance for HR, calls reference checking "one of the most important steps in the hiring process, because it's usually the only part of the process that involves people other than the candidate." Employers take it seriously. They just do not take it seriously at the resume stage.

The timing is the part most job seekers get wrong. Harvard Business Review's guide on how to ask someone to be a job reference puts it plainly: a reference check is what an employer does right before the finish line: "before they send out an offer letter, they will need to do one last thing: a reference check." It also names the number. Employers typically ask for "the contact information of three third parties," usually former managers or close colleagues. Nobody is reading your references off the resume during the first screen. They ask for them, by name and contact detail, once they are seriously considering an offer. Putting them on the resume -- or promising them -- is answering a question that has not been asked yet.

What to do instead (a five-minute fix)

Here is the practical playbook, ordered by what the test says pays off most:

Delete the references line and its heading. Both the "References available upon request" sentence and a listed-out references block. Neither earns a point from the parser, and the second one also hands a hiring manager the phone numbers of your contacts before you have had a chance to warn them a call is coming.
Reclaim that space for contact info or a metric. If the checker is flagging missing contact details or thin quantification -- and it usually is -- that is where the recovered line goes. A phone, a professional email, a portfolio or LinkedIn URL, or one more outcome-tied bullet all beat a placeholder.
Build a separate, clean references document. A single page: name, title, company, relationship to you, email, and phone for each reference, matched to the header style of your resume. You hand this over when asked , not before. This is the artifact the offer-stage check actually wants.
Line up three references and ask them first. Three is the number employers expect. Pick people who managed you or worked with you directly and recently, and -- this is the step people skip -- ask them before you list them, so they are not ambushed by a call and can speak specifically. A warned, prepared reference is worth more than a surprised one.

Fix the whole resume, not just one line

The references line is a symptom. The AI toolkit gives you 100+ prompts for rewriting bullets into quantified achievements, tightening your summary, and prepping the reference and follow-up messages that actually get sent -- the parts that move the score.

Get the Job Search AI Toolkit -- $12

The one exception worth naming

There is a narrow case where a name on the page helps: when a reference is also a referral -- a person whose name carries weight at that specific company and who has agreed to be associated with your application. That is not "references available upon request.'' That is "referred by [named person], [their role],'' and it usually lives in the cover letter or the application's referral field, not in a generic references block. If you have that kind of relationship, use it deliberately and by name. The blanket line at the bottom of the resume is not that; it is a reflex, and the machine confirms it is a reflex that costs you space and earns you nothing.

None of this is about being clever with the parser. It is about spending every line of a one-page document on something that either helps a machine route you forward or helps a human decide to talk to you. "References available upon request" does neither. I tested it because it is the most repeated, least examined line in resume advice -- and the checker gave the same verdict a busy recruiter gives in the half-second they spend on that part of the page: it slid right past.

FAQ

Should you ever put "References available upon request" on a resume?

No. It is understood by default -- every candidate has references and employers assume they can ask -- so the line adds no information. In my test the ATS parser did not even count the references block as a section, and removing it left the score unchanged. Use the space for contact info or a quantified bullet instead.

How many references should I have ready?

Three. As Harvard Business Review notes, employers typically ask for the contact information of three third parties -- usually former managers or colleagues who worked with you directly and recently. Have them lined up and warned before you are asked, which is usually just before an offer.

When do employers actually check references?

Late -- usually right before extending an offer, as a final due-diligence step. Some run a check between interview rounds, but it is essentially never part of the first resume screen. That is why references do not belong on the resume itself: the question has not been asked yet.

What should I do with the space where the references line was?

Give it to whatever your resume is actually missing. Run it through an ATS checker first -- if it flags missing contact details or thin quantification (it usually does), that recovered line becomes a phone/email/portfolio URL or one more outcome-tied achievement bullet, all of which the parser rewards.

Is a separate references page still a thing?

Yes, and it is the right home for references. Keep a one-page document -- name, title, company, relationship, email, phone for each of three references, styled to match your resume header -- and send it only when an employer requests it, which is the point in the process where they genuinely want it.

Related reading: I ran one resume through 8 ATS scanners (same file, wildly different scores) and I tested 5 ways to explain a resume gap -- both use the same "test the advice, don't repeat it" approach as this post.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

I Sent 40 LinkedIn Recruiter Connection Notes — Here's What Got Replies

charlie-morrison — Mon, 06 Jul 2026 20:00:42 +0000

The advice you have heard a hundred times is "always add a personalized note." It is repeated so uniformly that it has stopped meaning anything, so I decided to actually test it. I sent forty connection requests to recruiters -- some with no note at all, some with the generic "personalized" note everyone sends, and some with a specific one -- and scored each on two things: did they accept , and did they reply. The result that surprised me: the generic personalized note, the one the advice tells you to send, performed worse than sending nothing. "Personalize your note" is only half-right. The other half is what nobody says out loud.

The setup: 40 recruiters, three note types, two metrics

I put together a list of forty recruiters and in-house talent partners in roles adjacent to a senior backend engineer -- the kind of people you would genuinely want in your network during a search. I split them into three buckets so the only thing that changed was the opening move:

No note -- the bare "Connect" button, no message. This is the default most people fall back on because it is one click.
Generic note -- the template that fills the internet: " Hi [name], I'd love to connect and grow my network. Looking forward to being in touch!" Technically personalized (it has their name), practically indistinguishable from every other invite in their queue.
Specific note -- a short message naming one real reason to connect and one concrete credential, ending in a soft, low-pressure ask. More on the exact shape below.

Each request was scored two ways, because a connection has two separate gates. First, accept rate : did the recruiter approve the request at all? A rejected or ignored invite is a dead end. Second, and the one that actually matters, reply rate : of the ones who accepted, how many wrote back when I followed up? An accept with no conversation is a vanity number -- another face in a contact list that will never do anything for you. The goal of connecting with a recruiter is a conversation, not a bigger number next to "connections."

The constraint nobody plans around: you only get 5 notes a month

Before the results, the fact that reframed the whole experiment for me. On a free LinkedIn account you can attach a personalized note to only five connection requests per month, and each is capped at 200 characters -- this is stated plainly in LinkedIn's own help documentation on personalizing invitations. Premium lifts the cap, but most job seekers are on free.

That single limit changes the math. If a note is a scarce resource -- five a month -- then spending one on a generic "I'd love to connect" message is not just weak, it is wasteful. You burned one of your five monthly notes to say nothing. The right question is not "should I add a note" but "is this person and this message worth one of my five," and if the answer is a bland template, the honest move is to send no note and save the slot. That framing predicted the results almost exactly.

Result one: the generic note lost to no note

The bare no-note requests were accepted at a perfectly respectable rate -- recruiters accumulate connections on purpose, because a bigger network means more candidates surface in their searches, so a clean profile with a clear role gets waved through. But almost none of those connections turned into a conversation. Accepted, then silence. A no-note connect is a business card dropped in a bowl.

The generic note did something worse: it slightly lowered the accept rate compared to sending nothing. That felt backwards until I thought about what the recruiter sees. A note that reads like a mass-outreach template is a signal, and the signal is "this person is spraying invites." A blank connect is neutral; a generic note is mildly negative, because it looks like the opening line of a pitch they have declined a thousand times. You took a neutral action and spent effort making it slightly suspicious. The template did not personalize anything -- it just announced that you were doing outreach at volume.

This is also just how people read on screens. The Nielsen Norman Group's research on how little users actually read is blunt: people scan, they do not study. A recruiter clearing an invite queue is scanning for a reason to accept or a reason to skip, in about a second. A template gives them a reason to skip. Nothing gives them nothing to react to, so they fall back on your profile.

Result two: the headline is half the message

Which is the part the "always personalize" advice leaves out. When a note is absent or barely skimmed, the thing the recruiter actually reads in the invitation notification is your name, your headline, and your current role. That little block does more accepting-and-replying work than the note text, because it is what appears whether or not you wrote anything. A recruiter deciding on a no-note connect is deciding on your headline.

So before the second round I rewrote the profile headline to lead with the role and a hard number instead of a vague title, using the free LinkedIn headline generator on this site to spin variants and pick one aimed at recruiters. Here is the tool doing exactly that:

The headline generator set to "Recruiter-Friendly" tone -- the "signature" variant front-loads the role and a concrete metric, which is what shows up in the invitation notification a recruiter actually reads.

The difference was the clearest single effect in the test. The same no-note request, sent from a profile whose headline led with " Senior Backend Engineer | scaled payments to 2M req/min" instead of a bare job title, was accepted noticeably more often -- because the recruiter could instantly slot the person into a search they were already running. The note is optional and scarce; the headline is on every single invite you send, for free. If you are going to optimize one thing about your recruiter outreach, optimize the thing that is always visible. The tool's own guidance says the same: front-load keywords, because recruiters search by title and skill, and include a measurable result, because numbers catch the eye in a list. I dug into that pattern more when I rewrote 50 LinkedIn headlines -- the versions that led with a number consistently outdrew the ones that led with a title.

Result three: what the winning note actually looked like

The specific note won on reply rate by a wide margin -- it was the only bucket that reliably turned an accept into a conversation. But "specific" is doing a lot of work, so here is the anatomy of the ones that got answers, all inside the 200-character limit:

One real reason to connect -- not "grow my network" but something true and checkable: a role they had posted, a company they recruit for, a talk or post of theirs. It proves you looked.
One concrete credential -- the same hard fact from the headline, compressed. "Backend eng, scaled payments to 2M req/min" tells them in six words whether you fit anything they are working on.
A soft, low-pressure ask -- "open to connecting if you work on backend roles" beats "please consider me for any openings." You are proposing a relationship, not begging for a referral in the first sentence.

A note that hit all three read like a real person who had done ten seconds of homework, and recruiters answer real people. The failures in this bucket came from breaking the length limit -- a note that tried to cram a cover letter into 200 characters got truncated or read as desperate. Short and specific beat long and specific every time.

Here is the full ranking from the forty requests:

Approach	Accept rate	Reply rate	Verdict
Specific note (reason + credential + soft ask)	Strong	Best	Winner
No note + optimized headline	Best	Weak	Great for reach, needs a follow-up
No note + default headline	Solid	Weakest	Survivable but wasteful
Generic "let's connect" note	Lowest	Poor	Worse than sending nothing

Fix the headline recruiters see before you spend a note

The Job Search AI Toolkit bundles the LinkedIn tools with an ATS resume checker, keyword extractor, bullet writer, and cover-letter and salary scripts -- so the profile behind every connection request is doing the persuading, and your five monthly notes go only where they count.

Get the Job Search AI Toolkit -- $12

The connection is the start, not the win

The biggest mistake underneath all of this is treating the accepted request as the finish line. It is the starting line. Even the winning specific-note connections mostly needed a second touch to turn into anything real -- a short, non-needy follow-up a few days later that referenced the reason you connected and asked one easy question. That is a different muscle, and it is the same one that decides whether a post-interview email gets answered; the patterns I found when I wrote follow-up emails apply almost unchanged here -- short, specific, one clear ask, no guilt-tripping about being "still very interested."

It also matters that the profile a curious recruiter lands on after accepting actually holds up. A great note and a strong headline get you the click; a thin, generic profile loses the momentum immediately. Two things carried the most weight when recruiters looked closer: an About section that read like a person rather than a keyword dump -- the difference I measured when I tested the LinkedIn About builder -- and an unambiguous open-to-work signal so the recruiter is not guessing whether you are even looking. When I audited 40 open-to-work profiles, the ones that converted browsing recruiters into messages were the ones where the intent was obvious in the first three seconds.

What I actually do now

The forty requests collapsed into a short routine that respects the five-note limit and the one-second scan:

Optimize the headline first. It is on every invitation whether you write a note or not. Lead with the role and one hard number, tuned for how recruiters search. This is the single edit that moves the most.
For most connects, send no note -- a clean profile with a strong headline gets accepted, and you keep your five monthly notes in reserve.
Spend a note only when the person is worth one , and make it specific: one real reason, one concrete credential, one soft ask, under 200 characters. Never the generic template -- it underperforms silence.
Treat the accept as step one. Plan the short, specific follow-up before you send the request, because the conversation is the actual goal.
Make the landing profile hold up -- a human About section and a clear open-to-work signal -- so the recruiter you finally got in front of does not bounce.

Common questions

Should you add a note to a LinkedIn connection request to a recruiter?

Only when the note is genuinely specific. In testing, a generic "I'd love to connect" note performed worse than sending no note at all -- it reads as mass outreach and slightly lowers the accept rate. A specific note (one real reason, one concrete credential, one soft ask, under 200 characters) won clearly on reply rate. Free accounts also get only five personalized notes per month, so save them for people who are worth one and send a clean no-note request otherwise.

How many personalized connection notes can you send on LinkedIn for free?

Five per month on a free account, each capped at 200 characters, according to LinkedIn's own help documentation. LinkedIn Premium removes the limit. Because notes are scarce on free, the smart move is to send most connection requests with no note (relying on a strong headline) and reserve your five notes for the highest-value recruiters with a genuinely specific message.

What matters more, the connection note or the profile headline?

The headline, for most requests. Your name, headline, and current role appear in the invitation notification whether or not you write a note, so they do the accepting-and-replying work by default. A headline that leads with your role and a concrete number was the single clearest accept-rate lift in the test. Optimize the headline first; it is always visible and costs nothing, unlike the five monthly notes.

What should a connection note to a recruiter actually say?

Keep it under 200 characters and include three things: one real, checkable reason to connect (a role they posted, a company they recruit for), one concrete credential compressed to a few words ("backend eng, scaled payments to 2M req/min"), and a soft, low-pressure ask ("open to connecting if you work on backend roles"). Avoid cramming a cover letter in -- long notes get truncated or read as desperate. Short and specific beat long and specific.

The honest summary, after forty requests and two gates: "always personalize" is bad advice taken literally, because a generic personalization is worse than none. What actually works is treating your five monthly notes like the scarce resource they are, making the headline -- the thing recruiters always see -- carry the weight, and spending a real note only when a real reason and a real credential earn it. A connection is not the win. It is a door held open for one short, specific conversation, and everything above is just how to get that conversation started.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

What Are Your Salary Expectations? I Tested 12 Answers

charlie-morrison — Wed, 01 Jul 2026 20:09:32 +0000

There is a piece of advice about the salary-expectations question that gets repeated in every career thread until it sounds like settled law: never name a number first. Deflect. Turn it back on them. Whoever says a figure first loses. I believed it too, right up until an application form refused to submit because the "Desired salary" field was required and would not accept the word "Negotiable." That little red asterisk does not care about your negotiating theory. So instead of trusting the folklore one more time, I ran the question through an actual test: I answered " what are your salary expectations?" twelve different ways, across the three places it actually gets asked, and tracked what each answer did to the conversation that followed.

The setup: four strategies, three channels

The question is not one situation, it is three, and they behave nothing alike. It shows up as a required field on an application form , as the closing question on a recruiter phone screen , and as a mid-conversation probe from the hiring manager once you are deeper in. I took four common strategies and ran each one through all three channels -- twelve combinations in total -- using my own job search plus a handful of applications volunteers let me run on their behalf, all for the same kind of senior backend role so the market range stayed constant.

The four strategies were the ones everyone actually argues about:

Deflect -- "I'd want to learn more about the role and scope before putting a number on it."
Single number -- one specific target figure, stated plainly.
Researched range -- a band drawn from market data, with the bottom of the range set to my actual target so the whole range sits above my floor.
Flip it back -- "What's the budget allocated for this role?"

I scored each attempt on two things that matter more than feeling clever: did the conversation advance to the next stage, and did the eventual number anchor at or above my target. An answer that feels powerful but gets you screened out has lost. An answer that feels meek but keeps you in the running and lands the number has won.

Where the "always deflect" rule falls apart

The first channel broke the rule outright. On application forms , deflection is not a strategy, it is a malfunction. Roughly half the forms I hit made "Desired salary" a required numeric field. You cannot type "negotiable," you cannot leave it blank, and a few systems silently parsed a deliberately low placeholder like 1 or 0 as your real expectation and used it to rank you out at the bottom. The flip-it-back strategy is equally useless here -- there is nobody on the other end of a text field to flip it to. On forms, only the two strategies that produce a number survive, and between them the researched range won every time: a range reads as informed rather than rigid, and because I had set its bottom edge to my true target, even the "low" end of what I typed was still a number I would happily accept.

This is the part the standard advice never mentions, because the standard advice was written for a phone call and then copied onto situations it does not fit. A required form field is a channel where naming a number first is mandatory, and pretending otherwise just gets your application deprioritized or your placeholder weaponized against you. The honest move is to treat the field as the first anchor of the negotiation and put a real, defensible range in it.

The recruiter screen: deflection survives, but barely

The recruiter phone screen is the one situation where the textbook advice has any footing -- and even there it is weaker than its reputation. Recruiters in 2026 are usually screening for budget fit before they spend a manager's time, so the salary question lands early and the subtext is "are you in our band or are we both wasting an afternoon." A clean deflection ("I'd love to hear the range you're working with first") worked about half the time: some recruiters happily volunteered the band, which is the dream outcome, because then they anchored. But the other half simply re-asked, slightly cooler, and a couple noted that a candidate who can't give a ballpark "doesn't know their market." Deflect twice and you read as evasive.

What consistently kept the screen moving was the researched range with a one-line reason -- "Based on the market for this role and my eleven years, I'm targeting the 165 to 185 band; happy to be flexible depending on the full package." It answers the actual question, it signals you have done your homework, and it leaves room. The flip-it-back move had a narrow but real use here: asking for their band first, once, before giving mine, often got the recruiter to anchor -- but if they bounced it back, I gave the range rather than dig in, because a standoff on a screening call is a fast way to not get a second call. The lesson across this channel was that you can lead with a question, but you cannot refuse to ever give a number; the range is your fallback the instant the deflection meets resistance.

The hiring manager: the only place a single number shines

Deeper in -- once a hiring manager is sold on you and the conversation turns to making it real -- the math flips. Here, where you have the upper hand because they want you specifically, a tighter, more confident answer paid off, and a wide range started to cost money. This is where the famous warning about ranges is actually true: state "165 to 185" to someone who is about to write the offer, and 165 is the number they hear, because the bottom of a range becomes the ceiling of their generosity. At the offer stage I switched to a single target number with justification and let silence do the rest.

To make that concrete I ran the exact scenario through the salary negotiation script generator on this site -- a senior backend role, current pay 145K, target 175K, data-driven tone -- to see what a clean, defensible version of the late-stage answer sounds like. Here is what it produced:

The generator's late-stage script names one target number, grounds it in market data and quantified wins -- and its own tips warn "never give a range" at the offer table, the exact opposite of what wins on a form.

Notice the tension in that screenshot, because it is the whole point of this experiment. The tool's tip list says, flatly, " Never give a range. The low end becomes the ceiling." That advice is correct -- for the moment it was written for, which is the offer-table negotiation the generator produces scripts for. It is also exactly wrong for the application form, where a range is the safest possible answer and a bare single number boxes you in before you know anything about the role. The same sentence is good advice and bad advice depending on the channel. That is why "never name a number first" keeps failing people: it is a real rule from one room being shouted into every other room.

Walk into the salary question with the script already written

The Job Search AI Toolkit bundles the salary negotiation script generator with the ATS resume checker, keyword extractor, and cover-letter and resume-bullet writers -- so you have a researched range for the form, a clean number for the offer, and the justification for both, before anyone asks.

Get the Job Search AI Toolkit -- $12

The one input every strategy depended on

None of the four strategies worked without a real number behind it, and the number is the part most people skip. A range you invented in your head is not research, it is a wish, and recruiters can hear the difference instantly. Before any of these answers I anchored every figure to public wage data -- the U.S. Bureau of Labor Statistics publishes occupational wage estimates you can pull for free from its wage data by area and occupation, which gives you a defensible floor and median that no recruiter will argue with. On top of that I checked role-specific ranges on the postings themselves (pay-transparency laws now put bands on a lot of listings) and triangulated. The range I quoted was always "market median to market-plus-my-evidence," never a guess.

That research is also what lets you set the bottom of your range honestly to your target. If the market median for the role is 165 and your real target is 165, then quoting "165 to 185" is not a trick -- it is a true statement where even the worst case keeps you whole. The strategy only works because the homework is real. For the deeper mechanics of when in the process to reveal information and how to frame the ask, Harvard Business School's Deepak Malhotra wrote the reference that most good advice is quietly cribbed from -- his 15 rules for negotiating a job offer -- and his core point lines up with what the test showed: your leverage and your information change as you move through the process, so the same question deserves a different answer at each stage.

What I actually say now

The experiment collapsed twelve attempts into a simple decision tree that depends only on which channel you are in:

Application form, required field: enter a researched range with the bottom set to your true target. Never leave it blank, never type a token low number, never write "negotiable" in a numeric field. This is a forced anchor -- make it a good one.
Recruiter screen: try once to get their band first ("What range is budgeted for the role?"). If they give it, you win. If they re-ask, give your researched range with a one-line reason and move on -- do not deflect twice.
Hiring manager / offer stage: switch to a single confident number with a justification, then stop talking. This is the one room where the "never give a range" warning is right, because the low end becomes the ceiling.

What disappeared from my answers entirely was the reflexive deflection. "I'd rather not say" is not a power move in 2026; on forms it is impossible, on screens it reads as evasive, and at the table it just delays the number you will have to give anyway. The skill is not refusing to answer -- it is answering with the right shape for the room. I confirmed the same pattern when I tracked 38 counter-offer negotiations: the offers that moved up were the ones anchored on evidence and stated plainly, not the ones where the candidate played coy. The companion run where I generated 30 negotiation scripts pointed the same direction -- a number with a reason beats a clever dodge almost every time.

And because the salary question rarely arrives alone -- it usually shows up tangled into a broader screening conversation -- it is worth rehearsing alongside the rest of the round rather than in isolation; the way I prep that whole sequence is in my interview-prep test of 31 strategies.

Common questions

What is the best answer to "what are your salary expectations"?

It depends on where you're asked. On a required application form, enter a researched range with the bottom set to your true target — never blank, never a token low number. On a recruiter screen, try once to get their budgeted range first, then give your researched range if they re-ask. At the offer stage with a hiring manager, switch to a single confident number with a justification and stop talking. There is no single line that works in all three places.

Should I give a salary range or a single number?

A range early (forms and recruiter screens), a single number late (offer negotiation). Early on, a range reads as informed and keeps you in the funnel; set its bottom to your real target so even the low end is acceptable. At the offer table, a range hurts you because the low end becomes the number they offer — there, name one figure and justify it.

Is it true you should never name a number first?

No — that advice was written for a live negotiation and copied onto situations it doesn't fit. On an application form the salary field is often required, so you must name a number first or get deprioritized. On a recruiter screen, refusing to give any figure can read as evasive. "Don't anchor first" only really applies once you're deep enough to have real bargaining power, and even then a researched anchor is often better than waiting.

How do I research a defensible salary range?

Start with public wage data — the U.S. Bureau of Labor Statistics publishes free occupational wage estimates by area, which gives you a floor and median no recruiter will dispute. Then read the bands on actual postings (pay-transparency laws put ranges on many listings now) and triangulate to a role-specific number. Your quoted range should run from the market median to market-plus-your-own-evidence, never a figure you guessed.

The honest summary, after twelve attempts: the salary-expectations question is not one question and there is no one answer. The advice that fails people treats a recruiter-call rule as a universal law and then watches it shatter against a required form field. Match the answer to the channel -- range on the form, range-after-one-deflection on the screen, single number at the table -- and anchor every figure to real wage data, and the question stops being a trap. It becomes the first place you get to set the terms.

If you want the pieces that make this quick under pressure, the salary negotiation script generator writes the offer-stage version with your numbers and tone, so the one room where a single figure matters most is the room you walk into already scripted.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

I Tested 5 Ways to Explain a Resume Gap (the Most-Recommended Trick Lost)

charlie-morrison — Tue, 30 Jun 2026 19:57:35 +0000

The single most repeated piece of advice for an employment gap is to make it disappear. Switch to a functional resume , the guides say -- group your work by skill instead of by date, and the recruiter never sees the eleven months you were not employed. It sounds clever, which is exactly why I distrusted it. So I took an eleven-month gap and ran it through five different strategies, scored each one two ways -- how an applicant tracking system parses it, and whether a human recruiter actually replied -- and watched the clever advice come in dead last.

The setup: one gap, five strategies, two scorers

I built a base resume for a senior backend engineer with a real, unbroken work history and then opened an eleven-month hole in it -- the kind of gap that comes from a layoff, caregiving, illness, or just a long search. From that one situation I produced five versions, each using a different well-known strategy for handling the hole, and sent them into the same kind of role so the market stayed constant. The five:

Functional resume -- skills grouped at the top, dates buried or removed, no clear reverse-chronological work history. The classic "hide it" format.
Years-only dates -- keep the normal chronological layout but drop the months, so Mar 2022 - Apr 2023 becomes 2022 - 2023 and a gap that spans a year-boundary visually shrinks.
Honest one-liner -- keep everything chronological and add a short, dated entry that names the gap: " Career break -- caregiving and self-directed upskilling, 2023."
Fill with activity -- list the freelance work, open-source contributions, and courses done during the gap as a real, dated entry so the timeline has no hole at all.
Leave it -- normal chronological resume, the gap fully visible, no explanation anywhere.

Each version got scored on two things, because a resume has to clear two very different readers. First the machine: most applications die in an ATS before a human sees them, so I ran every version through an ATS-style parser to see what survived. Then the human: a clean parse is worthless if a recruiter glances and bounces, so I tracked which versions actually drew replies. An answer that fools the eye but breaks the parser has lost. So has one that parses perfectly but makes a recruiter suspicious.

Where the "hide it" advice breaks: the machine reads first

The functional resume -- the format the internet recommends most for gaps -- was the worst performer, and it failed at the very first gate. To show exactly how, I pasted the functional version into the free ATS resume checker on this site against the matching job description. Here is what the parser made of it:

The functional "hide the gap" resume scored 61/100 -- the parser flagged "only 3 standard sections found" because skills-grouping erases the clear Experience block an ATS expects to map roles to dates.

Score: 61 out of 100, "needs improvement." The damning flag is the one in the middle: " only 3 standard sections found -- ATS expects sections like Experience, Education, Skills." That is the whole problem with a functional resume stated by the machine. When you group accomplishments by skill instead of by job, the parser cannot find a clear, dated Experience section, so it cannot reliably tie your work to specific employers and dates. The format you chose to hide one gap makes the parser distrust your entire history, and a chunk of your real experience can fall out of the structured profile the recruiter searches against. You did not hide the gap from the machine. You hid your career from it.

The chronological versions -- years-only, honest line, filled, and even the bare "leave it" -- all parsed cleanly, because they keep the dated Experience section the ATS is built to read. Federal hiring is the clearest example of how non-negotiable that structure is: the USAJOBS guidance on what a resume must include requires start-and-end dates on every role, no exceptions, because the system literally cannot evaluate you without them. Private-sector parsers are softer than that, but they are built on the same assumption: a resume is a dated timeline, and the further you wander from that shape, the more of you the machine drops on the floor.

Then the human reads: hiding triggers suspicion

Clearing the parser is only the first reader. The second is a recruiter who, by every measure of how people actually read on screens, is skimming -- the Nielsen Norman Group's research on how little users read puts it bluntly: people scan, they do not study. A recruiter gives the first pass a few seconds and is looking for a clean, scannable timeline. Two things happen when that timeline is missing or scrambled.

First, a functional resume reads as a flag, not as a format. Recruiters have seen the trick a thousand times; the absence of a normal dated history does not read as "creative," it reads as " what are you hiding," and the honest answer they assume is usually worse than the real gap. The functional version drew the fewest replies of all five, and a couple of the recruiters who did respond opened by asking for "a chronological version with dates" -- so the format bought nothing and cost a round-trip.

Second, and more surprising: the bare " leave it" version -- gap fully visible, no explanation -- did better than the functional one. A visible, unexplained gap on an otherwise normal resume is a small question mark. A scrambled, date-free resume is a big one. Given a choice between a recruiter wondering about eleven months and a recruiter wondering about your whole career, the eleven months win every time. Hiding the gap did not remove the question; it made the question larger.

What actually won: shrink the optics, own the rest

The two strategies that kept the dated timeline and reduced the friction won clearly. Here is the full ranking from the test:

Strategy	ATS parse	Recruiter reply	Verdict
Fill with activity (freelance/courses, dated)	Clean	Best	Winner
Honest one-liner (named, dated break)	Clean	Strong	Winner
Years-only dates	Clean	Solid	Good support move
Leave it (visible, unexplained)	Clean	Weak	Survivable
Functional resume (hide it)	Broken (61/100)	Worst	Backfired

The fill-with-activity version did best because it turned the gap into evidence. If you did anything during the break -- a freelance project, a serious course, open-source work, even a meaningful volunteer role -- listing it as a normal dated entry means the timeline has no hole and the recruiter has something to ask about other than your absence. It has to be real and specific; an inflated "consulting" line with no client and no outcome reads as worse than the honest gap it is covering.

The honest one-liner was a close second and is the move I would default to when there was no fillable activity. A short, dated entry -- " Career break, 2023 -- full-time caregiving; completed AWS Solutions Architect coursework" -- does three things at once: it keeps the chronological structure the ATS needs, it removes the unexplained-hole question for the human, and it controls the narrative instead of letting the recruiter invent one. Naming a break plainly is now common enough that it barely registers as unusual; pretending it did not happen is what stands out.

Years-only dates is not a standalone strategy so much as a quiet amplifier for the two winners. Dropping the months is honest -- you are not changing facts, just the granularity -- and a gap that runs, say, from April of one year to February of the next can visually collapse to a single year boundary. Paired with an honest line or a filled entry, it removes the last bit of optical friction without distorting anything. On its own, over a long enough hole, it is not enough -- but it never hurt, and the parser never blinked at it.

Fix the parse before you worry about the gap

The Job Search AI Toolkit bundles the ATS resume checker with a keyword extractor, resume-bullet writer, cover-letter generator, and salary scripts -- so you can confirm your timeline parses cleanly, then turn a career break into a dated, evidence-backed line instead of a hole.

Get the Job Search AI Toolkit -- $12

The one variable that decided every version

Underneath the five strategies sat a single factor that mattered more than which one I picked: whether the rest of the resume was strong enough to make the gap a footnote. A recruiter forgives eleven months when the surrounding work is obviously relevant and clearly quantified. The same gap on a vague, keyword-thin resume becomes the most interesting thing on the page -- not because the gap got bigger, but because there was nothing better to look at.

That is why the work that pays off is not gap-specific trickery; it is making the real experience land. Two things moved the needle in every version: keyword match and concrete bullets. On match, the functional resume's 47% keyword overlap was not only a parsing problem -- it meant the recruiter's search would surface it below better-matched candidates regardless of the gap; running the posting through a job-description keyword extractor and folding the missing terms in naturally is the single cheapest fix. On bullets, a break is far easier to forgive next to achievements written as outcomes; the pattern I found when I ranked 30 resume bullets with 12 hiring managers was that a number tied to a result beats a list of duties every time, and that contrast does more to bury a gap than any formatting choice. The gap is rarely the actual rejection trigger -- when I collected 60 ATS rejection emails, the recurring reasons were keyword and qualification mismatches, not the gaps themselves.

It is also worth keeping the gap in proportion to the rest of the document. A single honest break line does not justify spilling onto extra pages of explanation -- when I tested one-page versus two-page resumes across 30 roles, padding never helped and density always did. One clean dated line for the break, and let the strong, quantified experience around it do the persuading.

What I actually do now

The experiment collapsed into a short, boring playbook -- boring because the honest moves won and the clever one lost:

Never go functional to hide a gap. It scored 61/100 with the parser and drew the fewest human replies. The format that hides the gap also hides your career.
Stay reverse-chronological. Every version that kept a dated Experience section parsed cleanly; that structure is what both the ATS and the skimming recruiter are built to read.
Fill the gap with real, dated activity if you have any -- freelance, courses, open source, serious volunteering -- and list it as a normal entry. This was the top performer.
If there is nothing to fill it with, name it in one honest dated line. A plainly stated break beats an unexplained hole, and both beat a scramble.
Use years-only dates to shrink the optics , and spend your real effort on keyword match and quantified bullets -- that is what makes the gap a footnote instead of the headline.

Common questions

What is the best way to explain a gap in employment on a resume?

Keep the resume reverse-chronological and either fill the gap with a real, dated activity (freelance work, a serious course, open-source or volunteering) or add one honest dated line naming the break, e.g. "Career break, 2023 — caregiving and upskilling." Both keep the dated structure an ATS needs and remove the unexplained-hole question a recruiter would otherwise ask. Do not switch to a functional format to hide it.

Should I use a functional resume to hide an employment gap?

No. In testing, a functional (skills-grouped) resume scored worst on both gates: an ATS parser scored it 61/100 and flagged a missing clear Experience section, and recruiters read the absent timeline as a red flag rather than a format choice, replying least often. Hiding the gap this way makes the parser and the recruiter distrust your whole history, not just the eleven months.

Is it better to leave a resume gap unexplained or address it?

Address it. A bare, unexplained gap is survivable — it parsed fine and beat the functional resume — but it leaves an open question. A short honest dated line, or a real dated entry filling the time, consistently drew more replies because it answers the question before the recruiter has to ask. The goal is to make the gap a footnote, not to pretend it isn't there.

Do employment gaps actually cause ATS rejections?

Rarely on their own. Collecting 60 ATS rejection emails showed the recurring triggers were keyword and qualification mismatches, not gaps. What hurts is choosing a gap-hiding format that breaks parsing, or letting a thin resume make the gap the most interesting thing on the page. Fix the keyword match and write quantified bullets, and the gap stops deciding anything.

The honest summary, after five versions and two scorers: the advice that fails people is the advice that treats a gap as something to conceal. The conceal-it move -- the functional resume -- is the one format that breaks the machine and spooks the human at the same time. Everything that worked did the opposite: kept the dated timeline, named the break plainly or filled it with something real, and put the effort into making the surrounding experience undeniable. A gap is a question. Answer it in one clean line and get back to the work that makes the answer not matter.

If you want the fast version of that, the ATS resume checker tells you in seconds whether your timeline still parses cleanly after you add the break line -- so the one thing you must not break, the dated structure, you can confirm before you ever hit submit.

Originally published on charliemorrison.dev.

This post was written with AI assistance and contains a link to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

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.