前言
最近組內(nèi)招人比較多，可惜一直沒有招到令人滿意的人選。我們一直在討論彼此都問了什么問題，是不是問的太難了，是不是要放松一下標(biāo)準(zhǔn)等等問題。周末在家閑來無事，發(fā)現(xiàn)不知不覺也已經(jīng)從事web后端開發(fā)5年多時間了，所以現(xiàn)在想從事互聯(lián)網(wǎng)的后端開發(fā)，對于大量的curd工作來說，到底需要哪些技能，這里就總結(jié)一下。
以下僅代表個人觀點。
web后端和工程研發(fā)有什么區(qū)別嗎？
首先web后端和工程研發(fā)的區(qū)別是什么？
在我心里是這么定義的：在基于H5技術(shù)棧的產(chǎn)品中（無論是PC還是手機端），處在需求第一線，以需求為導(dǎo)向的，提供數(shù)據(jù)與功能的業(yè)務(wù)支持。
如果單純的指后端開發(fā)，那么范圍太廣了，比如有專職處理大數(shù)據(jù)，有處理基礎(chǔ)平臺的，有算法服務(wù)的等等，如果整個后端是一個冰山，那么web后端就像是冰上露出的一角。因為我們都知道，頁面上一個看似很小的數(shù)據(jù)，看似很小的功能模塊，可能都是后臺經(jīng)過多個模塊，多次聚合得出來的結(jié)果，在這個位置就必須熟悉各種底層依賴，如果有些功能團隊沒法支撐，可能就要自己上去造輪子了。
這個職位可能沒有太多時間去在某一個專業(yè)方向做技術(shù)沉淀，因為需求每天都在變，而且永遠(yuǎn)做不完。而對應(yīng)的工程研發(fā)，應(yīng)該是以不變應(yīng)萬變的存在，有了一個通用的大的需求場景，去研發(fā)一些底層通用的東西，比如播放器的技術(shù)，地圖的技術(shù)，隊列的技術(shù)，數(shù)據(jù)庫的技術(shù)等。很多公司在招聘的時候把這兩類人混成一類來看待，因為我們自己往往也是這么看自己的，畢竟覺得要給自己留一條技術(shù)路線的選擇，萬一全部精力用來討論業(yè)務(wù)，自己豈不是未來要轉(zhuǎn)型稱為產(chǎn)品經(jīng)理了……
很多從事這方面工作的人都有一種感覺，就是我們每天都在ctrl c + ctrl v。curd的操作還需要什么技能？以前我也有這種感覺，但是當(dāng)自己好好總結(jié)一下后，發(fā)現(xiàn)東西還是不少的。
語言基礎(chǔ)
首先當(dāng)然是語言基礎(chǔ)，不管是什么編程語言，沒有一門拿得出手的編程語言，就像是士兵上了戰(zhàn)場沒帶槍一樣。剛畢業(yè)那段時間我也很重視這方面的能力，在各種群里討論，總結(jié)工作中遇見的各種奇怪的問題，但是越到后面，我反而對這個東西的重視程度沒那么高了。在我還沒畢業(yè)的實習(xí)階段，學(xué)習(xí)的是前端技術(shù)，也自學(xué)了一點nodejs，后來轉(zhuǎn)到后端做了java開發(fā)，再后來加入創(chuàng)業(yè)公司轉(zhuǎn)為php開發(fā)，也從事了幾個月的爬蟲研究，所以又學(xué)習(xí)了python，目前在公司進行的是go語言的開發(fā)工作。
這些經(jīng)歷讓我感覺語言終歸就是一個工具，很多東西大同小異，各自有自己的適合的場景，根據(jù)公司的技術(shù)棧和項目的實際情況，做出相對合理的選擇就好。正如go語言近兩年大火，也許過幾年又出現(xiàn)什么其他語言也說不定。
過去在面試別人的時候也喜歡去網(wǎng)上找一些所謂的面試題，比如這個函數(shù)的返回值是什么之類的問題。說實話，大部分場景我們的工作中都不會遇見的，這個東西有多少意義我對此表示中立，唯一的作用可能是用來衡量面試者的真實工作時長吧，畢竟類似設(shè)計模式，架構(gòu)分層等思想，真的是沒有幾年真實項目開發(fā)經(jīng)驗是完全無法理解的，書本上的知識和親身感受回答的內(nèi)容，過來人一聽就知道。
所以現(xiàn)在我面試的時候這方面的問題我一般也會問一些，但是一般就是象征性的問一些比較通用的，以go語言為例，基礎(chǔ)變量相關(guān)的問一問slice，hashmap，底層設(shè)計不同于其他語言的CSP模型，GC實現(xiàn)相關(guān)的，三色標(biāo)記法。當(dāng)然了，也會問一些“一下程序的輸出值是什么”之類的問題，這種知識應(yīng)該是一個人在入門一門語言的過程中隨便讀過一本書都會了解到的東西。如果面試者宣稱的主要開發(fā)語言，連一本像樣的入門書籍都沒讀過，這種人肯定是不考慮的。
網(wǎng)絡(luò)協(xié)議基礎(chǔ)
如果是計算機相關(guān)專業(yè)畢業(yè)的人，肯定知道計算機網(wǎng)絡(luò)，TCP/IP卷一，這類書籍，畢竟是必修課嘛。這類東西有用嗎？剛畢業(yè)的時候沒什么感覺，可是時間長了發(fā)現(xiàn)還是非常有用的。
比如幾乎說有面試寶典都會提到的TCP/IP三次握手，四次揮手。你知道為什么提問的次數(shù)這么高嗎？因為在web服務(wù)后端的開發(fā)過程中，尤其是現(xiàn)今微服務(wù)這么火熱的背景下，所有的服務(wù)間通信都離不開這里的知識。如果你身處大公司，可能好多東西都被運維部或基礎(chǔ)架構(gòu)部之類的部門解決掉了，但是如果你在一家中小型公司，這些東西是你必須面對的。
這里說一個我面試的過程中最喜歡提問的一個問題吧--?從瀏覽器輸入域名開始，到數(shù)據(jù)返回并呈現(xiàn)頁面，中間經(jīng)歷了哪些過程。
答：（DNS）域名解析 -》TCP連接-》http通信-》負(fù)載均衡（nginx）-》應(yīng)用服務(wù)（python，go，php等）
這個是應(yīng)屆生基本能給出的答案。
為什么我最喜歡問這個問題呢？因為這里有太多知識點可以提問，
比如：DNS采用什么協(xié)議傳輸，TCP還是UDP，為什么只有13個根域名服務(wù)器？
這個知識點有用嗎？有用，雖然我們主流的服務(wù)都是TCP的，但是不排除你未來會使用UDP應(yīng)用，UDP的數(shù)據(jù)報文長度限制都不知道，相關(guān)功能怎么開發(fā)？局域網(wǎng)的DNS更不用說，大家都改過hosts文件吧，這個在日常服務(wù)中也少不了相關(guān)的操作。你看很多我們每天在做的事情，其實就是這么一個普通的知識點。
再比如大家總是問tcp握手，相信很多人都像背誦課文一樣背下來了，但是能好好理解的人就不多了，比如DOS攻擊，目前使用云服務(wù)成了主流，這部分應(yīng)該都被服務(wù)商解決了，但是在過去這都是每個開發(fā)者自己要考慮的問題。
其次，做開發(fā)的，應(yīng)該沒有不知道wireshark的吧。我記得過去自己使用rabbitmq的時候，有一次因為參數(shù)配置問題一直搞不清楚，最終就是靠抓包的方式，再對著文檔，一點點分析出來問題的，抓下來的包其實就是書中描寫的那些東西。
這里多提問一個問題，抓包過程中WIN這個是干什么的？基本上問這個問題就能知道一個人是否學(xué)習(xí)過計算機網(wǎng)絡(luò)了。
以及路由的相關(guān)知識，我們曾經(jīng)遇見過，因為一個路由問題，線上機器同一個集群訪問數(shù)據(jù)庫走不同的路由，一個走很長的鏈路一個走很短，導(dǎo)致線上服務(wù)接口忽快忽慢，定位了許久才找到這個問題，最終聯(lián)系運維相關(guān)的同事解決了。雖然我們是后端服務(wù)開發(fā)，但是過程中很多問題也許并不是代碼的問題，有這些知識才能讓你定位問題時有更廣闊的視野。
作為web后端開發(fā)，http狀態(tài)碼都代表什么意思，這個必須會沒什么異議吧，比如301和302的區(qū)別，或者這樣問，登錄驗證時發(fā)現(xiàn)你未登錄，把你定向到到登錄頁用的是哪種？包括我們經(jīng)?？吹膆ttp報文體，里面很多字段都可以拿出來分析一下。
再然后就是https，相信只要你的公司有個正經(jīng)的主頁，都會有個https 的訪問地址了，那么關(guān)于https 的基本知識你了解多少呢？曾經(jīng)有個面試者連https是對稱加密還是非對稱加密都沒答上，我只能說對此很失望……
這里推薦一個博主總結(jié)的非常好的文章HTTPS溫故知新（一）?這是一個系列的文章，找時間讀一下受益匪淺
操作系統(tǒng)基礎(chǔ)
我這里毫無疑問指的是linux環(huán)境，如果有大佬是window服務(wù)器開發(fā)的，請繞行……
在面試的時候這里可以問的點就太多了，簡單一些的就是服務(wù)器的基本操作，比如文件目錄的創(chuàng)建，權(quán)限變更，常用配置更改，服務(wù)資源占用情況，nginx錯誤日志快速查詢等等。
這里問一個有意思的問題，linux的一個文件夾里的文件上限是多少？如果你只有一臺服務(wù)器，需要保存大量的文件，那么要怎么設(shè)計比較好？
上面這個問題就是我在創(chuàng)業(yè)公司的時候面對的問題，畢竟小團隊規(guī)模小，也沒那么多服務(wù)器，硬盤雖然可以隨便加，但是程序設(shè)計上就要注意了。
然后就是進程與線程，這個也不多介紹了，干入這行，這點基礎(chǔ)沒有就別進來了。目前比如go語言又有了協(xié)程的概念，其實本質(zhì)就是內(nèi)核態(tài)與用戶態(tài)的轉(zhuǎn)換問題。關(guān)于這個其實也有很多可以不是很深卻很基礎(chǔ)的問題，比如我們?nèi)绾未_保服務(wù)進程不死的？有使用crontab的，有使用supervisor的，那么supervisor的實現(xiàn)原理是什么？其實就是父子進程的知識點，但是好多人從來沒考慮過這個問題。
IO多路復(fù)用，基本上對應(yīng)的面試題就是Apache與nginx對比，或者select 與 epoll區(qū)別。
現(xiàn)如今大部分功能都在云上，或者被基礎(chǔ)運維同事解決，尤其容器化技術(shù)的應(yīng)用，讓過去很多必須小心翼翼的操作變的不那么重要了。
數(shù)據(jù)結(jié)構(gòu)與算法
大廠面試的門檻，今天你刷leetcode了嗎？
數(shù)據(jù)結(jié)構(gòu)與算法貌似只有計算機專業(yè)的人才學(xué)的一門課程吧，其實我覺得這個應(yīng)該拆開成兩個部分去看，首先是數(shù)據(jù)結(jié)構(gòu)，比如鏈表，hash表。然后是算法，我覺得應(yīng)該是在應(yīng)用開發(fā)過程中大部分情況都是一起來使用的，所以有了這么個名字。
首先這些知識的作用是毋庸置疑的，但是大家爭論比較大的就是，curd的工作會這個有用嗎？傳說中某廠面試手?jǐn)]紅黑樹是真的嗎？
這里說說我的一點微不足道的看法。
首先我之前跳槽找工作的時候也在刷題，但是很少，也就幾十道，大部分是簡單難度的，基本就停留在背包問題這種簡單動態(tài)規(guī)劃的水平。首先要承認(rèn)一點，能把算法學(xué)好，同時有能力現(xiàn)場手?jǐn)]出來的，編程能力普遍會高很多，學(xué)習(xí)能力也比較容易鑒別，對于財大氣粗的廠，也算是變相的減輕了很多人才篩選的工作壓力。但是話又說回來，對于主要偏向業(yè)務(wù)的工程開發(fā)，這些算法知識起到的作用很有限……因為除了一些常用的基礎(chǔ)知識，其他的都被封裝在各種類庫，各種框架中供我們使用，如果你追求極致性能上的優(yōu)化，當(dāng)然還是需要過硬的能力的，但是國內(nèi)有多少業(yè)務(wù)開發(fā)會去做這樣的事情呢？
而且還會出現(xiàn)一種情況，就是這類人解決單個問題的能力會偏強，但是在代碼規(guī)范，整體設(shè)計上往往并不比擅長工程開發(fā)的人要好，究竟什么是系統(tǒng)架構(gòu)設(shè)計這個我后面在聊。而且由于算法工種的平均薪資較高，所以這類人從事工程業(yè)務(wù)開發(fā)有時候會出現(xiàn)厭煩情緒，如果同一個功能頻繁換人開發(fā)，那么結(jié)果將是毀滅性的，相信有過剛?cè)肼毥邮忠粋€N多人開發(fā)過的項目的類似經(jīng)驗的人，一定非常理解。
說了這么多，當(dāng)我面試別人的時候，我會問相關(guān)問題嗎？當(dāng)然會了，不過我一般會挑選一些簡答的提問。
首先二叉樹相關(guān)的我基本就不怎么問，比如二叉樹找公共父節(jié)點，首先這確實是一道好題目，及考了二叉樹的結(jié)構(gòu)，又考了遞歸和非遞歸編程，不過二叉樹這種東西大家實際使用的確實比較少，大部分都是被各類框架封裝好了，所以如果沒有準(zhǔn)備過的人，一般也很難現(xiàn)場整理出來思路。但是我更喜歡的一個題目是二叉樹打印，感興趣的可以試試。
還有一些涉及到算法知識的問題，一般來說我是不喜歡問的，比如如果用randN隨機數(shù)創(chuàng)造出一個randM的隨機數(shù)，這里就用到了Rejection sampling（拒絕采樣）的知識。絕大部分候選人都是通過刷題庫的方式了解到這種解法，但是這有什么意義呢？如果是算法的面試去問問推導(dǎo)過程不是更好嗎？
然后關(guān)于鏈表相關(guān)的問題，我一般喜歡問判斷單向鏈表是否存在環(huán)結(jié)構(gòu)，并找出那個點。這個問題是那種做過了瞬間給出答案，沒做過基本沒思路的問題，在我面試眾多候選人里，只有一個人在我的提示下靠自己推算出來結(jié)果，毫無疑問我們直接錄用了他。
鏈表的思想還是非常重要的，這個在一些應(yīng)用場景里確實是有意義的，同時哪怕是簡單的鏈表翻轉(zhuǎn)，也可以在面試的時候考研面試者的編碼能力。
提完鏈表，就不得不再提一下hash表，這個的重要性就太高了，比如php用著最爽的部分就是那萬能的數(shù)組，本質(zhì)就是hash表，同時在日常開發(fā)中，進行一些數(shù)據(jù)源的合并，匹配，包括配合桶排序的思想進行一些業(yè)務(wù)的上排序和分類，都是非常常用的場景。這里提一個比較經(jīng)典的題目：兩數(shù)之和。
然后是排序，首先這個東西的使用大部分都是被各類語言的類庫解決了，但是這個思想很重要，手?jǐn)]快排我真的不覺得過分，至于使用場景就太多了，首頁的topN，charts的時間軸等等。
還有一些堆棧問題的使用，這個還是有些作用的，比如求一個連續(xù)輸入流的topN或者中位數(shù)等，就可以使用堆排序的思想解決。這個還是有一些使用場景的。
bitmap相關(guān)，很多場景我們不會輕易就使用大數(shù)據(jù)服務(wù)，那么如果進行數(shù)據(jù)壓縮處理，尤其是純數(shù)字的場景，那就是bitmap的思想，甚至在一些數(shù)據(jù)庫的設(shè)計中也可以使用類似的方法，可以幫助我們節(jié)省很多關(guān)聯(lián)表。最經(jīng)典的應(yīng)用應(yīng)該就是布隆過濾器了。
數(shù)據(jù)結(jié)構(gòu)與算法，在我看來本質(zhì)上就是時間換空間或者空間換時間的問題，但是web后端開發(fā)的日常真正會遇到這類問題的場景且需要通過代碼層面去優(yōu)化的有多少呢？往往都是通過緩存，網(wǎng)絡(luò)鏈路優(yōu)化等提升更加簡單直接有效。
通用的第三方服務(wù)
首先各大公司基本都是在用市面上的第三方工具，或者內(nèi)部公司造的輪子。有一些及其經(jīng)典的相信做這行的多少要好好去了解一下吧。
mysql
比如mysql，這個就是太經(jīng)典了，雖然現(xiàn)在隨著數(shù)據(jù)規(guī)模增加，需求場景的更加豐富多彩，存儲引擎也是五花八門的，但是依然無法動搖mysql的地位，首先SQL標(biāo)準(zhǔn)，基本是所有主流都會支持的，其次作為免費好用的工具，大學(xué)時期的大作業(yè)相信大部分人也是用mysql實現(xiàn)的吧，然后事務(wù)的使用目前也是非常穩(wěn)定。對于很多孵化期間的產(chǎn)品，mysql依然是最適合起步的存儲引擎。
由于各家公司的技術(shù)棧和需求場景不同，有人用mongo，有人用postgresql，所以這個在招聘面試的時候也很難針對某一種去面試。但是面試mysql就沒什么太大問題，關(guān)系型數(shù)據(jù)庫的設(shè)計在對象抽象，數(shù)據(jù)結(jié)構(gòu)描述上也更直接。比如我們目前的技術(shù)棧就是mysql加es的方式，但是面試的時候我一般還是主要面試mysql的知識為主。
那么mysql要怎么面試？
首先是sql基礎(chǔ)，比如下面這道題。
假設(shè)表如下
name?? kecheng?? fenshu
張三????語文?????? 81
張三?????數(shù)學(xué)?????? 75
李四?????語文?????? 76
李四?????數(shù)學(xué)?????? 90
王五?????語文?????? 81
王五?????數(shù)學(xué)?????? 100
王五?????英語?????? 90
找出每門課都大于80分的學(xué)生
首先這個并不難，但是為什么要面這種問題呢？因為現(xiàn)在ORM架構(gòu)的盛行，很多單純寫業(yè)務(wù)的人可能真的快把sql語句的基礎(chǔ)忘了吧，我記得之前招聘外包的時候真的有一些寫不出來的。
然后稍微上一點難度，就是數(shù)據(jù)庫的設(shè)計
學(xué)生，班級，課程
我有如下需求：
①查詢一班選擇高等數(shù)學(xué)課的學(xué)生有多少人
②查詢一班選課學(xué)分不足10分的學(xué)生
③查詢上學(xué)期足球課報名的女生數(shù)
其實就是關(guān)于一對多，多對多之類的考慮，這個也不難，但是一般面試的時候如果讓他現(xiàn)場設(shè)計，你可以看到候選人對于需求的拆解過程，是不是自己有過獨立負(fù)責(zé)功能模塊開發(fā)的經(jīng)驗。當(dāng)然這個只是面試剛工作一兩年左右的人比較合適。
再然后用的比較多的就是索引相關(guān)知識，比如：
select * from tb_test where a = ? and c=?;
idx_abc(a,b,c)
這條語句能命中索引嗎？
查詢結(jié)果我只需要a，select * 和select a 有區(qū)別嗎？
對于索引基礎(chǔ)的重要程度就不需要多做解釋了。
最后應(yīng)該就是事務(wù)鎖的一些問題，畢竟線上服務(wù)鎖表的風(fēng)險還是不言而喻的。再比如，select for update在一些特定場景下可能產(chǎn)生的死鎖現(xiàn)象，網(wǎng)上也可以搜到許多。
比如會議室系統(tǒng)：比如我司的會議室預(yù)定系統(tǒng)，每天10點開放搶會議室，對于比較搶手的時間，經(jīng)常出現(xiàn)頁面卡死，看著有會議室但是實際已經(jīng)被別人搶走了等等，類似春運搶票的樣子，這里就可能是事務(wù)鎖或主從同步的問題等，那么要如何優(yōu)化呢？這個就可以和候選人聊一聊。
隊列服務(wù)
大公司應(yīng)該都有專門的團隊就行封裝或者二次開發(fā)。那么隊列究竟幫我解決了什么問題，以及需要面對哪些新的問題？
我覺得簡單理解就是生產(chǎn)與消費速度之間的緩沖，同時也起到了一些分發(fā)的功能。
有一篇文章總結(jié)的很好，如何保證消息隊列的高可用和冪等性以及數(shù)據(jù)丟失，順序一致性
在面試的過程中大部分問題也會幾種在這部分，生產(chǎn)者弄丟了數(shù)據(jù)怎么辦？消費者弄丟了數(shù)據(jù)怎么辦？數(shù)據(jù)的順序如何保證？線上隊列堆積怎么辦？
很多都是真實的生產(chǎn)環(huán)境中會遇見的場景，真正從事過核心業(yè)務(wù)開發(fā)的人不可能沒考慮過這些問題，即使沒遇見過，預(yù)案肯定是要提前確定好的，所以通過這些問題就能夠知道面試者在進行日常開發(fā)的時候是否有過自己的思考。
redis
過去可能還會有人問redis和memcached的區(qū)別，現(xiàn)在好像也沒人問了……
redis在緩存上的地位目前應(yīng)該是無人撼動了，基于redis的提問一般會問什么呢？大部分喜歡問zset的實現(xiàn)，也就是跳躍表。正經(jīng)翻過一遍redis相關(guān)書籍的人應(yīng)該都對這個實現(xiàn)的印象非常深刻。
其他基于redis的實際使用場景可能會有不少人喜歡問，比如用redis充當(dāng)簡單的隊列，用redis實現(xiàn)分布式鎖。
如果是中小公司可能還需要考慮一下一致性hash在redis部署上的應(yīng)用。
這里推薦一個總結(jié)的不錯的文章Redis系列文章——合集?如果能把這些理解了相信關(guān)于redis的面試就沒什么問題了
作為日常web開發(fā)中，我一直覺得redis是查詢接口性能優(yōu)化中的“抗生素”，簡單直接高效，什么底層查詢慢，計算慢等問題，掛個定時任務(wù)，數(shù)據(jù)灌入，速度瞬間雄起。但是我一般還是不太喜歡這么做，首先這東西有依賴性，用了一次就有下一次，漸漸的系統(tǒng)就有了“抗藥性”，隨著數(shù)據(jù)量訪問量的增加，redis自身的負(fù)擔(dān)在加重，接口中值得優(yōu)化的點基本被忽略，然后接口的相應(yīng)速度有一點點降低，這時候怎么辦？可能就是提高“用藥量”，加資源吧……
nginx
我相信nginx與apache的競爭結(jié)果也出來了，在互聯(lián)網(wǎng)公司現(xiàn)在用apache的應(yīng)該少之又少了吧。
其實面試的時候關(guān)于nginx本身的問題我一般問的不多，畢竟這東西作為一個工具性的東西，業(yè)務(wù)開發(fā)了解的那么多也沒有什么太大的幫助，網(wǎng)上關(guān)于源碼分析的東西一抓一大把，我們小組也組織過幫nginx源碼加注釋的活動，全部過了一遍之后，好像也快忘的差不多了，但是如果是剛工作沒多久的，且有業(yè)務(wù)時間的，倒是可以看一看實現(xiàn)，很多工程實現(xiàn)確實很有借鑒意義。
基于nginx我可能會問一下負(fù)載均衡，反向代理，限速相關(guān)的問題，比如讓你自己實現(xiàn)一個限速器，或者實現(xiàn)一個加權(quán)負(fù)載的功能，你有什么想法？了解過nginx的一般當(dāng)場就能打出來，畢竟都是成熟的解決方案，我覺得作為業(yè)務(wù)開發(fā)了解這些就足夠了。如果有大佬說他自己實現(xiàn)了個更好的負(fù)載算法或者限速算法，那么我只能說大佬慢走，讓您做業(yè)務(wù)開發(fā)真的是暴殄天物了。
其他框架
比如spring，gin，laravel 等代碼使用的框架，其實寫多了就會發(fā)現(xiàn)很多共通的地方，比如反轉(zhuǎn)依賴，中間件，路由層，業(yè)務(wù)邏輯層等等，這個地方可以根據(jù)項目上的實際使用來提問。個人感覺可能值得提問的應(yīng)該就是服務(wù)注冊，反轉(zhuǎn)依賴，路由設(shè)計這幾個部分。同時如果你們同時在使用一個輕量級框架或者某框架的最新beta版，倒是可以一起討論一下遇到的一些坑。
“改輪子”的能力
沒事重復(fù)造輪子，這種事情經(jīng)常有人出來吐槽，后來又搞出了什么業(yè)務(wù)中臺之類的概念。這里我說一下，重復(fù)造輪子是不可能避免的事情，為什么？因為很多在別人看來很小的需求，在另一個項目確是個強需求，這個時候人家讓你支持一下，加個功能吧，定制化個接口吧，你覺得結(jié)果會是如何？所以最終就是誰需要誰去重新造，順便還能刷一波KPI。
我當(dāng)然是不支持這樣做的，但是實際遇見的問題怎么解決？這就是“改輪子”的能力了。大家都熟悉的主流架構(gòu)我們基本上沒法插手，畢竟代碼規(guī)范和需求涵蓋面等基本能滿足絕大部分需求了，但是有很多公司內(nèi)部相似的東西如果能快速理解源碼并在此基礎(chǔ)上進行微調(diào)，并投入自己的生產(chǎn)線中，這才是web后端該做的事情，畢竟這么多需求，你想自己造一個輪子，pm也不會給你時間啊。
掌握一點兒前端知識
前后端分離的概念貌似是近兩年流行出來的吧，PC端過去還是jsp，php的時代，那個時候做web開發(fā)要說一點前端技術(shù)都不懂肯定是不行的。現(xiàn)如今無論大小公司應(yīng)該都是前后端分離的方式，后端提供api，前端利用一些框架通過異步請求的方式。
這種工作模式下后端要了解前端的知識有什么用？問題在于前端頁面的本質(zhì)是DOM樹的渲染過程，通過異步獲取json報文并解析，消耗的是客戶端的資源，如果這個頁面很大，元素很多，甚至再加上一些炫酷的效果呢？估計用戶的電腦就像被點燃了一樣，風(fēng)扇飛速旋轉(zhuǎn)，然后死機。畢竟能有阿里這種前端后級別分配這么清晰的公司還是少數(shù)，這個時候其實就要前后端來共同決策如何進行優(yōu)化。
但是反過來如果問我，面試的時候要問面試者前端的相關(guān)知識嗎？如果非要找點相關(guān)性的話，可能就是用戶登錄，session管理之類的知識吧。
高并發(fā)解決方案
到了這里應(yīng)該都是招聘高級后端才會提問的問題了，大致應(yīng)該分為幾個吧。
比如zookeeper的相關(guān)知識。
剩下的應(yīng)該就是上面提到的那些知識，不過是把場景復(fù)雜化一些。
這里介紹一個最近剛看到的，分布式id生成的知識。方案一就是集中式生成，比如Oracle，Zookeper，Redis等，這類方法的問題在于嚴(yán)重依賴第三方。另一種就是叫做Snowflake方法，簡單來說，算法采用41bit毫秒時間戳，加上10bit機器ID，加上12bit序列號，理論上最多支持1024臺機器每秒生成4096000個序列號。
個人感覺，所有的方案都在CAP定理下，目前真正擁有超級大的訪問規(guī)模處理應(yīng)用就不多，真正有機會在實際生產(chǎn)環(huán)境中不斷探索和攻克的人更是少之又少，像我這種甘當(dāng)咸魚的選手，并不會在這上面放太多精力，對于面試者，只要他能夠有過自己的思考，說出自己在項目中的取舍過程就很好了。
系統(tǒng)規(guī)劃能力
毫無疑問，我這里說的肯定不是網(wǎng)上那種系統(tǒng)架構(gòu)設(shè)計。
這里我覺得我玩過的一個游戲很符合我心里對此的設(shè)定 -- 《異星工廠》，如果有愛玩策略類游戲的小伙伴，我這里推薦一下。
開局一個小人，通過建造工廠，造出宇宙飛船逃離星球。
這個就好像我們剛學(xué)習(xí)寫業(yè)務(wù)代碼的階段，砍砍樹，搬搬磚（寫一些最簡單的代碼），了解各類礦石（了解各種業(yè)務(wù)）
然后我們有了原材料（基礎(chǔ)知識），我們就可以開始建造機器（編寫業(yè)務(wù)功能）
很快，我們掌握的建造技術(shù)（業(yè)務(wù)功能）越來越多，功能之間彼此連接依賴（功能模塊相互調(diào)用），就成了一個完整的業(yè)務(wù)模塊。
我們需要的基礎(chǔ)資源（基礎(chǔ)數(shù)據(jù)）越來越多，我們建造起了礦場（數(shù)據(jù)庫）
隨著工廠規(guī)模的增加（數(shù)據(jù)規(guī)模增加），我們需要更多類型的資源，水資源，煤炭資源等（多數(shù)據(jù)源）
復(fù)雜材料需要一些基礎(chǔ)材料按照一定比例合成，這里就需要一些分發(fā)器（路由），進行礦石的分發(fā)與調(diào)度（隊列）
隨著我們需要的資源越來越多，身邊的資源已經(jīng)不夠了，我們建造出了火車幫我們?nèi)ミ\輸遠(yuǎn)處的資源（大數(shù)據(jù)平臺）
我們需要時刻關(guān)注著我們各類資源的生產(chǎn)和消費情況（運維監(jiān)控）
在這個星球上我們也有敵人，那就是這些異星的蟲子（黑客），我們在進行科技發(fā)展的過程中也需要建造武器來抵御攻擊（網(wǎng)絡(luò)安全）
很快隨著科技的進步，我們可以提前設(shè)計好圖紙，讓機器人快速部署防御系統(tǒng)（docker容器化部署）
這個游戲甚至還提供了與或，加減運算等組件，通過這些東西的合并組合，可以實現(xiàn)時鐘與計算器的功能（數(shù)據(jù)結(jié)構(gòu)與算法）
在這個過程中免不了一些不合理的設(shè)計被拆除重新建造（代碼重構(gòu)）
作為玩家，就是將這些簡單的組件，合理的組合分配，實現(xiàn)工廠的正常運轉(zhuǎn)。而這就是我心中web后端架構(gòu)要有的能力，就是將大量簡單的業(yè)務(wù)模塊合理規(guī)劃分配，讓整個工廠（系統(tǒng)）可以快速迭代，穩(wěn)定運行。
結(jié)語
web后端工程開發(fā)，簡單說就是一個什么都要會一些，但是貌似有不是特別需要精通的這么一個崗位。而我們就是要在這樣的工作過程中，在業(yè)務(wù)與技術(shù)領(lǐng)域共同進步。
