兩年經(jīng)驗,盡然斬獲多家巨頭offer,如:螞蟻、頭條、PingCAP~
來源:https://aleiwu.com
分享一篇面經(jīng),作者拿到了 PingCAP,今日頭條的 offer 以及螞蟻金服的口頭 offer。
準(zhǔn)備過程
反思:自己是不是真的要離職,假如不離職,在老東家接下來應(yīng)該做什么才能繼續(xù)提升?
定位:我在硬性技能(編碼、架構(gòu))上的長處在哪?我在軟技能(溝通,團(tuán)隊)上的長處在哪?這步順帶寫了簡歷
尋找平臺:哪些平臺能同時滿足:1、有挑戰(zhàn)有上升空間;2、符合我的定位方向;3、團(tuán)隊氛圍和老東家一樣好(或更好)
找人內(nèi)推:基本都是在 v2 上找的(誠摯感謝各位幫助我內(nèi)推的大佬)
面試談 offer
舉幾個例子,下面都是我在這個過程中考慮過的問題(當(dāng)然只是我自己的喜好):
對于一個畢業(yè)兩年多的人,我最希望他有什么特質(zhì)?這個階段的人其實還是“空杯”,我希望他有很強(qiáng)的學(xué)習(xí)能力和進(jìn)取心,給自己部門培養(yǎng)出一個超級生產(chǎn)力; 什么樣的行為會讓我“討厭一份簡歷”:把每個項目都大寫特寫,尤其是陳述細(xì)節(jié)沒有重點;羅列框架當(dāng)能力,用過了一類場景的框架就覺得能解決一類業(yè)務(wù)諸如此類; 面試的時候我會偏向于問哪些問題?一是簡歷上寫了“理解”或“精通”的語言與中間件;二是簡歷上寫得比較有趣,又沒有完全交代清楚的項目。
接下來就進(jìn)入正題,逐家講一下自己的面試體驗:
螞蟻 - 容器調(diào)度方向(CTO線)
頭條 - 工程效能方向
PingCAP - Cloud 方向
介紹一下自己。
問項目經(jīng)歷,聊“數(shù)據(jù)同步”。
接著聊上了 Kubernetes 的項目。
有沒有什么鉆研得比較深得技術(shù)?(我:Kubernetes,Golang,Prometheus,Java)
Kubernetes 的架構(gòu)是怎么樣的?
這個問題很大,拆成 apiserver、controller、kubelet、scheduler 講了一下。
Golang 與 Java 的比較。
這個問題又很大,當(dāng)時主要對比了 VM、協(xié)程支持、面向?qū)ο蠛头盒偷膮^(qū)別、以及自己對各自使用場景的一些理解。
Golang 的 gc 算法。
知道是三色標(biāo)記,不過細(xì)節(jié)說不上來。
從無限的字符流中,隨機(jī)選出 10 個字符。
沒見過也沒想出來,查了一下是蓄水池采樣算法,經(jīng)典面試題,沒刷題吃虧了。
怎么擴(kuò)展 kubernetes scheduler,讓它能 handle 大規(guī)模的節(jié)點調(diào)度?
單節(jié)點提速:優(yōu)選階段隨機(jī)取部分節(jié)點進(jìn)行優(yōu)選;水平擴(kuò)展 scheduler 節(jié)點,Pod 做一致性 hash 來決定由哪個 scheduler 調(diào)度。
你有什么想問我的?
先聊了聊項目。
給 Prometheus 做了哪些改動?
自研配置中心,具體做了哪些內(nèi)容?
有用過 MySQL 的什么高級特性嗎?
這里不太理解,我問什么算高級特性,面試官就切換到了下一個問題。
配置中心的核心數(shù)據(jù)表是怎么設(shè)計的?
為什么在業(yè)務(wù)里用 Redis,Redis 有什么優(yōu)點?
單線程:并發(fā)安全;高性能;原語與數(shù)據(jù)結(jié)構(gòu)豐富;采用廣泛,踩坑成本低。
對 Redis 里數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)熟悉嗎?
說了一個 zset 跳表。
用過 Redis 的哪些數(shù)據(jù)結(jié)構(gòu),分別用在什么場景?
Java 初始化一個線程池有哪些參數(shù)可以配置,分別是什么作用?
自己寫的 Java 應(yīng)用調(diào)優(yōu)過哪些 JVM 參數(shù),為什么這么調(diào)優(yōu)?
這個問住了,我只知道最大堆最小堆,開 G1,開 GC 日志以及 OOM dumper 這些基本的。
用 Jetty 的時候有沒有配什么參數(shù),為什么這么配?
Jetty QTP 等待隊列配置成無限的話,你覺得好嗎?會有什么問題嗎?
用過 Linux Bash 里的哪些命令,分別用它們干嘛?
一道筆試題:需要在給的鏈接中作答,不能 Google,不能跳出, 不能用 IDE。
啟動兩個線程,一個輸出 1、3、5、7……99,另一個輸出 2、4、6、8……100 最后 STDOUT 中按序輸出 1、2、3、4、5……100依然先聊項目。
對監(jiān)控警報的項目很感興趣,問了挺多細(xì)節(jié),最后問了一個問題:現(xiàn)在要你實現(xiàn)一個語義不弱于 PromQL 的查詢語言,你能實現(xiàn)嗎?
這里雖然看過一些 Prometheus 的代碼,但其實對 PromQL 的 lexer 和 parser 部分沒有細(xì)看,還好之前因為數(shù)據(jù)同步項目里想寫聲明式 Stream SQL 研究過一點 ANTLR,用 ANTLR 寫語法 + AST 遍歷塞查詢邏輯給糊弄過去了。
問我覺得做得最深入的項目是什么?
當(dāng)然是數(shù)據(jù)同步(狗頭)。
聊數(shù)據(jù)同步項目(這個很符合我的預(yù)期,哈哈哈哈)。
問 Linux 掌握得怎么樣?
沒有系統(tǒng)學(xué)習(xí)過,基本上是自己運維踩坑積累的。
問 Golang 掌握得怎么樣?
用了半年,看過 effective go。
問算法掌握得怎么樣?
到圖為止都可以。
問最短路算法。
只記得 Dijkstra 了,描述了代碼流程。
Kubernetes 掌握得怎么樣?
不怎么樣,沒有自己寫過 controller 和 scheduler,但是對概念都很熟悉,看過 xxx 這幾部分的源碼。
Kubernetes 的 exec 是怎么實現(xiàn)的?
這個問題正中下懷,之前寫了 PingCAP 的小作業(yè)正好對這塊特別熟悉。
介紹一下自己。
覺得自己基礎(chǔ)知識掌握怎么樣?
平時一般會用到哪些數(shù)據(jù)結(jié)構(gòu)?
鏈表和數(shù)組相比,有什么優(yōu)劣?
如何判斷兩個無環(huán)單鏈表有沒有交叉點?
如何判斷兩個有環(huán)單鏈表有沒有交叉點?
如何判斷一個單鏈表有沒有環(huán),并找出入環(huán)點?
TCP 和 UDP 有什么區(qū)別?
描述一下 TCP 四次揮手的過程中 TCP 有哪些狀態(tài)?
TCP 的 LISTEN 狀態(tài)是什么?
TCP 的 CLOSE_WAIT 狀態(tài)是什么?
建立一個 socket 連接要經(jīng)過哪些步驟?
常見的 HTTP 狀態(tài)碼有哪些?
301 和 302 有什么區(qū)別?
504 和 500 有什么區(qū)別?
HTTPS 和 HTTP 有什么區(qū)別?
寫一個算法題:手寫快排。
介紹一下自己。
在 Kubernetes 上做過哪些二次開發(fā)?
自己用 Helm 構(gòu)建過 chart 嗎?有哪些?
有沒有考慮過自己封裝一個面向研發(fā)的 PaaS 平臺?
配置中心做了什么?
為什么不用 ZooKeeper?
配置中心如何保證一致性?
Spring 里用了單例 Bean,怎么保證訪問 Bean 字段時的并發(fā)安全?
用并發(fā)安全的數(shù)據(jù)結(jié)構(gòu),比如 ConcurrentHashMap;或者加互斥鎖。
假如我還想隔離兩個線程的數(shù)據(jù), 怎么辦?
ThreadLocal,然后舉了個例子。
Golang 里的逃逸分析是什么?怎么避免內(nèi)存逃逸?
這個不知道,認(rèn)慫了。
對比一下 Golang 和 Java 的 GC。
答了一下 CMS、G1和三色標(biāo)記,我對比的點是 JVM 有分代回收,Go 的 Runtime 沒有,沒能深入地講。
Golang 的 GC 觸發(fā)時機(jī)是什么?
閾值觸發(fā);主動觸發(fā);兩分鐘定時觸發(fā)。
有沒有寫過 Kubernetes 的 Operator 或 Controller?(我:沒有寫過)
談一談你對微服務(wù)架構(gòu)的理解。
大體思路“微服務(wù)本質(zhì)是人員組織架構(gòu)演進(jìn)與關(guān)注點分離”。
談一談你對 Serveless 的理解
大體思路“Serverless 是繼 Docker 與容器編排之后的又一次應(yīng)用開發(fā)與基礎(chǔ)設(shè)施提供方之間的邊界劃分”。
你認(rèn)為 Serverless 是未來嗎?為什么?
大體思路“是云服務(wù)的未來,把蛋糕從企業(yè)的IT、運維與中間件部門切走,形成規(guī)模效應(yīng),做得越多賺得越多;公司內(nèi)的話 Serverless 能夠幫助加速前臺業(yè)務(wù)迭代,但對中后臺的收益還看不到,未來可能會有比 Serverless 更適合中后臺的架構(gòu)”。
面試官:最后你有什么要問我的?
我:為什么足足安排了五輪技術(shù)面,而且其中有兩輪似乎和 Kubernetes 沒有關(guān)系???
面試官:我們覺得你做過的東西挺多的,各個方向都想讓你嘗試一下(我的內(nèi)心:……)。
我:那這輪是最后一輪技術(shù)面嗎?
面試官:不一定(我的內(nèi)心:……)。
問經(jīng)歷。
為什么要考慮出來看看呢?
金句:”現(xiàn)在自己的技術(shù)成長有點碰到瓶頸,加上一直對您公司欽慕有加”
現(xiàn)在公司的主營業(yè)務(wù)是什么?(這塊往技術(shù)上問了很多,感覺是想考察我解釋復(fù)雜問題的能力)
現(xiàn)在帶人嗎?report 層級是怎樣的?
對自己這幾年的經(jīng)歷滿意嗎?
覺得自己有什么缺點?
碰到過什么很挫敗的事情嗎?
未來的職業(yè)規(guī)劃是怎樣的?
看機(jī)會的時候,主要考慮的是待遇、平臺、人員還是什么其他因素?
現(xiàn)在的待遇如何?
有什么想問我的?
面試難度:正常
面試體驗:正常
問題偏向:基礎(chǔ)知識,開發(fā)常識,技術(shù)見解
頭條
問項目,抓出一些你擅長的領(lǐng)域或場景
問系統(tǒng)設(shè)計題,每題都會不斷深化需求讓你應(yīng)變和權(quán)衡
問一道算法題(不難不偏),先看思路,再要求寫一下偽代碼看邊界條件能不能一次過
介紹一下自己,為什么選擇出來看看機(jī)會?
聊項目,警報怎么做的,統(tǒng)一接入監(jiān)控項怎么做的?
聊項目,配置中心項目,問實時配置推送怎么做?
討論為什么選擇所有的組件依賴放在配置中心中控制?
我現(xiàn)在要做一個限流功能,怎么做?
令牌桶。
這個限流要做成分布式的,怎么做?
令牌桶維護(hù)到 Redis 里,每個實例起一個線程搶鎖,搶到鎖的負(fù)責(zé)定時放令牌。
怎么搶鎖?
Redis setnx。
鎖怎么釋放?
搶到鎖后設(shè)置過期時間,線程本身退出時主動釋放鎖,假如線程卡住了,鎖過期那么其它線程可以繼續(xù)搶占。
加了超時之后有沒有可能在沒有釋放的情況下,被人搶走鎖
有可能,單次處理時間過長,鎖泄露。
怎么解決?
換 ZooKeeper,用心跳解決。
不用 ZooKeeper 的心跳,可以怎么解決這個問題呢?
每次更新過期時間時,Redis 用 MULTI 做 check-and-set 檢查更新時間是否被其他線程修改了,假如被修改了,說明鎖已經(jīng)被搶走,放棄這把鎖。
假如這個限流希望做成可配置的,需要有一個后臺管理系統(tǒng)隨意對某個 API 配置全局流量,怎么做?
在 Redis 里存儲每個 API 的令牌桶 key,假如存在這個 key,則需要按上述邏輯進(jìn)行限流。
某一個業(yè)務(wù)中現(xiàn)在需要生成全局唯一的遞增 ID,并發(fā)量非常大,怎么做?
snowflake(這個其實答得不好,snowflake 無法實現(xiàn)全局遞增,只能實現(xiàn)全局唯一,單機(jī)遞增,面試結(jié)束后就想到了類似 TDDL 那樣一次取一個 ID 段,放在本地慢慢分配的策略)。
算法題,M*N 橫向縱向均遞增的矩陣找指定數(shù)?
只想到 O(M+N) 的解法,補充:這幾天刷 leetcode 碰到這題了,240. Search a 2D Matrix II[4],辦法是從左下角或右下角開始查找。
有什么想問我的?
平時用的工具鏈和技術(shù)棧是什么?
Golang 踩過坑嗎?
答了之前 PingCAP 面試時面試官問的 for-range 里的 go-routine 閉包捕獲問題。
這段 Golang 代碼有沒有 bug(還是一個 for-range 的坑)?
有 bug,for-range 的 value 引用拷貝問題。
Java 中 HashMap 的存儲,沖突,擴(kuò)容,并發(fā)訪問分別是怎么解決的?
Hash 表,拉鏈法(長度大于8變形為紅黑樹),擴(kuò)容*2 rehash,并發(fā)訪問不安全。
拉鏈法中鏈表過長時變形為紅黑樹有什么優(yōu)缺點?
優(yōu)點:O(LogN) 的讀取速度更快;缺點:插入時有 Overhead,O(LogN) 插入,旋轉(zhuǎn)維護(hù)平衡。
HashMap 的并發(fā)不安全體現(xiàn)在哪?
拉鏈法解決沖突,插入鏈表時不安全,并發(fā)操作可能導(dǎo)致另一個插入失效。
HashMap 在擴(kuò)容時,對讀寫操作有什么特殊處理?
不知道。
ConcurrentHashMap 是怎么做到并發(fā)安全的?
segment 分段鎖。
Java 有哪些鎖機(jī)制,分別有什么特點?
Synchronized、可重入鎖。
知道 CAS 嗎?Java 中 CAS 是怎么實現(xiàn)的?
Compare and Swap,一種樂觀鎖的實現(xiàn),可以稱為“無鎖”(lock-free),CAS 由于要保證原子性無法由 JVM 本身實現(xiàn),需要調(diào)用對應(yīng) OS 的指令(這塊其實我不了解細(xì)節(jié))。
MySQL 的聚簇索引和非聚簇索引有什么區(qū)別?
聚簇索引的葉子節(jié)點是數(shù)據(jù)節(jié)點(比如定義了主鍵時的主鍵索引),非聚簇索引葉子節(jié)點是指向數(shù)據(jù)塊的指針。
B+樹和二叉樹有什么區(qū)別和優(yōu)劣?
B+樹是多叉樹,深度更小,B+樹可以對葉子節(jié)點進(jìn)行順序遍歷,B+樹能夠更好地利用磁盤扇區(qū);二叉樹:實現(xiàn)簡單。
針對一個場景設(shè)計索引,具體場景忘記了,反正考察的是聯(lián)合索引與列選擇性的知識。
現(xiàn)有一個新的查詢場景, 要怎么解決?
假如要查 A in () AND B in (), 怎么建索引?
只給選擇性高的一列建索引,這里因為兩個都是范圍查詢所以另一個是走不到索引的(這里答的不好,其實也可以建聯(lián)合索引然后用 (A,B) in ((1,2),(3,4)) 的方式去查)。
查 A in () AND B in () 時,MySQL 是怎么利用索引的?
先走一個非聚簇索引,查詢出行數(shù)據(jù)后再用另一列回表做篩選。
假如查詢 A in (),MySQL 是針對 N 個值分別查一次索引,還是有更好的操作?
不知道,有了解的同學(xué)可以留言(補充,@BillyLu 貼出了文檔 equality-range-optimization[5],大意是對非唯一索引 MySQL 會使用 index dive 的方式估算這個 range index 涉及的行數(shù),結(jié)合 where optimization[6] 中說明的在走 index 時假如涉及行數(shù)過多會走 full table scan,那么假如 estimation 認(rèn)為這次 IN 不夠好,是會走全表掃描的。不知道除此之外,面試官還有沒有想考察的點)。
用過 Redis 的哪幾種數(shù)據(jù)結(jié)構(gòu)?(都用過)ZSET 是怎么實現(xiàn)的?
跳表。
zrange start,stop,總長度為 n,復(fù)雜度是多少?
O(logN)(答得不好,實際是 O(M+log(N)), M 是結(jié)果集基數(shù) stop-start)。
Kafka 的消費者如何做消息去重?
MySQL 去重、Redis 去重、假如場景量極大且允許誤判,布隆過濾器也可以。
Log-Structured Merge Tree,犧牲讀性能換取性能,RocksDB、HBase、Cassandra 都在用,結(jié)構(gòu)有點忘了,只說了先寫 memtable 再刷盤成 sstable。
在生產(chǎn)中用過 Cassandra 和 RocksDB 嗎?量有多大?
用過,Cassandra 存調(diào)用鏈,RocksDB 做 flink 和 Kafka Stream 的本地狀態(tài)存儲。
Cassandra 的墓碑機(jī)制是什么?
不知道,對 Cassandra 停留在使用階段。
聊項目和工作經(jīng)驗。
用 Kubernetes 的過程中踩過哪些坑?
考慮一個業(yè)務(wù)場景:頭條的文章的評論量非常大,比如說一篇熱門文章就有幾百萬的評論,設(shè)計一個后端服務(wù),實現(xiàn)評論的時序展示與分頁。
我:需不需要支持頁碼直接跳轉(zhuǎn)?
面試官:支持和不支持兩種場景都考慮一下。
我:不需要支持頁碼翻頁就傳評論 id 用 offset 翻頁
假如用 id 翻頁的方式,數(shù)據(jù)庫表如何設(shè)計?索引如何設(shè)計?
(文章id,評論id)建聯(lián)合索引,評論 id 需遞增。
假如量很大,你覺得需要分庫分表嗎?怎么分?
需要分,分表有個權(quán)衡,按文章 id 分表,讀邏輯簡單,但寫有熱點問題;按評論 id 分表,讀邏輯復(fù)雜,但寫壓力就平均了。寫是要首先保證的,而讀總是有緩存等方案來折中,因此按評論 id 分表好。
分庫分表后怎么查詢分頁?
每張表查 N 條數(shù)據(jù)由 client 或 proxy merge。
分庫分表后怎么保證主鍵仍然是遞增的?
講了 TDDL 的辦法:有一張專門用于分配主鍵的表,每次用樂觀鎖的方式嘗試去取一批主鍵過來分配,假如樂觀鎖失敗就重試。
現(xiàn)在需要支持深分頁,頁碼直接跳轉(zhuǎn),怎么實現(xiàn)?
不能做精準(zhǔn)深分頁,否則壓力太大,找產(chǎn)品進(jìn)行妥協(xié),在 50 或 100 頁后數(shù)據(jù)分頁是否可以不完全精確,假如可以,那么緩存深頁碼的起始評論 id。
瞬時寫入量很大可能會打掛存儲,怎么保護(hù)?
斷路器。
斷路器內(nèi)部怎么實現(xiàn)的?
可以用 ringbuffer。
斷路器會造成寫入失敗,假如我們不允許寫入失敗呢?
先寫進(jìn)消息隊列,削峰填谷異步落庫。
算法題:N 場演唱會,以 [{startTime, endTime}…] 的形式給出,計算出最多能聽幾場演唱會?
先講了思路,按 endTime 升序排列,再順序取最多場次。
(講完思路之后)屏幕共享給我,用你最熟悉的語言把這個算法實現(xiàn)
用 Go 實現(xiàn)了一版。
你用了貪心法,貪心可能會存在什么問題?
局部最優(yōu),在這個問題里,只能找到一個可能解,無法找到所有排列方式。
面試難度:正常
面試體驗:挺好
問題偏向:架構(gòu)設(shè)計,算法
PingCAP
這里要特別感謝一下 PingCAP 的 HR 小姐姐,加了微信之后全程幫助我協(xié)調(diào)面試時間并不厭其煩地回答我各種奇奇怪怪的問題,最后談 offer 的時候還給我準(zhǔn)備了一個驚喜。面試體驗直接滿星<3!
問項目經(jīng)歷,聊了兩個項目。 對 Kubernetes 了解怎么樣,看過源碼嗎? Kubernetes 的代碼我以前其實只看過 kubelet,臨陣磨槍的時候把 apiserver、scheduler、controller-manager 都看了一遍,笑容漸漸出現(xiàn)。 Kubernetes 的 Service 是什么概念,怎么實現(xiàn)的? 你剛說到 Informer,Informer 是怎么實現(xiàn)的,有什么作用? StatefulSet 用過嗎?有什么特點? StatefulSet 的滾動升級是如何實現(xiàn)的? 現(xiàn)在我們希望只升級 StatefulSet 中的任意個節(jié)點進(jìn)行測試,可以怎么做? 這題沒有思路,只好強(qiáng)答用“兩個 StatefulSet”,后來一想起一個新的 StatefulSet 那 PV 里的數(shù)據(jù)就丟了,其實正確辦法是利用 partition 機(jī)制,笑容漸漸消失。 Kubernetes 的所有資源約定了版本號,為什么要這么做? 第二個拿不準(zhǔn)的問題,我面試前就反復(fù)告訴自己“不要強(qiáng)答”以及“不知道的題就講思路”,于是就說這塊代碼確實沒看過,但是根據(jù)微服務(wù) API 的設(shè)計理念,版本號的作用有巴拉巴拉。答完似乎面試官還算滿意,于是又往下挖了一句: 假如有多幾個版本號并存,那么 Kubernetes 服務(wù)端需要維護(hù)幾套代碼? 這題完全不知道,內(nèi)心逐漸焦灼,立馬走老套路“這我沒看過 Kubernetes 代碼怎么寫的無法確定(想表達(dá)自己真正看過代碼才會確認(rèn),凸顯自己嚴(yán)謹(jǐn)……我的媽呀),但假如由我來寫這份代碼(裝作非常自信),我會只會維護(hù)一份最新的 Model,然后設(shè)計對應(yīng)一個版本段的 Adpater 將老版本的 Model 轉(zhuǎn)化過來巴拉巴拉”。到這里我已經(jīng)虛的不行了。 OK,那接下來我們聊聊 Golang (我:長舒一口氣) 看一下這段代碼有沒有問題(一段 golang for-range 里 goroutine 閉包捕獲的代碼),為什么? goroutine 是怎么調(diào)度的? goroutine 和 kernel thread 之間是什么關(guān)系? 有什么想問我的?
給我介紹 PingCAP 相關(guān)團(tuán)隊的職責(zé)與挑戰(zhàn)。 聊為什么出來看機(jī)會,以及未來的職業(yè)規(guī)劃。 聊我之前做的一個數(shù)據(jù)同步的項目,大概內(nèi)容是訂閱 MySQL Binlog,sink 到搜索索引、分庫分表以及業(yè)務(wù)事件訂閱流中。 為什么數(shù)據(jù)同步里選擇了 xxxx 開源項目,優(yōu)勢在哪? 訂閱分庫分表的 Binlog 怎么訂閱? 分庫分表的數(shù)據(jù)源中假如存在主鍵沖突要怎么解決? 怎么保證下游對 Binlog 的消費順序? 如何在下游保證消費時的事務(wù)原子性? 描述了一下 TiDB 的 Binlog 架構(gòu),問這種場景下怎么保證 Binlog 順序 聊一個上了 Kubernetes 的項目,問了一些細(xì)節(jié)和坑。 用 Kubernetes 之后,解決了哪些問題? 聊我之前做的監(jiān)控警報項目,問背景和產(chǎn)出。 Prometheus 單實例數(shù)據(jù)量級 hold 不住了,有什么解決方案? 有什么想問我的?
聊“配置中心”項目的細(xì)節(jié)。 為什么不用 ZooKeeper,要自己再寫一個“配置中心”? 這個問題讓我措手不及,我只好坦白:當(dāng)時年輕,想刷經(jīng)驗,事后才領(lǐng)悟到不要重復(fù)造輪子,當(dāng)然最后系統(tǒng)的產(chǎn)出也不錯(后面這兩句是我臨時加的,不能讓面試官覺得我是一個不看全局只顧自己刷經(jīng)驗的人)。 配置中心怎么做服務(wù)發(fā)現(xiàn)的?怎么做 failover 的? 用 Kubernetes 碰到過哪些坑? 對 Prometheus 做了哪些改動? 對 Alertmanager 做了哪些改動? 監(jiān)控系統(tǒng)怎么做“自監(jiān)控”? 跨機(jī)房的網(wǎng)絡(luò)問題怎么監(jiān)控? 有什么想問我們的?
面試難度:正常
面試體驗:我給滿分
問題偏向:項目經(jīng)歷、工程能力
這里真的想夸一下 PingCAP(因為面試體驗超棒呀?。?。投 PingCAP 的初衷是覺得這個團(tuán)隊的工程師文化非常濃,大牛云集,同時 TiDB 夠牛逼,項目開源的模式我內(nèi)心也很認(rèn)可。只是掛羊頭賣狗肉的公司也不少,好多 JD 上寫著工程師文化濃郁,其實很多根本不是那么回事兒。但是經(jīng)過 PingCAP 的五輪面試之后,我實打?qū)嵉馗惺艿搅斯こ處熚幕好嬖嚴(yán)餂]有任何一個“刁難人的問題”,每一位面試官感興趣的是我的工程思維、學(xué)習(xí)能力、技術(shù)見解,同時還非常熱衷于與我討論和深挖一些坑與技術(shù)決策。這種感覺就很爽:面試官是懂我的,我作為工程師的思維能力與技術(shù)見解得到了認(rèn)可與尊重。這種氛圍是口號喊不出來的,因為它的硬性指標(biāo)就是這其中的每一個人要熱愛技術(shù)并且工程經(jīng)驗豐富。
簡歷里寫了的項目,以及熟練程度在“掌握”以上的領(lǐng)域與中間件要好好準(zhǔn)備,當(dāng)面試官問你一個偏門的問題時,他內(nèi)心其實也沒希望你能答上來。而當(dāng)面試官問你簡歷上涉及的問題時,假如你答不上來,那面試官就覺得這個人要么是眼界太低,會了一點就覺得自己掌握了,要么是簡歷造假在胡吹,這兩種都非常不利;
在上一條的基礎(chǔ)上,可以準(zhǔn)備一個最得意的項目,在簡歷上和面試過程中引導(dǎo)面試官往這塊聊;
面試前心里可以準(zhǔn)備一個方法論:明確面試官想招怎樣的人有哪些特質(zhì),在面試過程中努力表現(xiàn)出這些特質(zhì)。這聽起來是句正確的廢話,但面試的過程不可控因素太多,有一個清晰的目標(biāo)在腦子里能幫你在手足無措時想到說什么。舉個例子,有一輪中面試官問我有什么問題時,我就問貴司的對應(yīng)崗位會面臨哪些技術(shù)挑戰(zhàn)(當(dāng)然要先說清楚這不是在質(zhì)疑他們沒有挑戰(zhàn),只是自己渴望挑戰(zhàn))。
System Design Primer,入門架構(gòu)設(shè)計必看的一篇資料??赐曛筇嵝炎约菏冀K記得:架構(gòu)設(shè)計的本質(zhì)是深入理解業(yè)務(wù)場景之后用工程經(jīng)驗做出最佳權(quán)衡。面試時的一個套路是先提綱挈領(lǐng)地把舍棄什么來換取什么講明白;
云原生相關(guān),Kubernetes Concepts[8] 部分建議再看一遍,源碼部分推薦看 apiserver 中的 CRD 部分與 aggregation layer、kubelet 的 pod 狀態(tài)同步、scheduler 的調(diào)度部分以及 Sample Controller[9] 如何寫一個自己的 controller
語言方面,推薦看書《Effective Go》《Effective Java》,都很薄。這兩本書我是以前看的,面試前沒有專門準(zhǔn)備語言相關(guān);
還有公眾號互聯(lián)網(wǎng)架構(gòu)師里面的文章,對我的幫助也挺大的,建議各位好好讀一下;
算法相關(guān),這部分我純鶸,說實話我覺得大學(xué)里那本教材《數(shù)據(jù)結(jié)構(gòu)與算法分析》就寫得很不錯……至于 leetcode,面試前沒有刷過,最近為了練習(xí) Rust 刷了60多題,并沒有碰到面試?yán)锍霈F(xiàn)過的題目,看起來要刷 leetcode 的話就得走量多刷點,刷的少純拼強(qiáng)運了;
Golang for range的坑,有兩輪面試都涉及到了這個話題,這里貼一下。
正文結(jié)束
1.不認(rèn)命,從10年流水線工人,到谷歌上班的程序媛,一位湖南妹子的勵志故事
3.從零開始搭建創(chuàng)業(yè)公司后臺技術(shù)棧
5.37歲程序員被裁,120天沒找到工作,無奈去小公司,結(jié)果懵了...
一個人學(xué)習(xí)、工作很迷茫?
點擊「閱讀原文」加入我們的小圈子!

