Вопросы для собеседования тимлида

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

• Частота и длительность, кто ведёт повестку
• Темы: проблемы, развитие, обратная связь, а не статус
• Общий документ с повесткой и договорённостями
• Регулярность: не отменять, переносить
• Пример, как 1:1 помогла заметить проблему рано

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

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

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

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

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

• debounce создаётся заново на каждом рендере - откладывание не работает
• нужен useMemo или useRef, чтобы функция пережила рендер
• нет отмены отложенного вызова при размонтировании
• q не экранирован через encodeURIComponent
• нет отмены предыдущего запроса - остаётся гонка
• проще перенести задержку в эффект с зависимостью от value

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

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

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

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

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

• Делегирую развивающее: архитектура модулей, демо, разбор инцидентов
• Делегирую повторяющееся: релизы, дежурства, отчёты
• Оставляю кадровое: оценки, зарплаты, увольнения
• Ответственность за результат остаётся у меня
• Пример, как делегирование вырастило человека или сняло узкое место

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

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

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

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

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

• сокет не закрывается - нет функции очистки, утечка на каждом монтировании
• roomId не в зависимостях - при смене комнаты подписка остаётся на старой
• setMessages читает messages из замыкания - всегда пустой массив, сообщения затирают друг друга
• нужна функциональная форма setMessages((prev) => [...prev, msg])
• у li нет key
• нет обработки ошибок сокета и разрыва соединения

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

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

• Назвал реальную слабость, а не штамп
• Слабость не критична для роли
• Рассказал, что делает, чтобы её компенсировать
• Есть пример прогресса
• Коротко, без самобичевания

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

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

• Исходная точка человека и его цель
• Как определили разрыв и цели
• Какие задачи, менторство и обратную связь дали
• Сложности по пути и как с ними справились
• Результат: новый уровень, роль, конкретные достижения

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

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

• ошибка проглатывается и превращается в null - вызывающий код падает на result.id
• нет проверки res.ok: 500 не попадёт в catch
• console.log вместо отправки в мониторинг
• пользователь не узнает, что заказ не сохранился
• повтор отправки может создать второй заказ - нужна идемпотентность
• catch без разбора типа ошибки: сеть, отмена и ошибка сервера смешаны

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

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

• div вместо form и button - нет отправки по Enter, нет клавиатуры, нет доступности
• у полей нет label, type, name и autocomplete; пароль виден
• нет Content-Type: application/json - сервер не разберёт тело
• нет проверки ответа: редирект произойдёт и при неверном пароле
• нет обработки ошибки сети и блокировки кнопки на время запроса
• alert вместо сообщения рядом с полем

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

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

• key по индексу - при удалении состояние полей съезжает на соседние
• нужен стабильный key из данных - todo.id
• defaultValue делает поле неконтролируемым, изменения никуда не сохраняются
• onRemove принимает индекс, а не идентификатор - ломается при сортировке и фильтрации
• у кнопки нет доступного имени - символ × скринридер не прочитает
• нет обработки пустого списка

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

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

• Поговорить с каждым отдельно: аргументы, интересы, что важно
• Вывести спор из PR в отдельное обсуждение с критериями решения
• Сравнить варианты по критериям: риски, сроки, поддержка; при необходимости прототип с таймбоксом
• Если согласия нет, принять решение самому или через архитектора и объяснить
• Зафиксировать решение в ADR, договориться о правилах на будущее

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

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

• Требования: личные и групповые чаты до 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

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

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

• Требования: список чатов, история, отправка, статусы, «печатает», уведомления, офлайн и плохая сеть
• Оценка: тысячи чатов, длинная история, в групповом чате десятки сообщений в секунду, долгоживущая вкладка
• API: WebSocket для событий (message.new, typing, read), REST для истории с курсором вверх, загрузка файлов отдельно
• Данные: сообщения по чатам с клиентским id, нормализация, IndexedDB для кеша и офлайн-очереди
• Компоненты: ChatList, ChatWindow с виртуализацией в обратном порядке, Composer, MessageBubble
• Узкие места: порядок и дедупликация, переподключение с догрузкой пропущенного, батчинг обновлений, утечки памяти, позиция скролла при подгрузке истории

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

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

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

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

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

• Сейчас: оценить ущерб и варианты, сообщить стейкхолдерам о риске сразу
• Помочь, а не забрать: вместе приоритизировать, при необходимости подключить людей
• Не искать виноватого при команде
• Потом: разбор с мидлом, что пошло не так: задача, полномочия, синхронизации
• Признать свою часть: где мне нужно было сверяться чаще
• Изменить подход: вехи, ранние сигналы, уровень делегирования

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

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

• Требования: публикация поста, подписка, лента с пагинацией; порядок по времени (ранжирование вне рамок или упрощённо); лента грузится < 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, удаление и редактирование постов

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

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

• Измерить: время до первого ревью и до мержа, размер PR
• Маленькие PR и стеки PR, шаблон описания
• Автоматизация в CI: линтер, типы, тесты, превью-стенды
• Договорённость о сроке реакции и слоты для ревью в дне
• CODEOWNERS и распределение ревьюеров, чтобы не было узкого горлышка
• Парное программирование для сложных задач

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

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

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

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

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

• Подготовиться: собрать конкретные примеры комментариев, не пересказывая, кто пожаловался
• Наедине и вскоре, а не на ревью через полгода
• По SBI: ситуация, конкретные комментарии, влияние на джунов и скорость команды
• Спросить его взгляд и причины, выслушать
• Договориться о правилах ревью и конкретном изменении
• Вернуться к теме через 2-3 недели и отметить прогресс

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

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

• Называю 2-3 альтернативы, а не одну
• Связываю выбор с требованиями и оценкой нагрузки
• Явно называю цену выбранного варианта
• Говорю, при каком условии решение пересмотрю
• Не называю технологию без причины

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

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

• DRY про дублирование знания, а не похожих строк
• Если куски меняются по разным причинам или для разных команд, их лучше не объединять
• Неправильная абстракция обрастает флагами и связывает модули
• Правило трёх: выносить общее, когда паттерн повторился и стабилизировался
• Абстракцию дешевле ввести позже, чем разобрать неудачную

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

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

• Проверить оценку: декомпозиция, допущения, риски, что можно распараллелить
• Выяснить у продакта, что клиенту действительно нужно к дате
• Подготовить варианты: MVP к дате, полная версия позже, что отрезать
• Обсудить с продактом и при необходимости с руководителем, решение принять вместе
• Зафиксировать договорённость и показывать прогресс еженедельно
• Договориться на будущее: срок клиенту называется после оценки

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