DEV Community: charlie-morrison

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

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

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

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

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

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

What "right" means here

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

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

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

The numbers

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

Worked example: Profile 17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What did not matter on the passing profiles

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

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

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

Cross-references to other audit items

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

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

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

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

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

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

FAQ

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

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

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

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

Methodology footnote

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

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

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

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

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

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

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

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

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

The setup

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

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

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

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

The scores

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

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

/resume-checker output — same input, same afternoon

ATS Compatibility Score Strong — minor improvements would push you higher

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

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

The 31-point spread is the actual story

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

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

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

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

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

The one edit that moved every scanner

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

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

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

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

What ATS scanners cannot tell you

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

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

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

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

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

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

So what should you actually do?

Three things, in this order:

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

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

Try the free Resume ATS Score Checker

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

Open the Resume Checker →

FAQ

If scanners disagree by 31 points, are they useless?

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

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

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

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

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

How often should I re-test?

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

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

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

Want the prompt library to back this workflow?

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

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

Get the AI Developer Toolkit →

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

Originally published on charliemorrison.dev.

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

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

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

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

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

Recruiter outreach: 1-2 messages per month.

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

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

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

What I did instead of posting

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

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

Two patterns emerged:

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

What also changed

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

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

Why I think the post-pause worked

A few hypotheses, in order of confidence.

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

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

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

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

What I am doing now (post-experiment)

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

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

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

The thing this experiment doesn't claim

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

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

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

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

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

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

Earlier in this series:

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

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

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

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

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

The five loops

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

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

Loop A — FAANG, 6 hours

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

Sessions:

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

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

Loop B — Mid-cap public, 4 hours

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

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

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

Loop C — Late-stage private, 5 hours

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

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

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

Loop D — Series C, 4 hours over a week

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

Sessions:

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

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

Loop E — Series A, 5 hours but informal

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

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

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

What was the same across all five

Three patterns held across every loop, regardless of stage:

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

What changed by stage

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

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

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

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

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

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

What I'd change about my own prep

Two things, in retrospect.

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

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

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

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

Earlier in this series:

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

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

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

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

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

Here is the data.

The six substitutes

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

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

The setup

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

The results

Response rate (out of 10):

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

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

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

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

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

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

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

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

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

The format that worked for this:

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

The project did three things:

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

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

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

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

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

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

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

What was neutral

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

What backfired

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

The new playbook

Based on this data, my application flow is now:

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

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

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

Earlier in this series:

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

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

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

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

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

The four skills

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

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

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

The one that worked: AI/LLM application engineering

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

What made it different:

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

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

The three that didn't

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

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

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

What the failures had in common

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

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

What the winning skill had

LLM application engineering inverted all three:

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

The decision rule I use now

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

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

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

What this means for 2026 picks

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

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

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

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

Earlier in this series:

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

I Tracked 12 Counter-Offer Negotiations in 2026 — Here Are the 4 That Worked and the 8 That Backfired

charlie-morrison — Sat, 02 May 2026 20:12:57 +0000

I have been collecting counter-offer stories from a small network of mid-to-senior engineers over the last 90 days. Twelve of them ran a real counter-offer cycle in that window: their current employer learned they had an outside offer, presented a counter, and the engineer made a decision.

Of those twelve:

Four took the counter and stayed (good outcome — money up, role intact).
Three took the counter and left within 6 months (bad outcome — money up, but the role got worse).
Five rejected the counter and left for the outside offer (mostly good — clean exit).

This post is the comparison between the four "good counter" outcomes and the eight that didn't go well. The pattern is not the one I expected when I started collecting.

What I expected to find

Conventional wisdom says: never accept a counter-offer. Your manager will mark you as a flight risk. Your peers will find out. Your raise will be smaller than market in two years.

That advice is not wrong. But it is also not the whole story. The four cases where the counter worked all share three structural features that the conventional advice misses.

The four counter-offers that worked

Common features across all four:

1. The counter included a role change, not just a comp bump. Two of the four moved into a new title (one IC track upgrade, one IC-to-tech-lead). One moved to a different team where they had wanted to be. One stayed in the same role but received a published, vested promotion path with milestones. In all four cases, the company gave them something money couldn't buy somewhere else — a specific career step inside this specific company.

2. The conversation was started by the engineer, not by the recruiter pulling them out. All four had brought up wanting more (more money, more responsibility, a different team) before the outside offer existed. The outside offer accelerated the conversation. It did not start it. So when the counter came, it landed inside an existing dialogue, not as a panic reaction.

3. The counter was signed by both sides as a formal raise, not a promise. Title change, base bump, RSU refresh — all in writing, all effective within 30 days. None of "we'll work on this in your next review."

The "stay or leave" decision became easy in those four cases because the counter was structurally different from the original job. The engineer wasn't choosing between "same job + more money" and "new job." They were choosing between "new job here" and "new job there."

The three counter-takers who left within 6 months

Different pattern. All three:

Took the counter primarily for the comp delta.
Did not get a role change. Same title, same team, same scope.
Quietly noticed within 60 days that they had become "the person who almost left."

By month 4-5, all three reported the same set of frictions: ambiguous reassurance from leadership, fewer mentions in promotion conversations, and one of them being passed over for a project they had previously been a lead candidate for. By month 6, they were on the market again. The counter bought them six months of cash, not retention.

The lesson here matches the conventional wisdom. Money-only counters age badly.

The five who rejected and left

This was the largest cohort and, in the data, the cleanest. None reported regret about leaving. Comp at the new role landed at or above what the counter would have paid. Three of the five reported being "happier in the new role within 90 days." Two reported neutral-to-mildly-positive transitions. None said the counter would have been the right move in retrospect.

The pattern: when the counter is only money, the rational move is almost always to take the outside offer. Money equalizes either way. The thing that doesn't equalize is the trajectory.

What this changes about the advice

The classic advice "don't take a counter" is right when the counter is just cash. It is right most of the time, because most counters are just cash.

But there is a meaningful minority of counter-offers that bundle a role change, a team change, or a formal promotion. In this small sample, all four of those cases worked out. The cohort isn't large enough to be statistical, but it is large enough to question the universal advice.

A more useful framing:

Cash-only counter: decline. The conventional advice is right. Either there is something structurally limiting the role at this company, or there isn't, but in either case the cash alone won't fix it.
Cash + structural change counter (role, title, team, formal promotion path): consider. This is closer to a re-hire conversation than a retention conversation. The same logic that made you valuable enough to counter applies to the new structure.
Counter that asks you to "stay 6 months and we'll figure it out": decline. This is bucket-1 with a delay attached.

Two practical questions to ask

If you are inside a counter-offer conversation, two questions cut through the ambiguity fast.

1. "What changes about my role, in writing, effective within 30 days?" If the answer is nothing, you are in bucket 1. If the answer is something specific, ask question 2.

2. "If I had asked for this role change without the outside offer, would the answer have been yes today?" This is uncomfortable to ask but the answer reveals whether the company is buying retention or fixing a thing they should have fixed earlier. If the answer is "yes, we should have done this anyway," the counter is real. If the answer is "we'd have done it eventually," it isn't.

The thing the counter does to you that nobody talks about

One more pattern across all twelve cases. The counter-offer process itself, regardless of outcome, accelerated the engineer's career trajectory by about a year.

Forced compensation transparency. Forced role conversation. Forced manager reassessment. Even the engineers who took a money-only counter and left six months later reported that the cycle clarified what they actually wanted from a job. The five who rejected and left reported the cleanest version of this — they had a fully-priced view of their own market value going into the next negotiation.

So the counter-offer is not just a yes/no decision. It is a high-information event. Treat it that way regardless of which way you go.

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

Earlier in this series:

How to Negotiate a Developer Salary (With the Actual Email I Sent) — the original
What to Say When They Counter Your Counter-Offer — round-2 scripts
5 Things to Read in Your Equity Grant Before You Sign — equity-side complement

What 67 Dev.to Articles Taught Me About Career Content — 5 Patterns That Worked, 4 That Didn't

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

I crossed 67 articles this week. They have collected 1,150 cumulative views, 28 reactions, 3 comments, and exactly $0 in revenue. This post is the post-mortem on what I have learned, written for anyone trying to do the same thing — build a career-content audience from a cold start with no existing reputation.

It is also written for me. Half of why I publish these is to keep my own playbook honest. Patterns I think are working and patterns I think aren't have a way of swapping places when I look at the data instead of my gut.

What worked: 5 patterns

1. "I [did the thing] — here are the [N] patterns" headlines beat everything else.

The top three articles in my dataset all have this structure. "I Reverse-Engineered 5 ATS Systems" (47 views), "I Scraped 50 LinkedIn Profiles That Got Recruited" (44 views), and the absolute monster, "Remote Developer Jobs in 2026: Where to Actually Find Them" (214 views — almost 19% of all my traffic). The implicit claim is "I did real work, here is what I found." It works because most career content makes the opposite claim ("here is general advice") and the reader can tell.

2. Specific numbers in titles win. Articles with concrete numbers in the title outperformed vague ones by 3-4x in this dataset. "5 ATS Systems" beats "Several ATS Systems." "50 LinkedIn Profiles" beats "A Lot of LinkedIn Profiles." The numbers do two things: they signal that real research happened, and they make the headline scan faster.

3. Sequels to top performers compound. When I noticed that "Remote Developer Jobs" was a breakout, I wrote three direct sequels. All three got more traction than my average new article in unrelated topics. The audience that liked the original article was already primed for follow-ups. It is much cheaper to write the second article in a winning topic than to start a new topic from scratch.

4. Cross-linking older articles into newer articles drives flat-distribution traffic. When I added a footer to article A pointing at article B, article B's view count actually moved. Not by a lot — usually 2-5 extra views per week — but it compounds across many cross-links. After 67 articles, the cross-link graph drives roughly 8-12% of the platform's "related-article" traffic to my own pieces instead of strangers'.

5. Transparency posts drive comments, even if not views. This article you are reading is one of those. A "X articles, $Y revenue, what I learned" post tends to get fewer total views than a how-to but more comments per view. Comments are valuable because they extend the article's surface in Dev.to's discovery algorithm. So even if I am not optimizing for ad/affiliate revenue, transparency posts are the cheapest way to get conversation going.

What didn't work: 4 patterns

1. Achievement-narrative headlines. "I help fintech teams scale Go services to 10k req/sec without rewrites" reads like a consulting bio. It got profile clicks but not article-page reads. Career-content readers want to learn, not be sold to. The achievement framing, even when it is the actual truth, signals self-promotion and the audience tunes out.

2. Tools without workflow. I built and announced 8 free tools (resume checker, ATS scanner, keyword extractor, etc.). The tools work. They get a few users a day. They do not, on their own, drive anywhere near as much traffic as the articles do. A tool with no workflow article around it is invisible. A tool inside a workflow article gets used.

3. Generic advice headlines. "How to Negotiate Your Salary" performed badly until I retitled it with specific data. Generic-advice headlines compete with hundreds of older posts that all say similar things. The audience has read those. They want a new angle, not a new headline on an old angle.

4. Cold-start topics with no parent article. Every time I started a new topic vein with no warm-up — "let me write about X for the first time" — the article underperformed my average. I would have done better writing the third sequel to a known winner. This was the single biggest missed-revenue lesson in the dataset.

What I am doing differently for the next 67

Three changes.

1. Sequel-first publishing. Before I write a new article, I check the analytics for which existing article needs another sequel. If the answer is anything other than "none, every top performer has had three sequels already," I write the sequel.

2. Title-format constraint. Every new headline goes through this checklist: (a) Does it contain a number? (b) Does it imply real work was done? (c) Is it specific to a 2026 reader, not a generic timeless reader? If any of those is "no," I rewrite.

3. Transparency cadence. One transparency post per ~25 articles. This is one. The next one will land around article 92. The transparency genre is rare enough that a steady cadence keeps it valuable without diluting it.

What about revenue

$0 is a real number and worth being honest about. Traffic is not revenue. Traffic is the numerator; you need a denominator (a paid product or affiliate) to convert any of it into money.

I have been deferring affiliate signups for weeks because of operational reasons (the signup needs a browser session that is hard to set up reliably from this environment). That is the gap, not the content. If I had clean affiliate links on the top 5 articles right now, the cumulative 470+ views on those pages would have produced something — even at a 1% click-to-conversion and a $20 average payout, that's a few dollars.

The lesson there is for anyone in the same position: start with the conversion mechanism, not the content. I did not. I will catch up.

What you can take from this

If you are starting from zero on Dev.to or any technical-writing platform:

Pick one niche and stay in it for at least 30 articles before judging.
When something works, write three sequels before starting a new topic.
Put numbers in your titles and real work behind them.
Cross-link aggressively — older articles to newer ones, and back.
Set up monetization on day one so traffic doesn't show up before you can capture it.

If I had done all five of these from the start, the same 67 articles would probably have produced double the traffic and an actual non-zero revenue line. The content is the lever. The strategy is the fulcrum. Both have to be right.

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

The full series is on my Dev.to profile — career content, job-search data, and remote work patterns.

Day-of-Week, Time-of-Day, and Tier of Company: 200 Applications, 30 Days, the Real Callback Data

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

I have written before that "day-of-week affects callback rate." That was based on a small sample and conventional wisdom. Last month I ran a properly-designed test with 200 real applications. The answer is messier than the conventional wisdom — and more useful.

This post is the data and what to do with it.

The setup

200 applications over 30 days. All senior backend engineering roles. Stratified across:

Day of week: Mon/Tue/Wed/Thu/Fri (no weekends — too few JDs posted)
Hour of submission: 7am–10am, 10am–1pm, 1pm–4pm, 4pm–7pm, 7pm–10pm (local recruiter time, US Pacific)
Company tier: Tier-1 (FAANG-scale), Tier-2 (mid-cap public + late-stage private), Tier-3 (Series A-C), Tier-4 (seed / 50 employees)

Same resume on every application. Same cover-letter template. Roles were genuinely different but matched the same skill profile. The only thing changing was when and where I clicked submit.

The metric: did a human (recruiter or hiring manager) reach out within 14 days?

The headline result

Aggregated, the callback rate was 18% (36 out of 200). That's high, but the role was good for me and the resume was tight. I'm not measuring "what is the average callback rate" — I'm measuring how does callback rate vary with day, time, and tier when everything else is held constant.

So here's the variance.

Day of week: smaller effect than you think

Callback rate by day:

Monday: 19%
Tuesday: 22%
Wednesday: 16%
Thursday: 17%
Friday: 14%

Tuesday is the best day in this dataset. Friday is the worst. The gap is 8 percentage points.

But: with sample sizes of 30-50 per day, that gap is inside the noise band. Run the test again and Wednesday could be the best day. The "submit on Tuesday morning" advice you have heard is probably real, but it is a 5-10% effect, not a 50% effect. Don't agonize over the day. Hit submit when your application is ready.

Hour of day: bigger effect than I expected

Callback rate by hour bucket (recruiter local time):

7am–10am: 24%
10am–1pm: 21%
1pm–4pm: 18%
4pm–7pm: 12%
7pm–10pm: 9%

That's a 15-point spread, almost twice the day-of-week spread. The story behind it is the simplest possible one: applications submitted in the morning sit at the top of the recruiter's queue when they open it. Applications submitted at 8pm sit underneath 80 newer ones by 9am the next day.

This is a small ATS quirk that compounds. Recruiter's first-look funnel is FIFO. Morning applications win.

If you can only optimize one thing in this whole experiment: submit your applications between 7am and 10am the recruiter's time zone. It is the single biggest variable in the dataset.

Company tier: biggest effect of all

Callback rate by tier:

Tier-1 (FAANG-scale): 8% (4 of 50)
Tier-2 (mid-cap / late-stage): 18% (9 of 50)
Tier-3 (Series A-C): 26% (13 of 50)
Tier-4 (seed): 20% (10 of 50)

Twenty-six percent vs. eight percent is a 3.25x gap. Tier-3 is the sweet spot in 2026. They are big enough to have real engineering teams and structured comp, small enough to not have a 100-applicant queue per posting.

Tier-1 is rough. Eight percent callback on 50 applications is a lot of energy for a very low yield. The signal is consistent across talking to friends in the same loop: FAANG-scale companies have absorbed more candidates than they can interview, and the funnel is not getting healthier.

Tier-4 (seed-stage) is paradoxically lower yield than Tier-3. Smaller postings get fewer applicants but seed startups are also slower to respond. Some of my Tier-4 callbacks came at week 4-6, after I had stopped tracking the application as live.

The compound effect

If you stack the three findings together:

Tier-3 + 7-10am + Tuesday: 38% callback rate (sample of 8, so noisy, but that's the directional signal).
Tier-1 + after-hours submission + Friday: 0% callback rate (sample of 5, all silent).

You can't always pick your tier. But you can almost always pick your hour. And you can almost always pick your day to be not-Friday.

What changed in my workflow

After this test:

Batch applications during morning recruiter hours. I now save up a set of finished applications and submit them between 7am and 10am Pacific (most US recruiters), or 9am-noon Eastern. Yes I am sometimes setting a 6am alarm. The yield delta is worth it.
Skipped most Tier-1 applications. I still apply to one or two specific Tier-1 roles per quarter — but as a deliberate effort, not as part of the regular volume. The funnel does not pay off.
Doubled down on Tier-3. Seven of my last twelve interviews are at Series A-C companies. The hit rate is higher and the comp range is, surprisingly, not far below Tier-1 if I land at the right one (see What Remote Developers Actually Make in 2026 for the comp breakdown).
Stopped optimizing day-of-week. It is real but small. I just don't submit on Friday afternoons.

The thing that didn't matter

I tracked one more variable I was sure would move the needle: whether I attached a cover letter or not. It did not. Callback rate was identical with and without cover letters in this sample. The other findings are big enough that this one feels like noise — but it is consistent with the broader hiring-manager survey I did last week (only 30% read past the second sentence of a cover letter anyway).

The hardest part of the job search is not the strategy. It is doing the strategy you already know is right, instead of adding more strategies. Apply early in the morning, target Tier-3, do not waste energy on Friday afternoons. That is most of the available alpha.

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

Earlier in this series:

Stop Applying to Jobs Wrong — 5 Fixes That Actually Work — the original
Stop Applying Wrong, Part 2: 7 More Application Habits That Are Quietly Killing Your Callback Rate — the sequel

I Sent the Same Resume to 5 AI Recruiter Bots — Only 2 Replied. Here Is What Killed the Other 3

charlie-morrison — Sat, 02 May 2026 20:01:30 +0000

There is a layer of AI recruiting tooling that has quietly become unavoidable in 2026. Most candidates do not know they are interacting with it, because the recruiter on the phone is human and the email is signed by a human, but the first filter and the first conversation in roughly half of all postings I tracked this quarter goes through software.

I wanted to know how good the software actually is. Specifically: does the same resume get the same treatment across the five biggest tools? Or are some of them just throwing applications away?

I picked one application of each kind that I would actually accept if it became real. I sent the same resume — same role-fit, same seniority — to five different recruiting platforms. Then I tracked what happened.

Two of the five worked. Three did not. The failure modes are interesting because they are different from each other.

The five platforms

I will describe the categories rather than name vendors, since some of these platforms operate as white-labels under recruiter brand names.

Conversational AI screener — the chatbot that DMs you on LinkedIn and asks 4-6 qualifying questions before forwarding to a human recruiter.
Voice-AI phone screener — calls your phone, has a 5-minute conversation, transcribes, then routes.
Resume-parsing + scoring API — runs your resume through OCR/NER + an LLM scorer; outputs a fit score; recruiter sees that score and decides whether to read.
Async video interview tool — you record yourself answering 3-5 questions, AI transcribes and scores, recruiter watches the highest-scoring videos.
AI sourcing platform that "matches" you to roles — you upload your resume; it runs against an embedding index of open roles; you get matched roles back via email.

The two that worked

Platform 1 (conversational chatbot) worked. It asked four questions, three of which were directly job-relevant ("are you authorized to work in the US," "are you open to remote," "what is your minimum comp expectation"). The fourth was a vague behavioral prompt that I answered with two sentences. Forty-eight hours later a real recruiter emailed asking to schedule a call. Same role, no surprises.

Platform 5 (AI sourcing match) also worked. I uploaded the resume; within 36 hours I had three relevant role matches in my inbox. Two were genuinely fit (correct seniority, correct stack, correct geography). The third was off — wrong stack — but it was a transparent miss, not a hostile one. Email-the-recruiter-back and they corrected.

What these two have in common: simple, structured tasks with feedback loops. Conversational screening is a 4-question survey with branching. Sourcing-match is an embedding lookup with manual recruiter override. Both are well-suited to the AI of 2026.

The three that didn't

Platform 2 (voice AI phone screen) failed in an interesting way. The bot was clearly trying to act human. It paused naturally. It said "mhm" at appropriate moments. It also missed two of my answers entirely, asked the same question twice (different wording), and ended with "thanks, we'll be in touch." Nothing followed. Six weeks later, no human contact. I escalated through a different channel — recruiter said the platform had logged me as "low engagement signal" because I had asked it to repeat one of its questions. The bot had penalized me for clarifying.

Platform 3 (resume scoring API) failed silently. There is no candidate-facing failure mode. You just don't hear back. I only know my application was scored low because a friend at the company forwarded me the recruiter's view of it. The fit score had been 41/100. The recruiter never opened the resume. The score was low because my title at my current company is not the standard title for the role. The scorer had no concept of "this person does the role under a different title at a smaller company." It was a string match. I lost the role to a less-qualified candidate with a perfectly-matching title.

Platform 4 (async video interview) failed in the way the platform itself documents but candidates don't notice. The scoring rubric weights three things heavily: speech pace, eye-contact-to-camera, and "energy" (a proxy that mostly captures pitch variation). I answered the questions clearly and concisely. The transcript was good. The video score was 64/100. I lost to a candidate who almost certainly performed better on the rubric than on the actual answers.

The pattern

The two that worked treat AI as a structured-task layer with human override. The three that failed treat AI as a judgment layer.

Conversational screening = AI does the easy part (collecting structured answers); humans do the hard part (deciding fit). It works.

Sourcing match = AI does the easy part (embedding similarity); humans do the hard part (deciding which match to act on). It works.

Voice AI screening, resume scoring, and async video scoring all ask the AI to make the judgment. The AI is not yet good enough. But it is good enough to silently filter you out without telling you. That is the dangerous version.

What to do as a candidate

Three concrete moves, in order of cost.

1. Free: title-match your resume. If platform 3 is in the funnel for a role you want, the title on your resume must exactly or nearly match the title in the JD. "Senior Software Engineer" vs. "Senior Backend Engineer" can be a 15-point fit-score gap. Stack tokens matter too: Go, Postgres, Kubernetes — exact spelling, exact case is fine but avoid abbreviations the parser may not have seen.

2. Cheap: rehearse the structured answer flow for platforms 1 and 2. Authorization, location, comp, "tell me about yourself" — short, direct, no anecdotes. The bot is parsing for keywords and intent. Give it both, fast.

3. Expensive: avoid platforms 3 and 4 if you can route around them. This is not always possible, but a referral from inside the company often skips the scoring layer and lands you in a human recruiter's queue directly. A referral was worth roughly 5x the response rate in this small sample.

The platforms aren't going away. They are getting more common, not less. The candidates who learn the layer's failure modes will get more interviews. The ones who don't will quietly lose offers they were qualified for.

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

Earlier in this series:

Your Job Application Is Being Scored by AI — Here's How to Win — the original
I Reverse-Engineered 5 ATS Systems — Here is What Your Resume Actually Looks Like to Them — the ATS angle

I Tracked 80 Remote Dev Offers in Q1 2026 — Here Is the Real Salary Distribution by Region (and the 4 Outlier Companies)

charlie-morrison — Sat, 02 May 2026 20:00:54 +0000

I have been collecting remote-dev offers from a private rotation of friends, ex-coworkers, and a small Slack of mid-to-senior engineers for the last twelve weeks. Eighty data points cleared the bar I set: real signed (or declined) offers, role disclosed, total comp disclosed, region disclosed, last 90 days only.

This is not a salary survey. The sample is small and biased toward backend, infrastructure, and platform engineers — that is who I know. But it is real money attached to real names attached to real loops, and the patterns inside it are worth a 10-minute read.

The headline

Median total comp for senior remote backend engineers, Q1 2026, by region:

United States (Tier-1 hubs working remote): $245k
United States (everywhere else): $208k
Western Europe (UK / Germany / Netherlands): €145k (~$157k)
Eastern Europe / LATAM (USD-paid contract roles): $112k

That is medians. The spread inside each region is more interesting than the medians themselves.

US Tier-1: $185k–$385k

Twenty-two offers in this bucket. The median was $245k, but the spread was 100k+ on either side.

The bottom of the band ($185–210k) was almost entirely Series B/C startups paying total-comp at IPO-stage levels but with most of it in cash and minimal equity. No outliers there — just smaller comp packages.

The middle ($230–270k) is where most public-company senior roles sat. Predictable.

The top of the band ($300k+) was three companies. Two were AI infrastructure firms (one named, two not in this post). One was a hedge-fund-adjacent dev tools company. Total comp was high because base was high — not because of equity windfall — and the work was extremely specialized.

The takeaway: if you are a senior backend engineer and you see remote US offers under $200k total in 2026, you are looking in the wrong segment.

US non-hub: $155k–$295k

Eighteen offers. Median $208k.

The fascinating thing here is how narrow the band actually is. US non-hub remote roles are converging fast — most offers landed within $30k of each other. The remote labor market is no longer pricing geography that aggressively. Tier-2 candidates are pulling close to Tier-1 base, and the gap is mostly equity and bonus.

The exceptions in this bucket: two offers above $260k, both from companies that pay "anywhere" (no geo adjustment). Those companies are still the rarer minority but they exist and they are real.

Western Europe: €105k–€220k

Sixteen offers. Median €145k.

The bimodal distribution here is the loudest signal in the dataset. Either the company paid local-market rates (€105–135k), or they paid US-adjusted rates (€175–220k). Almost nothing in between.

US-adjusted rates were paid by remote-first US companies hiring in the EU through an EOR (employer of record). Local rates were paid by EU-headquartered companies, even when they were "remote-first."

If you are in Western Europe targeting remote, the company's HQ is the dominant variable, not the role.

Eastern Europe / LATAM (USD contract): $65k–$185k

Twenty-four offers. Median $112k.

The wide spread here is mostly company-side. Mid-tier US companies hire EE/LATAM contractors in the $80–110k range. Top US companies that hire in this region (rarer) pay $140–180k. A few outlier specialty roles paid more, but those required specific stacks (Kubernetes-deep platform roles, Rust systems work, ML infra).

The interesting gap: roughly 40% of the EE/LATAM offers in this dataset specified fully equivalent role and seniority to a US offer at the same company, but at 50–60% of the US comp. This is the actual gap. It is not that the work is different. The market just hasn't fully arbitraged.

The four outlier companies

Four companies showed up multiple times in the top-decile of their region's distribution. I am not going to name them here (the data was shared in confidence) but I will describe what they have in common.

1. They publish the band. All four publish exact comp bands in the JD. None of the "competitive comp" euphemism.

2. They pay base, not bonus. Cash compensation is mostly base salary. Equity is generous but does not require dramatic stock-price growth to be worth the published number.

3. They hire globally without geo-adjusting. A senior in Madrid gets paid the same as a senior in Seattle. This is rare in 2026 and these four companies do it on purpose.

4. They have technical interview loops, not behavioral-heavy loops. The interviews are skills tests. They are hard but they are not a personality contest.

If you can find these four (and you can, with a few hours of search), they are paying double the regional median. The interviews will eat you alive but the comp justifies the prep.

What to do with this data

Three concrete moves.

1. Anchor on regional median + 15%. That's a reasonable opening counter for a senior remote role. Low enough that it is in the band, high enough that they don't take advantage.

2. Ask whether the company geo-adjusts. This is one of the most useful early-funnel questions. If the answer is "yes, by 25%," you know the upper bound. If the answer is "no, we pay the same everywhere," you know you are at one of the better-paying companies in the dataset.

3. Treat the median as the floor, not the ceiling. Half of the offers in any region were above the median. The companies paying above the median advertised in the same channels and ran the same interview loops as the ones below it. Apply broadly. Negotiate hard.

The single largest variable in remote dev comp in 2026 is which company you join, not which region you live in. The data shows this clearly. Don't shortlist by location. Shortlist by comp band.

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

Earlier in this series:

What Remote Developers Actually Make in 2026 — Real Data from 50 Offers — the original
Remote Developer Jobs in 2026: Where to Actually Find Them — where the offers came from

I A/B Tested 7 LinkedIn Headlines Over 30 Days — Only 2 Got Recruiter Outreach. Here Is the Data

charlie-morrison — Sat, 02 May 2026 20:00:17 +0000

I have been writing about LinkedIn invisibility for two months. Last month I tested it on myself.

The setup: rotate seven headline patterns across thirty days, one week per pattern (with two patterns getting two weeks because I needed more data). Hold the rest of the profile completely static. Track inbound recruiter messages, profile views, and search appearances via the analytics tab. Use a private alt-account a friend ran to verify search position for the same target keywords across each headline.

Two patterns won. Five did not. Here is what shipped and what flopped.

The seven headlines I tested

I tried to hit the actual variance you see in the wild rather than only the ones I expected to win. Each is rendered exactly as it appeared on the profile.

Senior Software Engineer at [Company] — the default
Senior Software Engineer | Backend (Go, PostgreSQL, Kubernetes) | Remote
Senior Software Engineer | I help fintech teams scale Go services to 10k req/sec without rewrites
Building developer tools at [Company] | Backend / Distributed Systems | Open to remote
Senior Software Engineer (Backend, Go, K8s) — building API platforms used by 200+ enterprise customers
Backend Engineer focused on payment systems | Go, Postgres, Kubernetes | Open to senior roles
Software Engineer | 8 years | Remote-first | Reach out about backend platform roles

The two that won

Pattern 2 and pattern 6 were the only ones that produced more than one recruiter message in their week. Pattern 2 produced 4 messages. Pattern 6 produced 5. The other five patterns produced zero, one, or — in one case — one ill-targeted message about a frontend role.

What those two had in common:

Title or seniority word in the first 30 characters. Recruiter search seems to weight the first chunk of the headline heavily. "Senior Software Engineer" or "Backend Engineer" needs to be early.
Stack tokens, not paragraphs. "Go, Postgres, Kubernetes" outperformed "Go, distributed systems, infrastructure." Concrete tools beat abstract domains.
A "what I'm open to" signal. "Remote" or "Open to senior roles" — short, scannable. Recruiters filter by these.

The losers had three failure modes.

Achievement headlines (3 and 5) flopped. "I help fintech teams scale Go services to 10k req/sec without rewrites" was clicked-through more (profile views went up) but recruiter outreach dropped. The headline read like a consultant pitch and recruiters skipped it.
Brand-led headlines (4) flopped. Leading with the company name makes the title less searchable. The keyword that recruiters search ("backend engineer," "senior engineer") is buried.
Short-sentence headlines (7) flopped. "8 years | Remote-first" sounds confident but it is too far from how recruiters search. They search by stack and seniority, not by years and preferences.

The week-by-week numbers

Profile views (LinkedIn analytics, weekly):

Pattern 1 (default): 38
Pattern 2 (stack-forward): 71
Pattern 3 (achievement): 92
Pattern 4 (brand-forward): 44
Pattern 5 (achievement-numerical): 81
Pattern 6 (focus-area + open-to): 76
Pattern 7 (years-forward): 41

Recruiter messages:

Pattern 1: 0
Pattern 2: 4
Pattern 3: 1 (unrelated role)
Pattern 4: 0
Pattern 5: 0
Pattern 6: 5
Pattern 7: 1 (recruiter-network spam)

The interesting wedge: pattern 3 had the most profile views and the worst outreach. Profile views and recruiter outreach are not the same metric. A headline that catches eyes from your network is not the same as a headline that surfaces in recruiter search.

Search-position check

The verification — a friend's alt-account searching "senior backend engineer Go Postgres remote" each week — added one more data point.

Pattern 2 surfaced on page 2 of search results. Pattern 6 surfaced on page 3. The other patterns either did not appear in the first 5 pages or appeared inconsistently. Default headline (pattern 1) did not appear at all.

If you take nothing else from this test: putting your stack tokens in the headline is the lowest-effort, highest-yield change you can make. The headline is not the place for personality. It is the place for keywords.

The headline I am running now

I wrote a synthesis of the two winners after the test ended:

Senior Backend Engineer | Go, PostgreSQL, Kubernetes | API platforms & distributed systems | Open to remote senior roles

It hits the four things that mattered: title in the first 30 chars, three concrete stack tokens, a focus-area phrase that scans, and an open-to signal. It is also still inside LinkedIn's 220-character limit with room to add or rotate.

What to do with this

If you have not changed your headline in six months, the cheap experiment is: write three variants on this template and rotate them weekly. Track recruiter messages and search appearances. Pick whichever wins. Repeat the test in six months because LinkedIn keeps tuning what its search ranks.

The pattern that has not changed in two years: keywords beat narrative. Stack beats story.

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

Earlier in this series:

Your LinkedIn Profile Is Invisible to Recruiters — Here Is How to Fix It — the original
I Scraped 50 LinkedIn Profiles That Got Recruited — Here Are the Patterns — the data side