1. 那場持續(xù)四小時的技術拉鋸戰(zhàn)到底在考什么涂鴉智能的面試在圈子里一直有點名氣尤其是嵌入式加AIoT方向的崗位流程長、輪次密、技術面覆蓋廣很多人戲稱是“車輪戰(zhàn)”。我前后經(jīng)歷過兩次類似節(jié)奏的技術面也跟不少去面過的朋友復盤過發(fā)現(xiàn)一個很明顯的規(guī)律面試官真正在意的不是你背了多少八股文而是你能不能把嵌入式底層和物聯(lián)網(wǎng)通信這兩條線串起來講清楚。這個崗位的日常工作是圍繞智能模組、網(wǎng)關設備、傳感器節(jié)點展開的涉及從驅動層到應用層再到云端對接的完整鏈路所以面試的考察維度天然就比純嵌入式崗位要寬。這篇文章適合幾類人看正在準備涂鴉智能或類似AIoT公司面試的嵌入式工程師、想從傳統(tǒng)嵌入式轉向物聯(lián)網(wǎng)方向的開發(fā)者、以及剛入行不久想搞清楚NB-IoT和通信協(xié)議到底怎么落地的新人。我會把四小時車輪戰(zhàn)里高頻出現(xiàn)的考點拆開講重點放在嵌入式Linux開發(fā)環(huán)境、通信協(xié)議棧、NB-IoT數(shù)據(jù)傳輸實戰(zhàn)、以及面試中那些容易踩的坑上。不是簡單的面經(jīng)羅列而是把每個問題背后的技術邏輯和實際工作中的對應場景講透讓你在面試時能答出“做過”的感覺而不是“背過”的痕跡。先說一下整體節(jié)奏。涂鴉的技術面通常分三到四輪每輪四十分鐘到一個小時中間可能穿插筆試或在線編程。第一輪偏基礎C語言、數(shù)據(jù)結構、操作系統(tǒng)概念第二輪偏嵌入式Linux和驅動第三輪偏通信協(xié)議和物聯(lián)網(wǎng)架構第四輪可能是項目深挖或系統(tǒng)設計。四小時連軸轉下來體力和心態(tài)都是考驗。我見過技術不錯但第三輪開始明顯疲憊、回答質量斷崖式下滑的候選人所以提前做模擬連續(xù)面試是很有必要的。注意車輪戰(zhàn)的核心不是某一輪答得多驚艷而是四輪下來沒有明顯短板。任何一輪出現(xiàn)“完全不會”的領域基本就涼了。2. 嵌入式Linux這條線從VSCode環(huán)境到內核源碼的考察邏輯2.1 為什么面試官總愛問你的開發(fā)環(huán)境很多人覺得開發(fā)環(huán)境這種問題很水不就是用個編輯器嗎但在涂鴉這類公司的面試里開發(fā)環(huán)境的選擇和配置能力其實反映了你的工程化程度。我第一輪就被問到“你平時用什么開發(fā)嵌入式Linux”我說VSCode配合Remote-SSH插件連到Ubuntu編譯機面試官接著追問了三個問題怎么管理交叉編譯工具鏈怎么在VSCode里配置調試怎么處理頭文件路徑跳轉這三個問題直接把“會用編輯器”和“會搭建工程環(huán)境”區(qū)分開了。用VSCode做嵌入式Linux開發(fā)現(xiàn)在是很主流的方案核心配置其實就幾塊。首先是c_cpp_properties.json里的includePath要把交叉編譯工具鏈的頭文件路徑、內核頭文件路徑、項目自身的include路徑都加進去否則代碼里全是紅色波浪線跳轉也跳不過去。其次是tasks.json里配置編譯任務把make命令和交叉編譯器的環(huán)境變量寫進去。最后是launch.json配合gdbserver做遠程調試這個在調試驅動的時候特別有用。{ configurations: [ { name: Linux, includePath: [ ${workspaceFolder}/**, /opt/toolchain/arm-linux-gnueabihf/include/**, /home/user/kernel/include/** ], defines: [], compilerPath: /opt/toolchain/bin/arm-linux-gnueabihf-gcc, cStandard: c11, cppStandard: c17, intelliSenseMode: linux-gcc-arm } ], version: 4 }上面這段配置看起來簡單但實際踩坑的地方很多。比如內核頭文件路徑不能直接指向/usr/include那是宿主機的必須指向你實際編譯內核時用的源碼樹里的include目錄否則結構體定義對不上跳轉過去全是錯的。還有compilerPath一定要指向交叉編譯器而不是宿主機的gcc不然IntelliSense推導出來的類型寬度可能不對比如long在32位ARM和64位x86上寬度不同會導致一些隱蔽的誤判。2.2 內核源碼和驅動基礎問到什么深度才算過關涂鴉的嵌入式崗位對內核的考察不會像芯片原廠那么深但基本的驅動模型、設備樹、字符設備框架是必須掌握的。我被問到過“字符設備和塊設備的區(qū)別”“platform驅動模型的匹配機制”“設備樹里compatible屬性怎么用”這類問題。這些在嵌入式八股文里都有標準答案但面試官更想聽的是你有沒有實際改過驅動、調過設備樹。舉個例子面試官問我“I2C設備在設備樹里怎么描述”我不僅說了compatible、reg這些基本屬性還補充了實際調試中遇到的坑有些I2C從設備需要配置clock-frequency默認100kHz在某些傳感器上會導致讀取超時改成400kHz就好了還有pinctrl的配置順序會影響引腳復用如果先初始化I2C控制器再配置引腳可能會概率性失敗。這些細節(jié)一說出來面試官就知道你是真調過硬件的。關于RK3566這類AIoT常用主控設備樹的結構要熟悉。RK3566的DTS文件里I2C、SPI、UART這些外設節(jié)點都是現(xiàn)成的你只需要在對應的節(jié)點下添加子節(jié)點描述你的外設。比如掛一個NB-IoT模組到UART上就要在uart3節(jié)點下加配置設置status okay然后配置波特率、流控等參數(shù)。面試中如果被問到“你怎么把一個新的傳感器接到板子上”完整的回答應該包括確認硬件接口類型、查原理圖確定引腳、修改設備樹、編寫或適配驅動、在應用層通過sysfs或字符設備接口讀取數(shù)據(jù)。這個鏈路能講清楚基本就穩(wěn)了。2.3 嵌入式Linux應用開發(fā)的進階路徑從菜鳥到能獨立做項目嵌入式Linux應用開發(fā)有幾個關鍵臺階。第一個臺階是能交叉編譯一個Hello World并在板子上跑起來這個階段主要是熟悉工具鏈和部署流程。第二個臺階是能寫多線程程序會用pthread、mutex、condition variable理解線程同步和競態(tài)條件。第三個臺階是能寫網(wǎng)絡程序會用socket、select/poll/epoll理解TCP和UDP的區(qū)別以及各自適用的場景。第四個臺階是能設計一個完整的應用架構包括進程間通信、配置文件管理、日志系統(tǒng)、守護進程化。涂鴉的面試里第二輪就問到過“你的程序怎么在板子上開機自啟動”我說用systemd寫service文件面試官追問“如果程序崩潰了怎么自動重啟”這就涉及到service文件里的Restartalways和RestartSec配置。還有“怎么保證程序只運行一個實例”可以用pid文件加文件鎖的方式。這些問題看起來是運維層面的但實際上反映了你對嵌入式系統(tǒng)整體運行機制的理解。3. 通信協(xié)議棧從I2C到MQTT的完整鏈路怎么講3.1 板內通信協(xié)議I2C、SPI、UART的選型邏輯嵌入式面試里通信協(xié)議是必考項但很多人只會背“I2C是兩線、SPI是四線、UART是異步”這種表面區(qū)別。面試官真正想聽的是你在什么場景下選什么協(xié)議為什么這么選。我在第三輪被問到“如果要接一個溫濕度傳感器、一個顯示屏、一個NB-IoT模組分別用什么接口”這就是典型的選型題。溫濕度傳感器比如SHT30數(shù)據(jù)量小、速率要求低、引腳緊張用I2C最合適兩根線可以掛多個設備。顯示屏如果是SPI接口的TFT因為要傳圖像數(shù)據(jù)速率要求高SPI的全雙工高速特性更合適。NB-IoT模組通常走UART因為模組廠商提供的AT指令集就是基于串口的配置簡單、兼容性好。這個回答的邏輯是先看數(shù)據(jù)量和速率要求再看引腳資源和設備數(shù)量最后看軟件棧的成熟度。I2C的實際調試中有幾個高頻坑。一是上拉電阻I2C的SDA和SCL必須接上拉電阻典型值4.7kΩ如果板子上沒有或者阻值不對波形上升沿會很緩導致通信失敗。二是地址沖突同一個I2C總線上掛兩個地址相同的設備就會出問題有些傳感器可以通過ADDR引腳改變地址硬件設計時就要注意。三是時鐘拉伸某些從設備處理慢的時候會拉低SCL如果主控不支持時鐘拉伸就會丟數(shù)據(jù)。SPI的坑主要在模式配置上。CPOL和CPHA的組合有四種模式主從設備必須一致否則采樣時刻對不上讀出來全是0xFF或0x00。我調試SPI屏幕的時候就遇到過手冊上寫的是Mode 0但實際模組需要Mode 3試了好幾次才確認。還有片選信號的管理如果多個SPI設備共享總線片選必須嚴格互斥軟件上要做好保護。3.2 工業(yè)與車載通信協(xié)議CAN、Modbus、EtherCAT的適用邊界涂鴉的AIoT業(yè)務雖然以消費級為主但面試中也會問到工業(yè)協(xié)議因為很多網(wǎng)關設備需要對接工業(yè)場景。CAN總線在車載和工業(yè)控制里很常見它的特點是多主架構、差分信號、抗干擾強。面試中被問到“CAN和UART的區(qū)別”不能只說速率要講清楚CAN有仲裁機制、有錯誤幀、有優(yōu)先級適合多節(jié)點實時控制場景。Modbus協(xié)議在工業(yè)設備里幾乎是標配分RTU和TCP兩種。RTU走串口TCP走以太網(wǎng)。Modbus的報文結構很簡單從站地址加功能碼加寄存器地址加數(shù)據(jù)加CRC校驗。實際調試中經(jīng)常遇到的問題是字節(jié)序和寄存器映射不同廠商的寄存器地址定義不一樣有的從0開始有的從1開始有的數(shù)據(jù)是高字節(jié)在前有的低字節(jié)在前必須對著手冊一個一個對。EtherCAT是實時以太網(wǎng)協(xié)議在運動控制領域用得很多。它的特點是主站發(fā)送一幀數(shù)據(jù)所有從站依次讀取和寫入數(shù)據(jù)在從站間“飛速穿過”延遲極低。面試中如果被問到EtherCAT至少要能說出它的拓撲結構線型、環(huán)型、星型、分布式時鐘機制、以及和普通以太網(wǎng)的區(qū)別。不過涂鴉的崗位對EtherCAT的考察不深了解基本概念就夠了。3.3 應用層協(xié)議MQTT、CoAP、HTTP在AIoT中的分工到了應用層AIoT設備最常用的就是MQTT。涂鴉的云平臺對接基本都走MQTT所以面試中一定會問。MQTT的核心概念包括Broker、Topic、QoS、Keep Alive、遺囑消息。QoS 0是最多一次QoS 1是至少一次QoS 2是恰好一次。實際項目中QoS 1用得最多因為QoS 2的握手開銷太大在低功耗場景下不劃算。MQTT的Topic設計也有講究。涂鴉的設備Topic通常是/device/{deviceId}/command和/device/{deviceId}/status這種結構設備訂閱command主題接收指令發(fā)布到status主題上報狀態(tài)。面試中如果被問到“設備離線了怎么辦”要提到遺囑消息Last Will and Testament設備連接時設置遺囑Topic和消息內容Broker檢測到設備異常斷開后會自動發(fā)布遺囑消息云端就能感知到設備離線。CoAP是另一種輕量級協(xié)議基于UDP適合極低功耗的場景。NB-IoT設備有時候會用CoAP而不是MQTT因為UDP不需要維持長連接省電。HTTP在AIoT里主要用于設備固件升級、配置下發(fā)這類非實時場景因為它的開銷大、不適合頻繁通信。4. NB-IoT實戰(zhàn)從模組選型到數(shù)據(jù)上云的完整流程4.1 NB-IoT到底解決了什么問題NB-IoT是蜂窩物聯(lián)網(wǎng)技術專門為低功耗、廣覆蓋、大連接場景設計。和傳統(tǒng)的2G/4G模組比NB-IoT的功耗低得多一節(jié)電池可以用幾年覆蓋能力強在地下室、管道井里也能有信號連接密度高一個基站可以支持幾萬個設備。這些特性決定了它適合智能表計、環(huán)境監(jiān)測、資產追蹤這類場景。面試中被問到“NB-IoT和LoRa的區(qū)別”要能說出NB-IoT走運營商網(wǎng)絡需要SIM卡覆蓋廣但依賴基站LoRa是自建網(wǎng)絡不需要SIM卡成本低但覆蓋范圍有限適合園區(qū)級應用。涂鴉的設備既有NB-IoT方案也有LoRa方案選型取決于客戶的具體場景。NB-IoT的通信模型和傳統(tǒng)蜂窩模組類似也是通過AT指令控制。模組上電后先注冊網(wǎng)絡然后激活PDN連接獲取IP地址之后就可以用UDP或CoAP發(fā)送數(shù)據(jù)了。和4G模組不同的是NB-IoT支持PSMPower Saving Mode和eDRXExtended Discontinuous Reception這兩個機制是省電的關鍵。PSM讓設備在空閑時進入深度睡眠eDRX讓設備延長尋呼周期兩者配合可以把功耗降到微安級別。4.2 模組選型和硬件設計要點NB-IoT模組的選型主要看幾個維度支持的頻段、封裝形式、AT指令集的兼容性、以及是否支持CoAP/UDP/TCP協(xié)議棧。常見的模組有移遠的BC35-G、BC26中移的M5311廣和通的N700等。涂鴉的方案里用的比較多的是支持OpenCPU的模組也就是模組本身可以跑用戶代碼不需要外掛MCU這樣可以進一步降低成本和功耗。硬件設計上NB-IoT模組的電源設計很關鍵。NB-IoT發(fā)射時的瞬時電流可以到200mA以上如果電源的瞬態(tài)響應不好會導致模組復位或掉網(wǎng)。所以電源電路要加足夠大的電容通常建議在模組電源引腳附近放一個100uF以上的鉭電容或電解電容再配合0.1uF的陶瓷電容濾高頻。天線設計也很重要NB-IoT的頻段在800MHz到900MHz左右天線的尺寸和匹配網(wǎng)絡要針對這個頻段優(yōu)化否則信號強度不夠注冊網(wǎng)絡都困難。SIM卡接口要注意的是NB-IoT模組通常支持eSIM或貼片SIM卡如果用的是插拔式SIM卡座要加ESD保護器件因為用戶插拔時容易引入靜電。還有SIM卡的時鐘頻率NB-IoT模組一般用3.25MHz和傳統(tǒng)手機的5MHz不同硬件設計時要確認模組的要求。4.3 數(shù)據(jù)從傳感器到云端的完整鏈路一個典型的NB-IoT數(shù)據(jù)采集系統(tǒng)包括傳感器、MCU可選、NB-IoT模組、SIM卡、天線、云平臺。數(shù)據(jù)流向是傳感器通過I2C或SPI把數(shù)據(jù)給MCUMCU通過UART用AT指令把數(shù)據(jù)發(fā)給模組模組通過NB-IoT網(wǎng)絡把數(shù)據(jù)傳到運營商基站基站再路由到云平臺。實際開發(fā)中AT指令的交互是最容易出問題的環(huán)節(jié)。比如發(fā)送ATCGATT?查詢網(wǎng)絡附著狀態(tài)返回CGATT:1表示已附著但有時候模組返回CGATT:0這時候不能急著發(fā)數(shù)據(jù)要等幾秒鐘再查。還有ATNSOCR創(chuàng)建Socket參數(shù)包括協(xié)議類型UDP/TCP、本地端口、接收模式等參數(shù)寫錯了會返回ERROR但錯誤碼不具體得對著手冊排查。// 典型的NB-IoT數(shù)據(jù)發(fā)送流程偽代碼 void nbiot_send_data(uint8_t *data, uint16_t len) { // 1. 檢查網(wǎng)絡附著 while (!check_network_attached()) { delay_ms(1000); } // 2. 創(chuàng)建UDP Socket int sock create_socket(UDP, 0, 0); if (sock 0) { log_error(socket create failed); return; } // 3. 發(fā)送數(shù)據(jù)到云平臺 int ret send_to(sock, CLOUD_IP, CLOUD_PORT, data, len); if (ret 0) { log_error(send failed, retry...); // 重試邏輯 } // 4. 關閉Socket如果是UDP也可以不關復用 close_socket(sock); }上面這段偽代碼看起來簡單但實際實現(xiàn)的時候要考慮很多邊界情況。比如網(wǎng)絡附著失敗要重試幾次重試間隔多久Socket創(chuàng)建失敗是資源不夠還是參數(shù)錯誤發(fā)送失敗是網(wǎng)絡問題還是云平臺問題這些都需要在代碼里做好錯誤處理和日志記錄否則現(xiàn)場調試的時候兩眼一抹黑。4.4 低功耗優(yōu)化和現(xiàn)場調試經(jīng)驗NB-IoT設備的低功耗優(yōu)化是個系統(tǒng)工程。硬件上要選低功耗的傳感器和MCU軟件上要合理使用PSM和eDRX。PSM模式下設備在空閑后進入深度睡眠只有RTC還在跑功耗可以降到5uA以下。但PSM的缺點是設備在睡眠期間不可達云端下發(fā)的指令要等設備醒來才能收到。所以PSM的激活時間Active Timer和周期更新定時器TAU要根據(jù)業(yè)務需求權衡。實際調試中我遇到過模組頻繁掉網(wǎng)的問題。排查下來發(fā)現(xiàn)是PSM配置和基站參數(shù)不匹配模組請求的TAU太長基站不支持導致周期性掉網(wǎng)。解決辦法是把TAU改短一點或者聯(lián)系運營商確認基站的PSM參數(shù)。還有一次是設備在弱信號下反復重連功耗飆升后來加了信號質量判斷只有在RSRP大于某個閾值時才發(fā)送數(shù)據(jù)否則緩存起來等信號好了再發(fā)?，F(xiàn)場調試NB-IoT設備必備的工具包括串口調試助手看AT指令交互、網(wǎng)絡抓包工具看空口信令、以及運營商的物聯(lián)網(wǎng)管理平臺看設備在線狀態(tài)和流量使用情況。我習慣在代碼里加一個調試模式可以通過串口輸出詳細的日志包括每次AT指令的發(fā)送和接收、網(wǎng)絡狀態(tài)變化、數(shù)據(jù)發(fā)送結果等。這些日志在排查問題時非常有用。5. 面試中那些沒人明說但會悄悄扣分的細節(jié)5.1 八股文要背但別只會背嵌入式八股文包括C語言陷阱題、操作系統(tǒng)概念、數(shù)據(jù)結構算法等。C語言?？嫉氖侵羔?、內存對齊、位操作、volatile、const、static這些關鍵字。比如“volatile的作用是什么”標準答案是“告訴編譯器不要優(yōu)化每次從內存讀取”但面試官更想聽的是“在哪些場景下必須用volatile”比如硬件寄存器訪問、中斷服務程序里修改的全局變量、多線程共享變量。能舉出具體場景說明你是真理解而不是死記硬背。操作系統(tǒng)方面進程和線程的區(qū)別、進程間通信方式、死鎖的四個條件、內存管理機制這些都是高頻考點。但涂鴉的面試官喜歡結合實際場景問比如“你的程序里用了哪些IPC方式為什么選這個”。我回答的是共享內存加信號量因為數(shù)據(jù)量大、實時性要求高共享內存零拷貝效率最高信號量做同步。如果數(shù)據(jù)量小、頻率低用消息隊列更簡單。數(shù)據(jù)結構算法在嵌入式面試里不會考太難但基本的鏈表、隊列、棧、二叉樹要會。手寫一個單鏈表的反轉、判斷鏈表是否有環(huán)、實現(xiàn)一個循環(huán)隊列這些是常見的手寫題。我的建議是提前在白紙上練幾遍確保沒有語法錯誤邊界條件處理正確。5.2 項目經(jīng)歷怎么講才能讓面試官眼前一亮項目經(jīng)歷是面試的重頭戲但很多人講得太平淡面試官聽完沒什么印象。講項目的核心是突出你解決了什么難題、做了什么取舍、取得了什么可量化的結果。比如“我負責了一個NB-IoT環(huán)境監(jiān)測節(jié)點的開發(fā)”這是流水賬。改成“我負責的NB-IoT環(huán)境監(jiān)測節(jié)點在初期測試中功耗超標待機電流達到200uA遠超預期的50uA。我通過排查發(fā)現(xiàn)是模組的PSM模式?jīng)]有正確激活修改AT指令配置并優(yōu)化了傳感器的采樣周期后待機電流降到了35uA電池壽命從3個月延長到了2年”這就是有血有肉的項目經(jīng)歷。面試官可能會追問技術細節(jié)比如“你怎么確認PSM模式激活了”“采樣周期怎么優(yōu)化的”“電池壽命怎么估算的”。這些都要提前準備好。電池壽命的估算公式是電池容量除以平均電流。平均電流等于工作電流乘以工作時間占比加上待機電流乘以待機時間占比。這個計算過程能講清楚面試官會覺得你是有工程思維的。5.3 反問環(huán)節(jié)問什么顯得你懂行面試最后的反問環(huán)節(jié)很多人問“公司福利怎么樣”“加班多不多”這些問題不是不能問但會浪費一個展示自己的機會。更好的問法是圍繞技術和業(yè)務比如“貴司的AIoT設備主要走哪些通信協(xié)議”“NB-IoT和Cat.1在你們的方案里怎么選型”“嵌入式團隊和云端團隊的協(xié)作模式是怎樣的”。這些問題表明你對崗位的實際工作內容感興趣而且有一定的技術視野。我一般會問“這個崗位目前面臨的最大技術挑戰(zhàn)是什么”面試官的回答往往能透露很多信息比如團隊正在攻克低功耗難題、或者正在做多協(xié)議網(wǎng)關的兼容性適配。根據(jù)回答你可以進一步追問展示你的思考。反問環(huán)節(jié)不是走過場而是雙向選擇的過程你也在評估這個崗位是否適合自己。6. 從面試反饋反推學習路線6.1 如果基礎薄弱該從哪里補起如果面試反饋是“基礎不夠扎實”那大概率是C語言和操作系統(tǒng)的問題。補基礎的建議是C語言把《C和指針》和《C專家編程》過一遍重點理解指針、內存模型、編譯鏈接過程。操作系統(tǒng)把《現(xiàn)代操作系統(tǒng)》或《操作系統(tǒng)導論》的前幾章看完理解進程、線程、內存管理、文件系統(tǒng)的基本概念。然后找一些開源的嵌入式項目讀代碼比如RT-Thread、FreeRTOS的源碼看別人怎么組織代碼、怎么處理并發(fā)。嵌入式Linux方向的話必讀的是《嵌入式Linux應用開發(fā)完全手冊》和《Linux設備驅動開發(fā)詳解》。前者偏應用后者偏驅動。讀的時候要配合實際板子操作光看書不動手面試的時候還是講不出細節(jié)。6.2 如果項目經(jīng)驗不足怎么彌補項目經(jīng)驗不足是很多候選人的硬傷。彌補的方式有兩種一是自己做一個完整的項目從硬件選型到軟件開發(fā)到云端對接全走一遍。比如用ESP32加傳感器做一個環(huán)境監(jiān)測節(jié)點通過MQTT把數(shù)據(jù)傳到云平臺再用手機App查看。這個項目雖然簡單但涵蓋了嵌入式開發(fā)的完整鏈路面試的時候可以講很多細節(jié)。二是參與開源項目在GitHub上找一些活躍的嵌入式項目從修bug開始逐步深入。開源項目的代碼質量和協(xié)作流程都是很好的學習素材。涂鴉的面試官對項目經(jīng)驗的考察比較務實不要求你做過多么高大上的東西但要求你能把做過的項目講清楚、講深入。哪怕是一個簡單的溫濕度采集項目只要你能說清楚硬件設計、軟件架構、通信協(xié)議、低功耗優(yōu)化、調試過程就能拿到不錯的評價。6.3 面試前一周的沖刺策略面試前一周建議按這個節(jié)奏準備第一天到第二天把C語言和操作系統(tǒng)的八股文過一遍重點看高頻考點。第三天到第四天把簡歷上的項目重新梳理每個項目準備三個技術難點和解決方案。第五天針對目標公司的業(yè)務方向做功課比如涂鴉的AIoT平臺、支持的通信協(xié)議、典型的應用場景。第六天做一次模擬面試找朋友或同事扮演面試官連續(xù)問兩個小時適應車輪戰(zhàn)的節(jié)奏。第七天休息調整心態(tài)把之前整理的重點再過一遍。模擬面試非常重要。我見過很多候選人單個問題答得不錯但連續(xù)被問兩小時后注意力下降簡單的問題也答錯。模擬面試能幫你發(fā)現(xiàn)自己的體力極限和注意力波動規(guī)律提前做好應對。7. 一些零散但實用的經(jīng)驗碎片關于VSCode開發(fā)嵌入式再補充一個技巧用Remote - Containers插件把開發(fā)環(huán)境容器化。這樣你的編譯工具鏈、依賴庫、配置文件都在容器里換電腦或者重裝系統(tǒng)后拉取容器鏡像就能恢復開發(fā)環(huán)境非常省事。容器里可以預裝交叉編譯器、cmake、python腳本等團隊協(xié)作的時候也能保證環(huán)境一致。關于通信協(xié)議調試邏輯分析儀是必備工具。I2C、SPI、UART的波形都能抓配合協(xié)議解碼功能能快速定位是硬件問題還是軟件問題。我用的比較多的是Saleae的邏輯分析儀軟件體驗好協(xié)議解碼準。預算有限的話國產的Kingst邏輯分析儀也能用性價比高。關于NB-IoT的AT指令調試建議把常用指令做成腳本一鍵執(zhí)行。比如初始化流程AT測試模組是否響應ATCGMR查版本ATCGSN查IMEIATCSQ查信號質量ATCGATT?查網(wǎng)絡附著ATNSOCR創(chuàng)建Socket。把這些指令按順序寫成腳本每次調試的時候跑一遍能快速確認模組狀態(tài)。關于面試心態(tài)車輪戰(zhàn)最怕的是第一輪被問懵了后面心態(tài)崩了。我的經(jīng)驗是遇到不會的問題不要慌可以先說“這個問題我目前沒有直接經(jīng)驗但我的理解是……”然后從你掌握的知識出發(fā)做合理推斷。面試官往往更看重你的思考過程而不是標準答案。如果完全不會坦誠說“這塊我了解不深回去會補上”也比瞎編要好。最后說一個很多人忽略的點面試結束后的復盤。每場面完趁記憶還新鮮把被問到的問題、自己的回答、覺得答得不好的地方記下來。幾場面試下來你就能發(fā)現(xiàn)自己的薄弱環(huán)節(jié)有針對性地補強。我第二次面涂鴉的時候之所以比第一次順利很多就是因為第一次面完后做了詳細復盤把通信協(xié)議和低功耗相關的知識點重新學了一遍。