職涯 on 澳洲雲端架構師 EC

[我要升官加薪] 大結局：沒有升官加薪，但我很好

Sat, 29 Nov 2025 00:00:00 +0000

Photo by Frank Albrecht on Unsplash

2025.11.19 | 布里斯本

「我要升官加薪」系列最終章！

結論是：升官加薪的路斷了 XD 我沒有拿到 Principal Engineer 這個職位。

雖然消息還沒正式公布，但應該是同事 L 雀屏中選！

好笑的是，主管 B 私下找我一對一談這件事的時候，感覺他比我還緊張 XDDD

評審的反饋

技術能力很強（technically strong）——所以技術面是過關的。
面試過程中可以看出我非常善於自我反思（self-reflective），常常提出很好的問題。這點似乎廣泛得到主管 B、面試官 BJ、總經理 D 的一致認可。大家覺得我看事情不會只看表面，而是能看到背後的決策邏輯，有批判性視角（critical lens）。（我想也因此我的「好問題」有時候讓領導層們回答不出來，因為很明顯我想得比他們更深 XD）
溝通能力很強。
主管 B 認為我是團隊裡非常有價值的成員，也是這次 PE 職位非常有競爭力的候選人。

感覺他們其實也說不太出來為什麼不選我，最後給了我一個「領導力部分還可以持續加強」的發展計劃。

聽到消息當下

其實內心滿平靜的。看到主管 B 超緊張，反而隱隱覺得有點好笑 XDDD

我給他的反饋是：「感謝這次的機會，我覺得我學到了很多。就像我在績效評估（performance review）上提到的，當我靜下心來回顧過去一年在工作上的成果，我簡直不敢相信自己居然達成了這麼多，也很為自己感到驕傲。說實話，在 PE 這個職位出現之前，我從來沒有想過這件事，但在申請過程中我做了很多反思，發現其實我可以做到——而且我已經在做 PE 該做的事了。」

言外之意是：「我其實不需要來自你們的外部認可。向來以極高標準要求自己的我，居然已經自己認可自己了，意識到這點的我其實更開心。」✌️

旁觀者清

聽到消息後，朋友跟我說：「之前你說自己算半路出家，過去經歷比不上其他人——但實力上你根本不遜色，還很優秀啊！」

我一直覺得自己是文科轉職工程師，技術底子不如別人深厚。但看來可能只是冒牌者症候群（imposter syndrome）又犯病了，畢竟其他人完全沒有這種感覺 XD

總之，這其實也是好事

同事 L 實至名歸，我真心替他感到高興！

而且 PE 這個職位雖然我可以做得很好，但我可能會做得很痛苦——50% 技術 + 50% stakeholder management，實在不太符合我的個性 🤣

所謂能力越大，責任越大，壓力也越大——同事 L 加油 XD

[我要升官加薪] 第三集：PE 面試流程分享

Mon, 24 Nov 2025 00:00:00 +0000

Photo by Michal Czyz on Unsplash

2025.10.28 | 布里斯本

就在今天，收到了 Principal Engineer 職位的面試邀請 🥳

面試時間排在下週二，面試官是我的直屬主管，還有一個隔壁組的 GM（General Manager），我們就叫他 BJ 吧。我非常好奇為什麼不是我們組的 GM 來面試 😆

面試邀請上一片空白，什麼資訊都沒有，完全不知道是什麼形式。就只有標題寫「Principal Engineer Interview - EC」，太神秘了哈哈哈！

請大家祝我好運 🍀

2025.10.29

同事 EN 今天上班上到一半突然跟我說：「我們可以簡單聊一下嗎？」

我還以為他要問工作上的問題（我算是他的 mentor），結果我說好之後，他把我拉進一間會議室。

我：??????

一進會議室他劈頭就問我有沒有申請 Principal Engineer 這個缺？我說「有啊」，然後他說他其實也有興趣，但猶豫了很久還是不知道該不該踏出這一步 😖

我回說：「快申請啊，我支持你（Go for it）！不過……你知道申請截止是上週四嗎 🤣」

我還建議他趕快去找主管聊一聊，看看可不可以補交申請。我真心覺得我人有夠好 & 完全支持其他人也去追求他們想要的目標 😆

雖然我極力推薦，但也不知道他後來有沒有去找主管？

事後回想，覺得同事也太天兵！如果有興趣申請，至少先看一下截止日期吧 🤣 白白煩惱那麼久，還錯過截止日期！而且申請表上明確寫著「希望申請人在現職待一年以上」，EN 才入職九個月，其實本來就不符合條件……

太神奇了，澳洲職場 🤣

2025.11.04 一面

今天特意穿了新買的洋裝，有種寫意山水畫的感覺 😆

Principal Engineer 一面完成！形式是一對二，兩位面試官分別是我的現任主管 B（也是未來 PE 職位要匯報的對象）和隔壁部門的 GM - BJ。

面試形式是行為問題（behaviour questions），完全沒有技術或解決方案設計（solution design）相關的問題。

仔細想想這樣安排也有道理——既然是內部申請，技術能力平常就有目共睹，不需要額外評測。

面試問題主要圍繞在：如何主導跨團隊項目並處理反彈意見、如何在領導層目標和實際執行之間取得平衡、如何在交付壓力和技術債之間做取捨、如何在資源受限下工作、如何提升各團隊的工程標準、如何衡量 PE 上任 90 天的成功指標，以及這個 PE 職位的優先工作項目。

[我要升官加薪] 第二集：跟主管聊完之後，我決定申請了

Tue, 18 Nov 2025 00:00:00 +0000

Photo by Brett Jordan

2025.10.13 | 布里斯本

在大家的鼓勵下，我約了主管 B 一對一快速聊了一下 Principal Engineer（PE）這個職位，大概聊了四十分鐘。

控制狂如我，當然事先準備了問題——每個問題都是我萬中挑一，跟 ChatGPT、Gemini 再三斟酌後的結果XD

脈絡大概是：先簡單閒聊，再問關於角色定位跟職務劃分的問題、探口風，甚至連最難開口的薪資問題我都問了。

我是問問題的王者（自封）

整體對話氣氛滿輕鬆愉快的，我覺得我問了很多很好的問題！

怎麼說呢？好到主管 B 說「等等，這件事我還沒想過，我要先筆記下來～」

而且不止一題，他大概做了三題筆記，我還停下來等他打字，我簡直要笑死 XDDD

我精挑細選的問題完全環環相扣，每問完一題，他的回答就會無縫接到下一個問題～

職責：比我預期的好

這是純技術職位，不需要開管理會議（只需要開技術會議），也不用做人事管理或向上匯報。
主要目標是提升工程師文化（engineering excellence / best practices），甚至要指導（mentor）其他團隊的首席工程師（Principal Engineers）😳
主管 B 認為這個職位大約是 60% 內部實作 + 40% 對外技術諮詢（提供其他開發團隊技術建議）。
他不希望這個職位改變我們目前的團隊文化。他的態度是：我們團隊本來就是一群聰明的資深工程師，不需要過多指導，大家自主就能把項目完成。如果遇到超大型項目，需要集思廣益制定方向的時候，負責人也會找大家一起討論解決方案（這樣一想，這個人幾乎就是我 XD 因為我做過很多大型 migration 專案，我個人的工作風格的確就是他描述的那樣）。

然後我問：「那我們以後的技術決策流程會改變嗎？重大決策是不是都要讓 PE 點頭？」（他說不用。）我接著問：「可是 PE 需要負責技術問責（technical accountability）耶？如果技術決策有問題，PE 不是要主責嗎？」

然後主管 B 就被我問住了 XDDD 他說「讓我記下來回去想想」哈哈哈哈。

薪資：出乎意料的直接

這是我最後的問題，經過層層鋪陳才問出口，我覺得這個提問節奏相當精妙！

最好笑的是，主管 B 回答：「這是個好問題，我還沒想過這件事……讓我去跟人資討論一下再回來跟你說。」

我說：「喔喔～沒關係啦！我只是想知道一個大概範圍，這樣可以幫助我更了解這個職位的全貌跟預期職責。」

他說：「這個問題很正常啊～大家出來工作就是為了那份薪水！但我是真的還沒跟人資聊過，不過我想對你來說應該會是一個『顯著提升』（significant jump）。」

沒想到平常看起來這麼佛系的主管 B，對薪資話題居然這麼直接了當！我第一次遇到直屬主管用這種語氣跟我聊薪資，真的覺得很有趣 😆

結尾大轉折

其實整場對話我都保持著「我只是想多了解一下這個職位，還沒確定要不要申請」的態度。所以結尾我說：「謝謝你花時間跟我聊，對我幫助很大，我會好好思考一下。」

結果主管 B 話鋒一轉說：「我其實覺得不管怎樣你都應該要申請！不管最後結果怎樣，參與這個徵選流程對你也會很有幫助，你應該要認真思考，然後申請！」

[我要升官加薪] 第一集：天上掉下來的... Principal Engineer 職位?

Fri, 14 Nov 2025 00:00:00 +0000

Photo by Christoph Theisinger

2025.10.09 | 布里斯本

我的天天啊～大消息！

我們團隊居然要開一個 Principal Engineer (PE) 的職缺！

要知道，我們的部門組織一向扁平到不行。除了我的直屬主管 B (職稱是 Delivery Lead，但身兼 Manager、Tech Lead、Business Analyst、Program 外)，下面就只有 5 個 DevOps Engineers，加上 1 個 Senior QA。個 Sendior Testing Engineering/Test Lead。

這次突然開了一個前所未有的 PE 缺，而且是限時兩週的內部限定 (Internal Applicatoin Only)。雖然開放給公司十幾個工程師團隊申請，但明眼人都知道，這其實是我們 DevOps & Platform Team 的主場。

科普一下我們公司的工程師升遷階梯： Associate → Engineer → Senior Engineer → Principal Engineer (純技術職的終點) > (如果想轉管理職，可以繼續 → Delivery Lead → (General Manager) GM → CTO)

問題來了：大家覺得我該不該報名？

老實說，其實我覺得現在的工作狀態不錯，薪水不錯、工作內容駕輕就熟。但我也不知道這個新的 PE 職位會為我們團隊帶來怎樣的新變化？

Gemini vs ChatGPT 人設大不同！科技業職場觀察：AI 如何解讀多元包容、性別意識跟政治正確

Fri, 31 Oct 2025 00:00:00 +0000

Photo by Daria Nepriakhina 🇺🇦 on Unsplash

我是一個重度 AI 使用者!

不管是在工作上 - 寫程式、解 bug、潤飾 email、探討各種 solution approaches

或是個人生活 - 議題探討、烘焙食譜調整、財務規劃

我三不五時都在跟 AI 對話、探討各式想法。

也從中觀察出，雖然 LLM models 大致上給的回覆都大同小異，但有些時候切入的角度跟扮演的角色卻非常不同！

起因：一個「天上掉下來」的職位

是這樣的，我們團隊的組織本來非常扁平：

一個主管：負責 delivery lead, tech lead, people manager, business analyst。
DevOps Engineers x5：大家的職級基本相同，我跟Ｌ、A 是同一時間入職的（年資約兩年多）。E 是最資淺的，入職 10 個月。AL 本來是 senior data integration engineer，但他們整個 data integration 被裁，所以他被併入我們 DevOps team 後改做 DevOps Engineer 的工作。
Sendior Testing Engineering/Test Lead: 基本上自己主導 testing strategies 跟相關 testing 工作，獨立於其他 DevOps Engineers 之外。

突然有一天，主管宣布我們團隊要新增一個 Principal Engineer (PE)。

文組轉職澳洲科技大廠工程師—我的科技業職涯的反思

Fri, 12 Apr 2024 00:00:00 +0000

Photo by Christopher Sardegna on Unsplash

分享我從文組轉職科技業工程師後，在科技大廠 Amazon、微軟，以及大型石油公司 Shell 三個不同技術職位的任職經驗中獲得的技能與經驗分享。進一步分析我認為要轉職成功需要具備哪些要素。

前言

作為一名從文組背景轉職到科技業的工程師，我在過去幾年中有幸在三個不同規模和性質的公司工作：科技大廠 Amazon、微軟 (Microsoft)，以及大型石油公司 Shell。每一段經歷都帶給我不同的技能和視野，也讓我對科技業職涯有了更深入的理解。

在這篇文章中，我想分享這些寶貴的工作經驗，包括在不同公司文化中的學習成長，以及我認為轉職成功需要具備的關鍵要素。希望能為正在考慮轉職或剛踏入科技業的朋友們提供一些實用的參考。

我的科技業職涯歷程

Amazon：我的第一步

在 Amazon，我學會了如何在快節奏的環境中工作。Amazon 的文化強調客戶至上和創新思維，這讓我快速適應了科技業的工作模式。在這裡，我：

學會了敏捷開發方法 (Agile Development)
培養了數據驅動的決策思維
體驗了高效能團隊的協作模式
接觸到了雲端技術和大規模系統架構

Microsoft：深化技術能力

在微軟的工作經驗讓我更深入地了解企業級軟體開發。微軟重視技術深度和產品品質，這段經歷幫助我：

強化了軟體工程的基礎知識
學習了企業級應用程式的設計模式
參與了開源專案的貢獻
培養了跨文化團隊合作的能力

Shell：跨領域的挑戰

在石油公司 Shell 工作是一個有趣的跨領域體驗。作為一家傳統能源公司，Shell 正在積極進行數位轉型：

將科技應用於傳統產業的機會
學習了能源產業的專業知識
參與了數位轉型專案
體驗了大型企業的組織運作

轉職成功的關鍵要素

根據我的經驗，我認為成功轉職到科技業需要具備以下幾個關鍵要素：

1. 持續學習的心態

科技業變化快速，新技術層出不穷。保持學習熱忱和適應能力是非常重要的。我建議：

定期更新技術知識
參與線上課程和工作坊
關注產業趨勢和技術發展
建立個人學習計畫

2. 實務經驗的累積

理論知識固然重要，但實務經驗更是不可或缺。建議透過以下方式累積經驗：

參與開源專案
建立個人專案作品集
尋找實習或兼職機會
參加程式設計競賽或黑客松

3. 軟實力的發展

除了技術能力，軟實力同樣重要：

溝通能力：能清楚表達技術概念給非技術背景的同事
團隊合作：在跨功能團隊中有效協作
問題解決：面對挑戰時能系統性地分析和解決問題
時間管理：在多重任務間有效分配時間和資源

4. 網絡建立

在科技業建立專業網絡是非常有價值的：

轉職可以一轉再轉嗎？薪水是轉職最重要的考量？

Thu, 15 Jun 2023 00:00:00 +0000

Photo by Ian Schneider on Unsplash

前言

成功從文組轉職 IT 技術職的我，現在又想再轉職一次! 你們可能會說「來人啊! 可以讓人這樣一轉再轉嗎?」XDD

其實我一開始也覺得這種路線(英文系> Cloud Consultant > Solution Architect > DevOps Engineer) 感覺應該不會成功吧? 結果最近居然有個 DevOps Engineer 面試讓我闖進了最後一關 (其實也只有兩關啦)，讓我發現這件事居然是可行的!!! 哇，雖然我對於人生一直以來都是保持著勇於嘗試、努力體驗的心態，但我真的不知道這樣亂試(?)其實也是會成功的耶XDD

果然人生就是有試有機會!

題外話，其實我當年從文組轉職的目標是當 Web Developer/Software Engineer! 如果你不是 IT 相關產業的，你可能不會知道，雖然 Cloud Consultant、Solution Architect、Software Engineer 都是 IT 相關職業，但實際的工作內容跟專業技能可能天差地遠，甚至我們彼此之間也不一定了解對方在做什麼XD

例如我曾經試圖跟我做 Support Engineer 跟 Data Analyst 的朋友解釋過 Cloud Consultant 跟 Solution Architect 在做什麼，結果不管我怎麼講，他們都還是一頭霧水哈哈哈哈。我之前做過簡單的比較，雖然當時比較的是 Software Developer 而不是 DevOps Engineer，但大家有興趣的話還是可以參考: 《那些沒人告訴你的雲端職位真相：Solution Architect 與 Cloud Engineer 職場日常大揭密！》

背景

如果是第一次看我的文章的人，可以參考《大家好，我是EC!》，有我詳細的生平(?)。簡單來說，我是土生土長的台灣人，靠著自己的奮鬥成功移民澳洲。大學讀英文系，後來憑著一股不服輸的心 (參考:《文組轉職澳洲 IT 工程師，我靠 Coding Bootcamp 進了亞馬遜》)，裸辭了做了三年的辦公室文書工作，讀了六個月的全職 coding bootcamp (全端網頁工程師課程)。

如何評估現職是否適合你 — 工作小任務(work tasks) 評分表

Sat, 01 Apr 2023 00:00:00 +0000

如何評估現職是否適合你 — 工作任務 (work tasks) 評分表

Photo by Will Francis on Unsplash

前言

這個方法是我最近在 podcast 大人的 Small Talk EP121 不再憑直覺換工作！轉職也有系統化做法？上學到的，聽完之後覺得是一個以系統性方法來分析職位內容跟個人工作傾向，非常適用於最近在考慮要不要轉換職涯方向的我，所以想要加上我自己個人的解讀來跟大家分享一下。

如何做工作小任務分析:

把你每天在工作上要做的事情，以小時為單位記錄下來。 例如我週一做的事為: 跟客戶開會一小時 x4 、花時間回客戶郵件一小時 x 1、研究某一個雲端技術一小時 x2。紀錄兩週之後，你就可以歸納出你的工作大概是由 10–30 個小任務所組成。
為每個小任務評分 : 如果是你喜歡做的小任務，或是做完會給你成就感的小任務，我們給它 1 分。如果是你討厭的小任務，或是做完也沒有成就感的小任務，我們給它 -1 分。如果是你既不喜歡也不討厭的小任務，我們則給它 0 分。
分析並歸納你的 1 分小任務，找出你偏好的職場方向: 例如 Podcast 主持人 Bryan 的職位是土木結構工程師，但他後來發現他所喜歡的小任務都是跟人有關，例如跟客戶開會、專案管理、跨部門合作、專案報告，而不是結構計算與分析。但在他的現職的20個小任務中，只有 5 個1分小任務。
觀察在工作環境中，有哪些職位的工作內容包含了更多你的 1 分小任務: 例如 Bryan 後來發現他們公司有個職位叫專案工程師，這個職位的工作20個小任務裡面就包含了較高比例 Bryan 喜歡的1分小任務。
(這點可能比較適用於大公司) 發現其他包含更多1分小任務的職位之後，你就可以開始多跟這些職位的人接觸，了解他們的日常工作內容(可能他們實際上做的事會跟你想像的有出入)，甚至是主動提出要幫忙他們的工作，藉此嘗試一下這個職位的工作內容(當然此時你的本質工作還是要做好): 繼續使用 Bryan 的例子，隨著他幫忙的事情越來越多，同時他也做得特別好，老闆就漸漸把專案管理相關的工作交給他，把結構計算的工作交給其他人。此時雖然他的工作職稱沒有變，但他的工作內容其實已經逐漸偏向他想要的專案工程師了。(當然如果你不幸遇到慣老闆，此時也可能會變成你拿一份薪水，但卻要做兩個人的工作，所以尺度還是要稍微自己把握一下XDD)

以 Solution Architect 為例

以下是我對於 Solution Architect 這個職位的工作小任務分析，我總共歸納出14個小任務。有趣的是，我最後的總分是 0 分XDD (也就是我喜歡的小任務跟不喜歡的小任務剛好打成平手)。Bryan 的廣播裡沒有提到評分加總這個概念，但我覺得如果你的整體評分可以是正數或是越高越好，那就代表其實你的現職並沒有那麼難以忍受(可能只是其中一兩項你不喜歡)，所以你也可以用此作為要不要轉職的標準，畢竟世界上沒有完美的工作，人總是要做出取捨XD