Embedded & IoT Interview Core Topics: High-Frequency Questions & Answer Frameworks for 6 Key Modules

Embedded & IoT Interview Core Topics: High-Frequency Questions & Answer Frameworks for 6 Key Modules

Embedded and IoT development interviews differ fundamentally from application-layer interviews—interviewers focus more on your depth of hardware understanding and low-level debugging capability than framework proficiency. This article systematically covers 6 core modules in embedded/IoT interviews, each with high-frequency topics and answer frameworks to help you prepare efficiently.

1. C Language & Memory Management

C is the foundation of embedded development, and memory management is the first priority interviewers assess.

High-Frequency Topics

• Pointers & arrays: Pointer arithmetic, array decay, function pointers, multi-level pointers. The most common question: "What's the difference between pointers and arrays?"
• Memory layout: Stack, heap, global/static region, constant region distribution and characteristics. You should be able to draw a typical memory layout diagram
• Memory leaks & buffer overflows: Common leak scenarios, detection tools (Valgrind, AddressSanitizer), prevention strategies
• The volatile keyword: Three major use cases (hardware registers, ISR variables, multi-threaded shared variables)

Answer Framework

The "Three-Layer Progression Method" for C memory management questions: 1) Concept definition (what it is) → 2) Application scenarios (where it's used) → 3) Underlying principles (why it matters). For example, answering volatile: "Volatile tells the compiler that a variable may be modified by external factors, requiring every access to read from memory rather than optimizing to a register. Typical scenarios: hardware register mapping, ISR flag variables, and multi-threaded shared variables. The underlying reason is that compiler optimization may cache variable values, leading to stale data reads."

2. RTOS Real-Time Operating Systems

RTOS is the core differentiator in embedded interviews—mastering RTOS means upgrading from "writing bare-metal code" to "doing system design".

High-Frequency Topics

• Task scheduling: Priority preemption, round-robin, scheduling algorithm comparison. Differences between FreeRTOS and Zephyr scheduling
• Synchronization & communication: Semaphores (binary/counting), mutexes (priority inheritance), message queues, event flag groups
• Deadlock & priority inversion: Four necessary conditions for deadlock, classic priority inversion case (Mars Pathfinder), priority inheritance protocol
• Memory management: Static vs. dynamic allocation, memory pools, fragmentation handling

Answer Framework

The "Scenario-Driven Method" for RTOS questions: 1) Describe the problem scenario → 2) Analyze root cause → 3) Provide RTOS mechanism solution → 4) Note caveats. For example: "When multiple tasks access shared resources, if a high-priority task waits for a low-priority task to release a mutex, and the low-priority task is preempted by a mid-priority task, priority inversion occurs. The solution is using a mutex with priority inheritance: when the low-priority task holds the mutex, its priority is temporarily elevated to match the waiting task. Note that priority inheritance only resolves inversion, not deadlock."

3. Hardware Interfaces & Driver Development

Embedded engineers must understand hardware interfaces—driver development capability distinguishes "users" from "experts".

High-Frequency Topics

• GPIO: Input/output configuration, pull-up/pull-down, interrupt mode, debounce handling
• I2C/SPI/UART: Timing diagrams, speeds, master/slave modes, typical application scenario comparison
• ADC/DAC: Sampling rate, resolution, DMA transfer, calibration methods
• Interrupt management: Interrupt priorities, nested interrupts, interrupt latency, top-half/bottom-half mechanism

Answer Framework

The "Comparative Analysis Method" for hardware interface questions: 1) Protocol characteristics → 2) Applicable scenarios → 3) Selection criteria in real projects. For example: "I2C is a two-wire protocol supporting multiple slave devices with speeds up to 3.4Mbps; SPI is a four-wire, full-duplex protocol reaching tens of Mbps. In Amazon's IoT projects, sensor data collection uses I2C (many devices, low speed requirements), while Flash storage uses SPI (high-speed transfer needed). Selection criteria: device count, speed requirements, and pin resources."

4. Communication Protocols

In IoT interviews, communication protocols are a mandatory module—interviewers expect complete protocol stack knowledge from physical to application layer.

High-Frequency Topics

• Short-range protocols: BLE, Zigbee, Wi-Fi, Thread characteristics and applicable scenarios
• Long-range protocols: LoRa, NB-IoT, LTE-M comparison across power consumption, coverage, and data rate
• Application-layer protocols: MQTT, CoAP, HTTP selection for IoT scenarios
• Protocol stack design: OSI seven-layer model trimming practices in embedded systems

Answer Framework

The "Four-Dimension Evaluation Method" for communication protocol questions: 1) Power consumption → 2) Coverage range → 3) Data rate → 4) Cost. For example: "NB-IoT suits smart metering—ultra-low power (10-year battery life), wide coverage (strong penetration), low data rate (sufficient for reporting), and module cost under $5. By comparison, LoRa suits industrial scenarios with self-deployed networks but requires gateway infrastructure. In Samsung's smart home solutions, BLE connects phones directly to devices, while Zigbee handles device-to-device mesh networking."

5. Low-Power Design

Low power is the core competitive advantage of embedded/IoT products—interviewers use low-power design questions to assess your systems engineering thinking.

High-Frequency Topics

• Sleep modes: Sleep/Stop/Standby power consumption differences and wake-up time trade-offs
• DVFS (Dynamic Voltage and Frequency Scaling): Adjusting MCU frequency and voltage based on workload
• Peripheral management: On-demand peripheral switching, DMA replacing CPU polling, GPIO state optimization
• Power measurement: Current profile analysis, power budget tables, battery life estimation

Answer Framework

The "Layered Optimization Method" for low-power questions: 1) Hardware selection layer (low-power MCU/sensors) → 2) System architecture layer (task scheduling and sleep strategies) → 3) Software algorithm layer (reducing active time, batch transfers) → 4) Verification & measurement layer (current profiling, actual power testing). For example: "In Tesla's vehicle telematics project, we used an STM32L4 low-power MCU with 0.4μA Standby mode current. The key design: adjusting sensor sampling intervals from 1 second to 5 seconds reduced power consumption by 60%."

6. IoT Architecture

IoT architecture tests your end-to-end system design capability, from device to cloud platform.

High-Frequency Topics

• Device-Edge-Cloud architecture: Responsibility division across device layer, edge gateway layer, and cloud platform layer
• OTA updates: Firmware packaging, differential updates, rollback mechanisms, secure signature verification
• Device management: Device registration, identity authentication, remote configuration, log collection
• Data pipeline: Time-series databases, stream processing, rule engines

Answer Framework

The "Three-Layer Design Method" for IoT architecture questions: 1) Device layer (sensing & actuation) → 2) Connectivity layer (protocols & security) → 3) Platform layer (storage & analytics). For example: "In Microsoft's Azure IoT smart agriculture project, the device layer uses STM32+LoRa for soil data collection, the connectivity layer routes through LoRaWAN gateways to Azure IoT Hub, and the platform layer uses time-series databases and triggers irrigation rules. Security: TLS 1.3 with mutual certificate authentication, OTA updates with RSA signature verification and differential updates with automatic rollback on failure."

7. Embedded vs Application-Layer Interview Differences

Core differences between embedded and application-layer interviews:

• Assessment focus: Embedded emphasizes low-level principles and hardware understanding; application-layer emphasizes architecture design and business logic
• Programming languages: Embedded primarily uses C, occasionally C++/Rust; application-layer uses Java/Python/Go
• Debugging methods: Embedded uses oscilloscopes, logic analyzers, JTAG debuggers; application-layer uses IDE breakpoint debugging
• System constraints: Embedded focuses on memory, power, and real-time performance; application-layer focuses on concurrency, scalability, and availability

At NVIDIA and Intel embedded role interviews, interviewers probe deeply into register-level details, while application-layer interviews focus more on system design questions.

8. How to Showcase Hardware Debugging Experience

Hardware debugging experience is a bonus in embedded interviews—how you present it determines the impact:

• Use the STAR method: Situation (what hardware issue) → Task (what needed solving) → Action (what tools and methods used) → Result (quantified improvement)
• Show your toolchain: Mention specific oscilloscope models, logic analyzers, and JTAG debuggers to demonstrate professionalism
• Problem localization process: Emphasize troubleshooting methodology over jumping to answers. For example: "First ruled out software, then checked hardware signals, finally traced to PCB trace interference"

At Samsung's embedded interview, a candidate described using a logic analyzer to capture SPI timing and discovering a slave device response timeout. The interviewer commented: "This is an engineer with real combat experience."

Embedded and IoT interviews require systematic knowledge preparation and practical experience presentation. While preparing for technical interviews, don't forget to use a resume builder to create a professional resume that highlights your project experience and technical depth—giving interviewers a clear picture of your capabilities before you even meet.

FAQ

Q1: What development board projects should I prepare for embedded interviews?

Three types of projects are recommended: 1) RTOS multi-task project (demonstrating understanding of task scheduling and synchronization)—implement multi-sensor data collection and display using FreeRTOS; 2) Communication protocol project (demonstrating protocol stack capability)—implement end-to-end BLE or LoRa data transmission; 3) Low-power project (demonstrating system optimization thinking)—design a battery-powered sensor node, measuring and optimizing actual power consumption. Quality over quantity—each project should allow you to discuss technical details and design trade-offs in depth.

Q2: What if I don't have RTOS experience?

If you lack RTOS project experience, at minimum master FreeRTOS core concepts: task creation and scheduling, semaphores and mutexes, message queues. Spend 1-2 weeks building a multi-task project with STM32+FreeRTOS (e.g., sensor collection + LCD display + UART communication), and you'll be able to confidently answer RTOS-related questions. The key isn't which MCU you used, but your depth of understanding of RTOS mechanisms.

Q3: Do embedded interviews ask algorithm questions?

Yes, but with different emphasis. Embedded algorithm questions focus more on practical constraints of time and space complexity rather than optimal solutions. Common topics: linked list operations (memory pool management), bit manipulation (register operations), circular buffers (data stream processing), state machine design (protocol parsing). At Oracle's embedded interviews, algorithm questions typically combine with real scenarios, like "Design a circular buffer for UART data reception."

Q4: How should I answer "What's the hardest technical problem you've encountered?"

Use the "Problem-Investigation-Solution-Reflection" four-step method: 1) Problem description: Specific symptoms and impact (e.g., "Product randomly reboots in low-temperature environments"); 2) Investigation process: Systematic elimination (rule out software first → check hardware signals → trace root cause); 3) Solution: Specific measures and verification methods; 4) Lessons learned: What you learned and how to prevent recurrence. Avoid giving only results without process—interviewers want to see your engineering thinking.

Q5: Do I need to know Linux for embedded development?

It depends on your direction. Bare-metal/RTOS development doesn't require deep Linux knowledge, but you should be comfortable with Linux development environments (cross-compilation, Makefiles, Git). Embedded Linux development requires deep mastery: kernel configuration and compilation, device driver models, device trees, and file systems. At IBM and Intel embedded Linux role interviews, kernel and driver knowledge is mandatory. Decide your investment depth based on your target positions.