Вопросы для собеседования C++ разработчика

Что хотим услышать

• Препроцессор: include, макросы, условная компиляция, единица трансляции
• Компиляция каждой единицы отдельно в объектный файл
• В объектном файле определённые символы и неразрешённые ссылки
• Линковка: разрешение символов, статические библиотеки, релокации
• Динамические библиотеки разрешаются загрузчиком при запуске
• Типичные ошибки этапов: компиляции против линковки

Если ответил, копните глубже

Что хотим услышать

• Называет, что такое n (и m, если входов несколько)
• Считает циклы: вложенные перемножаются, последовательные складываются
• Помнит скрытые циклы: includes, indexOf, slice, sort, spread
• Отдельно оценивает память, включая стек рекурсии
• Сравнивает с ограничениями: при n до 10⁵ O(n²) уже не годится

Если ответил, копните глубже

Что хотим услышать

• Жёсткая ссылка: ещё одно имя того же inode, равноправное с оригиналом
• Данные живут, пока счётчик ссылок больше нуля и файл никто не держит открытым
• Жёсткую нельзя на каталог и между разными ФС
• Символьная: отдельный файл, внутри которого путь к цели
• Символьная ломается при удалении или переносе цели, зато работает с каталогами и через ФС
• Пример: symlink на текущий релиз current -> releases/42 для атомарного переключения

Если ответил, копните глубже

Что хотим услышать

• Same-origin policy: скрипт не может читать ответы другого origin (схема, хост, порт)
• CORS: сервер заголовками Access-Control-Allow-* разрешает конкретным origin читать ответы
• Проверяет браузер, сервер отвечает всегда; вне браузера CORS не действует
• Простые запросы уходят сразу, остальные после preflight OPTIONS
• С куками нужен credentials: 'include', Allow-Credentials: true и точный origin вместо *

Если ответил, копните глубже

Что хотим услышать

• Вертикальное: мощнее машина, код не меняется, есть предел и единая точка отказа
• Горизонтальное: больше узлов, нужен stateless или распределённое состояние
• Stateless-сервисы приложения масштабируют горизонтально в первую очередь
• БД часто сначала масштабируют вертикально и репликами, шардирование позже
• Горизонтальное даёт отказоустойчивость, но добавляет сложность

Если ответил, копните глубже

Что хотим услышать

• граф зависимостей от точки входа
• трансформация: TS, JSX, современный синтаксис, CSS
• резолв пакетов из node_modules
• склейка в чанки, минификация, tree shaking
• хеши в именах для долгого кеша
• dev-сервер с HMR и source maps

Если ответил, копните глубже

Что хотим услышать

• Две-три стороны, а не список из десяти
• Каждая подкреплена примером
• Стороны связаны с вакансией
• Нет пустых слов вроде «стрессоустойчивый, коммуникабельный» без доказательств
• Уверенно, без хвастовства

Если ответил, копните глубже

Что хотим услышать

• Три указателя: начало, конец данных, конец ёмкости
• Геометрический рост ёмкости, амортизированное O(1)
• Реаллокация: новый буфер, перенос элементов, освобождение старого
• Перемещение при реаллокации только если noexcept
• Инвалидация всех итераторов, указателей и ссылок
• reserve, если размер известен заранее

Если ответил, копните глубже

Что хотим услышать

• Сначала называет перебор O(n²) как базовое решение
• Идея: для x ищем дополнение target - x в Map
• Проверяет Map до вставки x, чтобы не взять один элемент дважды
• Сложность O(n) времени и O(n) памяти
• Упоминает краевые случаи: дубликаты, нет ответа

Если ответил, копните глубже

Что хотим услышать

• Три дескриптора: 0 stdin, 1 stdout, 2 stderr
• > перезаписывает, >> дописывает, 2> для ошибок, < для ввода
• > file 2>&1 объединяет потоки, порядок важен: перенаправления слева направо
• Пайп передаёт только stdout, для ошибок нужен 2>&1 |
• sudo cmd > /etc/x не работает: файл открывает shell без прав, используют | sudo tee
• /dev/null для выбрасывания ненужного вывода

Если ответил, копните глубже

Что хотим услышать

• GET читает и безопасен, POST меняет состояние
• GET идемпотентен, POST нет: его нельзя молча повторять
• GET кешируется браузером и прокси, POST по умолчанию нет
• Параметры GET в URL: попадают в логи и историю, длина ограничена серверами
• GET можно добавить в закладки и prefetch, поэтому нельзя менять данные по GET

Если ответил, копните глубже

Что хотим услышать

• Асинхронность: пользователь не ждёт долгой работы
• Сглаживание пиков: очередь копит, консьюмеры разбирают
• Развязка сервисов: продюсер не знает о получателях
• Ретраи при временных сбоях получателя
• Цена: eventual consistency, дубли, мониторинг отставания

Если ответил, копните глубже

Что хотим услышать

• Ровно одно определение не-inline функции и переменной на программу
• Классы, inline-функции, шаблоны: по определению на единицу трансляции, и все одинаковые
• Multiple definition: диагностируемое нарушение
• Разные определения одного inline или класса: UB без диагностики
• Источники: разные макросы и флаги, копипаста имён классов в разных файлах
• Средства: безымянные пространства имён, модули, -fsanitize или детекторы ODR в линковщике (gold, lld)

Если ответил, копните глубже

Что хотим услышать

• Воспроизвести и уточнить симптом: таймаут, refused, ошибка TLS, 5xx
• DNS: dig +short, правильный ли IP, не истёк ли домен
• Сеть и порт снаружи: curl -v, nc -zv host 443; refused или timeout
• На сервере: слушает ли процесс и на каком адресе (ss -tlnp), отвечает ли локально
• Фаервол на хосте и в облаке, балансировщик и его health checks
• Логи прокси и приложения, сертификат и его срок

Если ответил, копните глубже

Что хотим услышать

• Реконнект с экспоненциальной задержкой и джиттером, сброс задержки после успеха
• Heartbeat: ping/pong с таймаутом, при пропуске закрыть и переподключиться
• Нумерация сообщений: после реконнекта клиент сообщает последний id, сервер досылает пропущенное
• Очередь исходящих сообщений с клиентскими id, идемпотентность на сервере против дублей
• Реакция на online/offline и видимость вкладки, повторная авторизация при истёкшем токене

Если ответил, копните глубже

Что хотим услышать

• Требования: личные и групповые чаты до 1 000 участников, доставка онлайн и офлайн (push), история, статусы «доставлено» и «прочитано»; порядок сообщений в чате; медиа и сквозное шифрование вне рамок
• Оценка нагрузки: 50 млн DAU по 40 сообщений ≈ 2 млрд в сутки ≈ 20 000 RPS записи, в пике ~60 000; 10 млн одновременных соединений, ~100 000 на gateway → ~100 gateway; 2 млрд × 200 байт ≈ 400 ГБ в сутки, ~150 ТБ в год без реплик
• API: WebSocket: send {chat_id, client_msg_id, text}, ack {msg_id}, события new_message, read; HTTP: GET /chats/{id}/messages?before=...
• Данные: чаты и участники в PostgreSQL, сообщения в Cassandra/ScyllaDB с ключом партиции chat_id и сортировкой по msg_id, реестр user_id → gateway в Redis с TTL
• Компоненты: gateway-серверы с соединениями, сервис сообщений (сохранить, присвоить id, разослать), сервис присутствия, push-сервис для офлайн, очередь для фан-аута в группах
• Узкие места: большие группы (фан-аут через очередь), дубли при переотправке (client_msg_id для идемпотентности), переподключения и догрузка пропущенного, горячие чаты, падение gateway

Если ответил, копните глубже

Что хотим услышать

• начать с самого рискованного и ценного для бизнеса: оплата, вход, ключевые сценарии
• несколько e2e smoke-тестов на критичные пути
• unit-тесты на чистую логику: расчёты, форматирование, утилиты
• интеграционные тесты компонентов и API на новых и изменяемых местах
• тесты в CI как обязательная проверка PR
• регрессионный тест на каждый найденный баг, борьба с флаки

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже

Что хотим услышать

• Nothrow, строгая, базовая: определения
• RAII как основа: деструкторы освобождают всё при раскрутке
• Строгая гарантия через copy-and-swap или «сначала всё, что может бросить, потом коммит»
• noexcept на move, swap, деструкторах; влияние на vector
• Деструкторы не бросают
• Примеры из стандартной библиотеки: push_back строгая, insert в середину базовая

Если ответил, копните глубже

Что хотим услышать

• Сначала SIGTERM, затем ожидание (таймаут), и только потом SIGKILL
• Приложение ловит SIGTERM: перестаёт принимать новые запросы, дожидается текущих, закрывает соединения с БД
• SIGKILL нельзя перехватить, поэтому после него остаются lock-файлы и незавершённые операции
• systemd делает так же: KillSignal, TimeoutStopSec, затем SIGKILL
• В контейнере процесс должен быть PID 1 или запускаться через init (tini), иначе сигнал не дойдёт
• Код выхода 143 после SIGTERM и 137 после SIGKILL помогают понять, как завершился процесс

Если ответил, копните глубже

Что хотим услышать

• Измерить: Navigation Timing и RUM по этапам (DNS, connect, TLS, TTFB, загрузка, рендер), Lighthouse и WebPageTest
• Сеть: CDN ближе к пользователю, HTTP/2 или HTTP/3, preconnect к сторонним доменам
• Сервер: медленный TTFB → кеширование, отдача статики с CDN, 103 Early Hints
• Ресурсы: Brotli, меньше JS, code splitting, оптимизированные картинки с размерами
• Рендер: критический CSS, defer для скриптов, без блокирующих сторонних скриптов

Если ответил, копните глубже

Что хотим услышать

• Требования: публикация поста, подписка, лента с пагинацией; порядок по времени (ранжирование вне рамок или упрощённо); лента грузится < 200 мс, допустима задержка появления поста в секунды
• Оценка нагрузки: 100 млн DAU, 10 открытий ленты в день ≈ 10 000 RPS чтения, в пике ~30 000; 10 млн постов в сутки ≈ 100 RPS записи; при 200 подписчиках в среднем ≈ 20 000 вставок в ленты в секунду
• API: POST /posts; GET /feed?cursor=...&limit=20; POST /users/{id}/follow
• Данные: посты в шардированной БД по author_id, граф подписок отдельно, готовые ленты как списки id постов в Redis (последние ~500), медиа в S3
• Компоненты: сервис постов, очередь событий публикации, fan-out воркеры, сервис ленты, кеш постов, CDN для медиа
• Узкие места: аккаунты-звёзды (гибрид on write + on read), неактивные пользователи (не раскладывать, собирать при входе), пагинация курсором, память Redis, удаление и редактирование постов

Если ответил, копните глубже

Что хотим услышать

• Акцент на масштаб и влияние, а не на список фич
• Метрики бизнес-эффекта
• Лидерство: менторинг, процессы, архитектурные решения
• Компактность: старый опыт свёрнут
• Понимание, что резюме под роль, а не под всё сразу

Если ответил, копните глубже

Что хотим услышать

• Шаблонный параметр или std::invocable: точный тип, встраивание, но код в заголовке и раздувание
• std::function: стирание типа, хранение разнородных колбэков, цена аллокации и косвенного вызова
• Указатель на функцию: дёшево, но без состояния
• function_ref (C++26) или ссылка на вызываемый для невладеющей передачи
• move_only_function для move-only замыканий в C++23

Если ответил, копните глубже