如何面試程序員

⑴ 如何面試後端程序員

• 計算機網路常見面試點總結

  計算機網路常見問題回顧

  2.1 TCP、UDP 協議的區別

  2.2 在瀏覽器中輸入url地址 ->> 顯示主頁的過程

  2.3 各種協議與HTTP協議之間的關系

  2.4 HTTP長連接、短連接

  2.5 TCP 三次握手和四次揮手

• 三 Linux

  3.1-簡單介紹一下-linux-文件系統？

  3.2 一些常見的 Linux 命令了解嗎？

• 四 MySQL

  4.1 說說自己對於 MySQL 常見的兩種存儲引擎：MyISAM與InnoDB的理解

  4.2 資料庫索引了解嗎？

  4.3 對於大表的常見優化手段說一下

• 五 Redis

  5.1 redis 簡介

  5.2 為什麼要用 redis /為什麼要用緩存

  5.3 為什麼要用 redis 而不用 map/guava 做緩存?

  5.4 redis 和 memcached 的區別

  5.5 redis 常見數據結構以及使用場景分析

  5.6 redis 設置過期時間

  5.7 redis 內存淘汰機制

  5.8 redis 持久化機制（怎麼保證 redis 掛掉之後再重啟數據可以進行恢復）

  5.9 緩存雪崩和緩存穿透問題解決方案

  5.10 如何解決 Redis 的並發競爭 Key 問題

  5.11 如何保證緩存與資料庫雙寫時的數據一致性？

• 六 Java

  6.1 Java 基礎知識

  6.2 Java 集合框架

  6.3 Java多線程

  6.4 Java虛擬機

  6.5 設計模式

• 七 數據結構

• 八 演算法

  8.1 舉個栗子（手寫快排）

• 九 Spring

  9.1 Spring Bean 的作用域

  9.2 Spring 事務中的隔離級別

  9.3 Spring 事務中的事務傳播行為

  9.4 AOP

  9.5 IOC

不需要寫代碼就能衡量候選人的方法可能有一萬種。我常用的三個主要方法可以覆蓋許多不同的技能。在面試過程中，我們會談論候選人的經驗，要求他們做一些代碼審查，並與別人合作設計一個系統。

下面我會詳細解釋這個過程。

我試圖通過這些方法找到真正能夠勝任技術工作的候選人，並且他們必須能在單純的編程技能之外給團隊帶來價值。通常在一次面試中我能在大約一個小時內覆蓋所有三個部分。我有信心這些信息能讓我找到好的候選人。

1、深入挖掘他們的經驗

許多團隊已經這樣做了。他們會在面試一開始花幾分鍾，詢問候選人之前的工作，他們對工作的態度，等等。大多時候這就像隨意談話一樣。

但這是不對的。

記住這是面試。你需要盡可能地理解他們構建系統時使用的技術。

為了做好這一點，你需要在面試開始之前仔細閱讀他們的簡歷。這不是開玩笑，在面試開始之前至少花上10分鍾仔細閱讀（不是略讀）簡歷，如果花30分鍾時間則最好。要從簡歷中盡可能多了解些他們之前的項目，Google一下看看能否找到他們項目的公開信息。面試時挖掘背景信息所花的時間越少，就越能獲得好的效果。

在面試中，要求候選人談談他最近最感興趣的項目。要練習主動的傾聽，要學會參與。假裝你是他團隊中的一員，或者假裝你們是在做架構審查。你要努力了解他們構建的東西以及構建的方法。這樣做的好處和壞處是什麼？要讓候選人知道，不知道答案無所謂，但重要的是能勾起你的好奇心。

下面是我認為能獲得好的答案的問題：

• 你在項目中的職責是什麼？這個問題本身並不是決定性的。即使在項目中承擔的職責很小，他們也可能很適合你們的團隊。你的候選人也許正是因為沒能獲得重要的職責而在尋找新的機會。因此，知道他們過去的職責會很有幫助。

• 你從他人那裡獲得了什麼幫助？無法感受他人的幫助是個極其危險的信號。即使是個人項目，也一定需要別人的幫忙。你肯定不想要一個以自我為中心的同事。

• 給我介紹下那個功能的工作原理。解釋下數據的來源和去向、存儲方式以及這一切能帶給最終用戶的好處。這個問題的答案足以吸引你的好奇心。

• 這個項目中最糟糕的技術債務是什麼？好的工程師必須理解他們做出決定時需要付出的代價。問完這個問題，可以繼續詢問他們怎樣改正這些問題，或者尚未改正的理由。

• 有沒有出過生產環境下的bug或服務中斷？測試下他們是否理解bug的原因，以及團隊解決bug的方法。他們是否提前預期到了bug？下次怎樣才能避免同樣的問題發生？

這一部分面試能讓你直接了解候選人的經驗。做好這一部分還能讓你了解他們如何感謝別人或責備別人。你將會了解到他們如何在兩難的工程問題上做出抉擇，他們會與你分享最近的教訓，他們與別人溝通技術的能力應該也很明顯。

如果他們選擇了不太適合的項目，可以考慮談論其他項目。所謂不太適合的意思是項目不夠復雜或他們記不清的情況。

注意，這一步要避免詢問類似於「告訴我你解決過的最難的bug」之類的問題。要求別人回憶系統的某一部分的具體原理會帶來大量的虛假負面判斷。人們不可能擁有他們修復的bug相關的一切知識，這種問題會給面試過程帶來很大壓力。

2、讓他們審查你們的代碼

這項活動一半是代碼審查一半是角色扮演。你可以藉此篩選出那些能夠提升團隊整體代碼質量並促進辦公室氛圍的人。

下面是代碼審查過程中需要關注的一些方面：

• 他們怎樣與代碼的「作者」交流？交流是否有用？是否高效？是否友善？

• 他們會著重哪些問題？是否能明確表達出他們的疑問？他們是否會立即指出哪些無關緊要的問題？

• 他們是否善於閱讀自己不熟悉的代碼？

這個方法需要提前准備很多東西。你需要找到或編寫一段代碼供候選人審查。你還需要為你希望候選人找出的問題創建一個優先順序列表。不要讓面試管當場出題，一定要事先准備好。

在選擇需要審查的代碼時，不要選擇產品代碼。你的候選人沒有你所擁有的背景知識，這樣做實際上是將候選人與你的同事比較，而不是與其他候選人比較。

努力降低代碼示例中的復雜度。面試的時候，候選人沒有太多時間閱讀代碼，而且很可能他們並沒有想到會做代碼審查。熱身就要花很長時間。

在代碼中加入一兩個真實的bug，但不要強調找bug。一般來說，代碼審查並不是個好的找bug方法，特別是審查者從來沒有見過代碼的情況下。能自證的bug（如給需要數組的函數傳遞字元串）最好。在你的優先順序列表中，bug的優先順序應該是最低的，bug應該是給極其優秀的人的加分項。

最後，代碼應該做一些實際的事情。如果你的公司很出名，那可以選擇你的產品簡化版本。但如果你需要花大量時間為候選人提供背景信息的話還是算了。

最好的選擇要麼是虛構的代碼（也許可以選擇本文竭力避免的代碼面試中用到的代碼），要麼是開源代碼中的一個拉取請求。

一旦決定了要審查的代碼，你應該期待候選人找出下面這些東西：

• 過於糟糕的拉取請求的描述或提交信息；

• 能用但無法自洽的代碼；

• 過於復雜的代碼（需要重構的代碼）；

• 混亂的變數或方法名；

• 過度設計的代碼（即實際上永遠不會用到的功能）。

如果代碼中沒有足夠的問題，就多加一些。

這里有個潛在的問題，我還沒有確定的答案。這個問題是：你是否應該提前將代碼發給候選人？

如果你這樣做，就又給那些有空閑時間的人以巨大的優勢。如果不這樣做，就要面臨增加面試壓力的風險。

我傾向於後者。好的面試官可以減輕壓力，方法之一就是讓面試者提前知道他們將做代碼審查，你也可以在審查開始之前介紹你的期望。

⑵ 面試程序員的時候，怎麼聊更好

呈現出自己完整的知識結構。對於程序員來說，最重要的一件事情就是在短短的面試過程中呈現出自己完整的知識結構。要想做到這一點，一定要在自我介紹的過程中下足功夫，既簡練又豐富，引起面試官的重視，當然最重要的是自然一點，別緊張。

⑶ 程序員面試時需要注意哪些

1 說得太少
尤其是那些開放式的問題，如「請介紹下你自己」或「請講一下你曾經解決過的復雜問題」。面試官會通過你對這些技術和非技術問題的回答來評估你的經驗和能力。
所以，僅僅只用兩三句話來回答不但不能顯示出你對這個專業的興趣，還會讓整個面試過程顯得非常無聊。如果你不能很好地說明你的經驗、成就和技能給企業帶來的價值，那麼你的競爭力毫無疑問就高不起來。所以，你需要對一些最常見的開放式問答作充分的准備，學會推銷自己。
2 說得太多
不斷地說，不斷地說，卻並沒有什麼實質性的內容。換句話說，就是廢話連篇，言之無物。如果你不能簡潔的解釋問題，那麼面試官就會懷疑你在工作時的表現是不是也會像你的談話一樣拖泥帶水？可以先問問面試官，確定是否真的需要詳細解釋。
解釋也是一門藝術，關鍵是確定重點，如果需要的話再深入到細節。當聊到業務的時候，就應該從業務的角度看問題，不要涉及任何技術術語。學會用簡潔明了的方式解釋問題。如果你能時刻把握主旨，那麼這一點也不是問題。
3 回答不出一些必知的基本技術問題
面試不是技術競賽，不是看誰答對的問題多，但是有一些「必須知道」的核心Java和Web基礎知識，你不能不知。例如，對於Java開發人員
1）不知道「==」和equals之間的區別。
2）不知道equals和hashCode方法被隱式調用時的約定。
3）不能解釋曾投入精力過的應用程序的高層體系結構。
4）不知道OO的概念和設計原則。
5）不能很好地處理多線程。
6）不知道如何在HTTP客戶端與伺服器端之間保持狀態。
7）不知道SQL。
…
4 既寫不好簡單的代碼，又回答不出如何解決棘手的問題
作為一個開發人員，你應該根據自己的經驗水平，來針對給定的問題和情況編寫代碼。如果碰到一些比較棘手的問題，那麼即使你還沒有解決方案，也應該將你的思路講給面試官聽。當然這在面試時會讓人特別緊張，尤其是在還有時間限制的情況下，但是你也必須保持冷靜，至少應該說明你將如何試著去解決問題的方法。
5 糟糕的禮儀和態度
遲到，不適宜的著裝，抖手抖腳，沒有眼神接觸，過於緊張，沒有提問，顯示不出對這份職業的興趣，「我什麼都知道」的高傲態度，貶低你的現在和以前的僱主，遇到技術問題時煩躁不安或者垂頭喪氣，為自己找理由而不是虛心接受錯誤，與面試官發生爭執，隨波逐流而沒有自己的看法，過於呆板，撒謊，嗓門太大，無法成為良好的傾聽者，等等。
提示：面試官要找的不是技術明星，而是實實在在具備了合適的技術技能、軟技能、端正的態度以及能為企業獲取利益、全面的專業人才。因此，不妨先研究下想要應聘的機構，深入了解其工作規范以調整回答問題時的方向和重點。將每一場面試都當作免費的培訓課程，積極調整心態，不但能達到一個雙贏的局面，還可以減少緊張的情緒，從而獲得更好的表現。這樣即使你並沒有得到那份工作，也可以由此學到點什麼，獲得進步

⑷ 作為HR你是如何面試程序員的

我看下面幾乎所有人都說看人品。我就呵呵了，北京遍地小公司，哪怕大公司招一個合適的高級程序員知道有多難嗎？HR還看人品？這人品是你兩三句話能聊出來的？別逗了，無非是在技術差不多的情況下看看能不能接受加班出差，再比比價格，僅此而已。

⑸ 程序員應該怎樣去面試

嗨，親愛的程序員朋友們，如果你是工作好幾年的人了，那麼你一定經歷過面試吧，今天我以個人的視角總結了一下怎麼才能有一次成功的面試，希望對你有所幫助。如果你已經開始看了，那麼你一定看完哦，只有有耐心的人兒才能成大事，如果看了一半，這篇文章對你來說是沒有任何收獲的，反而卻浪費了你寶貴的時間。

關於簡歷的製作

每個技術面試官每天要閱覽幾百甚至上千份簡歷，閱讀一封簡歷的時間可能不超過10秒，你的簡歷就是茫茫大海中的一滴水，如果能讓面試官從一大摞簡歷中選出你的簡歷，那麼就需要從簡歷製作上下功夫了。

各位可以仔細琢磨一下上面的幾種場景，有時沒有經歷過這種場景，可能沒法對上面的描述做到感同身受，看了之後就會一帶而過了，建議收藏此文，以後遇到類似情況了，可以把這篇文章找出來看看，相信會對你有所幫助，最後祝各位程序員朋友們都能找到自己心儀的工作！

大家好，我是「上世是朵花」。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步了解我，那就關注我吧。

⑹ 如何面試c++程序員

你好，不知道你是面試哪個公司的C++程序員，所以只能籠統的給你找了兩個北京公司C++的面試經驗：
1、三個面試題，比較簡單，第三個是個模擬計算機，不建議採用編譯原理的方法去做。然後一個項目經理面試，考察設計能力，給一個場景，問如何設計，比較簡單。一個工程師面技術，主要問題一些Linux相對底層的東西。
2、總體，面試的一些問題還是比較簡單的。但是答的不好，主要是這些問題是比較簡單，但是就是簡單平時可能就這樣隨便學一下就過了，沒有仔細深入和歸納。 還有我也不知道是不是他們已經不想招人了。好像他也沒怎麼仔細看我的簡歷吧。
面試過程。
進去坐下，首先他讓我介紹自己，沒有說是介紹自己的基本資料，是介紹自己。
我的回答是名字，本科，研究生，來自哪個學校，什麼專業。
然後我停頓了一會，想他會問我吧，尷尬了，他說就這些嗎，意思叫我繼續介紹其他情況，下面就是我介紹研一主要是學習基礎知識，研二參加一些實踐，講sctp，不過大部分是將sctp基礎知識，sctp是類似於tcp的升級，sctp主要區別於tcp的地方是...sctp的一些特性，然後是講到sctp的握手機制，我覺得沒有講的深入，只是講了一些流程，和防止了syn攻擊。 總之大多都是講sctp是什麼，並沒有突出其重要的特性和使用的價值，關鍵之使用價值，沒有吸引住對方的東西。總體就是平鋪直敘，沒有吸引點，也沒有表現出個人在其中哪些貢獻和工作能力。
如果覺得不夠有針對性，你可以去卧龍閣看看具體公司的具體職位面試經驗。

⑺ 程序員應該如何面試，程序員面試問什麼技術

3年以下的面試
面試主要看兩個方面：
一、通過溝通交流，一些簡單的問題，了解的你的邏輯思維，個人性格。

二、一些常用的技術是否了解，根據你的回答問幾個典型的問題。

這個階段面試技術並不是最重點的，主要還是邏輯思維是否敏捷，為人處事是否好相處，技術是可以培養的，基本帶一周就可以很好的幹活了。

3年以上就麻煩了
一、技術會問的很詳細，沒有扎實的功底，擋不住啊。

二、超過3年的招聘，一般都是有一定目的性的，比如需要搭建項目構架，或者需要專攻資料庫的，或者需要比較全能的技術大牛來解決問題，所以應該針對面試方的一些需求去准備。

以上都是瞎掰，看看就行了。

⑻ 你要面試一個程序員，應該問他什麼問題

首先面試程序員分有沒有經驗
面試沒有經驗的程序員就隨便問問點ssm，ssh五大框架問題，多線程什麼的，再問問是否會點前端技術
有經驗就看看他的簡歷，問他簡歷項目上的問題，可以圍繞著簡歷上的項目問，通過他的回答涉及到的技術點之類的，拓展出去問其他的