【演講】從研究室到辦公室：連學校老師也無法教你的必修課

前言

我們花了幾年時間學習如何寫程式跑實驗、如何把論文寫到能夠發表。可是，當研究生涯結束、準備踏出校園的那一刻，心裡總會浮現一個疑問：這些技能，真的能在職場上派得上用場嗎？

從研究室到辦公室，看似只是一道門檻，但要能跨過這道門檻所需要的技能，你已經具備了嗎？該具備哪些呢？如何具備呢？

好不容易跨過去後才發現，那其實是一個完全不同的世界，每個人講著我們聽不懂的專有名詞，一個全新的環境和文化，從早上九點到晚上六點，從禮拜一到禮拜五，時時刻刻充斥著全新的挑戰，一波未停，一波又起。

在學校不懂、做錯了，老師會體諒你、教導你。而在這裡，你有責任必須要把事情做對、必須要時時刻刻產生貢獻與價值，因為你的每一分每一秒都是老闆買來的。

沒有人有義務教你，如果有，那是你的福份，你必須心懷感激，並且下次想辦法不靠別人就把事情做對。想辦法在職場上求生存。

還有許多在職場上生存、成長所需的能力，從來沒有人在課堂上告訴過你。

而這些，才是真正決定你能不能順利從研究室，跨進辦公室，並且在裡面站穩腳步的關鍵。

今天這場演講，我想帶你們提前看見那些「隱藏課程」──
那些老師不會教、課本找不到，但每個人都遲早要面對的必修課。

希望學弟妹們在還沒踏出校園之前，就能比我當年更有準備，也少走一些不必要的彎路。

關於我

我是 2016 年從政大畢業，MCLab1 蔡子傑教授的學生。

我一直有一種感覺是我好像才剛畢業而已，但仔細一算，也快要十年了(今年 2025)。

那我目前正職是在一家外商公司擔任 Senior Software Engineer，一個月只需要進公司一次，是個全遠端的工作者。

我的專長是 Web 的開發，特別是在前端的部分。

我待過的公司種類也蠻多的，也開發過許多不同的產品，B2B、B2C 軟體開發經驗，上市公司、新創公司、台商、外商...

這幾年來陸續有參加一些社群，所以有時候也會在一些小社群或是技術會議上面擔任講者。

另外，我也有出版過幾本專業書籍。

所以如果各位學弟妹對下面主題有興趣：

軟體工程師
職涯發展、履歷健檢、面試技巧
遠端工作、數位遊牧
軟體接案

對這些主題感興趣的，歡迎找我私下交流。

我的資歷比較不是那種神人等級的，我是比較那種接地氣的人，所以相對來說比較符合大部分的人的狀況。所以我相信我的經驗應該對大部分的人有幫助。

我出社會之後大多是自己一個人去探索和衝撞，過程中當然會有一些跌跌撞撞。所以我是站在一個，如果我跟各位一樣是一個研究生，未來十年後的我，希望我能夠提早準備的事，可以幫助我少一些碰撞，這樣的角度來跟各位學弟妹們分享。

畢業前的焦慮

畢業前其實會有一點擔心，我學的東西，在職場上真的堪用嗎？這可能是每個即將踏入職場的學生都會有的焦慮。

我會寫 python 跑一些實驗，但這些寫法是否能被業界所接受？在學術環境中，我們寫程式主要是為了驗證理論、跑實驗、分析數據，程式碼只要能跑出結果就好。但在業界，程式碼需要考慮可讀性、可維護性、效能、安全性等等，這些都是我在學校時沒有特別注意的。

Git 版本控制也是，在學校通常都是單打獨鬥，git 對我們來說就是 push 和 pull 而已。我甚至不知道什麼是 feature branch，什麼是 Pull Request，為什麼要 code review。當同事提到 merge conflict 時，我完全不知道那是什麼。reset、revert、cherry-pick 這些指令我聽過但從來沒用過，不知道什麼時候該用哪一個。rebase 和 merge 的差別？我連想都沒想過。你會發現，原本以為很簡單的 git，在團隊協作中變得如此複雜，而我對這些一無所知。

Step1: 有用 git 的舉手
Step2: 你的 git 專案有多人一起維護的繼續舉著
Step3: 你的 git 專案有多人一起維護，並且有除了 main/master branch 以外的人繼續舉著
Step4: 你的 git 專案有結合 CI/CD 自動化整合、測試、部署流程的，繼續舉著

該如何加強自己？要加強哪一些面向？面試該準備哪些部分？我目前的技能能夠找哪一些職缺？這些問題每天都在我腦中打轉。更讓我焦慮的是，我花這麼多時間做研究，這些東西在面試或職場上派得上用場嗎？會不會我學的都是用不到的東西？

這種焦慮其實很正常，因為我們即將從一個熟悉的環境，跳入一個完全未知的世界。但現在回頭看，這些焦慮其實都是成長的動力，讓我更積極地去學習和準備。

程式能力焦慮

做研究、作業還夠用，但是符合業界水準嗎？
出社會需要會什麼東西？
要會到什麼程度？
有沒有除了專業技能以外需要的東西？

技能廣度焦慮

我只會寫 python，這樣夠嗎？
我是否還需要學點別的東西？
公司丟一包專案給你，你看不看得懂？改不改得動？
例如：FastAPI, FlaskAPI, React.js, Next.js, ... 其他

求職準備焦慮

該如何加強自己？要加強哪一些面向？
面試該準備哪些部分？
我目前的技能能夠找哪一些職缺？
我花這麼多時間做研究，這些東西在面試或職場上派得上用場嗎？

及早開始你的職涯探索

我建議各位及早開始探索你的職涯，如果想說「等到要找工作的時候再來想好了，可能那時候比較知道自己要什麼。」我覺得到時候會有點太匆促，其實很多東西可以提早準備的，但你可能因此錯失機會。

或是，如果只是大概大概的想像，例如說「我畢業之後想要做跟資料處理相關的工作」「我畢業之後想要找一份寫 python 的工作」這樣是不夠的。這些想法太模糊了，你根本不知道這些工作實際上是什麼樣子，需要什麼技能，會遇到什麼挑戰。

找工作前難免會有點焦慮、難免有點難規劃自己的職涯、做決定。這種焦慮其實很正常，因為我們即將從一個熟悉的環境，跳入一個完全未知的世界。

我們無法做決定或規劃通常有幾種理由：

目前擁有的資訊太少：對職場、對不同工作內容、對技能要求都不了解
目前擁有的資訊太雜、沒有整理：聽了很多，但不知道哪些是對的，哪些是錯的
擁有的資訊不正確、太多刻板印象：以為程式設計師就是整天寫程式、以為資料科學家就是整天做分析、新創公司一定是怎樣、大公司一定是怎樣...。

這些問題都會讓你無法做出正確的職涯規劃，甚至可能讓你選擇了不適合自己的道路。

你應該現在就為未來做準備。方法有三個層次：

設定方向
就像選論文題目一樣，先試著為自己設定一個職涯方向。
你不需要馬上找到「最終答案」，但至少要先有個「假設」：
- 想嘗試的產業？
- 想往前端、後端，還是資料領域？
- 喜歡專精技術，還是偏向 PM、顧問型角色？
收集資訊
設定目標後，就能更有方向地蒐集資訊：
- 追蹤職缺網站（104、LinkedIn）看看這些職位要求什麼技能
- 訪談學長姐或在職朋友，理解他們的真實工作內容
- 參加社群活動、讀書會、技術小聚，觀察業界的趨勢與需求
- 看看別人的面試心得(medium, 面試趣...)
累積實戰經驗
最好的探索方式就是「下場比賽」：
- 主動投遞履歷、去面試，把面試當作檢測自己能力的機會
- 參加社群或社群領袖舉辦的模擬面試活動

面試不是終點，而是最好的學習過程。每一次面試，都能讓你更清楚自己的不足，也更接近理想的工作。

如何篩選適合的工作？

當你蒐集到足夠的資訊後，下一步就是思考「什麼才算是適合自己的工作」。以下幾個面向可以幫助你做判斷：

興趣與動機：選擇自己感興趣的職位或產業，因為熱情會讓你在困難時有繼續堅持的力量。
技術堆疊：觀察該職位使用的技術是否符合市場趨勢，能幫助你保持競爭力。
公司文化：一個讓你自在發揮的文化，比光鮮亮麗的招牌更重要。要問自己：這裡的氛圍是否適合長期成長？
職位內容：確保工作內容與職稱一致（名符其實的職位），避免掛羊頭賣狗肉。
薪資與福利：基本的經濟保障很重要，尤其第一份工作要能支撐生活，並為未來規劃打基礎。
未來發展性：不只看「現在能學到什麼」，也要思考「三年後這份經驗能帶你去哪裡」。

把這些條件攤開來思考，你會發現，有些工作可能薪水高但文化不適合；有些公司技術潮流跟得快，但職位內容模糊。適合自己的選項，往往是在多面向之間找到平衡。

面試是要準備的，但...要準備什麼？

剛開始踏出社會的時候，我不太知道面試要準備什麼。

我以為我只要把論文帶著，像是在準備口試那樣來準備面試就可以了。畢竟我這幾年都是在寫論文，我所知道的專業的東西就是在我論文裡，我以為面試官也會這樣想。

但出去面試被洗過臉之後，才知道事情不是這樣子。

曾經有面試官對我說「你沒有準備。」但其實我覺得很疑惑，明明我覺得我很用心在準備了，還被這樣講，真的很無力。但現在回過頭來看，我準備的方向錯了。

面試到底要準備什麼呢？這邊列幾個常見的面試題目：

自我介紹
程式基礎能力
軟體開發基礎
專業領域知識
作品集、專案展現
軟技能、態度、公司文化契合度
行為面試
資歷查核

自我介紹

各位都怎麼做自我介紹呢？很多人在進到新的環境裡面自我介紹，可能都隨便講一講而已，自己的名字、興趣、學校之類的，簡單十幾二十秒就帶過了。這種自我介紹可以應付你過去種種的學校、社團經驗。因為在這些場域當中，自我介紹可能沒那麼重要。

可是在面對面試的時候，自我介紹是非常重要的，你如果還是用以前那一套方式來自我介紹的話，很容易讓你錯失良機，甚至給面試官帶來負面的印象，覺得你很隨便。

在面試的場景當中，自我介紹是需要且值得精心準備的。自我介紹是面試中的必考題，也是你擁有完全主導權的唯一機會。透過有策略的內容安排，讓面試官在短時間內對你產生深刻而正面的印象。

自我介紹做得好的話，會讓面試官對你產生興趣，因此容易順著你的自我介紹脈絡繼續問下去，你就可以順勢再繼續挖深、展現自己的優勢。

反之，如果自我介紹做得很糟糕，面試官可能會覺得你沒有準備，或者對這個職位不夠重視。他們可能會問一些你沒有準備過的問題，或者直接跳到其他面試環節，你就失去了展現自己最佳一面的機會。更糟糕的是，如果自我介紹中提到了你不熟悉的話題，面試官可能會深入追問，反而暴露了你的弱點。

自我介紹的五大要素：

基本背景：簡潔說明身份背景、學校科系，以及為什麼對這個職位感興趣。重點在於建立連結，讓面試官了解你的背景與職位的相關性。
技能與學習：精選與應徵職位最相關的 3-5 項核心技能，說明掌握程度並提供具體的學習歷程。展現持續學習的態度，提及最近學習的新技術。
專案、實習經驗：選擇 1-2 個最具代表性的經驗，說明專案背景、你的角色與貢獻、採用的技術，以及量化成果。重點在於展示你在其中的具體價值。
軟實力：透過具體事例展示解決問題能力、團隊合作、溝通能力、工作態度等。避免空泛形容詞，用具體行為來證明。
個人特質：發掘並展示你的獨特價值，如對技術的持續熱情、特殊思維方式、跨領域知識背景等。真誠分享你的熱情所在。
未來規劃與期許：展現短期目標、長期規劃，以及對公司的價值。讓面試官感受到你尋求的是「共同成長的機會」而非「一份工作」。

程式基礎能力

程式基礎能力是面試中最基本的門檻，也是很多學生最容易忽視的部分。在學校裡，我們可能覺得自己會寫程式就夠了、會動就好了，但到了面試現場，你會發現事情沒那麼簡單。

面試官會從哪些面向來評估你的程式能力？

熟悉一門主要語言：不是要你什麼都會，而是要對一門語言有深入的理解（Python / Java / JS / Go…）
資料結構：Array, Hash Map, Stack/Queue, 基本樹結構，這些是解決問題的基礎工具
演算法：排序、搜尋、簡單遞迴、時間/空間複雜度概念，展現你的邏輯思維能力
基本 Debug 與除錯能力：當程式出錯時，你能快速定位問題並解決嗎？

通常面試官會考你一題簡單的 leetcode 來測試你的程式能力。但這不只是考你能不能寫出答案，更重要的是評估你的：

正確性：程式能正確執行嗎？邊界條件有考慮到嗎？
效能評估：你的解法效率如何？時間和空間複雜度是多少？
可讀性評估：程式碼寫得清楚易懂嗎？變數命名有意義嗎？
可擴展性評估：如果需求改變，你的程式容易修改嗎？
演算法優劣：你選擇的演算法是最適合的嗎？
Design Pattern：你的程式架構合理嗎？

舉例：請實現一個函數，計算第 n 個費波那契數

這是一個經典的面試題目，看似簡單，但能展現多個層面的能力：

基礎版本 (Easy)

def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

重點：邊界條件處理 (n ≤ 1)
方法：遞迴實現
問題：時間複雜度 O(2^n)，效率極差
缺點：大量重複計算，當 n 很大時會非常慢，甚至可能導致堆疊溢出

效能優化 (Medium)

def fibonacci(n):
    if n <= 1:
        return n
    # 使用陣列儲存所有計算結果
    dp = [0] * (n + 1)
    dp[1] = 1
    for i in range(2, n + 1):
        dp[i] = dp[i-1] + dp[i-2]
    return dp[n]

重點：避免重複計算，時間複雜度 O(n)
方法：動態規劃，用陣列儲存中間結果
技巧：自底向上填表，避免遞迴重複計算
缺點：需要 O(n) 的額外空間，當 n 很大時，費波那契數會超過整數範圍，導致溢出

空間優化 (Medium)

def fibonacci(n):
    if n <= 1:
        return n
    # 只保留前兩個值，滾動更新
    prev, curr = 0, 1
    for i in range(2, n + 1):
        prev, curr = curr, prev + curr
    return curr

重點：空間複雜度 O(1)，只使用常數空間
方法：滾動數組概念，優化空間使用
技巧：只保留前兩個值，不需要儲存整個序列
缺點：仍然存在大數溢出問題，當 n 很大時結果不正確

大數處理 (Hard)

def fibonacci(n):
    if n <= 1:
        return n
    prev, curr = 0, 1
    for i in range(2, n + 1):
        prev, curr = curr, (prev + curr) % (10**9 + 7)
    return curr

重點：處理大數溢出問題
方法：模運算避免整數溢出
技巧：動態規劃 + 模運算，適合處理超大數值
缺點：返回的是模運算後的結果，不是真正的費波那契數，但在實際應用中通常足夠

軟體開發基礎

下面是一些舉例，實際上建議可以針對該職位來準備，甚至網路上也會流出一些考古題，運氣好的話可以找到。

基礎架構概念
- 「當使用者在瀏覽器輸入 URL 並按下 Enter 後，發生了什麼事？」
資料庫設計
- 「關聯式資料庫 vs NoSQL 的優缺點和適用場景」
- 「什麼是正規化？為什麼需要正規化？」
- 「如何優化一個慢速的資料庫查詢？」
OOP
- 「請解釋 OOP 的四大特性及其優點」
Git
- 「請解釋 git merge 和 git rebase 的差異」
- 「如何解決合併衝突？」
測試相關
- 「單元測試、整合測試、端對端測試的區別」
- 「你如何為一個函數撰寫測試案例？」
軟體開發流程的基本理解
- 需求 → 設計 → 開發 → 測試 → 部署
- 面試官可能問的問題：
  - 「請描述一下軟體開發的完整流程」
  - 「在每個階段，開發者需要做什麼？」
  - 「如果需求在開發過程中改變了，你會怎麼處理？」
  - 「測試階段發現 bug，你認為應該回到哪個階段？」
  - 「部署後發現問題，你的處理流程是什麼？」

作品與學習證明

在面試中，面試官除了聽你說，更想看到你的實際能力。作品集和學習證明就是最好的證據，證明你不只是會說，更會做。

Side Project 或 GitHub Repo（小型應用 / 練習專案都可以）

很多人以為作品集一定要是大型專案，但其實不是這樣的。即使是小型應用或練習專案，只要能展現你的能力，就是好的作品集。面試官想了解的是：

你負責的部分：在這個專案中，你具體做了什麼？是前端、後端，還是全端？
遇到的挑戰：過程中遇到了什麼技術難題？這展現你的問題解決能力
你是怎麼解決的：用什麼方法、技術、思維來解決問題？這是最重要的部分
團隊的分工、合作：如果是團隊專案，你如何與他人協作？展現你的溝通和合作能力
Readme 文件：好的文件說明你重視程式碼的可維護性和團隊協作

面試官可能會問的驗證問題：

面試官為了確認這真的是你寫的，而不是抄襲或 AI 生成的，可能會深入詢問：

「這個功能是怎麼實現的？能詳細說明一下邏輯嗎？」
「為什麼選擇這個技術棧？有什麼考量？」
「如果用戶量增加 10 倍，你會怎麼優化？」
「這個 bug 是怎麼發現的？你怎麼 debug 的？」
「如果重新做這個專案，你會怎麼改進？」
「這段程式碼的效能如何？時間複雜度是多少？」
「你遇到過什麼技術難題？最後怎麼解決的？」

準備建議：

對專案中的每一行程式碼都要能解釋
準備具體的技術細節和實現邏輯
思考過專案的優缺點和改進方向
準備真實的開發過程和遇到的問題

展現持續學習

技術變化很快，面試官很看重你是否具備持續學習的能力。你可以透過以下方式展現：

線上課程：參加過哪些課程？學到了什麼？如何應用到實際專案中？
參加社群：是否參與技術社群、讀書會、技術小聚？這展現你對技術的熱情
Hackathon 經驗：參加過哪些比賽？獲得了什麼成果？這展現你的實戰能力和抗壓性

記住，作品集不是越多越好，而是要精。選擇最能展現你能力的 2-3 個專案，深入準備，比準備 10 個普通專案更有價值。

軟技能與行為面試

除了技術能力，面試官也很重視你的軟技能和行為表現。這些能力往往比技術能力更難培養，也更能決定你是否適合這個團隊。

面試官會評估的軟技能：

表達清楚：能解釋程式碼、邏輯，講給非工程背景的人聽
願意學習：誠實承認不知道，但能說「我會怎麼找答案」
團隊合作：展示與同學、隊友協作過的經驗
問題解決能力：遇到困難時的思考過程和解決方法
抗壓性：在壓力下如何保持冷靜和效率

常見的行為面試問題：

「請分享一個你學習新技術並應用的例子」
「你怎麼處理專案進度落後的情況？」
「曾經遇過 bug 卡住很久，你怎麼解決？」
「描述一次你與團隊成員意見不合的經驗，最後如何解決？」
「你如何處理多個專案同時進行的情況？」
「你有沒有其他問題想要問？」

回答技巧：

準備具體的實例，避免空泛的回答
展現你的學習能力和成長思維
最後一個問題要展現你對公司和職位的興趣

小結

到目前為止的段落，我希望大家能夠理解一個重要的觀念：面試是要準備的，而且不能只有準備論文和那些會扣分的自我介紹。面試要準備的東西真的不少，從自我介紹到程式基礎能力，從軟體開發基礎到作品集展示，每一項都需要時間去學習和練習。

所以我的建議是，提早準備，不要等到要畢業了才開始想這些事情。記住剛剛提到的那些關鍵字，回去之後去查、去研究、去找資源。網路上有很多免費的資源，也有很多學長姐的經驗分享。

最重要的是，不要怕！技術這條路本來就是不斷學習的過程，沒有人一開始就什麼都會。關鍵是要有行動力，要願意去嘗試、去犯錯、去學習。付出行動吧！只有開始做了，你才會發現其實沒有想像中那麼困難。

入行後的挑戰

好不容易過了面試這一關之後，其實挑戰也才剛剛開始而已。很多人以為拿到 offer 就代表成功了，但其實這只是職涯的起點。

成為正式的工程師之後，你會發現職場的文化和習慣與學生時期完全不同。在學校，你有老師指導、同學討論、固定的課程安排；但在職場，你需要學會獨立思考、主動學習、承擔責任。這是一個全新的世界，需要你具備以下能力：

技術棧衝擊：面對全新的技術棧和複雜的系統架構，需要快速學習和適應
熟悉團隊規範：了解公司的開發流程、程式碼規範、溝通方式
自學能力、自己解決問題：沒有人會手把手教你，必須學會自己找答案
對自己的程式碼負責：你寫的每一行程式碼都可能影響整個系統
不斷掌握新知、趨勢：技術變化很快，必須持續學習才能保持競爭力
獨當一面的開發者：從被動的學習者變成主動的問題解決者

這些轉變不會在一夜之間發生，需要時間和經驗的累積。接下來，我想跟大家分享一些入行後會遇到的具體挑戰，以及如何應對這些挑戰。

技術棧的挑戰

我只會寫 Python，這樣足夠嗎？是不是還需要學習其他技術？

在學生時期，很多同學都會有這樣的疑問。如果你也曾這麼想，那表示你對自己的技術發展相當有自覺——這其實是件好事。確實，你可能會遇到這樣的狀況：在學校對某個語言（例如 Python）已經相當熟練，但進入職場後，卻發現自己好像突然什麼都不會了。

從校園到業界的技術落差

進入職場後，你會發現即使同樣使用 Python，實際的開發環境與學校所學有著明顯差距：

不熟悉的框架與工具：公司交給你的專案可能是 FastAPI、Flask 或其他你從未接觸過的框架，甚至不清楚程式的運行邏輯
陌生的套件生態：專案中常使用許多學校沒教過的套件，例如 Alembic、SQLAlchemy、Pillow、Pydantic 等，需要時間理解其用途
複雜的系統架構：你負責的可能只是大系統中的一小部分，還需要理解它與其他服務之間的關聯
陌生的基礎設施：專案中往往整合了 Docker、Kafka、Redis、K8s、Jenkins 、Kibana、Grafana、Airflow、Jaeger 等基礎設施，這些都是在學校較少接觸的

看著眼前的 Python 專案，你可能會感到困惑：明明覺得自己對 Python 已經很熟了，為什麼實際的程式碼卻如此陌生？這種時候很容易產生自我懷疑——雖然承接了任務，卻不知從何著手，甚至無法判斷：是自己能力不足，還是前人寫的程式碼不夠清晰？

熟悉團隊規範

在學生時期，我們大多是單打獨鬥完成論文、作業，偶爾有小組作業，但程式上的合作其實比較少，多是討論上的合作而已。進入職場後，你會發現軟體開發是一個高度協作的過程，需要遵循各種團隊規範和流程。

程式碼規範

了解團隊使用的 Linter / Formatter：ESLint、Prettier、Black 等工具，確保程式碼風格一致
命名規則、檔案結構、程式風格：變數命名、函數命名、檔案組織方式都有既定規範
不要硬改既有專案的風格：先跟著現有規範走，熟悉後再提出改善建議

版本控制 (Git Workflow)

分支策略：Git Flow、trunk-based、feature branch 等不同策略的應用
Commit message 格式：例如 Conventional Commits，讓歷史記錄更清晰
Pull Request / Merge Request 的流程：誰審、怎麼審、什麼時候可以合併

專案管理流程

需求分析與規劃：如何理解需求、拆解任務、估算工時
開發週期管理：Sprint、迭代、里程碑設定
品質控制流程：Code Review、測試、部署流程

開發環境與工具

環境設定：開發環境、測試環境、生產環境的配置
工具熟悉：IDE 設定、除錯工具、監控工具的使用
CI/CD 流程：自動化測試、部署管道的理解

溝通與協作習慣

會議參與：Daily Standup、Retrospective、Planning Meeting 的參與方式
溝通管道：Slack、Teams、Email 等不同情境的溝通方式
跨部門協作：與 PM、Designer、QA 等不同角色的協作模式

知識文件與紀錄

技術文件撰寫：API 文件、架構文件、規格文件、設計文件、操作手冊的撰寫
知識分享：技術分享、Code Review 記錄、問題解決記錄
學習資源管理：如何有效記錄和分享學習心得

自學的能力、自己解決問題的能力

在學校，當你遇到問題時，可以隨時問老師、問同學，甚至問助教。但在職場，這種依賴性必須大幅降低。沒有人會手把手教你，你必須學會獨立思考和自主學習。

什麼問題都可以問嗎？

答案是否定的。 你只要肯上網查就查得到的資料，千萬不要問。這不是說同事不願意幫忙，而是時間寶貴，每個人都很忙。如果你連基本的 Google 搜尋都不願意做，會給人留下不好的印象。 (大家都是領錢來上班的，為什麼你的工作我要幫你做？你的薪水要分我嗎？)

什麼時候可以問？

當你已經嘗試過多種方法，但問題依然存在
當你對某個技術決策有疑慮，需要經驗豐富的同事提供建議
當你遇到系統性的問題，需要團隊協作解決

技術學習能力

看懂官方文件：學會閱讀和理解技術文件的結構，能夠快速找到需要的資訊，理解 API 的使用方法和參數說明。
看懂錯誤訊息：當程式出現錯誤時，能夠從錯誤訊息中快速定位問題，理解錯誤的含義和可能的解決方向。
看懂別人的程式碼：能夠理解同事寫的程式碼，分析其設計思路和實作邏輯，學習優秀的程式設計模式。

資料搜集能力

善用 Google, AI, Stack Overflow...：掌握各種搜尋技巧，能夠快速找到相關的技術資料和解決方案。
能夠判斷資訊的正確性：學會評估網路資訊的可靠性，區分過時和最新的資訊，避免被錯誤的資料誤導。

解決問題能力

找到 root cause 的能力：不只是解決表面問題，要能夠深入分析問題的根本原因，避免問題重複發生。
面對大問題能夠拆解成小問題的能力：將複雜的問題分解成可管理的小任務，逐步解決。
判斷優先級的能力：能夠評估不同問題的緊急程度和重要性，合理安排解決順序。

自我成長規劃

反思的能力：定期回顧自己的工作表現，分析成功和失敗的原因，從中學習和改進。
為自己設定目標並逐一達成：制定短期和長期的學習目標，制定具體的行動計劃，並持續追蹤進度。

記住，在職場中，你的價值不僅在於解決當前的問題，更在於持續學習和成長的能力。

對自己的程式碼負責任

在學校寫作業時，只要程式能跑、能通過測試，基本上就過關了。但在職場，你寫的每一行程式碼都可能影響整個系統的運作，甚至影響到用戶的體驗。因此，你必須對自己寫的程式碼負起完全的責任。

程式碼品質的基本要求

正確性：程式碼必須能正確執行，沒有邏輯錯誤，能處理各種邊界情況和異常狀況。
可維護性：程式碼要容易修改和擴展，當需求變更時，能夠快速調整而不影響其他功能。
可讀性：程式碼要清晰易懂，變數命名有意義，函數職責單一，註解適當，讓其他同事能夠快速理解。
穩定性、可靠性：程式碼要能夠穩定運行，不會因為環境變化或數據異常而崩潰。
效能與資源：考慮程式碼的執行效率，合理使用記憶體和 CPU 資源，避免不必要的資源浪費。
測試與驗證：為程式碼撰寫適當的測試，確保功能正確，並在修改後能夠快速驗證。
文件與交接：撰寫清楚的技術文件，讓其他同事能夠理解你的設計思路和實作細節。

外部資源的審慎使用

套件評估：使用第三方套件前，要仔細評估其穩定性、安全性、維護狀況和授權條款，不要盲目引入。
網路上程式碼亂貼：不要直接複製貼上網路上找到的程式碼，要理解其原理，確認其適用性，並根據專案需求進行調整。
AI 程式碼亂貼：AI 生成的程式碼雖然方便，但不要盡信，要仔細檢查其正確性和安全性，確保符合專案規範。
不要盡信 AI、Google：AI 和搜尋引擎是很好的工具，但不要完全依賴，要培養自己的判斷能力和技術理解。

對每一行程式碼的把握

對自己寫的每一行都有把握：你應該能夠解釋每一行程式碼的作用，知道為什麼這樣寫，以及可能的影響範圍。如果對某段程式碼不確定，寧可多花時間研究，也不要留下疑問。

記住，在職場中，你的程式碼不僅代表你的技術能力，更代表你的專業態度和責任感。每一行程式碼都是你的作品，要為其品質負責。

成為獨當一面、成熟的開發者

從學生到職場，最大的轉變之一就是從「被動接受任務」變成「主動承擔責任」。在學校，你只需要完成老師交代的作業；但在職場，你需要成為一個能夠獨當一面的開發者，這意味著你不僅要會寫程式，更要有全方位的職場能力。

自己與 PM 談需求：學會用清楚的語言，確認需求背後的目標，避免誤解或需求變動造成返工。不要只是被動接受任務，要主動了解為什麼需要這個功能，它要解決什麼問題。
與非技術人員溝通：把專業內容轉換成對方能理解的語言，促進跨部門合作。當你向設計師、產品經理或客戶解釋技術問題時，要用他們聽得懂的話來說。
評估技術可行性：能快速判斷某個需求是否能實現，以及需要多少成本與時間。這需要你對技術棧有深入的了解，能夠預估實作的複雜度和風險。
與團隊成員分工合作：清楚界定彼此的任務邊界，互相支援，避免重工或漏工。學會在團隊中找到自己的定位，同時支援其他成員。
獨立完成專案、帶領夥伴完成專案：有能力從頭到尾執行，也能帶領他人一起完成，展現領導潛質。這不只是技術能力，更是專案管理和團隊協作的能力。
規劃專案任務、進度、估時：能把大需求拆解成小任務，合理排程並預估時間，避免專案失控。這需要你對專案有全局的思考，能夠預見可能的風險和挑戰。
主動發現問題、提出改善方案：不只是執行工作，還能察覺風險或痛點，並提出可行的解法。這需要你對系統有深入的了解，能夠從多個角度思考問題。
具備系統與產品思維：不只寫功能，還要理解整個系統如何運作，並從使用者與產品角度思考。你要知道你的程式碼如何影響整個產品，如何為用戶創造價值。

記住，成為獨當一面的開發者，不只是技術能力的提升，更是思維方式的轉變。你要從「被動的執行者」變成「主動的思考者」，從「只關心技術」變成「關心產品和用戶」，從「單打獨鬥」變成「團隊協作」。

這樣的轉變不會在一夜之間發生，需要時間和經驗的累積。但只要你持續學習、持續反思、持續成長，你就能成為一個真正獨當一面的開發者。

研究所的研究對我的工作有幫助嗎？

參考： https://just-taiming.medium.com/淺觀點-我到底該不該唸研究所呢-e7acac210c7c

結論

各位學弟妹，今天我們一起走過了從學術界到業界的完整旅程。讓我簡單回顧一下今天分享的重點：

我們今天談了什麼？

首先，我們討論了畢業前的焦慮。從「我只會寫 Python，這樣夠嗎？」的疑問開始，到面對業界複雜技術棧的衝擊，這些都是每個即將踏入職場的同學會遇到的真實挑戰。

接著，我們深入探討了面試準備的重要性。從自我介紹的五大要素，到程式基礎能力、軟體開發流程理解，再到作品集展示和軟技能培養，每一項都需要你提前準備，不能等到要畢業了才開始想。

然後，我們談到了入行後的挑戰。技術棧的衝擊、團隊規範的適應、自學能力的培養、對程式碼的責任感，以及如何成為一個獨當一面的開發者。這些轉變不會在一夜之間發生，需要時間和經驗的累積。

最重要的三個觀念

提早準備：不要等到要畢業了才開始思考職涯規劃，現在就可以開始行動。
持續學習：技術這條路本來就是不斷學習的過程，沒有人一開始就什麼都會。
主動思考：從被動的執行者變成主動的思考者，從只關心技術到關心產品和用戶。

給大家的建議

記住，每個人都有自己的學習節奏和發展路徑。不要因為看到別人已經很厲害就感到焦慮，也不要因為自己還有很多不懂就感到沮喪。重要的是要有行動力，要願意去嘗試、去犯錯、去學習。

今天分享的這些資源和建議，希望能夠幫助大家少走一些彎路，在職涯的路上走得更順暢。但記住，這些只是起點，真正的成長還需要你們自己去實踐和探索。

歡迎交流

如果大家對今天的內容有任何疑問，或者想要分享自己的經驗和想法，都歡迎隨時跟我交流。無論是透過社群媒體、Email，或者面對面的討論，我都樂意與大家分享更多的心得和建議。

最後，希望大家都能在技術這條路上找到屬於自己的方向，成為更好的自己。謝謝大家！

投影片

投影片連結

紀錄

很榮幸拿到母校的演講邀請函，紀錄之～

Menu

前言

關於我