DEV Community: Chris

Stop guessing your freelance rate: what 2026 survey data says

Chris — Tue, 29 Sep 2026 04:24:50 +0000

Ask a room of freelancers what their hourly rate is and half of them will hesitate. Ask how they arrived at it and the honest answer is usually "my old salary divided by two thousand" or "whatever the freelancers around me on Upwork seem to charge." Then they never revisit the number. Years pass.

The number you quote shapes everything downstream: which clients take you seriously, how fast the business grows, whether you can afford to say no. It deserves better than a guess. Here is what actual 2026 survey data says.

The bands by experience level

Arc's 2026 survey of 5,302 freelance developers worldwide reports these global hourly ranges:

Junior: $20 to $50
Mid: $40 to $90
Senior: $75 to $150
Staff or Principal: $120 to $220

US numbers skew higher, roughly $82 to $130 across levels in the same survey. The DACH market (freelancermap 2026, 5,400+ respondents) averages €103 per hour — down from €104 in 2025, the first dip since €96 in 2022.

The bands by role

A 2026 compilation across marketplaces and salary databases:

Junior developer: $35 to $60
Mid developer: $55 to $85
Senior developer: $85 to $130
Tech lead: $100 to $150
Architect: $120 to $175
AI or ML engineer: $110 to $175
DevOps engineer: $80 to $130
UI or UX designer: $60 to $100

These are approximate — geography, niche, and reputation move real people well outside the bands. But the direction across sources is consistent, which is what makes them useful.

Specialty beats seniority

The premium for specialization is real and measurable: cloud and mobile expertise earn 10 to 30 percent more than generalist developers, while AI and ML command 25 to 60 percent premiums, with niche AI work reaching 100 percent above generalist baselines. Specialized consultants — cloud, cybersecurity, data — report median rates of $160 to $220 an hour. Niche specialist positioning is arguably the single highest-leverage pricing decision a freelancer makes.

How to answer "what is your rate"

Never open with a number. Open with discovery:

"What does this project look like in terms of scope, timeline, and team? I want to quote something accurate rather than a guess."

Anchoring research shows the first number mentioned sets the range for everything after. When the prospect answers with a budget, they have given you their anchor and their constraints — calibrate your quote to the project's value, not their number.

The raise you never gave yourself

Pick a target — one band up. Compute the monthly cost of not being there. Then build a ledger: every win, every testimonial, every scope successfully delivered, every metric moved. Review it monthly. Each entry is evidence for the next quote.

The freelancers who raise rates on schedule share the same operating rhythm: they set calendar reminders for rate reviews, build evidence between reviews, and quote the new number to new prospects instead of renegotiating old clients.

The negotiation rules that matter

Project pricing beats hourly pricing whenever the client's problem has a dollar value. Give three options — Good, Better, Best — instead of one number. Never discount without removing scope; a discount on the same work teaches the client the first price was theater. And when you are too busy to take a project, quote a deliberately high number instead of declining: the "too busy" premium. The worst outcome is a very profitable project.

This is one chapter of The Freelancer Client-Acquisition Kit — 37 pages covering outreach scripts, proposals, rate tables, contracts, retainers, and referrals. Every data point labeled with its source and evidence strength; where the research found no data, it says so. No guru fluff: https://cjettoostudent.gumroad.com/l/qfckgb

Cold outreach for freelance developers: 6 scripts that actually get replies

Chris — Tue, 29 Sep 2026 04:18:32 +0000

Cold outreach has a reputation problem among freelancers, and the reputation is mostly earned. The average freelancer cold email: generic flattery up top, a wall of credentials, three links, a demand for a 30-minute call. Sent to five hundred people. Zero replies. Then the freelancer concludes "cold outreach does not work" and goes back to refreshing job boards.

Cold outreach works. Bad cold outreach does not. The data — mostly vendor and aggregator studies of sales outreach, so treat the numbers as directional — points to two levers above everything else: personalization and follow-up. Roughly 55 percent of replies come from a follow-up, not the first email. Micro-lists of 500 to 1,000 hyper-targeted prospects dramatically outperform hundred-thousand-contact blasts.

Every effective cold message follows the same shape: signal, proof, low-friction ask.

Signal proves the message is for them specifically — one sentence on something you actually observed. Proof shows you understand the business problem, not just the technology. The ask is one easy question, not a meeting demand. Keep cold emails to 75-125 words and LinkedIn DMs under 50. Here are six scripts built on that shape. Replace every [BRACKET] before sending.

1. The cold email

Subject: [specific observation, e.g. "your checkout migration"]

Hi [Name],

[Signal: one sentence on something specific you observed.]

[Proof: one sentence showing you understand the problem — e.g. "Those migrations usually stall on [specific pain point]; I have untangled that exact problem for [type of company]."]

Worth a 15-minute call to compare notes on [specific topic]?

[Your Name]
[One-line credential]
[One portfolio link only]

2. The LinkedIn DM

Hi [Name], [signal in one clause]. [Proof in one clause]. I help [niche] teams fix exactly that — worth a brief chat?

No links in the first message.

3. The follow-up bump (day 4)

Hi [Name], floating this back up in case it got buried. Still happy to share what I have seen work for [specific problem] at [type of company] — worth 15 minutes?

Short, polite, adds nothing new. Most conversions happen on the first or second follow-up.

4. The new-value follow-up (day 10)

Hi [Name], one more thought since my last note: [one genuinely useful observation or example relevant to their situation].

Each follow-up must add new value. "Just checking in" trains prospects to ignore you.

5. The breakup email (day 18)

Hi [Name], I will stop following up — no point being a pest. If [specific problem] becomes a priority down the road, I am easy to find. Good luck with [specific initiative].

Then stop. Continuing past the breakup burns the relationship for zero expected return.

6. The referral request (past clients and peers)

Hi [Name], hope [project] is going well. Quick favor: I am taking on [number] new [niche] projects this quarter. If you know one person dealing with [specific problem], I would appreciate an introduction — happy to return the favor anytime.

Send this quarterly to every past client and friendly peer. Referral networks run on explicit asks, not good intentions.

Track it in a spreadsheet

You do not need a CRM. Columns: prospect, company, signal observed, date of first message, script used, follow-up dates, outcome. At 50 rows you have your own reply-rate benchmarks — real data about your market that no vendor study can give you.

These scripts are one chapter of The Freelancer Client-Acquisition Kit — 37 pages on getting freelance clients: channels, proposals, 2026 rate tables, contracts, retainers, referrals, and knowing when to walk away. Every stat labeled with its source. No guru fluff: https://cjettoostudent.gumroad.com/l/qfckgb

The 10 contract clauses every freelance developer needs

Chris — Tue, 29 Sep 2026 04:17:50 +0000

Most freelancers treat contracts as paperwork. The freelancers who get paid on time treat them as a system. Late-payment and non-payment trouble is widespread enough that second-hand industry figures put it at the majority of freelancers at some point — the exact numbers are soft, but the direction is not. Here are the ten clauses that separate the freelancers who get paid from the ones who chase invoices, drawn from collective practitioner experience. (Practical guidance, not legal advice — for large engagements, pay a local attorney to review your template.)

1. Scope: what exactly are you delivering?

Numbered deliverables, verifiable outcomes, acceptance criteria. "Migrated checkout flow" is not scope. "Checkout flow migrated to Stripe, handling 500 concurrent users, sub-2-second response, verified by load test" is scope. If it is not written down, it does not exist.

2. The out-of-scope list

The mirror of clause 1, and the highest-leverage block of text in the contract. List what you are NOT doing. Every scope dispute you will ever have is a sentence that should have been here.

3. Payment terms with a real deposit

Total, schedule, method, currency — and a 30 to 50 percent deposit upfront, non-negotiable, before work begins. A client who will not pay a deposit is telling you politely that they will not pay the final invoice either.

4. Deadlines on both sides

Your phase deadlines plus theirs: feedback within 5 business days, assets by agreed dates. Add a deemed-acceptance provision — if the client does not reject a deliverable within 15 business days, it is accepted. One unresponsive client can otherwise stall your cash flow indefinitely.

5. Revision limits

State the number of revision rounds per deliverable, and define the line between a revision (correction inside the agreed scope) and a new project. The "just make the text bigger" pattern is how four free favors become a second unpaid job.

6. Change orders in writing, always

Client requests change, you provide a written estimate, client approves in writing, then work begins. Verbal change orders evaporate the moment there is a dispute — which is exactly the moment you need them.

7. A kill fee

If the client cancels mid-project: 25 to 50 percent of the remaining contract value, plus payment for work performed through termination. Either side can terminate with written notice. The fee makes endings orderly instead of catastrophic.

8. IP transfer timing

State explicitly when intellectual property transfers: on final payment (safer for you) or on delivery. Refuse IP transfer before payment, and refuse blanket assignment of your pre-existing IP, methods, and tooling.

9. Late-payment terms

Interest on overdue invoices plus fixed compensation per late invoice. But prevention beats enforcement: deposits, milestone invoicing, and IP transfer on final payment only.

10. A liability cap

Cap your liability at the fees paid under the contract, and exclude consequential loss. One bug in a client's revenue system should not be able to bankrupt you.

Phrases that should make you flinch

Watch for these in client-drafted contracts: "as may be reasonably requested" (unlimited scope in reasonable clothing), "contractor shall ensure client is satisfied" (an infinite revision clause), "pay-when-paid" (you underwriting someone else's credit risk for free), and uncapped liability. Strike or rewrite every one.

This is one chapter of a bigger system. I put together The Freelancer Client-Acquisition Kit — 37 pages covering outreach scripts, proposal structure, 2026 rate tables, contracts, retainers, and referrals, with every data point labeled by source and evidence strength. If this article saved you one bad contract, the kit will save you ten: https://cjettoostudent.gumroad.com/l/qfckgb

15 ATS Keywords Software Engineers Forget to Put on Their Resume

Chris — Tue, 29 Sep 2026 03:20:19 +0000

Your resume lists React, TypeScript, and Node. So does everyone else's. Meanwhile the keyword that would have matched you to the role — the one describing work you actually did — never made it onto the page, and the ATS moved on.

This isn't about stuffing buzzwords. Recruiters search the ATS database with specific terms, and if your resume doesn't contain the terms for work you've genuinely done, you're invisible for roles you'd be great at. Engineers are especially guilty of this: we write what we built, not what it's called in hiring language.

Here are 15 terms engineers do constantly but forget to write down, grouped by category. For each one: what recruiters search, and why it matters.

Practices and process

1. CI/CD. You push code and it deploys itself — that's CI/CD, and it's one of the most searched terms in backend and DevOps-adjacent postings. If you've touched GitHub Actions, Jenkins, GitLab CI, or CircleCI, the term "CI/CD" belongs on your resume. Name the tool too; recruiters search both.

2. Code review. "Reviewed pull requests" sounds mundane, so engineers leave it off. But "code review" signals seniority — it means someone trusted your judgment on other people's code. One bullet is enough: "Reviewed 10+ PRs weekly across a 6-engineer team."

3. Unit testing / integration testing. Writing tests is invisible work that hiring managers specifically filter for. Don't just list "Jest" or "JUnit" in your skills — write the practice into a bullet: "Raised test coverage from 40% to 75% with Jest unit and integration tests." The words "unit testing" and "integration testing" are what get searched.

4. Agile / Scrum. Most teams run some flavor of it, and "Agile" still appears in a huge share of job descriptions. If you did sprint planning, standups, and retros, say "Agile/Scrum" plainly instead of assuming it's obvious.

Data

5. SQL / query optimization. Backend engineers write SQL daily and list "PostgreSQL" in skills — then never write the word "SQL" itself. Some ATS searches match the literal term "SQL" and miss the database name. Include both. And if you've ever fixed a slow query, "query optimization" is a high-signal phrase: "Optimized slow queries, cutting report generation time 60%."

6. Caching. You added Redis to stop hammering the database — that's "caching," a term architects and backend leads search for. Write it as a strategy, not just a tool: "Implemented Redis caching layer, reducing database load 70%."

7. Data modeling. Designed a schema? That's data modeling, and it's a distinct searched skill from just "knowing Postgres." Engineers treat schema design as part of the job; hiring managers treat it as a qualification.

Architecture

8. RESTful APIs / API design. "Built endpoints" is what you write; "RESTful API design" is what gets searched. If you designed routes, versioned an API, or wrote API contracts, use the formal term at least once.

9. Authentication & authorization. You implemented login with OAuth or JWT — recruiters search "authentication," "OAuth 2.0," and "JWT." "Set up auth" in a bullet matches nothing. "Implemented OAuth 2.0 authentication with JWT-based session management" matches three searches.

10. Microservices. Even if your architecture was "a few services talking to each other" rather than textbook microservices, the term describes the reality of distributed work: service boundaries, inter-service communication, independent deploys. If that's what you did, name it.

Operations

11. Docker / containerization. "The app runs in Docker" is infrastructure reality for most teams now, and "Docker" plus "containerization" are baseline filters for backend and platform roles. If you wrote a Dockerfile or debugged a container issue, it counts.

12. Monitoring & logging. You added Datadog dashboards or dug through CloudWatch logs at 2 AM — that's "monitoring and logging," and reliability-focused roles search for exactly that. One bullet: "Set up Datadog monitoring and alerting, cutting mean time to detection from hours to minutes."

13. Cloud deployment. Listing "AWS" in skills is table stakes; "deployed to AWS" or "cloud deployment" describes what you did with it. Recruiters distinguish between engineers who've used a cloud console and engineers who've shipped to one.

Craft

14. Performance optimization. Made something faster — a query, a page load, a bundle size? The umbrella term "performance optimization" is what gets searched, and it covers all of it. Pair it with the number: "Cut initial page load 45% via code-splitting and lazy loading."

15. Technical documentation / API documentation. Wrote a README that saved onboarding time? Documented endpoints with OpenAPI/Swagger? "Documentation" signals the senior-level habit of making knowledge durable. Teams hiring senior engineers filter for it.

Where to put them (placement matters as much as the words)

Keywords in the wrong place look stuffed; in the right place they look like a career. Three zones:

Skills section — exact terms, both forms. CI/CD (GitHub Actions), SQL (PostgreSQL), OAuth 2.0 / JWT. This is the machine-readable index. Mirror the job description's exact phrasing here.
Experience bullets — terms inside real work. Every keyword above should appear inside a bullet describing something you actually built, with an outcome. "Implemented Redis caching, cutting p95 latency 50%" beats a lonely "Redis" in a skills list, for both the parser and the human.
Summary line — the 3–4 heaviest hitters. If the role is backend-heavy, your summary mentions REST APIs, SQL, and CI/CD. This is the first thing the parser and the recruiter both read.

And the rule that keeps all of this honest: only list what you've actually done. Keyword optimization is translation, not invention — describing real work in the language hiring uses. The moment you list a tool you've never touched, it becomes lying, and it will surface in a technical interview.

The 10-minute keyword audit

Pull up the last job description you applied to (or want to apply to). Highlight every technical term in it. Now search your resume for each one — Ctrl+F, literally. Every highlighted term that's missing but describes work you've done is a keyword to add this week, in a skills entry or a bullet.

Do that against five job descriptions and a pattern emerges: the same 10–15 terms keep appearing. Those are your market's vocabulary. Learn to speak it on paper the way you already speak it in standup.

If you want a head start

Rewriting a resume around the right keywords from a blank page is slow, which is why I put together the ATS Resume Template Pack for Software Engineers ($15): three ATS-safe templates — classic single-column, skills-forward, and senior/staff — plus a setup guide and the full ATS checklist, so the formatting is handled and you can focus on the words.

But honestly? Even if you never buy anything, run the Ctrl+F audit against your target job descriptions today. Ten minutes, and you'll see exactly which of these 15 terms your resume is missing.

How to Answer 'Tell Me About Yourself' as a Software Engineer (With a Word-for-Word Framework)

Chris — Tue, 29 Sep 2026 03:19:35 +0000

"Tell me about yourself" is the first question in almost every interview, and most engineers waste it.

The typical answer is a chronological tour of the resume: "Well, I graduated in 2019, then I worked at Company A where I did some frontend stuff, then I moved to Company B..." Two minutes in, the interviewer's eyes glaze over, and you've burned your best first impression reciting information they already read.

Here's what the interviewer is actually listening for — it's only three things:

Can you communicate clearly? If you can't explain your own career in 90 seconds, they doubt you can explain a technical decision to the team.
Are you relevant to this role? They're pattern-matching your background against the job description in real time.
Do you have direction? A candidate who knows why they're here beats a candidate who's just... interviewing everywhere.

The framework below hits all three. It takes 60–90 seconds, and you can reuse it for every interview by swapping the details.

The framework: Present → Prove → Pivot

Three parts, in this order. Think of it as a commit message for your career: context, what changed, why it matters now.

1. Present — who you are right now (2 sentences)

Current title, current stack, what you're working on today. Not your life story — your current state. This orients the interviewer immediately.

2. Prove — your trajectory in proof points (3–4 sentences)

Pick two or three highlights that are relevant to this specific role, each with a concrete outcome. Numbers beat adjectives. "Led migration" is forgettable; "led the migration of our checkout flow to React, which cut page load time 40%" is memorable. Skip everything that doesn't serve the role you're interviewing for — that's what the resume is for.

3. Pivot — why this role, why now (2 sentences)

Connect the dots forward. What about this team, this product, this stack makes it the obvious next step? This is the part almost everyone skips, and it's the part that makes you sound intentional instead of desperate.

Total: 7–8 sentences. About 90 seconds spoken. Then stop talking and let them ask the next question.

A word-for-word example (full-stack engineer)

Here's the framework filled in, so you can hear what it sounds like. Treat it as a template — swap in your own stack, numbers, and story:

"I'm a full-stack engineer currently building internal tooling with React on the frontend and Java with Spring Boot on the backend. Most of my recent work has been on our deployment pipeline and admin dashboards — the unglamorous stuff that keeps 200+ engineers shipping.

Before this, I spent two years at a logistics startup where I rebuilt their order-tracking API in Node and Postgres. That cut our p95 response time from 900ms to under 200ms and took us from constant timeout complaints to basically zero. Earlier in my career I did frontend-heavy work, which is why I'm comfortable owning features end to end — I've been the person debugging both the React component and the database query behind it.

I'm talking to you because this role is exactly that intersection: a product team that needs someone who can ship full features without handoffs, and your stack is the one I've spent the last three years getting good at."

Count the sentences: eight. Notice what it doesn't do — no graduation year, no exhaustive job history, no "I'm passionate about" filler. Every sentence either proves competence or points at this role.

The three mistakes that kill this answer

Mistake 1: The autobiography. Starting from college and walking forward year by year. The interviewer has your resume; they don't need the audiobook version. Start with now and work backward only as far as relevance requires.

Mistake 2: The five-minute monologue. If your answer needs a breath in the middle, it's too long. Long answers signal you can't prioritize information — a bad look for an engineer. Time yourself: if it's over two minutes, cut the weakest proof point.

Mistake 3: Vague and numberless. "I've worked on various projects across the stack and collaborated with cross-functional teams." That sentence contains zero information. Every claim needs a what and a so-what: what you built, what changed because of it.

Tailor it in 10 minutes before every call

The framework is fixed; the content changes per role. Before each interview:

Read the job description and highlight 3–4 must-haves — the stack, the seniority signals, the domain.
Pick proof points that match. If they want AWS experience, your Prove section leads with the AWS migration, not the CSS refactor.
Write the Pivot last, and make it specific. "Your team" is weak; "your checkout team rebuilding payments on Spring Boot" shows you did homework.
Say it out loud once, timed. You'll catch the rambling parts immediately.

One rehearsal out loud is worth ten silent read-throughs. Your mouth finds the awkward transitions your eyes skip.

If you want the full question bank

"Tell me about yourself" is one question. A real interview loop has thirty more — behavioral rounds, system design, live coding, and the tricky ones like "why are you leaving your current role" where one wrong sentence ends the process.

I put together The Tech Job Search Kit ($39) partly because I kept seeing engineers lose offers they should have won in the interview stage. It includes a full interview question bank with frameworks like the one above for behavioral and technical rounds, plus the resume templates, LinkedIn playbook, outreach scripts, and salary-negotiation guide.

But even if you never buy anything: write your Present → Prove → Pivot tonight, time it, and say it out loud once. You'll walk into your next interview with the first 90 seconds already won.

Two $150k+ Job Offers Compared Line by Line — The Higher Salary Lost by $59k

Chris — Tue, 29 Sep 2026 03:15:16 +0000

When the offers land, almost everyone does the same thing: compares the base salaries, picks the bigger number, and signs. It's understandable — base salary is the biggest, boldest number on the page.

It's also the most misleading number on the page.

Let me walk you through a worked example with two realistic offers. The base salaries are $15,000 apart. The actual gap, once you do the math honestly, is nearly $60,000 in year one — and roughly $234,000 over four years. Nobody would ever know that from the base salaries alone.

The trap: base salary is one line of many

An offer is a package: base salary, bonus, equity, 401(k) match, health insurance, PTO, and a dozen smaller items. Comparing two offers on base alone is like comparing two apartments by square footage while ignoring that one has no windows.

Here's the framework. For every offer, calculate four-year total comp: Year 1 total = base + (bonus × realistic payout %) + (equity vesting in year 1) + 401(k) match + quantifiable benefits. Run this for each offer. The "lower base" offer wins far more often than you'd expect.

Bonus: the target is not the payout

A "15% target bonus" means nothing until you know the payout history. If the company paid out 90% of target last year, that 15% is really 13.5%. If a startup paid 70% of a 10% target, that's a 7% bonus — less than half of what the headline suggests.

Always ask: "What did this bonus actually pay out the last two years?" It's a completely normal question. Evasive answers are a red flag — treat a non-answer as a low payout in your math.

Equity: RSUs are math, options are lottery tickets

This is where the biggest hidden gaps live.

Public-company RSUs are straightforward: shares × current stock price, vesting over four years with a one-year cliff. Discount 15–25% in your head for taxes and volatility, but it's real, countable money.

Startup options are a different animal: value = (exit value − strike price) × shares × probability of a meaningful exit. Be brutally honest about that last term. Most startup equity ends up worth exactly $0. Unless the company is late-stage with clear metrics, treat options as a lottery ticket — a wonderful bonus if it hits, not compensation.

Interrogate the mechanics: vesting schedule and cliff (four years with a one-year cliff is standard; five-year or back-loaded is a pay cut in disguise), post-termination exercise window (standard 90 days is a trap; two-plus years is far more employee-friendly), refresh grants (without them your comp quietly declines after year two), and current valuation and runway.

Benefits have dollar values — use them

A $200/month health-insurance premium difference = $2,400/year. A 6% 401(k) match on a $160k salary = $9,600/year of free money. 15 vs. 25 days PTO = two full weeks of your life, every single year. These aren't perks. They're compensation with different names, and they belong in the spreadsheet.

The worked example

Offer A (public company): $165k base, 15% target bonus, $120k RSUs over 4 years, 4% 401(k) match, 20 days PTO.
Offer B (Series B startup): $150k base, 10% target bonus, 0.15% equity (options), 3% 401(k) match, "unlimited" PTO.

Year one, counted honestly: Offer A — base $165,000; bonus $22,275 (90% payout); equity $30,000 (RSUs); 401(k) $6,600; total $223,875. Offer B — base $150,000; bonus $10,500 (70% payout); equity $0 (options valued at $0 until exit); 401(k) $4,500; total $165,000.

That's a $58,875 gap in year one from a $15,000 base-salary difference. Over four years the countable gap grows to roughly $234,000.

For the startup equity to close that gap, you'd need something like a 20x outcome and a successful exit and staying all four years. Possible — but that's the lottery-ticket framing, and you should be honest with yourself about the odds.

To be clear: there are valid reasons to take Offer B anyway. Broader scope, faster learning, a team you admire, genuine conviction in the company — all legitimate. Just don't take it because the equity "might be worth millions" without running this math first.

Before you sign anything

Two rules. First: never accept on the spot. "This is exciting — can I have a few days to review everything?" Always. Second: the first offer is rarely the best offer. A polite counter with justification works far more often than engineers expect. Pick one thing to push on (base, equity, or signing bonus); signing bonuses are often the easiest yes since they're one-time. Negotiate over email when you can: it gives you time to think, creates a record, and removes real-time pressure.

The complete system — when to discuss comp at each interview stage, the exact script for answering "what are your salary expectations" without anchoring low, five counter-offer email templates, the equity interrogation checklist, and the full list of what never to say — is in the salary negotiation guide inside The Tech Job Search Kit ($39): https://cjettoostudent.gumroad.com/l/tech-job-search-kit

Do the math before you sign. It's the highest-paid hour of your career.

The 30-Minute LinkedIn Routine That Makes Recruiters Message You First

Chris — Tue, 29 Sep 2026 03:14:32 +0000

Most engineers treat LinkedIn like a digital filing cabinet: set it up once during a job hunt, then forget it exists. Meanwhile, recruiters live on LinkedIn. A huge share of tech hiring starts with a recruiter search — not with your application.

That means your LinkedIn profile isn't a resume backup. It's a landing page. And right now, for most engineers, it's a landing page with no headline, no call to action, and no reason for anyone to stay.

The good news: you don't need to become a "LinkedIn influencer." You need about 30 focused minutes a week — once the profile itself is fixed.

Fix the headline first — it's a search field, not a job title

Your headline is the single most-searched field on LinkedIn. Recruiters search by title + technology + location. "Software Engineer at Acme Corp" wastes that field on information LinkedIn already displays in your experience entry.

Write for the search instead:

Active job seeker: Full-Stack Engineer | React, TypeScript, Node.js | SaaS & Fintech | Open to Remote Roles
Specialist: Backend Engineer specializing in distributed systems | Java/Spring Boot | 10M+ req/day
Career switcher: Frontend Engineer | React, TypeScript | ex-Teacher bringing curriculum-design rigor to UI
Senior/staff: Staff Software Engineer | Platform & Infrastructure | Led teams of 8 | Fintech

A few rules: use standard titles recruiters actually type ("Frontend Engineer," not "Code Ninja"). Include your top 3–4 technologies — these are keyword fields. Set your location to your metro area or "Remote," because recruiters filter by it.

And turn on "Open to Work." The old advice that it signals desperation is outdated — it increases inbound. If you're employed and hunting quietly, use the private "visible to recruiters only" setting.

Rewrite your About section in three paragraphs

First person. No buzzword soup. Three short paragraphs:

Who you are (2 sentences): "I'm a [title] with [X] years building [what] with [stack]. Currently focused on [specialty]."
Proof (3–4 sentences): your biggest achievement with a number, one more proof point, and one genuine engineering value. Pick one that's actually true.
Call to action (1–2 sentences): what you're looking for and the best way to reach you.

Compare that to what most profiles have: "Passionate software engineer with experience in full-stack development." That could describe literally every engineer on the platform. It's invisible. Replace every adjective with evidence.

Curate your Featured section — it's above the fold

The Featured section renders above your experience, which makes it prime real estate. Put exactly three things there:

Your best proof of work — a blog post, a conference talk, a project with your name on it.
Your resume as a PDF. Recruiters who find your profile want it in one click.
One personality signal — an open-source contribution, a thoughtful post, a side project.

Rotate these quarterly. A featured post from 2021 signals a dormant profile.

Prune your skills list

Keep the list to 15–20 max. Pin your top 3 to match your target roles. Delete aspirational skills you can't defend in an interview: if a recruiter finds you via "Kubernetes" and you fumble the technical screen, you've burned a lead.

One more high-leverage move: ask 3–5 former colleagues for short written recommendations (not endorsements — actual recommendations, a paragraph each). The ask is simple: "I'm job hunting and building out my LinkedIn — would you be open to writing 2–3 sentences about working together on [project]? Happy to return the favor."

Don't copy-paste your resume into the Experience section

Your LinkedIn experience is not your resume. Different medium, different reader, different rules. Keep 3–4 bullets per role (fewer than a resume — LinkedIn readers skim harder), and make the first bullet the headline achievement. Include one or two things a resume would cut for space: the interesting side project, the tech talk you gave. Attach media where it exists — the architecture write-up, the shipped product link.

The 30-minute weekly routine

Monday (10 min) — Visibility. Comment thoughtfully on 3–5 posts from engineers, hiring managers, or companies you follow. Not "Great post!" — add a sentence of substance or a genuine question.

Wednesday (10 min) — Outreach. Send 5 connection requests with personalized notes to engineers at target companies, plus 2 to recruiters. Always add a note — blank requests from strangers get ignored.

Friday (10 min) — Content or maintenance. Every other week, post something small: a thing you learned, a project update. On the off weeks, improve one profile section, request a recommendation, or prune your skills list.

That's the whole system. Consistency beats intensity.

Want the full playbook?

This is the short version. The complete LinkedIn playbook — all five headline formulas with filled examples, the About-section template, the Experience-vs-resume structure rules, connection and referral DM scripts, the skills triage, and a full before/after profile teardown — is one of seven components in The Tech Job Search Kit ($39): https://cjettoostudent.gumroad.com/l/tech-job-search-kit — which also covers ATS resumes, interview prep, outreach scripts, and salary negotiation.

Your move: open your profile right now and rewrite the headline. It's the highest-leverage five minutes in your entire job search.

Why Your Engineering Resume Might Never Reach a Human (And How to Fix It in 20 Minutes)

Chris — Tue, 29 Sep 2026 02:56:34 +0000

You can be the perfect candidate for a role and never get a callback — because your resume sat in a database nobody ever queried.

Most mid-to-large companies run every application through an Applicant Tracking System (ATS) before a recruiter glances at it. The ATS doesn't "read" your resume like a person. It parses it: rips the text out of your file and tries to slot it into fields — name, title, skills, experience. If your resume is built like a design portfolio, the parser mangles it, and your application shows up as gibberish.

Here's the uncomfortable truth: the fanciest resume template is often the worst one for getting hired.

What the ATS actually does to your resume

Think of the parser as a very literal, very dumb reader. It goes top to bottom, left to right, extracting plain text. Anything that isn't plain text in a single column confuses it.

1. Multi-column layouts scramble your content. That sleek two-column template — skills sidebar on the left, experience on the right — gets read as one interleaved stream of text. "React" from your sidebar lands in the middle of a job bullet. Some parsers try to reconstruct the order and fail; the result is a jumbled mess no recruiter will bother decoding.

2. Tables, text boxes, and graphics are invisible or garbled. Parsers frequently can't read text inside tables or text boxes at all. Your carefully formatted experience section can parse as empty. Icons, skill-bar charts, and headshots are worse than useless — the parser ignores them, and the human never gets the chance to see them because the parse failed first.

3. Headers and footers get skipped. Some parsers ignore header and footer content entirely. If your name, phone number, and email live in the header, the system may file your application with no contact info attached. Keep everything in the body of the document.

4. Non-standard fonts and sloppy filenames create friction. Decorative or custom fonts can fail to embed or render in the parser — stick to Calibri, Arial, Helvetica, Georgia, or Garamond. And when a recruiter downloads resume_final_v3_UPDATED.pdf, it looks sloppy. Hiring is a game of small signals; don't waste any.

5. Keyword mismatch kills you silently. Recruiters search the ATS database by keywords: "React," "TypeScript," "AWS." If the job posting says "TypeScript" and your resume only says "TS," some parsers won't match them. If the posting says "Amazon Web Services (AWS)," use both forms at least once — parsers and humans search both.

The 20-minute fix

You don't need a redesign. You need a de-design. Here's the checklist:

Go single-column. One column, top to bottom. No sidebars, no exceptions.
Strip tables, text boxes, columns, graphics, icons, and headshots. All of them.
Use a standard font at 10.5pt minimum for body text.
Move contact info into the body — name, phone, email, city/state, LinkedIn URL, GitHub URL, all as plain text.
Use simple section headers: EXPERIENCE, SKILLS, EDUCATION. Bold or slightly larger is fine; colored banners are not.
Keep dates consistent everywhere: Jan 2023 – Present, not 1/23 – now in one place and something else in another.
Use standard job titles. An ATS searching "Frontend Engineer" may never match "UI Wizard" or "Code Ninja."
Export as PDF from Google Docs or Word (not a scanned image, not "Print to PDF" from a design tool), and name it FirstName-LastName-Resume.pdf.
Test selectability: open the PDF and try to highlight your phone number with your cursor. If you can't select it as text, the ATS can't read it either.
Run the 10-second plaintext test: copy your entire resume and paste it into a plain text editor. If it reads in a sensible order, the parser will handle it. If it's scrambled, fix the layout until it isn't.

That last test is the single most useful thing in this article. Run it before every application.

Keywords: mirror, don't stuff

Pull up the job description and note the exact terms it uses — "React," "Node.js," "PostgreSQL," "CI/CD." Now check your resume: do those exact terms appear in your experience bullets, describing work you actually did?

Honest keyword optimization is just good writing: describe your work using standard industry terms. If you built APIs in Express, write "Node.js/Express" at least once, because that's what the recruiter searches. If the posting says "Kubernetes," and you've genuinely used it, make sure the word appears — don't assume "container orchestration" will match.

What not to do: a hidden block of white-on-white keywords at the bottom. Some parsers flag keyword stuffing, and if a human ever selects the text and sees it, your credibility is gone. Write the terms into real bullets about real work.

One more thing: bullets matter more than templates

An ATS-safe resume gets you parsed. But a human still has to want to interview you, and the difference between a bullet that gets skimmed and a bullet that gets you a call is specificity:

Weak: "Worked on the company dashboard using React."
Strong: "Rebuilt the analytics dashboard in React + TypeScript, cutting load time from 4.2s to 1.1s and lifting weekly active usage 35% among 2,000+ users."

Same work. One gets interviews; the other doesn't. The formula: specific action + quantified outcome + scale.

If you want a head start

Getting all of this right from a blank page takes a while, which is why I put together the ATS Resume Template Pack for Software Engineers ($15): three ATS-safe templates — a classic single-column, a skills-forward layout for career switchers and bootcamp grads, and a senior/staff version — plus the 20-minute setup guide and the full ATS checklist from this article: https://cjettoostudent.gumroad.com/l/ats-resume-template-pack

But honestly? Even if you never buy anything, run the plaintext test on your resume today. Twenty minutes, and you’ll never again wonder whether a parser mangled your application.

How to Actually Diagnose a Postgres Deadlock in a Spring Boot App

Chris — Tue, 29 Sep 2026 02:34:56 +0000

Prerequisites: Spring Boot 3.x, Postgres via Docker, basic JPA.

The pager goes off: PSQLException: deadlock detected. Your first instinct is to slap @Retryable on the service and go back to sleep. Sometimes that even works — which is exactly why it's dangerous. Retry hides the bug; the deadlock keeps happening, just quieter. In this post I'll show you how to reproduce a Postgres deadlock in five minutes, read the error properly, map it back to your code, and fix the root cause — a lock-ordering bug — instead of papering over it with retries.

Reproduce it in 5 minutes

Two @Transactional methods locking the same rows in opposite order. Docker Postgres, Spring Boot 3.x:

@Service
public class TransferService {

    @PersistenceContext
    private EntityManager em;

    // Thread A: locks account 1, then account 2
    @Transactional
    public void transferAtoB(Long a1, Long a2, BigDecimal amount) {
        Account from = em.createQuery(
            "SELECT a FROM Account a WHERE a.id = :id", Account.class)
            .setParameter("id", a1)
            .setLockMode(LockModeType.PESSIMISTIC_WRITE)
            .getSingleResult();
        sleep(500); // widen the race window so it deadlocks reliably
        Account to = em.createQuery(
            "SELECT a FROM Account a WHERE a.id = :id", Account.class)
            .setParameter("id", a2)
            .setLockMode(LockModeType.PESSIMISTIC_WRITE)
            .getSingleResult();
        from.debit(amount); to.credit(amount);
    }

    // Thread B: locks account 2, then account 1 — opposite order
    @Transactional
    public void transferBtoA(Long a1, Long a2, BigDecimal amount) {
        // ... same shape, locks a2 first, then a1
    }
}

Run both concurrently. You'll get the deadlock on demand.

Read the error — actually read it

Postgres tells you everything in the DETAIL line:

ERROR: deadlock detected
DETAIL: Process 1234 waits for ShareLock on transaction 5678; blocked by process 9012.
Process 9012 waits for ShareLock on transaction 1234; blocked by process 1234.

Two processes, each waiting on the other. That's the whole story: a lock-ordering bug, not a database problem.

Find it while it's happening

Three things to run against Postgres during (or right after) an incident:

-- 1. Who is blocked right now?
SELECT pid, usename, query, state, wait_event_type, wait_event
FROM pg_stat_activity
WHERE datname = current_database() AND pid <> pg_backend_pid()
  AND wait_event_type = 'Lock';

-- 2. The full blocker → blocked graph
SELECT blocked_locks.pid AS blocked_pid,
       blocking_locks.pid AS blocking_pid,
       blocked_activity.query AS blocked_query
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity
  ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
  ON blocking_locks.locktype = blocked_locks.locktype
 AND blocking_locks.relation = blocked_locks.relation
 AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity
  ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

And to catch the next one with full context, enable this once:

ALTER SYSTEM SET log_lock_waits = ON;
SELECT pg_reload_conf();

Now every lock wait over deadlock_timeout lands in the Postgres log with the offending query attached.

Once you have the blocked query text, trace it back to your code. The query in blocked_query is the raw SQL Hibernate issued — table names, locked columns, and the WHERE clause it locked on. Enable SQL logging in dev (spring.jpa.show-sql=true or a DataSource proxy like p6spy) so you can see every query your app issues with the repository method that triggered it. Take the SQL from the blocker query, grep it against your query log, and you'll land on the exact repository methods or @Query annotations on both sides of the conflict — the two code paths whose lock acquisition order forms the cycle. In our example, the log would show one path locking account rows ordered 1 → 2 and another locking them 2 → 1, and that's your bug: the two methods.

The fix: order your locks

The rule: within a transaction, always acquire row locks in the same deterministic order — e.g., ascending ID:

@Query("SELECT a FROM Account a WHERE a.id IN :ids ORDER BY a.id")
@Lock(LockModeType.PESSIMISTIC_WRITE)
List<Account> lockAllOrdered(@Param("ids") List<Long> ids);

Both threads now lock account 1 before account 2. No cycle, no deadlock. One thread waits briefly; nobody dies.

Two more things people get wrong:

Isolation levels. Postgres defaults to READ COMMITTED, which is correct for most of this. Reaching for REPEATABLE READ or SERIALIZABLE increases deadlock/failure rates — don't escalate isolation to fix a locking bug.
Retry. Retry is for the unavoidable remainder (two genuinely concurrent writers), not the systematic case. And if you retry, be specific:

@Retryable(
  retryFor = { DeadlockLoserDataAccessException.class,
               CannotAcquireLockException.class },
  maxAttempts = 3,
  backoff = @Backoff(delay = 200, multiplier = 2.0)
)

Retrying on generic DataAccessException will retry things that will never succeed. Be precise.

TL;DR

Deadlocks are a lock-ordering bug in your code, not a Postgres tuning problem. Reproduce → read the DETAIL → map it to the two code paths → lock in a consistent order → retry only the narrow exception types.

I'm turning this into a full field guide — 10 production incidents like this (N+1s, pool exhaustion, OOMs, Kafka lag…) each with diagnosis steps, fixes, and prevention checklists, plus a complete Spring Boot → AWS deployment walkthrough. Preorder is $49 (goes to $79 at launch): https://cjettoostudent.gumroad.com/l/spring-boot-production-rescue-kit