Yin

Yin

那杯茶
職涯故事

那杯茶

剛進公司那陣子,他出門前還會花一點時間在自己身上。 站在衣櫃拿起一件,想一下,再換另一件,確定好了,還會順手用蒸氣熨斗把折痕燙平。 換上隱形眼鏡,他對著鏡子看一眼,把頭髮撥整齊。 走到門口時,有時還會折回去再看一次。 那篇文章是他前一個週末寫完,帶進了公司。 上午他改了幾個字,午休前又重讀了一次,把圖的順序重新排過。 有前輩教他,把流程畫出來看。他畫了,那些原本容易漏掉的情況,順著箭頭一條一條出來了。 他想,這種坑以後進來的人也會踩。 那個週末,他圖重畫了好幾次,甚至還找朋友幫他看過一遍,確認別人真的看得懂。 吃完午餐回來沒多久,前輩喊了他一聲。 「我們來討論一下吧。」 他把文章打開,推到前輩面前。 前輩看完,頓了一頓,說: 「主動寫文件很好啊。不過你現在這個階段,還是先把基本功練熟比較重要。 我之前給你的那本書,你再多練幾遍看看。 先練到不用看教學,也能把基礎功能寫出來。」 他點頭,說好。 手卻先一步把教學文章的視窗關掉了。 那篇文章後來沒有再被提起。它一直留在他的 private 文件區裡。
閱讀時間 8 分鐘
開會
職涯故事

開會

會議上,同事在講新功能的概念,還沒講完。 我提出一個盲點。 同事視線往斜下方落了一下,嘴巴微開,停了半拍,才說「對誒。」 他開始接我的問題時,第二個問題已經頂到喉嚨口,幾乎是自己滑了出去。 他回答的速度降了下來,認真地說:「這個問題很好,我要想一想」。 我原本只是坐著聽,背卻不自覺挺直了,身體往桌前靠了一點。嘴角抿住。 走出會議室,我用比平常更快的腳步回到座位,什麼都沒做,只是不斷重播剛剛那一幕,不是我開口的瞬間,是他真的停下來想的那一秒。 腦中甚至開始浮現下一次的畫面:我再丟出一個問題,對方再一次停住。 隔一天的會議,我又在討論的斷點切了進去。 別人話還沒講完,我已經抓到提問的縫。 第一題還在試,後面卻越問越順。有一次我丟出一個問題,旁邊的人直接接過去,討論順著那個方向就展開了。 我第一次不是散會後才補交作業,而是在討論還活著的時候,跟上了那個速度。 那幾天,我甚至開始期待開會。 有次朋友聊到愛情觀,聊到一見鍾情, 他還找了一支短影片傳給我看,説他就是那樣的人。 我一邊看,腦袋卻已經先往前跑了,從他上次失戀到現在的模式、
閱讀時間 9 分鐘
答案來得太快之後
職涯故事

答案來得太快之後

閱讀器平常都在我身上,搭車會看,等人也會看。 那天下班打開新買的工具書,看了幾行,文字開始糊在一起,怎麼讀都進不了腦袋。把書蓋起來,打開手機,滑了十分鐘不知道自己在看什麼。再打開,又是同一頁。 不是身體累。 放下書,想說那來安排週末好了。打開行事曆,盯著看,挑個週末能去的地方。眼睛聚焦不了,關掉。 今天上班到底做了什麼? 其實沒做什麼特別的,只是打開 AI,跟它討論工作規劃,再一路審查它的產出。 以前寫到一半卡住,會開一個分頁,搜尋那段語法怎麼寫。複製回來,貼上去,跑一次看看。錯了,再查。那十五分鐘裡什麼都不用決定,手在動,腦子可以放空。 現在按下去,兩秒後整頁程式碼已經在那裡了。手還放在鍵盤上,但接下來每一行都要自己判斷。沒有那十五分鐘了。 我試過解決這個問題,寫更多的規則讓 AI 可以幫代勞判斷。它確實越來越像回事,但以前錯得明顯,現在是錯得漂亮。 我得停下來,
閱讀時間 7 分鐘
我原本以為那只是一次支援
職涯故事

我原本以為那只是一次支援

撇除公司一定要參與的任務之外,我們其實有一部分目標是可以自己選的。 有一次季初選目標時,我看到一個基礎建設任務。我看到的當下停了一下。腦中閃過的畫面很具體:三個月後的 demo meeting,我坐在那裡,從頭講一個自己主導的東西。不是補充說明,不是協助處理,而是有一條主線是我自己的。 同事舉手了。我沒動。我覺得對方確實能做得更好。我把視線移開了。 同一時間,另一個 API 重構任務正在找幫手。同事直接開口問了,有沒有人能支援。 我當下是抗拒的。 但我最後還是答應了。 我甚至還替自己找了一個很順的理由:只幫一下應該還好,原本的任務多少還是能往前推。結果我真正想推的任務進展很慢。時間被分去支援救火,最後哪邊都沒有長出很清楚的成果。 下一季到來,那個 API 任務又被提了出來。 我一聽到,心裡先縮了一下。 果然,沒有人接。 同事開始一個個往下問。 問到另一位也有主要任務的同事時,他沒有移開視線,幾乎在問題一說完的下一秒就回了不要,拒絕幾乎是直接撞在問句的尾音上。 我愣了一下。 現場沒有拉扯,沒有我以為會有的那種壓力。提問的同事只是很自然地轉向下一個人,好像剛剛那句
閱讀時間 5 分鐘
AI 時代的工程師成長:從學工具到練能力
職涯故事

AI 時代的工程師成長:從學工具到練能力

2024 年我參加了曼陀號,得到很多職涯建議。當時覺得那些建議閃閃發光,連續發了長文紀錄。我最喜歡的那篇是「技術海中浮沉,尋找未來地圖」— 就是因為那篇,我才開始有意識地寫技術文、設目標、做紀錄。 一年多後,我想回來看看那套框架有沒有用。但得先說一件事:我技術文斷更了。 原因很直接。AI 太強了。強到讓我開始懷疑,自己花力氣學技術、寫技術文,到底還有沒有意義。這個懷疑越滾越大,後來我就停了下來。 這篇其實想回答的,是一個最近一直讓我有點站不穩的問題:AI 加速之後,原本支撐我成長、也支撐我寫下去的那種自我確認,還剩下多少意義? AI 讓我開始懷疑寫技術文章的意義 那時候根據教學訂了一個目標:成為公司裡的 CDN master。為了驗證成長,我寫了 4 篇相關技術文,內部解了至少 3 個痛點。做完後確實變熟,甚至公司遇到相關問題都會先問我。 但有一次,在寫技術文的過程中,我把一篇寫到一半的文章丟進
閱讀時間 14 分鐘
要不要轉職?從業務轉工程師前,我怎麼判斷該停損離開
轉職心得

要不要轉職?從業務轉工程師前,我怎麼判斷該停損離開

那些隱藏在果決背後的猶豫 這是我四年多前,從業務轉職成工程師前留下的碎念,現在的我做回顧,已經跟這些情緒有了距離,但我決定把這份脆弱留下來,遞給還在漩渦裡的人。 前陣子有讀者詢問我轉職方向,他卡在最源頭的掙扎:還不確定要不要轉職。這讓我意識到,過去的文章我大多呈現了確定目標後的果決,但那並不完全真實。事實上,在做出決定前,我經歷了長達一年的猶疑與反覆徘徊。 那段時間並不是某個瞬間的頓悟,而是一圈一圈的反覆確認與試錯。猶豫本身,是無法被壓縮成一句結論。當時我花了一段時間用各種方式測試、調整、再觀察,最後才下結論:繼續撐沒有用,該停損了。 這段歷程值得被記錄下來。如果你現在也卡在「要不要轉職」,或者單純好奇那些猶豫的人究竟在想什麼,希望這篇文章能給你一些共感。 關於業務工作的實測結論:開發型與維護型的差異 為什麼這兩條路,最後都沒有走得下去 業務其實有不同類型,例如:「維護型」、「開發型」,這邊只舉這兩個簡單說明。同一個職務也有可能開發跟維護都有,差別在於比例多寡。我曾做過半導體代理商業務(維護)、儀器業務(開發)、半導體原廠業務(維護)。 面向 開發型業務
閱讀時間 16 分鐘
工程師為什麼會解錯問題?從 Staging 到 SQL 優化的兩次復盤
職涯故事

工程師為什麼會解錯問題?從 Staging 到 SQL 優化的兩次復盤

之前提到要寫關於復盤(反思)的文章,這個想法在我腦中躺到都長灰塵了。 想到要從早期的文件重新檢視那些現在看來淺顯易見的錯誤,同時也得面對自己當初的不足,心裡的抗拒比想像中大太多了。畢竟剛轉職時踩過的坑又痛又深。趁著過年長假慢慢寫下來,總算把這段思考整理完成。如果你也對復盤在實作中的實際應用有興趣,以下紀錄我的思考歷程。 工作一段時間之後,我發現過去很多錯誤不是因為技術不好,而是因為太快開始解題。過去習慣看到問題就動手優化、修正、調整。好像只要把手段做漂亮,事情就會自然變好。 但有時候,真正應該先做的,是停下來確認:這個問題本身對嗎?我們要解的到底是什麼?成功的定義是什麼?那些「看起來理所當然」的前提,真的成立嗎? 這篇文章是我用現在的視角,回頭檢視兩年前的自己,並紀錄我當時怎麼利用復盤跟反思,一步步改正自己的思考習慣,把自己從「急著答題」拉回「先把題目問清楚」。用兩個印象很深的踩坑案例,拆解我剛當工程師時在驗證標準、責任邊界、以及對既有邏輯的假設上,常犯的錯。 情境回放:電子發票上線的意外 — Staging OK 卻卡在 Production 2023
閱讀時間 12 分鐘
新手工程師的 Code Review 衝擊:從訓練營到商業產品的現實落差
職涯故事

新手工程師的 Code Review 衝擊:從訓練營到商業產品的現實落差

轉職不只打怪升等,更是「被怪打到痛」的真實洗禮——這篇記錄被怪打的心得 (以下內容著墨於轉職第一年的心得) 我的總體歷程大概是這樣: 功能可以動 → 可讀性問題 → 品質盲區,驗證不足 → 思路狹窄,只會找一個可行解 → 慢慢開始有自己的想法 這歷程裡的每一段,對我來說都不是自然而然突然會的,而是「刻意練習強制修正」。從訓練營出來也就 6 個月學習時間,仍然是趕鴨子上架,很多觀念只是了解表面而已。 真正進到商用產品真的還差了一大截,不可否認剛開始我對自己感覺良好,畢竟從訓練營畢業,能做出網頁而且可以 demo 我已經覺得自己很棒。但第一次 code review 之後就讓我面對現實了… 滿滿的 code review comment,讓我發現還有很多成長空間。想起來那段時間充滿壓力,每天不斷反思錯誤在哪,真的是胃痛啊啊啊啊啊啊。 Code Review 是照妖鏡:「以為懂了」,其實還沒懂? 曾經前輩對我提出這個問題,並且要求我理解問題的時候加入以下流程: * 什麼是 XX?
閱讀時間 17 分鐘
CloudFront 快取策略實作思維與常見誤區(下)
CDN

CloudFront 快取策略實作思維與常見誤區(下)

本文為 CloudFront 系列第三篇,建議先閱讀以下文章了解基礎架構後再繼續。 CloudFront cache 錯頁面 Debug 流程(Rails 篇)這篇文章從真實案例出發,帶你逐步排查 CloudFront 快取錯頁面的問題。解析 Rails 的預設 Header、CDN 設定與 DNS 模式,避免使用者畫面被快取錯誤、看到別人的資料。假裝喝酒的軟體工程師YinCloudFront 快取設定詳解:Cache Key、TTL、Path Pattern 是什麼?(上)CloudFront 的快取設定讓你一頭霧水?這篇用白話文解釋 Cache Key、TTL 和 Path Pattern,讓你一次掌握 CDN 的快取核心概念!假裝喝酒的軟體工程師Yin 以下內容會幫助你理解 CloudFront 的快取策略與行為設定,
閱讀時間 7 分鐘
CloudFront 怎麼決定快取?搞懂 Cache Key、TTL 與 Path Pattern(上)
技術文章

CloudFront 怎麼決定快取?搞懂 Cache Key、TTL 與 Path Pattern(上)

第一次打開 CloudFront 的設定頁時,我其實有點混亂。 畫面上會看到 Cache Key、TTL、Path Pattern 這些名詞,但如果你還沒實際踩過 CDN 快取的坑,很難立刻知道它們各自在管什麼。 後來我爬了很多文跟資料才理解,這三個設定其實分別在回答三件事: * 這份快取可以保留多久? * 哪些請求可以共用同一份快取? * 這個請求要套用哪一套規則? 換句話說,CloudFront 的快取行為,很多時候就是由 Path Pattern、Cache Key、TTL 一起決定的。 這篇文章我會用比較直白的方式,整理這三個概念各自的角色,以及它們實際上怎麼影響 CDN 的快取判斷。 實際進到 CloudFront 的 Behaviors 頁面時,會看到一組預設行為,以及對應的快取相關設定。 一開始如果不熟這些欄位,很容易只看到一堆名詞,卻不知道它們分別會影響什麼。也因為這樣,我後來是反過來先搞懂每個設定在決定什麼,再回頭看介面,才比較看得懂。 當我從
閱讀時間 10 分鐘
CloudFront cache 錯頁面 Debug 流程(Rails 篇)
技術文章

CloudFront cache 錯頁面 Debug 流程(Rails 篇)

以前在 bootcamp 學習套用 CDN 的時候,因為懂的少也不懂得懷疑,覺得反正部署之後,圖片有經過 CDN 、顯示得出來就好,其他不管。 但現在有了經驗、也踩了各種雷坑之後,疑心病加重!每個設定都覺得疑點重重,在想幹嘛要有這個,設定這是想做什麼!每個都覺得這一定有問題!!決定用這篇紀錄我的實作心得。 事件緣起:Reddit 真實案例 在 Reddit 上看到這篇討論,作者遇到了一個恐怖的狀況:CloudFront 把 A 使用者的頁面快取起來,卻回傳給 B 使用者看! 想像一下這個場景: * 付費用戶登入後看到的專屬內容,竟然被免費用戶看到了 * 或者相反,免費用戶看到了付費才能看的頁面 * 更糟的是,用戶 A 的個人資訊被用戶 B 看到了 Production 環境要是真的發生這種事情還得了啊!天啊!!!!緊張如我開始有了一連串的質疑! 問題:我的
閱讀時間 9 分鐘
CDN: Push 和 Pull CDN 的應用場景與使用考量
技術文章

CDN: Push 和 Pull CDN 的應用場景與使用考量

什麼是 CDN ? 全名是 Content Delivery Network(內容傳遞網路),是一種透過分佈式的伺服器網路來加速網站和應用程式內容傳遞的技術。這些伺服器分佈在世界各地,目的是將內容更靠近用戶,從而提高訪問速度和效能。CDN 的伺服器稱為節點,當用戶請求網站內容時,CDN 會將請求路由到距離用戶最近的節點,提供最快的回應時間。 如果要我比喻 CDN 的話,他很像物流業者的倉庫。 舉例來說:物流業者有總倉庫和各個地點的小倉庫,當小倉庫設在離你家很近的地方,而且物流業者定期都會從總倉庫拉貨到你家旁邊的小倉庫的時候,當你訂貨購買,貨物只要從你家小倉庫送到你家就好,相當快速。 → 所以,以台灣用戶來說,如果有節點在台灣,回應速度是最快的。 可以想像成:貨物從日本倉庫送來 vs 貨物從台灣倉庫直送的時間差 什麼是 Push 型 CDN ? * 主動上傳內容: 在 push 型 CDN 中,需要「主動」將資源上傳到你指定的 storage,
閱讀時間 8 分鐘
工程師的溝通祕訣:從公司面試官視角揭露面試核心重點
面試 精選

工程師的溝通祕訣:從公司面試官視角揭露面試核心重點

前陣子有幫一些認識的人看了履歷以及面試準備,發現大家其實有一些很棒的特質只是寫履歷的時候沒有想到,又或者在面試回答的時候只有著重在技術上,導致技術以外的特質無法得知,在模擬面試完後總覺得少了什麼…。 剛好曼陀號第三次月會「工程師的溝通祕訣」就是分享面試的全部流程以及核心。分享內容以「公司面試官」的視角來看整個面試!說明到底面試的時候要注意什麼,讓面試官可以在短時間內建立對你的印象。 這篇文章會引用船長 Jalex 的觀點(船長背景)並融合我的個人觀點。這次的月會也讓我從更宏觀的角度看整個面試流程,而不是用網路上查到的題目單點、單點去拼湊出面試的形狀。而且之前都只有幫助身邊的朋友,這次有機會可以寫成文章,也希望可以幫助一些有看到文章的人。😆 面試的本質 求職/招募是尋找長期合作夥伴的過程 公司是在找一個可以長期合作的人,而你在找的是一間可以獲得自我成長的公司。 ⭐ 公司觀點: 因為雇用錯人的成本很高,所以要最大限度地淘汰可能不適任的人。 ⭐ 求職者觀點: 在決定簽下去之前,確認這是份兼具自我成長與公司獲益的機會。 以公司角度來看,雇用錯人可能會花很長時間去調整,因
閱讀時間 18 分鐘
PostgreSQL中文全文檢索:pg_trgm 與 pg_bigm 模組性能對比
技術文章

PostgreSQL中文全文檢索:pg_trgm 與 pg_bigm 模組性能對比

本文研究了 PostgreSQL 的兩個 extension module - pg_trgm 和 pg_bigm,比較它們在中文全文檢索方面的性能和特點。並且有詳細的功能對比和實際的效能測試 為什麼要比較 pg_trgm 和 pg_bigm? 主要是因為現在在使用的是 postgreSQL,原本做中文檢索只用 like 很慢,想要做中文全文檢索但是又不想要導入全新工具,受限於中文全文檢索網路上的資源很少,這邊先看看 postgreSQL 有沒有什麼神奇小道具可以支援,而 pg_trgm 和 pg_bigm 這兩個都是 postgres 的 extension,而且 AWS RDS 有支援。 參考 AWS RDS extension support 資料 pg_
閱讀時間 7 分鐘
從面試窺見未來:轉職軟體工程師時如何評估潛在主管
面試

從面試窺見未來:轉職軟體工程師時如何評估潛在主管

為什麼需要面試時關注面試主管? * 在求職過程中,許多人常常專注於回答技術問題和展示個人表現,卻忽略了對面試官——未來可能的主管——的仔細觀察。主管在職場中扮演著決定性的角色,他們不僅是你最重要的合作夥伴,同時也深刻影響著你的工作表現和職業發展。以下是一些與主管密切相關的工作範疇:一位優秀的主管能夠在困難時為你擋風遮雨,為你在高層面前爭取利益,並協助你談判加薪,讓你日子妥妥過。相反,一位不稱職的主管可以讓你黑到發亮,除了他可以電你之外,還讓上層也電你電到飛、讓你身心受創等著看心理諮商。下面列出工作與主管關聯的項目: * 績效評核:直接影響你的獎金和職業晉升。 * 任務分配:確定你的日常工作內容和責任範圍。 * code review(PR review):提升你的程式碼質量和專業技能。 * 個別談話(1 on 1):提供反饋並討論職業發展。 * 作為與公司高層溝通的橋樑:代表團隊發言並反映團隊需求。(當然也包括回報你的工作狀態!!!) * 提供學習和發展建議:指導你的專業成長路徑。 面試過程中,評估未來主管的 5 個面向 * 技術問題的處
閱讀時間 12 分鐘
加薪準備指南:( 二 )績效評估的策略與實踐
績效考核

加薪準備指南:( 二 )績效評估的策略與實踐

公司績效考核的重點是什麼? 當我們談到公司的績效考核時,通常會聽到主管對於新員工的評價,例如「不符合期待」、「符合期待」或「超出預期」。許多公司會設定明確的目標,指導員工應該朝哪個方向努力。然而,有些公司對於期望卻沒有明確的表達,需要你去主動提問。 在前幾份工作中,我觀察到公司績效優異的人通常會深入了解公司期望的方向和目標,並且在這些方向力求表現。因此確切了解「公司對你的期待是什麼?」是績效考核的核心。以下列舉了幾種常見的評估方向,但是請記得,每間公司的重點可能不盡相同。一般來說,進入公司後,主管會期望新員工能達到一定的標準。以下我將先詳述幾個常見的評估方向,再以一個例子說明當努力的方向與公司期望不符時可能出現的情況。(下面只是舉例,實際狀況依公司而定) 首先,讓我們看看幾種常見的績效考核方向: * 交付程式碼品質 * 工程師是否遵循公司內標準,寫出的程式碼是否易於理解和維護 * 團隊合作和溝通能力 * 重視工程師在團隊中的互動,包括他們如何與同事合作解決問題,以及他們在會議和討論中的表現 * 積極主動性 * 評估工程師是否能夠在日常工作中主動發現潛在的
閱讀時間 10 分鐘
技術海中浮沉,尋找未來地圖
曼陀號計畫 精選

技術海中浮沉,尋找未來地圖

此為曼陀號第六屆工程組第二次月會心得 工作快滿兩年後,我開始很常冒出一個念頭: 每天上班寫程式、改 bug,也不是沒做事,但我到底有沒有在進步? 技術書買了一堆,不知道該先讀哪本。看著訓練營同學換工作、加薪、往下一階段走,自己卻有種卡在原地的感覺。我後來發現,問題不一定是我不夠努力,而是我根本不知道該怎麼規劃成長。 這次曼陀號月會談的,正是這個我卡了很久的問題:技術百百種,到底該培養什麼,又該怎麼執行? 對我來說,這場分享最有幫助的不是再多學幾個技術名詞,而是把原本模糊的職涯焦慮,拆成比較能行動的問題。 這篇我想整理其中兩個收穫:怎麼盤點自己現在的位置,以及怎麼把成長規劃拆成可以執行的短中期計畫。 首先來提一下我自己每一季都會做的事情~ 自我盤點 在設立職涯目標之前,我認為最重要的是對自己目前的狀態有自覺,要先了解自己目前有什麼技術跟能力,才能夠去思考缺少的部分或需要補強的部分,這些事情離自己很近,不像未來會覺得模糊,很容易可以思考往下一步或修正的方向。 先看清自己:能力盤點與現況 以下是我每一季會對自己做的盤點內容: 目前自己在公司累積的技術跟能力是什麼?我解決
閱讀時間 19 分鐘
只補技術還不夠:我在曼陀號月會重新理解職涯與產品視角
曼陀號計畫

只補技術還不夠:我在曼陀號月會重新理解職涯與產品視角

轉職成工程師後,我前一段時間幾乎把重心都放在技術上。看文件、補知識、學工具,這些都很重要,但做了一陣子之後,我開始隱約覺得哪裡怪怪的:如果我只會從技術角度看事情,那我的職涯到底要怎麼往下走? 我會有這個感覺,是因為平常接觸的人幾乎都在公司內部,視角很容易被現在的工作環境限制住。也是因為這樣,我開始想找一個能接觸不同觀點的地方,後來加入了曼陀號。這是一個為期約六個月的 mentoring 計畫,每月有實體月會,也會搭配小組線上討論。 對我來說,它最有價值的不是活動形式本身,而是我第一次有機會在公司之外,聽到不同背景的工程師怎麼理解職涯、產品與工作的下一步。 第一次 engineer 組月會裡,船長 Jalex 講的不只是工程師要學什麼技術,而是我們的影響力、角色定位,還有職涯發展怎麼思考。那次我才比較明確地意識到:我原本以為自己缺的是更多技術知識,但其實我也缺少了看待職涯與產品的視角。 這篇我想從月會中最有感的兩個主題談起:職涯發展故事,以及產品思維。其中第一個真正打到我的,是怎麼從工作裡累積自己的職涯故事。 很多人前期只專注把任務做完,卻很少回頭想:我現在做的這些事,未來有
閱讀時間 12 分鐘
轉職軟體工程師的面試注意事項:如何回答軟性問題
面試

轉職軟體工程師的面試注意事項:如何回答軟性問題

今天要介紹的是轉職軟體工程師在面試的時候,常常會被問到的軟性問題。一般考量新手軟體工程師的成長潛力會根據「人格特質」做判斷,因此怎麼回答這類問題會顯得相當重要。這次列的問題幾乎每家公司都會從中挑幾個問題問,因此整理出來讓大家注意。 看完這篇文章,你可以了解以下內容: * 面試的關鍵:了解公司需要什麼樣的人才 * 如何識別並展示你是面試官理想中的人選 * 面試官真正想要聽到的軟實力回答 - 關鍵問題解析 ⭐  面試的關鍵:了解公司需要什麼樣的人才 * 為什麼重要? * 面試主要是要找「公司需要的人」,因此公司需要判斷眼前的人選「能不能符合公司需求?」 * 為什麼挑這點出來講? * 轉職新人往往已經具備了多樣的技術技能和個人優勢,但在面試中,最關鍵的是要能夠有效地表達這些能力,並與公司的需求相匹配。如果沒有注意到這些而漫天喊優點就會像下面狀況:一位顧客走進一家鞋店,他想買一雙運動鞋。但是,當鞋店的店員開始介紹鞋子時,他們卻只介紹各種正式的皮鞋、涼鞋,完全不提運動鞋。即使這些鞋子質量再好,款式再時尚,但因為並不符合顧客想要的運動鞋,所以這些介紹對顧客來說都沒有
閱讀時間 10 分鐘
談加薪前要準備什麼?先搞懂公司制度、職等與調薪標準 |加薪準備指南(一)
公司薪資制度

談加薪前要準備什麼?先搞懂公司制度、職等與調薪標準 |加薪準備指南(一)

為什麼要主動談調薪? 以前我一想到加薪,直覺都會放在自己身上:是不是表現還不夠好、成果還不夠多、現在開口會不會太早。 但後來我發現,談加薪這件事,不只是在看你做得夠不夠好,也在看你有沒有先理解這間公司是怎麼看待薪資、調薪和升遷的。 有些公司本來就有固定調薪節奏,有些公司薪資範圍很透明,有些公司則更吃主管判斷;有些時候問題不是你沒有資格談,而是你還不知道這個地方能不能這樣談、通常怎麼談、談了之後會影響什麼。 所以如果想提高談加薪的成功率,我覺得第一步不是急著準備說詞,而是先看清楚:你現在待的這間公司,到底是用什麼邏輯在決定薪水。 不過第一步我覺得還是要先從自己出發。 我準備好了嗎? 當你考慮談加薪時,有以下幾個問題需要考量: * 導致責任變更大,工作難度迅速調升。我是否已經準備好公司給我的新挑戰? * 公司文化不喜歡主動談薪的人,被同事聽到會被閒言閒語,我是否能夠承受這樣的壓力? * 為了符合公司需求,我是否能夠接受並按照公司給予的反饋進行調整? * 在談判過程中可能會遇到許多未知的問題,我是否已經準備好面對並解決這些問題? * 我真正的動機是什麼?這真的是我想
閱讀時間 6 分鐘
轉職心路歷程 ( 四 ) 訓練營中反思並成就職涯的獨特
轉職心得

轉職心路歷程 ( 四 ) 訓練營中反思並成就職涯的獨特

本文人格特質色彩重,聚焦於在訓練營中軟技能的發展跟建立人脈 同儕壓力拔山倒樹而來:WeHelp 第二階段的第一個難題 WeHelp 訓練第二階段開始,我跟同期的同學有了接觸。在第一階段學習時,我覺得成功交出作業就是一件很棒的事情,也無暇顧及其他的人進度。但到了第二階段看到同學之後…我漸漸開始不這麼想。 每週任務完成期限都是到週日,本來我交作業的時間就是在星期三、星期四,還有時間優化。我對於自己這樣的完成進度是給予肯定的,但當我跟同學有了實際接觸,也知道了前幾名交作業的同學是誰之後,我有了比較的心態: 「我完成作業的速度不是最快的,如果每個人只要時間夠多都能寫完 code, 並成功交付作業,那我的亮點在哪?」 焦慮感直接海嘯而來,比沒見到同學的時候多太多太多了,這就是同儕壓力拋出給我的第一個難題:「如果我跟同學爭取同一個職位,我贏在哪裡?」 本來只是想轉職成功,後來好像變貪心了?! 對我來說進訓練營還有一件事情很可怕,就是每個人專注在技術上!畢竟轉職成軟體工程師最該專注的是技術,覺得視野好像變窄,一有人技術比自己厲害,就好像他就是一個不得了的人物,持續追趕不上的挫敗感就會
閱讀時間 16 分鐘
轉職心路歷程 ( 三 ) 翻轉職涯的訓練營探索
轉職心得

轉職心路歷程 ( 三 ) 翻轉職涯的訓練營探索

以下文章主要探討我選擇參加軟體訓練營的原因和經驗。如果你正在考慮軟體工程師的轉職路徑,特別是對訓練營感興趣,這篇文章可能你提供一些見解。 注意:每個人的學習需求和情況都不同,這裡分享的只是我個人的觀點和經歷。 自學還是找訓練營? 我發現自學有遇到一些問題,像是如果學習卡關,很容易要花很長時間自己探索問題,而且卡關太久效率低落,我又想要提早轉職成功,這會延宕到我的進度。另外雖然網路上資源很多,但看課程自己試做,總覺得不是真的學會怎麼寫,懷疑自己是不是只是看完課程但是其實沒有吸收進去。最後一個考量是,要自己長時間堅持,心理要承受很大壓力,自學有可能讓我會想放棄。 所以如果要考慮自學還是進訓練營,我覺得可以考慮以下問題面向: 學習效果與進度評估 * 哪種學習方式能更有效地幫助我達成轉職目標? * 如何衡量自己的學習進度和成效? * 有哪些具體的里程碑或指標可以用來評估學習成果? 技能掌握與應用 * 哪種方式能夠更快、更高效地讓我掌握所需技能? * 如何確保我能長期保持這些技能,而不是速成後就忘記? * 學到的技能如何與實際工作
閱讀時間 12 分鐘
轉職心路歷程 ( 二 ) 循心探索轉職之路
轉職心得

轉職心路歷程 ( 二 ) 循心探索轉職之路

工作不快樂的根源:從補短轉向發揮優勢 在選擇下一份工作的時候,我認真思考了一個問題:「在工作中,什麼對我來說是最重要的?」我覺得是,我的快樂。 為什麼我前一份工作不快樂?我在業務工作其實花了很長的時間在改善我不擅長的事,做起來是痛苦的,雖然有成效、有些事開始變得輕鬆,但無法達到更好,要達到更好我要花更多心力,而且就算達到了我也不開心。 是不是我該換方向,去知道自己的優勢,去發揮它,而別花太多時間在補短。那麼發揮我的優勢是不是一個通往快樂的方向? 如果用以上方向來思考,哪種工作能讓我發揮優勢,能讓我感到快樂呢?一次通勤路上剛好聽到劉軒的 podcast - 探索天賦How-to——個人優勢檢測工具超實用解析,介紹了蓋洛普優勢識別的工具。這不只是一個測驗,更像是一面鏡子,讓我看到了自己以前沒有注意到的一面,也發現了自己的優勢所在:「學習和解決問題」。雖然我一直知道我喜歡用某種特定的方式來學習和工作,但以前我從來沒有深入去挖掘這些方法。這就是蓋洛普優勢識別測驗發揮它的功用的地方。 那麼,蓋洛普測驗到底有什麼好處呢?它適合那些希望深入了解自己工作特質的人,幫助你明確自己的優勢,還提供了
閱讀時間 9 分鐘
從業務到軟體工程師 - 轉職心路歷程 ( 一 ) 迷茫中想轉職
轉職心得

從業務到軟體工程師 - 轉職心路歷程 ( 一 ) 迷茫中想轉職

最初的想法 第一份工作為業務,當初選擇這條路是因為想改善我最不擅長的事情:「溝通跟人際應對」,也覺得要是最不擅長的都能夠克服,其他的技能還會有什麼難? 期間也歷經了很長的痛苦期,為了建立關係,跟 RD 除了聊工作之外也要聊天。曾經經歷過聊完案子之後,為了擠出話題,拋出週末有什麼計畫的話題,對方卻只簡單回答:「 沒什麼特別的。 」直接被句點!那個 RD 就坐在位置上一語不發,也不說自己要去忙了,就這樣跟我乾瞪眼超過 3 分鐘,當時覺得經過人生最漫長的沈默。不曉得怎麼搞的,雖然是在半導體業當業務,可是當時我完全沒有感受到什麼叫做女生優勢... 歷經被電、被噹、被黑,終於累積經驗到了一定程度。就算客戶很瘋打電話來說我再不給他樣品,他就要告我們,也嚇不倒我了。然而,我也發現我的進步幅度漸緩,當初驅動我持續努力是因為進步空間還有很大,但現在已經接近我的極限。而且當業務有一個點我始終不喜歡,就是「接電話」。客戶打來,如果身為專業業務,就應該隨 call 隨到。業務部長常說:「業務對客戶的服務要像呼吸一樣自然而且即時」。但是我就是超討厭做事情的時候因為要接客戶電話而被打斷!
閱讀時間 7 分鐘