之前很多同學(xué)嚷嚷有沒有社招經(jīng)驗(yàn)，正好，我有個(gè)朋友去騰訊社招面試了。

他的面的是全棧開發(fā)崗位，工作兩年，后端是Go，前端是 JavaScript + Vue。

因?yàn)楣ぷ饕矝]多久，就兩年時(shí)間，所以大概率可能還是一半考察業(yè)務(wù)，一半考察基礎(chǔ)，事實(shí)證明，基礎(chǔ)占六成，業(yè)務(wù)占四成，其中業(yè)務(wù)就是自己在工作中的具體業(yè)務(wù)，基礎(chǔ)則就是校招那些東西，編程語言、操作系統(tǒng)、計(jì)算機(jī)網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)（MySQL + Redis)、算法等。

大概是三月份的時(shí)候就斷斷續(xù)續(xù)開始找一些機(jī)會(huì)，其實(shí)去年 11-12 月份的時(shí)候他就刷過一些算法題，當(dāng)時(shí)就想著找找感覺，刷了小 10 天就沒再繼續(xù)刷了。

而在今年一月份的時(shí)候他就開始在力扣上重新刷題了，一直斷斷續(xù)續(xù)的刷，總共加起來 200+ 道題是有了。

對(duì)接觸一線業(yè)務(wù)的后端程序員來說，第一次跳槽，那么編程語言、計(jì)算機(jī)網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、操作系統(tǒng)四大塊是一定繞不開的，這四塊是最基本的根基所在，系統(tǒng)和網(wǎng)絡(luò)還好，數(shù)據(jù)庫(kù)絕對(duì)是考察重點(diǎn)，在此之上才是一些其余的分布式、微服務(wù)架構(gòu)、服務(wù)治理等。

最后再在面試中補(bǔ)充你自己對(duì)工作項(xiàng)目的思考，聊聊你的業(yè)務(wù)，所負(fù)責(zé)的模塊，前期做的一些市場(chǎng)調(diào)研，以及與同行的方案對(duì)比，你的創(chuàng)新點(diǎn)或者說優(yōu)越點(diǎn)在哪里。

其實(shí)工作久了的人就會(huì)知道：編程語言不重要，重要的是業(yè)務(wù)，這句話有多么的對(duì)。

一面

鵝廠一面是個(gè)小哥，應(yīng)該是做后端的，基本圍繞著Go和計(jì)算機(jī)基礎(chǔ)來問，面試時(shí)間很長(zhǎng)，差不多一個(gè)半小時(shí)了，前端基本沒問。

1、看你自我介紹是寫全棧的？前端技術(shù)如何？

答：工作中自學(xué)的前端，會(huì)寫一點(diǎn)，不算很好，基本夠用的水平

2、前端開發(fā)過程中有遇到什么自己覺得難搞的點(diǎn)嗎？

答：有，有一個(gè)功能印象較深，開發(fā)實(shí)現(xiàn)了url頁面分享的功能，這個(gè)在我們開發(fā)時(shí)市面上還沒有很好的例子，并且在內(nèi)網(wǎng)分享會(huì)上寫了文章進(jìn)行分享。

哦，那挺好的，那我們聊些后端吧

3、Go 里面使用 Map 時(shí)應(yīng)注意問題和數(shù)據(jù)結(jié)構(gòu)？

答：可以通過定義 value 為 struct 來節(jié)約內(nèi)存；哈希分桶的結(jié)構(gòu)，用哈希值的高八位和低八位分別來做桶內(nèi)定位的依據(jù)和分桶的依據(jù)等；

4、Map 擴(kuò)容的細(xì)節(jié)可以說一下嗎？

答：這個(gè)《Go 語言底層原理剖析》這本書里有，不展開，其實(shí)跟 Redis 中漸進(jìn)式 rehash 的思路差不多；

5、Rehash 過程中存放在舊桶的元素如何遷移？

答：見2

6、sync.Map 比加鎖的方案好在哪里？底層數(shù)據(jù)結(jié)構(gòu)？

答：緩存 + map 組成的結(jié)構(gòu)；底層 map 實(shí)際依然是加鎖的，但是讀的時(shí)候加上緩存可以增加并發(fā)性能；

7、如果有這樣一個(gè)場(chǎng)景，在并發(fā)環(huán)境想要用哈希容器，你會(huì)采用哪些方案？

答：sync.Mutex / sync.RWMutex或者sync.Map

8、還是上面那個(gè)場(chǎng)景，并發(fā)環(huán)境共享同一個(gè) map 可以嗎？

答：不可以，可能會(huì)panic

9、channel 知道吧，他的底層數(shù)據(jù)結(jié)構(gòu)大致說說？

答：見2，不贅述

10、mysql中的事務(wù)？

答：事務(wù)是一組操作單元，要么全部執(zhí)行成功，要么全部執(zhí)行失敗，不存在第三種情況，主要用來保證數(shù)據(jù)庫(kù)一致性。

事務(wù)具有四個(gè)特性：ACID

• 原子性（Atomicity）：事務(wù)中的所有操作要么全部執(zhí)行成功，要么全部執(zhí)行失敗，不會(huì)出現(xiàn)部分執(zhí)行的情況。

• 一致性（Consistency）：事務(wù)執(zhí)行前后數(shù)據(jù)庫(kù)的狀態(tài)是一致的，即數(shù)據(jù)庫(kù)中的約束和規(guī)則都得到了保持。

• 隔離性（Isolation）：多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)，相互之間不會(huì)影響彼此的執(zhí)行結(jié)果。

• 持久性（Durability）：事務(wù)執(zhí)行完成后，對(duì)數(shù)據(jù)庫(kù)所作的修改將被永久保存到數(shù)據(jù)庫(kù)中。

11、索引什么時(shí)候下會(huì)失效？可以舉個(gè)例子嗎？

答：場(chǎng)景很多，比如一次性查詢超過全表40%以上的數(shù)據(jù)，gorm框架里自帶一個(gè)model結(jié)構(gòu)，其中有create_time字段，如果我按照 create_time 去做范圍查詢，查詢1970-2021年間的數(shù)據(jù)，那么索引就形同虛設(shè)了，因?yàn)樽叩氖侨頀呙瑁?/p>

12、寫個(gè)SQL吧，求一個(gè)商品表中價(jià)格最高的第10和第14個(gè)產(chǎn)品？

答：使用limit關(guān)鍵字

13、有寫過查詢時(shí)間很慢的接口嗎？最后有查到原因嗎？

答：有，寫過，入職沒多久的時(shí)候遇到過這個(gè)問題，好像是剛?cè)肼氁粋€(gè)月左右。

最開始以為是SQL寫的不行，直接用explain看了一下發(fā)現(xiàn)沒什么大問題，索引也用上了，后來排查下來發(fā)現(xiàn)是緩存沒加上。。。每次取數(shù)后忘記回表了，這樣每次都走的DB，redis根本沒用上，所以導(dǎo)致每次都很慢??

14、你們做的具體業(yè)務(wù)？

答：大致說了一下自從我入職以后做的業(yè)務(wù)，面試官偶有打斷并詢問，因?yàn)槭莾?nèi)部項(xiàng)目不公開，就不展開了。

15、三握四揮具體過程？

答：老八股文了

16、算法題：最長(zhǎng)子序列

反問：

• 部門業(yè)務(wù)？

• 騰訊基架服務(wù)如何？

• 常規(guī)上下班時(shí)間？加班現(xiàn)象如何？

小哥直接說過了，問我接下來有沒有時(shí)間，二面面試官現(xiàn)在正好空，方便的話可以繼續(xù)面，不方便的話再找HR約時(shí)間。

求之不得，我這個(gè)人最不喜歡拖泥帶水，一次性面完最好。

二面

10分鐘后二面開始了，年紀(jì)稍大的一個(gè)老哥，30+歲的樣子，腦袋有點(diǎn)禿，頭頂有點(diǎn)亮，看起來像個(gè)大佬的樣子，我坐直了身子，開始認(rèn)真回答。

1、你負(fù)責(zé)的業(yè)務(wù)是什么？

答：balabalba，二十分鐘過去了

2、前端開發(fā)多還是后端開發(fā)多？你覺得你的前端水平如何？

答：前后端四六開吧，剛?cè)肼殨r(shí)寫過半年的前端，后面一年半只寫自己功能模塊對(duì)應(yīng)的前端了。

我感覺自己的前端水平屬于半吊子水平，野路子出生，沒有經(jīng)過系統(tǒng)學(xué)習(xí)，都是工作中學(xué)會(huì)的技能，不瞞你說我以前在學(xué)校的時(shí)候?qū)W的都是后端技術(shù)棧，所以最開始寫前端，全靠抄組內(nèi)同事的代碼，找一個(gè)差不多的頁面就開抄，抄著抄著就會(huì)寫了。

老哥笑了一下。。。

3、前端回調(diào)地獄是什么？

答：在JavaScript中，多層嵌套的回調(diào)函數(shù)造成的問題。在處理異步請(qǐng)求時(shí)，為了保證數(shù)據(jù)的同步和正確性，往往需要使用回調(diào)函數(shù)。當(dāng)多個(gè)回調(diào)函數(shù)嵌套在一起時(shí)，就會(huì)形成回調(diào)地獄。

4、有哪些解決方案？

答：Promise或者async/await

5、diff算法是什么？

答：diff算法是指在前端框架中用來對(duì)比兩個(gè)虛擬DOM樹的差異，并將差異更新到真實(shí)DOM上的一種算法，可以減少渲染次數(shù)，提高渲染性能，避免對(duì)整個(gè)頁面的重新渲染，從而提升用戶體驗(yàn)。

基本思路是，通過對(duì)比虛擬DOM樹中節(jié)點(diǎn)的屬性和內(nèi)容的變化，來確定哪些節(jié)點(diǎn)需要更新，哪些節(jié)點(diǎn)需要?jiǎng)h除，哪些節(jié)點(diǎn)需要新增。

6、vue生命周期？用的哪個(gè)比較多？

答：大致有八個(gè)生命周期：beforeCreate、created、beforeMount、mounted、beforeUpdate、updated、beforeDestroy、destroyed。

我們用的最多的是created和mounted，前者created是在實(shí)例被創(chuàng)建后會(huì)被調(diào)用。在這個(gè)階段，Vue實(shí)例已經(jīng)創(chuàng)建完成，數(shù)據(jù)已經(jīng)初始化好，可以訪問實(shí)例的數(shù)據(jù)和方法。但此時(shí)還沒有開始模板渲染；mounted則在掛載完成后被調(diào)用，此時(shí)實(shí)例已經(jīng)被掛載到頁面上，并且可通過DOM獲取到。在這個(gè)時(shí)期，實(shí)例的數(shù)據(jù)綁定和狀態(tài)也更新完畢了。

7、vuex用過嗎？想在一個(gè)頁面中使用兩個(gè)模塊的屬性？比如一個(gè)用戶模塊，一個(gè)商品模塊，應(yīng)該用什么關(guān)鍵字去調(diào)用？

答：用過，頁面中使用computed和mapState來做區(qū)分，可以自定義別名來做。

8、分布式鎖如果是基于 Redis 的會(huì)有什么問題？

答：鎖可能會(huì)失效，在主從模型下同步并不保證一致，這種場(chǎng)景下會(huì)失效。

9、Redis 使用的過程中有碰到過一些熱 Key、大 Key 的問題嗎？如何處理？

答：我理解是想問如何定位key，說 rdbdump 導(dǎo)出之后做（離線）分析，看看哪個(gè) Key占的空間特別大，再做處理，比如哈希、打散等；

10、如果有一些熱點(diǎn) Key，比如某個(gè)鏈接被明星分享了，訪問就會(huì)很頻繁，怎么辦？

答：這不就是redis的存在意義嗎？里面放的就應(yīng)該是熱數(shù)據(jù)啊。

如果熱點(diǎn)數(shù)據(jù)里面的 Value 過大，可以嘗試使用多線程來緩解網(wǎng)絡(luò)IO壓力，這是Redis 6的功能。

11、后臺(tái)服務(wù)架構(gòu)中如何設(shè)計(jì)？怎么才能高性能一些？

答：劃重點(diǎn)，超級(jí)難的一個(gè)問題?。?！，聊了很久，這個(gè)問題來來回回大概聊了差不多30分鐘都不止，從以下幾個(gè)方面聊了很久：

池子：內(nèi)存池、連接池、對(duì)象池

并發(fā)：請(qǐng)求并發(fā)、請(qǐng)求冗余

異步：調(diào)用異步、流程異步

緩存：緩存分類、緩存回收、崩潰修復(fù)

數(shù)據(jù)庫(kù)：分庫(kù)分表、動(dòng)態(tài)平衡、任務(wù)分片、路由策略、讀寫分離

12、隨便寫道題吧，我也不想考，但這是規(guī)定，力扣接雨水

答：啊行行行，你是面試官，你咋說都行，磕磕絆絆寫出來了。

反問

• 詢問我的不足之處？答：基礎(chǔ)很好，建議加強(qiáng)表達(dá)。？？？？？我摸不著頭腦，不知道啥意思，沒再追問

• 部門業(yè)務(wù)？如果我能夠通過面試，會(huì)負(fù)責(zé)哪些業(yè)務(wù)？

• 項(xiàng)目組的細(xì)節(jié)，比如代碼組織、管理形式等。

今天就到這里了，后面有機(jī)會(huì)再分享一下其余廠的面經(jīng)。文章來源地址http://www.zghlxwxcb.cn/news/detail-486041.html

到了這里，關(guān)于去面騰訊了（社招兩年面試經(jīng)驗(yàn)）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！