DEV Community: Ava Bagherzadeh

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.

The same ghost job is charging you three times

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

You open a listing and something about it feels familiar. The title, the bullet about "fast-paced environment", the same slightly-off salary band. You check your tracker. You applied to this in March.

Except you didn't, not to this one. This is a different URL, on a different board, posted eleven days ago.

It is the same job.

Syndication is the part nobody explains

When a company posts a role, it rarely stays in one place. The ATS pushes it to the company careers page, then to the aggregators, then the aggregators repost each other. Each hop adds its own tracking parameters:

https://boards.example.com/jobs/1234?utm_source=indeed&utm_campaign=q3&gh_src=abc
https://www.example.com/careers/1234?ref=linkedin
https://aggregator.example/j/1234?s=email&t=daily

Three URLs. One job. Your tracker sees three rows, because a spreadsheet compares strings and those strings are different.

So when the role is a ghost — a listing kept open to collect a pipeline, or one that was filled internally in week one — it doesn't cost you one application. It costs you every time you meet it again and don't recognise it.

The check you can run on your own tracker tonight

Take your spreadsheet. Add a column. For each URL, strip everything from the ? onwards, and lowercase what's left. Sort by that column.

=LOWER(LEFT(A2, IFERROR(FIND("?", A2) - 1, LEN(A2))))

Count the duplicates. Most people are surprised, and the number is worse for anyone applying through aggregators rather than company pages.

That's it. No tool required, and it will tell you something your row count has been hiding.

Why I did not build ghost-job detection

I run a product in this space, so the obvious feature request lands in my inbox constantly: filter out the fake postings.

We have the code for it. A scoring service, several modules, tiers, a cross-check against layoff news. It is not wired into the apply path, and I left it that way deliberately.

When I looked at what the score actually measured, it was recency, whether a salary was disclosed, and description length. That's a proxy for "this listing looks well maintained". A ghost job is defined by intent, and none of those three observe intent. A well-maintained ghost job scores well.

The tell was that I could not write a test that would fail if the feature were wrong. If you cannot construct the failing case, you have not built a check. You have built a number that goes up.

What actually helps

A uniqueness constraint, which is a much duller thing.

Normalise the URL, strip the tracking parameters, and enforce a unique index on the pair of (user, normalised posting). Then the same job syndicated across four boards collapses into one record, and the second attempt is rejected by the database rather than by a judgement call.

Detection is a claim. Deduplication is a constraint. A claim asks you to trust that someone's scoring is good. A constraint is enforced by something that cannot be reasoned around, and when it fails you get an error instead of a quietly wrong answer.

It does something far smaller than detecting ghost jobs. It means a posting that was never real costs you once instead of three times. That happens to be the difference you can actually feel at the end of a month.

The general version

I have started asking it of anything that sounds intelligent: is there an index or a uniqueness rule underneath this, or is it a model output wearing a confident label?

Often the honest version is smaller, duller, and works.

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

Every ATS loses your application somewhere different

Ava Bagherzadeh — Tue, 25 Aug 2026 10:23:50 +0000

It is eleven at night and you are on your thirtieth application of the day. The upload resets. You retype your address for the fortieth time this week. You hit submit, a page says thank you, and you add another row to the spreadsheet.

Here is the part nobody tells you: some of those rows are fiction.

Not rejected. Not ignored. Never received. The company has no record of you at all, and you will never find out, because the failure looks exactly like the silence you were already expecting.

Each system drops you in its own specific way

We run applications across the twelve ATS platforms we cover at AI Applyd, which means we get to watch the same application succeed on one and vanish on another. The failures are not random. Each platform has a signature.

Workday loses you at the account. Every company runs its own separate Workday tenant, so the account you made for one employer does not exist at the next. People assume they are logged in, breeze through, and submit into a session that was never associated with a candidate profile.

Lever refuses on an empty required dropdown. The form looks complete because the empty field is below the fold or renders as a custom component that never took a value. The submit returns an error page, and if you already closed the tab you never saw it.

Greenhouse is a single form with no account at all, which sounds simpler and is, except that means there is nothing to log back into. There is no record on your side. Your only evidence is the confirmation email, and if it went to spam you have nothing.

iCIMS has no anonymous path. You must create an account, and the account creation and the application are separate steps that people routinely half-finish.

Ashby will accept a complete, correct form and still refuse it, because it scores the submission itself and can reject on signals that have nothing to do with your answers.

Five platforms, five completely different ways to end up with no application and no idea.

The one thing your resume cannot survive

Before any of that, there is a failure that happens before a human or a filter ever sees you.

Your PDF can contain zero extractable text. If it was exported as an image, or built in a design tool that outlines the fonts, the parser reads nothing. Not "reads it badly". Nothing. Your form comes through with empty fields where your history should be.

You can check this in five seconds: open the PDF, try to select a sentence with your cursor. If you cannot highlight the text, neither can the parser.

Two checks that cost nothing

Look for the employer's own confirmation, not the job board's. Workday, Greenhouse, Lever and iCIMS each send their own receipt within a few minutes of actually receiving you. A board saying "application sent" is not that. It is the board reporting on itself, and it is what most people are reading as proof.

Where the ATS gives you an account, open your own application list. Workday and iCIMS both do. That list is the employer's copy of reality. If a role you applied to is not on it, that application does not exist, no matter what your spreadsheet says.

Do those two things on your next five applications. If all five check out, your problem is genuinely upstream and you can stop worrying about this one. If even one of them is missing, you have just found out something your tracker could never tell you.

Why we built the product around this

Every tool in this category can tell you it clicked submit. That is easy, and it is a claim about our own software rather than about your application.

AI Applyd counts an application as sent only when the employer's own system confirms receipt. Their receipt, not our click, across the twelve ATS platforms we cover. It is the one signal in the whole chain that we did not generate ourselves, and it is the only one worth showing you.

It means we sometimes have to tell a customer an application failed, on a screen where a competitor would show a green tick. That trade is the product.

Your resume is probably fine. Your cover letter is probably fine. Find out whether the form ate it.

How we built an application tracker that cannot lie to you

Ava Bagherzadeh — Mon, 24 Aug 2026 11:31:19 +0000

Most software tells you what it did. AI Applyd tells you what the employer did, and the difference
is an architecture decision you can copy.

Here is the design, because I think the pattern generalises to anything that hands work to a system
you do not control.

The rule the whole system is built on

No state that matters may be writable by us.

One field decides whether an application counts as sent. That field can only be written by an inbound
email from the employer's applicant tracking system, classified to a positive landing stage. Our
click cannot set it. Our screenshot cannot set it. A retry cannot set it. There is no admin path that
sets it.

landing_confidence = 100  AND  submission_verified = 1

100 is reserved and architecturally unreachable from our own telemetry. Everything we observe about
our own session tops out below it. The only way to reach 100 is for a company to reply.

Why you would design it this way

Because the alternative is a mirror.

Every application tool can show you the fields it filled, the file it attached and the button it
clicked. Read that list again: it is the tool reading back its own input. It proves the software has a
memory. It proves nothing about whether an employer received anything.

We know precisely how that fails because we instrumented it. A form widget can hold your typed text in
the visible box while the value the form actually submits stays empty. The tool reads the box, sees
its own text, and reports success. A check that reads your own write can never fail while the write
works, which is exactly why it is worthless.

So we stopped scoring anything on our own behaviour.

The pieces

A relay address per user. Applications go out with an address we control, so the employer's
acknowledgement comes back to us instead of vanishing into a personal inbox. That reply is the only
evidence that exists.

A classifier on the inbound. Acknowledgement, rejection, interview invitation, or noise. Only a
positive landing stage writes the field.

A reserved value. 100 cannot be produced by any of our own signals, so no amount of internal
optimism can round up to it.

A twelve-platform submitter. Greenhouse, Lever, Ashby, Workday, iCIMS, Personio, Teamtailor,
SmartRecruiters, Recruitee, Breezy, Workable, Rippling. Each one gets a real form filled properly,
including the widgets that quietly submit empty.

What it buys the person using it

They know where they stand. Not "submitted" as a hopeful noun. Confirmed, with the timestamp of
the company's own reply.

Silence becomes information. These acknowledgements arrive in seconds to a couple of minutes. When
one has not arrived, that is a fact about the submission, and it can be retried while it still
matters rather than discovered in three weeks.

They stop paying for nothing. A submission a company never confirmed does not count against their
plan. That pricing rule only exists because the confirmation exists. You cannot build it on top of
your own click.

The property I like most

We cannot fake our own success metric. The one number that matters can only be written by somebody
else's mail server.

That is an uncomfortable way to build a company and a very easy one to trust. If you are building
anything that hands work to a system you do not own, the question worth asking of every check you
have written is whether it would read differently had the other side failed. If it would not, you do
not have a check.

I build AI Applyd. It scores, tailors and submits applications on the
company's own hiring system across twelve platforms, and only counts one as sent when that company
confirms it. Interviews on your calendar, not rejection emails in your inbox.

I built a robot that applies for jobs. The hard part was proving it worked.

Ava Bagherzadeh — Sun, 23 Aug 2026 20:38:11 +0000

The demo was never the problem.

A browser agent that opens a job posting, reads the form, writes your history into it and clicks submit is a weekend of work now. It looks like magic in a screen recording. You can film one this afternoon.

The problem is the sentence you have to say afterwards: it worked.

I spent one full day, eight hours and seventeen minutes, and twelve real applications on real postings, chasing four failures. I landed none of them. Every experiment cost about fifty-six minutes, because most of that was waiting for a deploy to reach the machines that run the applications before the test could even begin.

Three separate fixes to one small function shipped fifty-five minutes apart, then fifty-four minutes apart. All three were properties of the same HTML element, and all three were findable in a single pass with a browser open in front of me.

The whole time, a local test rig was running on my own laptop. Thirty-six hours of uptime. Its log recorded zero bytes during my entire working day.

The actual bug, when I finally opened the page like a person instead of reading logs like a detective, took two minutes. A field I was reading as a textarea was an input.

Production is a verifier, not a debugger

That is the rule I got out of the day, and it cost enough that I now enforce it in writing.

A production run answers exactly one question: does this hold in the real world. It answers that question expensively, slowly, and once. Using it to find a bug means paying full price for every guess, and you will guess a lot, because the feedback arrives an hour later stripped of everything you needed.

A local rig answers a hundred cheap questions badly and one expensive question not at all. That is the correct division. Look at the page, fix it locally, verify it locally, and only then spend a real run on the things a laptop structurally cannot answer: capacity, queueing, anti-bot behaviour, the employer's actual response.

The order matters more than the tooling. Look, then fix, then verify, then spend. I had it backwards for a day.

The instrument is the thing that lies

Here is the deeper version, and it is the single most useful idea I have taken out of building this.

Most of my hardest bugs were not bugs in the system. They were bugs in the thing measuring the system.

A form field reported as filled, because the check read back our own typing rather than asking the widget what it had committed. Seventeen fields, all confirmed, all empty.
A metric that read zero for a feature that was working perfectly, because the measurement armed itself eighteen seconds after the event it was supposed to measure.
A watchdog that killed live sessions for going quiet, when quiet was what a long submission looks like. Its own reset then removed the signal that would have told it so, which made it produce the next reason to fire.
A daily alarm that paged me at full severity for an incident I had already fixed the previous afternoon, because it computed its rate over a rolling twenty-four hours and the burst was still inside the window.

Every one of those looked exactly like a broken product and was in fact a broken measurement. The failure mode is symmetrical and horrible: you fix things that were never wrong, and you ignore things that are.

So I wrote a rule and put it where I cannot avoid reading it:

An absence is not evidence until you have proved you were watching. Prove the instrument was armed at all, prove it was armed before the event and still armed after, and prove the mechanism works when a human does it by hand. If you cannot prove all three, the correct word is unobserved, not absent.

The distance between absent and unobserved is where most of my wasted engineering time has lived.

Why this ends up being the product

Once you have been fooled by your own telemetry enough times, you stop trusting any signal you generate yourself. And the moment you apply that to a job application tool, the entire design falls out of it.

Our own click is not evidence. Our own screenshot is not evidence. Our own status field is not evidence. The only thing that proves an application exists is the company's own system replying, and that reply arrives at an address we control, gets classified, and is the only thing that moves an application to sent.

It is a harder product to build and a much easier product to trust, and it means the number on the dashboard is the one number I cannot fake for myself.

That is not a marketing position. It is what is left after you stop believing your own instruments.

I am Ava Bagherzadeh, building AI Applyd as a solo founder. It scores, tailors and submits applications on the company's own hiring system, and only counts one as sent when that company confirms it. Interviews on your calendar, not rejection emails in your inbox.

Your job application isn't sent until the company says it is

Ava Bagherzadeh — Sun, 23 Aug 2026 20:37:26 +0000

There is a moment every job seeker knows. You finish the fourteenth form of the week, you hit submit, the page goes white, and something appears that says Thank you for your interest.

Then nothing. For weeks.

And you cannot tell the difference between they read it and passed, they never opened it, and it never arrived at all. Three completely different situations, one identical experience.

I build a product that applies to jobs on your behalf. So I had to decide what my product is allowed to call sent. That decision turned out to be the entire product.

What everyone counts

Ask any application tool what proof it can show you, and you get some version of this list:

the fields it filled in
the answers it gave to the open questions
the resume and cover letter it attached
a confirmation it saw on screen

Read that list again. The first three are the tool reading back its own input. It typed a value into a box, then printed the value it typed. That proves the tool has a memory. It proves nothing at all about whether an employer received anything.

We know because we shipped exactly that, and it was confidently wrong.

Our agent once reported a form as fully completed. Seventeen fields written, seventeen confirmed. Zero of those values reached the employer. The fields it was reading were the ones it had just typed into, and the values the form actually submits sat empty underneath. The check could not fail while the typing worked. It was a mirror, not an instrument.

The fourth item, the on-screen confirmation, is better and still not enough. Plenty of forms show a thank-you page and then refuse the submission behind it. We have watched a hiring system return a clean success page and separately record a refusal, on the same request, for the same posting.

What we count instead

An application is sent when the company's own system says something back.

That is a specific, boring, mechanical thing. Every applicant tracking system in wide use sends an automated acknowledgement. It arrives from their domain, or the vendor's, within seconds to a couple of minutes. Something like this:

Thanks for applying to StackAI

Our applications route through an address we own, so that reply comes to us. We classify it, we match it to the application it belongs to, and only then does that application change state. Nothing we observe about our own session can produce that state. Not the click, not the screenshot, not the status code, not our own confidence.

This has a consequence I like more every time I explain it: we cannot fake our own success metric. The one field that matters can only be written by somebody else's mail server.

The three-verb ladder

Once you look at this category with that lens, everything sorts itself by one question: who performs the last verb?

Some tools stop at you review. They draft, you approve, you submit. The last verb is yours, which means the work is still yours.
Some tools stop at we submit. The last verb is theirs. Better, and it is still a claim about their own behaviour.
We stop at they confirm. The last verb belongs to the employer.

That is not a feature comparison. It is a standard. If your application tool cannot show you something the employer produced, you are being shown a receipt the shop wrote for itself.

What it changes for you, concretely

When the only thing that counts is an outside confirmation, four things follow.

You know where you stand. Not "submitted" as a hopeful noun. Confirmed, or not yet confirmed, per application, with the timestamp of the reply.

Silence becomes information. These acknowledgements arrive fast. When one has not arrived in a few minutes, that is a signal about the submission, and it can be retried while it still matters, rather than discovered in three weeks when you wonder why nobody called.

You stop paying for nothing. A submission the company never confirmed does not count against your plan. That rule only exists because the confirmation exists. You cannot build that pricing on top of your own click.

Ghost postings stop being invisible. A listing that never acknowledges anything, from a company still posting it every three weeks, is telling you something. You just have to be counting the right thing to hear it.

The part I would tell my competitors

I am not writing this to say we are cleverer. Our first version had the same defect as everyone else's, and it took a production run where seventeen out of seventeen fields were empty to make us look properly.

The defect is seductive because the code is easier, the tests are green, and the dashboard is full. Reading your own input always succeeds. That is exactly why it tells you nothing.

If you build anything that hands work to somebody else's system, an application, a payment, a webhook, an upload, ask one question of every check you have written:

Would this read differently if the other side had failed?

If the answer is no, you do not have a check. You have a mirror.

I am Ava Bagherzadeh. I build AI Applyd, which scores, tailors and submits applications on the company's own hiring system across the twelve platforms most companies actually use. Interviews on your calendar, not rejection emails in your inbox.

What actually happens to your resume after you hit submit

Ava Bagherzadeh — Sun, 23 Aug 2026 18:15:55 +0000

I run a system that fills in job application forms on company hiring platforms, all day, across the twelve systems most companies actually use. Greenhouse, Lever, Ashby, Workday, iCIMS, Personio, Teamtailor, SmartRecruiters, Recruitee, Breezy, Workable, Rippling.

Which means I have watched, in logs, the thing you never get to see: the sixty seconds after you press the button.

Here is the real sequence. Four of these six steps can drop you without anybody deciding anything about you.

1. The file is parsed, not read

The first thing that happens is not a person. It is a parser pulling a text layer out of your PDF.

This is the step that eats people alive, because a PDF can look perfect and contain no text at all. If your resume was exported by anything that renders the page to an image, a design tool, a screenshot, some web builders, then the file is a picture. The parser extracts nothing, and your application arrives as a blank form with your name on it.

Ours did this. For months. Our own export produced a PDF with zero text-showing operators inside it, a JPEG in a PDF wrapper, and our own importer read it back empty. A real person then retyped their entire history by hand rather than fight it.

Check yours right now. If you have pdftotext, run pdftotext resume.pdf - | wc -c. Under a hundred bytes means you are sending a picture. If you do not, open the PDF in any viewer and try to select a line of text with your cursor. If nothing highlights, no parser can read it either.

That one check is worth more than any keyword advice you will read this year.

2. The parse is mapped to fields

The parsed text gets mapped into structured fields. Name, email, employers, dates, titles, education.

Two-column layouts, tables and text boxes are where this goes wrong, because reading order in a PDF is not visual order. A parser walking the content stream can interleave your left column into your right one. Your five-year role at one company becomes three months at another.

Single column. Real headings. Ordinary dates. This is not a style opinion, it is a parsing constraint.

3. Knockout questions run before any human is involved

Work authorisation, notice period, location, salary expectation, sometimes a years-of-experience number. These are evaluated by rules the recruiter configured, and they run before a person opens anything.

A blank answer here is not neutral. Many of these forms treat an unanswered required question as a disqualification rather than an omission, and the form itself will often refuse the submission entirely.

This is where a lot of "I applied and heard nothing" actually happens, and it is invisible from the outside. There is no message. There is no rejection. The application simply never enters the queue a human looks at.

4. The form validates, and can refuse you politely

The form runs its own validation, and it does not always tell you the truth on screen.

We have watched a hiring system return a perfectly clean confirmation page while separately recording a refusal for the same submission. We have watched a form refuse a complete application, with every field filled and a valid token attached, purely on an automated reputation score. The reason came back in the response body: the score was below the threshold. Nothing about the application was wrong.

If that can happen to a system built to watch for it, it is happening to people who cannot see the response body at all.

5. The acknowledgement is sent, or it is not

If the submission is genuinely accepted, the system sends an automated acknowledgement. It arrives fast, seconds to a couple of minutes, from the vendor's domain or the company's.

This email is the only proof you will ever get that your application exists. Not the thank-you page, which is rendered by the same code that can refuse you afterwards. Not your own sense that it went fine. The reply.

If you apply somewhere and no acknowledgement arrives within a few minutes, treat that as a fact about the submission and not a fact about your candidacy. Apply again, from a different browser, and watch for the reply.

6. Only now does the queue exist

Everything above happened before a human being saw anything. What reaches the recruiter is a row in a list, sorted by whatever their view is sorted by, with the parsed version of you in it.

The parsed version. Not your PDF.

What I would actually do with this

Four things, in order of how much they matter and how little time they take.

Verify your PDF has a text layer. Two seconds, and it is the single highest-value check in job hunting right now.
Answer every question on the form, especially the ones that look optional. Blank is not neutral.
Watch for the acknowledgement email. Give it five minutes. No acknowledgement, no application.
Keep the acknowledgements. They are the only evidence you will have when a company says they never received anything.

None of this is about writing a better resume. It is about the fact that between you and a person, there are four machines, and each of them can drop you without an opinion.

I am Ava Bagherzadeh. I build AI Applyd. It applies on the company's own hiring system and only counts an application as sent once that company's system confirms it, for exactly the reasons above. Stop getting filtered out before a human ever reads you.

Zero asset requests was the tell: finding a scraper in 50 seconds of logs

Ava Bagherzadeh — Sun, 23 Aug 2026 16:13:28 +0000

Four alarms fired overnight. Two database contention pages, one read-replica collapse, and a batch of metrics that came back empty.

Four alarms, one cause, and the cause was not anything we shipped.

The wrong first instinct

The reflex when four alarms land at once is to open the deploy log and start reading diffs. I did that for a few minutes. It is almost always wasted time, and there is a cheaper question that settles it.

Did request volume change?

workersInvocationsAdaptive, grouped by script, per hour
  prod-api  3.6K/hr  ->  18K/hr   at 01:00Z
  prod-web  3.6K/hr  ->  17K/hr   at 01:00Z

Both workers stepped up five times at the same minute and stayed there. A deploy does not do that. Traffic does. One query, and the entire code-review lane is closed.

The database side matched:

d1AnalyticsAdaptiveGroups, by databaseRole
  primary reads  15-28K/hr  ->  sustained 37-46K/hr  at 01:00Z

D1's primary is single-threaded. Roughly ten queries a second is about 36K an hour, so we were sitting above the ceiling. Everything downstream, the refusals, the replica page, the empty metrics, is one queue backing up.

The 50 seconds that named it

wrangler tail aiapplyd-prod-web --format json

Fifty seconds of live requests. 187 of them. What was in there:

155 of 187 from one hosting provider's VPS range, across eight or more addresses, geolocated to a single country.
Plain desktop Chrome user agents, rotating across five major versions plus a macOS build. No bot user agent anywhere. Nothing in robots.txt would have stopped it, because it never asked.
152 requests to /jobs/{id} and 29 to /companies/{slug}. Nothing else.

That last line is the whole diagnosis.

Not one CSS file. Not one JS chunk. No font. No favicon.

A browser cannot render a page without them. A human cannot browse without a browser. So whatever this was, it was reading HTML and discarding it, at a rate of roughly four pages a second, walking two URL families in ID order.

The rotating user agent is what makes this worth writing down. It is a deliberate signal that the client wants to look human. The asset requests are the signal it forgot to fake, and they are free to check because they are already in your logs.

Why caching was not the answer

The first three suggestions in the room were all cache-shaped: longer TTL, more edge caching, a stale-while-revalidate window.

None of them help. The two families being walked hold hundreds of thousands of distinct IDs. Every request is a unique URL, on a first visit, at a rate the origin cannot absorb. A cache that never gets a second request is an extra hop. You cannot cache your way out of an enumeration.

What does work, in order of how quickly it can be deployed:

Rate limit by ASN or by IP prefix, not by user agent. The user agent is attacker-controlled. The network path is not.
Serve the enumerable families cheaply. If they are not indexable anyway, they do not need a database read per request.
Verified-bot checks are not free. On our plan, the verified-bot field is enterprise-only. We reached for it, we could not have it, and knowing that in advance would have saved twenty minutes.

The two instrumentation lessons

Tail the worker that is actually being hit. Our API worker sees requests from our own frontend worker, which forwards without the original user agent. Tailing the API would have shown a wall of identical internal requests and nothing else. The client's fingerprint only exists at the true front door. Name the process that receives the traffic, then tail that one.

And check the alarm's window before you believe it. One of these alarms re-fired the next morning at full severity for an incident that had been fixed the previous afternoon, because it computed its rate over a rolling 24 hours. The burst was inside the window. The verdict was stale.

A rate wants a wide window. A verdict wants a recency gate. If you only have one window, you get paged for your own fixes, and the day you stop trusting the page is the day it is real.

I build AI Applyd. We scrape job listings ourselves, on a strict budget and only from sources that allow it, which is exactly why I recognise the shape of a client that does not read your CSS.