兩年經(jīng)驗(yàn)，盡然斬獲多家巨頭offer，如：螞蟻、頭條、PingCAP~

• 反思：自己是不是真的要離職，假如不離職，在老東家接下來應(yīng)該做什么才能繼續(xù)提升？

• 定位：我在硬性技能（編碼、架構(gòu)）上的長(zhǎng)處在哪？我在軟技能（溝通，團(tuán)隊(duì)）上的長(zhǎng)處在哪？這步順帶寫了簡(jiǎn)歷

• 尋找平臺(tái)：哪些平臺(tái)能同時(shí)滿足：1、有挑戰(zhàn)有上升空間；2、符合我的定位方向；3、團(tuán)隊(duì)氛圍和老東家一樣好（或更好）

• 找人內(nèi)推：基本都是在 v2 上找的（誠(chéng)摯感謝各位幫助我內(nèi)推的大佬）

• 面試談 offer

• 對(duì)于一個(gè)畢業(yè)兩年多的人，我最希望他有什么特質(zhì)？這個(gè)階段的人其實(shí)還是“空杯”，我希望他有很強(qiáng)的學(xué)習(xí)能力和進(jìn)取心，給自己部門培養(yǎng)出一個(gè)超級(jí)生產(chǎn)力；
• 什么樣的行為會(huì)讓我“討厭一份簡(jiǎn)歷”：把每個(gè)項(xiàng)目都大寫特寫，尤其是陳述細(xì)節(jié)沒有重點(diǎn)；羅列框架當(dāng)能力，用過了一類場(chǎng)景的框架就覺得能解決一類業(yè)務(wù)諸如此類；
• 面試的時(shí)候我會(huì)偏向于問哪些問題？一是簡(jiǎn)歷上寫了“理解”或“精通”的語言與中間件；二是簡(jiǎn)歷上寫得比較有趣，又沒有完全交代清楚的項(xiàng)目。

• 螞蟻 - 容器調(diào)度方向（CTO線）

• 頭條 - 工程效能方向

• PingCAP - Cloud 方向

• 介紹一下自己。

• 問項(xiàng)目經(jīng)歷，聊“數(shù)據(jù)同步”。

• 接著聊上了 Kubernetes 的項(xiàng)目。

• 有沒有什么鉆研得比較深得技術(shù)？（我：Kubernetes，Golang，Prometheus，Java）

• Kubernetes 的架構(gòu)是怎么樣的?

  這個(gè)問題很大，拆成 apiserver、controller、kubelet、scheduler 講了一下。

• Golang 與 Java 的比較。

  這個(gè)問題又很大，當(dāng)時(shí)主要對(duì)比了 VM、協(xié)程支持、面向?qū)ο蠛头盒偷膮^(qū)別、以及自己對(duì)各自使用場(chǎng)景的一些理解。

• Golang 的 gc 算法。

  知道是三色標(biāo)記，不過細(xì)節(jié)說不上來。

• 從無限的字符流中，隨機(jī)選出 10 個(gè)字符。

  沒見過也沒想出來，查了一下是蓄水池采樣算法，經(jīng)典面試題，沒刷題吃虧了。

• 怎么擴(kuò)展 kubernetes scheduler，讓它能 handle 大規(guī)模的節(jié)點(diǎn)調(diào)度？

  單節(jié)點(diǎn)提速：優(yōu)選階段隨機(jī)取部分節(jié)點(diǎn)進(jìn)行優(yōu)選；水平擴(kuò)展 scheduler 節(jié)點(diǎn)，Pod 做一致性 hash 來決定由哪個(gè) scheduler 調(diào)度。

• 你有什么想問我的？

• 先聊了聊項(xiàng)目。

• 給 Prometheus 做了哪些改動(dòng)？

• 自研配置中心，具體做了哪些內(nèi)容？

• 有用過 MySQL 的什么高級(jí)特性嗎？

  這里不太理解，我問什么算高級(jí)特性，面試官就切換到了下一個(gè)問題。

• 配置中心的核心數(shù)據(jù)表是怎么設(shè)計(jì)的？

• 為什么在業(yè)務(wù)里用 Redis，Redis 有什么優(yōu)點(diǎn)？

  單線程：并發(fā)安全；高性能；原語與數(shù)據(jù)結(jié)構(gòu)豐富；采用廣泛，踩坑成本低。

• 對(duì) Redis 里數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn)熟悉嗎？

  說了一個(gè) zset 跳表。

• 用過 Redis 的哪些數(shù)據(jù)結(jié)構(gòu)，分別用在什么場(chǎng)景？

• Java 初始化一個(gè)線程池有哪些參數(shù)可以配置，分別是什么作用？

• 自己寫的 Java 應(yīng)用調(diào)優(yōu)過哪些 JVM 參數(shù)，為什么這么調(diào)優(yōu)？

  這個(gè)問住了，我只知道最大堆最小堆，開 G1，開 GC 日志以及 OOM dumper 這些基本的。

• 用 Jetty 的時(shí)候有沒有配什么參數(shù)，為什么這么配？

• Jetty QTP 等待隊(duì)列配置成無限的話，你覺得好嗎？會(huì)有什么問題嗎？

• 用過 Linux Bash 里的哪些命令，分別用它們干嘛？

• 一道筆試題：需要在給的鏈接中作答，不能 Google，不能跳出, 不能用 IDE。

• 依然先聊項(xiàng)目。

• 對(duì)監(jiān)控警報(bào)的項(xiàng)目很感興趣，問了挺多細(xì)節(jié)，最后問了一個(gè)問題：現(xiàn)在要你實(shí)現(xiàn)一個(gè)語義不弱于 PromQL 的查詢語言，你能實(shí)現(xiàn)嗎？

  這里雖然看過一些 Prometheus 的代碼，但其實(shí)對(duì) PromQL 的 lexer 和 parser 部分沒有細(xì)看，還好之前因?yàn)閿?shù)據(jù)同步項(xiàng)目里想寫聲明式 Stream SQL 研究過一點(diǎn) ANTLR，用 ANTLR 寫語法 + AST 遍歷塞查詢邏輯給糊弄過去了。

• 問我覺得做得最深入的項(xiàng)目是什么？

  當(dāng)然是數(shù)據(jù)同步（狗頭）。

• 聊數(shù)據(jù)同步項(xiàng)目（這個(gè)很符合我的預(yù)期，哈哈哈哈）。

• 問 Linux 掌握得怎么樣？

  沒有系統(tǒng)學(xué)習(xí)過，基本上是自己運(yùn)維踩坑積累的。

• 問 Golang 掌握得怎么樣？

  用了半年，看過 effective go。

• 問算法掌握得怎么樣？

  到圖為止都可以。

• 問最短路算法。

  只記得 Dijkstra 了，描述了代碼流程。

• Kubernetes 掌握得怎么樣?

  不怎么樣，沒有自己寫過 controller 和 scheduler，但是對(duì)概念都很熟悉，看過 xxx 這幾部分的源碼。

• Kubernetes 的 exec 是怎么實(shí)現(xiàn)的?

  這個(gè)問題正中下懷，之前寫了 PingCAP 的小作業(yè)正好對(duì)這塊特別熟悉。

• 介紹一下自己。

• 覺得自己基礎(chǔ)知識(shí)掌握怎么樣？

• 平時(shí)一般會(huì)用到哪些數(shù)據(jù)結(jié)構(gòu)？

• 鏈表和數(shù)組相比，有什么優(yōu)劣？

• 如何判斷兩個(gè)無環(huán)單鏈表有沒有交叉點(diǎn)？

• 如何判斷兩個(gè)有環(huán)單鏈表有沒有交叉點(diǎn)？

• 如何判斷一個(gè)單鏈表有沒有環(huán)，并找出入環(huán)點(diǎn)？

• TCP 和 UDP 有什么區(qū)別？

• 描述一下 TCP 四次揮手的過程中 TCP 有哪些狀態(tài)？

• TCP 的 LISTEN 狀態(tài)是什么？

• TCP 的 CLOSE_WAIT 狀態(tài)是什么？

• 建立一個(gè) socket 連接要經(jīng)過哪些步驟？

• 常見的 HTTP 狀態(tài)碼有哪些？

• 301 和 302 有什么區(qū)別？

• 504 和 500 有什么區(qū)別？

• HTTPS 和 HTTP 有什么區(qū)別？

• 寫一個(gè)算法題：手寫快排。

• 介紹一下自己。

• 在 Kubernetes 上做過哪些二次開發(fā)?

• 自己用 Helm 構(gòu)建過 chart 嗎？有哪些？

• 有沒有考慮過自己封裝一個(gè)面向研發(fā)的 PaaS 平臺(tái)？

• 配置中心做了什么？

• 為什么不用 ZooKeeper？

• 配置中心如何保證一致性？

• Spring 里用了單例 Bean，怎么保證訪問 Bean 字段時(shí)的并發(fā)安全？

  用并發(fā)安全的數(shù)據(jù)結(jié)構(gòu)，比如 ConcurrentHashMap；或者加互斥鎖。

• 假如我還想隔離兩個(gè)線程的數(shù)據(jù), 怎么辦？

  ThreadLocal，然后舉了個(gè)例子。

• Golang 里的逃逸分析是什么？怎么避免內(nèi)存逃逸？

  這個(gè)不知道，認(rèn)慫了。

• 對(duì)比一下 Golang 和 Java 的 GC。

  答了一下 CMS、G1和三色標(biāo)記，我對(duì)比的點(diǎn)是 JVM 有分代回收，Go 的 Runtime 沒有，沒能深入地講。

• Golang 的 GC 觸發(fā)時(shí)機(jī)是什么？

  閾值觸發(fā)；主動(dòng)觸發(fā)；兩分鐘定時(shí)觸發(fā)。

• 有沒有寫過 Kubernetes 的 Operator 或 Controller？（我：沒有寫過）

• 談一談你對(duì)微服務(wù)架構(gòu)的理解。

  大體思路“微服務(wù)本質(zhì)是人員組織架構(gòu)演進(jìn)與關(guān)注點(diǎn)分離”。

• 談一談你對(duì) Serveless 的理解

  大體思路“Serverless 是繼 Docker 與容器編排之后的又一次應(yīng)用開發(fā)與基礎(chǔ)設(shè)施提供方之間的邊界劃分”。

• 你認(rèn)為 Serverless 是未來嗎？為什么？

  大體思路“是云服務(wù)的未來，把蛋糕從企業(yè)的IT、運(yùn)維與中間件部門切走，形成規(guī)模效應(yīng)，做得越多賺得越多；公司內(nèi)的話 Serverless 能夠幫助加速前臺(tái)業(yè)務(wù)迭代，但對(duì)中后臺(tái)的收益還看不到，未來可能會(huì)有比 Serverless 更適合中后臺(tái)的架構(gòu)”。

• 面試官：最后你有什么要問我的？

• 我：為什么足足安排了五輪技術(shù)面，而且其中有兩輪似乎和 Kubernetes 沒有關(guān)系??？

• 面試官：我們覺得你做過的東西挺多的，各個(gè)方向都想讓你嘗試一下（我的內(nèi)心：……）。

• 我：那這輪是最后一輪技術(shù)面嗎？

• 面試官：不一定（我的內(nèi)心：……）。

• 問經(jīng)歷。

• 為什么要考慮出來看看呢？

  金句：”現(xiàn)在自己的技術(shù)成長(zhǎng)有點(diǎn)碰到瓶頸，加上一直對(duì)您公司欽慕有加”

• 現(xiàn)在公司的主營(yíng)業(yè)務(wù)是什么？（這塊往技術(shù)上問了很多，感覺是想考察我解釋復(fù)雜問題的能力）

• 現(xiàn)在帶人嗎？report 層級(jí)是怎樣的？

• 對(duì)自己這幾年的經(jīng)歷滿意嗎？

• 覺得自己有什么缺點(diǎn)？

• 碰到過什么很挫敗的事情嗎？

• 未來的職業(yè)規(guī)劃是怎樣的？

• 看機(jī)會(huì)的時(shí)候，主要考慮的是待遇、平臺(tái)、人員還是什么其他因素？

• 現(xiàn)在的待遇如何？

• 有什么想問我的？

• 面試難度：正常

• 面試體驗(yàn)：正常

• 問題偏向：基礎(chǔ)知識(shí)，開發(fā)常識(shí)，技術(shù)見解

• 問項(xiàng)目，抓出一些你擅長(zhǎng)的領(lǐng)域或場(chǎng)景

• 問系統(tǒng)設(shè)計(jì)題，每題都會(huì)不斷深化需求讓你應(yīng)變和權(quán)衡

• 問一道算法題(不難不偏)，先看思路，再要求寫一下偽代碼看邊界條件能不能一次過

• 介紹一下自己，為什么選擇出來看看機(jī)會(huì)？

• 聊項(xiàng)目，警報(bào)怎么做的，統(tǒng)一接入監(jiān)控項(xiàng)怎么做的？

• 聊項(xiàng)目，配置中心項(xiàng)目，問實(shí)時(shí)配置推送怎么做？

• 討論為什么選擇所有的組件依賴放在配置中心中控制？

• 我現(xiàn)在要做一個(gè)限流功能，怎么做？

  令牌桶。

• 這個(gè)限流要做成分布式的，怎么做？

  令牌桶維護(hù)到 Redis 里，每個(gè)實(shí)例起一個(gè)線程搶鎖，搶到鎖的負(fù)責(zé)定時(shí)放令牌。

• 怎么搶鎖？

  Redis setnx。

• 鎖怎么釋放？

  搶到鎖后設(shè)置過期時(shí)間，線程本身退出時(shí)主動(dòng)釋放鎖，假如線程卡住了，鎖過期那么其它線程可以繼續(xù)搶占。

• 加了超時(shí)之后有沒有可能在沒有釋放的情況下，被人搶走鎖

  有可能，單次處理時(shí)間過長(zhǎng)，鎖泄露。

• 怎么解決？

  換 ZooKeeper，用心跳解決。

• 不用 ZooKeeper 的心跳，可以怎么解決這個(gè)問題呢？

  每次更新過期時(shí)間時(shí)，Redis 用 MULTI 做 check-and-set 檢查更新時(shí)間是否被其他線程修改了，假如被修改了，說明鎖已經(jīng)被搶走，放棄這把鎖。

• 假如這個(gè)限流希望做成可配置的，需要有一個(gè)后臺(tái)管理系統(tǒng)隨意對(duì)某個(gè) API 配置全局流量，怎么做？

  在 Redis 里存儲(chǔ)每個(gè) API 的令牌桶 key，假如存在這個(gè) key，則需要按上述邏輯進(jìn)行限流。

• 某一個(gè)業(yè)務(wù)中現(xiàn)在需要生成全局唯一的遞增 ID，并發(fā)量非常大，怎么做？

  snowflake（這個(gè)其實(shí)答得不好，snowflake 無法實(shí)現(xiàn)全局遞增，只能實(shí)現(xiàn)全局唯一，單機(jī)遞增，面試結(jié)束后就想到了類似 TDDL 那樣一次取一個(gè) ID 段，放在本地慢慢分配的策略）。

• 算法題，M*N 橫向縱向均遞增的矩陣找指定數(shù)？

  只想到 O(M+N) 的解法，補(bǔ)充：這幾天刷 leetcode 碰到這題了，240. Search a 2D Matrix II[4]，辦法是從左下角或右下角開始查找。

• 有什么想問我的？

• 平時(shí)用的工具鏈和技術(shù)棧是什么？

• Golang 踩過坑嗎？

  答了之前 PingCAP 面試時(shí)面試官問的 for-range 里的 go-routine 閉包捕獲問題。

• 這段 Golang 代碼有沒有 bug（還是一個(gè) for-range 的坑）？

  有 bug，for-range 的 value 引用拷貝問題。

• Java 中 HashMap 的存儲(chǔ)，沖突，擴(kuò)容，并發(fā)訪問分別是怎么解決的？

  Hash 表，拉鏈法（長(zhǎng)度大于8變形為紅黑樹），擴(kuò)容*2 rehash，并發(fā)訪問不安全。

• 拉鏈法中鏈表過長(zhǎng)時(shí)變形為紅黑樹有什么優(yōu)缺點(diǎn)？

  優(yōu)點(diǎn)：O(LogN) 的讀取速度更快；缺點(diǎn)：插入時(shí)有 Overhead，O(LogN) 插入，旋轉(zhuǎn)維護(hù)平衡。

• HashMap 的并發(fā)不安全體現(xiàn)在哪？

  拉鏈法解決沖突，插入鏈表時(shí)不安全，并發(fā)操作可能導(dǎo)致另一個(gè)插入失效。

• HashMap 在擴(kuò)容時(shí)，對(duì)讀寫操作有什么特殊處理？

  不知道。

• ConcurrentHashMap 是怎么做到并發(fā)安全的？

  segment 分段鎖。

• Java 有哪些鎖機(jī)制，分別有什么特點(diǎn)？

  Synchronized、可重入鎖。

• 知道 CAS 嗎？Java 中 CAS 是怎么實(shí)現(xiàn)的？

  Compare and Swap，一種樂觀鎖的實(shí)現(xiàn)，可以稱為“無鎖”（lock-free），CAS 由于要保證原子性無法由 JVM 本身實(shí)現(xiàn)，需要調(diào)用對(duì)應(yīng) OS 的指令（這塊其實(shí)我不了解細(xì)節(jié)）。

• MySQL 的存儲(chǔ)引擎用的是什么？（InnoDB）為什么選 InnoDB？

  幾乎所有公司用 MySQL 都用 InnoDB，降低踩坑成本；聚簇索引，MVCC。

• MySQL 的聚簇索引和非聚簇索引有什么區(qū)別？

  聚簇索引的葉子節(jié)點(diǎn)是數(shù)據(jù)節(jié)點(diǎn)（比如定義了主鍵時(shí)的主鍵索引），非聚簇索引葉子節(jié)點(diǎn)是指向數(shù)據(jù)塊的指針。

• B+樹和二叉樹有什么區(qū)別和優(yōu)劣？

  B+樹是多叉樹，深度更小，B+樹可以對(duì)葉子節(jié)點(diǎn)進(jìn)行順序遍歷，B+樹能夠更好地利用磁盤扇區(qū)；二叉樹：實(shí)現(xiàn)簡(jiǎn)單。

• 針對(duì)一個(gè)場(chǎng)景設(shè)計(jì)索引，具體場(chǎng)景忘記了，反正考察的是聯(lián)合索引與列選擇性的知識(shí)。

• 現(xiàn)有一個(gè)新的查詢場(chǎng)景, 要怎么解決？

• 假如要查 A in () AND B in (), 怎么建索引？

  只給選擇性高的一列建索引，這里因?yàn)閮蓚€(gè)都是范圍查詢所以另一個(gè)是走不到索引的（這里答的不好，其實(shí)也可以建聯(lián)合索引然后用 （A,B) in ((1,2),(3,4)) 的方式去查）。

• 查 A in () AND B in () 時(shí)，MySQL 是怎么利用索引的？

  先走一個(gè)非聚簇索引，查詢出行數(shù)據(jù)后再用另一列回表做篩選。

• 假如查詢 A in ()，MySQL 是針對(duì) N 個(gè)值分別查一次索引，還是有更好的操作？

  不知道，有了解的同學(xué)可以留言（補(bǔ)充，@BillyLu 貼出了文檔 equality-range-optimization[5]，大意是對(duì)非唯一索引 MySQL 會(huì)使用 index dive 的方式估算這個(gè) range index 涉及的行數(shù)，結(jié)合 where optimization[6] 中說明的在走 index 時(shí)假如涉及行數(shù)過多會(huì)走 full table scan，那么假如 estimation 認(rèn)為這次 IN 不夠好，是會(huì)走全表掃描的。不知道除此之外，面試官還有沒有想考察的點(diǎn)）。

• 用過 Redis 的哪幾種數(shù)據(jù)結(jié)構(gòu)？（都用過）ZSET 是怎么實(shí)現(xiàn)的？

  跳表。

• zrange start，stop，總長(zhǎng)度為 n，復(fù)雜度是多少？

  O(logN)（答得不好，實(shí)際是 O(M+log(N))， M 是結(jié)果集基數(shù) stop-start）。

• Kafka 的消費(fèi)者如何做消息去重？

  MySQL 去重、Redis 去重、假如場(chǎng)景量極大且允許誤判，布隆過濾器也可以。

• 介紹一下 Kafka 的 ConsumerGroup

  挺長(zhǎng)的，略。

• Kubernetes 和 Docker 用得怎么樣？（我：在公司推行布道）

• 給它們貢獻(xiàn)過代碼嗎？（我：沒有……）

• 時(shí)序型數(shù)據(jù)庫(kù)的存儲(chǔ)結(jié)構(gòu)是怎么樣的？

  講了 Prometheus 1.x 和 2.x 的存儲(chǔ)結(jié)構(gòu)。

• LSM 樹了解嗎？是一種什么存儲(chǔ)結(jié)構(gòu)？

  Log-Structured Merge Tree，犧牲讀性能換取性能，RocksDB、HBase、Cassandra 都在用，結(jié)構(gòu)有點(diǎn)忘了，只說了先寫 memtable 再刷盤成 sstable。

• 在生產(chǎn)中用過 Cassandra 和 RocksDB 嗎？量有多大？

  用過，Cassandra 存調(diào)用鏈，RocksDB 做 flink 和 Kafka Stream 的本地狀態(tài)存儲(chǔ)。

• Cassandra 的墓碑機(jī)制是什么?

  不知道，對(duì) Cassandra 停留在使用階段。

• 聊項(xiàng)目和工作經(jīng)驗(yàn)。

• 用 Kubernetes 的過程中踩過哪些坑？

• 考慮一個(gè)業(yè)務(wù)場(chǎng)景：頭條的文章的評(píng)論量非常大，比如說一篇熱門文章就有幾百萬的評(píng)論，設(shè)計(jì)一個(gè)后端服務(wù)，實(shí)現(xiàn)評(píng)論的時(shí)序展示與分頁。

  我：需不需要支持頁碼直接跳轉(zhuǎn)？

  面試官：支持和不支持兩種場(chǎng)景都考慮一下。

  我：不需要支持頁碼翻頁就傳評(píng)論 id 用 offset 翻頁

• 假如用 id 翻頁的方式，數(shù)據(jù)庫(kù)表如何設(shè)計(jì)？索引如何設(shè)計(jì)？

  （文章id，評(píng)論id）建聯(lián)合索引，評(píng)論 id 需遞增。

• 假如量很大，你覺得需要分庫(kù)分表嗎？怎么分？

  需要分，分表有個(gè)權(quán)衡，按文章 id 分表，讀邏輯簡(jiǎn)單，但寫有熱點(diǎn)問題；按評(píng)論 id 分表，讀邏輯復(fù)雜，但寫壓力就平均了。寫是要首先保證的，而讀總是有緩存等方案來折中，因此按評(píng)論 id 分表好。

• 分庫(kù)分表后怎么查詢分頁？

  每張表查 N 條數(shù)據(jù)由 client 或 proxy merge。

• 分庫(kù)分表后怎么保證主鍵仍然是遞增的?

  講了 TDDL 的辦法：有一張專門用于分配主鍵的表，每次用樂觀鎖的方式嘗試去取一批主鍵過來分配，假如樂觀鎖失敗就重試。

• 現(xiàn)在需要支持深分頁，頁碼直接跳轉(zhuǎn)，怎么實(shí)現(xiàn)？

  不能做精準(zhǔn)深分頁，否則壓力太大，找產(chǎn)品進(jìn)行妥協(xié)，在 50 或 100 頁后數(shù)據(jù)分頁是否可以不完全精確，假如可以，那么緩存深頁碼的起始評(píng)論 id。

• 瞬時(shí)寫入量很大可能會(huì)打掛存儲(chǔ)，怎么保護(hù)？

  斷路器。

• 斷路器內(nèi)部怎么實(shí)現(xiàn)的？

  可以用 ringbuffer。

• 斷路器會(huì)造成寫入失敗，假如我們不允許寫入失敗呢？

  先寫進(jìn)消息隊(duì)列，削峰填谷異步落庫(kù)。

• 算法題：N 場(chǎng)演唱會(huì)，以 [{startTime, endTime}…] 的形式給出，計(jì)算出最多能聽?zhēng)讏?chǎng)演唱會(huì)？

  先講了思路，按 endTime 升序排列，再順序取最多場(chǎng)次。

• （講完思路之后）屏幕共享給我，用你最熟悉的語言把這個(gè)算法實(shí)現(xiàn)

  用 Go 實(shí)現(xiàn)了一版。

• 你用了貪心法，貪心可能會(huì)存在什么問題？

  局部最優(yōu)，在這個(gè)問題里，只能找到一個(gè)可能解，無法找到所有排列方式。

• 面試難度：正常

• 面試體驗(yàn)：挺好

• 問題偏向：架構(gòu)設(shè)計(jì)，算法

PingCAP

• 簡(jiǎn)歷里寫了的項(xiàng)目，以及熟練程度在“掌握”以上的領(lǐng)域與中間件要好好準(zhǔn)備，當(dāng)面試官問你一個(gè)偏門的問題時(shí)，他內(nèi)心其實(shí)也沒希望你能答上來。而當(dāng)面試官問你簡(jiǎn)歷上涉及的問題時(shí)，假如你答不上來，那面試官就覺得這個(gè)人要么是眼界太低，會(huì)了一點(diǎn)就覺得自己掌握了，要么是簡(jiǎn)歷造假在胡吹，這兩種都非常不利；

• 在上一條的基礎(chǔ)上，可以準(zhǔn)備一個(gè)最得意的項(xiàng)目，在簡(jiǎn)歷上和面試過程中引導(dǎo)面試官往這塊聊；

• 面試前心里可以準(zhǔn)備一個(gè)方法論：明確面試官想招怎樣的人有哪些特質(zhì)，在面試過程中努力表現(xiàn)出這些特質(zhì)。這聽起來是句正確的廢話，但面試的過程不可控因素太多，有一個(gè)清晰的目標(biāo)在腦子里能幫你在手足無措時(shí)想到說什么。舉個(gè)例子，有一輪中面試官問我有什么問題時(shí)，我就問貴司的對(duì)應(yīng)崗位會(huì)面臨哪些技術(shù)挑戰(zhàn)（當(dāng)然要先說清楚這不是在質(zhì)疑他們沒有挑戰(zhàn)，只是自己渴望挑戰(zhàn)）。

• System Design Primer，入門架構(gòu)設(shè)計(jì)必看的一篇資料?？赐曛筇嵝炎约菏冀K記得：架構(gòu)設(shè)計(jì)的本質(zhì)是深入理解業(yè)務(wù)場(chǎng)景之后用工程經(jīng)驗(yàn)做出最佳權(quán)衡。面試時(shí)的一個(gè)套路是先提綱挈領(lǐng)地把舍棄什么來換取什么講明白；

• 云原生相關(guān)，Kubernetes Concepts[8] 部分建議再看一遍，源碼部分推薦看 apiserver 中的 CRD 部分與 aggregation layer、kubelet 的 pod 狀態(tài)同步、scheduler 的調(diào)度部分以及 Sample Controller[9] 如何寫一個(gè)自己的 controller

• 語言方面，推薦看書《Effective Go》《Effective Java》，都很薄。這兩本書我是以前看的，面試前沒有專門準(zhǔn)備語言相關(guān)；

• 還有公眾號(hào)互聯(lián)網(wǎng)架構(gòu)師里面的文章，對(duì)我的幫助也挺大的，建議各位好好讀一下；

• 算法相關(guān)，這部分我純鶸，說實(shí)話我覺得大學(xué)里那本教材《數(shù)據(jù)結(jié)構(gòu)與算法分析》就寫得很不錯(cuò)……至于 leetcode，面試前沒有刷過，最近為了練習(xí) Rust 刷了60多題，并沒有碰到面試?yán)锍霈F(xiàn)過的題目，看起來要刷 leetcode 的話就得走量多刷點(diǎn)，刷的少純拼強(qiáng)運(yùn)了；

• Golang for range的坑，有兩輪面試都涉及到了這個(gè)話題，這里貼一下。