How to get hired as a software engineer in 2026-27

What "software engineer" means on a 2026 posting, read the verbs before you apply

"Software Engineer" is the least informative title in tech. The same two words are used for a new graduate fixing bugs in a ticket queue and for the person deciding whether a company moves off its monolith. "Software developer" is the same job under a different label at most employers, where a distinction is drawn, "engineer" sometimes implies more design and systems scope, but that varies by company rather than following a rule. Judge the posting by its verbs and its loop, never by which of the two words is in the title.

The fastest read is the verbs. Fix, implement, assist, contribute, participate means they expect to supervise you, entry or early career, and your job in the loop is to show you can be trusted with a change. Own, design, lead, drive, define means they expect you to decide things and defend them, mid to senior, and the loop will include design and a deep dive on a past decision. On-call, operate, scale, reliability means a production-facing role where debugging a live system matters more than writing a clean class.

The second read is the stack, and specifically whether the posting names one at all. A posting naming a precise stack ("Go, Postgres, Kubernetes, AWS") usually means a team with an existing system that needs someone productive in it quickly; mirror those nouns exactly. A posting saying "strong fundamentals, language agnostic" usually means an employer that interviews on general problem solving and will teach you their stack, commonly large employers and new-grad programmes. A stack-specific resume sent to a fundamentals employer is wasted effort, and the reverse gets you filtered by a recruiter matching keywords.

The third read is the hidden title. Many postings called Software Engineer are really something else: a data-heavy role, a platform or DevOps role, an integrations or forward-deployed role, a QA-automation role, or an AI application role. Those have different loops and different resumes. If the responsibilities spend more lines on pipelines, Terraform, customers or evals than on product code, treat it as that role instead.

• Entry / early career signals: "0-2 years", "new grad", "under the guidance of", "learn our codebase", "pair with senior engineers", degree listed as required.
• Mid-level signals: "3-6 years", "own features end to end", "mentor junior engineers", "participate in design reviews", an on-call rotation mentioned matter-of-factly.
• Senior and above signals: "lead technical direction", "influence across teams", "make build-vs-buy calls", "define standards", and a loop description that includes system design.
• Not-actually-a-SWE-posting signals: Terraform and Kubernetes in the first three bullets (platform), dbt and warehouses (analytics engineering), "customer-facing" plus travel (forward deployed), "evals", "retrieval" and "guardrails" (AI engineer).
• Sponsorship signals, which decide whether you should apply at all: "must be authorized to work in the US without sponsorship", "we are unable to sponsor", or "US person" / "ITAR" / "must hold or be eligible for a clearance".

How you actually become a software engineer, and what the entry-level squeeze really is

There are four routes in and they are not equally good, but all four are used. A CS or adjacent degree, with internships, is still the widest door and the only one most new-grad programmes accept. A bootcamp buys structure, a cohort and a deadline; it no longer places people into a market short of juniors, and published placement rates should be treated as marketing unless independently audited, judge one on whether it teaches testing, debugging, databases, deployment and reading unfamiliar code, not on which frameworks it covers. Self-teaching works and takes longer than anyone budgets for. And the quietest route is sideways: QA, support engineering, IT, data analysis, implementation consulting or an internal-tools job at a company whose product is not software, then moving into engineering from inside, where you have colleagues who have seen you work.

Whichever route you take, the sequence that ends the search is the same, in this order. Learn one language properly rather than four badly, with its real behaviour, integer division, string immutability, how its hash map orders, how its runtime does concurrency. Learn SQL and a relational database. Learn Git, testing and how to read code you did not write. Then build and deploy one thing that solves a real problem for people who are not you, and keep it running for months while they complain about it. Then get a reference and a referral out of that work. The project with users is not a portfolio ornament; it is the thing that substitutes for experience you do not have.

Now the squeeze, because the two common stories are both wrong. The defeatist story says AI eliminated junior engineering and you should not bother. The denial story says nothing changed and you should apply harder. What is observable is that entry-level software hiring contracted sharply from 2022-2023 and has not returned to 2021 levels while the number of people competing for those roles rose. You do not have to take that from me, the series that show it are public: BLS JOLTS job openings for the information sector, Indeed Hiring Lab's software-development job-postings index, NACE's new-graduate hiring surveys, and the CRA Taulbee survey for how many CS degrees are being produced. Read them for the shape rather than trusting a number in any article, including this one.

Three forces stack here and it is worth keeping them apart. The first wave of contraction was financial (the end of cheap capital, an over-hiring correction, headcount discipline) and it happened before AI-assisted coding was broadly adopted. AI-assisted coding then changed the economics of the work juniors used to be given: the small, well-specified, heavily reviewed task is exactly what an assistant does cheaply, which weakens the traditional argument for hiring someone to do it for a year while they learn. On top of both, application volume per posting rose because applying is automated now, so a posting can draw a thousand applications that all look tailored.

The part the defeatist story leaves out: companies still hire juniors, and the ones who get hired are not distinguished by application volume. They are distinguished by three things, in descending order of power, a referral or prior relationship with the team, a real internship or apprenticeship, and a thing they built that other people use. That third one became disproportionately valuable precisely because AI made code cheap. If anyone can generate a CRUD app, having one is worthless; having one that twenty strangers use every week and that you have kept running for eight months is evidence of judgement, operations and persistence, which a generator cannot produce.

So invert the search. Mass applying to the headline companies with public new-grad programmes is a lottery with terrible odds, and it is where most candidates spend most of their effort. Better allocation: companies where you can reach a human, applied to properly; small and mid-size employers with no recruiting brand, who get a fraction of the volume and actually read applications; and the unglamorous sectors, government contractors, defence, healthcare, insurance, logistics, manufacturing, utilities, universities, state and local government, and the internal engineering teams of companies that do not sell software. They hire steadily and they will teach you production software. An unglamorous first job with real users fixes the experience problem in twelve months. A year of applying to the same thirty companies does not.

One honest caveat on the "get experience by freelancing" advice: for engineers aiming at employment it is weaker than it sounds, because gig-site work and a logo-shuffling portfolio read as unverifiable to a hiring manager. What works is scoped work for a named, reachable organisation that will confirm it, a nonprofit's booking system, a research group's data tool, a small business's internal dashboard. Time-box it: one deliverable, six to eight weeks, agreed in writing up front, with a reference, a public deployment and permission to describe the work as the payment. Unpaid work with no scope and no end date is not experience, it is just unpaid work.

• Allocate effort roughly in thirds: people (former colleagues first, then meetups, open-source maintainers, alumni), small and unbranded employers, and the structured programmes everyone else is also applying to, not all of it in the third bucket.
• Treat "no experience" as a thing to remove, not to argue around. One deployed project with real users and eight months of uptime removes it faster than any phrasing on a resume.
• Apply the day a posting appears where you can. On high-volume postings the funnel is often effectively full within days.
• Interview for jobs you do not want, early. The loop is a skill and it decays; the first two are always the worst ones.
• Ask every employer who rejects you whether they will consider you for other requisitions, and diarise a re-application in six to twelve months. A recruiter who has already read your resume is a warm contact, not a closed door.

The loop, stage by stage: starting with the timed online assessment

The stage most articles skip is the one most entry-level candidates hit first. At many large employers, and at nearly every new-grad programme, the first gate is not a human: it is a timed online assessment, sent automatically within days of your application, hosted on HackerRank, CodeSignal, Codility or the employer's own platform. Typically 60 to 90 minutes, two to four problems, auto-scored against hidden tests, with partial credit for passing some of them. Often nobody reads it unless your score clears a threshold, and the threshold is not published. It usually has an expiry date, and letting it expire is a withdrawal.

Prepare for it as an exam, because that is what it is. Sit it on a laptop with a real keyboard and a stable connection, not a phone and not hotel wifi. Read all the problems before starting the first one, because they are rarely in difficulty order and the clock does not care. Write a brute-force solution that passes the small cases before optimising, partial credit is real and an elegant half-finished answer scores zero. Handle the empty input, the single element and the maximum size, because the hidden tests are mostly edge cases. If the platform offers a practice assessment, take it first for the interface alone.

The AI policy on an online assessment is usually "no assistance", enforced by honour system, sometimes a camera or a browser lockdown, sometimes a plagiarism and keystroke check, and sometimes by a later live round where you are asked to re-solve or extend your own submission. That last one is the real enforcement: treat anything you submit as something you will be asked to explain line by line.

After the assessment the loop is conventional, with two structural changes since 2021. Multi-hour unpaid take-homes have become harder for employers to justify, because an assistant finishes a typical one in minutes, so a take-home now usually comes with a live follow-up where you extend or defend what you submitted. The submission is no longer the evidence; the conversation about it is. And debugging and code-review rounds have become noticeably more common, because they test the thing AI made scarce rather than the thing it made cheap.

Ask the recruiter three questions in writing before the loop: how many rounds and what each one is, whether AI assistance is permitted in the technical rounds and in what form, and whether any round is in person or proctored. Recruiters answer these readily. Candidates who do not ask walk in with the wrong preparation, and the AI question in particular is not one you can guess.

• Online assessment (60-90 min, often first). Graded by a machine on hidden test cases with partial credit. Prepare like an exam, do not sit it cold, do not let it expire, and expect to defend your own code later.
• Recruiter screen (20-30 min). Graded on whether your background matches the posting's vocabulary and level, plus logistics: location, work authorisation, compensation expectations, notice period. Have a 90-second version of what you have shipped and one sentence on why this company. Ask the three questions here.
• Technical screen (45-60 min, live). One coding or debugging problem in a shared editor. Largely pass/fail on whether you can turn a spec into working, tested code while talking. Running code beats elegant code that does not compile.
• Coding rounds at the onsite (1-2 × 45-60 min). Graded on decomposition, correctness at the edges, how you test, and how you react when the interviewer changes the requirement halfway. Senior candidates are also graded on whether they establish constraints before writing.
• System design (45-60 min, mid-level and up). Graded on requirement gathering, explicit trade-offs, what you would measure, and under what condition you would reverse the decision.
• Behavioural / hiring manager (45-60 min). Graded on ownership, how you handle disagreement, and whether your stories contain decisions rather than chronology.
• Code review or bug hunt (increasingly common, 45-60 min). You get a diff or a failing repository and are asked what is wrong. Graded on what you notice: a correctness bug, missing error handling, a concurrency hazard, a test that asserts nothing.
• Hiring committee (large employers, after your loop, you are not in the room). This is why a strong onsite can be followed by three weeks of silence.

Software engineer interview questions, and what each one is actually grading

These are the real questions, in the words they are asked in. Prepare answers out loud, to a timer. An answer that runs ten minutes fails regardless of content; two minutes with a decision in the first thirty seconds passes.

On the four behavioural prompts below, every strong answer has the same shape: a decision you made, the alternative you rejected, what it cost, and what you would do differently. A chronology in which everything went fine is not an answer.

On system design, grading is not whether your design matches the interviewer's. It is whether you behave like someone who can be trusted with a decision. Spend the first five to eight minutes not drawing: get the numbers (how many users, read-to-write ratio, perceived latency, what must never be lost, what may be stale and for how long, which failure the business cannot tolerate), then state your assumptions aloud so they can be corrected. Design the simple thing first and say you are doing so (one service, a relational database, a cache if the read pattern warrants one, a queue where the work is genuinely asynchronous) and add complexity only when you can name the pressure forcing it. Then cover the parts candidates usually skip: what happens when a dependency is down, how a retry does not duplicate a payment, how you migrate to this design with the system live, what goes on a dashboard versus what pages someone, and what it costs per month. Senior candidates are expected to raise cost unprompted. Very few do.

Do not bluff an unfamiliar technology in any round. "I have not run that in production; here is what I would want to find out before committing to it" is a strong answer. A fabricated opinion is detected fast and taints everything after it.

• "Tell me about something you shipped end to end." Grading: scope, your actual contribution versus the team's, and whether you know what happened after launch, adoption, incidents, what you changed afterwards.
• "Tell me about a time you broke production." Grading: whether you own it without theatre, how you detected it, how long recovery took, and the systemic change you made so it cannot recur silently. Candidates with no such story read as having never been trusted with anything.
• "Tell me about a technical decision you made and why." Grading: the rejected alternative. "We chose Kafka because it is the industry standard" fails. "We chose Kafka over a database queue because we needed replay for the reconciliation job and two consumers with different retention; the cost was an extra operational surface and a week of consumer-lag debugging, and honestly a Postgres queue would have held for another year at that volume" passes a level above the one you applied for.
• "Tell me about a disagreement with a colleague or a manager." Grading: whether you can disagree on technical grounds, change your mind on evidence, and commit to a decision that went against you without relitigating it for six months.
• "Design a URL shortener." Grading: key generation and collisions, the read-heavy ratio and therefore caching, what you do about custom aliases, expiry, and the analytics write path that is actually the hard part.
• "Design a notification or feed system." Grading: fan-out on write versus on read and when you would switch, idempotency and deduplication, ordering guarantees you actually need, and what happens to a user who has been offline for a month.
• "Design a ticket-booking system." Grading: inventory contention, holds, timeouts, double-booking under concurrent purchase, exactly-once charging against an unreliable payment provider, and what the user sees when the hold expires mid-checkout.
• "Here is a pull request. What is wrong with it?" Grading: what you notice and in what order. Say what you are checking for rather than reading top to bottom, correctness at boundaries, error handling, a race, an N+1 query, a retry without an idempotency key, a test that asserts nothing, a secret in a config file.
• "This test fails intermittently. Find out why." Grading: method over luck. Reproduce it reliably first (seed, ordering, clock, shared state), form one hypothesis at a time, and say what evidence would eliminate each.
• "Walk me through debugging a production latency spike." Grading: whether you start from a measurement rather than a guess (which metric moved, when, what else changed, which dependency, which query) and whether you name real tools: traces, logs, a flame graph, a slow-query log, a bisect.
• "What are your questions for us?" Ask five: what the first ninety days look like; how a change reaches production and how long that takes; what the on-call rotation really is and how often it pages; what the team's AI policy and approved tooling are; and what level this role is and what would move it up. The last two are the ones candidates skip and the ones that change your decision.

The coding interview now that AI writes code: and the question you must ask

The content of coding interviews shifted, and the shift is consistent even though employers' policies are not. Pure algorithmic puzzles have not disappeared, large employers still use them, and if you are interviewing at one, practise them. But weight moved toward problems where the answer is easy to produce and hard to be sure about: debug this, review this, extend this, explain why this is correct, what happens under concurrency, what does this do with an empty input and with ten million rows.

On AI policy there are three distinct employer regimes, and you cannot infer which one you are in from the company's size or how modern it sounds.

First regime: AI allowed and expected. You are given an assistant, sometimes the one they use internally, and the problem is deliberately bigger than you could type by hand in the time. What is graded is supervision, how you frame the request, whether you read the output before accepting it, whether you notice the subtle wrongness, whether you test, and whether you can explain the code you just accepted. The failure that gets candidates rejected here is accepting a plausible implementation and being unable to answer "why does this line do that". Slower but sceptical scores better than fast and credulous.

Second regime: AI explicitly forbidden and enforced, screen share, a lockdown browser, a proctor, or an in-person round added back for exactly this reason. You will often hear about it from the recruiter unprompted, because they have learned that candidates are surprised by it; if yours does not volunteer it, ask. Here you need unassisted fluency: standard library from memory, no autocomplete, able to write a correct binary search or a hash-map pass without help. If you have spent two years with an assistant always on, this feels far worse than you expect. Practise without it before you need to.

Third regime: unstated, and the interviewer may not know their own employer's position. Ask anyway. If it is still unclear, default to working unassisted and say out loud what you would normally reach for: "in my editor I'd have a model draft this parser and I'd review it; I'll write it by hand so you can see the reasoning." That sentence costs nothing and resolves the ambiguity in your favour.

Two things regardless of regime. Narrate: state your assumptions, name the approach you are rejecting and why, say what you will test before you test it. And leave time to verify, walk one real input through your code out loud, then an edge case. Candidates lose far more offers to a wrong answer delivered confidently than to a slow one.

• Practise both modes deliberately. Two sessions a week unassisted for fluency; the rest on real repositories with your usual tooling, which is what the job is.
• Build a debugging rep, not just a solving rep: take an open-source repository, break something non-obvious, and fix it from a failing test. This is what the newer rounds test and almost nobody practises.
• Know your language's actual behaviour cold: integer overflow and division, string immutability, hash-map ordering, how its concurrency model really works. These separate "wrote it" from "understands it".
• Never claim you wrote something you cannot explain. Interviewers probe exactly there, and one "I'm not sure why that works" after a confident claim ends the loop.

The resume: shipped things, scope, and numbers with units

Start with how a resume is physically read, because it explains every formatting rule worth following. Applicant tracking systems extract text from your PDF and linearise it, and multi-column layouts have been mangled by that extraction for over a decade, a sidebar's text gets interleaved into the body, dates detach from titles, and a skills column arrives as a run-on line. Then a recruiter skims the result for about ten seconds. Some ATS vendors now also generate a short summary of the extracted text for the recruiter, which makes the quality of that extracted layer matter more, not less.

So the rule is not "never use two columns". The rule is that the text layer must read in the right order, and that is testable in thirty seconds: export the PDF, select all, paste into a plain text editor, and read it top to bottom. If your titles and dates come out interleaved with a sidebar, the screen reads it that way and you should change template. If the main column extracts cleanly and the sidebar follows it intact, a sidebar design is fine. Run that test on whatever you send, from whatever tool you built it in, ours included. What is never fine, regardless of layout: a photo, skill-percentage bars, information carried only in a graphic, and skills buried in prose.

Structure, boring on purpose: name and contact, an optional two-line summary only if you are changing direction, experience in reverse chronological order, a skills block, education, then projects, projects move above experience only if you have no professional experience. Every bullet has a shape: what you did, to what, with what measurable result. The result is the part most candidates omit, and "I don't have numbers" is almost never true, you have users, requests, latency, error rates, build times, incident counts, support tickets, revenue, cost and time. If the exact figure is confidential or unknown, give an honest approximation and mark it as one ("roughly 40,000 monthly active users"), or give the lever without the sensitive number ("cut median checkout latency by about 60%"). Never invent precision. Interviewers ask where a number came from, and an invented one unravels the page it sits on.

On open source and side projects, the honest answer: for most employers contributions are not required and their absence is not held against you, plenty of strong engineers have none, and a drive-by typo fix on a famous repository fools nobody. What moves a hiring manager is a shipped thing with users, maintained over time. A tutorial clone, a to-do app or a repository with one commit and a generated README is worse than nothing, because it signals you think that counts. If your projects are not real, leave the section out and spend the effort making one real. Open source genuinely matters in three places: developer-tools companies, infrastructure and database companies, and any team maintaining the library you contributed to, where a merged non-trivial PR works almost like a referral.

Two details that cost people interviews quietly. Dates: state employment months and years plainly; a gap needs no explanation on the page, just one calm sentence ready for the screen, and obscuring dates to hide a gap costs more trust than the gap would have. And work authorisation: if your status removes a question, citizen or permanent resident for cleared or export-controlled work, one line near the top saves a recruiter a guess. If it does not, leave it off the resume and answer the application form honestly.

• Good: "Rebuilt the order-import path (Python, Postgres, SQS): 140 endpoints migrated with no customer-visible downtime, p99 1.8s → 240ms, on-call pages for this service from about 20/week to 3."
• Weak: "Responsible for backend development and performance optimisation using modern technologies in an Agile environment."
• Put stack nouns where a keyword match cannot miss them: in the bullets where you used them, and again in a skills block grouped as Languages / Frameworks / Data / Infra / Tooling. Do not pad to forty items, a panel reads a long list as a list of things you have heard of.
• List AI tooling specifically if you use it ("Claude Code, Copilot, Cursor" under tooling) and let the real evidence live in a bullet about review and verification. "Familiar with AI" on a 2026 engineering resume is a dead line.
• Make the repository readable in ninety seconds: a README that opens with what the thing does, a live link, who uses it, how to run it locally, and what you would fix next.
• Career changer: lead with the deployed project and its users, name the previous domain as the asset it may be (six years in claims processing is valuable to an insurer), and do not apologise anywhere on the page.
• Tailor by substitution, not rewriting: swap stack nouns and reorder bullets so the matching ones come first. A full rewrite per application is how people burn out at 200 applications with nothing to show.

Where these jobs are, how to reach a human, and what sponsorship changes

Most engineers' searches are limited by where they look, not by their skill. The large-brand postings on the big aggregators are the most competitive square metre of the job market. The same week, there are postings with a tenth of the applicant volume at companies you have never heard of, doing unglamorous work, that will hire you faster and teach you more.

Go to the applicant tracking systems directly. Greenhouse, Lever and Ashby host a large share of tech postings and index well; searching a stack plus a city plus one of those hostnames surfaces roles that never reach an aggregator's front page. Check company career pages for anywhere you actually want to work, because a posting is usually there first. And use the low-volume boards (a VC's portfolio job list, a local tech Slack or Discord, an alumni board) where a referral is one message away.

On referrals, what works is narrower than "network more". Find the engineer on that team, not a recruiter. Send three sentences: what you built, one specific opinion about their system or product, and the exact posting. Do not ask a stranger to "have a chat about opportunities". A referral costs them two minutes if you make it easy and half an hour if you do not, and that difference is most of your reply rate. Former colleagues are the highest-yield and most under-used contacts you have; a message to six people you worked with two jobs ago routinely outperforms a hundred applications.

Now the thing that decides where a large share of readers can apply at all, and which most guides give four words. If you need visa sponsorship, that is a filter on your target list before it is anything else. Nearly every application form asks whether you will now or in the future require sponsorship. Answer it truthfully, a false answer is a termination matter later, and in the fewest words the form allows; large-volume employers filter on that field automatically, so the honest answer plus a target list of employers who do sponsor beats a hedged answer to everyone.

Three things materially change your list. Cap-exempt employers (universities, affiliated nonprofit research organisations, nonprofit and government research organisations) can file H-1B petitions outside the annual cap and at any time of year, and they run large real systems that need engineers. Cap-subject employers can only enter you in a registration window once a year with an October start, so the calendar, not your readiness, sets the timing. And STEM OPT extensions require the employer to be enrolled in E-Verify and to sign a formal training plan, which means an employer that is not enrolled cannot host your extension even if they want you, ask early, because this is cheap to check and expensive to discover.

Policy in this area moved during 2025 and 2026, including on fees and process, with litigation still running. Do not take a fee, a deadline or lottery odds from any article, including this one: read the current position on uscis.gov, and ask the recruiter three questions in the screen, do you sponsor for this role, have you filed before for this team, and are you enrolled in E-Verify. Also note that export-controlled, ITAR and cleared work generally requires US citizenship or permanent residency and has no sponsorship path, which is why those postings say "US person" rather than "authorised to work".

Finally, run the search as a pipeline with stages rather than a stream of applications. Track where each application is and which stage you lose at, then act on the pattern: no replies means the resume or the targeting; failing the online assessment means timed practice; losing technical screens means fluency; losing onsites at design means design practice; losing the behavioural means your stories have no decisions in them. Most people apply more when the correct response is to fix one stage.

• Deliberate pass worth making: government contractors and defence, healthcare systems and health tech, insurance and claims, banks and credit unions, logistics and freight, manufacturing and industrial, utilities and energy, universities, state and local government, and internal engineering teams at companies whose product is not software.
• These are not consolation prizes. "Migrated a claims adjudication system with no lost transactions" is a stronger line than most consumer-app work.
• If you need sponsorship, build two lists: cap-exempt employers you can approach any time of year, and cap-subject employers whose timing is set by the annual registration window.
• Read a posting's authorisation language before you spend an hour on the application. "Must be authorized to work in the US without sponsorship" and "US person" are hard filters, not negotiable preferences.

What to be paid, and what to actually say

Do not negotiate off a figure from an article, including this one, not because numbers are unknowable, but because the real ones are published, dated and easy to pull yourself, and a quoted band goes stale and strips the context that makes it mean anything. Three sources, each answering a different question. The BLS Occupational Employment and Wage Statistics series under code 15-1252, software developers, gives you the employment-weighted reality: a median annual wage plus the 10th, 25th, 75th and 90th percentiles, nationally and by metropolitan area, from a new release each year for the prior May reference period. Pull your own metro's table, not the national one, the metro spread is the whole point, and remember OES counts wages, so it does not capture equity, which is most of the gap at the top tiers.

Second, the US Department of Labor's foreign labor certification disclosure data, published quarterly from LCA filings. For a given employer, job title, internal level and worksite city, it shows the exact base salary an employer filed under penalty of perjury. That is the most specific public number you can get about a named company in a named city, and its limitation is clean: base salary only, no bonus, no equity, so read it as a floor rather than a target. Third, levels.fyi, which is the best public map of how tiers and internal levels relate and the only one of the three that includes equity, but it is self-reported and its sample skews senior, big-tech and high-cost-of-living, so its medians are not the market's medians. Anchoring on it for a mid-size insurer in Ohio produces exactly the unserious number this section exists to prevent.

A growing set of states now require a pay range in the posting, and the list keeps expanding, so check your state and the employer's headquarters state rather than any list in an article, many employers post ranges nationally once one state forces them to. A posted range for the exact role and location is better than any survey.

Understand the three components before you talk. Base salary is what a lender cares about. Bonus is usually a target percentage, paid on company and individual performance. Equity is where tier differences live: at a public company, RSUs with a dollar value and a vesting schedule, which is close to deferred cash; at a startup, options with a strike price, a preference stack above you, and a real chance of being worth nothing. Treat startup options as a lottery ticket bought with foregone salary, and ask what determines their value: the strike, the last preferred price, total shares outstanding (not just your count), what happens on an exit, and the exercise window if you leave.

Levelling matters more than the title. The same work is "Senior" at one company and "SWE II" at another, and pay follows the internal level, not the words on the offer letter. Now the mechanics, because knowing where to look is useless if you do not know what to say.

• When the recruiter asks your expectations in the first call, do not name a number first: "I'd rather not anchor before I understand the level and scope. What's the band for this role at the level you're hiring at? If that's in range, I'm glad to keep going." If the form or the recruiter insists, give a range whose bottom you would genuinely accept, and source it out loud from the posted range or the OES percentile for your metro.
• Get the level and band before you invest in the loop, in writing: "Before I put four or five hours into interviews, what level is this requisition, and what's the base band for that level in <city>?" An employer who will not say is telling you something.
• With one offer and no competing process, the lever is not a bluff, recruiters check, and a collapsed bluff costs you the goodwill you need at your first review. Use: "Where in the band does this land, and what would move it up?" If the band is capped, negotiate the things that are not base: a signing bonus, an earlier review date with a written criterion, a larger initial equity grant, a start date that lets your other processes finish.
• Get it in writing before you resign anything: level, base, bonus target, equity grant with vesting schedule and the valuation it was struck at, start date, and the location or remote policy in exact terms. A verbal offer is not an offer; keep every other process running until a signed one exists.
• Ask two 2026-specific questions early, because both are cheap now and expensive after you accept: is remote pay location-adjusted and to what, and what exactly does "hybrid" mean, how many days, enforced how, and is the team actually in the office you would be assigned to.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Software engineer
• Software developer
• Backend development
• Frontend development
• Full stack development
• Python
• Java
• JavaScript
• TypeScript
• Go
• C++
• SQL
• React
• Node.js
• REST API
• GraphQL
• gRPC
• API design
• Microservices
• Event-driven architecture
• Message queue
• Kafka
• PostgreSQL
• Redis
• Caching
• Database schema design
• Query optimization
• Idempotency
• Concurrency
• Distributed systems
• System design
• Code review
• Unit testing
• Integration testing
• Property-based testing
• Test-driven development
• CI/CD
• Docker
• Kubernetes
• Terraform
• AWS
• Azure
• Google Cloud
• Observability
• Monitoring and alerting
• On-call
• Incident response
• Root cause analysis
• Performance optimization
• p99 latency
• Scalability
• Zero-downtime migration
• Technical design document
• AI-assisted development
• GitHub Copilot
• Cursor
• Claude Code
• LLM integration
• Retrieval-augmented generation
• Model evaluation
• Secure coding
• Authentication and authorization

Mistakes that cost people this job

Questions people ask