163 Scored Roles, 125 Overdue Follow-Ups, and What That Says About Job Hunting

Two numbers came off my own tracker this month. 163 freshly scored roles, sitting in the markets I actually want to work in. 125 follow-ups past due. I built the machine that produced the first number, and I am personally the reason for the second.

I am working out where to go next, and being the sort of person who cannot leave a manual process alone, I automated the looking. That part went well. The pipeline pulls roles, scores them against my background, and hands me a ranked list every morning, which felt like real progress for about a week.

Then I looked at the two columns side by side. At any honest rate of work, that is roughly three weeks of queued effort sitting there before a single new search result matters to me at all. Which is a strange thing to find out immediately after spending a weekend making the search faster.

The part I automated was never the scarce part

Finding roles is a solved problem and has been for years. Feeds, boards, alerts, scrapers, a dozen tools that will all cheerfully hand you a hundred plausible openings by Tuesday. I did not build anything clever there. I built a scoring layer on top of something the internet already gives away.

Following through is the part that does not automate, and I think it genuinely cannot, because it is not one task. It is 125 separate acts of remembering one specific human on one specific day, in a way that reads like a person wrote it, at the moment it will still be welcome.

The scoring layer does earn its place, to be fair to it. Most of what a feed hands you is a role that looks right in the title and is wrong by the third requirement, and having something rank that before I read it saves me a genuinely miserable hour a day. But a rank is a convenience, not a judgment. It tells me what order to read in. It has never once told me whether to apply.

There is a habit PMs fall into where you build what is buildable rather than what is binding, because the buildable thing produces a number on a dashboard and the binding thing produces a knot in your stomach. I have called teams out for it. Then I spent a weekend doing it to myself with more automation than most of those teams had.

Three bugs that never announced themselves

While I was in there, I found three things wrong. All three had been wrong for a while. None of them had ever produced an error message anywhere I would see one.

The autopilot was scoring me against the wrong resume version. Every score it produced was arithmetically correct and computed from a document I had already replaced. That is the worst failure a scoring system can have, because it keeps producing numbers, and numbers look like health. Nothing on the board says “confident, precise, and about a file from last month.”

The daily reports were filed under the wrong day. toISOString() returns UTC. IST runs five and a half hours ahead of UTC, so anything generated in the early hours got stamped with the previous date. The contents of the report were fine. The label on it was not, and the date field is exactly the one nobody re-reads.

The third one had been dead the longest. node: command not found, under launchd, since 17 August. A scheduled job does not inherit the PATH your login shell has, so the tracker render had simply not run for two weeks. Nothing crashed. The board just stopped changing, and a board that stops changing looks precisely like a quiet fortnight in the job market.

What links all three is that the system kept reporting success. That is the standing tax on automating anything you care about: you lose the ability to tell “nothing happened” apart from “nothing was attempted.” A job search you have handed to a machine that has quietly stopped is worse than no machine at all, because you are still spending the belief.

My own tool subtracted my best facts

This is the one that actually stung.

I build Jobtune, a resume product. I ran my own tailoring pass against a real job description, and it came back shorter in the places that mattered. It removed the line about turning down a Director of Product offer. An insurance product I embedded inside Microsoft Copilot went too, along with a scoring feature I shipped and five entries off the skills list.

Tailoring turned out to be subtractive. The pass was optimising for overlap with the job description, and anything the JD did not mention got read as noise. Which is defensible logic and completely wrong, because the facts that make me worth a phone call are exactly the ones the posting did not think to ask for. A job description is written by somebody describing the person they have already imagined. Match it perfectly and you have made yourself the median applicant with better keyword density.

The declined offer is the clearest example. No JD anywhere asks whether you turned down a Director role. It is also, for the person reading, one of the few lines that says something about judgment rather than scope.

The fix was plumbing, which it usually is. I rebuilt the document through the API instead of the UI, because the bullets are HTML list strings and a form-fill flattens them on the way through. A rendering detail was eating content, and the content it ate happened to be the good stuff.

I am not fully sure how much of this is a bug versus the honest output of the objective I handed it. Probably more the second, which is less comfortable, and a useful thing to know about every tailoring tool on the market including the one I sell.

The counterweight is a step in the same pipeline that blocks fabricated claims in cover letters and screener answers. The model is not allowed to invent a number about me, and that is tested rather than assumed. So one half of my machine refuses to add a fact about me while the other half was busy deleting them. That is a funny place for a resume product to end up, and I would not have found it without running it on myself.

D+3, D+10, D+21, and what the overdue column costs

The cadence I actually run is three touches. Day three is the acknowledgement, short, low information, mostly proof that a human is on the other end. Day ten is the one that works, I think, because it lands after the first pass through the pile and before the shortlist hardens into a decision. Day twenty-one is the last polite one, and if it goes nowhere, that is fine, it has done its job by closing the loop.

Day three is worth almost nothing on its own, which is why people skip it, and skipping it is a mistake. It carries no new information about me. What it does is put a timestamp on the thread that is not the application itself, so that when the day-ten note arrives it lands inside an existing conversation rather than opening a cold one. The cheap touch exists to make the useful touch possible.

The cadence only works inside its window. That is the whole thing about follow-ups that the tracker does not tell you.

Past a certain point the message changes genre. On day forty you are not following up, you are reintroducing yourself, and a reintroduction needs a reason to exist that a follow-up does not. Most people cannot manufacture that reason on demand, so they send nothing, and the thread ends without either side deciding anything. So the 125 in that column is less a to-do list than a record of conversations that went cold while I was looking at the other column, the one with the shiny new roles in it.

That is the real cost, and it is not measured in effort. It is measured in the difference between a warm thread and a stranger.

I still have not decided what to do with the backlog. Working through it means sending 125 messages that are late enough to read as late, which is its own kind of signal. Deleting it means admitting the machinery generated a number I was never realistically going to act on, which is the more useful admission and the one I keep not making.

The tracker renders every morning now, on the correct date, scored against the right document. There is a column in it I have not opened this week.