軟體工程師的 ATS 履歷檢查清單（2026）

通用的 ATS 建議會漏掉工程師特有的陷阱。行銷履歷不會有五行技術 stack，工程師會，而那一塊正是 ATS parser 要嘛乾淨抓出關鍵字、要嘛漏掉一半訊號的關鍵地點。GitHub 連結、技術 bullet、leetcode 提及、OSS 貢獻——這些一般 ATS 指南都不會講，因為它們是寫給所有人的。

這篇是寫給工程師的版本。後端、前端、SRE、ML 工程師都可以在每次投遞前跑一遍的職能對應檢查表。

為什麼工程師履歷的 ATS 行為不一樣

大型科技公司一個 mid-level 工程師職缺通常收到 200-500 份履歷。它們的 ATS 設定來抓特定欄位：每個語言用了幾年、列出哪些框架（要原文一致）、雲端平台、JD 提到的工具名稱要原樣出現。如果你把這些訊號埋在敘事 bullet 裡，parser 會漏掉，排序演算法會把你排在那些技能列得乾淨的人後面。

第二個關卡：工程 JD 通常列 12-25 個技術要求。非工程師可能挑出 5-6 個認得的、其他用通用語帶過。工程師必須把每一個都當成獨立的關鍵字確認，要嘛對上要嘛知道自己漏了。沒有「我寫過後端系統」這種中間地帶可以同時涵蓋 Go、gRPC、PostgreSQL。Parser 不會推論。

關於 ATS 系統怎麼讀履歷的基礎，看 ATS 優化指南。這篇是疊在那上面的工程師專屬手法。

程式碼密集履歷的 parser 安全排版

大多數工程師 default 的兩種失敗模式：太花俏（icon、圖示、雙欄排版會搞砸 parser）或太擠（4 行用逗號分隔的技術，parser 沒辦法乾淨切詞）。

規則：

• 單欄。雙欄排版會被重新排列，你放在右邊的技能區塊常常被推到 parsed text 最底，權重就垮了。
• 標準段落標題：Experience、Education、Skills、Projects。不要替換成 Tech Stack、Engineering Toolkit。Parser 是用有限的標題字典在比對。
• 不要表格、不要文字框、bullet 旁邊不要 SVG icon，會被丟掉。
• 一個字型，內文 10-11pt。PDF 沒問題；不確定的話 .docx 比較保險。
• 不要照片。你的程式碼就是照片。
• 日期格式：Mon YYYY - Mon YYYY（例如 Jan 2023 - Mar 2026）。Present 適合用在現職。
• 檔名：firstname-lastname-resume.pdf，不要 Resume_v17_FINAL_FINAL.pdf。有些 ATS 會把檔名直接顯示給招募人員。

如果你要一個照這些規則做的起點，ATS-friendly resume template 是經得起主流系統 parsing 的格式。

GitHub、作品集、Stack Overflow 連結要放哪

工程師履歷比其他職位有更多高訊號的連結。放兩個地方：

1. 頁首區塊：github.com/yourname 和作品集網域，跟 email、城市同一行。ATS 會把這當聯絡資訊抽出來，招募人員也會點。
2. 相關專案 bullet 內：當 bullet 在描述 side project 或 OSS 貢獻，連結放在那條 bullet 結尾。這是真人審閱時會點的版本。

三個常見錯誤：

• 連結藏在「GitHub」或「see project」這種 anchor text 後面。一半的 parser 會丟掉 URL 只留 anchor。直接寫網址。
• 連到空的或停滯的 GitHub。如果你 top pinned repo 是 2019 年的 fork 加課程作業，這條連結是扣分的。要嘛養好要嘛省略。
• 把 Stack Overflow 連結放在 GitHub 之前（除非你是非常資深）。SO reputation 是好訊號但比現行程式碼弱。GitHub 在前。

LinkedIn URL 也放這裡。Parser 通常會抽出來。確認 LinkedIn 上的職位和日期跟履歷完全對得上。這層的不一致是招募人員把履歷打標「inconsistency review」最常見的原因。

各 stack 真正會影響分數的 20 個關鍵字

大多數 JD 圍繞著各 role family 的可辨識集合打轉。這些關鍵字出現會明顯拉高 match score，缺席通常表示你漏掉一個 must-have。

Backend（Go / Java / Python / Node.js）：distributed systems、microservices、REST、gRPC、message queues（Kafka、SQS、RabbitMQ）、PostgreSQL 或 MySQL、Redis、Docker、Kubernetes、AWS 或 GCP、CI/CD、observability、system design、code review、on-call。

Frontend（React / TypeScript / Next.js）：React、TypeScript、Next.js、accessibility（a11y）、Core Web Vitals 或 web performance、GraphQL 或 REST 消費、design system、component library、testing（Jest、React Testing Library、Playwright）、responsive design、browser compatibility。

SRE / Infrastructure：AWS / GCP / Azure、Terraform、Kubernetes、observability（Prometheus、Grafana、Datadog）、incident response、SLO / SLI / error budget、runbooks、on-call rotation、cost optimization、networking、Linux、security best practices。

ML / AI 工程：PyTorch、TensorFlow、transformers、LLM、RAG、vector database（pgvector、Pinecone、Weaviate）、prompt engineering、model evaluation、fine-tuning、AWS Bedrock 或 Azure OpenAI、MLOps、data pipelines。

要對上 JD 的精確措辭，不要用同義詞。Kubernetes 和 k8s 對 parser 來說不可互換，雖然對人來說可以。JD 用 k8s 三次，履歷就用 k8s。JD 用 Kubernetes，履歷就用 Kubernetes。不確定就兩個都列。

關於招募端如何衡量不同類型的技能，看 hard skills vs soft skills。

Leetcode 和 OSS 貢獻怎麼出現（或不出現）

初階到 mid-level：簡短提及如果真實又近期就 OK。可以接受的例子：

• 「Leetcode top 5%（1,800 rating、600+ 解題）」——前提是真實且現行。
• 「OSS: 14 merged PRs to [project]，包含 [specific feature]」——前提是具體可驗證。

會扣分的例子：

• 「Active on Leetcode」沒有數字。讀起來像填字。
• 「Contributed to open source」沒講哪個專案。同上。
• 任何資深以上履歷上提到 leetcode。到那個層級這已經低於用人主管在乎的 noise floor。

Side project 寫法：先寫成果，技術 stack 放結尾括號。「Built X that reached Y users / processed Z requests / saved $W」遠強於「Built X using React、Node、MongoDB、Docker、AWS」。Stack 放結尾括號就好。招募人員掃成果；parser 哪邊都會抓到 stack。

關於轉換職位時專案要怎麼框架，看 career change resume。

工程師專屬的量化模式

通用建議是「量化你的 bullet」。這對但不夠完整。工程師有用人主管真的會比較的具體維度：

• 延遲 / 效能：「Reduced p95 latency from 800ms to 120ms」勝過「Improved performance significantly」。
• 吞吐 / 規模：「Service handles 12k RPS at peak」或「processed 4.5B events/day」。
• 成本：「Cut AWS spend by 38%（$14k/mo）by migrating cron jobs to Lambda」。
• 可靠性：「Raised SLO from 99.5% to 99.95% over two quarters」。
• Code review / mentorship：「Reviewed avg 35 PRs/week; mentored 3 junior engineers to mid-level」。
• 出貨節奏：「Led 6 launches in 12 months; 5 hit committed dates」。

如果不知道精確數字，給範圍。「Reduced query time roughly 4x」可以接受。要避免的是「Improved query performance」，那一句什麼資訊都沒傳達。

投遞前 60 秒最終檢查

每份工程師申請投遞前都跑一遍：

• [ ] 頁首：github.com/yourname 和作品集 URL 寫成完整網址（不要藏在 anchor text 後），加上 LinkedIn URL
• [ ] Skills 區塊：12-18 個技能，全部對齊 JD 措辭，列得乾淨（沒 icon、沒 progress bar）
• [ ] JD 提到的 stack：每一個 must-have 技術在履歷至少出現一次，理想是 Skills 和 bullet 各一次
• [ ] 最近一份工作的前 3 個 bullet 對應 JD 前 3 項要求，依順序
• [ ] 量化：至少 60% 的 bullet 有數字（延遲、規模、成本、RPS、%）
• [ ] Side project：先寫成果，stack 放結尾括號。每個專案有可運作、有內容的連結
• [ ] 格式沒跑掉：用跟你存檔不同的 viewer 開 .pdf。如果排版偏移，重存或改 .docx
• [ ] 檔名：firstname-lastname-resume.pdf
• [ ] 比對分數：對 JD 達 75%+ 關鍵字匹配

最後一條最容易 game 也最一致地預測 callback 率。Tailor 60 秒給你那個分數，加上漏掉哪些關鍵字、應該補在哪一條 bullet。

什麼時候不要照清單做

三個工程師 ATS 優化要放鬆的情境：

1. Staff+ / Principal 等高階職位：這個層級的履歷被人讀的比例高過 ATS，篩選標準轉向 scope、技術領導、設計判斷。關鍵字密度仍重要，但敘事更重要。
2. Research / FAANG L5+ 但 JD 寫得很泛：當 JD 寫「strong CS fundamentals, willingness to work on hard problems」，沒東西可以對齊。優先優化清晰度和影響力。
3. Founding engineer / 早期新創：履歷主要是創辦人讀，不是招募人員，他們明確要 range。打磨過的通才贏過窄領域專家。

其他情況清單都成立。跑一次、把 pattern 存下來、之後每份申請花 5 分鐘而不是 30 分鐘。工程師履歷的客製化複利比任何其他職類都大，因為 JD 的關鍵字密度更高。

對 104 履歷的補充

台灣求職如果走 104，平台限制了排版，前面的格式規則大半不適用。但關鍵字對齊和量化的規則仍然成立。如果你同時投外商和本土，建議維持一份依照本檢查表的英文版，附 link 或檔案。雙語工作流程詳情看 English resume for Taiwan job seekers。

更大的視角

ATS 優化是地板不是天花板。通過 parser 是必要不是充分。過了篩選之後，履歷還是要讀起來像一個有在建東西、有 own outcome、把摸過的系統都改得更好的工程師。檢查表帶你過閘門，履歷裡的 bullet 才是讓你拿到面試的東西。

這兩個技能是可以分開的，多數工程師權重抓錯了：80% 的力氣花在打磨 bullet、20% 在 parser 衛生。第一版反過來分配，之後再 iterate。