DEV Community: charlie-morrison

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

I Asked 12 Hiring Managers What 'Truly Remote' Means in 2026 — Their Answers Don't Match Their Job Postings

charlie-morrison — Sat, 02 May 2026 19:59:41 +0000

There is a phrase I see on roughly half of every "remote" posting I read this year: fully remote / work from anywhere.

Then I started asking the people who write those postings what the phrase actually means. Twelve hiring managers, four 1:1 conversations a week, written follow-ups for the rest. The answers don't match the postings.

This is not a complaint. It is the friction layer that keeps costing candidates real offers — accepting a "fully remote" role and then discovering, three months in, that there was a quiet expectation about quarterly travel, or a four-hour overlap window that wasn't disclosed, or a state-tax restriction the recruiter never asked about.

So I went back to the source. Here is what hiring managers actually meant when they wrote "fully remote."

The 12 answers

I sorted the responses into five buckets after about eight conversations. The remaining four didn't add a sixth bucket, just more variance inside the existing ones.

1. Time-zone-bounded remote (4 of 12). "We say fully remote, but you'd need to work US Pacific or close to it." Sometimes there's a 2-3 hour overlap window. Sometimes the engineering team is split across two time zones and they expect you to land in one of them. The posting almost never says this.

2. State/country-bounded remote (3 of 12). Payroll/tax/legal restrictions mean the company can only hire in specific states or countries. One had hired in 14 states; one had a four-state list; one was technically only allowed to hire in their HQ state but was making exceptions case-by-case. The posting said "remote, US."

3. Office-optional remote (2 of 12). "We say remote because you don't have to come in. But the senior staff comes in two days a week, and that's where the relationships get built." This is the bucket where remote candidates quietly don't get promoted.

4. Travel-required remote (2 of 12). "Fully remote, but onsites every quarter and a one-week kickoff at the start." The travel was real and not optional. It was also not in the posting.

5. Truly distributed (1 of 12). Async-first, time zones don't matter, no required onsites, hiring open globally subject to contractor terms. One company. Out of twelve.

If I extrapolate that to the broader market, "fully remote" means truly distributed about 8% of the time. Even if I'm off by 2x, that's still under 20%.

Why postings don't say this

Three reasons came up unprompted across the conversations.

The first is that the recruiter writing the JD doesn't know. They have a template, the hiring manager said "yes it's remote," and the line goes in. The hiring manager meant bucket 1 or 2. The recruiter posted bucket 5.

The second is that specifying narrows the candidate pool too much for the company's brand goals. "If we say 'remote, but only Pacific time zone' we lose 60% of applicants. If we say 'remote' we get more applicants and we screen for time zone in the first call." This is honest but it costs both sides time.

The third is that the company is genuinely figuring it out. They started fully remote in 2020-22, are now reconsidering, and the posting hasn't caught up. One manager admitted: "We are remote until we aren't. The team is small enough that one person joining who needs to be in-office for some reason could change the whole policy."

The four questions that close the gap

If the posting says fully remote and you don't know which of the five buckets it is, ask these four in your first recruiter call. They are not aggressive. They are just specific enough that handwaving stops working.

"What's the time-zone overlap requirement, in hours, with the rest of the team?" Note: not "do you have an overlap requirement." Hours. They will give you a number or admit there isn't one.
"What states or countries can you hire in for this role?" This is a payroll question. If they don't know, they will check and come back. If they say "anywhere" — write it down, because you will want it later.
"How often does this team travel for in-person meetings, and is it required?" Quarterly is normal. Monthly is a different job. "Optional but encouraged" is hiring-manager code for required-for-promotion.
"How many of the senior people on this team work fully remote vs. hybrid?" This is the bucket-3 trap-detector. If senior staff are mostly hybrid, the trajectory of the role is hybrid, regardless of what the posting says.

What "no" looks like in those answers

Watch for the patterns that mean it's not bucket 5.

"We are flexible on time zones, but the team is mostly in [city]." → bucket 1 or 3.
"Right now we can hire in [list of states under 10]." → bucket 2.
"Travel is rare, but the kickoff is in person." → bucket 4 (small dose).
"Most of our senior engineers come in 1-2 days a week." → bucket 3, full strength.

None of these are dealbreakers if you know about them upfront. They are dealbreakers when they show up after you've signed.

The one thing I changed in my own search

I stopped applying to "fully remote" without the answers. Not as a dealbreaker — just as a sequencing thing. I get the four answers in the recruiter call, then I decide whether to invest in the loop. It cuts about 30% of postings from the funnel and saves an enormous amount of mid-funnel time.

If you are early in the search and want to filter postings before even applying, the bucketing exercise above also works on the JD itself. "Distributed team," "async-first," "no onsites required," "we hire globally" — that's bucket 5 language. "Remote (US)," "remote with quarterly onsites," "remote within North America" — that's bucket 2 or 4 being honest.

The companies that mean bucket 5 say it. The ones that say "fully remote" without elaboration usually mean something else.

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:

Remote Developer Jobs in 2026: Where to Actually Find Them — the original list
What Remote Developers Actually Make in 2026 — Real Data from 50 Offers — the comp side

5 Things to Read in Your Equity Grant Before You Sign (Most Candidates Miss 3 of Them)

charlie-morrison — Sat, 02 May 2026 01:04:29 +0000

The cash component of a tech offer in 2026 is increasingly the easy part to negotiate. The hard part is reading the equity grant — and most of the candidates I have helped negotiate offers in the last year did not realize how much they were leaving on the table because they did not know what to ask.

This post covers the 5 things to read in any equity grant before you sign, and the questions to ask if the offer letter does not address them. None of this is legal advice; it is the practical version of what someone who has been on the receiving end of half a dozen of these now would tell themselves before round 1.

1. The grant size, and what it is worth at four different prices

The offer letter says "150,000 RSUs" or "0.4% equity." That is not the negotiation surface. The negotiation surface is dollars, and dollars require a price.

For RSUs at a public company, ask for the 30-day trailing average share price as the basis for the dollar value, not the strike or the day-of-grant price. The day-of-grant price is what most companies use; the trailing average is more honest because it smooths out a bad day.

For private-company stock or options, ask the recruiter to walk you through the math at four different exit valuations:

Bear case (50% of last round price)
Last round price (the most common reference point)
2x last round price (the company's near-term aspiration)
Bull case (5x or 10x last round, depending on stage)

If the recruiter cannot or will not do this math with you, that is a signal. The number on the offer letter is meaningless without the math.

2. The vesting schedule (and the cliff)

Standard is 4-year vesting with a 1-year cliff. If your offer is anything different, read it carefully:

5-year vesting: rare, almost always worse for you. Push back to 4-year.
No cliff: good for you, ask if the recruiter offers it (some do, some do not).
Back-loaded vesting (10/20/30/40 over 4 years): common at Amazon and a few others. The dollar value of the offer is meaningfully lower than a 25/25/25/25 schedule. If the offer letter does not specify, assume 25/25/25/25 and ask explicitly.
Monthly vs quarterly vs annual cliff: ask. Monthly is best for you. Annual is the worst (you lose 11 months of vesting if you leave 11 months in).

3. The strike price and the 409A timing (private companies only)

For options at a private company, the strike price is set by a 409A valuation that is updated periodically (usually annually, sometimes more often after a fundraise).

Ask:

"When was the most recent 409A valuation?"
"Is there a fundraise that might trigger a new 409A before my grant date?"

If a new 409A is coming and it is going to raise the strike, your effective gain on the grant just dropped before you started. You can sometimes negotiate the grant date to before the new 409A, or negotiate more shares to compensate.

4. The post-termination exercise window

This is the one nobody warns you about and it has cost real people real money. When you leave a company with vested options (private company), you typically have 90 days to exercise them or you lose them.

Ask:

"What is the post-termination exercise window?"
"Is there an extended exercise window for employees who stay 2+ years?"

Some companies (Stripe, Pinterest historically, several more) offer extended windows (up to 10 years) or convert vested options to RSUs in some scenarios. Some do not. The difference can be six figures of value depending on your tenure and the strike price.

If the company has a 90-day window and refuses to extend it, factor that into your decision: your vested options are essentially company-controlled until you exercise. Exercising can be expensive (especially with AMT implications in the US), so the options can be effectively worthless if you cannot afford to exercise.

5. Refresher grant policy

The offer is the on-hire grant. Most senior engineering roles at established companies also include refresh grants every 1-2 years. The offer letter rarely specifies these.

Ask:

"What is the typical refresh grant size at my level here, after year 1 and year 2?"
"Is there a clear process for refresher grants tied to performance?"

If the answer is "we do not really do refreshers" — that is a major signal at the senior level. Your effective compensation will drop sharply in years 3-4 as the on-hire grant winds down. Either negotiate a larger on-hire grant to compensate, or expect to renegotiate or leave at the 3-year mark.

What to ask explicitly during the offer call

Print this list, ask each one in order:

Can I see the equity grant terms before signing the offer letter?
What is the dollar value of the equity at the trailing 30-day average share price (or last round price for private)?
What is the vesting schedule and cliff?
(Private only) When was the most recent 409A and is a new one expected before my grant date?
What is the post-termination exercise window?
What is the typical refresh grant cadence at my level here?
Is there a tax-advantaged option election I should be aware of (ISO vs NSO, double-trigger RSUs, 83(b) for early exercise)?

You will not get answers to all 7. You will get answers to most. The pattern of which ones the recruiter answers immediately and which ones they hedge on tells you a lot about how the company actually treats compensation.

Why this matters more in 2026

Two things have shifted:

Equity is a larger fraction of senior offers than it was 3 years ago. At several public companies, the equity component is now 40-50% of total comp at L4+. Negotiating the cash and ignoring the equity means negotiating the smaller half of the package.
Equity is harder to value. Public-market volatility and slower IPO cycles for private companies mean the stated offer value is more disconnected from realized value than ever. The 5 questions above are how you bridge the gap.

For the cash side of the negotiation, How to Negotiate a Developer Salary (With the Actual Email I Sent) walks through the script that actually moved my last 3 offers. And for the round-2 ("they came back with a counter") moment specifically, What to Say When They Counter Your Counter-Offer has the scripts.