DEV Community: Chris

Freelance discovery calls: 15 questions that prevent most scope disasters

Chris — Sat, 10 Oct 2026 15:25:47 +0000

Discovery is one chapter of the system in The Freelancer Client-Acquisition Kit — 37 pages covering outreach, proposals, 2026 rate tables, contracts, retainers, and referrals, every data point labeled by source and evidence strength: https://cjettoostudent.gumroad.com/l/qfckgb

The 90-day freelance client plan: from zero to a full pipeline

Chris — Thu, 08 Oct 2026 15:28:56 +0000

"I need clients" is not a plan. Here is one, in three 30-day phases. It assumes you are starting from zero — no audience, no referrals, no pipeline. Each phase has one goal and a short list of actions. Do the actions, measure the one goal, move on.

Days 1-30: Become findable

Goal: a profile that converts a visit into a conversation.

Pick one niche to lead with. "Full-stack developer" is invisible; "I build booking systems for dental clinics" is searchable. You can always take other work — the niche is a door, not a cage.
Rewrite your LinkedIn headline for search: role, stack, proof. Add one featured item: your best project write-up.
Set up a simple portfolio page: three projects, each with the problem, what you built, and the outcome. Outcomes beat feature lists.
Tell everyone you know that you're freelancing and what you do. Not a mass blast — individual messages to 20 people. Referrals are the highest-converting channel in freelancing; most freelancers never activate it.

Measure: profile views and inbound messages per week. If nobody is finding you, the niche or headline is wrong — fix that before spending a dollar or an hour on outreach.

Days 31-60: Start conversations

Goal: 10 real conversations with potential clients per week.

Cold outreach, 5 messages a day, 4 days a week. Short: one signal you noticed, one proof point, one question. Follow up on day 4, 10, and 18 — most replies come from follow-ups, not first messages.
Answer questions in two communities where your niche hangs out. Teach in public; every good answer is a portfolio piece that compounds.
Ask every conversation, even dead ends: "Who else should I talk to?" Warm introductions beat cold messages every time.

Measure: replies and calls booked. If replies are under 10 percent after 100 messages, the problem is targeting or the first line — not volume.

Days 61-90: Convert and systematize

Goal: signed work and a pipeline that refills itself.

Run every call through the same discovery sequence: their problem, its cost, what success looks like. Quote Good/Better/Best tiers, never a single number.
Send every proposal within 24 hours. Follow up day 3, day 7, then a breakup note.
Start the retainer conversation at every project close: "Who handles this after launch?" One retainer changes the economics of the whole business.
Keep the outreach running at half volume even when you're busy. The famine always comes from the weeks you stopped prospecting.

Measure: proposals sent, close rate, pipeline value. A healthy pipeline holds 3x your monthly target in quoted work.

The part everyone skips

Track it all in one place: outreach sent, replies, calls, proposals, closes — by channel. After 90 days the data tells you exactly which channel deserves your hours. Most freelancers guess. You won't have to.

This plan is the short version of the system inside The Freelancer Client-Acquisition Kit — 37 pages with the outreach scripts, proposal structure, 2026 rate tables, contract clauses, retainer models, and referral engines, every data point labeled by source. The full pipeline, not just the plan: https://cjettoostudent.gumroad.com/l/qfckgb

8 client red flags every freelancer should memorize

Chris — Mon, 05 Oct 2026 15:33:06 +0000

Every freelancer has a story about the client they should never have taken. The details differ; the patterns repeat so reliably you can memorize them. Here are the eight, each with the response that saves you.

1. The fantasy budget

Champagne scope, tap-water budget. They want a full platform rebuild for the price of a landing page. Response: anchor to value, offer a smaller first phase at a real price, and walk away if they will not move. A client who will not pay properly will not behave properly either.

2. The no-contract client

"We don't really do contracts, we work on trust." Translation: they want all of the flexibility and none of the accountability. Response: no contract, no work. Ever. This one is non-negotiable.

3. Manufactured urgency

"We needed this yesterday!" — before you have even scoped the work. Sometimes urgency is real. Usually it is a negotiation tactic or a sign of an organization that plans nothing. Response: a rush fee, or a realistic timeline in writing. Watch which one they choose.

4. The "just" revision

"Just make the logo bigger" becomes a second unpaid project, one "just" at a time. Response: the change-order procedure, every single time. Written estimate, written approval, then work. No exceptions for small asks — small asks are how the big ones get in.

5. The committee

Five stakeholders, no decision-maker, feedback by consensus. Your two-week project becomes a two-month referendum. Response: name one decision-maker in the contract, with a 5-business-day feedback clause, or decline the project.

6. The badmouthing ex

They trash their last three developers unprompted. Every one of them was "terrible," "slow," or "impossible." Response: you will be number four. Decline politely and quickly.

7. The free-work audition

"Build us a small feature so we can evaluate you." Custom work, for free, for a stranger, with no commitment. Response: a paid discovery phase, or a portfolio walkthrough of similar work. Never free custom work — it selects for clients who do not value the work.

8. The scope fog

After two conversations they still cannot describe what they want. This is not always a bad client — sometimes they genuinely need help thinking. Response: sell a paid discovery phase that produces the scope. If they will not pay for thinking, they will not pay for building.

The meta-rule

Red flags cluster. One is a conversation. Three is a pattern. Walk away from patterns — the project you decline is never the one you regret.

This is one chapter of The Freelancer Client-Acquisition Kit — 37 pages covering outreach scripts, proposals, 2026 rate tables, contracts, retainers, referrals, and knowing when to walk away. Every data point labeled with its source and evidence strength. No guru fluff: https://cjettoostudent.gumroad.com/l/qfckgb

How freelancers actually get retainer clients: 3 models with real price points

Chris — Sat, 03 Oct 2026 15:26:01 +0000

Feast or famine is the default freelancer business model. Land a project, go heads-down for two months, surface to an empty pipeline, panic, discount the next project to fill the gap, repeat. Retainers break the cycle: recurring monthly revenue in exchange for reserved availability. Here are the three models that actually work, with the price points practitioners report.

Model 1: Maintenance and support

You keep the thing running — bug fixes, small improvements, monitoring, a monthly report on what changed and why. Typical range: $1,500 to $4,000 per month for small-to-mid clients. The easiest sell in freelancing happens at project close: "Who handles this after launch?" Ask it on every project. Half your retainers will come from that one sentence.

Model 2: Advisory

A set number of hours per month for architecture reviews, technical guidance, and team mentoring. Typical range: $2,000 to $6,000 per month. Clients are buying judgment, not keystrokes — position it that way in the proposal. Lead with the expensive mistakes you will prevent, not the hours you will spend.

Model 3: Fractional engineering leadership

Part-time CTO or tech lead for companies too small for a full-time hire: roadmap, hiring, technical decisions, team processes. Typical range: $5,000 to $12,000 or more per month. Highest value per hour, fewest slots available — take one or two at most, because each one consumes real attention.

The Day 1, 3, 5 upsell sequence

Do not pitch the retainer in the middle of the project, when the client is thinking about the current invoice. Pitch it at the close, when satisfaction is highest. Day 1: plant the seed in the wrap-up conversation — "Most of my clients keep me on for [model]." Day 3: send a one-page retainer proposal. Day 5: follow up once. After that, let it go. Chasing devalues the offer.

Watch the churn signals

Retainers die quietly. Unused hours piling up month after month means the client will cancel what they do not use — right-size the retainer before they kill it. A new internal hire in your lane, or budget-freeze language from finance, means renegotiate now. It is always cheaper to shrink a retainer than to replace one.

The anti-feast-or-famine math

Two retainers at $2,500 a month is $5,000 of baseline revenue — enough to cover most freelancers' floor. Project work on top becomes growth instead of survival. That is the entire game: turn the business from hunting into farming, one retainer at a time.

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

Freelance proposals that win: the 8-part structure (and 7 mistakes that kill deals)

Chris — Thu, 01 Oct 2026 15:26:02 +0000

Most freelancers lose the deal before the proposal is even read. They propose to the wrong client — no real budget, no decision-maker in the conversation — or they lead with themselves instead of the client's problem. A proposal is not a brochure. It is a sales document with one job: make saying yes feel safe.

The gate-check comes first

Before writing a word, confirm three things: a real budget exists, a real timeline exists, and the person you are talking to can say yes. If any answer is no, you are writing a free consulting document for someone who cannot buy. Decline politely or park it until the answers change.

The 8-part structure

Restate their problem in their words. This proves you listened, and it is the highest-trust sentence in the document.
Define what success looks like. The outcome, not the technology. "Checkout converts 15 percent better" beats "migrated to Stripe."
Your approach. Phases, what happens in each, and what you need from them. Clients fear black boxes; show the machinery.
Timeline with milestones. Dates, not durations. "Phase 1 complete Oct 20" beats "Phase 1 takes two weeks."
Deliverables. Numbered and verifiable. If it cannot be checked off, it is not a deliverable.
Investment. Good, Better, Best tiers (see below).
About you. Brief. Relevant proof only — one or two results that match their situation.
Next step. One clear ask: "Reply with your choice of tier and I will send the contract."

Good, Better, Best beats one number

Three tiers change the conversation from "yes or no" to "which one." Good is the minimum viable engagement. Better is the recommended scope — most clients land here, so build it carefully. Best is the full transformation. The middle tier anchors value and makes the decision feel safe.

7 mistakes that kill deals

Leading with your bio instead of their problem.
One price, take it or leave it.
Vague deliverables ("website redesign" with nothing verifiable).
No timeline — open-ended proposals signal open-ended projects.
Sending it and going silent. Proposals need follow-up too: day 3, day 7, then a breakup note.
Discounting on the first objection. Remove scope instead; a discount on identical work teaches the client the first price was theater.
Proposing to someone who cannot say yes. The gate-check exists for a reason.

This is one chapter of The Freelancer Client-Acquisition Kit — 37 pages covering outreach scripts, proposal structure, 2026 rate tables, contracts, retainers, and referrals. Every data point labeled with its source and evidence strength. No guru fluff: https://cjettoostudent.gumroad.com/l/qfckgb

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.