幾個關於當面試官的趣事記錄 年輕真好 有個約3-4年工作經驗待業近半年的年輕人主動應徵， 當我初步簡介職缺的工作內容提到： 這個工作會需要些程式架構、系統架構設計… 應徵者隨即脫口說： 完蛋了，這次我一定沒機會… 好羨慕這樣純真年輕的心態。 我也給予很多鼓勵、建議。 「我嚮往研發的工作…」 接觸過幾個在現職崗位上表現得非常得心應手的傑出人才， 離職原因是想挑戰更多研發類型任務， 但也由於工作經歷上較缺相關經驗， 使得應聘方只能以實作題、白板題 等 Q&A 方式來進一步確認， 但取得的「情報」會偏向能力、個人特質， 老實說這在專業人資角度看是非常有風險的。 曾在急中生智提出了這樣的試探問題： 「通常你怎麼使用 Google 查詢課題/障礙？」 我得到了非常有自信的答案： 「我通常只看搜尋結果的第一頁，這是關聯度最高、最有價值的…」 「我會請教其他資深同仁，再嘗試其他關鍵字」 認真輸一半？ 看著許多履歷內容常注意到， 許多認真為公司、崗位付出的人才因為工作內容較為相似， 在履歷文件上卻著實遠遠輸給刻意規劃職涯的人選。 若投身於維護類型工作最好要找些亮點出來（如 品質、速度、…）， 否則光在技能就被屌打。 當然，職涯規劃雕琢過的不見得符合需求方的要求。 易經 - 火山賁 當面試到這樣的人選時， 常替認真做事的人感到不值， 越能感到長輩說得對： 慎選產業、公司

Bloom Filter 布隆過濾器：「不存在 為可確定，存在 為＂可能＂」 聽朋友聊到 Bloom Filter 布隆過濾器覺得有趣， 做了點調查。 這篇文章說明得較清楚： 深入浅出BloomFilter原理 - 刘训灼的文章 - 知乎 由於 Bloom Filter 的原理特性 使得「不存在 為可確定，存在 為＂可能＂」， 存在可以推的（可控的）誤判率， 因此合適其優勢的情境有些特徵，如： 大數據 下 希望運用類 Hash 來過濾，希望避免 Hash 衝突 合適的 二元向量 數量 合適的 Hash function 數量 特別好奇於把一個對其＂存在＂具有一定誤判率的東西， 拿來用在「判断一个元素是否在集合中」的方式… 頗有趣的可以強調 正面用、反面用。 「不存在為確定」特性 緩存穿透 的攻擊，優先排除掉 不合規Key 的 request 訪問。 延伸課題：緩存做水平擴展、熱點調教、… 運用「存在判斷有可控極低的誤判率」特性 爬蟲過濾掉疑似曾經訪問過的 URL。（代價是可能少抓到頁面） 特殊運用： 資料採集之：巧用布隆過濾器提取資料摘要 Reference 什么是缓存雪崩、缓存击穿、缓存穿透？ - java技术爱好者的文章 - 知乎 什么是缓存雪崩、击穿、穿透？ 布隆过滤器与布谷鸟过滤器 - 终端研发部的文章 - 知乎 硬核 | Redis 布隆（Bloom Filter）过滤器原理与实战 - 码哥字节的文章 - 知乎

2022 小小回顧 分享幾個今年的領會來做個回顧。 《易經》教會我衡量主觀、客觀、時機、演變等道理， 讓我生活、工作中的多事讓我產生很多的省思。 轉到現職時向天地、菩薩卜問的卦－巽卦很好的交代了我的工作內容。 所在單位希望進行雲端化的大工程， 我嘗試幫忙在維護為主的組織文化中引領一群 Junior 挑戰 研發 任務， 在 團隊合作、成員培養、技術探勘、學習、舊AP的底層技術破解、人員招募 等方面都有著巽卦的寓意表現， （這部分也讓我曾被前同事說過很像 龍 的特點） 其中特別想分享的是我在 人員招募、團隊合作、技術學習方面 等方面在思維層面上的學習， 這些體驗的描述通常不會侷限在 單一觀點 或是限制在 單一層面， 造成不好理解的地方請多見諒。 招募 這年我幫忙招募在 104 上看過了非常多的履歷，以及進行了不下 30 場面試面談，調整過數次我的面試面談的進行方式與提問內容。 首先我想分享的是： 你的 104 履歷被看過，不太表用人單位真的有興趣 原因很簡單：招募人員可以都先點開後續慢慢挑，下次查詢用「只看未讀」來過濾。 也因此常有人說 「104 的履歷可以關閉一陣子，微調內容再開，可能有新機會」的成因。 （當然，有時間的單位可以做個爬蟲去撈，分析內容關鍵字來省事） 履歷內容的評估 引申出履歷內容最好要有： 深度（如 心智圖可以展開數層）。 將經歷 抽象化 的主要敘述，經歷成為 use case。 人格特質。（特別的心得、成就、行為慣性） 不知道各家資方除了技術關鍵字之外還會下什麼千奇百怪的… （認真、負責、抗壓、…） 但懶得寫請出、不擅長寫的人還是居多， 其次是寫不到重點（檢討中~）。 特別的是，若能將思維脫離「讓人知道我」轉移到「針對需求去寫」那就神了。 「過去績效不代表未來之表現」 半年前我對 適才適所 很不以為然，半年後我信了。 『適才適所』 這句話其實囊括了 主客觀 雙重因素去配合的， 正如《易經》 64 卦的 上下卦、7 habits 的 雙贏思維、知彼解己 的概念。...

現職崗位有機會接觸代表不同 Cloud Service Provider 的顧問服務， 他們各自對自家服務產品都很熟稔、很專業， 但對於客製化上雲需求的課題卻顯得較輕忽。 以實際經驗來說， 公司其他單位窗口詢問 AWS 顧問關於轉換地端 Database 資料上雲端的解決方案， 僅得到回答:「版本太舊…」 我與同事早早有解決方案 x 2… 另外是曾經詢問 Azure 顧問關於權限設定問題， 最後是 代理商 業務細心、耐心幫忙解答。 該顧問參與幾次會議老欠調查進度後消失 模仿一點點市場分群分析， 假設三大 Cloud Service Provider 都希望爭取更多人使用雲服務， （也許可以找到市調/問卷資料進一步分析） 較容易爭取的、需求較為普遍的客群 應有相當程度地成為使用者，（紅海） 剩下的客群假設有預算但上雲需求有遇到難度的， 這類生意做不做？ 我們確實也遇到這樣的案例， Google 代表做了許多 POC 承諾（業務面 domain knowhow 還沒掌握的狀況下）， 還真的用 Google AppSheet 爭取到案子。 過程真的替他捏把汗， 看得出來對於系統架構面的專才， 但是很疏於透過 Q&A 去抽絲剝繭梳理 業務面進一步需求， 或是利用一些設計方法來確認客戶需求。 或許扮演這樣角色的職缺會由其他代理商、軟體服務公司的「雲端解決方案架構師」以 POC 驗證型專案來銜接？