DEV Community: Ava Bagherzadeh

Four things that cost us money while automating job applications

Ava Bagherzadeh — Tue, 22 Sep 2026 14:52:46 +0000

Filling a job application is a browser-automation problem that looks solved and is not.

We run an MCP server that applies to jobs end to end on the employer's own hiring system. Fifteen applicant tracking systems: Greenhouse, Lever, Ashby, Workday, iCIMS, Personio, Teamtailor, SmartRecruiters, Recruitee, Breezy, Workable, Rippling, BambooHR, JazzHR and softgarden. Here are four things that cost us real money to learn.

1. Scoring on your own input is not evidence

The first version reported success when the upload call returned staged: true and the field read back files: 1. Both were true. Zero bytes reached the server.

The automation library took a different code path on a remote browser and sent nothing, while every counter we owned said it had worked. We were reading our own writes back and calling it proof.

The rule we run on now: never score on a read-back of your own input. Only score on something the other side produced. A request on the wire. A confirmation page. An email from the employer. submitted: true is a variable you set. It is not a receipt.

This generalises well past job forms. If your integration test asserts on state your own code wrote, it asserts nothing.

2. An empty result is not a zero until you prove you were watching

We spent 23 debugging sessions reading logs that showed nothing wrong. Nothing was wrong in the logs. The instrument started 18 seconds after the event it was supposed to measure, so a working fix and a total failure produced identical output: silence.

Before you believe any empty list, prove three things:

The instrument was armed at all, at the right scope.
It was armed before the event and still armed after.
The mechanism works when a human does it. Then diff the human run against yours. The divergence is the bug.

If you cannot prove all three, the correct word is not "absent". It is unobserved. Write that down instead, and go fix the instrument before you touch the subject.

We found the upload bug in minutes once we stopped reading logs and opened the page in a real browser.

3. HTTP 200 is not success, and a 200 from an SPA is not even a page

Two separate versions of this one bit us.

A provider returning an overloaded-service message inside the body of a 200 made our SDK classify it as a schema validation failure. We spent a day looking for drift in a parser that was fine. Match the error text, not the status code.

Separately, while surveying sites this week, several returned 200 for /submit, /add-tool, /new and four other paths that do not exist. They are single-page apps with a catch-all route. A 200 there proves the server answered. It says nothing about whether the page exists. Read the body.

4. A list that is still rendering is not a list

Dropdowns were harvesting exactly one option. The code waited for a loading placeholder to disappear, which it did, correctly, while the list kept painting rows behind it.

Waiting for the absence of a spinner is not the same as waiting for the presence of the data. We now settle on count stability: read the option count, wait, read it again, and only proceed when it stops changing. One field went from 1 option to 7.

The part that has no clever fix

The distinction we built the product around is that an application is not "sent" because we clicked submit. It is sent when the employer's system says it received it. Those are different events and only one of them is checkable.

Most of the engineering above exists to keep that honest, because the tempting version, where your own click counts as the outcome, is much easier to build and quietly useless to the person waiting for an interview.

The MCP server is public and works in Claude, ChatGPT and Cursor over streamable HTTP at https://mcp.aiapplyd.com/mcp. Source mirror: github.com/aiapplyd/aiapplyd-mcp. The product is AI Applyd.

Happy to answer anything about the ATS-specific parts. Workday alone is worth its own post.

An HTTP 200 is not a delivered job application

Ava Bagherzadeh — Mon, 14 Sep 2026 07:40:23 +0000

We are launching on Peerlist this week. If this is your kind of problem, come and tell us where it still falls short: AI Applyd on Peerlist Launchpad

Every auto-apply tool I have taken apart marks an application "sent" at the same moment: the instant it dispatches the click. That is a read-back of our own input, and it is the weakest signal in the whole pipeline.

The four signals that look like proof and are not

I shipped all four of these at some point and had to take them back out.

1. Our own click. The submit button was pressed. Nothing about that tells you a request left the browser, or that the server accepted it, or that a row was written on the other side.

2. HTTP 200. A 200 means a server answered. Applicant tracking systems return 200 for validation errors, for a re-rendered form with a red field, and for a page that says "we could not process your application". A status code is not a receipt.

3. Our own database row. We wrote status = submitted. We wrote it. Scoring on a value you set yourself is circular, and it is the single easiest way to build a dashboard that is confidently wrong.

4. A page that looks like a thank-you. Heuristics on the confirmation screen are the most seductive of the four, because they are usually right. Usually is the problem. A cached page, a redirect to a generic careers landing page, or an ATS that renders the same shell for success and failure all pass a text match.

What we count instead

One thing: the employer's own system says the application arrived, and we can link to that evidence. A confirmation email from their ATS tied to that application. A post-submit screen we retained and verified as an employer confirmation. Nothing else moves a row to sent.

When we cannot get that, the application does not silently become a success. It says so, in plain words, and it names what it is waiting on.

What that bought

Refusing the weak signals forced the agent to get further on its own, because every shortcut we removed was a shortcut around a real wall.

It opens the employer's real hiring form on Greenhouse, Lever, Ashby, Workday, iCIMS, Personio, Teamtailor, SmartRecruiters, Recruitee, Breezy, Workable and Rippling.
It rewrites the resume for that specific posting and writes the cover letter in the candidate's voice.
It gets through account walls by itself: it signs up, verifies the email and resets a password using a private inbox we create for the user. The user is never asked for a code or a login.
It solves the captcha inside the vendor's own frame rather than giving up when the challenge sits in an iframe.
It stops pressing once the employer says yes.

If you want to poke at it

There is a remote MCP server, so the same tools run inside Claude, Cursor or ChatGPT. Streamable HTTP on Cloudflare Workers with OAuth 2.1 and dynamic client registration, so there is nothing to install and no API key to paste.

https://mcp.aiapplyd.com/mcp

The product itself is at aiapplyd.com.

I build AI Applyd - https://aiapplyd.com?ref=devto - auto-apply that proves your application arrived.

The question I keep asking, and the one that keeps changing this codebase: what would make you trust that an application actually landed?

Come and kick the tyres on the launch page, it is live all week and every comment there reaches me: peerlist.io/firstexhotic/project/ai-applyd-mcp

Both sides of the job interview are running models now, and neither one says so

Ava Bagherzadeh — Sat, 12 Sep 2026 12:39:48 +0000

A recruiter sends you a link. You record four answers into a webcam with nobody on the other end. A model scores the transcript. A human skims the top of the pile.

Meanwhile, on your side of the screen, there is a second window open with the job description pasted into it.

Neither party mentions any of this. Both parties suspect the other.

The part that gets called cheating depends entirely on who went first

The usual framing is that candidates started it. It is worth checking the order.

Automated screening was in the pipeline long before consumer language models were. Keyword filters, then scoring, then recorded-interview scoring. By the time a candidate could open a chat window and ask for help with a cover letter, the other end of the process had already been machine-read for years.

That does not make anything permissible. It does mean the moral panic is pointed in a strange direction.

And it is not a wash, because one side had to consent

Here is the asymmetry that actually matters, and it is structural rather than a matter of opinion.

If a candidate uses a model to prepare, that is their own time and their own business. If an employer uses one to score, it is deciding an outcome about a person, often without telling them, and the person cannot see the rubric, cannot appeal it, and frequently cannot even confirm it happened.

Same technology. Very different position in the power arrangement.

The measured cost is not accuracy, it is who stays in the room

This is where it stops being a vibes argument.

In CESifo Working Paper 12573, researchers randomised over 3,000 real job applicants into asynchronous audio interviews, asynchronous video interviews, live online interviews, or a control group.

Asynchronous interviews caused an over 50% decrease in application continuation. The paper reports the decline happened "including among the most qualified applicants", and that it was largest for women.

Read that as a systems person rather than as a candidate. A stage that removes more than half your input, non-uniformly, and correlated with something other than the quality you are selecting for, is not a filter. It is a sampling bug. Anywhere else in engineering you would treat that as a defect in the pipeline rather than a property of the population.

So what does a candidate actually do about a system they cannot see

Not much, honestly. But not nothing.

Ask what is recorded and what is analysed by software. In the EU the AI Act treats candidate-evaluation systems as high risk. Illinois requires notice and consent before AI analyses a video interview. New York City requires a published bias audit for automated hiring tools. Elsewhere there is usually no rule, and you should ask anyway, because the shape of the answer is information about the company.

Then write for the reader you actually have. A transcript scorer reads structure, not charm. Name your structure out loud. "There were three constraints. The first was cost." That sounds faintly robotic to a person and it is exactly what survives being turned into text and graded.

And answer the follow-up nobody is there to ask. On a recorder, the second attempt does not exist. Whatever you said is the artefact.

The uncomfortable ending

Everyone reaches for the same closing line here, which is that we should go back to talking to each other. Nobody is going to do that. Interviewing a thousand people by hand is genuinely expensive, and that was a real problem, and the recorder was a real answer to it.

But if the cheapest way to interview a thousand people also removes the best of them before anyone is assessed, the saving is being booked on the wrong side of the ledger.

I build AI Applyd, which fills in and sends job applications on the employer's own careers page across fifteen of the hiring systems companies actually use, so the hours before any of this go somewhere better.

One question I do not have a good answer to, and I would take yours: if you were designing the first screening stage from scratch, knowing it has to scale to a thousand applicants and knowing the recorder costs you your strongest candidates, what would you build instead?

Laid off this week? Four clocks started the day you found out

Ava Bagherzadeh — Fri, 11 Sep 2026 07:40:57 +0000

The August jobs report came out on September 4. It said the US added 162,000 jobs. It also said the information sector lost 23,000, and that the median time someone stays unemployed is now 11.4 weeks, up from 9.9 a year ago.

Then the first week of September happened. Uber told staff it was cutting about 10% of its workforce on September 2. Volkswagen's supervisory board approved another 50,000 job cuts on September 3. Jaguar Land Rover announced 4,000 on September 7.

If you are one of those people, here is the thing nobody says in the meeting. Several clocks started the moment you found out. Most people hear about them after the shortest one has already run out.

The shortest clock is three days, and it is not the one you are thinking about

If you work in Germany, you have to register as job-seeking with the Agentur für Arbeit within three days of learning your job is ending. If you learn more than three months ahead, the rule is three months before the end date instead (§ 38 SGB III).

Register late and you can lose a week of unemployment benefit, a Sperrzeit (§ 159 SGB III). You can register online. It takes less time than writing the message to your team.

The second German clock is three weeks. That is how long you have to file a claim against the dismissal itself, counted from the day you receive the written notice (§ 4 KSchG). Miss it and the dismissal is treated as valid, whatever was wrong with it.

And one right with no clock at all: you are always entitled to a written reference, the Arbeitszeugnis (§ 109 GewO). Ask for it now, while the people who know your work are still there to write it.

So if the German clocks are the short ones, why do Americans get more time on the most expensive decision?

The paper they hand you in the meeting can wait 21 days

In the US, if you are 40 or older, a severance agreement that asks you to waive age-discrimination claims has to give you at least 21 days to consider it. In a group layoff, that becomes 45 days. After you sign, you still get 7 days to change your mind (29 U.S.C. § 626(f)).

The pressure in the room is real. The deadline in the law is longer. Take the paper home and read it with someone who does not work for the company.

Your health cover has a window, not a cliff

COBRA gives you at least 60 days to elect continued health coverage. The window is counted from the later of two dates: the day your coverage ends, or the day the notice is sent (29 U.S.C. § 1165).

That window exists so you can decide calmly. Find the date on the notice tonight and put the last day in your calendar, because the most expensive mistake is a date that passes while you are busy with everything else.

Which brings us to the clock that only starts when you start it.

Unemployment only starts counting when you do

The Department of Labor's own advice is to contact your state's unemployment agency as soon as possible after you lose your job. Some states have an unpaid waiting week. The first payment usually arrives two to three weeks after you file. Most states pay for up to 26 weeks.

Every one of those numbers is measured from the day you file, not the day you were let go. Filing on day one costs you an afternoon. Filing in week three costs you three weeks.

The clock nobody gives you a date for

Then there is the search itself. The Bureau of Labor Statistics puts the median time unemployed at 11.4 weeks in August 2026, up from 10.5 in July (Employment Situation, table A-12). Nobody hands you that one on paper, and it is the one that decides how the other clocks feel.

So spend week one on the dated clocks: register, read, elect, file. Start the applications in week two, with your calendar clear and your head in it.

When you do, that part does not have to eat your evenings. I build AI Applyd. You pick the job, it fills in the whole application on the company's own careers page, sends it, and brings back the company's own confirmation. Only the employer can call an application sent, so that is what we count.

This is general information, not legal advice. Check the rules for your state or your situation.

Which of these clocks did nobody tell you about?

The hiring window that opens in September, and the two dates it shuts

Ava Bagherzadeh — Wed, 09 Sep 2026 08:13:35 +0000

Job hunting feels like weather. It is closer to tides.

There is a shape to the hiring year, and right now you are standing in the best part of it. Not because of luck, and not because of anything mystical about autumn. Because of how companies actually spend money and book calendars.

Here is the whole thing, and you can check every piece of it yourself in about ten minutes. No signup, no tool, nothing to buy.

First, the ten minute check

Open the careers page of three companies you actually want to work at. Not a job board. Their own page.

Sort by newest. Look at the date on the top role.

A page that added something this week has a person behind it this week.
A page whose newest role is six weeks old is a page nobody is working.

That one number tells you more than the job description does. A description tells you what they wish they needed. A date tells you whether anyone is currently allowed to hire.

Why September is different from August

Two things change at once, and they are not the ones people talk about.

The money became real. A role does not appear because a manager wants help. It appears after someone in finance approves the headcount. Those approvals cluster around planning cycles, and a role approved for this quarter has a spend-it-or-lose-it clock attached to it.

You are allowed to ask about this. "Which quarter was this headcount approved for?" is a normal question and recruiters answer it. If the answer is this one, the deadline is on their side of the table, not yours.

The people came back. Hiring is a scheduling problem wearing a trench coat. A single loop usually needs a hiring manager, someone from the team, a skip level, and whoever signs the offer. In September you can get those four calendars to line up inside a week.

Why December is different from September

The window does not shut once. It shuts twice.

Gate one, late November. The panel starts to break up. Interviews still happen, they just take three times as long. Most of what people describe as being ghosted in December is not rejection. It is four calendars that no longer overlap.

Gate two, mid December. Nothing decides until January. A role posted after that is usually being parked so the req stays alive, not filled.

Neither gate is a reason to stop applying. Both are a reason to stop waiting on a specific role and to keep the next one moving.

The five moves for this month

Sort by newest. Not by relevance, not by best match. Newest.
Go for it the same week it appears. Not the same hour. Rushing is not the point, being inside the window is.
Ask which quarter the headcount came from. One sentence, in your first reply to the recruiter.
Send the CV that is good enough today rather than the perfect one on Friday. Friday is four days of this window gone.
Write every application down somewhere you can see it. So that in November you are looking at a list instead of a feeling.

That last one sounds like admin. It is the one that changes how the next two months feel. The worst part of a job search is not rejection, it is not knowing what is still alive.

Where I am coming from

I build AI Applyd. It keeps that list for you and it fills in the applications, across fifteen of the systems companies actually use. One thing we are stubborn about: a job only moves to sent when the company's own system confirms it arrived. Our own screenshot is not proof of anything.

But the five moves above cost nothing and work without any of that. Use them either way.

What is the oldest job you are still waiting to hear back on? I would genuinely like to know how long people are holding on before they call it.

The counter-intuitive thing job seekers started doing in 2026

Ava Bagherzadeh — Tue, 08 Sep 2026 08:48:15 +0000

There is a number in this year's job-search data that reads like a mistake.

Nearly a quarter of job seekers say they have significantly reduced the number of jobs they apply to. Not because they gave up. Because applying more stopped working, and they noticed before the advice did.

If you have been hunting this year, you already feel why. The median time from starting a search to a first offer is now past 100 days. Somewhere in there, most people cross a line where the search stops being a project and starts being a second job that pays nothing.

The maths that broke

The old advice was volume. Apply to everything, something lands, it is a numbers game.

That advice assumed each application costs you five minutes. It does not any more. Here is the honest cost of one real application in 2026:

Read the posting properly. Four minutes.
Adjust the CV so the first third matches what the role actually screens for. Ten minutes if you are fast.
Upload it. Watch the parser eat it and hand back a form with your dates wrong. Fix it by hand. Twelve minutes, and this is the part nobody counts.
Answer the extra questions. Notice period, salary expectation, work authorisation, the essay box. Six minutes.
Press submit. Find out nothing.

That is over half an hour. Twenty applications is a working week. And a chunk of those postings are not real, which is its own tax on top.

So people did the sensible thing. They cut the number down and put the saved hours somewhere with a better return.

What the people cutting back are doing instead

Three things, and none of them are clever:

They apply to fewer, better-matched roles. Not "roles I could do" but "roles where the first screen will not reject me on the four things it checks": the title, the years, the location, and whether you can legally work there. Everything else is decided later by a human. If one of those four reads wrong, nothing you wrote below matters.

They spend the saved time on one warm route per week. One message to a person who actually works there beats six cold applications, and it takes less time than one of them. Not "networking". One message.

They keep a record of what they sent. Sounds like admin. It is the only way to tell a rejection from an application that quietly never arrived, and those two things look identical from where you are sitting: silence.

The part I find genuinely interesting

The volume advice never died because it was right. It died because volume got expensive. When an application cost five minutes, spraying was rational. At thirty-five minutes, it is the most expensive possible way to be ignored.

And the tooling response to that has mostly been to make spraying cheaper rather than to make it unnecessary, which is how you end up with a market where everyone applies more and nobody hears back sooner.

I build in this space, so treat that as an interest declared. The thing I would defend is narrower than a product pitch: the expensive part of an application is not the writing, it is the retyping and the silence afterwards. Fix those two and the volume question mostly answers itself.

If you are in it right now

Cut your list. Check the four screening facts before you spend thirty minutes on anything. Keep the record. Send one warm message a week.

And do not read your own silence as a verdict on you. Most of it is a req that got frozen, an offer waiting on a signature, or a form that failed.

What actually moved the needle in your search this year? I am collecting honest answers rather than advice, and the honest ones have been more useful.

I build AI Applyd - it fills in and submits job applications across the twelve systems companies actually use to receive them.

I stopped reading the headline jobs number. Table B-1 tells me something different.

Ava Bagherzadeh — Sat, 05 Sep 2026 09:33:27 +0000

The US August employment report came out on September 4. It was good. Total nonfarm payroll employment rose by 162,000, against a prior 12-month average monthly gain of 31,000. The unemployment rate held at 4.1 percent. Economists polled by FactSet had forecast 65,000, so the print came in well above what the street expected.

Then I looked at my own industry's line.

Information employment declined by 23,000 in August, following losses that had averaged 8,000 per month over the prior 12 months. So the national total ran at more than five times its own recent trend, and the information sector fell at nearly three times its own recent trend, in the same month, in the same release.

Inside that 23,000, the report breaks it down further. Computing infrastructure providers, data processing and web hosting lost 8,000. Publishing lost 7,000. Broadcasting and content providers lost 5,000.

If you write software, run infrastructure, or produce content for a living, there is a decent chance your employer is counted in that line. The headline number is not describing you. It is describing an average that includes you, weighted so lightly that you disappear into it.

Why the aggregate cannot describe you

The total is a sum, and sums hide their own composition. In August, food services and drinking places added 59,000 against its own prior 12-month average of 12,000, and local government education added 42,000. Between them, those two categories account for most of the beat.

That is not a criticism of the report. The report is doing exactly what it says. It is a criticism of reading only the first sentence of it.

The comparison that matters to a person is not their industry against the national total. It is their industry against its own recent trend. The two questions have different answers and only one of them is about you.

Health care is the cleanest example in this release. Health care employment went up in August, by 13,000. A positive number. It is also well below health care's own prior 12-month average of 32,000. So a health care worker reading "employment continued to trend up" is reading a true sentence about a sector that hired at less than half its recent pace. A positive number can be a slowdown. You only see that if you know what the sector's own normal is.

Do this in five minutes

Nothing here needs an account, a data subscription, or a spreadsheet. It is a browser and about five minutes, once a month.

Open the current Employment Situation summary at bls.gov/news.release/empsit.nr0.htm. This is the primary source. Every number quoted in every article about the report is in here.
Search the page for your industry's name. The summary text names the industries that moved, and it gives each one its own prior 12-month average in the same sentence. That sentence is the whole comparison, already done for you. This is the step most people skip.
If your industry is not named in the summary, open Table B-1, "Employees on nonfarm payrolls by industry sector and selected industry detail", at bls.gov/news.release/empsit.t17.htm. It carries the detailed industry rows.
In the seasonally adjusted block of that table, take your industry's level for the current month and subtract its level for the same month one year earlier. Both columns are right there. Divide by 12. That is your industry's own average monthly change over the last year, computed by you, from the primary table.
Compare this month's change against that average. Same direction and similar size means this month is ordinary. A large gap in either direction is the thing worth reading about.
Read the revisions paragraph before you conclude anything. It is near the top of the summary.

Six steps, one table, one subtraction. That is the entire method.

Telling a trend from one month of noise

Two habits keep me from over-reading a single print.

The first is the revisions. In this release, June was revised up by 11,000, from +20,000 to +31,000. July was revised up by 44,000, from -23,000 to +21,000. July changed sign. A month that was reported as a contraction is now reported as growth. A first print is an estimate that gets two more passes, and the second pass moved that one by more than double the original figure.

The second is the sampling error. The technical note for this release puts the 90 percent confidence interval for the monthly change in total nonfarm employment at plus or minus 122,000. For the monthly change in the unemployment rate it is about plus or minus 0.3 percentage point. So a month-over-month move of 40,000 in the total is inside the noise band, and a change in the unemployment rate from 4.1 to 4.3 is not clearly a change at all.

BLS does not publish a separate interval for every industry in that note, so I do not have a clean noise band for the information line on its own. What I have instead is the run of months. The report says information losses averaged 8,000 per month over the prior 12 months. That is twelve consecutive months of the same direction. One month at 23,000 could be noise. A year of negative months with a bad one on top is a trend, and it is the only part of this release I would actually plan around.

That is the practical rule I use. One month is a data point. Twelve months in the same direction is a signal. The report gives you both, in the same sentence, for free.

Where I actually apply this

I check my sector's line the morning the report drops, and it changes how I spend the following month. When information is shedding and health care is still net positive but decelerating, I read that as a market where the same resume gets a different response depending on which industry code the employer sits under, and I widen where I look before I widen how much I send.

I build AI Applyd, which submits applications on the twelve hiring systems companies actually run, and none of the five minutes above needs it or mentions it again.

The part I do not know

Information employment has fallen for more than a year while total payrolls kept climbing. I do not know what that line is actually measuring.

The CES classifies an establishment by what the employer does, not by what the worker does. The same backend engineer is counted under information at a publisher, and under professional and business services at a consultancy, and under retail trade at a retailer with an in-house platform team. So a year of information losses could be AI substitution, or the unwinding of a hiring overshoot, or a slow reclassification as software work moves out of software companies and into everyone else. Those three stories are indistinguishable in the top-line series, and they imply completely different things about whether the work is disappearing or just moving.

If you know a way to separate them using published CES or QCEW data, I would genuinely like to read it. I have not found one.

Sources, all primary or directly linked:

BLS, The Employment Situation, August 2026: https://www.bls.gov/news.release/archives/empsit_09042026.htm
BLS, Employment Situation Technical Note: https://www.bls.gov/news.release/empsit.tn.htm
BLS, Table B-1: https://www.bls.gov/news.release/empsit.t17.htm
CBS News, August jobs report coverage: https://www.cbsnews.com/news/august-jobs-report-us-labor-market/

Your saved-jobs list is sorted the wrong way round

Ava Bagherzadeh — Wed, 02 Sep 2026 15:06:58 +0000

The pool of people applying for your next role is growing faster than the number of roles. If you have a list of jobs you meant to apply to, the useful move this week is to send to the oldest one first and cut the rest down to ten.

Here is the number behind that. Robert Half's 2026 research puts the share of already employed US workers planning to start a job search in the first half of 2026 at 38 percent, up from 29 percent a year earlier. Those are people who currently have a job and are choosing to compete anyway. They arrive before the openings do, because hiring plans move on a slower cycle than personal ones.

Why a bigger pool changes your ordering, not your effort

Most people work a saved-jobs list newest first. That feels right and it is backwards.

A posting that has been live for three weeks is closer to closing than to opening. It already has its pile. Every day you leave it sitting is a day the pile grows and the recruiter's attention moves to the shortlist. The posting you saved this morning has the most runway, which means it is the one that can afford to wait.

So the ordering rule is simple: oldest first, every session. It costs nothing and it is the highest-leverage change most people can make to a list they already have.

The second thing the numbers argue for

Three other measurements make the case for a shorter list rather than a longer one.

Employer ghosting is at a three-year high. Axios, reporting survey data in August 2026, put the share of job seekers ghosted by an employer in the past year at 53 percent, up from 48 percent in 2025 and 38 percent in 2024. A larger list does not protect you from this. It just spreads the same silence over more of your evenings.
A machine reads first now. A 2026 hiring-trends report from ResumeGenius found 58 percent of hiring managers use AI to screen resumes, up from 35 percent the year before, with 87 percent of companies using AI somewhere in recruiting. The first reader is looking for structure and specifics, not for volume from you.
The supply side is not slowing. Public layoff trackers counted 365 layoff events and 209,032 affected workers across 2026 by the start of September, the largest single event being 30,000 at one company. Those people are entering the same queue.

Put together: more applicants, a filter reading first, and a rising chance of no reply at all. The response is not to send more. It is to send better, earlier, to fewer.

Four things worth doing this week

None of these need a tool or a signup.

Send to the oldest saved job first, today. Reverse your list ordering permanently.
Cut the list to the ten you would actually accept. Everything you would turn down is costing you the evenings you would have spent on the ones you would take.
Put your last role in one sentence with a number in it, and move that sentence to the top. Most people bury the only line anyone is scoring, three paragraphs down. "Cut onboarding drop-off 19 percent by rebuilding the first run flow" beats "responsible for the onboarding experience" every time, and it survives both a human skim and a machine parse.
Answer the optional questions. A half finished form is the cheapest thing in the world for a filter to sort on. Optional to them is not optional to you.

The part that does not scale, and what to do about it

The genuinely unpleasant part is the retyping. You upload a CV on the first screen and then type its contents into thirty boxes anyway, once per company, because every applicant tracking system keeps its own tenant and its own account.

That is the part worth automating rather than enduring. I work on AI Applyd, which fills and submits applications on the employer's own careers page across twelve application systems, so the forty minutes per form stops being yours. Whatever you use for it, the ordering and the shorter list are worth doing first, because no amount of speed fixes a list sorted the wrong way round.

FAQ

Does applying earlier actually matter?
It matters for the same reason a queue matters. A posting accumulates applications from the day it goes live, and shortlisting starts before the posting comes down. Being early does not guarantee anything, but being late removes options that being early keeps open.

Is a shorter list not just fewer chances?
It is fewer chances at a higher standard of preparation each. Ten applications where the top line is specific and the optional fields are filled is a different submission than forty half finished ones, and the filter reading them is looking at exactly those signals.

Should I stop applying because the pool is growing?
No. The pool growing is an argument for starting now rather than in three months, because the people in that 38 percent are starting now.

What counts as a number in my top line?
Anything checkable. A percentage, a count, a duration, a size of thing you owned. "Nine engineers" is a number. "Cross functional collaboration" is not.

Sources

Robert Half, 2026 hiring and job search research: https://www.roberthalf.com/us/en/insights/landing-job/why-hiring-trends-may-be-better-than-they-appear
Axios, 21 August 2026, on job seeker trust, AI hiring and ghosting: https://www.axios.com/2026/08/21/job-seekers-ai-hiring-ghost-jobs-trust
ResumeGenius 2026 hiring trends report: https://resumegenius.com/blog/job-hunting/hiring-trends-report-2026

The take-home task is the only interview stage you can negotiate, and almost nobody tries

Ava Bagherzadeh — Tue, 01 Sep 2026 15:31:50 +0000

Every other stage of a hiring process is fixed. The screen is thirty minutes because their calendar says thirty minutes. The panel is four people because four people were free. You cannot move any of it.

The take-home is different, and the difference is structural rather than a matter of goodwill. It is the only stage where you supply the resource being spent. Their cost is one review. Your cost is your weekend. Any time both sides are spending different currencies, there is a negotiation, whether or not anyone opens it.

Almost nobody opens it. I did not for years, because the brief arrives looking like a fact.

What is actually negotiable

Four things, and none of them make you look difficult.

1. The scope, against the stated time. Briefs routinely say "about four hours" and describe eight. This is usually not a trick, it is a brief written by someone who already knows the codebase and forgot how long the setup takes. Asking "if this runs long, would you rather I ship the smaller thing finished, or the larger thing partial" is a normal engineering question. The answer tells you a lot about the team, and it is the same question you would ask in week one of the job.

2. The deadline. The date on the email is almost always the date the sender typed, not a constraint from anywhere. Two extra days is a routine ask and I have never seen it refused. What gets refused is silence followed by lateness.

3. The format. If the brief asks for a repo and you would rather send a repo plus a fifteen minute walkthrough, offer it. If it asks for a deployed app and deploying is two hours of the four, ask whether local is acceptable. You are proposing a cheaper path to the same evidence.

4. Whether it happens at all. If you have public work that already demonstrates the thing being tested, say so and offer it as a substitute. The worst outcome is that they say no, and you have still shown them the work.

The one thing that is not negotiable

The scoring is not a mystery to be reverse engineered, but it is also not yours to change. Nearly every rubric I have seen or been given weights the same four things: does it run from a clean checkout, is the core case correct, is the code readable by someone who did not write it, and did you say what you left out. The fourth one is free and it is the one people skip.

Write the README that says what you did not do. "No auth, out of scope. No pagination, would add it at N rows. Tests cover the parser, not the CLI, because the parser is where the risk is." That paragraph costs ten minutes and it converts every gap from a thing they found into a thing you decided. Those are not the same finding.

How to open it without sounding like you are dodging

One message, sent the day you receive the brief, not the day before it is due:

Thanks, this looks like a good problem. Two questions before I start. It reads like more than the four hours suggested, so if it runs long, would you rather have the smaller version finished or the larger version partial? And I have a conference on Thursday, would Monday work instead of Friday?

That is it. You have asked one engineering question and one logistics question. Nobody has ever read that and thought less of the sender.

The uncomfortable part

This only works if you actually do the task well afterwards. The negotiation buys you a fair brief. It does not buy you a pass, and asking for two more days and then sending something rushed is worse than sending the rushed thing on time.

The question

I have not found anyone who tracks this properly, so I will ask rather than assert. When you have pushed back on a take-home, what happened? I am specifically interested in the cases where it went badly, because I have only ever heard the success stories and that cannot be the whole distribution.

I build AI Applyd. It applies to jobs for you across the twelve ATS platforms we cover, and counts an application as sent only when the employer's own system confirms it.

Your unanswered comments are worth more than your next post, and nothing shows you which they are

Ava Bagherzadeh — Tue, 01 Sep 2026 15:03:29 +0000

Every platform I write on is good at telling me about other people's posts and bad at telling me which of my own threads has an open question sitting in it. The highest-value action on the board is also the one that is structurally hardest to see, and I think that explains a lot of quiet accounts better than laziness does.

What I found this morning

I went through four of my own threads. Three had substantive comments nobody had answered.

One was a week old, twelve hundred characters, written by someone who had clearly read the whole post, and it ended in a direct question. Another was a stranger handing me a better version of my own argument, for free, in a thread I had stopped opening.

Answering four of them took about forty minutes. One thread went from nineteen comments to twenty-three. I produced no new writing to get that. The material was already there, written by other people, waiting.

The obvious objection, and why it is the wrong comparison

Reach per hour is worse for a reply than for a post. That is true.

It is also comparing the wrong two things. A post is an impression. A reply is a named person who already spent effort on you, in a thread a stranger can still find in six months. Everyone already knows this, which is what makes the neglect interesting. If it were a value judgement people would defend it. Nobody defends it. They just do not do it.

The cause is the inbox, and there isn't one

Look at what a notification feed actually contains. Likes. Follows. New posts from people you follow. Someone reacted to a comment you left. And somewhere in there, the one item that matters: a question on your own thread that you have not answered.

They are the same size and the same colour. The item with the highest value carries the same visual weight as somebody clicking a heart, so it loses to whatever is louder and more recent. There is no view anywhere that filters to it.

There is a second cost I only noticed today. A thread with an unanswered question does not read as neutral to someone arriving late. It reads as abandoned, and it says something about the author rather than about the post. You are not only failing to collect the value, you are publishing a small signal that you stopped caring, on a page that keeps getting read.

The spec I want, which is boring on purpose

One list. Threads on my content where the last message is not mine and contains a question. Across three or four platforms. Sorted by age, oldest first, because the old ones are the ones I have already failed once.

That is it. No sentiment scoring, no priority model, no digest email. The hard part is not the ranking, it is that almost none of these platforms give you a clean way to enumerate your own threads and walk their comment trees, and the half that do rate limit you into uselessness. Every attempt I have made ends up either scraping something fragile or being a folder I forget to open.

The question

Has anyone actually solved this for themselves? I am interested in the version that survives a busy week, not the elegant one. A cron job and a text file counts. A saved search counts. If your answer is "I just check every morning", I want to know what you check, because I thought I was doing that too.

I build AI Applyd. It applies to jobs for you across the twelve ATS platforms we cover, and counts an application as sent only when the employer's own system confirms it.

A confirmation page is not a confirmation

Ava Bagherzadeh — Tue, 25 Aug 2026 11:42:56 +0000

The page says "Thanks for applying". Maybe it shows a reference number. You close the tab, tick it off your list, and move to the next posting.

As far as you know, that application exists.

Sometimes it doesn't.

Who is actually telling you it worked

The confirmation screen is rendered by the page you were already on. It is your own browser reporting back on what your own browser just did. That's not nothing, but it's the weakest kind of evidence there is, because it can be true in every visible way and still be wrong underneath.

A file attachment that reported as uploaded but sent zero bytes. A required question below the fold that failed validation on a step you already passed. A session that expired between page four and page five. In each of those the screen can still look like success.

The only evidence that means anything comes from the other side. Something the employer's system produced, not something yours did.

The two checks, both free

Check one: the receipt email, within a few minutes. Greenhouse, Lever, Ashby and most modern applicant tracking systems fire an automatic acknowledgement almost immediately. If ten minutes pass and there's nothing, including in spam, treat that as a signal rather than as normal. Some employers genuinely disable the acknowledgement, so this is not proof of failure on its own. It's the first thing to look at.

Check two: the candidate portal. Workday, iCIMS, SuccessFactors and Taleo all make you create an account. That account has a page listing your applications. Log back in a day later and look. If the application is listed there, it exists in their system, and no confirmation screen is needed. If it isn't listed, you have your answer.

Do both and you know. Do neither and you're relying on a screen that was only ever describing itself.

What to do when one is missing

Don't immediately resubmit. Duplicate applications look careless and some systems reject the second one silently, which puts you right back where you started.

Instead: open the posting again in a fresh tab. If the ATS shows "you have already applied", it's in. If it shows you a blank form as though you'd never been there, that's the strongest signal you'll get that the first attempt didn't land, and now resubmitting is the right call.

Why I care about this so much

I work on AI Applyd. We build the thing that fills in employer forms and submits them, and the hardest part of that job was never the filling in. It was proving the application arrived.

So we stopped scoring our own work on what our own browser reported and started scoring it on what the employer's system sent back. The receipt, the portal entry, the request the other side actually accepted.

That's the standard I'd hold any tool to, including ours, and honestly including your own spreadsheet. A row that says "applied" is a record of your intention. A receipt is a record of theirs.

You already uploaded your resume. Now type it in again.

Ava Bagherzadeh — Tue, 25 Aug 2026 11:42:48 +0000

Every application starts the same way. You find the posting, you click Apply, and the first thing the form wants is your resume. You upload it. It parses. There's a little green tick. Then you scroll down.

First name. Last name. Email. Phone. Street. City. Postal code. Country.

Then work experience. Company, title, start date, end date, description. Add another. Company, title, start date, end date, description. Add another.

You just handed them a document with every one of those fields in it. The form read it. It said so. And now it wants you to type the whole thing in again by hand.

Why the form does this

Resume parsers are unreliable and the vendors know it. A two-column layout, a table, a date written as "Jan '23" instead of "January 2023", and the parser drops a role or shifts a job title into the company field. Rather than ship a product that quietly loses your last employer, the ATS vendors made a design decision: parse it, prefill what we can, and make the human confirm every field.

That decision is defensible. It's also why the same twenty minutes of typing happens on every single application you send.

The part that makes it worse

The forms are not the same form. Workday wants an account before it will show you anything, and its work-history widget is its own little application. Greenhouse is one long page. Lever is short but hides required questions below the fold. Ashby is a single-page app that loses your place if you refresh. iCIMS wants you to re-upload the resume you already uploaded.

So it isn't one form you get fast at. It's a dozen forms you get slow at, over and over, in random order, at eleven at night.

What I'd actually do about it

Three things that cost nothing:

Keep a plain text version of your resume open in another tab. Not the PDF, the text. Copy-paste beats typing, and it stops the small drift where the dates on your application don't match the dates on the document you attached.

Fill in the work history from the bottom up. Most forms put the newest role first but validate the oldest one last. Doing it in the order the form validates means fewer surprise errors after you've already spent fifteen minutes.

Screenshot the confirmation screen before you close the tab. Not because it proves anything, but because the reference number on it is the only thing you can quote later if you need to ask what happened.

And the honest pitch

I work on AI Applyd. This exact problem is the reason it exists. An agent opens the posting, fills the employer's own form field by field the way you would, answers the screening questions from your profile, and submits. You keep the tab closed and the evening back.

The promise is simple: you should never have to type your own work history into a box again. You already wrote it down. Once should be enough.