Дисклеймер: Данный текст — это рефлексия и практический гайд. Лично я выбрал путь ИП и проектной работы (B2B-договоры), но принципы, описанные ниже, универсальны и проверены моими возрастными коллегами, которые продолжают строить карьеру в найме.
Для возрастных кандидатов на рынке IT действительно существует негласная планка. После 45 лет количество откликов и звонков заметно снижается, а ближе к 50 поиск работы рискует превратиться в тяжелый труд, где помогают либо связи, либо уникальная, редкая экспертиза. Это касается не только embedded разработчиков, но и любых IT специалистов.
В идеальном мире после 45 лет не вы должны «бегать по вакансиям», а рынок должен приходить к вам. Если этого не происходит, проблема чаще всего не в вашей квалификации, а в том, как упакован ваш опыт и как вы заходите в процесс найма.
После пересечения этой «волшебной даты» веерная рассылка резюме перестает работать — большинство откликов улетит в корзину на этапе первичного скрининга. Ваша задача — сменить тактику: перестать быть «кандидатом из стопки» и начать предъявлять результаты работы тем, кто реально принимает решения.
Проблема: Вас оценивают как набор тегов
Рынок часто ощущается так, будто вас оценивают не как инженера, а как JSON-объект с набором полей.
Вы выходите на рынок с уверенностью: «Я умею вытаскивать сложные ситуации, закрывал аварии, оптимизировал прошивки, приводил железо в чувство — меня должны оторвать с руками».
Но сталкиваетесь с реальностью: найм работает как конвейер совпадений по ключевым словам. В IT это особенно заметно. Если в вакансии написано: STM32, FreeRTOS, SPI, EMC, а у вас в резюме: «ARM Cortex‑M, RTOS, низкоуровневая периферия», фильтр может решить, что вы «не подходите». Хотя по факту вы за неделю поднимете плату, запустите прошивку, соберете стенд и объясните, почему I2C сбоит из‑за емкости линии.
Важно принять факт: HR не обязан понимать технические нюансы. Рекрутер не знает:
зачем DMA разгружает CPU;
почему проблемы с SPI отличаются от проблем с QSPI;
и почему «просто добавили ретраи» иногда означает «спрятали проблему до следующего релиза».
Задача HR — за полминуты отсеять 95% резюме. Это механика, а не злой умысел. Система «любит» средних и шаблонных. Сильные инженеры часто пролетают именно потому, что их опыт шире, формулировки сложнее, а задачи были нестандартными.
Обижаться на устройство мира — путь к выгоранию. «Взломать» систему — путь к интересным задачам и деньгам. Ниже — гайд для тех, кто реально умеет делать железо и софт, но устал биться о фильтры.
Шаг 1. Резюме как лендинг: продавайте результат, а не процесс
Главная ошибка инженеров — писать резюме как отчет о проделанной работе:
«Разрабатывал прошивки. Писал драйверы. Работал с UART/SPI/I2C. Делал отладку».
Это звучит так, будто вы просто «были рядом». Бизнес и техлид ищут ответы на два вопроса:
Какую проблему вы решали?
Каким был результат (желательно измеримый)?
Рабочая формула: Проблема → Решение → Эффект.
Примеры трансформации (Было / Стало)
Кейс 1. CAN-шина
- Было: «Работал с STM32, FreeRTOS, CAN».
+ Стало: «Стабилизировал обмен по CAN на STM32 + FreeRTOS под жесткие тайминги. Устранил потерю сообщений на пиках нагрузки, сократил задержки в критических секциях с X до Y мс».
Кейс 2. Оптимизация
- Было: «Оптимизировал прошивку».
+ Стало: «Профилировал обработчики прерываний, вынес обмен в DMA и кольцевые буферы. Загрузка CPU снизилась с 70% до 25%, исчезли срывы таймингов, появился запас ресурсов под новые функции без смены МК».
Кейс 3. Драйверы и тесты
- Было: «Писал драйверы датчиков».
+ Стало: «Унифицировал драйверный слой для сенсоров (I2C/SPI), внедрил стенд автопроверок на железе. Ошибки периферии перестали всплывать „в полях“, время регрессионного тестирования сократилось с 3 дней до 4 часов».
Кейс 4. EMC
- Было: «Занимался EMC».
+ Стало: «Локализовал источник помех, скорректировал схемотехнику (фильтрация) и режимы GPIO. Устройство прошло сертификационные тесты по EMC без программных „костылей“».
Лайфхак для прохождения фильтров:
Возьмите вакансию, выделите 5–7 ключевых терминов и вставьте их в резюме дословно (если вы действительно с этим работали). Написано FreeRTOS — пишите FreeRTOS, а не просто RTOS. Написано CMake или J-Link — эти слова должны быть в тексте.
Шаг 2. Скрининг: вы не «кандидат», вы инженер
Классика: рекрутер просит «рассказать о себе», и кандидат уходит в хронологию: «В 2005 году я закончил вуз, в 2008 устроился...».
Заходите через 2–3 коротких, ярких кейса:
«Устройства зависали у заказчика, проблема не воспроизводилась в офисе. Я организовал сбор логов, внедрил расширенный watchdog с сохранением контекста ошибки. Нашли гонку между прерыванием и задачей. За квартал число отказов снизилось в 10 раз. Сейчас ищу команду, где ценят тако�� инженерный подход, а не героизм в стиле „ночью пропатчим и помолимся“».
Это сразу переводит разговор в плоскость пользы.
Шаг 3. Техническое интервью: вопросы важнее синтаксиса
Когда вам дают задачу «спроектируйте устройство/прошивку», сильный инженер (особенно уровня Senior/Lead) не бросается писать код. Он сначала выясняет границы системы:
Энергопотребление: режимы сна, пики тока (батарейка или сеть?).
Условия среды: температура, вибрации, помехи.
Update: обновление «по воздуху» или через программатор? Риски «окирпичивания»?
Производство: нужны ли точки теста, калибровка, прошивка серийников?
Надежность: что считается критическим отказом и как система должна деградировать при сбоях?
Эксперт не обязан помнить наизусть биты во всех регистрах. Он обязан видеть систему целиком и задавать вопросы, которые вытаскивают сложность наружу.
Красный флаг: Если вам запрещают уточнять требования и требуют «писать код на листочке» молча. В Embedded это опасно: можно написать синтаксически верный код, но сделать устройство, которое сгорит или зависнет на морозе.
Если вы чего-то не знаете — не играйте в угадайку. Нормальная позиция: «С этим конкретным стеком плотно не работал, но решал похожую задачу на [X]. Там были такие подводные камни... Я бы начал с такой архитектуры. Давайте обсудим, подходит ли это под ваши ограничения».
Шаг 4. Финал с руководством: язык денег и рисков
Руководству (CTO, Product Owner) важен не красивый код, а:
Скорость вывода продукта (Time-to-Market).
Стабильность в поле (Cost of ownership).
Снижение возвратов и гарантийных случаев.
Предсказуемость сроков.
Говорите на их языке:
«Если мы сейчас разделим слои драйверов и бизнес-логики и сделаем HIL-стенд, мы потратим на 2 недели больше сейчас, но сократим время отладки каждого следующего релиза на 30%. Это снизит риск возврата партии из-за багов в периферии. Техдолг — это кредит: его можно брать, но важно понимать процентную ставку».
Обязательно «собеседуйте» компанию в ответ:
«Как принимаются решения по архитектуре?»
«Расскажите про последний крупный факап: что вы изменили в процессах после него?» (Если ответ — «нашли и наказали виноватого», бегите).
Как обходить фильтры: тактика точечных ударов
Массовая рассылка для эксперта работает плохо. Эффективнее точечные заходы.
1. Прямой контакт
Найдите в LinkedIn или профильных чатах тимлида / ведущего инженера компании. Напишите коротко:
«Привет! Вижу, вы ищете инженера под [Проект]. Я делал похожее на [Железо]. Есть идея, как снизить [Риск/Стоимость]. Можем созвониться на 10 минут?»
2. Нетворк и рекомендации
Знакомый внутри компании — это «черный ход», позволяющий пропустить этап первичного отсева HR-фильтром.
3. Профессиональные сообщества
В профильных чатах и на митапах смотрят на то, как вы мыслите, а не на возраст в паспорте.
Вместо вывода
Ищите не «работу», а место, где вас слышат. Собеседование — это переговоры партнеров, а не экзамен школьника.
Вы приносите: опыт реальных инцидентов, инженерную культуру и умение делать продукт устойчивым.
Они приносят: контекст, ресурсы и команду.
Если вас не слушают на интервью, если говорят «вы не решили задачку на бумаге» — часто это означает «нам нужен дешевый исполнитель, а не инженер». Это не трагедия, просто вам не по пути.
В 45+ лет инженер — это не тот, кто быстрее всех пишет HAL_GPIO_WritePin. Это тот, чьи решения меняют траекторию проекта, экономя бизнесу деньги и нервы.
Статья открыта для обсуждения. Все пройдено на личном опыте и обсуждении с эйчарками.