Companies switch ATS providers, restructure their websites, or change subdomains. A URL that returns jobs today might 404 or redirect silently in three weeks. The watch list needs URL maintenance, not just company maintenance – and silent failures here are particularly dangerous.

This isn't a problem that needs automation – it needs detection + a quick re-discovery path, because the failure itself is rare. Three layers handle it:

Layer 1: Detection is already built in. The weekly cycle hits every URL anyway. If a URL returns 404, a redirect to a homepage, or an empty response, the script flags that company as "URL broken" instead of silently treating it as "no open positions." That turns an invisible failure into a visible task.

Layer 2: ATS-first reduces exposure significantly. For the ~80% of companies on known ATSs (Greenhouse, Lever, Ashby, etc.), the URL the script calls is controlled by the ATS provider, not the company. That token almost never changes unless the company switches ATS providers entirely. Real URL rot is mostly a problem for the ~20% on custom career pages.

Layer 3: Re-discovery when it breaks. When a URL fails, a semi-automated lookup can shortlist candidates: check the company's main domain for a /careers or /jobs path; search {company_name} site:greenhouse.io or site:lever.co to detect an ATS migration; check their LinkedIn company page – the "Jobs" tab always points to the current active source.

"Growth Manager," "Performance Marketing Manager," "Acquisition Lead," and "Digital Marketing Manager" can describe identical roles at different companies. A keyword-based Position_description_list will miss non-standard titles systematically.

Approach 1: Give the logic. Instead of listing exact keywords, define the logic of what you're looking for – a semantic description that captures intent, not just title. For example: "Performance marketing roles responsible for paid acquisition, unit economics, and growth metrics – regardless of whether the title says Growth, Performance, Acquisition, Digital, or Marketing." In a more advanced implementation, this description is passed to an LLM to evaluate each collected job title and description against the intent.

Approach 2: Wide net + clustering. Collect all positions broadly, then run clustering on the results (by title similarity, description keywords, or embedding similarity) to group roles that describe the same thing. Review the clusters once to identify which match your target and tag accordingly.

As the watch list grows to 80+ companies, maintaining it becomes its own job. There is no cap, pruning strategy, or review cadence defined. The time cost of list maintenance may partially offset the time saved by automation.

The lists are just structured data – markdown files in a folder – which means any AI assistant with file access acts as a conversational database on top of them. Instead of manually editing files, you say "add X to the watch list" or "move Y to skip, they just had layoffs" and it's done. Tools like Cowork (Claude's desktop agent for file and task management) make this the default interaction pattern, but any similar setup works. A scheduled task that runs monthly and prompts a review ("your watch list has 90 companies – do you want to audit it?") closes the cadence gap.

Company_fit_criteria_list is acknowledged as "the trickiest to get," but the only suggested starting point is companies you've worked at before. For someone re-entering a market or changing industries, this is a significant bootstrap problem with no solution proposed.

Same "give the logic" approach. The person isn't actually starting cold – they have domain knowledge, market awareness, and professional history. The bottleneck was never information, it was translating that knowledge into a structured list. You give Claude the logic – "I'm looking for B2B SaaS companies between Series B and Series D, European HQ, English-first culture, strong growth metrics focus" – and it populates the initial list from that description.

A company on the skip list today – due to a hiring freeze, wrong leadership, or bad funding news – might be a great fit in six months. The skip list has no expiry date or periodic review trigger. It only grows, and stale entries quietly eliminate valid opportunities.

The time horizon makes this concern irrelevant. Over a 4–12 month job search, core exclusions don't meaningfully change. If healthcare isn't a fit now, it isn't a fit for the duration of the search. Skip list staleness is a concern for a permanent, multi-year system – not a time-bounded tool.

You can only filter for things you know to add to the list. Unknown unknowns – a company's undisclosed relocation requirement, internal culture issues, or financial instability – slip through until discovered the hard way, after time has already been spent.

We automate known things. Unknown unknowns that only surface during an interview are outside the scope of automation by definition. The interview exists precisely to surface those things. Accept the boundary.

The one nuance: when a new deal-breaker is discovered during an interview, add it to the Hard_stop_list for future cycles. The list self-improves over time – new data points discovered the hard way become filters that prevent the same mistake twice.

The article flags LinkedIn's algorithm for optimizing engagement over precision (the false positive problem), then relies on that same algorithm's recommendations to surface new companies in Branch B. The quality of the input determines the quality of the entire pipeline.

The filter is already there. LinkedIn's noisy recommendations don't flow straight into the watch list – they pass through the human evaluation step. The flawed signal gets caught before it does any damage.

Improve the signal without changing the architecture. The passive feed is the noisiest part of LinkedIn – it optimizes for engagement, not relevance. Replacing it with active LinkedIn search (filtered by company size, industry, growth stage, keywords) uses the same platform but on your terms.

Optional: supplement with one cleaner source. Platforms like Crunchbase or Wellfound allow filtering by funding stage, industry, and headcount with no engagement algorithm distorting results. Adding one such source alongside LinkedIn gives Branch B a higher signal-to-noise ratio without significant extra effort.

Application results – no response, rejection, interview, offer – contain the strongest signal about whether criteria are correctly calibrated. Currently that signal is discarded. The lists can be sharpened manually, but there is no mechanism to learn systematically from what is and isn't working.

What's already there. Things discovered during interviews already feed back into Hard_stop_list. That's a feedback loop, just not a structured one.

The practical addition: outcome logging. After each application, log the result alongside the job entry – no response, rejection (at which stage), interview, offer. This is one extra field in the database. Over time, patterns emerge: consistently getting no response from companies of a certain size, or consistently advancing further with a specific type of company.

Pattern analysis with Claude. Once you have a few weeks of data, you can ask: "Here are my 20 applications and outcomes – what patterns do you see?" Claude identifies which criteria seem well-calibrated and which might need adjusting.

What not to automate. Trying to automatically infer why you didn't get a response isn't worth it. Ghosting happens for too many reasons unrelated to fit.

A weekly cycle is better than monthly, but for high-competition roles in fast-moving markets, the application window can be 24–48 hours. Weekly is still too slow for those cases.

Tier 1 (top targets) → 24–48 hour cycle. For the companies where you'd drop everything to apply immediately, a daily or 48-hour check eliminates the timing risk entirely. Technically trivial – it's just a different cron schedule for a subset of the watch list.

Tier 2 (everyone else) → weekly cycle. You're not racing to be first for every role, only the high-priority ones.

One requirement: the cycle cadence and the human review cadence must match. If the script flags a new role every 24 hours but you only check results weekly, nothing is solved. The notification needs to surface in a way that gets seen – a daily digest rather than a dashboard you open once a week.

Approximately 26% of active LinkedIn employers use Easy Apply only and have no external career page. These are silently excluded from Branch A with no fallback handling.

Easy Apply rarely works for a targeted, senior, or specialist job search. It is primarily used by companies with high-volume, low-specificity hiring – roles where they want maximum applicant volume rather than precision. The overlap between "Easy Apply only companies" and "companies on your watch list" is close to zero. The ~26% exclusion is not a real loss for this type of search.

A manual search has random gaps – you miss things unpredictably. A list-driven system has systematic gaps: if a good company never makes it onto Companies_to_watch_list, it is permanently invisible, and the system still looks complete. The structured feel of the approach can create false confidence in coverage.

Algorithmic recommendation systems don't achieve perfect recall – that's well-established. LinkedIn optimizes for engagement, not for surfacing every relevant company to every relevant candidate. So yes: there are companies that fit your criteria, are actively hiring, and will never appear in your Branch B feed.

The correct response is not to argue this can't happen, but to ask whether it matters enough to act on. Two things keep this gap manageable.

The watch list baseline isn't zero. Branch A starts from companies you already know – past employers, clients, competitors, companies you've encountered over years of working in this space. The systematic gap is smaller than it appears because the starting point is domain knowledge, not a blank slate.

Closing the gap completely isn't worth the cost. Eliminating algorithmic blind spots would require continuous manual market scanning – exactly the kind of work this system was designed to replace. Some coverage loss is the price of having a system at all. The alternative is no system.

The article notes that automating LinkedIn discovery "may conflict with LinkedIn ToS," but the practical consequence is more serious than a footnote: account suspension during an active job search means losing your primary professional network at the worst possible moment.

The ToS risk applies to bots, scrapers, and crawlers that automate LinkedIn access. In this design, LinkedIn is touched only manually – you check recommendations yourself and save company names. That's using LinkedIn normally, which is exactly what it's designed for. The automated parts of the system (ATS API calls, career page checks) never touch LinkedIn at all. LinkedIn is intentionally kept as the manual step, which means the ToS concern was already mitigated by design before it was flagged as a pitfall.

If the automation works well and surfaces 15 qualified roles per week instead of 5, the time saved in sourcing is partially consumed by the increased volume of tailored applications needed. The bottleneck shifts from finding to applying, which may limit the net time gain.

This is not a pitfall – it's the goal. More qualified roles in the pipeline means more opportunities, which is exactly what the system is designed to produce. Spending time on tailored applications is where the time should go – the entire point of automating sourcing is to free capacity for the high-value work of crafting strong applications. A shift in bottleneck from sourcing to applying is a success state, not a failure mode.