2022 小小回顧

分享幾個今年的領會來做個回顧。

《易經》教會我衡量主觀、客觀、時機、演變等道理， 讓我生活、工作中的多事讓我產生很多的省思。

轉到現職時向天地、菩薩卜問的卦－巽卦很好的交代了我的工作內容。

所在單位希望進行雲端化的大工程， 我嘗試幫忙在維護為主的組織文化中引領一群 Junior 挑戰 研發 任務， 在 團隊合作、成員培養、技術探勘、學習、舊AP的底層技術破解、人員招募 等方面都有著巽卦的寓意表現， （這部分也讓我曾被前同事說過很像 龍 的特點） 其中特別想分享的是我在 人員招募、團隊合作、技術學習方面 等方面在思維層面上的學習， 這些體驗的描述通常不會侷限在 單一觀點 或是限制在 單一層面， 造成不好理解的地方請多見諒。

招募

這年我幫忙招募在 104 上看過了非常多的履歷，以及進行了不下 30 場面試面談，調整過數次我的面試面談的進行方式與提問內容。 首先我想分享的是：

你的 104 履歷被看過，不太表用人單位真的有興趣

原因很簡單：招募人員可以都先點開後續慢慢挑，下次查詢用「只看未讀」來過濾。 也因此常有人說 「104 的履歷可以關閉一陣子，微調內容再開，可能有新機會」的成因。 （當然，有時間的單位可以做個爬蟲去撈，分析內容關鍵字來省事）

履歷內容的評估

引申出履歷內容最好要有：

• 深度（如 心智圖可以展開數層）。
• 將經歷 抽象化 的主要敘述，經歷成為 use case。
• 人格特質。（特別的心得、成就、行為慣性）

不知道各家資方除了技術關鍵字之外還會下什麼千奇百怪的… （認真、負責、抗壓、…） 但懶得寫請出、不擅長寫的人還是居多， 其次是寫不到重點（檢討中~）。

特別的是，若能將思維脫離「讓人知道我」轉移到「針對需求去寫」那就神了。

「過去績效不代表未來之表現」

半年前我對 適才適所 很不以為然，半年後我信了。

『適才適所』 這句話其實囊括了 主客觀 雙重因素去配合的， 正如《易經》 64 卦的 上下卦、7 habits 的 雙贏思維、知彼解己 的概念。

眼前履歷上很強的高手其實是借助先前經歷中「天時地利人和」造就的 英雄， 能力方面可能很高機率合適， 但在團隊合作、作業模式、文化 等方面很高機會不合適。

• 「合適」的定義這仍有盲點，維護經驗好不代表無痛轉 研發
• 對外應用系統 的技能需求 不等於 內部應用系統的經驗
• AP 經驗 不等於 打造基礎底層的能力

端看用人單位要的是什麼， 要 資質 代表要花成本培養型塑成理想人才， 要 即戰力 就必須先對自身需求做過分析後再開始。 （分析構想部分暫時偷懶）

各項離職原因、經歷空白、選擇 Offer 的三大評估因素 必須交代清楚

較多意義是要觀察「你是什麼樣的人」。 延伸問題像是「最近做了什麼樣的學習？」、「有興趣的技術議題」… （秉持的現場面談方式的面試則會進一步觀察行為語言、衣著、說話方式、…）

另外就是要看「坦承、誠懇」， 有應徵者會去過度包裝離職原因（或是草草帶過）， 或是 隱藏 「選擇 Offer 的三大評估因素」， 相信我，只要是有相當經驗的面試官都能辨識出來的。（剩下的就是各自的盤算）

于美人：「人生沒有用不到的經歷」

經歷空白方面，只要你不是 尼特族 就會做點什麼， 剩下的是在「職能上」、「個人能力」延伸累積， 若暫時還看不到關聯價值的話則應徵者較吃虧。

各式各樣的測驗

淺顯的看法是 考線上題庫的方式得到有特定方面能力的人才， 通常要輔以其他面試搓合方式去評估， 當然也要看職缺內容是否與優化演算法、優化效能直接相關。

相對的，普遍成本較低的做法要在 1-2 小時內就要判斷， 用基礎實作題 + CodeReview 來幫忙過濾會是個不錯的辦法。

我買了3本刷題庫的書籍學習的感想是－這個測驗方式應該快失效了吧。 我的面談經驗中曾刷掉了 Leetcode 解不少 Hard 的應徵者， 原因是

• 實作題 的 coding style 顯得沒有質量（特別是AP開發經驗方面）。
• 面談 Q&A 對於架構、系統層面的理解凸顯出 見樹不見林 盲點的學習理解方式。

其他考智力測驗、國中英文、性向測驗的方式就看應徵者接不接受了， 假如該公司面試官夠有經驗， 是可以嘗試從履歷、Q&A中取得線索的， 將這樣的成本轉嫁到應徵者身上去的作法可能是希望貫徹「客觀數據化」的文化。 （考題庫的做法也屬於此）

品格 應優先於 能力

面試最終是希望將人才放到工作中賦予任務， 期望能有特殊表現 或是 確實解決工作， 這個階段從管理者角度去看這名員工的觀點會漸轉為：

• 遇到障礙難題會做什麼？怎麼做？
• 溝通中表達一句話 會怎麼說？

這也是應該面試注意找線索的點， 同時是應徵者履歷中應該表現出的亮點之一。

比方說，爭取加薪會怎麼做？

團隊合作

我很喜歡跟夥伴們一起做事的感覺， 從確認規格、設計、程式架構準備、Coding、自動測試、源碼掃描、CI/CD.. 各方面分工， 也很喜歡 Scrum 適合的 僕人式領導。 也許我該參考學習高階管理者的用人方式。

技術

（從招募過程中透過 Q&A 我也學了些技術觀念）

我協助單位在沒有詳細規格書、source code 的狀況下， 對運作10多年底層工具的關鍵技術做了理解上的破解， 率先完成了初版的實作驗證。

先前是對維護開發品質的破譯讓我再學習了《孫子兵法》、軟體工程、行為心理等知識， 這次的技術破解則是廣泛對 分布式系統、原子操作、高併發 等知識做了學習， 也應用在 招募的面談中。

年底時我針對這個技術又提出了破壞性的創新做法， 約等於是一項機制、算法等級， 實現了我內心深處對此技術總能再簡化的一個「感覺」。

另方面， 我在 1個月內初次學習 C# 並建構 Generic 程式架構、Generic Unit Test， 目的是在不妨礙業務使用的條件下便於團隊成員協力、省力開發， 將複雜的改寫工作轉化為簡單的機械動作。