程序員實施工程師面試題

1. 程序員面試，為什麼感覺很多都和運維有關

不會運維的程序員不是好程序員。 這個信條要時刻謹記，不管是面試還是自己平時在工作中都要堅持這個准則，因為這對你以後的發展大有裨益。

觀念問題

一直以來，很多圈外人對我們程序員的觀念就是永遠的一本正經，著裝單一，了無生趣，聰明絕頂，其實這是他們對程序員的誤解，因為多才多藝，多姿多彩的程序員比比皆是，但是傳統的觀念或者說以偏概全的觀念蒙蔽了他們的雙眼，而他們自己又沒有嘗試去了解，所以導致人雲亦雲，給程序員披上了一層灰。

同樣的，我們大部分程序員的觀念也跟他們差不多，認為程序員就只是搬磚擼碼的，至於各種部署伺服器相關的工作應該是運維做的，其實非也，如果真的這樣認為的話，那就真的太不把自己當程序員了。為什麼這么說呢？因為我們程序員是實實在在擼碼開發產品的群體，可是如果我們開發出來的東西只能自個在本地玩耍，卻不能眾樂樂，那還有什麼意義，此時，你可能會說，交給運維啊，那麼如果沒有運維呢，就沒法玩了，所以我們不能總是將希望寄託在別人身上，當自己有能力能夠將系統進行部署的時候，那就該學會部署。

其實不僅僅是程序員，優秀的運維工程師也是需要會開發擼碼的，因為有時候他們也需要開發一些小工具來進行驗證，或者開發網頁來進行服務的管理，所以說程序員和運維都是相輔相成的。

公司問題

像我們現在很多的公司都沒有明確的人員分工，特別是小公司連運維都沒有，所以就談不上讓運維去部署了，那麼怎麼辦呢？肯定就是開發人員自己去部署了，如果不會部署的話就可以去網上查找資料，其實總體來說不會很難，因為我看過很多運維其實也是在網上找資料按步聚進行操作。

另外公司之所以這么要求，一方面是基於人員成本的考慮，畢竟如果一個人能幹好的事為啥非得招兩個人；另一方面可能基於公司的發展問題，像一般的小公司確實沒必要專門招一個運維，不過隨著公司的發展，後期肯定會招專業運維，畢竟專人做專事，事半功倍。

總結

永遠記住「不會運維的程序員不是好程序員」，其實作為程序員不能總是把自己陷在擼碼的深淵，除了擼碼，我們還要學會產品需求分析、簡單的UI畫圖、資料庫分表分庫及性能優化、運維伺服器部署、單元及系統測試等等，總的來說，要想成為優秀的程序員，我們有必要把產品線上的每一個環節都略知一二，這是經驗收獲，一定會成為我們日後發展的資本。

技術迭代是需要時間的，而且公司預算不多的話，會選擇現有系統繼續使用。有的企業也會選擇維穩，不會輕易開發新系統代替現有系統。

這是一個非常好的問題，作為一名IT從業者，我來回答一下。

首先，在當前的大數據、雲計算時代，程序員在面試的過程中，經常會遇到與運維相關的問題，尤其是有自身產品（平台類）的企業，往往對於程序員的運維類知識有比較多的要求，所以當前的程序員，尤其是Java程序員，要想獲得較強的崗位競爭力，一定要重視運維類知識的學習。

在當前的大數據時代背景下，很多程序員在日常開發過程中，需要與運維人員進行配合，所以程序員在面試過程中，經常會被問及與運維相關的問題，通過這樣的問題，也能夠全面了解程序員是否面對過大用戶的並發問題，這對於判斷程序員是否適合當前的招聘崗位也有一定的參考價值。

以大數據開發崗位為例，程序員在進行大數據任務開發的過程中，不可避免地需要與運維人員打交道，其中大數據平台的搭建就是比較繁瑣的過程，另外還有一系列產品的安裝和部署，這些通常都需要運維人員來完成。對於一款平台類產品來說，運維人員的技術能力能夠在很大程度上決定軟體平台的性能，而且運維人員與開發人員的配合也非常關鍵。

當然，對於程序員來說，如果能夠自己掌握一定的運維知識，對於開發任務的開展還是很有幫助的，如果什麼問題都需要運維人員來完成，不僅需要更多的運維人員，同時也會影響項目的整體開發進度。從這個角度來看，隨著未來大數據技術的逐漸落地，程序員掌握一定的運維類知識，對於提升自身的工作效率，還是很有幫助的。

在程序員面試過程當中，通過一些運維知識也能夠更加直觀地了解到程序員的技術棧，相對於比較復雜的開發問題來說，運維知識的脈絡還是比較清晰的，通過運維知識能夠在一定程度上擠出一些「技術水分」，這也是很多面試官比較願意問運維問題的主要原因。另外，對於一些創業型公司來說，程序員掌握一定的運維類知識，也會節省一些投入，尤其在產品研發的初期。

從技術體系結構來看，要想解決大用戶的並發問題和系統擴展性問題，通常需要從兩個角度出發，一個角度是技術選型，比如採用擴展性比較強的大數據平台，另一個角度就是硬體擴充，但是硬體擴充的前提是要有一個可擴充的平台體系，而通過運維知識，程序員的交流會更明確，技術方案也比較直觀。

從崗位任務劃分的角度來看，程序員的工作任務與運維人員的工作任務有比較明確的邊界，但是在雲計算技術的推動下，程序員接觸運維場景的情況也在不斷增加，比如通過雲計算平台的支撐，很多傳統的運維類任務，程序員也會比較方便地完成，比如安全配置等等。

最後，程序員在進行面試的過程中，如果遇到的運維類問題並不清楚，一定要如實回答，因為運維類知識需要一個積累的過程，而且經驗往往非常重要，所以很多運維類知識，在短期內是無法掌握的，如果盲目擴展自己的知識面，會為後續的工作帶來很多麻煩。

如果有互聯網、大數據、人工智慧等方面的問題，或者是考研方面的問題，都可以在評論區留言，或者私信我！

一、提問之前的准備

首先，最重要的是，你自己一開始就應該想清楚：

只有明確這些根本性的問題，才能正確高效地完成面試。

二、提問的原則

假定你對上一節的三個問題，已經有了清晰的想法，那麼接下來就可以設計如何提問了。

有一些提問的原則，是你應該遵循的：

三、考察專業能力

為了確認面試者是勝任的，你可以問一些與職位相關的專業方面的問題。（不過通常來說，一次面試不足以看出一個人的專業能力。）

比如，你的招聘職位是系統管理員，你可以問"如何快速地在50台機器上部署Linux？"（提示：正確答案不是刻錄50張安裝光碟。）

另外，你還應該向面試者了解他的過去，因為過去是未來的最好預測依據。不過，提問的重點不要僅僅是他過去的成果，更要關注在當時的環境中，他是如何決策和實施的。

四、考察綜合素質

因為人是會發展的，所以某種程度上，面試者的綜合素質要比他的專業能力更重要。

所以，具體的技術問題（如何調用API、什麼是設計模式、編程語言的語法等等）可以少問一些，更應該關注面試者的事業心、對工作的熱情、進取心、自律能力、毅力等方面。

下面是一些典型問題：

五、考察理性思維

某些情況下，你可能需要了解面試者的分析判斷能力，看他能否全面地思考問題、客觀地評價自己。

那麼，你可以依次提出這樣三個問題：

這里的重點是，讓面試者從正反兩方面評價一件自己熟悉的東西，看看他的思維是否片面。答案無所謂對錯，只要面試者有一個明確的立場，能夠從正反兩方面說出令人信服的理由，就可以了。比如，某個軟體的口碑不好，但是面試者說他很喜歡，而且說得出一大堆理由，清楚地解釋了這種軟體的優點和缺點在哪裡，這樣就很好。

不邀自來。眾所周知，越大型的公司，分工越明確。在BAT裡面，有專門的前端，後端，ops，dba等等。他們專研一方面，所以有深度，有沉澱。遇到問題了，找到相應的人，能夠快速解決問題。

但絕大多數中小公司，更偏愛樣樣都會的全棧，恨不得你一個人把所有活兒做完。並不一定需要有多大深度，能幹活兒就行了。

再說，現在提倡devops，開發懂點運維，能夠更好地定位問題，部署和架構項目，這是需求，也是趨勢。

對小公司而言基本沒有專門的運維，所以需要研發具備一些運維的知識，比如資料庫的搭建、nginx、jdk部署，其它開源中間件，比如Kafka、es等等

其實這個目前真正大規模用的少，炒概念的多，很多公司根本沒機會用. 但是他會問

我覺得很自然的事，為什麼總有人說得高大上？裝個軟體，調個參數，做個邏輯卷，調一調網路，配置一下分布式組件，搞個文件系統程序員就應該不會？

這些工作，我們公司一般運維人員搞不定的。所以用啥，自己整。

個人觀點，計算機知識就必須全面，才能做好一個程序員吧？

而且看大家回復，我有8成猜對，有8成以上的架構師，不懂底層，知識面也沒傳說中那麼廣。

現在devops在流行，說白了企業為了省成本，研發要干一部分運維的活。運維只負責硬體網路和k8s維護，其他什麼部署啦，服務編排啦，通通交給程序員做。

不過這樣倒也合理，運維只負責全公司通用的設施建設，至於cicd，服務編排，熔斷限流等等，都和業務強相關，交給開發做比較貼近實際業務

2. 應聘用友的erp軟體維護工程師，面試會問些什麼

首先給你分析一下，他們的職位要求的原因：
1、需要入職者經過一個好的理論環境熏陶過，或者說對一些專業知識、詞語不是很陌生，即方便與ERP的理論結合！
2、ERP軟體維護工程師服務的對象就是客戶，也就是一些生產和物流行業的企業。這點就是要求入職者對一些行業熟悉，即方便與生產和供應鏈的實際流程結合！
3、ERP實施無非就是推項目及解決異常，即方便與理論和實際的結合！
你的條件：
1、本科畢業，計算機和會計專業，其中應該涉及很多ERP相關知識，特別是會計，至於計算機網路你只需要知道基本就可以了，因為用友針對軟體使用過程中由於計算機及網路出現的異常都有FAQ！
2、溝通協調能力你目前僅僅限於理論，不過這個也是你的優勢！
3、CRM客戶關系管理，也可以理解為ERP的一個模塊，不過你也僅僅限於使用！
總結：
1、這個職位基本不需要編程，但是你需要懂一些編程的知識，因為你是客戶（使用者）和程序員之間的關鍵點，你需要將兩者的語言互譯，你可以去網上了解一些簡單的編程知識！
2、多去網上找一些ERP項目推行的計劃書，因為你這個職位主要是做這些，可以去用友官網去找！
3、多去網上找一些ERP的FAQ（異常處理方法）主要針對用友！

3. 工程師與程序員

簡單來說程序員負責軟體產品的設計開發工作，實施工程師負責軟體產品的安裝與運維工作。

4. IT面試經驗：程序員面試什麼最重要

程序員面試一直是社區樂於討論的熱門話題。我自己從06年實習以來，先後經歷了4家軟體公司，全部是外企，其中有世界500強的通信企業，有從事期權期貨交易的歐洲中等規模的金融公司，也有為大型汽車製造商開發Android智能汽車的新興公司。跨入IT行業以來，我在求職過程中經歷過多次面試，最近兩年也有過多次面試別人的經驗。我感覺現在到了對這個問題發表自己看法的時候，這篇文章是我站在面試官角度對於程序員面試問題的一個階段性反思和經驗總結。
目標
相信和不少朋友一樣，有了幾年工作經驗成為Senior後就開始了面試別人的經歷。我在最初這個階段只是按照自己的想像把」找到基礎好的程序員「，」找到演算法能力優秀的程序員「，」找到有Android開發經驗的程序員「等作為面試的目標。但是，實際的經歷告訴我，尤其是按「基礎好」，「演算法好」這些目標招到的人最終效果並不好。比如，有的面試者基礎知識和演算法掌握情況不錯，進程、線程、內存等概念清晰，基本的Hash，二叉樹，快速排序等數據結構和演算法也比較熟悉，但是進公司後在實際工作中表現得很糟糕。後來，我才發現原來是我的面試目標出了問題，我原先的面試方法更像是大學的演算法或操作系統期末考試，按照這種方法讓許多並不合適的人通過了面試，同時也可能錯過了許多合適的人。
後來，我的反思是，從公司的角度講，面試的根本目的是找到「能夠干好工作」的人，而「高學歷」，「演算法好」，「基礎好」，「有經驗」這些都是表象而不是根本，它們並不能直接和「工作好」劃等號。
方法
目標明確了，但接下來的問題是假設面試者是一個黑盒系統，「工作好」不是直接可觀測變數，你所能直接觀測的變數是基礎、演算法、經驗、學歷、性格、談吐、年齡等等。所以，實際上，你只能從「基礎好」，「演算法好」等可以直接觀測的量去推測「工作好」的概率，這就是一個在「X好「條件下」工作好「的條件概率問題：P(工作好 | X好)。
根據這個模型，面試所應該考察哪些方面就很明顯了，那就是選擇那種最具有區分性的方面來考察。比如，考察面試者的體型特徵沒有太大意義，因為P(工作好|高)，P(工作好|矮)，P(工作好|胖)，P(工作好|瘦)的概率都差不多；所以，體型特徵不具有區分性，這不是面試所應該關注的內容。
面試官應當結合職位的要求明確哪些因素具有比較好的區分性。比如，如果要招一名技術門檻比較高的3D游戲引擎開發工程師，面試者A具有3D游戲引擎開發的經驗，但是在基礎知識和演算法面試方面表現一般；面試者B相反，基礎知識和演算法面試表現很好，但沒有游戲開發經驗，而你只能選擇其一。你選誰呢？其實，這就是兩個條件概率問題P(工作好|經驗好，基礎一般，演算法一般）和P(工作好|沒經驗，基礎好，演算法好）。這個問題就留給面試官來判斷了，就我個人而言，對於技術門檻較高需要技術積累的職位，經驗更加說明問題，因此，我更傾向於面試者A。
下面，我再結合自己的經驗談談對面試中常見方面的看法。
演算法
演算法是Google和MS等大公司面試所重點考察的內容。我個人很喜歡演算法，曾經參加ACM/ICPC拿過北京賽區的13名。但是，就個人經驗來看，我所接觸過的絕大多數開發職位而言，演算法都不適合作為考察面試者優劣的主要因素。對於普通的非演算法性開發職位，考察面試者的演算法就相當於考察他打乒乓球好不好一樣，與目標「工作好」的相關性太低。就我個人的經驗來看，差不多P(工作好|演算法好)=50%，也就是演算法面試沒有太大的區分性。
甚至，還有一種很不好的情況特別多地出現在演算法好的面試者身上，我稱之為「只磨刀，不砍柴」。什麼意思呢？有類人只對什麼A*演算法，非同步編程，JVM類載入機制這種純技術問題感興趣，對實現用戶需求毫無興趣。這類人看起來有一定的技術能力，但是對公司來講貢獻十分有限，甚至不如技術一般但認真負責的人。所以，一旦遇到面試者演算法好，我就特別留意考察會不會是這種「只磨刀，不砍柴」的人。
另外，雖然我個人不了解Google和MS，但我對於其特別重視考察演算法能力的面試策略是持懷疑態度的。即使在這樣的世界級大公司，演算法雖然重要，但可以想像在項目實施過程所遇到的各種各樣問題中，演算法問題絕大多數時候不會是主要瓶頸，沒有到那種需要每個人都是演算法高手的情況。實際上，絕大多數項目真正難點並不是一兩個演算法瓶頸，甚至也不是單點的技術瓶頸，而是系統性的組織、協調、設計、開發問題，有大量的看起來不是那麼有技術含量的臟活累活，也有許多問題是由於信息不足，並不是技術能力強就能克服這些困難。一個團隊最好優勢互補，有人演算法強，有人業務分析能力強，有人擅長後端服務，有人擅長前端界面，有人聰明，有人踏實，這是最好的。如果按照「演算法好」的單一標准選材，必定會把許多優秀的人才拒之門外。
基礎
基礎面試是指考察諸如指針使用、進程線程概念等基礎知識的面試，十分類似於大學期末考試題。我曾經以為基礎面試十分重要，但是現在不這么看了。在工作中基礎的確是重要的，但是在面試過程中，它必須具有區分性才有意義，也就是說P(工作好|基礎好)的概率要高，那麼考察指針使用，進程線程區別這樣的基礎題目才有它的意義。我的實際經驗是，基礎面試並不具有很好的區分性，和演算法一樣， 差不多P(工作好|基礎好) = 50%。同時，基礎面試是最容易准備的，中國人有長期的應試教育經驗，要准備幾個把玩指針題目太容易了。
我曾經遇到過這樣的面試者，他的C語言基礎和編譯、鏈接等原理掌握得非常好，給我留下了深刻的印象，我給的面試結論是：知識面不寬，只會C語言，但基礎很扎實，建議錄用。後來的事情證明了那個結論的前半部分是對的，但是」建議錄用「錯了。他在實際工作中表現得一塌糊塗，不理解需求，不理解整體架構；同時，上班時間不是花在項目上，而是花在閱讀諸如《程序員的自我修養》之類的書籍上。最後，這位同事由於長期「不出活」離開了公司。
基礎不是不重要，而是「基礎好」不足以說明面試者能幹好工作，因為基礎是屬於局部性知識，而實際工作需要綜合性能力，二者有天壤之別。C語言、操作系統能考高分，但是不會寫程序的人在大學我們還見得少嗎？ 軟體開發就像蓋房子，綜合能力是設計和搭骨架，基礎知識是碼磚。張小龍原先Foxmail是Delphi開發的，他它不懂C#，你如果要招聘一個開發.NET Email客戶端的人，你考察他對CLR掌握得好不好有意義嗎？ 讓張小龍來開發一個C#版的Foxmail真的會有困難嗎？ 你招一個精通C#但沒有Email客戶端開發經驗的人來真的比張小龍靠譜嗎？
我說基礎知識不重要，和古人說的「不積窪步無以至千里」是不是矛盾呢？不矛盾！「窪步」與「千里」是一種可累加關系，但再多的「基礎知識」都累加不成「綜合能力」。學習軟體開發要像持續集成一樣，一開始就是一個完整的系統，雖然規模不大，問題很多，但它麻雀雖小五臟俱全，從小系統到大系統，從簡單系統到復雜系統逐步演化。
所以，基礎好本身不足以說明太多的問題，必須進一步考察綜合能力。對於基礎面試表現不好的面試者，如果時間允許也要進一步考察，有的面試者其實是有能力的，只是沒有進行充分的准備。最理想的狀態當然是基礎和綜合能力俱佳，若不能兼顧，應當綜合能力優先。
經驗
這里所說的經驗不是通過工作了多少年來衡量的，而主要是指面試者的經歷，比如，是否完整地實現過一個軟體，或作為主要開發者完成過一個項目。經驗的重要性在於它能說明一個人的綜合能力。從項目的性質、規模和難度，面試官就可以大致判斷出面試者的綜合能力。如果一個面試者一直在大公司負責一個小模塊的開發維護，那麼基本可以判斷他不具備獨立或作為主要開發者承擔一個項目的能力，只適合在另一家大公司做類似的事情。對於門檻較高需要長期技術積累的職位，相關經驗更顯得尤為重要，比如，Linux內核開發，JVM開發，游戲引擎開發，資料庫實現，高級UX等。對於這類職位，沒有經驗的面試者即使綜合素質不錯也是需要長時間的學習和積累才能勝任。所以，基本上如果確定了你的職位屬於此類，那麼相關經驗毫無疑問應該成為首選因素，換句話說，P(工作好 | 相關經驗好)的概率是非常高的。
通過項目經驗判斷面試者的優劣比通過基礎和演算法測試更加靠譜，所以，面試過程中面試官應該花比較多的時間聽面試者介紹項目經驗，並進行深入地探討交流，了解面試者的知識面、思維能力、表達能力等。同時，可以結合項目提一些基礎知識和演算法的問題，比如，如果面試者做過C++相關的項目，那就可以問他如何進行內存管理？是否熟悉智能指針？如果面試者的回答不能令人滿意，那麼就基本上可以判斷他的項目做得不是很好。
要注意的是，經驗也是一個多維度的事物。比如，C++股票交易中間件系統，這就涉及(C++，中間件，股票) 3個維度。假如面試者A做過C++股票交易客戶端，面試者B做過C的股票交易中間件。從語言角度看，A最匹配，從項目性質看，B最匹配，你如何選擇？這就是在多個維度中，哪個維度更重要的問題，就這個例子而言，我個人更傾向於B，因為我認為中間件開發經驗是主要矛盾，而從C切換到C++並不是問題。所以，面試官需要判斷哪一種經驗是主要的，而哪一種經驗是次要的。比如，我們招聘Android應用開發，這個職位的Android技術門檻並不高，它的真正難點在於做出好的用戶體驗(UX)。所以，如果一個面試者沒有Android的經驗我們是可以接受的，但是我希望他在UX方面有經驗，至少做過其他平台的移動應用開發。
性格
現在，我來談我認為最重要的因素：性格。這可能是許多初為面試官的朋友所難以想像的，怎麼會是性格最重要呢？說實話，當我意識到這一點時，我自己也很驚訝！說白了，還是 P(工作好|性格好)的概率最高啊。我的實際經驗是，如果一個人的性格好，他能把工作做好的可能性是最高的，性格好遠比基礎好、演算法好要靠譜。
一個人如果技術上有缺陷，經驗上有不足，但性格好，在團隊中是很容易由其他人來補位的，他自己也很容易逐漸補起來；相反，如果一個人的性格不好，所有的技術優勢經驗優勢都發揮不出來，甚至還會起到負作用，而且性格缺點很難改變。我一直談到實際工作所需要的是綜合性的能力，這種綜合能力的發揮中性格是至關重要的。項目中不止會遇到技術問題，要涉及溝通、協調，不同的人不同的部門既有合作又有磨擦，如何處理這些事情都需要一個良好的性格。可以說，在開發團隊里讓你與眾不同的不是你從哪個學校畢業，也不是你過去的經驗，而是你的性格。
當然，性格是一個復雜的東西，它包含了很多的方面，並非所有方面都是程序員面試所需要關注的。我的經驗是可以重點考察這些方面：
1) 態度積極還是消極。有的面試者在談吐中就會自然給你一種積極上進的感覺，或者你可以在他的經歷中發現他積極的因素，這些都不是太難看出來的。相反，有的面試者你能明顯感覺到他的消極情緒。積極性在工作中是十分重要的，積極的人能給團隊帶來朝氣，也更易於合作。基本上，如果確定面試者屬於態度積極的，他通過我這一關的可能性就會大大增加；相反，如果確定屬於態度消極的，即使技術能力不錯我也會十分謹慎。
2) IQ。我的經驗是，總體來看，聰明的人在工作中的表現更為優秀。在面試中要考察一個人是否聰明並不一定要像Google和MS那樣找些專門測試IQ的智力題，其實，你只需要看他討論問題是不是很有邏輯性，思考和說話是不是反應敏捷就可以做出大致的判斷。另外，眼睛是人心靈的窗戶，一個人聰明與否，眼睛是會說話的。不過，聰明也不完全是優點，比如，當公司或項目遇到困難時，往往是聰明人先跑掉了，堅守的往往是IQ一般的人。
3) 語言表達能力。語言表達能力也是程序員十分重要的一項素質，它關繫到項目中的溝通是否順暢。面試官可以看看面試者能否用簡明的語言介紹清楚曾經做過的項目，能否抓住要點，能否考慮到聽者的相關背景。一般來講，語言表達能力強的人綜合能力都不會太差。
4) 是否具有用戶意識。有人說程序員是做研發的，哪來什麼用戶？只有銷售、市場人員才會和用戶打交道。其實，這是完完全全的錯誤認識。你寫一個模塊，甚至一個API，只要有別人用，他就是你的用戶。有的程序員設計一個模塊或是一個軟體總是習慣於從使用者的角度來考慮，盡量地方便使用者，這就是一種良好的用戶意識。具有良好的用戶意識的人更能考慮別人的感受和整體的需要，而不是單純地從自己和局部來思考問題。當面試者談及過去的項目經驗時，面試官可以常常站在用戶的角度對其進行提問，從這個過程中觀察其是否具有良好的用戶意識。
5) 如何應對質疑和壓力。面試官應該對面試者的回答以及以往項目進行合理的質疑，看看他如何應對。曾經有一位面試者談到做游戲登錄伺服器的經歷，我就問：「如果登錄伺服器掛了，怎麼辦呢」？他說原先雖然沒有考慮這個問題，但是可以怎麼怎麼改進。其實，大家都理解項目中有各種不完美，這裡面原因很多，只要面對質疑和壓力能從容應對努力往好的方向思考解決就可以了，不需要掩飾缺陷，更不應該有情緒。我遇到過有的面試者，一旦你對其項目提出質疑，他馬上產生反抗情緒，或不高興，或不承認有問題，這很容易一下子看出來他在工作中容不得質疑和批評，這種人要想合作就很困難。
6) 個性特點。許多面試者喜歡在簡歷上寫「精通C++/Linux「，這些字眼看得人麻木，如果有人寫」喜歡C++/Linux「，我就會有一種眼前一亮的感覺。「精通」是沒有感情色彩的敘述，而「喜歡」包含了面試者的個性，我更願意看到面試者的個性。我相信對某樣東西真正的熱情遠比你當前對它的掌握程度更為重要。其實，N年的經歷告訴我們，同一個班的同學，同一個項目組的同事，雖然每天所學的知識，所接觸的工作都是相同的，但其實每個人的成績和表現差異是十分明顯的。那麼，到底本質的差異是什麼呢？其實，就是每個人的個性。是個性使得有的人業余時間去打球，有的人業余時間去看書，有的人喜歡Linux，有的人喜歡Mac。一個人在團隊中扮演的角色也和他的個性有很大的關系。面試官應該引導面試者展現自己的個性，並判斷其是否有益於團隊。
總結
最後總結起來，我的經驗是： 1) 面試官的目標是找到」工作好「的人，一定要圍繞這個目標來進行面試，如果把面試當成了演算法或操作系統期末考試這就走入了誤區；2) 面試過程是通過學歷、性格、基礎、經驗、演算法等可以測試的因素去綜合判斷面試者「工作好」的概率；3) 在各種因素中，性格 > 經驗 > 基礎 > 演算法。性格是最重要的，如果性格不好，所有技術能力都會大打折扣，而且技術缺陷容易彌補，性格缺陷很難改變；經驗體現了一個人的綜合能力，你可以從面試者過去的經歷中判斷他能從事哪種工作，不能從事哪種工作；基礎和演算法則主要起到輔助參考的作用，基礎好的程序員一般適應性比較強，學新技術更快，但是切忌單純從基礎來判斷一個人的能力。

5. 實施工程師面試的話一般會問些什麼問題

1、根據你的經驗說說你對軟體測試/質量保證的理解？軟體質量保證與測試是根據軟體開發階段的規格說明和程序的內部結構而精心設計的一批測試用例（即輸入數據和預期的輸出結果），並利用這些測試用例去運行程序，以發現錯誤的過程。它是對應用程序的各個方面進行測試以檢查其功能、語言有效性及外觀排布.2、軟體測試的流程是什麼？需求調查: 全面了解您的系統概況、應用領域、軟體開發周期、軟體開發環境、開發組織、時間安排、功能需求、性能需求、質量需求及測試要求等根據系統概況進行項目所需的人員、時間和工作量估計及項目報價。制定初步的項目計劃: 在與您充分共同和協商的基礎上制定我們的測試計劃。測試准備: 組織測試團隊、培訓、建立測試和管理環境等。測試設計: 按照測試要求進行每個測試項的測試設計，包括測試用例的設計及測試腳本的開發等。測試實施: 按照測試計劃進行實施測試。測試評估: 根據測試的結果，出具測試評估報告。3、(1) 你對SQA的職責和工作活動(如軟體度量)的理解：SQA就是獨立於軟體開發的項目組，通過對軟體開發過程的監控，來保證軟體的開發流程按照指定的CMM規程（如果有相應的CMM規程），對於不符合項及時提出建議和改進方案，必要是可以要高層經理匯報以求問題的解決。通過這樣的途徑來預防缺陷的引入，從而減少後期軟體的維護成本。SQA主要的工作活動包括制定SQA工作計劃，參與階段產物的評審，進行過程質量、功能配置及物理配置的審計等;對項目開發過程中產生的數據進行度量等等；(2) 說說你對軟體配置管理的理解：項目在開發的過程中要用相應的配置管理工具對配置項（包括各個階段的產物）進行變更控制，配置管理的使用取決於項目規模和復雜性能及風險的水平。軟體的規模越大，配置管理就顯得越重要。還有在配置管理中，有一個很重要的概念，那就是基線，是在一定階段各個配置項的組合，一個基線就提供了一個正式的標准，隨後的工作便基於此標准，並且只有經過授權後才能變更這個標准。配置管理工具主要有CC,VSS,CVS等，偶只用過CVS，對其它的不熟悉(3) 怎樣寫測試計劃和測試用例：簡單點，測試計劃里應有詳細的測試策略（測試方法等），合理詳盡的資源安排等，至於測試用例，那是依賴於需求（包括功能與非功能需求）是否細化到功能點，是否可測試等。(4) 說說主流的軟體工程思想(如CMM，CMMI，RUP，XP，PSP，TSP等)的大致情況以及對它們的理解：CMM:SW Capability Maturity Model 軟體能力成熟度模型,其作用是用於軟體過程的改進、評估及軟體能力的評鑒CMMI:Capability Maturity Model Integration能力成熟度模型集成CMMI融入了大部分最新的軟體管理實踐，同時彌補了SW-CMM模型中的缺陷RUP:rational unified process 是軟體工程化過程。XP：extreme program，即極限編程的意思，適用於小型團隊的軟體開發，想上面第三個問題就可以結合原型法採用這樣的開發流程。要明白測試對於xp開發的重要性，強調測試（重點是單元測試）先行的理念。編程可以明顯提高代碼的質量，持續集成對於快速定位問題很有好處。PSP ,TSP 分別是個體軟體過程（Personal Software Process），群組軟體過程（Team Software Process）大家都知道，CMM只是告訴你怎麼做但並沒有告訴你如何做，所以PSP/TSP就是告訴你企業在實施CMM的過程中如何做，PSP強調建立個人技能（如何制定計劃、控制質量及如何與其他人相互協作等等）而TSP著重於生產並交付高質量的軟體產品（如何有效地規劃和管理所面臨的項目開發任務等等）。總之，單純實施CMM，永遠不能真正做到能力成熟度的升級，只有將實施CMM與實施PSP和TSP有機地結合起來，才能發揮最大的效力。因此，軟體過程框架應該是CMM/PSP/TSP的有機集成。4、還有問一下你是怎樣保證軟體質量的，也就是說你覺得怎樣才能最大限度地保證軟體質量？測試並不能夠最大限度的保證軟體的質量，軟體的高質量是開發和設計出來的，而不是測試出來的，它不僅要通過對軟體開發流程的監控，使得軟體開發的各個階段都要按照指定的規程進行，通過對各個階段產物的評審，QA對流程的監控，對功能及配置的審計來達到開發的最優化。當然測試也是保證軟體質量的一個重要方式，是軟體質量保證工程的一個重要組成部分。5、然後緊接著就基於目前中國的國情，大多數公司的軟體項目進度緊張、人員較少、需求文檔根本沒有或者很不規范，你認為在這種情況下怎樣保證軟體的質量？(大多數公司最想知道的就是在這種困難面前你該怎麼保證軟體的質量，因為這些公司一般就是這種情況—–既不想投入過多又想保證質量，faint )出現以上的情況，如果僅僅想通過測試來提高軟體質量，那幾乎是不可能，原因是沒有足夠的時間讓你去測試，少而不規范的文檔導致測試需求無法細化何談足夠且有針對性進行測試。所以，作為公司質量保證的你應該先和項目經理確定符合項目本身最適合的軟體生命周期模型（比如RUP的剪裁，原型法）,明確項目的開發流程並督促項目組按照此流程開展工作，所有項目組成員（項目經理更加重要）都要制定出合理的工作計劃，加強代碼的單元測試，在客戶既定的產品交付日期范圍之內，進行產品的持續集成等等，如果時間允許可以再配合客戶進行必要的系統功能測試。6、一個測試工程師應具備那些素質和技能？1、掌握基本的測試基礎理論 ；2、本著找出軟體存在的問題的態度進行測試,即客觀吧,不要以挑刺形象出現3、可熟練閱讀需求規格說明書等文檔 ；4、以用戶的觀點看待問題5、有著強烈的質量意識 ；6、細心和責任心 ；7、良好的有效的溝通方式(與開發人員及客戶)8、具有以往的測試經驗 ；能夠及時准確地判斷出高危險區在何處.7、做好軟體測試的一些關鍵點1.測試人員必須經過測試基礎知識和理論的相關培訓。2.測試人員必須熟悉系統功能和業務。3.測試必須事先要有計劃，而且測試方案要和整個項目計劃協調好4.必須事先編寫測試用例，測試執行階段必須根據測試用例進行5.易用性，功能，分支，邊界，性能等功能性和非功能性需要都要進行測試6.對於復雜的流程一定要進行流程分支，組合條件分析，再進行等價類劃分准備相關測試數據7.測試設計的一個重要內容是要准備好具體的測試數據，清楚這個測試數據是測哪個場景或分支的8.個人任務平均每三個測試用例至少應該發現一個BUG，否則只能說明測試用例質量不好9.除了每日構建的冒煙測試可以考慮測試自動化外，其它暫時都不要考慮去自動化。8、軟體測試員自身素質培養（1）首先，應對軟體測試感興趣和對自己有自信，如果具備了這兩點，那麼在開發過程中不管遇到什麼樣的困難，我相信你一定能克服。（2）善於懷疑，世界上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發生的事，我卻認為可能發生。別人認為是對的，我卻認為不是對的。（3） 打破砂鍋問到底的精神，對於只出現過一次的bug，一定找出原因，不解決誓不罷休。（4） 保持一個良好的心情，否則可能無法把測試作好。不要把生活中的不愉快的情緒帶到工作中來。（5） 做測試時要細心，不是所有的bug都能很容易的找出，一定要細心才能找出這些bug。（6） 靈活一些，聰明一點，多製造一些容易產生bug的例子。（7） 在有條件的情況下，多和客戶溝通，他們身上有你所需要的。（8） 設身處地為客戶著想，從他們的角度去測試系統。（9） 不要讓程序員，以「這種情況不可能發生」這句話說服你，相反，你應該去說服他，告訴他在客戶心裡，並不是這樣的。（10） 考慮問題要全面，結合客戶的需求、業務的流程、和系統的構架，等多方面考慮問題。（11）提出問題不要復雜化，這一點和前面的有點矛盾，如果你是一新手，暫時不要管這一點，因為最終將有你的小組成員討論解決。（12） 追求完美，對於新測試員來說，努力的追求完美，這對你很好，盡管有些事無法做到，但你應該去嘗試。（13）幽默感，能和開發小組很好的溝通是關鍵，試著給你的開發小組找一個「BUG殺手」，或對他們說「我簡直不敢相信，你寫的程序居然到現在沒有找到BUG」。（14）到此是不是對測試很有興趣呢？不過我要告訴你，測試過程中有酸甜苦辣，其中的滋味只有你知道，也許你會感到枯燥，要學會放鬆自己，去溜冰或做你喜歡做的事，不過，別放棄，因為你的自信告訴過你「你會是很優秀的測試員」不是嗎？9、為什麼要在一個團隊中開展軟體測試工作？因為沒有經過測試的軟體很難在發布之前知道該軟體的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測試的工作。在測試的過程發現軟體中存在的問題，及時讓開發人員得知並修改問題，在即將發布時，從測試報告中得出軟體的質量情況。10、您所熟悉的軟體測試類型都有哪些？測試類型有：功能測試，性能測試，界面測試。功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。界面測試，界面是軟體與用戶交互的最直接的層，界面的好壞決定用戶對軟體的第一印象。11、您認為做好測試用例設計工作的關鍵是什麼？白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果黑盒用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入介面。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：1、是否有不正確或遺漏的功能？2、在介面上，輸入是否能正確的接受？能否輸出正確的結果？3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？4、性能上是否能夠滿足要求？5、是否有初始化或終止性錯誤？軟體的白盒測試是對軟體的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：1、對程序模塊的所有獨立的執行路徑至少測試一遍。2、對所有的邏輯判定，取「真」與取「假」的兩種情況都能至少測一遍。3、在循環的邊界和運行的界限內執行循環體。4、測試內部數據結構的有效性，等等。4、驗收測試是部署軟體之前的最後一個測試操作。驗收測試的目的是確保軟體准備就緒，並且可以讓最終用戶將其用於執行軟體的既定功能和任務。驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有的模塊組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是驗收測試的任務，即軟體的功能和性能如同用戶所合理期待的那樣。12、測試計劃工作的目的是什麼？測試計劃工作的內容都包括什麼？其中哪些是最重要的？軟體測試計劃是指導測試過程的綱領性文件，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟體測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試策略和測試方法（最好是能先評審）13、您認為做好測試計劃工作的關鍵是什麼？1. 明確測試的目標，增強測試計劃的實用性編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試計劃的價值取決於它對幫助管理測試項目，並且找出軟體潛在的缺陷。因此，軟體測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、准確2．堅持「5W」規則，明確內容與過程「5W」規則指的是「What（做什麼）」、「Why（為什麼做）」、「When（何時做）」、「Where（在哪裡）」、「How（如何做）」。利用「5W」規則創建軟體測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟體的存放位置（Where）。3．採用評審和更新機制，保證測試計劃滿足實際需求測試計劃寫作完成後，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟體需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。4. 分別創建測試計劃與測試詳細規格、測試用例應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。14、 您所熟悉的測試用例設計方法都有哪些？1．等價類劃分2．邊界值分析法3．錯誤推測法4．因果圖方法15、你的測試職業發展是什麼？測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步步向著高級測試工程師奔去。而且我也有初步的職業規劃，前3年累積測試經驗，按如何做好測試工程師的11，12點要求自己，不斷的更新自己改正自己，做好測試任務。17、你自認為測試的優勢在哪裡？優勢在於我對測試堅定不移的信心和熱情，雖然經驗還不夠，但測試需要的基本技能我有信心在工作中得以發揮。18、當開發人員說不是BUG時，你如何應付？開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好後再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據是什麼？如果被用戶發現或出了問題，會有什麼不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最後的確認。

6. 軟體實施工程師具體是做什麼的

軟體實施工程師主要負責工程實施： 包括常用操作系統、應用軟體及公司所開發的軟體安裝、調試、維護，還有少部分硬體、網路的工作； 負責現場培訓： 現場軟體應用培訓； 協助項目驗收； 負責需求的初步確認；把控項目進度；與客戶溝通個性化需求； 負責項目維護。

大量的軟體公司項目實施案例證明，軟體項目是否成功、用戶的軟體使用情況是否順利、是否提高了用戶的工作效率和管理水平，不僅取決於軟體產品本身的質量，軟體項目實施的質量效果也對後期用戶應用的情況起到非常重要的影響。

項目實施規范主要包括項目啟動階段、需求調研確認階段、軟體功能實現確認階段、數據標准化初裝階段、系統培訓階段、系統安裝測試及試運行階段、總體驗收階段、系統交接階段等八個階段工作內容，

每個階段下面有不同的工作事項，各個階段之間都是承上啟下關系，上一階段的順利完成是保證下一階段的工作開展的基礎。

(6)程序員實施工程師面試題擴展閱讀

崗位職責：

1、負責客戶售前售後技術支持及銷售人員的售前售後的技術輔助；

2、負責客戶軟體安裝與調試；

3、負責客戶的現場培訓及現場答疑；

4、負責客戶售前售後的技術問題答疑、處理及維護;

5、參與項目招投標相關技術內容的籌備，負責標書技術部分的編寫及答疑、應標等；

6、協助公司各部門工作，排除相關技術障礙;

7. 實施工程師和程序員有什麼區別

實施工程師，就是指軟體實施工程師，其與程序員的區別如下：

軟體實施工程師的工作是軟體產品服務主線的一個決定性環節，軟體的成功離不開實施。負責工程實施： 包括常用操作系統、應用軟體及公司所開發的軟體安裝、調試、維護，還有少部分硬體、網路的工作； 負責現場培訓： 現場軟體應用培訓； 協助項目驗收； 負責需求的初步確認； 負責項目維護。

一般的程序員都有四年的在專業領域的學習，需要一個在程序領域的學士學位獲得者，不論是數學方面的還是工程方面的都是可以的。
大約有20%的人在這一領域的計算機科學和工程學擁有更高的學位。還有很小一部分程序員是自學的，盡管一些專業性的學校或者綜合大學可以提供，但是也需要一些別的途徑來提供相關的人才。盡管學歷是比較重要的，但是公司經常把重點放在應聘者的工作經驗上，很多剛從大學畢業的大學生雖然有引人注目的學位證書，但是他們找不到工作是因為他們缺乏經驗。一個程序員雖然沒有正規的學歷，但是如果一個人擁有程序設計的深厚知識背景或者豐富的工作經驗的話，那麼他的機會要比有學歷的應屆畢業生大得多。所以要盡量抓住有用的工作和實習機會，這樣的話在畢業後你就會發現，多實習讓你有更多的經驗，在找工作的時候就有更多的機會。
對於職業程序員，另外一個重要的方面就是，程序員需要不斷提升自己的業務技術，他的技術必須一直保持在一個較高的水平，並且要不斷發展，程序員也要尋找貿易的機會，要參加研討會，在周刊上發表文章和接受職業教育，這些使程序員在自己的領域中分級或者不斷並排前進。

8. 程序員和軟體工程師，軟體實施工程師，項目經理有什麼區別，級別怎麼排哪個更有前途

程序員和軟體工程師是沒有什麼區別的，不過是叫法不同罷了，是純技術的。實施工程師有點偏向於和客戶交流，但懂軟體的安裝和使用，要求好的口才和應變能力。項目經理是最牛的，不過一般的剛畢業的學生難以勝任的，都是要有3-5年經驗的才可以的。一般人都是從程序員開始的，慢慢走向項目經理或銷售經理。

9. 程序員與工程師

有很多的公司他們會把程序員也稱為工程師，所以程序員是工程師這一個大集合當中的一個子集，而工程師是不包含在程序員這個概念裡面的。

10. 用技能的分類來分析你對 「學問好不如做事好,做事好不如做人好」的理解。

舉個例子吧。
就拿軟體來說事，程序員的職場規劃：程序員----實施工程師---項目經理
學問好不如做事好，就比如，程序員會寫代碼，這是專業技能。
但項目做完了要到客戶那去實施丫，不懂安裝調bug，解決突發狀況的話是不行的哦。
這是應急處理實戰技能。這樣，次數多了，跟客戶溝通多了，了解客戶需求多了，
懂得客戶的需求了，知道如何為客戶打消顧慮了。
這些只有經驗豐富的項目經理才有的哦。這叫溝通領導的技能。
所以軟實力才是我們職業生涯要增長的東西。