Intel Embedded Engineer Interview: C Language, RTOS, and Hardware Fundamentals Full Assessment

Background

Let me start with my background. I have a bachelor's degree in Electronic Information Engineering and spent 2 years doing embedded development at a mid-size security company. My main work was firmware development for IPCs (IP Cameras), using HiSilicon's Hi3516 chip. Day-to-day, I wrote C code, debugged drivers, and occasionally did RTOS porting. Honestly, Intel had always been one of my dream companies for embedded work — a global leader in semiconductor technology, and the tech stack was a perfect match for my experience.

I applied during the fall hiring season and got a response from HR within about 3 days to schedule the first round. The entire process consisted of three technical rounds plus an HR round, spanning about two weeks. Let me walk through each round in detail.

Interview Process Review

Round 1: C Language Fundamentals + Memory Management (about 60 minutes)

My first interviewer was a tech lead who looked to be around 30. He started with a brief self-introduction and then dove straight into technical questions. Intel's first round is seriously hardcore — no fluff, all substance.

Pointer-related questions:

The very first question made me a bit nervous — "Explain the difference between pointers and arrays." I handled this one okay, covering memory layout, sizeof differences, and whether they support increment operations. But then the interviewer followed up with: "What about pointer arrays vs. array pointers?" I hesitated for a moment, but thankfully I had reviewed this — I explained that p1 is an array where each element is an int pointer, while p2 is a pointer pointing to an int array. The interviewer nodded.

Next came a memorable question: "Write a macro to calculate the offset of a struct member." This is essentially the implementation of the offsetof macro. I wrote ((size_t)&((type*)0)->member), and the interviewer said that works, then asked why we use address 0. I explained that casting from address 0 avoids creating an actual object and directly computes the offset.

Memory management:

The interviewer then asked: "Explain the underlying implementation of malloc." I covered brk/sbrk system calls, memory pools, and chunk structures. The follow-up was: "How does free know how much memory to release?" I explained that malloc stores a header before the returned pointer recording the allocation size, and free uses this header to determine the size.

There was also a classic question: "What is memory alignment? Why is it necessary?" I covered CPU access efficiency, some platforms not supporting unaligned access, and struct padding.

The volatile keyword:

"What does volatile do? In what scenarios must it be used?" I gave three scenarios: variables modified in ISR, shared variables in multi-threading, and memory-mapped registers. The interviewer followed up: "Can volatile guarantee thread safety?" I clearly stated it cannot — it only prevents compiler optimization and doesn't guarantee atomicity.

Round 2: RTOS + Driver Development (about 75 minutes)

The second-round interviewer was clearly more senior, likely a department tech lead. The depth of this round was noticeably higher.

RTOS-related:

First, they asked which RTOS I had used before. I said FreeRTOS. Then: "Explain FreeRTOS's task scheduling mechanism." I covered priority-based preemptive scheduling, time-slicing for equal-priority tasks, and the data structure of the ready list (linked list array). The follow-up: "What exactly happens during a context switch? What context is saved?" I walked through PendSV interrupt, register stacking, updating task stack pointers, and restoring the new task's context.

There was also a practical question: "What are the inter-task communication methods in FreeRTOS? What scenarios is each suitable for?" I listed queues, semaphores (binary/counting), mutexes (with priority inheritance), event groups, and task notifications, along with their use cases.

Driver development:

The interviewer asked: "What drivers have you developed before?" I mentioned I2C, SPI, and UART. Then they asked me to detail the I2C driver implementation. I covered GPIO-simulated I2C timing, start/stop conditions, ACK/NACK handling, and 7-bit addressing. Follow-up: "What's the difference between I2C and SPI? Pros and cons of each?" I compared them on wire count, speed, multi-slave support, and full-duplex/half-duplex.

There was also an interrupt-related question: "Explain Linux's top-half and bottom-half interrupt mechanism." I covered fast processing in the top half and deferred processing in the bottom half, listing mechanisms like softirq, tasklet, and workqueue.

Round 3: Deep Project Dive + Comprehensive Assessment (about 60 minutes)

The third round was with a director-level interviewer, focusing on deep dives into project experience and assessing systems thinking.

The interviewer asked me to pick my most challenging project and describe it in detail. I chose a low-power IPC project I had worked on, covering requirements analysis, solution selection, problems encountered, and solutions. The interviewer followed up on several points: "How exactly did you implement the low-power mode switching? What was the wake-up latency?" "What was the bitrate control strategy for video encoding?" "If you were to redesign it, how would you optimize?"

There was also an open-ended question: "If a product you're responsible for experiences occasional crashes at a customer site, how would you troubleshoot?" I systematically covered confirming reproduction conditions, log analysis, watchdog configuration, memory leak investigation, and hardware signal capture.

Key Interview Questions

C Language:

1. Difference between pointers and arrays? Pointer arrays vs. array pointers?

2. Write an offsetof macro

3. Underlying implementation of malloc? How does free know the size to release?

4. What is memory alignment? Why is it necessary?

5. Purpose and use cases of the volatile keyword

6. Struct memory layout calculation (given a struct, calculate sizeof)

RTOS:

7. FreeRTOS task scheduling mechanism

8. Context saving and restoration during task switching

9. Inter-task communication methods and their use cases

10. Priority inversion problem and solutions (priority inheritance/ceiling protocol)

Driver Development:

11. I2C driver implementation details

12. Differences between I2C and SPI

13. Linux interrupt top-half/bottom-half mechanism

14. DMA working principles

Comprehensive:

15. Troubleshooting approach for occasional crashes

16. Low-power design approaches

17. Watchdog principles and usage considerations

Lessons and Advice

1. C language fundamentals must be solid. Intel's first round was almost entirely C language, and it's not the kind you can pass by memorizing standard answers. Many questions require genuine understanding of underlying principles. For instance, with the offsetof macro and malloc implementation, rote memorization falls apart the moment the interviewer digs deeper.

2. Understand RTOS principles, not just APIs. Many people only know how to call vTaskCreate and xQueueSend, but interviewers ask about scheduling mechanisms and context switching — the underlying principles. I recommend reading the FreeRTOS source code, especially tasks.c and list.c.

3. Driver development requires hands-on experience. Intel places great emphasis on practical ability. Reading books without writing code won't cut it. I suggest buying a development board and working through from GPIO LED blinking to I2C/SPI drivers to a complete device driver framework.

4. Be able to explain project details clearly. The third round was mainly about discussing projects, and the interviewer will probe from various angles. If you actually built the project, you can answer the details; if it's embellished, you'll easily get caught. Only include things on your resume that you've genuinely done.

5. Systems thinking is crucial. Embedded development isn't just about writing code — you need to consider hardware, power consumption, stability, maintainability, and more. Demonstrating systems thinking during the interview will earn you significant bonus points.

FAQ

Q: Does Intel's embedded interview have high education requirements?

A: Bachelor's degree and above all have a chance. Campus recruiting tends to favor top-tier universities, while experienced hires focus more on project experience. I got my offer based on project experience.

Q: Do I need to prepare Linux kernel knowledge?

A: It depends on the position. For Linux driver roles, kernel knowledge is essential; for RTOS roles, focus on RTOS. But some Linux kernel knowledge is always a plus.

Q: Will there be coding during the interview?

A: Yes. In the first round, I had to hand-write the offsetof macro and a linked list reversal. In the second round, I wrote pseudocode for a producer-consumer model. I recommend practicing embedded-related coding questions beforehand.

Q: What chips does Intel mainly use for embedded development?

A: It varies by team and project. I recommend familiarizing yourself with common embedded processor architectures before the interview.

Q: How is the compensation?

A: With 2 years of experience, the salary is competitive for the industry. Benefits include full social insurance and housing fund contributions, which is quite reasonable.