校招筆試全解析:從基礎(chǔ)考點到編程題實戰(zhàn)復(fù)盤)
那年秋招我在很長一段時間里都在投客戶端開發(fā)方向的崗位。點我達2019屆校招這場筆試是我印象比較深的一次。倒不是說題目有多偏多難而是它的考察范圍非常典型幾乎把客戶端開發(fā)校招筆試該覆蓋的考點都過了一遍兼具廣度和深度。如果你正準(zhǔn)備客戶端開發(fā)相關(guān)崗位的校招筆試這篇文章可以當(dāng)作一份復(fù)盤筆記來看我會把當(dāng)時這場筆試的題型分布、核心考點、易錯點和編程題的解題思路都拆開講清楚也會聊一些在普通面經(jīng)里不太會寫到的臨場細(xì)節(jié)。先說結(jié)論這類筆試整體難度屬于中上但真正拉開差距的往往不是最后那道壓軸算法題而是前面選擇題里那些“好像會、一選就錯”的基礎(chǔ)概念?;A(chǔ)不牢后面編程題寫得再順手總分也可能被拖下去。1. 筆試題型拆解一份典型的客戶端開發(fā)筆試拿到手先看什么1.1 題型分布與分值結(jié)構(gòu)我參加的那場筆試是線上限時答題總共120分鐘題量不算小。整體分為三個部分客觀題單選多選、簡答題、編程題。具體的分值分布大概是這樣的題型數(shù)量分值占比考察側(cè)重單選20題左右約30%數(shù)據(jù)結(jié)構(gòu)、操作系統(tǒng)、網(wǎng)絡(luò)、語言基礎(chǔ)多選10題左右約15%概念辨析、邊界條件、易混淆知識點簡答2~3題約15%客戶端機制理解、方案設(shè)計編程2題約40%算法實現(xiàn)、代碼規(guī)范性、復(fù)雜度意識客觀題一共占了近一半的分?jǐn)?shù)這其實是非常常見的校招筆試結(jié)構(gòu)。很多準(zhǔn)備筆試的同學(xué)容易把精力全壓在編程題上進了考場才發(fā)現(xiàn)前面那些選擇題做起來并不輕松——每個選項都在“對與不對”的邊緣反復(fù)橫跳特別是多選題少選漏選都拿不到分。建議拿到試卷后先快速瀏覽一遍所有題目對編程題的難度心里有個數(shù)然后倒過來從客觀題開始逐項推進。不要一上來就死磕某道選擇題任何一道題超過三分鐘沒有明確思路先標(biāo)記跳過。1.2 為什么筆試要考這些內(nèi)容作為客戶端開發(fā)崗位的候選人你得先想清楚一個問題公司為什么要在筆試環(huán)節(jié)考這些內(nèi)容點我達這類業(yè)務(wù)形態(tài)的公司核心產(chǎn)品是一個高頻使用的移動應(yīng)用一端連著配送員一端連著商戶和用戶。客戶端開發(fā)工程師要面對的遠(yuǎn)不只是“寫頁面”這件事——地圖定位的持續(xù)回調(diào)、訂單狀態(tài)的實時推送、弱網(wǎng)環(huán)境下的接口請求重試、長列表的滑動性能、App崩潰率的控制每一樣都是真實的線上問題。所以筆試不會只考API怎么調(diào)用它會通過基礎(chǔ)題看你有沒有扎實的計算機功底通過客戶端機制題看你是不是真懂Android或iOS的底層運行原理通過編程題看你能不能寫出健壯、高效、可維護的代碼。換句話說筆試篩選的不只是“會寫代碼的人”而是“能在這個業(yè)務(wù)場景里把代碼寫穩(wěn)的人”。理解到這一層你在準(zhǔn)備筆試時的側(cè)重點就會不一樣單純刷LeetCode不夠還得把操作系統(tǒng)、網(wǎng)絡(luò)、客戶端機制這些“地基”補牢。2. 核心考點深度解析高頻知識點與出題意圖2.1 數(shù)據(jù)結(jié)構(gòu)與算法不只是刷題數(shù)量的問題這部分是客觀題和編程題的重疊區(qū)??陀^題里考察的數(shù)據(jù)結(jié)構(gòu)知識點主要集中在數(shù)組和鏈表的操作復(fù)雜度對比、棧和隊列的應(yīng)用場景、二叉樹的遍歷方式、哈希表的沖突處理、排序算法的穩(wěn)定性和復(fù)雜度。其中“排序算法在不同場景下的選擇”是出現(xiàn)頻率非常高的考點。比如題目會給出一組近乎有序的數(shù)據(jù)問你用哪種排序效率最高——這就是在考察插入排序?qū)跤行驍?shù)據(jù)集的適應(yīng)能力而不是讓你直接背快排的時間復(fù)雜度。只有真正理解每種排序的“數(shù)據(jù)敏感度”現(xiàn)場才能快速判斷。算法題的考察方向則集中在字符串處理、鏈表操作、二叉樹相關(guān)的遞歸、動態(tài)規(guī)劃入門級問題以及一些基于業(yè)務(wù)場景的模擬題。點我達的業(yè)務(wù)和LBS強相關(guān)所以筆試?yán)锍霈F(xiàn)過類似“計算兩個坐標(biāo)點之間的距離”“按照距離對一批點排序”這類題目。這類題本身不復(fù)雜但它提醒你準(zhǔn)備客戶端筆試時幾何計算和空間數(shù)據(jù)處理的基本思路要有一點概念這些知識在真實業(yè)務(wù)里很常用。字符串處理的題是校招筆試的常客幾乎不會缺席。常見的有字符串去重、字符統(tǒng)計、最長公共前綴、反轉(zhuǎn)字符串等。這類題難度不大但非??简灳幋a基本功邊界條件處理、空指針判斷、字符編碼的處理、時間復(fù)雜度的控制全是踩分點。我的建議是字符串相關(guān)的題型不要只看解題思路一定要自己手寫一遍完整代碼因為這類題最容易出現(xiàn)“思路對、代碼編譯不過”的尷尬局面。2.2 操作系統(tǒng)與計算機網(wǎng)絡(luò)客戶端開發(fā)繞不開的兩座山很多科班同學(xué)在大學(xué)里學(xué)過操作系統(tǒng)和計算機網(wǎng)絡(luò)但備考客戶端崗位時容易輕視這兩門課覺得“客戶端開發(fā)用不到那么底層的東西”。這個想法在校招筆試?yán)飼艹蕴潯2僮飨到y(tǒng)的高頻考點包括進程和線程的區(qū)別、線程同步的幾種方式互斥鎖、信號量、條件變量、死鎖產(chǎn)生的四個必要條件、虛擬內(nèi)存和頁面置換算法、進程間通信的方式。選擇題往往會給出幾個容易混淆的說法讓你判斷正誤比如“線程是資源分配的基本單位進程是調(diào)度的基本單位”這種經(jīng)典的錯誤表述。而簡答題可能會讓你設(shè)計一個“多線程下載”的方案任務(wù)怎么拆、線程池大小怎么定、下載失敗怎么重試、多個線程寫同一個文件如何保證數(shù)據(jù)不沖突。這已經(jīng)不只是考概念而是考你能否用操作系統(tǒng)知識解決實際工程問題。計算機網(wǎng)絡(luò)的重點則集中在TCP和UDP的區(qū)別、TCP三次握手和四次揮手的過程、HTTP和HTTPS的差異、HTTP常見狀態(tài)碼的含義、DNS解析過程。由于客戶端的主要工作是網(wǎng)絡(luò)請求的發(fā)送和數(shù)據(jù)的解析所以HTTP協(xié)議相關(guān)的內(nèi)容考察得非常細(xì)。比如“HTTP的長連接和短連接分別適用于什么場景”“TCP擁塞控制在弱網(wǎng)環(huán)境下對App請求有什么影響”這些都屬于客戶端開發(fā)的高頻面試題在筆試?yán)锿瑯訒霈F(xiàn)。準(zhǔn)備這部分內(nèi)容推薦拿著Charles或Wireshark實際抓包看幾次請求和響應(yīng)把協(xié)議頭字段對應(yīng)到真實流量上理解深度會好很多。2.3 客戶端平臺基礎(chǔ)Android與iOS的核心機制這部分是真正區(qū)分“認(rèn)真準(zhǔn)備過客戶端開發(fā)”和“海投碰運氣”的考點的環(huán)節(jié)。如果投的是Android方向Activity生命周期是必考內(nèi)容而且往往會結(jié)合場景出題比如屏幕旋轉(zhuǎn)時Activity會經(jīng)歷哪些回調(diào)、A頁面跳轉(zhuǎn)到B頁面時兩個頁面的生命周期回調(diào)順序是什么、App退到后臺再回來時會發(fā)生什么。這些看似基礎(chǔ)但細(xì)節(jié)非常多不同場景下的執(zhí)行順序很容易混淆。我的復(fù)習(xí)方法是把幾個常見場景的生命周期調(diào)用順序自己手寫一遍整理成表格反復(fù)對照直到完全形成條件反射。Android的消息機制、Handler和Looper的關(guān)系、主線程和子線程的通信方式也是考察重點。還有內(nèi)存優(yōu)化相關(guān)的內(nèi)容內(nèi)存泄漏的常見場景Handler持有Activity引用、靜態(tài)Context引用、未注銷的BroadcastReceiver、內(nèi)存抖動和GC機制、ANR的原因分析和避免方式。這些都是客戶端開發(fā)日常工作中一定會遇到的問題筆試考察它們非常合理。如果投的是iOS方向運行時機制、消息傳遞機制、內(nèi)存管理引用計數(shù)、循環(huán)引用、多線程方案GCD、NSOperation是核心考察點。因為點我達的客戶端是Android和iOS雙端都在做筆試主體雖然以Android為主但也出現(xiàn)了少量iOS相關(guān)題目。我的建議是主攻一端但對另一端的基本概念至少做到“聽說過、不陌生”避免出現(xiàn)整道題完全看不懂的情況。2.4 語言基礎(chǔ)Java是Android開發(fā)的根雖然現(xiàn)在Kotlin在Android開發(fā)中的占比越來越高但很多筆試仍然默認(rèn)考察Java基礎(chǔ)。比如String、StringBuilder、StringBuffer的區(qū)別HashMap的底層實現(xiàn)原理數(shù)組鏈表紅黑樹ArrayList和LinkedList的性能對比Java內(nèi)存區(qū)域的劃分堆、棧、方法區(qū)、本地方法棧、程序計數(shù)器GC回收機制和常見的垃圾收集器多線程相關(guān)的synchronized、volatile、ThreadLocal等。這些知識點幾乎每一場客戶端筆試都會出現(xiàn)屬于“送分題”和“送命題”之間的模糊地帶——真正理解了是送分半懂不懂就是送命。還有一個小眾但值得關(guān)注的知識點反射和注解??陀^題里可能會問你“反射機制的性能問題”“注解的保留策略有哪些”這其實是在考察你對框架底層原理的了解程度。現(xiàn)在的Android開發(fā)大量依賴注解和反射框架比如ButterKnife、EventBus筆試?yán)锍霈F(xiàn)相關(guān)題目并不意外。3. 編程題實戰(zhàn)解析手寫代碼的思路與細(xì)節(jié)3.1 字符串去重與排序一道典型的“基本功”題編程題中出現(xiàn)過一道這樣的題目給定一個字符串去除其中重復(fù)的字符并按照字符ASCII碼升序排序輸出處理后的字符串。這道題LeetCode上有很多變體核心考察點在于你能否用合理的數(shù)據(jù)結(jié)構(gòu)在O(n)時間內(nèi)完成去重再以較小的空間開銷完成排序。思路并不復(fù)雜用一個長度為256的布爾數(shù)組記錄字符是否出現(xiàn)過第一遍遍歷標(biāo)記由于ASCII碼本身有序第二次遍歷時按數(shù)組順序輸出即可。這里有個容易出錯的地方如果你只用一個HashSet去重后再轉(zhuǎn)換成數(shù)組排序整體復(fù)雜度會變成O(n log n)在大數(shù)據(jù)量下可能超時而用布爾數(shù)組的方式可以把排序步驟也變成O(1)的常數(shù)時間。代碼可以這樣寫public String removeDuplicateAndSort(String s) { if (s null || s.length() 0) { return ; } boolean[] seen new boolean[256]; for (int i 0; i s.length(); i) { seen[s.charAt(i)] true; } StringBuilder sb new StringBuilder(); for (int i 0; i 256; i) { if (seen[i]) { sb.append((char) i); } } return sb.toString(); }這道題想清楚了其實不難但我在筆試現(xiàn)場發(fā)現(xiàn)不少人在“排序”這一步繞了遠(yuǎn)路還有人忘了處理空字符串和null輸入。面試官看的不只是你能不能解出來還看你有沒有防御式編程的意識。寫完代碼之后多問自己一句如果輸入是空串怎么辦如果字符包含中文怎么辦如果字符串特別長怎么辦這些問題想清楚代碼質(zhì)量會明顯上一個臺階。3.2 鏈表反轉(zhuǎn)高頻中的高頻鏈表反轉(zhuǎn)是客戶端筆試中出現(xiàn)頻率極高的題目沒有之一。點我達的筆試題里同樣出現(xiàn)了。題目本身很經(jīng)典給定一個單鏈表的頭節(jié)點將鏈表反轉(zhuǎn)返回新鏈表的頭節(jié)點。解題思路有三種迭代法、遞歸法、頭插法。迭代法最直觀用一個prev指針記錄前驅(qū)節(jié)點一個curr指針遍歷當(dāng)前節(jié)點每次迭代時先保存下一個節(jié)點再把當(dāng)前節(jié)點的next指向前驅(qū)節(jié)點。代碼大概長這樣public ListNode reverseList(ListNode head) { ListNode prev null; ListNode curr head; while (curr ! null) { ListNode nextTemp curr.next; curr.next prev; prev curr; curr nextTemp; } return prev; }這道題真正坑人的地方不在基本反轉(zhuǎn)而在進階變體反轉(zhuǎn)鏈表的第m到第n個節(jié)點。點我達的筆試編程題里有一道就是這種變體需要先找到第m-1個節(jié)點然后反轉(zhuǎn)中間的n-m1個節(jié)點最后把三段鏈表拼接起來。這里非常考驗?zāi)銓χ羔槻僮鞯氖炀毝壬圆涣羯窬蜁谄唇禹樞蛏铣鲥e。我的建議是做鏈表相關(guān)題目時一定要在紙上畫圖把指針的指向變化一步一步畫出來不要直接在腦子里做指針操作。3.3 場景模擬題訂單列表分頁加載出了數(shù)據(jù)結(jié)構(gòu)題編程題的第二道往往是一道業(yè)務(wù)場景模擬題。這類題目不會直接告訴你“要用動態(tài)規(guī)劃”或者“要用貪心算法”而是給你一個真實業(yè)務(wù)場景讓你自己提煉問題、設(shè)計方案。我當(dāng)時遇到的一道題大致是這樣有一個訂單列表接口服務(wù)端支持分頁返回數(shù)據(jù)每頁最多返回20條客戶端需要實現(xiàn)一個加載函數(shù)。給定一個訂單ID數(shù)組代表當(dāng)前已有的訂單再給定一個整數(shù)n代表需要加載的條數(shù)要求返回需要請求的頁碼列表頁碼從1開始。如果加載過程中遇到已存在的訂單需要跳過繼續(xù)加載直到湊夠n條為止。這道題本質(zhì)上是考察分頁邏輯的邊界處理和對“已有數(shù)據(jù)”的理解。解決思路的關(guān)鍵點在于當(dāng)某一頁的20條訂單全部已存在時不能只跳過這一頁就結(jié)束要繼續(xù)請求下一頁直到湊滿n條新訂單。這里非常容易出錯很多人會忽略“整頁都重復(fù)”的情況導(dǎo)致返回結(jié)果不足n條。我給的建議是場景模擬題一般沒有唯一答案但你一定要在代碼里體現(xiàn)出對邊界條件的周全考慮。寫完代碼后主動用幾個測試用例驗證一下n為0時、已有訂單數(shù)為0時、某一頁全部重復(fù)時、最后一頁不足20條時。把這些情況都想到了代碼才算是合格的。4. 客觀題高頻易錯點與排查技巧這些坑你必須提前踩過4.1 易混淆知識點對照表備考客觀題時最讓人頭疼的就是那些“看起來差不多實際上差很多”的知識點。我整理了幾個高頻易錯點的對照表非常適合在考前快速過一遍易混淆點正確理解常見錯誤HashMap vs HashtableHashMap允許null鍵和null值線程不安全Hashtable不允許null線程安全但性能差以為HashMap線程安全TCP vs UDPTCP面向連接、可靠、有序UDP無連接、不可靠、高效認(rèn)為UDP比TCP更穩(wěn)定Activity的onStart和onResumeonStart表示頁面可見但不可交互onResume表示可交互將兩者混為一談進程 vs 線程進程是資源分配的基本單位線程是CPU調(diào)度的基本單位互換兩者的定義static方法能否被重寫static方法可以被隱藏但不能被重寫認(rèn)為static方法可以正常重寫String的equals和比較引用地址equals比較內(nèi)容String重寫過用比較字符串內(nèi)容數(shù)組和鏈表的區(qū)別數(shù)組隨機訪問快、插入刪除慢鏈表反之忽略數(shù)組擴容的開銷這類題目沒有太多捷徑只能靠反復(fù)記憶和刷題鞏固。但有一點值得注意不要只看答案要理解每個選項“為什么對”和“為什么錯”。因為多選題經(jīng)常把幾個容易混淆的知識點放在一起你只有真正理解它們的區(qū)別才能在多個選項中做出準(zhǔn)確判斷。4.2 多選題的答題策略多選題是校招筆試?yán)锸Х肿顕?yán)重的題型很多同學(xué)不是不會而是不敢選。我的經(jīng)驗是多選題的計分規(guī)則一般是多選、少選、錯選都不得分所以如果你對某個選項只有五六成的把握建議不選。雖然這樣拿不到滿分但至少有機會拿到部分分?jǐn)?shù)——有些筆試的計分規(guī)則是按照正確選項數(shù)量給部分分的少選比錯選強。另外多選題的選項設(shè)計往往有一個規(guī)律四個選項中至少有一個是“明顯正確”的至少有一個是“明顯錯誤”的剩下的兩個屬于“邊緣選項”。先把明顯正確和明顯錯誤的選項標(biāo)記出來對邊緣選項做分析和判斷而不是憑感覺選。這個方法聽起來沒什么技術(shù)含量但在高壓的筆試環(huán)境下非常實用能有效降低失誤率。4.3 編程題提交前的自查清單編程題寫完之后千萬不要急著提交。我在實際筆試中總結(jié)了一個自查清單每次提交前都強制自己過一遍第一檢查輸入的邊界情況空數(shù)組、空字符串、null、長度為1的數(shù)組、最大值和最小值。第二檢查主要變量在循環(huán)中的更新邏輯避免出現(xiàn)死循環(huán)或數(shù)組越界。第三檢查時間復(fù)雜度和空間復(fù)雜度是否滿足題目約束如果數(shù)據(jù)量是10^5級別O(n^2)的算法大概率會超時。第四檢查是否有輸出格式要求有些題目要求輸出順序、換行、大小寫等細(xì)節(jié)。第五如果時間允許在本地或腦海中選擇一個能覆蓋邊界條件的測試用例手動運行一遍代碼邏輯。這個流程看起來會多花幾分鐘但對正確率的提升非常明顯。校招筆試的編程題往往不是一道題定勝負(fù)而是幾道題的綜合得分決定你是否進入下一輪。確保已提交的題目穩(wěn)定得分比冒險沖擊難題更重要。5. 時間分配與答題順序決定最終成績的關(guān)鍵細(xì)節(jié)5.1 分階段的答題時間規(guī)劃120分鐘的筆試時間說長不長說短不短。如果在前面的客觀題上耗時太久后面編程題就只能草草收場如果飛速掠過客觀題又容易在一些基礎(chǔ)概念題上白白丟分。我自己的時間分配方案是前60分鐘做完全部客觀題和簡答題留下60分鐘給編程題。如果客觀題做得順利還能把節(jié)省下來的時間勻給編程題做更充分的測試。具體到每道題的時間控制單選題平均每題不超過1.5分鐘多選題每題不超過2.5分鐘簡答題每題不超過10分鐘。如果在某道題上超過這個時間還沒有明確思路立即標(biāo)記并跳到下一題。筆試系統(tǒng)一般支持題號跳轉(zhuǎn)回頭再看完全來得及。很多同學(xué)在時間壓力下容易陷入“不甘心跳過”的心理狀態(tài)但這在筆試?yán)锸谴蠹伞R坏纼煞值倪x擇題花十分鐘死磕就算做對了從收益上看也是虧的。5.2 簡答題的答題結(jié)構(gòu)與表達技巧簡答題是容易被忽視的失分點。這類題目往往考察你對某個機制或方案的理解深度比如“請說明Android中Handler機制的工作原理”“如何優(yōu)化App的啟動速度”。很多同學(xué)的答案是“想到哪寫到哪”缺乏結(jié)構(gòu)導(dǎo)致閱卷人難以快速抓到你的核心觀點。我在分享一個比較實用的答題框架先給出核心結(jié)論再展開分點解釋最后補充一個實際案例或踩坑經(jīng)驗。比如回答“如何優(yōu)化App啟動速度”可以先說“啟動優(yōu)化主要從三個方面入手減少主線程任務(wù)、延遲初始化非必要組件、優(yōu)化布局加載”然后分別展開解釋具體手段最后結(jié)合自己項目中遇到的問題舉一個實例。這樣的回答結(jié)構(gòu)清晰信息密度高閱卷人一眼就能看出你有實際項目經(jīng)驗而不是在背面經(jīng)。簡答題寫得有層次感實際是一種成本極低的加分方式。它不需要你掌握額外的知識只需要你把已經(jīng)會的知識點組織得更清晰。5.3 編程題的取舍原則編程題通常有兩道分值相同。遇到兩道題難度不均的情況時我的建議是先做自己更有把握的那一道把確定性分?jǐn)?shù)先拿到手。不要在偏難的那道題上花掉全部時間最后兩道題都沒做完。這個取舍原則在筆試界有一個很形象的類比這就像搞開發(fā)時做技術(shù)選型穩(wěn)定可用的方案優(yōu)先級永遠(yuǎn)高于花哨但不成熟的方案。校招筆試不是競賽它的目的是篩選出基礎(chǔ)扎實、代碼能力合格的人而不是尋找能在45分鐘內(nèi)做出算法難題的天才。把自己會的題目做對、做完整、做得干凈已經(jīng)能超過大部分候選人了。6. 筆試后的復(fù)盤與下一步準(zhǔn)備6.1 筆試后的復(fù)盤方法筆試結(jié)束并不代表整個流程結(jié)束。無論結(jié)果如何認(rèn)真復(fù)盤這場筆試都是提高自己競爭力的關(guān)鍵一步。復(fù)盤不是“對一下答案看看自己得了多少分”而是要追溯每道錯題背后的知識盲區(qū)。我在每一次筆試后都會做一件事把客觀題中所有拿不準(zhǔn)的選項全部整理到錯題本里無論這道題最終是否答對。因為“拿不準(zhǔn)但蒙對了”和“做錯了”本質(zhì)上沒有區(qū)別都說明對應(yīng)的知識點沒有徹底掌握。對編程題復(fù)盤時要把自己的解法改寫一遍并嘗試用更優(yōu)的思路重新實現(xiàn)。比如一道用雙循環(huán)暴力解決的題復(fù)盤時能否用HashMap優(yōu)化到O(n)一道用遞歸解決的題復(fù)盤時能否用迭代實現(xiàn)來規(guī)避棧溢出的風(fēng)險這種“一題多解”的復(fù)盤方式對算法能力的提升效果立竿見影。我認(rèn)識的一個朋友就是靠三輪筆試復(fù)盤把算法題的解題速度提升了將近一倍。6.2 為后續(xù)面試做知識儲備筆試只是校招的第一關(guān)通過筆試后還有面試環(huán)節(jié)。在準(zhǔn)備面試時筆試中出現(xiàn)過的知識點往往具有很強的參考價值——因為面試官很可能會就這些知識點繼續(xù)追問。比如筆試考了Handler機制面試時就可能讓你手寫一個簡化版的Handler筆試考了自定義View的測量和繪制流程面試時就可能讓你現(xiàn)場講一下View的繪制流程在緩存優(yōu)化時怎么把控甚至給出一段代碼讓你分析性能問題。所以筆試復(fù)盤整理的錯題本和知識清單要一直保留到整個校招季結(jié)束隨時補充新的內(nèi)容。我個人的習(xí)慣是把面試中被追問到的知識點加入同一份清單標(biāo)注“筆試已考”“面試已問”和“掌握程度”三個字段形成自己的知識圖譜。這樣復(fù)習(xí)起來非常有針對性不會漫無目的。6.3 保持心態(tài)與節(jié)奏最后想聊聊心態(tài)。校招筆試和面試密集安排的那段時間幾乎每個人都會經(jīng)歷被拒、拿到面試機會、等待結(jié)果這種情緒上的起伏。有一些筆試你感覺自己發(fā)揮得不錯結(jié)果卻沒有進下一輪有一些筆試你覺得考砸了反而意外通過了。這是非常正常的現(xiàn)象因為公司在篩選候選人時會參考多項指標(biāo)筆試成績只是其中之一。我的經(jīng)驗是不要試圖從單場筆試的結(jié)果中過度解讀自己。把每一場筆試當(dāng)作一次模擬練習(xí)考完之后客觀記錄自己的表現(xiàn)找到薄弱環(huán)節(jié)然后投入到下一階段的準(zhǔn)備中去。計算機基礎(chǔ)這門課沒有捷徑但也沒有天花板——你把一個知識點弄懂之后它就會一直長在你身上。保持節(jié)奏穩(wěn)步推進最后一定能拿到心儀的offer。