軟體工程師的英文履歷怎麼寫
更新於 2026-09-02
軟體工程師的英文履歷，比的是範圍與所有權。技術清單再長也不算數。看履歷的人在找三件事：你負責的系統邊界在哪、系統承受什麼負載、出事時你在不在場。列了十五種語言、每一行卻沒有主詞的履歷，這三題全部空白。
描述系統要用負載與約束。「Built with React and Node.js」只說了材料；「serving [N] requests per day with a p95 under [N] ms」才說了工程。這一頁所有範例都是英文，因為外商履歷的成品語言是英文。數字的位置一律留 [N]。那些數字必須是你自己的：面試時要守住它們的人是你。
以下依序是版面結構、三個層級的 summary、依職能分組的 bullet、改寫前後對照、技能區的取捨、ATS 關鍵字、常見錯誤，以及每一句主張會招來的面試追問。
這個職位的英文履歷，完成後長這樣
下面是一份虛構人物的完整範例，由產品的排版引擎渲染成真正的頁面，分數由同一套規則引擎現算——不是我們打上去的。缺的數字一律留 [N]，所以分數停在上限以下；那不是範例的缺陷，是產品的規則在示範。
Wei-Ting Lin
Education
- Built a distributed key-value store for the systems capstone that sustained [N] thousand ops/sec under a simulated network partition
- Mentored [N] first-year students as the systems programming lab teaching assistant, rewriting the debugging handout the course still assigns
Experience
- Cut p95 order-routing latency from [N] ms to [N] ms by replacing synchronous fan-out with a worker pool
- Halved on-call pages by adding SLO-based alerting and deleting [N] alerts that had never preceded an incident
- Designed the payment-webhook idempotency layer, ending [N] duplicate charges a month refunded by hand
- Shipped a Go log shipper handling [N] million events a day, replacing a pipeline that dropped [N]% at peak
- Built the integration test harness adopted by [N] teams, cutting release regressions from [N] to [N] per quarter
- Led the CI migration from Jenkins to GitHub Actions, shortening median build time from [N] min to [N] min
- Automated the nightly catalog reconciliation in Python, retiring a manual checklist two operations staff worked through every morning
- Instrumented checkout with request tracing, surfacing the slow inventory call behind [N]% of abandoned carts
- Consolidated [N] thousand product images onto one CDN path with generated thumbnails, cutting median product-page load from [N] s to [N] s
Projects
- Launched an open-source token-bucket limiter now used in production by [N] companies, with [N] GitHub stars
- Rebuilt the capstone key-value store on a from-scratch Raft implementation, which doubled sustained write throughput under simulated partitions
Additional Information
版面結構與順序
單欄、標準標題、不用圖示與技能條。這是 ATS 解析的前提。雙欄會把兩段經歷讀成一段，星等圖示在解析器眼裡直接消失。
順序的原則只有一條：最強的證據先出現。工程師的最強證據幾乎都在 Experience，所以其他區塊都為它讓路。
- 1Summary
三句話：層級、領域、你最站得住的一個量化事實。看的人用這段決定要不要往下讀。
- 2Experience
倒序。每段三到五條 bullet，動詞開頭、有範圍、有 [N] 結果。這區應占掉整頁六成以上。
- 3Projects（選用）
有真實使用者、或有值得被追問的工程決策才放。寫法與工作經歷完全相同。
- 4Skills
只列近期實際出貨用過的技術，按類別分組。這區的作用是關鍵字對照表，寫短一點。
- 5Education
工作三年以上放最後、一到兩行。新鮮人可前移並附相關修課與專題。
三個層級的 Summary 範例
Summary 是你最強證據的預告。三個層級各一例，數字留 [N] 由你自己填。
Backend engineer with internship experience building and operating services in Go and PostgreSQL. Shipped a rate-limiting middleware adopted by [N] internal services and handled production incidents under supervision. Looking for a team where code review and operational ownership start on day one.
新鮮人要寫的是一件有使用者的事。Middleware 被 [N] 個服務採用，就是可以被追問的事實。
Software engineer with [N] years across payments and logistics systems, owning services from design review to on-call. Cut p95 latency and infrastructure cost on systems handling [N] requests per day. Comfortable being the engineer who writes the design doc and then answers for it in production.
中生代要讓人看見所有權的完整範圍：從設計到 on-call。最後一句講工作方式，比任何形容詞都有資訊量。
Senior engineer setting architecture direction for a [N]-service platform and mentoring [N] engineers across two teams. Retired two legacy systems without downtime and turned recurring incident patterns into roadmap items. Works best where technical decisions are written down, argued, and revisited on evidence.
資深的證據是留在別人身上的變化：系統被安全退役、事故模式進了 roadmap。整段沒有一個字在自我評價。
依職能分組的 bullet 範例
工程師的 bullet 按職能分組看最清楚。每一條的骨架相同：動詞、範圍、方法、[N] 結果。
交付與迭代速度
· Shipped a checkout service rewrite in [N] weeks by cutting scope to two payment flows, then closing the remaining edge cases over [N] follow-up releases.
· Cut deployment lead time from [N] days to [N] minutes by moving the team to trunk-based development with automated canary rollouts.
· Delivered a partner-facing API from design doc to production in [N] weeks, including a versioning policy and a migration path for [N] existing integrations.
可靠性與除錯
· Diagnosed a memory leak that restarted production pods every [N] hours, tracing it to an unbounded cache and shipping the fix within one on-call shift.
· Cut P1 incidents from [N] to [N] per quarter by alerting on user-visible symptoms instead of host metrics.
· Raised availability of the order service to [N]% by adding retry budgets and circuit breakers at the three most failure-prone downstream calls.
效能與成本
· Reduced p95 checkout latency from [N] ms to [N] ms by batching downstream calls and moving session lookups into an in-memory cache.
· Cut monthly infrastructure spend by [$N] by right-sizing over-provisioned instances and archiving [N] TB of cold data to object storage.
· Profiled a report-generation job, removed an O(n²) join, and brought runtime from [N] hours to [N] minutes at peak volume.
架構與取捨
· Split a monolith into three services along team ownership lines, keeping shared billing logic in one place to avoid distributed transactions.
· Chose PostgreSQL over an event-sourced design for the order system, trading replay ability for operational simplicity, and documented when to revisit the decision.
· Introduced idempotency keys for payment writes, eliminating duplicate charges under retry storms without adding a distributed lock.
跨職能協作
· Turned a vague “make search better” request into [N] measurable relevance fixes by pairing with support to label the worst-failing queries.
· Wrote the rollout plan for a pricing change with product and legal, sequencing feature flags so each market could launch independently.
技術領導
· Onboarded [N] engineers with a paved-path starter service and a written runbook, cutting time to first merged change from [N] weeks to [N] days.
· Ran design reviews for a [N]-engineer group, cutting rework by requiring a one-page decision doc before implementation starts.
改寫前後對照
同一段經歷，弱寫法與強寫法的差距。why 指出的缺陷，比改寫本身更值得記住。
Responsible for backend development of the e-commerce platform.
Owned the order and inventory services for an e-commerce platform serving [N] daily users, including schema design, on-call, and two major version migrations.
差在哪 · 「Responsible for」只說了座位在哪，沒說做了什麼。改寫後有範圍（兩個服務）、有規模（每日 [N] 使用者）、有可追問的事實（版本遷移）。
Used React, Node.js, Docker, Kubernetes, AWS, Redis, and MongoDB to build applications.
Built the seller dashboard in React against a Node.js API, containerizing the stack so preview environments spin up per pull request in [N] minutes.
差在哪 · 工具清單不是成就。動詞換成 built，工具只留故事需要的那幾個，並補上工具帶來的結果：per-PR 預覽環境。
Improved system performance significantly.
Cut p95 API latency from [N] ms to [N] ms by adding a read-through cache and removing [N] redundant database round trips per request.
差在哪 · 「Significantly」無法查證。改寫給出指標名稱（p95）、前後值留 [N]、加上方法。面試官可以沿著任何一點往下問。
Participated in the migration to microservices.
Migrated the notification pipeline out of the monolith, designing the queue-based interface and running both systems in parallel for [N] weeks before cutover.
差在哪 · 「Participated」看不出你做了哪一段。改寫指名你負責的服務、你設計的介面、你怎麼降低切換風險。
Wrote unit tests to ensure code quality.
Raised branch coverage on the billing module from [N]% to [N]% and wired the suite into CI so regressions block merge instead of reaching production.
差在哪 · 寫測試是日常。亮點在覆蓋率的變化，以及測試被放進守門的位置：擋在 merge 之前。
技能區怎麼取捨
技能區的原則是可辯護：白板上不敢被考的，不要出現在紙上。
值得佔版面的
Go · TypeScript · Python · React · Node.js
PostgreSQL · Redis · Kafka · Docker · Kubernetes · AWS
CI/CD · OpenTelemetry · load testing · incident response
可以刪掉的
- Microsoft Office · 沒有工程師因為會 Office 被錄取，放著只稀釋版面。
- 碰過的每一種語言（C++、PHP、Ruby⋯） · 面試官會從清單裡挑最弱的一個往下問。留下願意被白板考的，其餘刪掉。
- Hard-working、fast learner 之類的形容詞 · 沒有證據的主張是雜訊。學得快，就用轉換技術棧的實例寫進 bullet。
- Agile / Scrum · 每間公司都自稱敏捷，這個詞不產生區別度；除非你實際帶過流程，否則刪掉。
ATS 關鍵字
ATS 先比對關鍵字，人才看內容。以下是這個職位常被比對的詞，按類別分組。
只放你的經歷撐得起的詞：被問到答不上來，比沒寫更傷。堆關鍵字對解析器不加分，在人眼裡只是雜訊。
履歷之外的證據：GitHub 與可查證的東西
工程師的履歷是索引，證據在別的地方。放上去的連結一定會被打開，所以每一個連結都要當作「對方馬上會點」來寫。以下是他依序看到什麼、履歷上哪一行指過去，以及什麼時候不放連結才是對的。
- GitHub 個人頁：釘選欄、最後更新時間、貢獻圖
看的人通常在你第二段經歷還沒讀完時就把分頁開好了。他先看到的不是程式碼，是釘選的那幾個 repo、每個 repo 旁邊的 updated 日期，以及貢獻圖是不是一片空白。釘選欄有六格，那是上限不是配額：放三個你願意逐行解釋的，比六個湊數的有力。公司的私人 repo 可以在設定裡打開「計入貢獻」，圖就不會像一個廢棄帳號，內容一樣看不到。
- README 不用捲動的那一個螢幕
假設對方只讀第一屏。那一屏要交代三件事：這東西解決什麼問題、你做了哪個取捨、一行指令怎麼把它跑起來。安裝步驟排在架構圖前面，因為前者他會照做，後者他只會掃過。沒有 LICENSE 的 repo，在公司法務眼裡是不能用的程式碼。
- 一個現在打得開的網址
會動的東西比會編譯的東西更快換到信任，前提是它此刻真的會動。免費方案睡著的服務只回一個轉圈圈，示範帳號密碼過期等於一個繞路的 404。送出履歷那天早上，自己用無痕視窗開一次。開不起來就把網址拿掉，只留 repo，別讓對方替你發現。
- 履歷上真正指過去的那一行
上面那份範例的 header 沒有 GitHub 欄，指路的是 Projects 區每個專案自己帶的一行：ratelimit-go · Go, Redis · github.com/[你的帳號]/ratelimit-go。個人頁本身值得被打開時，才把 github.com/[你的帳號] 放進 header。兩個都放，等於要對方多點一次才找到你真正想給他看的東西。
- 不放連結才是對的時候
個人頁只有課堂作業、一排 fork、最後一次提交在兩年前——這個欄位刪掉。刪掉不是認輸：改成在 Projects 寫一個做完的小東西，範圍窄、講得清楚、面試時你能當場打開檔案往下捲。空的個人頁是主動邀請對方去看你手上最弱的證據。
- 可以被查的，和只是你說的
星數、下載量、被合併的 PR，對方點一下就知道。所以寫進 bullet 的數字要跟今天頁面上的一致；數字小就不要寫，改寫這段程式在做什麼。證照同理：AWS 與 CKA 都發可查的憑證編號與到期日，履歷上就把發證年份寫出來，過期的標明或拿掉。紙上說有、查詢頁說沒有，沒有人會當成筆誤。
- 不能公開的工作要怎麼指
公司的 repo 給不出去，但形狀可以講：什麼負載、什麼約束、你負責哪一段介面，不帶客戶名字也不帶他們的資料。真正能被查證的替代品是外溢出來的那部分——你送進上游套件的修補、被合併的 issue 討論、公開投影片的技術分享。那些東西留著你的帳號，而且不屬於你的雇主。
工程師履歷的常見錯誤
- 1技能區列出碰過的每一種語言
清單越長，單項可信度越低。面試官挑最弱的問，一題答不好，整份清單都被重新估價。
- 2用框架名稱代替系統描述
「Built with React and Node.js」只講了材料。負載、資料量、延遲要求這些約束，才是工程能力的證據。
- 3Bullet 沒有主詞，看不出你做了哪一段
「The team migrated…」的功勞不屬於任何人。動詞前面站的必須是你：designed、migrated、debugged。
- 4Side project 偽裝成工作經歷
被發現的代價是整份履歷的可信度。獨立放 Projects 區塊，有使用者或有值得追問的決策才寫。
- 5雙欄版面與圖示化技能條
ATS 逐行解析文字：雙欄會把兩段經歷讀成一段，星等圖示直接消失。單欄與標準標題是底線。
- 6GitHub 連結指向空的 repo
放連結等於邀請對方點開。裡面只有課堂作業跟 fork，不如不放。
每句主張會招來的追問
履歷上的每一句主張，都是你自己出的面試題。寫之前先想：這句話被追問三層，你守得住嗎。
Cut p95 latency from [N] ms to [N] ms.
p95 是在哪裡量的？客戶端、負載平衡器，還是服務本身？同一段期間 p99 怎麼變？
說得出量測點、時間窗口與流量條件。若 p99 沒動或惡化，自己先講，比被挖出來好。
Scaled the service to [N] requests per second.
瓶頸是什麼？CPU、資料庫連線池，還是鎖競爭？下一個瓶頸會出現在哪裡？
準備當時負載測試的方法與數字來源。「加機器」不是答案；要能解釋為什麼那個架構水平擴展有效。
Migrated the monolith to microservices.
哪些部分你決定不拆？事後看，哪一條服務邊界切錯了？
可信的邊界故事必然包含沒拆的部分、和一個承認的失誤。答「都拆對了」會被解讀成你不在做決策的位置。
Reduced production incidents by [N]%.
分母是什麼期間？incident 的定義與嚴重度分級，期間內改過嗎？
講清楚計算窗口與定義。分級標準若調整過要主動說明，否則數字會被當成敘事而不是量測。
Led a team of [N] engineers.
Led 指的是管人、定技術方向，還是專案協調？他們的績效評估有你一份嗎？
外商對 lead 的用字敏感。先想好你守得住的定義，並準備一個你實際拍板的技術決策當例證。
常見問題
沒有知名公司的經歷，英文履歷會不會直接被刷掉？
第一層篩選是 ATS 的解析與關鍵字比對，不看公司名字。你能控制的是把系統規模、負責邊界、可查證的結果寫清楚。這一頁的 bullet 結構就是為此設計的。
真的以公司名字篩人的，多半是獵頭主動出擊的職位。那是投遞策略的問題，履歷解決不了。
Side project 可以當工作經歷寫嗎？
不能混進 Experience，但值得獨立一個 Projects 區塊。條件是有真實使用者，或有值得被追問的工程決策。寫法與工作 bullet 相同：範圍、方法、[N] 結果。
職缺要求的技術棧我只碰過一部分，要照 JD 補關鍵字嗎？
只補你守得住的。相鄰技術可以誠實分層：主力寫 Go、Kafka 用過但沒調過參數，就放在技能區的次要位置，不寫進成就 bullet。
這裡的生成器不會替你加上你沒提供的技術。這是刻意的設計。
英文履歷要放照片、年齡或 GitHub 嗎？
照片與年齡不放，多數外商的合規流程反而排斥這些欄位。GitHub 只在裡面有可看的東西時放。只有空 repo 與 fork 的頁面，不如不放。
工程師履歷一頁還是兩頁？
十年以內的經歷，一頁。要刪就從舊經歷下手，別縮小字級。三年前的職位縮成兩行，版面留給你現在最強的證據。
把你的系統，寫成面試官想追問的樣子
用中文照實描述你做過的系統與規模，AI 以 Tech 視角改寫成這一頁等級的英文 bullet。四項分數由規則引擎計算，同一份稿重測數字不變。缺的數字一律留黃色 [N] 空格由你自己填：面試時要守住那個數字的人是你。
免費生成 2 次接著讀
同一位的英文求職信
信只引用履歷上的事實，逐段說明每一句在做什麼，旁邊是量測引擎現算的信件檢查。
軟體工程師的英文求職信怎麼寫