Какой опыт у вас есть в программировании под микроконтроллеры

Что проверяют

Работали ли вы с железом по-настоящему или только собирали скетчи в Arduino IDE. Интервьюер слушает, называете ли вы конкретные контроллеры, периферию и инструменты отладки. Следом почти всегда просят рассказать про самый трудный баг, который вы ловили на плате.

Как отвечать

Стройте ответ вокруг одного или двух проектов и проходите по слоям:

• платформа: семейство и ядро, например STM32 на Cortex-M4 или ESP32, объём Flash и RAM, в который приходилось укладываться;
• инструменты: arm-none-eabi-gcc, CMake или PlatformIO, STM32CubeMX для генерации инициализации, прошивка и отладка через SWD с ST-Link или J-Link, GDB и OpenOCD;
• уровень доступа к железу: HAL, LL, CMSIS или прямая работа с регистрами, и почему выбрали именно его;
• периферия: таймеры, ADC, DMA, UART, SPI, I2C, CAN, обработчики прерываний;
• многозадачность: суперцикл или RTOS (FreeRTOS, Zephyr), очереди и семафоры между задачами;
• C++ на контроллере: сборка с -fno-exceptions и -fno-rtti, отказ от кучи после старта, constexpr и шаблоны вместо макросов, RAII для захвата периферии.

Цифры берите свои: насколько снизили потребление в режиме сна, сколько килобайт сэкономили, какую задержку реакции на прерывание получили. Если опыт только учебный или хобби, так и скажите, но покажите глубину: какую плату брали, что читали в reference manual, как смотрели сигнал логическим анализатором. Честное «делал дома, вот что понял про DMA» звучит сильнее выдуманного промышленного проекта.

Где спотыкаются

Перечисляют аббревиатуры без контекста: «знаком с SPI и I2C». Сразу следует вопрос, чем они отличаются и что делать, если устройство на шине не отвечает, и ответ рассыпается.

Не могут объяснить volatile и защиту общих данных между прерыванием и основным кодом. Это базовая тема, без неё рассказ про RTOS не убеждает.

Приписывают проекту результат вроде «эффективность выросла на 30%», не зная, как это мерили. Интервьюер уточнит методику, и цифра обернётся против вас.