很幸運在五月底終於找到工作了（aka 願意收留我的公司 😭）！半年餘的準備過程中，除了感謝還是感謝，家人們的支持，朋友們的建議與推薦的工作們，以及數不清超好用卻都免費的資訊，才能讓（半個？）轉職仔的我能專注於準備工作可能需要的知識與技能。

也因此，本篇能分享的準備過程也有諸多限制，僅專注於「非本科」但「有程式相關經驗」者，在轉職「後端工程師」的準備過程。（雖然我最後上的是資料工程師 🥸）

其他我認為同等、甚至更重要的因素都無法討論到。像是

  • 如何更有效運用時間 → 我從退伍後就家裡蹲，專心準備找工作。所以如果是在職轉職、有時間壓力（ex. 1 個月內從零轉職）或是財務壓力的狀況，則參考價值較低。
  • 如何得到身邊人的支持與理解 → 準備過程中沒有和家人起過衝突，所以也沒有太多相關的溝通經驗。
  • 如何從零開始轉職 → 我碩士期間即有修和資訊系統、商業分析相關的課，因此在準備前已經有 Python / Ruby 後端專案開發經驗，以及 Python 資料分析經驗。

雖然有這麼多面向無法討論到，而且網路上已經有很多前輩分享了很有價值的文章們，我卻仍想記錄準備過程，因爲剛退伍打算專心準備時，卻發現

「即便在學期間已經有相關經驗，真的要認真為工作做準備時，卻仍然因為範圍之廣、領域之雜而不知從何下手。」

1. 緣起｜是蟲是龍摸不清

當認真以「後端工程師」為目標，開始準備並整合過往所學時，我感覺建議很分歧（這部分純粹個人感覺，並沒有實際的數據或是調查支持 🤓），大概可以分這幾種：

  1. 刷題派 Leetcode 刷起來，寫得又快又好是重點。感覺這類型通常是面大公司居多？
  2. 作品派 即戰力最重要，要讓業主看到自己能做什麼。最有效精準的做法，就是仿製和申請公司類似的產品，然後轉成作品集。這類型好像是新創或是中小公司較多？
  3. 基礎派 應該要搞懂基礎原理，不變應萬變，掌握基礎就可以快速理解各種框架。這種感覺是頂尖公司 OR 學院派？
  4. 學歷派 學歷夠純碩論夠強，直接碾壓。這種感覺也是外商 OR 大公司居多？不過因為我與此路線無關，所以沒有細究。

由於過往準備相當不充分，因此，剛開始準備時，無論從哪個方向入手，都可以有很大的成就感。（學歷派因為要砍掉重練太痛苦，所以不納入考慮）然而，當準備過幾週後，心中難免升起「這樣可以嗎？還是應該要那樣？」的騎驢找馬心態，總是會想在刷題／作品／基礎派的路線間切換。

而針對該心態細究，則大致可能是：

  1. 認真為工作做準備時，卻仍然因為範圍之廣、領域之雜而不知從何下手
  2. 從 刷題／作品／基礎 派中，依照個人偏好挑選主要路線，以及安排其他路線的比重（ex. 刷題 50% / 作品 30% / 基礎 20%）
  3. 準備一陣子後，不確定比重是否需要調整
  4. 不確定的原因是
    1. 不確定應徵職缺的面試官會看中哪些面向
    2. 不確定自己應該要準備到何種程度

因此，重新整理疑惑，應該會更像是

  1. 我不知道面試官會問哪些項目 → 範疇界定（Scope）
  2. 針對這些項目，我的程度有多少 → 成效評估（Measure）

必須要 釐清準備的範疇（WHAT），以及 如何評估成效（HOW），才能有辦法回推自己的準備計劃。

遺憾的是，我面試經驗很受限（主要只面試了2間公司3個職缺），而當有能力針對面試結果評估自己的準備成效時，即有幸找到合適的工作。因此，也無法迭代調整出更精準的成效評估策略。

因而整篇紀錄的邏輯，是建立在

根據既有的面試經驗，針對這七個月的準備經驗，評估範疇（Scope）以及準備成效（Measure）

2. 背景｜10年變不見

若要清楚交代七個月準備計劃的過程與效果，勢必得先交代我在準備前的狀態，才能更有效說明準備過程中的取捨。

  1. 程式啟蒙（2013 - 16） 高中時（2013 - 2016）曾經參加學校的 IOI （資訊奧林匹亞）培訓營，但在北市賽就被刷掉了。當時對於 C / C++ 有基礎概念，但理解程度僅限於初階的 pointer / class, 也主要是學習解題。因此，基礎的資料結構（likned list, graph）和算法（DFS, BFS），都僅停留在「知道但寫不出來」的程度。
  2. 興趣使然（2016 - 21） 大學期間因為非資訊本科，只要在 2018 年暑期實習時，因緣際會用 Python 抓網站資料（用的是 Beautiful Soup）
  3. 課程學習（2021 - 23） 碩士時因為是資管相關領域的研究所，開始修習資訊系統課程（使用 Ruby 做 Web App）、商業分析課程（Python 為主，包含基礎的 Text Mining, Machine Learning; 以及用 R 做一些基礎的統計）
  4. 專案練習（2023 - 24） 2023 - 2024 年交換期間，假期或課餘時間在做自己的 Side Project, 以 Python (Flask) Backend, Vue.js 當 Frontend. 不過都是很小的專案，功能也沒有開發完全。

因此，雖然十多年前已有接觸程式，但正式以「軟體工程師」相關職缺為目標開始準備，應從 2023 下半年交換後開始，並直到 2024 年 10 月中退伍（結訓）後，才正式開始全力準備。

3. 縱覽準備計畫

3.1 準備類型分類

正式準備期間從 2024 年 10 月底開始，到 2025 年 5 月底，約七個月。

我根據前述的刷題／作品／基礎派，展開準備類型的分類圖，如圖一。

準備類型分類圖

圖一：準備類型分類圖

根據圖一，刷題（Problem）和基礎（Background）都是自己一個類別，而作品（Project）則拆成三個類別，分別是技術知識（Tech Stack）、專案（Project），以及呈現（Deliver, 包含作品集、職缺申請等等）而根據這段時間的準備經歷，我覺得在學習的過程中，比較容易：

  1. 基礎知識開始
  2. 逐步學習和練習刷題和技術知識。
  3. 專案仰賴於技術知識的學習，並將最終成果呈現給面試官。

而面試流程則比較像倒過來：

  1. 篩選階段：
    1. 透過篩選履歷快速瀏覽作品集內容 → 對應到呈現
    2. 透過 code test 來檢驗面試者的程式能力 → 對應到刷題
  2. 面試階段：
    1. 針對過往經歷提問來評估專案經驗
    2. 透過技術問題和白板題評估技術知識

至於背景知識，在面試過程中比較少被問到，因此不確定應劃分在哪個類別，我猜測應該是部分會在面試流程中考察到，其他面向的背景知識，則是在後續試用期以及以後的合作過程中，逐步顯現和評估吧！

3.2 準備期間的階段劃分

根據 3.1 的準備類型分類，展開準備期間的劃分與重點項目，如下方圖二所示。

準備期間的劃分與重點項目

圖二：準備期間的劃分與重點項目

主要可以分成三個階段：

  1. 探索期｜202410 - 12: 找尋比較適合自己的準備方式，以加強基礎知識（入門的演算法和資料結構）和嘗試新專案（Python Backend by Flask）
  2. 準備期｜202412 - 202503: 建立在探索期的經驗，重新整理準備方向。主要專注於刷題（Leetcode）、技術知識（Python / MySQL）和加強專案（Home Lab / Python Backend by Flask）
  3. 申請期｜202503 - 05: 開始投履歷，採打帶跑策略。前期加強專案（Python Backend by Flask），後期則根據面試可能需求調整學習方向（Python Backend by FastAPI / AWS / Terraform / k8s / OOD）

各個階段的準備內容，如下展開。

4. 探索期｜202410 - 12

4.1 補足基礎網路概念、演算法和資料結構

Topic: The Bits and Bytes of Computer Networking & MIT 6.006 Introduction to Algorithms

從剛退伍（結訓）到 11 月中，因為想說過往都沒有正式修過資料結構或演算法，因此，希望能找個時間補強。大概找了一下相關資訊後，最後選擇看在 Youtube 上的免費公開課程 MIT 6.006 Introduction to Algorithms, Spring 2020

我覺得這門課對於非本科（沒有修過資料結構或演算法）的人來說，蠻有幫助的。課程主要著墨於「如何證明某個算法可以解決某個問題」，以及分析時間複雜性。雖然對於實際怎麼解題（ex. 刷 Leetcode）幫助較小，但對於非本科生來說，我覺得可以建立比較系統性的思維，從「演算法是什麼」，到「如何證明某個方法可以解決某個問題」，以及慢慢建立不同類型演算法的基礎概念。

另外，因為對網路的概念還比較薄弱，就用重看了一次 Google IT Support Professional Certificate 的免費線上課程 The Bits and Bytes of Computer Networking，補強一些網路相關的基礎知識。

4.2 嘗試 Python Backend 專案

Topic: Python Backend (Flask)

原先其實沒有要做專案的。11 月中看完課程後，原本想說一邊找更進階的演算法／資料結構的課程來看，一邊補強其他基礎知識。結果因緣際會下和朋友聊到了「個人財務規劃」的專案構想，不小心就一路從 Prototype（用 Google Sheet 做簡易的個人財務規劃）、Monolith（用 Flask 做 Web App）到 Frontend / Backend.（Vue.js as Frontend + Flask as Backend）

這也是第一次明顯的準備方向轉向。當時看完課程後，覺得知道了一些基礎知識，但同時也覺得「要補足的基礎知識好多，可是補完要不知道對工作的直接幫助為何？」因此，實際開始做專案，也讓自己心底覺得比較踏實，有感覺實際在做些什麼。

該專案的詳細說明，可以參考 這裡 ✨

5. 準備期｜202412 - 202503

5.1 刷 Leetcode

Topic: Leetcode

12 月初時，專案的雛形告一段落，心中突然有股空虛與擔憂：「雖然可以寫簡單的專案，可是如果連 code test 都過不了，好像就完蛋了。」加上也覺得沒有實際練習到之前線上課程學的內容，就覺得應該要來刷個題了。

剛開始刷題的時候，很有高中在比 IOI 校內賽的感覺。大體上就是「很像在解益智題目，然後發現自己是笨蛋」。雖然卡關時都用 ChatGPT 跑解答，再跟其他網路上找到的解答比較，然後逐步學習模式，但總覺得見樹不見林，摸不著邊際的學習。

後來找到幾個資源，才開始覺得學習的比較有系統：

5.1.1 題目選擇

Grind 75

因為 Leetcode 題目實在太多，發現 Grind 75 最棒的地方是，可以調整計劃期間（總共幾週）、花費精力（每週幾小時）來篩選題目，並訂出合理數量。同時，也可以根據週計劃（每週要做哪些）、題目類型(Array, Stack, String, …) 分類。

對新手來說，準備起來會比較有方向，可以感覺到「啊大概主要方向有準備到」，每天看進度條逐步增加也很有回饋感。

5.1.2 系統學習

  1. AlgoMaster
  2. labuladong 的算法笔记

這兩個部落格對我的幫助都蠻大的，性質類似（不過 AlgoMaster 還有包含系統設計，而 labuladong 的算法笔记 則是有付費內容跟動畫輔助學習），都是很詳盡的拆解分析各種解題思維模型。

說老實話因為個人偷懶，所以大部分的內容其實都沒看完。不過，我覺得光把兩個部落格的總綱看完，對於解題整體思維就會有很大的幫助！

  • How I Mastered Data Structures and Algorithms 這篇比較短，主要是 AlgoMaster 部落格在解釋如何學習演算法和資結。其中對於常見模式和主題的說明，以及練習流程，我覺得都有很大幫助！
  • 学习数据结构和算法的框架思维 這篇比較長，不過我覺得內容很精彩，交代了刷題（演算法／資料結構）的學習邏輯，對我幫助很大。從文章中節錄一段我覺得對解題思維很有幫助的概念：

种种数据结构，皆为数组（顺序存储）和链表（链式存储）的变换。

数据结构的关键点在于遍历和访问，即增删查改等基本操作。

种种算法，皆为穷举。

穷举的关键点在于无遗漏和无冗余。熟练掌握算法框架，可以做到无遗漏；充分利用信息，可以做到无冗余。

Source: https://labuladong.online/algo/essential-technique/algorithm-summary/#总结一切数据结构和算法

這段時間的 Leetcode 學習，因此大致按照

  1. 從 Grind 75 中按照規劃挑題刷
  2. 若 20 - 30 分鐘仍解不出來，用 ChatGPT 提供建議
  3. 有空時閱讀系統學習的文章

進行。

此外，我發現以我的個性來說，刷題和看文章要交替進行。刷題久了會覺得空虛失去方向感（感覺沒有掌握到綱要），而看文章久了會覺得很空泛（好像知道了很多但又寫不出來）交替的做才能保持比較舒適的準備節奏。

5.2 刷題 + 補強技術知識

Topic: Leetcode + Techstacks

刷了三週後，開始覺得，除了題目之外，也要對使用的工具有比較多的了解。因此，想說開始多讀一些 Python 和 SQL 的書（以 MySQL 為主）

5.2.1 Python

最早想要找一些 Python 對應的白板題，或是技術面試題，但一直找不太到適合的，後來發現看一些 Python 的書蠻有幫助的（相較來說，有想過直接看 Python 的 documentation, 但因為經驗不足，所以看起來會抓不到重點，也分不出優先順序）

  1. Powerful Python: Patterns and Strategies with Modern Python 這本是我唯一有看完的。主要針對有 Python 經驗，但想要學習更多的人。許多以前有看過但不熟的概念（Generator, Comprehension, Decorator, Unpacking, Logging）在文章中都有提及，也會給實際應用場景，對我的幫助很大。
  2. Fluent Python: Clear, Concise, and Effective Programming 這一本對我來說非常扎實，我大概看不到兩成。不過裡面有很多我認為蠻重要的 Python 知識，像是 is 和 == 的差異，或是 immutability 等等的重要細節。我覺得適合願意花時間深入了解 Python 的人。不過因為很細節，讀起來對我來說比較吃力。

另外，我發現對我來說蠻有幫助的學習方式，是開個 Notebook (Google Colab, Jupyter Notebook or 其他 notebooks），把剛學來的 Python 小知識試寫看看。雖說直接應用在專案中會比較有記憶點，不過我覺得有些知識需要有對應的契機才能使用到（像是之前在定義專案的 Domain Model, 就會有機會練習到很多 dataclass . type hint 的知識）直接用 Notebook 想寫就寫，對我的幫助很大！

5.2.2 Database

我的 Database 和 SQL 應該算是慘不忍睹（？），後來面試就有似乎因為 SQL 太爛而被刷掉的經驗。

雖說如此，我還是覺得有本書在準備過程幫助不少。

Database Internals: A Deep Dive into How Distributed Data Systems Work 這本對我來說有點太難了，而且只看了一半。不過我覺得有幫助的地方是，對於 Database 的一些重點 Components, 像是 Index, 如何存資料（B-Tree / B+ tree / AVL tree）等等，會有一些概念

5.2.3 小插曲

剛好一月初有一場就職博覽會，所以這段時間也抽空更新 LinkedIn 和作品集，然後把常見的平台（104, Cake, 1111, Yourator 等等）的履歷更新一下。去完就職博覽會後危機感大爆發，發現感興趣的公司沒有想像中多，自己也還有很多要準備，所以才興起了自架伺服器的念頭。

5.3 自架伺服器

Topic: Home Lab Project

2025 年 1 月初時，想說後續會花時間嘗試更多的專案，但是網路上我能找到的免費 Hosting 服務就這麼少，而且也不一定會一直免費（追念 Heroku），因此，若能有個地方可以想部署就部署，而且幾乎不用錢，該有多好？因此，我就把自己的舊筆電（Acer Swift, 2018 年出廠）重灌 Debian OS, 然後試著改成可以使用的 Server.

因為是第一次架，也想不太到要問誰，所以都是自己胡搞瞎搞。基本上比較有幫助的嘗試有以下幾點：

  1. 沒有 Static IP
    1. 用 VPN SSH 連到自己的電腦（我是用 Tailscale）
    2. 用 Cloudflare Tunnel 讓外部可以連到我電腦上的服務
  2. 用 Traefik 當 Reverse Proxy, 用 Docker 部署想要測試的服務
  3. 用 Checkmk 監控電腦狀況

針對該專案的資訊，可以參閱 Home lab 專案 👻

另外，在嘗試搭建 Home Lab 過程中，比較有幫助的來源有

  1. ChatGPT 當我不知道我不知道什麼時，ChatGPT 可以提供很好的切入點
  2. Reddit Self Host 許多自己好奇的問題，可以在 Reddit 上面找到相關討論。相較於找到最好方案，Reddit 可以幫助我釐清「選擇哪個方案時，可能會需要付出哪些代價，可以期待哪些好處」。同時，也可以看到很多截然不同的立場，進而發展出自己的見解和立場。
  3. UNIX and Linux System Administration Handbook 這本書對我幫助很大，主要是逐步建立 「Linux 是什麼？可以做什麼？」的思維。雖然大部分的功能在 Self Hosted 時不會立即用上，但我覺得能建立比較完整的理解，學起來會比較放心。

5.4 繼續寫專案

Topic: Python Backend (Flask)

把 Home Lab 告一段落後，重新開始寫專案。這段期間花比較多時間練習的是 Test-Driven Development (TDD), Domain-driven design (DDD) 和 Layer architecture. 基本上就是一層一層的疊（ORM → Repo → Domain → Service），然後用 Pytest 先寫 Test 再讓 Test Case 過關。

6. 申請期｜202503 - 05

6.1 正式丟工作

Topic: Job Application

因為正式開始丟工作了，就先把作品集整理到堪用程度（我的作品集），同時認認真真地更新了 104 履歷。

再來，則是建立公司和職缺的清單。我先展開工作和職缺的流程圖（如圖三），根據流程圖的狀態分類職缺投遞狀況。再透過 Notion 分別建立公司列表和職缺列表（如圖四），並根據相關屬性評分（如圖五），協助篩選出合適的職缺。

公司與職缺狀態

圖三：公司與職缺狀態

公司列表範例

圖四：公司列表範例

權重評分公式

圖五：權重評分公式

6.2 邊丟工作邊寫專案

Topic: Job Application / Python Backend (Flask)

如題，就是邊丟工作邊寫專案。

6.3 根據職缺需求寫專案

Topic: Python / FastAPI Project

當時因為要面試某職缺，該職缺使用的是 FastAPI 的框架。因此，想說試看看在一周內能否趕出 Demo Project. 該專案根據前述的找工作流程，改寫成一個簡易版的 Web App, 前端一樣用 Vue.js, 後端則嘗試用 FastAPI. （該作品資訊請點我）

後來雖然有趕出來，不過面試過程也沒有特別問到 FastAPI 的內容，反而問了比較多 Python 和 SQL 的問題，算是準備錯方向 🥲

6.4 根據職缺需求準備

Topic: Preparation for interviews

這段時間每週有一場面試，因此每週都會根據前週面試的觀察，調整接下來的準備方向。因為時間因素，大部分能準備到的內容都比較淺，不過實際面試上也都或多或少有幫忙到。

  • 面試Ａ前：該職缺是雲端工程師，所以花比較多時間在準備 AWS / Terraform
  • 面試Ａ後：因為面試過程有靠到物件導向設計（OOD）的白板題，同時，也提到該職缺用比較多微服務，因此，準備較多的 OOD 和微服務
  • 面試Ｂ後：說後續可能會有 Data Engineer 相關的面試，同時，因為之前面試時的 SQL 慘痛經驗，所以開始補 SQL
  • 拿到 Offer C - Data Engineer: 因為該 Offer 用比較多 Azure, 開始學習 Azure Ecosystem

沒有特別什麼需要紀錄的，或許比較有幫助的是，用 Leetcode 的 SQL 50 來學 SQL, 算是蠻有回饋感的！

7. 回顧｜做與也許不做

說實話整個準備過程就像矇眼在迷宮裡轉，每過一陣子都會換個重點，網路上查到的資訊，或是跟身邊朋友的聊天，也都會影響到準備方向。到底哪些有幫助，哪些比較還好，哪些準備夠了，哪些又很不足，我覺得從頭到尾都沒有太多頭緒。甚至此刻，我仍然不確定有哪些方向比較合適，或是哪些主題我比較熟悉。

在過程中也很糾結，想說是不是要去報名 Bootcamp 會比較穩當，又或是不要堅持一定要走軟體，也可以考慮找一些其他的職缺。明明覺得職缺很符合，投了很多間卻發現都石沉大海，不禁懷疑自己是不是根本就樂觀過頭，應該要打掉重練才是。我相信這些糾結與挑戰，用找工作或申請計劃經驗的朋友們一定都能切身體會。

然而，回顧七個多月的準備過程，我仍然感覺，某些準備方向，在某些狀況下是比較適合的。因此，我把那些「若能回到剛退伍（結訓）時，會想跟自己分享的心得」紀錄在下方。

7.1 面試經驗回推：作品 ≅ 刷題 > 基礎（正在找工作時）

回顧我的面試經驗，我發現比較有立即幫助的有：

  1. 有趣的專案經驗 雖然面試經驗很少，但我發現 Home Lab 的部分，感覺面試官們都蠻喜歡，也都特別喜歡針對 Home Lab, 詢問「為何這樣做？」、「解決了什麼問題？」。此外，自己也覺得在過程中成長很多，從「部署靠 PaaS 就好」，到開始思考 Linux/GNU 有哪些功能，以及如何部署，讓我對 Web App 的運作邏輯更了解一些。
  2. 基礎的技術經驗 這部分比較可以預期，感覺大家會問的都差不多。如果是後端軟體工程師，大概會問的就是身份驗證流程（註冊／登入）、資料庫 Schema 怎麼切、API 怎麼訂（只有被問到 RESTful API）等等。其他還有一些 Stack 就是有說有用到就會被問，我有被問到的像是 Pytest, AWS, Terraform, Ansible, Ruff 等等。（面試自介簡報時我有列出我曾用過的 Tech Stack, 如圖六所示）
面試時分享的 Tech Stack

圖六：面試時分享的 Tech Stack

  1. Code Test 面試過程中也都有遇到 Code Test, 包含演算法類型（當時題目有考 DFS）、除錯（給一段 Code 要找錯）或 SQL（寫 SQL Query）這部分我覺得 Leetcode 有寫就會有幫助，大概以 Easy ~ Medium 之間的難度為主
  2. 語言熟練度 在面試 Python 相關的職缺時，有被問到一些比較基礎的 Python 問題。這部分透過閱讀相關 Python 書籍，大致上就能回應到。

我沒準備到的有：

  1. 系統設計白板題 給定題目要求，然後設計 AWS , Database Schema, OOD 等等。這部分自己沒有透過模擬面試演練過，所以實際面試時就有點慘。
  2. 行為面試 有問到團隊合作經驗、遇到挑戰怎麼處理、主管交付任務的處理流程等等。這部分就沒有特別準備。

有練習到但比較沒有立即幫助的有：

  1. 基礎知識 像是網路的基礎知識（osi model）、演算法基礎知識（計算時間複雜度）、作業系統基礎知識（虛擬化、parallel vs. concurrency, kernal, booting）都比較沒有問到。
  2. 系統架構或設計模式 當時花不少時間在實作 Layer Architecture / DDD / TDD 等等，不過面試過程中沒有遇到相關問題。其他如 Dependency Injection, Repository Pattern 等等，也都沒問到。這部分的知識感覺比較能「讓自己在開發專案過程中比較踏實」，在面試過程中的幫助則比較小一些。

7.2 準備派別的多元派對

雖說我的面試經驗主要受到我面試的職缺、面試官的偏好、此時此刻就職市場的狀況等等，不過若根據既有經驗回推，建議我自己怎麼準備，我大概會試著調整準備派別的比例和方式如下：

7.2.1 主要任務（60%）：Tech Stack → Project → Deliver 特快車

作為 Entry level / Junior level 的求職者，我覺得專案算是投資報酬率比較高的準備選項，同時，需要的時間和專注力也比較高。因此，以我自己的案例來說，我認為專案準備會是主力項目。此外，準備過程中勢必偶爾感到枯燥乏味，不過學習新技術或是開啟新專案，總是使人愉快。

因此，我認為作為求職的專案，若能符合「精準快速」的特性，或許幫助會比較大！

7.2.1.1 精準

每個專案都有很明確要練習的項目。像是熟悉一個新框架（ex. FastAPI）或是嘗試新技術（Ex. Traefik）若想要一次整合很多項目，一方面容易遇到意料之外的問題，二方面則是會拖慢開發進度，反而容易造成專案半途而廢，無法作為作品使用。（當然，若能解決意料之外的問題，絕對會是加分項。不過，以我個人為例，作為 entry level 的求職者，遇到複雜或是意外問題，受挫或是卡住的頻率會高上許多。

反之，若專注於特定 Tech Stack 練習，則比較能在穩定的環境中測試該技術的重點功能。

7.2.1.2 快速

求職過程容易 burnout, 也容易疲倦。此外，以我的經驗來說，entry level 或是 junior level 的面試提問，比起「解決複雜實務問題」，會更專注於「有意識的初階嘗試」。當然，若能有「解決複雜實務問題」的能力會是最好。不過，以我的例子來說，缺乏實務經驗，也沒有解決複雜問題的能力。故比起花費大量時間試圖創造「複雜問題」，若能更快速的展開「有意識的初階嘗試」，或許更有幫助。

「有意識的初階嘗試」，指的是：

  1. 有意識 知道有哪些技術、自己為什麼會要用這個技術，以及隨之而來的 tradeoff. 像某次面試時，就被問到「為何選擇 FastAPI 而非 Flask」
  2. 初階 受限於時間和能力，先避開進階功能，而是專注於「這個 Tect Stack 主要能解決哪些問題」來練習。節省時間的同時，也可以避免太受挫，同時也可以大致掌握全貌。等到遇到基礎功能無法解決的問題，再開始探索進階功能。
  3. 嘗試 實際上手經驗。也因此根據需求試著打造小專案，讓小專案可以運作，會是很有幫助的嘗試方案。

之所以會有上述心得，主要是因為在準備求職過程中，我花了很多時間在測試領域驅動設計 (DDD) ，想說透過牽涉較多的 Domain Entity, 並運用 Layer Architecture, 可以讓我模擬實際開發會遇到的複雜性。然而，該方案會導致的挑戰有

  1. 不必要的複雜性 Layer Architecture 的好處，包含可以讓不同層由不同人負責開發，只要確保介面穩定即可，以及讓 domain 保持純粹，避免對於框架有太多依賴（ex. 仰賴 Flask, FastAPI, 或是 SQLAlchemy 等框架）然而，個人作品集的時間短，開發人力少（主要為獨自開發）因此，上述的好處很受限，但卻需要付出大量時間來打造 Layer Architecture 所需的分層。
  2. 開發時間長 為了處理上述的複雜性，而付出較多的開發時間，導致很多簡單的 features 也需要耗費很多開發時間，導致實際能嘗試的功能和技術受限，而花更多時間在堆砌各層需要的 code.

即便如此，我仍然覺得試著處理複雜性，或是嘗試 Layer Architecture, DDD, TDD 等等，還是可以學習到很多寶貴經驗，只是若在求職階段，則受限於開發時間精力，以及想測試的技術項目，若耗費太多時間在處理複雜度，則比較容易 burnout 或是感受不到回饋感。

最後，之所以寫「Tech Stack → Project → Deliver 特快車」，是因為我覺得專案是整體學習的其中一環，而整個專案學習的迭代流程，更像是

  1. 找到想要學習或是練習的 Tech Stack / 技術
  2. 精準快速實踐小專案
  3. 把專案內容轉化為作品集的一部分

透過精準且快速的實踐流程，讓「設定學習目標 → 實作 → 展示」可以被反覆操作，並提供回饋感，進而讓準備過程可以感覺比較踏實愉快。

7.2.2 日常習慣（20%）：Leetcode & 文章

相較於專案需要比較長時間專注，Leetcode 更適合生活習慣。我覺得專案比較是「有做有分」而且回饋感高的項目，相較來說， Leetcode 則像是「有做不一定有，沒做一定沒有」的硬實力挑戰，比較難短時間衝起來，更需要長時間培養。

以我自己的經驗來說，大概刷 Leetcode 1.5 個小時左右，就會開始懈怠，而相關技術文章，也大概是學一兩個概念 + 例題，就會覺得「今天這樣就夠了」。反之，也因為目標和度量方式明確（有解題就有學習），我覺得很適合變成一天的習慣，或甚至開電腦第一件事就是寫個一兩題，這樣就會有種「即便今天很廢，還是刷題了呢」的莫名安心感。此外，因為範圍廣題目多，我會覺得刷題很難短時間衝起來，更需要「從第一天開始做，每天做一點點」的愚公移山式練習。

因此，我覺得 Leetcode 很適合當成日常習慣，每天做天天做，當覺得意志消沉時就看自己已經寫過幾題，就會很有激勵效果（應該啦！

7.2.3 休閒嗜好（10%）：基礎知識

基礎知識應該是範圍最廣，且對於非本科來說，最難準備的。畢竟隨便一個項目，就是一學期以上的課程，要在短時間內讀起來，不僅很困難，而且回饋感很低。然而，相較於專案或是刷題，我覺得基礎知識相較來說是比較有趣的。或許是因為距離實務比較遠，看起來更像是有種「知道了新的冷知識！」的趣味感。

以我自己的經驗為例，基礎知識無論在履歷或是面試上，能幫助的都很少，但卻能在精神上給予支持，有一種「我不只會堆積木，還更了解積木的前世今生」的踏實感。此外，若莫名其妙多了空閒時間，或是在寫專案比較不方便的地方（像是等人等很久，搭火車、醫院等看病等等），讀一些基礎知識都是打發時間又讓自己覺得有努力的好方法。

當初為了補足基礎知識，找了資工系的課綱，也看了許多準備資工研究所的文。不過課綱推薦的教科書看起來很厚很硬（其實就是我很懶），而研究所準備文相較來說比較考試取向（很多都是補習班的課程或是書籍，感覺買起來貴貴的）後來在 Reddit 上逛了逛後，發現了對我最有幫助的文章 Teach Yourself Computer Science.

該文章中提出了非本科生建議可以學習的電腦科學基礎知識，我自己也是根據書中類別，整理出自己近期應該要專注的基礎知識和可能相關的 Tech Stack, 如圖七所示。

需要補足的基礎知識

圖七：需要補足的基礎知識

文章中不少書都借得到或是查得到，而其中的彗星書（Operating Systems: Three Easy Pieces）更是直接在官網上公開所有 PDF（甚至建議你要看時再下載，因為會不定期更新），對我來說內容扎實又比較容易讀。（不會太生硬）

另外，若是要針對某職缺了解有哪些相關知識，roadmap.sh 這個網站也是很好的來源！該網站整理了不少熱門資訊類職缺的知識地圖。

7.2.4 隨便逛逛（10%）：各種資訊

在準備求職過程中，剛開始我很容易會有「因為時間不夠了，所以得要專注在既有計劃，才能最快速有效成長。」然而，這種心態會讓我很焦慮，也會不停質疑自己「現在的計劃夠好嗎？」因此，相較最佳化準備過程的方方面面，我發現更適合我自己的方式是

預留一段隨意時間；保有計劃的彈性；相信會有更好的計劃，卻也能考慮到遷移成本。

準備過程中，偶爾會有「突然很想要查某東西」的念頭，舉凡「轉職經驗分享」、「OO 技術是不是比ＸＸ好」、「ＯＯ職缺和ＸＸ職缺的比較」。這些資訊通常對履歷或面試本身都沒有太大幫助，但我認為這些隨意查詢的資訊，不僅因為回應到自己的疑惑，而有很大的支持作用，同時也能提供一些意外的資訊和支持。不少我覺得有幫助的書籍或文章，都是起源於「查查看ＯＯＯ好了」的驚奇發現。

8. 結論｜老調重彈

一如開頭所說，因為我並沒有認真做過文獻回顧，能拿來分析的案例也只有我自己的經驗，因此，分析而得的經驗很受限。即便如此，我仍相信在過程中的觀察，與事後的反思，能讓我找到一些對自己有幫助的心得。

彈性準備：依照自己的節奏，找出合適的學習步調！

如「7.2 準備派別的多元派對」中所提及，以我自己的面試經驗和學習過程來說，不同派別的重點都有其價值，比起選擇怎麼做，或許更重要的是根據自己的節奏，找到適合的配比。以我自己的經驗來說，合適的配比是 作品 60%, 刷題 20%, 基礎知識 10%, 預留 10% 作為彈性調整使用。

另外，因為是自己準備，我需要足夠的內在動機才能繼續學習。因此，準備過程中，很仰賴「我想要學什麼」的感覺。因此，即便有大致的配比權重，實際上也會依照個人狀態而調整學習進度，像是想到合適的專案點子時特別有熱忱，就會一整天都在寫專案；比較沒有幹勁時，則會寫多一點題目，畢竟多寫題目不需要做太多決策，只要寫完一題再寫一題就好。

最後，因為自己是 Entry level 的求職者，加上求職時間有限、求好心切，因此，選擇專案上會有「精準快速」為原則，專注於「有意識的初階嘗試」。

多元吸收：搭配不同的方法，讓生活浸泡在學習氛圍！

還記得某次面試時，面試官問到「你是怎麼學習這些技術與框架的？」以我自己的經驗，我覺得對我來說比較有效的學習方式是「想怎麼學就怎麼學」。以「7.2 準備派別的多元派對」為例，作品、刷題和基礎知識對應到日常生活的不同面向，也會有不同學習法：

  1. 專案｜主要任務：
    1. 用 ChatGPT 掌握大致內容
    2. 查詢 Reddit 了解 Tech Stack 選擇
    3. 閱讀技術 OR Tech Stack 的 documentation
    4. 閱讀相關書籍
  2. 刷題｜日常習慣
    1. 用 ChatGPT 提供答案
    2. 閱讀部落格文章建立解題模式
  3. 基礎知識｜休閒嗜好
    1. 閱讀相關書籍
    2. 看開放式課程

另外，我也發現一天當中有些時段對我來說，比較適合做某些事情：

  1. 剛起床 → 適合刷題，立刻有回饋感，覺得當天有進度
  2. 精神正好的完整時間（早上／下午）→ 寫專案，一次可以專注 2 - 4 小時
  3. 等待、睡前、休閒時 → 閱讀相關書籍（電子書）
  4. 不知道要做什麼但不太想太累 → 看線上課程／隨便查詢相關資訊（好像有在做事但又不會太消耗）

因此，根據不同的派別，有不同的學習法，在不同的時間做，並依照個人的狀態與節奏調整，讓我覺得準備過程中比較不會太快 burnout, 也可以持續看到回饋！

整篇文章的總結圖，請參考圖八。

紀錄總結圖

圖八：紀錄總結圖