DEV Community: StackChief

October 2026 Jobs Report: Software Postings Climb, Software Firms Still Shrink

StackChief — Sat, 07 Nov 2026 16:54:30 +0000

The October 2026 jobs report gave software engineers two stories at once: tech job postings kept climbing, but employment at the firms that build and run software for others is still lower than a year ago. Here's the gap in numbers, and what it means if you're job hunting.

The headline

On November 6, 2026, the Bureau of Labor Statistics reported that US payrolls rose by 165,000 in October and unemployment was little changed at 4.1%. August and September were revised up by a combined 84,000. Professional and business services led with +70,000; the information sector was flat at −1,000.

Software-heavy industries are shrinking

The BLS doesn't publish a monthly "software engineer" count, but it does publish employment by industry. Year over year, October 2026 vs October 2025 (seasonally adjusted):

Industry	October 2026	Change
All nonfarm payrolls	159,293,000	+885,000 (+0.6%)
Computer systems design and related services	2,354,100	−25,600 (−1.1%)
Publishing (includes software publishers)	880,000	−23,500 (−2.6%)
Computing infrastructure, data processing and hosting	454,800	−25,900 (−5.4%)
Information sector (all)	2,734,000	−119,000 (−4.2%)
Management, scientific and technical consulting	1,905,700	+45,700 (+2.5%)

October was actually the first month of growth for computer systems design since May (+3,200), and September's 2,350,900 was its lowest level in the 34 months since January 2024. Since January 2024, that industry has lost 92,800 jobs (3.8%) while total payrolls grew 2.26 million (1.4%).

Hiring signals point the other way

CompTIA put October IT occupation unemployment at 2.8%, down from 3.3% in September, and new IT job postings at 290,892, 22.2% above October 2025.
Software developer and engineer roles led postings with 51,944 new listings, up 6.3% from September.
Indeed's software development postings index reached 81.6 on October 30, 2026 (February 2020 = 100), up from a low of 61.1 in May 2025.

Indexed to January 2024, software postings are at 112.4 while computer systems design employment has slid to 96.2.

What the data can't tell you

Industry counts aren't occupation counts: an engineer at a bank or hospital is counted in finance or health care. Postings aren't hires either; a rising index can mean more openings or openings that stay up longer. Neither the BLS nor CompTIA attributes the gap to AI or anything else. The last two months are preliminary and will be revised on December 4.

What this means for you

If you're job hunting:

Budget for a longer search than the postings count suggests, because more postings haven't turned into more net jobs at software firms.
Widen the employer list. Consulting added 45,700 jobs over the year while data processing and hosting lost 25,900, so engineering roles at consulting firms and non-tech employers belong on your list.
Read the seniority mix. Indeed Hiring Lab found that in Q1 2026, 69.3% of software development postings were senior and 4.5% entry-level, so rising postings help early-career candidates least.

If you're employed: don't read a 2.8% IT unemployment rate as safety. It's occupation-wide, and the industries most exposed to software budgets are the ones still shrinking.

The full post has the indexed chart, the industry breakdown and links to every BLS series: October 2026 Jobs Report on StackChief.

This post was written with the help of AI, as a summary of the StackChief article above.

Tests Pass, Exploits Still Work: What a 145-CVE Benchmark Says About AI-Generated Code

StackChief — Fri, 06 Nov 2026 16:54:27 +0000

"The tests pass" is how most of us accept a coding agent's work. For security-sensitive code, a new benchmark says that's a weak signal.

On November 4, 2026, eight researchers (Yu et al.) posted A.S.E 2.0 to arXiv. It tests how the repository context an LLM sees changes the security of the code it writes, using 145 tasks built from real CVEs in 51 open-source projects. Each task runs in Docker with functional tests and a validated proof-of-concept exploit, and counts as secure only if the tests pass and the exploit fails. It's a preprint, not yet peer reviewed.

Passing is not safe

Claude Code running Sonnet 4.5 passed the functional tests on 74.0% of tasks, but only 18.4% of its output was secure. 55.6% passed every test while a working exploit still succeeded.

That pattern held across every setup. As a share of test-passing output, 73.2% to 77.3% was exploitable, whether it was Claude Code, SWE-agent on Sonnet 4.5 or GPT-5.4, or plain retrieval with no agent loop.

Agents search for the wrong things

The agents read far more of the repository than any retrieval pipeline, yet saw the relevant safeguard (an existing validator or access policy) in only 27% to 36% of their runs. 71% of their search queries named functional things, such as a file format; only 9% named security concepts.

When the safeguard was in view, results changed:

Runs that saw and used the safeguard reached a 34.5% secure rate, against 12.7% for runs that never saw it.
Seeing it wasn't enough, though: 41% of runs that observed a safeguard didn't use it.
With a reference context of annotated safeguards, secure output was 24.8%, against 12.6% with the target file alone.
A generic "write secure code" reminder only moved it to 13.9%.

More context, more copying

Feeding the model more of the repository didn't help. A truncated 128K-token repository raised the functional pass rate from 56.9% to 60.9% and cut the secure rate from 12.6% to 12.1%. Inserting one insecure example raised correct-but-exploitable output by 6.3 points, even with the safeguard present.

The agent loop also bought working code, not safe code. Claude Code cost $1.41 per task against $0.09 for its retrieval setup without the loop, and read 204K tokens against 7.2K, for a secure rate of 18.4% against 17.9%.

What to do with this

If you let an agent touch security-sensitive code:

Name the safeguard in the prompt ("use validate_path() from utils/security and check can_edit() before writing"). The agent won't reliably go looking for it.
List your validators, auth checks and safe APIs, with paths, in your agent instruction file.
Remove or label insecure examples in the codebase the agent reads.

If you review agent pull requests:

Treat "tests pass" as a functional result, not a security result.
Check that the safeguard is called, and called in the right place. A permission check that runs too late is a real failure mode in the paper.
Don't rely on static analysis alone: it disagreed with the exploit oracle on 36.8% of 28,984 functionally correct generations.

Limits: the tasks come from known CVEs, so they're security-sensitive by construction; the paper tested Sonnet 4.5 and GPT-5.4, not newer models; and an exploit can demonstrate a vulnerability but not exclude one.

The full write-up has the per-agent cost table, the cost per secure solution and the context experiments: AI-Generated Code Security Study 2026 on StackChief.

This post was written with the help of AI, as a summary of the StackChief article above.

AGENTS.md vs CLAUDE.md: What 3,387 Agent Instruction Files Leave Out

StackChief — Thu, 05 Nov 2026 16:54:46 +0000

If your repo has an AGENTS.md, a CLAUDE.md, or both, a new preprint has numbers on what teams actually put in them, and what they leave out.

On November 2, 2026, four researchers (Shanto, Islam, Asaduzzaman and Ngom) posted to arXiv a study of 3,387 agent instruction files (AGENTS.md, CLAUDE.md, copilot-instructions.md and .cursorrules) from 1,000 GitHub repositories, drawn from the public AIDev dataset of agent-authored pull requests. It's version 1 of a preprint that hasn't been peer reviewed, so treat the numbers as a first look.

Popular repos pile up formats

66.2% of the higher-star half had at least one instruction file, against 50.2% of the lower-star half.
AGENTS.md led in both: 50.0% of popular repos had one, ahead of CLAUDE.md at 40.4%.
42.2% of instruction-bearing popular repos keep more than one format (21.6% in the other half). AGENTS.md plus CLAUDE.md is the most common pair, in 231 repositories.

Two files, two sets of instructions

The authors compared 386 pairs of sections covering the same topic in two formats of the same repo. 32.6% said the same thing in different words and 51.3% complemented each other, but 16.1% gave divergent guidance. None contradicted outright.

A plain diff won't catch it: for AGENTS.md/CLAUDE.md pairs, median overlap was 0.273 at the heading level but 0.929 at the category level. Same content, different headings.

Why it matters: by default, Claude Code reads only CLAUDE.md when both files exist (unless CLAUDE.md imports @AGENTS.md), while Codex reads AGENTS.md. So in the most common pair, the two agents can work from different briefs.

Files get written once

40.4% of files had only one recorded modification (47.7% for Copilot instructions, 34.4% for CLAUDE.md), and every format had a median of one author.

What most files leave out

Do's and don'ts appear in 81.2% of files. Four categories fall well below half:

Missing category	Share of files	What to add
Git and PR conventions	43.8%	Branch naming, commit format, what a PR needs
Security and secrets	29.9%	Where secrets live, files never to print or commit, commands that need a human
When to update this file	26.6%	A trigger (build, test or conventions change) and a reviewer
Ownership and contacts	18.8%	Owning team per directory, who to ask about risky changes

What to do this week

Pick one source of truth. Keep AGENTS.md as the shared file and put @AGENTS.md at the top of CLAUDE.md, followed only by Claude-specific lines.
Compare by topic, not by diff. Walk build, test, style and structure across files and resolve divergent lines.
Add the security and secrets section first. It's in fewer than a third of files, and it's the one that protects you.
Treat generated files as drafts. In the paper's generation test, a template raised category coverage from 18.7% to 82.8%, yet only 19.4% of generated sections fully preserved the developer's intent.

The study's limits: public GitHub repos only, and it didn't measure whether divergent or incomplete files change what agents produce. Still, combined with earlier work showing agents follow stale instruction files over the code, the message is that these files matter and rarely get maintained.

The full write-up, with charts, a table of which agent reads which file and the 16-category template, is here: Agent Instruction Files Study 2026 on StackChief.

This post was written with the help of AI, as a summary of the StackChief article above.

LLM Interview Questions in 2026: 6 Debugging Scenarios and How to Answer Them

StackChief — Wed, 04 Nov 2026 16:54:28 +0000

Some applied LLM interviews skip "explain temperature" and start from a production symptom: answers are cut off, the bill doubled, behavior changed overnight. The answer shape that works: name the likely causes, say how you'd tell them apart, then say what you'd change.

Six of the 15 scenarios from the full guide, condensed:

1. A fact in the middle of a long prompt gets ignored

Name the effect: the "Lost in the Middle" study (Liu et al., 2023) found performance is often highest when relevant information sits at the beginning or end of the context and degrades when it's in the middle. Reproduce it by moving the fact to the edges. The fix is less context: fewer, better passages, the most relevant ones at the edges, and the question restated after long documents.

2. Answers are cut off, but only in production

Read the stop reason before guessing. OpenAI's finish_reason is length when the token limit was reached, and Anthropic's stop_reason is max_tokens. "Only in production" points to longer real inputs, a lower limit in the prod config, or a stop sequence that appears in real text. With reasoning models the cap includes reasoning tokens, so it can be hit before any visible output.

3. About 2% of structured responses fail to parse

Triage before fixing. Sort failures into buckets: truncated JSON (check the stop reason), valid JSON with the wrong shape, extra prose around the JSON, or a refusal. Each has a different fix: a bigger limit, schema-constrained output or one repair retry, or a separate refusal path. Count the buckets before and after each change so you know which fix moved the 2%.

4. The bill doubled, and traffic didn't

Break cost into requests × tokens per request × price, by endpoint and model; one of those moved. Usual suspects: a retry loop, an agent calling tools more often, a prompt or context that grew, chat history no longer trimmed, traffic routed to a pricier model, or prompt-cache reads that fell. Then add budgets: alerts on tokens per request and a cap on agent steps.

5. The prompt cache hit rate dropped to near zero after a deploy

Caching works on an exact prefix. Anthropic's docs say cache hits require 100 percent identical prompt segments, built in the order tools, system, messages, and a change at one level invalidates everything after it. Diff the prompt: a timestamp or user name moved into the system prompt, or tools reordered, is the classic cause. Also check timing, because the default cache lifetime is 5 minutes, so a quiet endpoint can miss even with an unchanged prefix.

6. Behavior changed overnight, and nothing was deployed

List what isn't in your deploy: the model behind the ID you call, retrieved data, upstream tools and the traffic itself. Check whether you call an alias or a pinned snapshot, rerun your eval set and compare with the last stored run. Prevention: pin model versions, run evals on a schedule, and log the model version returned with each response.

The pattern

Every scenario rewards the same habit: find a signal that separates the causes (stop reason, chunk timestamp, cache-read tokens, per-request cost) before changing anything. If you can say what you'd log so the next incident takes minutes, you're answering at the mid-to-senior level.

All 15 scenarios, with levels, follow-ups and links to the vendor docs: LLM Interview Questions (2026) on StackChief.

This post was written with the help of AI, as a summary of the StackChief article above.

AI Engineer Interview Questions in 2026: 5 Answers Worth Having Ready

StackChief — Tue, 03 Nov 2026 16:54:18 +0000

AI engineer interviews in 2026 mostly ask you to reason about a working LLM system: why a RAG answer is wrong, how a tool call executes, what a chatbot costs per month, how to keep a model from being tricked. Here is the condensed version of a 13-question guide and the answer shape interviewers reward.

What companies actually publish

Very little. Google says its process typically takes roughly 6-8 weeks, assesses candidates against clear rubrics, and does not permit AI tools in interviews. Anthropic says live interviews are "all you", with no AI assistance unless it says otherwise. Most round-by-round breakdowns online are candidate reports.

The rounds fall into four buckets: concepts (tokens, embeddings, tool calling, fine-tuning trade-offs), practical coding (call an LLM API, validate output, handle failures), system design (RAG or agents with cost, evals and failure modes) and behavioral (an AI project you shipped and what you'd change).

Five answers worth having ready

1. Tokens. OpenAI's rule of thumb for English is about 4 characters, or 0.75 words, per token. Tokens drive cost (input and output are priced separately), limits (the context window is a token budget) and odd behaviour (models see tokens, not letters, so counting letters fails, and non-English text often costs more).

2. Why you can't unit-test an LLM feature. Correct answers vary in wording, and the same prompt can return different text, so exact-match assertions are flaky and fail good answers. The replacement is an eval set: fixed realistic inputs, a scoring method and a pass rate you re-run whenever the prompt, model or retrieval changes.

3. RAG gives confident wrong answers. Split the pipeline before touching the prompt. For each failing question, check whether the right passage was retrieved at all (if not: chunking, embeddings, query phrasing). If it was, give the model only that passage. If it still fails, the fault is generation.

4. Estimating chatbot cost. State the formula first: conversations × turns × (input tokens × input price + output tokens × output price). Then name what people forget: the system prompt, retrieved passages, tool definitions and the full history are re-sent every turn, so cost grows faster than linearly with conversation length.

5. Handling 429s and timeouts. Honor Retry-After, fall back to exponential backoff with jitter, and cap attempts, single waits and the total deadline. Retry timeouts, 429s and 5xx errors, never bad requests or auth errors. Anthropic documents a 429 for a monthly spend cap that keeps failing until access resumes, so not every 429 is retryable.

Prompting, retrieval or fine-tuning?

Match the technique to the failure. Misunderstood task or format: better prompt and structured output. Missing or changing facts: retrieval. Consistent style or a narrow skill the prompt can't teach: fine-tuning. Go in that order, because each step costs more to build and maintain, and have the eval set first so you can prove the cheaper option wasn't enough.

Prepare by level

Junior: correct mental models (tokens, the tool loop, why evals exist, prompt injection). Build one small RAG app with a 20-question eval set.
Mid: diagnose failures by stage and argue trade-offs with numbers, including a worked cost estimate for something you shipped.
Senior: limit blast radius, treat evals as release gates, and know when not to use a model.

The full guide has all 13 questions with follow-ups: AI Engineer Interview Questions (2026) on StackChief.

This post was written with the help of AI, as a summary of the StackChief article above.

Can You Use AI in Coding Interviews? What Changed in 2026

StackChief — Mon, 02 Nov 2026 16:53:51 +0000

"Can I use AI in my coding interview?" The honest answer in 2026 is: it depends on the round, and you have to ask. Here's what has verifiably changed, from published employer guidance rather than anecdotes.

AI-allowed and AI-prohibited rounds now coexist

Canva (announced June 11, 2025) replaced its Computer Science Fundamentals screen with an AI-assisted coding screen for backend and frontend roles. AI use is expected, and the problems are realistic product challenges, not LeetCode with an assistant switched on.
Anthropic's candidate guidance (updated July 10, 2025) says the opposite by default: no AI in live interviews or take-homes unless explicitly permitted. Yet its January 21, 2026 engineering article permits AI for the performance-engineering take-home it describes. Even one employer has exceptions.
Microsoft's technical-interview guidance still covers problem solving, coding, testing, algorithms, data structures and complexity.

The takeaway: an employer's enthusiasm for AI tells you nothing about a specific round. Confirm permission separately for every round.

Proctoring isn't permission

CodeSignal documents proctored assessments with camera, microphone, screen sharing, photo ID and recordings reviewed by its verification team. Monitoring tells you how you're watched, not which tools are allowed. Ask your recruiter:

Are AI chat, code generation, inline completion and agent features allowed?
Can I use docs, web search, my own editor or a project template?
Must I use a supplied assistant or account?
What needs to be visible, recorded or submitted, including prompts?
What should I do if the approved tool fails?

What's being graded in AI-allowed rounds

Canva's October 20, 2025 interviewer guide lists engineering problem-solving, technical depth and ownership, and AI collaboration as evaluation areas. Anthropic's October 16, 2026 report on its own hiring scorecards found comments on autonomy and judgment rose the most. That's evidence about one company, not an industry standard.

In practice, show control: clarify requirements, review every generated change, test behavior, and defend your decisions. If an assistant picks a different reading of the requirements than you did, point out the mismatch instead of accepting plausible-looking code.

Take-homes: AI permission isn't automatic

If the instructions are silent, ask. Silence isn't permission. Also ask whether you may send the assignment or its data to an external AI service. If AI is allowed, submit work you can defend, with a README covering how to run it, how you interpreted ambiguous requirements, the design decisions you made and rejected, known limitations, and what the assistant contributed versus what you checked yourself. Never claim you wrote generated code by hand.

A practice plan for both formats

Unaided: disable completions, solve a bounded problem in your interview language (clarify, implement, test, analyze complexity), then note where you got stuck.
Assisted: write your plan first, delegate one bounded subtask, inspect every change, add a test the assistant didn't propose, and make one follow-up change yourself.
Review code you didn't write: e.g. a booking-overlap function that wrongly treats [10, 11) and [11, 12) as conflicting. Find the smallest failing case, write a test that tells the right behavior from the wrong one, and make the smallest fix.

The full article, with the preparation categories and a step-by-step review exercise: Coding Interviews in the Age of AI: What Changed.

This post was written with the help of AI, as a summary of the StackChief article above.

Will AI Replace Software Engineers? What the 2026 Data Says

StackChief — Sun, 01 Nov 2026 16:53:54 +0000

"Will AI replace software engineers?" mostly gets answered with hot takes. Here's what the 2026 primary data says, from payroll records, job postings, a randomized trial and the largest field study so far.

The job isn't disappearing. The way into it is.

Entry level has collapsed. Only 4.5% of US software postings in Q1 2026 were entry-level, and 69.3% were senior (Indeed Hiring Lab). Across all US jobs, about 46% are entry-level.
Young workers are feeling it. Stanford's Digital Economy Lab (ADP payroll data) found employment for 22–25-year-olds in the most AI-exposed jobs about 19% below their peers in less-exposed jobs, up from a 15% gap a year earlier. The gap comes mainly from fewer hires, not layoffs.
Overall demand still grows. BLS projects software developer jobs to grow about 10% through 2035, from roughly 1.72M to 1.89M. That's a downgrade from 15.8% in the previous projection. Narrow "computer programmer" roles are projected to shrink about 7%.

In Stanford's words: "We do not see widespread, economy-wide job displacement associated with AI."

Productivity: nobody has measured it convincingly

METR's randomized trial (early 2025): 16 experienced developers on 246 real tasks were 19% slower with AI, while believing they were 20% faster. A 2026 follow-up found them roughly 18% faster, with a confidence interval that includes no effect. METR calls the data "an unreliable signal."
Harvard field study (Chen & Stratton, 2026): across 700+ firms, adopting coding agents raised lines of code 30%, commits 20% and pull requests 23%. Resolved Jira issues and epics (the features and fixes actually shipped) didn't change significantly.

Where did the extra output go? Into review. Time from PR to merge rose 49%, the share of PRs needing changes nearly doubled, and comments per PR rose 35%. Code got cheap. Confidence that the code is right did not.

What AI does well, and what still needs you

Think in tasks, not jobs:

Mostly automated: scaffolding, glue code, simple endpoints, first-draft tests, translating code between languages.
AI drafts, a human decides: debugging is the best example. An agent proposes five plausible causes in seconds, and someone has to confirm the real one.
Still yours: deciding what not to build, choosing an architecture you'll live with for years, being the person paged at 3 a.m. who understands the system.

The workflow shifted too. 90% of developers in JetBrains' 2026 survey (vendor data) use AI coding agents at least weekly. The skills that gained value are writing context files, writing specs before code, and agentic engineering: parallel agents, small reviewable changes, CI as the gate, and a human accountable for every merge.

The junior problem

At Anthropic, the junior share of technical hires fell from 27% to 9% (its own October 2026 report). Some economists argue interest rates and pandemic over-hiring explain more of the decline than AI does. The likeliest answer is both. Either way, if companies stop hiring juniors, they stop growing the seniors they'll need to supervise agents later.

What to do

Students and juniors: expect a smaller front door. Build proof you can verify AI output, not just produce it.
Mid-level: move toward the right-hand column of tasks: design, review and ownership.
Senior and staff: your judgment is the bottleneck now, so make it visible.

The full article covers every source, the charts, and a 90-day plan for each career stage: Will AI Replace Software Engineers? What the 2026 Data Actually Says.

This post was written with the help of AI, as a summary of the StackChief article above.

Software Engineer Salary in 2026: What Actually Moves Your Number

StackChief — Sat, 31 Oct 2026 16:53:57 +0000

"How much does a software engineer make?" has two correct answers that differ by about $60,000. Here's why, and what actually moves your number in 2026.

Two numbers, both right

$135,980: the median US software developer wage (BLS, May 2025). It covers every employer, from banks and hospitals to small agencies, and counts base pay and bonuses but not stock. The middle half earned $105,210 to $171,980.
$198,000: the median total compensation reported to Levels.fyi (Oct 23, 2026, 47,830 reports). That includes stock and bonuses, and skews toward the companies that pay the most.

The gap between the two is mostly equity and the type of employer. Whether a company grants stock can matter as much as your city.

Has pay kept up with inflation? Barely. The BLS median rose 2.2% from May 2024 to May 2025, while prices rose 2.4%. Matching the May 2025 median's buying power in September 2026 takes about $142,600, a useful floor if you're asking for a raise.

Level is the biggest lever

Stack Overflow's 2026 survey (US developers, median pay):

Experience	Median
0–2 years	$90,000
3–5 years	$100,000
6–10 years	$144,000
11–15 years	$170,000
16+ years	$167,000

At top-paying tech companies (Levels.fyi), the curve is far steeper: $155,000 entry level → $226,000 mid → $312,600 senior → $457,500 staff → $551,200 principal. In 2025, staff pay grew fastest (+7.52%) while principal pay fell 6.58%.

Location: cost of living reshuffles the middle

San Jose has the highest median developer wage, $213,110, and stays #1 even after adjusting for local prices. The surprises are further down a ranking of 43 metros:

Huntsville, AL: a $128,080 median ranks 37th, but 14th after the price adjustment, ahead of Austin, Denver and Chicago.
Miami: a $132,650 median drops from 24th to 42nd once prices are counted.

Highest-paying states: California ($174,410), Washington ($166,540), New York ($166,180), Massachusetts ($165,210). Taxes aren't in these numbers. Washington, Texas and Florida have no state income tax.

Remote pays more, but only for experienced engineers

Fully remote US developers earned about 11% more than in-person peers with similar experience (hybrid about 6% more). The premium is concentrated at the senior end: at 11–15 years it was $181,000 vs $137,500 (32%), while at 3–5 years there was no gap. It's a correlation, not a raise you collect by going remote: remote roles cluster at bigger, better-paying employers.

The pool is also shrinking. 30.4% of US software postings mentioned remote or hybrid work at the end of September 2026, down from a 45.2% peak in May 2023 (Indeed).

Takeaways

Compare offers on total compensation, and ask how the equity is valued.
Price-adjust before relocating. A lower headline salary can buy more.
Remote is a perk to negotiate around, not a pay bump to count on.

The full guide, with an interactive salary explorer (metro × level × remote), charts and sources: Software Engineer Salary 2026: Pay by Level, City and Remote Status.

This post was written with the help of AI, as a summary of the StackChief article above.

The 2026 Software Engineer Job Market in 6 Numbers

StackChief — Sat, 31 Oct 2026 03:58:17 +0000

If you're job hunting as a developer in 2026, the market feels contradictory: postings are up, yet entry-level openings are scarce. Both are true. Here are the numbers that explain it, all from primary sources (Indeed Hiring Lab, the New York Fed, CompTIA, BLS).

1. Postings are recovering, from a very low base

Indeed's software development postings index (Feb 2020 = 100) stood at 78.9 on October 16, 2026. A year earlier it was 65.0, so that's up about 21%. The low point was 61.1 in May 2025.

That still leaves postings about 21% below February 2020 and roughly two-thirds below the February 2022 peak (233.8). If you got your first job in 2021, that market is gone.

2. Software is still one of the weakest fields on Indeed

Of Indeed's 47 occupational sectors, software development ranked 6th lowest. All US postings sit at 103.8, slightly above pre-pandemic levels. Mechanical engineering is at 169 and electrical engineering at 152.

3. The recovery is for senior engineers

In Q1 2026, 69.3% of US software postings on Indeed were senior roles and just 4.5% were entry-level. Across all US jobs, roughly 46% of postings are entry-level. Of the growth in software postings from May 2025 to May 2026, 71% came from senior roles.

4. New grads have it hardest

Computer science graduates have the 4th-highest unemployment rate of 73 majors (7.0%) in the New York Fed's data, even though they earn the 2nd-highest starting pay.

5. AI is reshaping demand, not erasing it

Jobs with "AI" in the title drove 37% of the posting growth. Overall tech unemployment is 3.3%, and BLS still projects software developer employment to grow about 10% through 2035.

6. One signal to watch

Indeed's new postings for software (ads posted in the past week) averaged 82.8 in Jul–Sep 2026, down 6.6% from Apr–Jun, while total postings kept rising. If that continues, more of the "growth" is ads staying open longer, not fresh openings. One quarter isn't a trend yet.

What this means if you're looking

Junior: the scarce thing is the entry rung, not the profession. Widen your radius to hybrid and nearby cities, and look at adjacent entry points (QA/test automation, support engineering, internal tools, data roles, apprenticeships). Anything that makes you look less "entry-level" helps: a project real people use, freelance work, or prior experience framed as problems you solved.
Experienced: demand is back, especially for engineers who can show AI-tool fluency in interviews.

The full version with charts, sources and a monthly update is on StackChief: Software Engineer Job Market 2026: What the Data Shows Right Now.

This post was written with the help of AI, as a summary of the StackChief article above. Every figure was checked against that article and its sources (Indeed data through Oct 16, 2026).