前兩天整理移動硬盤翻到了當年參加小鵬汽車2019春招車聯網軟件工程師筆試時留下的復盤文檔。那會兒正值春招補錄崗位掛靠在互聯網中心名字叫“車聯網軟件工程師”但看了筆試內容就會發現它既沒有去考CAN總線解析也沒有考高精地圖和SLAM更多還是集中在軟件工程師的基本盤上。今天把這份筆試題的考察邏輯重新捋一遍也是給正在準備車企軟件崗面試的朋友一個參考車聯網方向筆試題并不是什么“玄學”所有題目都指向同一個問題——你能不能在一個資源不算寬裕的車載環境里寫出穩定、可維護、能上線的軟件。這份筆試如果落在今天來看題型其實不算特別新穎C/C、數據結構、操作系統、網絡協議、算法編程一圈下來看起來和互聯網后端校招差別不大。但仔細做進去會發現它選的知識點非?？酥破蚯度胧綀鼍昂屯ㄐ艌鼍暗慕徊娴貛?。這也提醒我們準備車聯網軟件工程師不只是刷LeetCode還要把Linux、網絡協議、系統資源這些“傳統地盤”撿起來。文章后面我會按當年筆試涉及的知識塊逐一展開也會把我重做了一遍后想明白的細節寫出來。1. 互聯網中心招的“車聯網軟件工程師”和嵌入式開發有什么不同1.1 同一個“車聯網”標簽不同崗位的權重差別很大很多人在投“車聯網軟件工程師”時會下意識把它等同于嵌入式軟件開發。實際上車企的軟件崗位分得很細車聯網方向也存在明顯的業務邊界。以當年小鵬汽車互聯網中心掛出的崗位來說它要解決的更多是“車端如何和云端互通”“用戶如何通過手機與車輛交互”“車輛運行數據如何穩定上報”這些問題。換句話說這個崗位處在傳統汽車電子和移動互聯網的交叉點上。這種定位直接影響了筆試選題。純嵌入式崗位大概率會考寄存器配置、中斷處理、I2C/SPI時序甚至讓你分析某塊SoC的啟動流程而互聯網中心的車聯網軟件工程師崗位更關心你能不能寫對網絡通信模塊、能不能處理并發上報、能不能在Linux環境下定位一個崩潰問題。所以筆試里出現大量C/C和Linux基礎但很少出現芯片級驅動題目也就不奇怪了。1.2 從崗位能力畫像反推筆試的底層邏輯如果仔細拆解崗位要承擔的工作會得到下面這張能力畫像能力維度為什么要考在筆試里的對應題型C/C語言車機端應用、T-Box通信模塊大量使用C/C指針、內存、類相關選擇題和改錯題數據結構與算法軟件工程的基本功決定代碼質量鏈表、二叉樹、棧隊列的手寫與復雜度分析操作系統車機系統需要應對多任務調度、資源緊張進程線程、死鎖、信號量、內存管理計算機網絡車聯網的本質是車與云端、手機之間的通信TCP/UDP、HTTP、MQTT概念題Linux操作車機系統普遍基于Linux/Android常用命令、簡單腳本編寫這個畫像并不要求每一塊都達到專家水平但要求每一塊都不能有明顯短板。筆試的篩選邏輯也很有意思它不通過偏題怪題來制造門檻而是通過“基礎題密度”來淘汰訓練不足的人。很多人覺得車聯網工程師崗位很酷考前拼命去補自動駕駛、激光雷達、高精地圖結果一上筆試發現連struct內存對齊都能做錯這就很可惜。1.3 “互聯網中心”這五個字透露出的關鍵信號崗位名稱里帶“互聯網中心”意味著這個團隊的工作模式更接近互聯網團隊有較快的迭代節奏講究代碼評審和工程質量也會關注數據上報、服務端接口、App聯動這類偏上層的事情。筆試里出現“車輛狀態上報”“遠程控制指令怎么設計”這類題目其實就是在考察你有沒有互聯網軟件的思維習慣。我當時還注意到一個細節題目里對內存和性能的關注明顯比純互聯網后端崗位要高。原因是車機的硬件資源遠不如服務器那么充裕一行不規范的字符串處理代碼就可能在某個低配車機上引發卡頓甚至崩潰。所以筆試考內存對齊、考動態內存管理不是故意刁難而是這個崗位每天都會遇到這些事。2. 從崗位描述反推筆試范圍基礎能力與車聯網場景的權重2.1 崗位描述里那些關鍵字的優先級當年招聘信息里的關鍵字我現在還記得大概車聯網、軟件工程師、嵌入式、Linux、通信。把這些詞展開就是筆試考察范圍。校招筆試不會考你上一份實習做了什么它更傾向考察“你這個人有沒有獨立成長的基礎”。所以從崗位描述能直接推出好幾個可能考到的模塊如果寫了Linux大概率會考常用命令、進程概念、文件系統如果寫了通信大概率會考TCP/IP協議棧運氣好會碰到MQTT這類物聯網協議如果寫了嵌入式C語言的優先級會直接拉到最高指針、內存、結構體這些跑不掉如果寫了軟件工程師數據結構與算法基本是必考題。注意這里的權重分配基礎能力是主體車聯網場景是包裝。就像互聯網后端筆試會把題目包裝成“訂單系統”一樣車聯網筆試也喜歡把題目包裝成“車輛狀態上報”“遠程升級任務”。你看穿這點之后復習就不會跑偏。2.2 必考、?？?、加分考點的優先級表結合當年實際筆試的體感如果把考點排個優先級大概是這樣的優先級考點常見出題方式必考C語言基礎、指針、內存選擇題、代碼找錯必考數據結構鏈表、棧、隊列、樹手寫代碼或復雜度分析必考操作系統進程線程、同步、死鎖概念選擇題、問答?？糒inux命令、shell腳本命令填空、場景腳本?？季W絡協議TCP/UDP、HTTP問答、流程描述常考算法題字符串、數組、簡單動態規劃在線編程題加分MQTT、JSON/Protobuf、OTA流程場景問答你可以發現車聯網特有的知識點通常不會單獨出一道大題而是作為背景嵌入到網絡或操作系統題目里。例如“車輛在弱網環境下上報位置應該選TCP還是UDP”表面考網絡實際考的是你對可靠性和實時性的權衡。這種題目如果只背概念而不理解場景很容易答偏。2.3 為什么2019年春招的筆試會更偏重基礎那一年春招的節奏比秋招快留給筆試的時間窗口短面試官也需要通過一場筆試快速篩選出值得進入后續流程的人。所以筆試題目不會出得太難更不會為了一個冷門知識點讓大多數人交白卷。它的目的是把“基礎扎實、具備計算機系統觀”的人挑出來而不是找“百科全書式”的人。這也意味著備考重點應放在高頻考點上。如果你花大量時間去背車聯網行業分析、研究每一個OEM的遠程升級方案反而可能錯過最核心的得分點。把基礎題練到肌肉記憶再去拓展車聯網場景題才是穩妥的路。3. 基本盤拆解C/C、數據結構、操作系統在筆試中的考法3.1 C/C的送分題與爭奪題C/C是當年筆試里分量最重的一塊。它考察的難點不在語法本身而在你是否真正理解內存布局和對象生命周期。隨便舉幾個高頻點指針和引用的區別、const在C和C中的不同含義、static變量和全局變量的區別、結構體內存對齊、虛函數底層實現。這些知識點非?；A但能全答對的人并沒有想象中那么多。以結構體內存對齊為例題目往往問一個結構體占多少字節struct Node { char a; int b; char c; };如果在32位系統上默認4字節對齊答案是12字節而不是6字節。很多人只算字段寬度忘了對齊填充。這個考點幾乎年年出現因為它在嵌入式通信中非常關鍵結構體經常用來解析CAN報文或者網絡幀如果對齊規則不清楚很容易踩到協議解析的坑。另一個值得寫的是淺拷貝和深拷貝。車聯網代碼里經常會出現車輛信息結構體的賦值如果只做淺拷貝動態分配的字符串就會被兩個對象同時持有析構時就會double free。筆試里可能不會讓你寫完整代碼但會給出一個類讓你指出拷貝構造和賦值運算符有什么問題。這類題邏輯不復雜前提是你平時真寫過、真崩過。C里還有個容易考的細節為什么構造函數不能是虛函數而析構函數推薦寫成虛函數。在車輛通信模塊中上層往往定義抽象接口下層有多種協議實現比如4G、Wi-Fi、藍牙。如果基類析構函數不是虛函數delete基類指針時子類資源就無法釋放。這個點既考語言機制也考工程意識答到“資源釋放”層面通常就能拿高分。3.2 數據結構題不只考手寫代碼數據結構的選擇題通常是送分題比如棧和隊列的異同、哈希沖突的幾種解決方式、二叉搜索樹的查找復雜度、快排最壞時間復雜度。這部分只要刷過一遍基礎題基本不會丟分。容易拉開差距的還是手寫代碼題。鏈表反轉出鏡率很高。它看起來簡單但要在五分鐘內寫對手不能生。參考答案思路如下struct ListNode* reverseList(struct ListNode* head) { struct ListNode *prev NULL, *curr head; while (curr) { struct ListNode *next curr-next; curr-next prev; prev curr; curr next; } return prev; }除了鏈表二叉樹層序遍歷、用兩個棧實現隊列也稱得上高頻。這些題不考技巧純粹考你平時有沒有動手寫過。如果沒有在筆試現場邊想邊寫非常容易卡殼。另一個值得注意的考點是復雜度分析。有些題目不要求你寫完整代碼但會問你“將哈希表改為紅黑樹后查找復雜度從O(1)變成多少”這需要你對數據結構的底層實現有基本感知。3.3 操作系統與Linux嵌入式環境下的實操感操作系統題很少考特別抽象的理論更多是問進程和線程的區別、死鎖的四個必要條件、信號量和互斥鎖的使用場景。如果你有過多線程編程經驗答起來會輕松很多。車機場景里多個應用要同時訪問定位模塊、網絡模塊這里就是典型的同步與資源管理問題。當年的題目里我最深的一道是“多個線程同時往一個日志緩沖區寫數據如何保證不互相覆蓋”。這個問題表面考線程安全實際考你對鎖的理解。正確的回答是先想到互斥鎖或自旋鎖然后再補充一句“鎖的粒度盡量小避免日志寫入過程中長時間持有鎖導致其他線程卡頓”。如果還能想到用無鎖環形緩沖區那就是加分中的加分了。Linux方面命令題是性價比最高的部分。下面這幾條建議你考前閉眼都能寫出來用top或free查看系統負載和內存占用用ps -ef | grep 進程名查找進程PID用netstat -tunlp查看端口和網絡連接用find /var/log -name *.log | xargs grep xxx在日志目錄里查關鍵詞用tail -f實時跟蹤日志用kill -9 PID強制結束進程。筆試里可能會讓你寫一個簡單腳本比如“刪除一周前的日志文件”。很簡單#!/bin/bash find /var/log/vehicle -name *.log -mtime 7 -exec rm -f {} \;這其實也考察了find條件的組合能力。如果你只會ls和cd到這就露餡了。Linux不是一天練成的但常用命令突擊一兩天就能覆蓋大部分考點投入產出比很高。另一個常見問法是“如何查看某個進程的CPU和內存占用”很多人會答ps但top -p PID才是更有針對性的答案面試官會更認可這種精確操作。4. 提分項拆解網絡通信與算法編程題怎么準備4.1 TCP/UDP和車聯網場景的結合網絡題是車聯網軟件工程師筆試里最具崗位特色的部分因為它能真正區分“背過八股文”和“理解場景”。基礎題大家都準備過三次握手為什么不是兩次、四次揮手為什么需要TIME_WAIT、UDP和TCP各自適合什么場景。但真正有區分度的是把它放到車聯網語境里問。舉個例子題目可能會說車輛在行駛過程中需要每10秒上報一次GPS位置請問選用TCP、UDP還是MQTT更合適很多人一看到“上報”就寫UDP理由是實時性好。但如果你了解實際工程會發現位置上報也需要考慮數據完整性因為服務器端要用這些位置繪制軌跡、分析駕駛行為。完全丟包會導致軌跡斷裂。所以工程上常用MQTT QoS1既保證至少一次到達又比裸TCP連接重建的開銷小。再比如遠程控車指令這種操作要求可靠性和安全性。車門解鎖指令一旦丟失用戶可能被鎖在車外。所以它必須走加密的可靠通道HTTP/HTTPS或MQTT QoS2都可行。筆試答題時如果能寫出“可靠指令用TCP/HTTPS高頻低價值數據用UDP或MQTT QoS0”這種層次感閱卷人一眼就能看出你不只是背了協議區別。還包括HTTP和HTTPS的區別這個常規考點在車聯網里也有延伸車機請求云端接口證書校驗失敗應該怎么辦如果直接忽略證書繼續請求就可能被中間人攻擊。好的回答應該是“先判斷失敗原因再決定是否走安全策略涉及車輛控制類接口必須嚴格校驗”。這種安全意識在車聯網崗位里非?？粗?。4.2 算法題的難度和取舍算法編程題通常是整個筆試里最耗時間的。當年的題目難度基本在LeetCode中等偏下不太會出現競賽題。常見方向包括字符串處理、數組操作、鏈表、二分查找、簡單動態規劃。例如“合并兩個有序鏈表”“最長無重復子串”“兩數之和”這類。寫題時有個很重要的取舍拿到題目先不要急著寫代碼先跟出題人給的例子過一遍流程確認輸入范圍和邊界。比如合并兩個有序鏈表它考察的不只是邏輯還包括“有沒有處理空鏈表”“有沒有理清dummy節點”這些小節。代碼可以寫得樸素但一定要完整struct ListNode* mergeTwoLists(struct ListNode* l1, struct ListNode* l2) { struct ListNode dummy; struct ListNode* tail dummy; dummy.next NULL; while (l1 l2) { if (l1-val l2-val) { tail-next l1; l1 l1-next; } else { tail-next l2; l2 l2-next; } tail tail-next; } tail-next l1 ? l1 : l2; return dummy.next; }如果運氣好碰到“最長無重復子串”可以用滑動窗口解決。關鍵是想清楚窗口什么時候收縮什么時候更新答案。這類題只要保持刷題手感臨時上手不會太難。還有一個方向也值得留意排序類題目。比如給一組車輛狀態記錄按時間戳排序你會優先寫快速排序還是直接調用系統庫工程上當然是調用系統庫更穩妥但筆試里如果明確要求“手寫排序”就必須能在紙上寫對partition過程。4.3 答題規范與調試技巧在線筆試平臺通常沒有代碼提示也不提供完整編譯調試環境。很多人寫完代碼后沒有測試用例的意識丟分常常不是思路不對而是“沒考慮到空輸入”。我的建議是寫完之后至少在腦子里跑三組用例——正常輸入、空輸入、單元素輸入。如果平臺支持本地編譯就先把代碼在本地跑一遍再貼上去穩得多。另外注意輸入輸出的格式。?？秃唾惔a這類平臺經常要求你處理多行輸入如果scanf或cin用錯代碼邏輯再正確也可能超時或者讀不到數據。這些都是細節但細節決定筆試能不能進面。還有一個很實用的習慣在代碼開頭寫清楚思路注釋哪怕只有兩三行。如果線上判題沒給滿分后續人工復核時看到你在注釋里寫了“用快慢指針找中點再用歸并排序”也能給出印象分。5. 90分鐘作答的節奏控制與真實踩坑復盤5.1 我當年的時間分配方案當年筆試時長是90分鐘題目類型包括選擇題、填空題、簡答題、編程題。很多人到最后沒有做完不是題目量太大而是沒有控制節奏。我自己的時間分配習慣是這樣的先快速瀏覽整張試卷判斷題量比例接著用10到15分鐘解決所有選擇題和填空題給編程題留出40分鐘再用剩余20分鐘處理簡答題和檢查。選擇題和填空題是最容易拿分但最容易被拖時間的部分。有些C語言題很刁鉆比如“有符號和無符號比較”“整型提升”如果你不確定不要戀戰先做一個標記回頭再來看。編程題必須留足時間因為一旦寫不完幾乎拿不到分數。簡答題不要寫太長按照“定義、原因、場景、做法”四段式組織每條控制在三四行既清楚又不浪費時間。5.2 那些看著會做卻丟分的瞬間復盤當時答題卡我發現最可惜的丟分點不是不會做而是“會做但沒寫全”。比如某道簡答題問“為什么車機遠程升級要設計多個版本回退機制”我光寫了OTA升級失敗會導致設備變磚但沒有展開說明版本校驗、A/B分區、升級包簽名這些工程細節。閱卷人想看的不是一句口號而是你真的了解一個軟件系統在真實設備上會遇到的邊界情況。編程題也踩過類似坑。我記得有一道題要求“輸出合并后的鏈表節點值”我寫完合并邏輯后忘記逐節點輸出直接輸出了頭節點指針平臺判題必然報錯。這種錯誤不是能力問題而是考場狀態下習慣性忽視“輸出格式”這四個字。還有一次是寫代碼之前沒初始化指針本地編譯器開啟了嚴格警告所以能發現但線上平臺可能直接編譯失敗。5.3 重新復盤后的心得整理完這份復盤我最大的感受是車聯網軟件工程師筆試的核心不是“卷難度”而是“考穩定”。它希望篩出來的是能在有限時間內把基礎題做對、把關鍵場景想清楚、把代碼寫得不出邊界問題的人。如果讓我重新準備一次我會把復習順序調整為先快速刷一遍C語言和數據結構基礎題確保不犯低級錯誤再花兩三天把Linux命令和shell腳本練熟接著把TCP/UDP、MQTT、HTTP這些協議在車聯網場景里的應用想透最后才是刷算法題。這個順序不是按分數占比排的而是按“投入產出比”排的——基礎題和命令題背了就有分算法題則依賴長期積累沖刺階段性價比相對低。我還想特別提一點面試官很看重“排查問題”的思維方式。筆試里如果出現“車輛偶發不上報數據如何排查”這樣的場景題不要一上來就寫“我是后端工程師不擅長”。把鏈路拆成車端采集、網絡傳輸、云端接收三段每段列出可能的故障點和排查命令比如車端看進程是否存活、網絡層看TCP連接狀態、云端看日志和數據庫寫入。這種結構化表達即使不是標準答案也能展現出你的系統思維。最后再分享一個簡單但有用的技巧筆試前把常見的結構體對齊、三次握手、進程切換、鏈表反轉、滑動窗口這五類題各默寫一遍。字不用多關鍵是手要熟。很多時候你感覺自己“會”但真正動筆才發現缺了一個dummy節點。這份2019春招的筆試題已經過去好幾年了但這類崗位要的東西其實一直沒變基礎扎實、懂場景、能落地。如果你正在準備類似的車聯網軟件工程師崗位不妨把這份復盤當作一份最小檢查清單逐項確認一下自己是否真的準備好了。