你打開了關於理想職缺的每日通知郵件，卻發現該職缺已經上線五天了。你沒有看錯——以下是資料如何從公司的職涯頁面傳到你信箱的實際流程。
大多數積極求職者最終都會注意到相同的模式：求職提醒郵件送達，職缺看起來很理想，你點進去，發布日期卻寫著「5 天前」或「1 週前」。當你實際投遞時，你發現已經有 200 人搶先一步。等你到達人工篩選階段時，招募人員已經在進行候選名單面試了。
這不是任何一個求職網站的缺陷。這是整個聚合層架構的必然結果。
幾乎每家現代公司都透過求職者追蹤系統（ATS）發布職缺。按市佔率大致排序，主要的 ATS 有：
當公司發布一個職缺時，一旦在其 ATS 上線，就會產生一個公開 URL。該 URL 是權威的事實來源。其他一切——聚合網站列表、贊助職缺、招募人員的推播——都是下游的。
主要求職網站透過以下三種機制之一從這些 ATS 系統中取得職缺資訊：
部分 ATS 供應商提供合作夥伴 API，將新職缺推送給選定的聚合網站。這是最快的路徑——通常從發布到索引只需幾分鐘——但僅用於高價值的合作關係，而且聚合網站仍需在將職缺公開於搜尋之前進行去重、分類和品質過濾。
聚合網站按照合理的排程（通常每天一次，有時更頻繁）訪問每家公司的職涯頁面，下載 HTML 並解析出個別職缺。這是大部分延遲的來源——即使每天只造訪一百萬個公司頁面中的每一個都是沉重的基礎設施負擔，而且大多數聚合網站會對爬取進行優先排序，高流量的公司被爬取的頻率高於長尾雇主。
較小的雇主和招募機構透過聚合網站的表單或資料流直接提交職缺。這對提交者來說很快，但往往會引入雜訊（重複刊登、重複的職缺，有時甚至是假職缺）。
在此之上，聚合網站還運行自己的排名和即時性訊號，因此即使職缺被索引後，也可能不會立即出現在你的儲存搜尋結果中。他們首先最佳化「為這個使用者找到合適的職缺」，其次才是「最新的職缺」——這兩個目標確實會相互權衡。
管線中的每一步都增加了延遲。一個職缺到達你儲存搜尋電子郵件的典型時間線：
最好的情況，你在職缺上線 24 小時後才看到它。最差的情況，一週。對於知名雇主的職缺——收到申請最快的職缺——即使 24 小時也是顯著的劣勢。
三件事，按效果排序：
1. 直接 ATS 監控（這就是 FirstPost 所做的）。如果你直接監控 ATS 端點，你就跳過了整個聚合層。大多數 ATS 系統會為公司的開放職缺提供 JSON 或 RSS 源——這就是公司自己的網站渲染職涯頁面的方式。這是除了在公司內部之外最快的訊號。
2. 利基社群。對大多數領域來說，都有一個小型的社群經營求職版或電子報，職缺在數小時內由人工提交。這些覆蓋範圍較小但即時性更好，而且提交的篩選通常意味著品質高於大型聚合網站。
3. 對精選清單設定直接申請提醒。如果你有 20 到 50 個目標雇主，每天自動檢查這些特定職涯頁面比在整個 LinkedIn 上進行通用儲存搜尋更有用。你是在用廣度換取速度和訊號品質。
每種搜尋策略都是廣度、即時性和訊號品質之間的取捨。聚合網站以犧牲即時性和訊號品質來最大化廣度。直接監控以犧牲廣度來最大化即時性和訊號品質。
對於積極求職者——尤其是針對特定雇主或競爭性職缺的人——計算結果通常有利於即時性。你在第一天投遞的職缺和你在第五天投遞的職缺不是同一個機會，即使它們是同一則職缺列表。