程序員基礎扎不紮實，對實際的開發工作有什麼影響？

12-23

一直覺得程序員面試的時候問的一些問題，在平時開發過程中用到的概率很小。也可能是我的開發經驗少？

遇到問題都不知道搜什麼關鍵詞。

沒學過的話，很多東西你就不會覺得它有用，因為需要用到的時候你也認識不到是這裡出了問題。

你努力奔跑的時候，有些人在飛。而你甚至從來沒有抬過頭。
＝＝＝＝＝＝＝＝＝＝＝
有些面試題，對具體的招聘者的項目確實沒用，或者當時那個階段對他們沒用，他們就是隨便網上找份面試題抄了給你答而已。但是知識對於你漫長的一生，就不一定在哪裡會起作用了。

我以前過馬路的時候從來都不懼汽車，想著萬一車撞了我也是車主的責任。

後來自己考駕照了，雖然離買車還很遙遠，但想著萬一這司機跟我一樣菜，撞了可是會死人的！於是過馬路老實多了。

那麼，你覺得我現在買不起車，學駕照有用么？

無知者不僅無畏，還可能生活在另一個維度。

基礎不好的話，會經常性的給隊友挖坑。

就像是給你的事業蓋樓。隨便蓋個二層小別墅還是沒什麼問題的，但是建起摩天大樓的那種標誌性建築，就幾乎很難了。

就是知其然不知其所以然，如果基礎不紮實，那麼能做東西，但是遇到bug就毫無頭緒了，只能瞎貓碰上死耗子賭運氣了。

不是專業程序員。藝術背景，後來碩士去了一個交互項目，開始學著寫PROCESSING, ARDUINO，後來開始接觸OOP，寫OPENFRAMEWORKS(C++)。最近在學習OPENGL。這麼斷斷續續的，也倒騰三年了。當時學習編程，就只為prototyping，不求效率，不求團隊合作，只要run10次成功一次就好，各種編程習慣自然糟蹋透頂。
後來畢業，開始參與一些很大的交互裝置項目，二三十個人的DEV團隊。角色這邊叫做Creative Technologist。第一個項目來，就把隊友坑死了。（捂臉

一來是代碼組織糟糕，東西一窩蜂的放到一個CLASS裡面，結果代碼基本不可讀……
二來是一些約定俗成的習慣不知道，比如變數命名啥的，結果溝通起來也就困難……
三來是自己坑不住自己的代碼，因為沒有系統學過DESIGN PATTERN，所以自然想到啥寫啥，結果可想而知，第二天打開，想要改個東西，然後自己都被自己的代碼震驚了，趕緊關上編譯器去上廁所……

目前為止大概就是這樣。總結一下就是，如果基礎不紮實，慢點其實沒關係，大不了少睡點，但是關鍵是，遇到情況，你知識儲備不足的話你就壓根意識不到有更好的解決方案。這樣隨著項目推進，代碼質量也就越來越差。最後坑掉全隊。

走了……我還是去做我自己的藝術裝置去吧……

你的感覺並沒有錯，基礎不紮實對實際開發肯定是有影響的，這個無需質疑。

只是大多數公司根本搞不清什麼才是基礎。

舉例來說校招筆試面試永遠只考200行以內必能搞定的演算法題（其實目前我連超過100行的演算法題都沒見過），卻從來不考需要千行規模才能實現的小型程序系統。而後者所需的技能和素養在實際工作中往往比前者更重要，我想之所以不考估計是考察期太長不適合作為必須在短時間內完成的筆試和面試來用。反正不看應聘者千行規模代碼的公司基本都可以認為他們不覺得合理組織代碼、設計靈活程序架構也算是基礎能力之一。

另外我也很詬病筆試題出基本概念題，把這也作為基礎來考察，尼瑪，人的記憶是會遺忘的，你早幾年考我肯定記得，現在考我幾個意思，我google給你算嗎？這樣玩兒有意思嗎？當然學霸、大牛過目不忘肯定沒問題，我等凡人還是要複習複習才能應試的。好吧我其實只是發泄一下那些包括我在內的只想努力寫優秀code不願刷題卻最終被刷題黨淘汰筆面的不甘吧。

純屬個人觀點，大牛盡情反駁。

我是多麼的希望那些認為面試中出現的"不常用的技術"的人把那個技術說出來讓俺們見識下啊..

解決問題只能達到解決的目的，但路上會挖好多坑……

只知道開調試器和瘋狂重現, 測試. 就是不知道對代碼靜態分析, 眼睛找bug!

還有一點，就是學習新技術時基礎紮實的能夠把主要精力放在關鍵點上，基礎不紮實的要不停的補充以前落下的盲點，阻礙比較大。就像背書一樣，基礎紮實的朗誦幾遍就會了，你還得回頭查這個字該怎麼讀。

你的問題和你的描述有些出入，建議修改題目。以下是針對你描述的。

面試和實際工作本來就不對等，人家不能上來就問你工作上的問題，你又沒有上下文背景，有些人也沒有實習/工作經歷，比如應屆生。

那該問什麼的？很多時候是圍繞你的簡歷來的，如果你的簡歷中提到你演算法什麼的不錯，請可能會讓你解釋一些要點，描述一些解決方法和思路等等。面試官自己不一定很清楚你提到的東西，但通過其他方面大致可以判斷你是否了解。

還有一種情況，你的簡歷中描述的內容和現在公司工作內容相差太大，你很幸運沒有在HR篩選階段被pass掉的話，面試官也可能憑空出一些工作上的基礎問題，因為和你的技術交集實在太少。這個時候其實不是人家出什麼題的問題，而是你的簡歷問題了。

至於筆試上，沒可能按照個別的人來定，所以是選擇平均水平定題目的。有些會和工作相關，有些純粹是基礎題，畢竟要平衡純技術的和有經驗的。

題主所感受到的面試問題與實際開發的區別其實就是因為上面的面試出題傾向而已，這點沒有必要去深究，對方全問你工作上的，除非你完全對口否則你肯定通不過。招聘方也要考慮留一些餘地供發展。

至於基礎題，大部分人認為基礎不會上層的專業題肯定也不行，不能說沒有道理。但是類似TCP是哪幾個字母的縮寫你不知道就不會寫socket程序這種是偏見，大可以轉移對方問題到自己熟悉的領域，不過這種還是需要工作幾年的人才能明白。所以最好的方法就是你找一本基礎書看一遍，除非你確實實際經驗豐富，否則重心還是放在基礎上。基礎非常好和實際工作經驗很符合的人相比其實後者更有吸引力。

總結一下，面試是面試，工作是工作。建議還是不要過度解決招聘背後的這種衡量。

去年來了個還沒畢業的實習生，聽說是某某某的兒子，想來體驗開發工作，就隨便安排他先折騰一下虛擬項目練手。
我見他將外部輸入字元串用小圓點拼接成SQL語句，然後直接用來操作資料庫，需要查三個欄位就執行了三次查詢指令。還看見一行注釋 //echo "zhengchang&";。後來沒體驗多久就回去學校操辦畢業的事情，之後就很少聯絡了，說是投身網路設備行業了。
不過前不久說準備結婚了，看照片對象還挺漂亮的。。。

基礎不紮實的最大壞處就是考慮問題的思路太窄（拿dota來類比，豬隊友，補刀殺人水平過不去），短時間內不太容易造成太多的壞處（偶爾被kill、double kill差距還看不出來），長遠的影響更多一些（被殺次數一多，大經濟差距就被拉開），如果有個強力的隊友還好，一些風險還能被控制住（強力反殺能力），但是有時候神也架不住豬隊友亂送死。

總結一句話，沒出問題的主要原因是因為你有個實力還行的團隊。

1. 用專業名字解釋一個東西發現對方不懂，於是得打比方解釋
2. 能搜索到的東西每次都是張嘴跑去問別人

程序員是個體力活，基礎不好，多健身增強體質。

一、造輪子，重複實現框架，或者庫中已經實現的東西，而且實現的性能比人家差，功能還不一定完全。
二、走彎路，用笨辦法去實現一些東西。例如用加法解決乘法的問題。

不知道。
我現在知道的是，基礎不紮實，連工作都找不到。
——剛剛面跪T的大三狗如是說道

蓋樓打的地基不牢固你說對蓋樓有沒有影響
一個道理
最後送你一段話
基礎好到什麼時候都不多餘
基礎不好總有你先露出來的那一天