C++ разработчик в 2026: подготовка к интервью

На интервью проверяют границы обещаний

Сильный ответ по C++ начинается не с названия механизма, а с контракта. Чем владеет объект, как долго живёт ссылка, кто синхронизирует доступ и какое поведение стандарт действительно гарантирует? Фраза «обычно это работает» опасна именно там, где оптимизатор, другой поток или редкий путь исключения меняет наблюдаемую картину. На интервью полезно сначала назвать инвариант, затем показать нарушение и только потом выбрать инструмент.

Разбирая фрагмент кода, отделяйте корректность от производительности. Если два потока одновременно обращаются к обычному int, причём хотя бы один пишет без синхронизации, возникает data race и поведение не определено. Нельзя сначала измерить, «как часто теряется инкремент», а потом решать, нужна ли защита. Сначала устраняют undefined behavior, после чего сравнивают допустимые реализации по цене. То же относится к выходу за границы массива и использованию объекта после окончания времени жизни.

Аргументируйте минимальную гарантию. memory_order_relaxed обеспечивает атомарность и единый порядок модификаций конкретного атомарного объекта, но не публикует связанные обычные данные другому потоку. Для счётчика статистики, который не служит сигналом готовности, этого может быть достаточно. Если читатель по значению флага должен увидеть заполненную структуру, нужен другой протокол синхронизации. Название memory order без описания связи между потоками не является объяснением.

Хороший технический ответ явно называет владельца ресурса, срок жизни, границу синхронизации, допустимое состояние после операции и способ проверить утверждение.

Время жизни видно в сигнатуре не всегда

std::string_view не владеет символами. Возврат view на локальный std::string оставляет ссылку на буфер, уничтоженный при выходе из функции. Короткий тест способен пройти, потому что память ещё не перезаписана, но объект уже dangling. Исправление зависит от нужного контракта: вернуть владеющий std::string, принимать буфер вызывающей стороны или гарантировать более долгую жизнь хранилища. Копирование самого view жизнь данных не продлевает.

Raw pointer тоже не сообщает всё необходимое. По Widget* нельзя понять, передаётся ли владение, разрешён ли nullptr и как долго объект доступен. Для обязательного заимствования часто яснее ссылка, для владения — значение или подходящий smart pointer, для необязательного наблюдения — документированный указатель либо другой тип с явной семантикой. Выбор не сводится к запрету звёздочки; он должен сделать неправильное использование труднее.

После std::move объект остаётся валидным, но его конкретное состояние обычно не задано контрактом типа. Его можно уничтожить, присвоить ему новое значение и вызывать операции, для которых выполнены предусловия. Проверять «обязательно пуст» нельзя, если тип явно этого не обещает. Для стандартных типов действуют их собственные гарантии, поэтому ответ должен ссылаться на контракт конкретной операции, а не на визуальный образ переноса.

Потоки требуют протокола, а не отдельных mutex

RAII связывает ресурс со временем жизни объекта. Локальный std::lock_guard захватывает один mutex при создании и освобождает его в деструкторе как при обычном выходе, так и при раскрутке стека из-за исключения. Ручная пара lock/unlock распадается при раннем return или броске. std::unique_lock нужен, когда требуется отложенный захват, временное освобождение или передача владения блокировкой, но его режимы создают дополнительные состояния, которые нужно обосновать.

Два mutex добавляют проблему порядка. Если один путь берёт A затем B, а другой B затем A, оба потока могут ждать друг друга. Единый глобальный порядок решает задачу, когда его реально соблюдают все места. Если блокировки нужны вместе в одной области, std::scoped_lock применяет алгоритм совместного захвата и освобождает обе через RAII. Простая замена mutex на recursive mutex не исправляет цикл между разными блокировками.

Атомик не превращает составную операцию над несколькими объектами в транзакцию. Два атомарных счётчика могут по отдельности быть корректными и одновременно нарушать общий инвариант, если читатель должен видеть согласованную пару. Тогда нужен протокол: mutex, версия состояния, неизменяемый снимок или другой способ публикации. На интервью важно сказать, что защищается, а не просто перечислить atomic, mutex и memory order.

Производительность начинается с воспроизводимого симптома

Если tail latency выросла вместе с числом мелких allocations, сначала воспроизводят характерную нагрузку и фиксируют исходные p50/p95/p99, пропускную способность, CPU и память. Затем профиль показывает, где происходят выделения, сколько они живут и какие пути попадают в медленный хвост. Только после этого выбирают изменение: reserve, иной layout, arena, pool или сокращение числа объектов. Меняют один существенный фактор и повторяют измерение вместе с проверкой корректности и потребления памяти.

Мгновенная замена глобального allocator способна улучшить один график и скрыть удержание памяти или конкуренцию в другом месте. Пул для объектов с разными сроками жизни может увеличить рабочий набор и задержку очистки. Даже reserve требует разумной оценки размера: резервирование максимума на каждый запрос уберёт часть allocations, но раздует RSS. Поэтому интервьюеру нужен не список оптимизаций, а связь профиля, выбранного изменения и измеренного компромисса.

AoS и SoA выбирают по паттерну доступа. В массиве структур поля одного объекта лежат рядом; это удобно, если горячий цикл использует большинство полей каждой записи. Структура массивов хранит одинаковые поля плотно и выигрывает, когда цикл читает, например, только координату x у большого числа объектов: cache line содержит меньше ненужных данных, а векторизация проще. Универсального победителя нет; layout проверяют на реальном размере данных и горячем пути.

Микробенчмарк должен сделать результат вычисления наблюдаемым. Если удалить потребление результата, компилятор вправе выкинуть чистое вычисление, и «ускорение» измерит пустой цикл. Используйте средства benchmark-библиотеки, которые не дают оптимизатору удалить значение, прогревайте нужное состояние, разделяйте настройку и измеряемую часть, проверяйте сгенерированный код. Затем подтвердите локальный выигрыш на интеграционном сценарии: cache, allocator и планировщик могут изменить эффект.

Инструменты находят ошибки только на выполненных путях

Чистый прогон ASan или UBSan не доказывает отсутствие ошибок. Sanitizer проверяет поддерживаемые классы дефектов на тех путях, которые реально выполнил тест. Неохваченная ветка, состояние гонки или логическая ошибка могут остаться. Для data race используют ThreadSanitizer в подходящей конфигурации, но и он зависит от выполненного расписания. Статический анализ, предупреждения компилятора, fuzzing, code review и тесты контрактов дополняют друг друга.

Набор проверок выбирают под гипотезу. ASan полезен для выхода за границы и ряда ошибок времени жизни, UBSan — для поддерживаемых проявлений неопределённого поведения, TSan — для наблюдаемых конфликтующих доступов. Запускать их в одной и той же сборке не всегда возможно или разумно: инструментация меняет скорость, память и расписание потоков. Поэтому отчёт должен фиксировать компилятор, флаги, входные данные и реально пройденные сценарии. Если дефект проявляется только без инструментации, сохраняют воспроизводимый тест и исследуют различие, а не объявляют результат ложным. Аналогично профильная сборка обязана быть достаточно близка к production: замеры debug-бинарника редко объясняют поведение оптимизированного кода. Чистый отчёт — свидетельство по конкретной конфигурации, а не сертификат всей программы.

Concepts делают требования шаблонного интерфейса явными и отсекают неподходящие типы ближе к месту вызова. Они улучшают диагностику и участвуют в выборе перегрузки, но не доказывают семантическое свойство автоматически. Требование наличия операции + не гарантирует её ассоциативность или отсутствие побочного эффекта. Хороший ответ различает синтаксическое ограничение, документированный смысл и runtime-проверку данных.

Для подготовки выберите по одному кейсу о времени жизни, многопоточности и производительности. В каждом назовите исходный дефект, минимальную гарантию языка, альтернативы, проверку и цену решения. Сверьте темы с актуальными вакансиями C++ разработчиков, затем сопоставьте глубину ответственности с зарплатными диапазонами C++ backend. Такой рассказ показывает инженерное мышление лучше, чем перечень стандартных контейнеров.