Перейти к основному содержимому

Проверка навыков SRE: собеседования по system design и troubleshooting / Ал-др Поломодов (Тинькофф)

· 49 мин. чтения
DevOps Channel
DevOps Channel

Сегодня мы разберем процесс найма инженеров на примере Тинькофф, где технические собеседования разделены на несколько этапов: системный инжиниринг, программирование и troubleshooting. Основной акцент сделан на этап troubleshooting — кандидат должен продемонстрировать умение диагностировать и устранять инциденты в условиях, приближенных к реальным, а также предложить улучшения для повышения надежности системы. Мы также обсудим, почему из процесса найма был исключен этап system design и как кандидаты могут прокачаться в обоих направлениях.

Вопрос 1. Как выглядит процесс найма в компании Тинькофф для инженеров?​

Таймкод: 00:01:49

Ответ собеседника: Правильный. Процесс найма включает несколько этапов: сначала общение с рекрутером для оценки целесообразности продолжения, затем технические этапы — системное интервью (вопросы по сетям, ОС, распределённым системам), этап программирования (решение задач на код для проверки умения писать скрипты и работать с алгоритмической сложностью), и этап troubleshooting. Если кандидат успешно проходит все этапы, его показывают внутренним командам, проводится fit-интервью с командой, и при успешном прохождении выдаётся оффер.

Правильный ответ:

Процесс найма в Тинькофф для инженерных позиций действительно многоэтапный и достаточно структурированный. Вот более детальная расшифровка каждого этапа:

1. Скрининг с рекрутером

На этом этапе рекрутер оценивает общее соответствие кандидата: опыт работы, технический стек, ожидания по компенсации, мотивацию и релевантность позиции. Это не просто формальный звонок — рекрутер может задать базовые технические вопросы, чтобы убедиться, что кандидат соответствует минимальному порогу для прохождения на технические этапы.

2. Системное интервью (System Design / Infrastructure Interview)

Этот этап проверяет понимание фундаментальных аспектов инженерной работы:

  • Сети: TCP/IP, HTTP/HTTPS, DNS, балансировка нагрузки, TLS-рукопожатие, модель OSI
  • Операционные системы: процессы и потоки, управление памятью, файловые системы, планировщики, системные вызовы
  • Распределённые системы: консистентность, доступность, теорема CAP, репликация, шардирование, паттерны взаимодействия микросервисов
  • Базы системы хранения: индексы, транзакции, уровни изоляции, выбор СУБД под конкретные задачи

3. Этап программирования (Coding Interview)

Здесь проверяется способность кандидата писать рабочий код:

  • Решение алгоритмических задач с анализом временной и пространственной сложности
  • Умение писать чистый, читаемый код с правильной обработкой ошибок
  • Для Go-разработчиков могут быть задачи на работу с горутинами, каналами, контекстами
  • Важно не только решить задачу, но и объяснить ход рассуждений, обсудить альтернативные подходы

4. Этап Troubleshooting

Это один из наиболее специфичных этапов Тинькофф. Кандидату предлагается диагностировать проблему в распределённой системе:

  • Анализ логов, метрик, трейсов
  • Умение выстроить гипотезу и последовательно её проверять
  • Понимание того, как сервисы взаимодействуют друг с другом
  • Способность работать с неполной информацией и задавать правильные уточняющие вопросы

5. Fit-интервью с командой

После успешного прохождения технических этапов кандидат знакомится с потенциальной командой:

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

6. Выдача оффера

При положительном решении со всех этапов формируется оффер с обсуждением условий.

Рекомендации по подготовке:

  • Для системного интервью полезно повторить основы сетей и ОС, почитать про проектирование распределённых систем
  • Для кодинга — регулярно решать задачи на LeetCode / Codeforces, уделяя внимание объяснению решений
  • Для troubleshooting — практиковаться в анализе реальных инцидентов, изучать post-mortem отчёты крупных компаний

Вопрос 2. Зачем компании нужен этап troubleshooting на собеседовании?​

Таймкод: 00:03:38

Ответ собеседника: Правильный. Этап troubleshooting необходим из-за масштаба компании — более 25 миллионов клиентов, быстро растущая нагрузка, мультипродуктовая экосистема со сложными интеграциями между продуктами. Компания переходит к децентрализации обеспечения надёжности, где инженеры в кросс-функциональных командах должны самостоятельно устранять инциденты. Поэтому важно проверить, насколько кандидат способен диагностировать и решать проблемы в сложных распределённых системах.

Правильный ответ:

Этап troubleshooting является одним из ключевых дифференциаторов процесса найма в Тинькофф и обусловлен несколькими важными факторами:

Масштаб и сложность инфраструктуры

Тинькофф обслуживает более 25 миллионов клиентов, и это число продолжает расти. Компания представляет собой мультипродуктовую экосистему: банк, страхование, инвестиции, путешествия, мобильная связь и множество других сервисов. Каждый продукт — это набор микросервисов, которые взаимодействуют друг с другом через различные протоколы и брокеры сообщений. Интеграции между продуктами создают сложные цепочки зависимостей, где сбой одного компонента может каскадно повлиять на работу нескольких сервисов одновременно.

Децентрализация обеспечения надёжности

Традиционная модель, когда есть выделенная команда SRE или NOC, которая занимается всеми инцидентами, не масштабируется при таком количестве продуктов и команд. Тинькофф движется к модели, где каждая кросс-функциональная команда отвечает за надёжность своих сервисов end-to-end. Это означает, что инженер должен уметь самостоятельно диагностировать проблему, находить корневую причину и устранять её, а не передавать инцидент в другую команду.

Что именно проверяется на этом этапе

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

Пример задачи troubleshooting

Кандидату может быть предложена ситуация: «Пользователи жалуются, что приложение стало медленно открываться. Вот графики метрик, вот фрагменты логов, вот топология сервисов». Нужно определить, где проблема: в сети, в базе данных, в конкретном сервисе, в инфраструктуре — и предложить план действий.

Почему это важно именно для Go-разработчиков

Go часто используется для написания высоконагруженных микросервисов, которые являются критичными элементами инфраструктуры. Инженер, пишущий такие сервисы, должен понимать, как его код ведёт себя в продакшене, как диагностировать проблемы с горутинами, утечки памяти, проблемы с конкурентностью, таймауты при взаимодействии с другими сервисами.

Вопрос 3. Зачем этап troubleshooting нужен самому кандидату?​

Таймкод: 00:05:31

Ответ собеседника: Правильный. Для кандидата этот этап полезен по двум причинам: во-первых, это возможность получить интересный опыт работы с инцидентами в условиях, приближённых к реальным, но с гораздо меньшей ценой ошибки — можно попробовать себя в почти боевых условиях без реальных последствий. Во-вторых, в зависимости от результатов кандидат может получить обратную связь о том, какие знания и навыки стоит подтянуть, что тоже является ценным опытом для профессионального роста.

Правильный ответ:

Этап troubleshooting ценен для кандидата не менее, чем для компании, и вот почему:

Безопасная среда для получения опыта

В реальной работе цена ошибки при диагностике инцидента может быть очень высокой: потеря данных, длительный даунтайм, финансовые потери, недовольство клиентов. На собеседовании кандидат может попробовать себя в максимально приближённых к реальным условиях, но без каких-либо последствий. Это возможность проверить свои навыки диагностики, столкнуться с нестандартной задачей и понять, как вы действуете в условиях неопределённости и ограниченного времени.

Получение качественной обратной связи

Тинькофф известен тем, что даёт развёрнутую обратную связь кандидатам, даже если они не прошли собеседование. На этапе troubleshooting интервьюер может подсказать, какие направления диагностики кандидат упустил, какие инструменты стоило использовать, какие знания подтянуть. Это конкретная и применимая информация, которую сложно получить из других источников.

Понимание рабочих процессов компании

Прохождение этого этапа даёт кандидату представление о том, как в компании организована работа с инцидентами:

  • Какие инструменты мониторинга и диагностики используются
  • Как устроены процессы эскалации
  • Какой уровень самостоятельности ожидается от инженера
  • Как команды взаимодействуют при решении кросс-сервисных проблем

Это помогает кандидату принять осознанное решение о том, подходит ли ему такая работа.

Оценка своей готовности

Многие разработчики привыкли работать в режиме «написать код, закрыть задачу» и не имеют опыта диагностики проблем в продакшене. Этап troubleshooting помогает честно оценить свой уровень и понять, какие компетенции нужно развивать. Это особенно ценно для разработчиков, которые переходят из компаний с другой культурой — например, где за надёжность отвечает отдельная команда SRE, а разработчики не вовлечены в онкол и диагностику.

Демонстрация сильных сторон

Для кандидатов с опытом работы в продакшене этот этап — возможность показать свою экспертизу. Умение методично подходить к диагностике, задавать правильные вопросы, интерпретировать метрики и логи — всё это выделяет кандидата и может компенсировать недостатки на других этапах.

Рекомендации к подготовке

  • Изучите основы мониторинга: метрики (Prometheus), логирование (ELK), трейсинг (Jaeger)
  • Практикуйтесь в анализе постмортемов — многие крупные компании публикуют их открыто
  • Попробуйте решить задачи на платформах вроде PagerDuty или просто проанализируйте реальные инциденты из блогов инженерных команд
  • Освойте базовые инструменты диагностики: tcpdump, strace, pprof для Go

Вопрос 4. Как устроена секция troubleshooting на собеседовании — какие этапы она включает?​

Таймкод: 00:06:55

Ответ собеседника: Правильный. Секция troubleshooting состоит из нескольких этапов. Сначала описывается регламент и легенда: кандидат — это лид-инженер, который уходит в отпуск, оставляя джуна дежурить. Далее обсуждается архитектура системы, которую поддерживает команда: компоненты, связи между ними, нагрузка. Затем кандидат может задать уточняющие вопросы по архитектуре. После этого стартует инцидент — интервьюер в роли джуна описывает симптомы. Кандидат задаёт вопросы и даёт рекомендации по действиям, формулирует гипотезы и предлагает эксперименты для диагностики. Когда накоплена достаточная информация, кандидат предлагает быстрое решение (workaround) для устранения симптомов. Затем нужно предложить полноценное исправление с объяснением алгоритма. В конце кандидат должен докопаться до корневой причины проблемы и собрать полную картину.

Правильный ответ:

Секция troubleshooting в Тинькофф построена как симуляция реального инцидента и включает несколько последовательных этапов, каждый из которых проверяет определённые компетенции:

1. Введение и легенда

Кандидату описывается контекст: он — лид-инженер команды, который уходит в отпуск. На дежурстве остаётся джуниор-разработчик. Кандидат играет роль старшего коллеги, который консультирует джуна по телефону. Это задаёт рамку взаимодействия: кандидат должен не просто решить проблему, но и объяснить свои действия менее опытному коллеге.

2. Обсуждение архитектуры

Интервьюер описывает архитектуру системы, которую поддерживает команда:

  • Основные компоненты и их ответственность
  • Связи между сервисами (синхронные, асинхронные)
  • Используемые технологии и протоколы
  • Примерные объёмы нагрузки
  • Критичные пути для бизнеса

3. Уточняющие вопросы

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

4. Старт инцидента

Интервьюер в роли джуна описывает симптомы проблемы. Например: «Поступают жалобы от пользователей, что приложение стало очень медленно работать. В логах вижу много ошибок таймаута». Формулировка намеренно неполная — как в реальной жизни.

5. Диагностика

Кандидат задаёт уточняющие вопросы, формулирует гипотезы и предлагает эксперименты:

  • Какие метрики посмотреть и почему
  • Какие логи проверить
  • Как проверить конкретную гипотезу
  • Как интерпретировать результаты

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

6. Workaround (быстрое решение)

Когда проблема локализована, кандидат должен предложить быстрое решение для устранения симптомов:

  • Переключение на резервный сервис
  • Откат деплоя
  • Увеличение ресурсов
  • Включение rate-limiting

Это проверяет умение разделить устранение симптомов и исправление корневой причины.

7. Полноценное исправление

Кандидат предлагает решение, которое устраняет проблему полностью:

  • Исправление кода
  • Изменение конфигурации
  • Обновление инфраструктуры
  • Необходимые тесты

8. Корневая причина

Финальный этап — докопаться до корневой причины:

  • Почему проблема возникла
  • Почему не была обнаружена раньше
  • Как предотвратить повторение
  • Какие улучшения процессов необходимы

Что оценивается в процессе

  • Логичность и последовательность диагностики
  • Умение задавать правильные вопросы
  • Скорость локализации проблемы
  • Качество коммуникации (объяснение для джуна)
  • Баланс между быстрым решением и полноценным исправлением
  • Глубина анализа корневой причины

Вопрос 5. Как выглядит типовая задача на этапе troubleshooting и как происходит диагностика инцидента?​

Таймкод: 00:11:44

Ответ собеседника: Правильный. Даётся условная система — масс-медиа ресурс с несколькими миллионами клиентов, развёрнутая в двух дата-центрах. Архитектура включает фронтовое приложение на React, backend на Django, слой консистентного кэша с базой данных PostgreSQL в каждом дата-центре. Стартует инцидент: пользователи жалуются на долгую загрузку страниц и неполную загрузку. Кандидат задаёт вопросы интервьюеру (в роли джуна): что можно посмотреть, какие логи и метрики доступны. Выясняется, что количество запросов не выросло, но увеличилось количество ошибок и среднее время ответа. Основные ошибки — gateway timeout и 5xx. Далее кандидат идёт в логи приложения для выяснения причин. Диалог продолжается с целью собрать максимум информации о симптомах и выяснить, что пошло не так.

Правильный ответ:

Разберём типовую задачу troubleshooting более детально, чтобы понять логику диагностики и ожидаемый ход рассуждений.

Описание системы

Представьте масс-медиа ресурс с несколькими миллионами пользователей, развёрнутый в двух дата-центрах для отказоустойчивости:

  • Фронтенд: SPA-приложение на React, раздаётся через CDN
  • Backend: монолит на Django, обрабатывающий основную бизнес-логику
  • Кэш: слой консистентного кэша (например, Redis Cluster) перед базой данных
  • База данных: PostgreSQL в каждом дата-центре с репликацией
  • Балансировка: L7-балансировщик распределяет трафик между дата-центрами

Симптомы инцидента

Пользователи жалуются на:

  • Долгую загрузку страниц
  • Неполную загрузку (часть контента не отображается)

Этап 1: Первичная оценка

Кандидат должен начать с уточняющих вопросов:

  • Есть ли алерты в мониторинге?
  • Как изменились ключевые метрики: RPS, latency, error rate?
  • Проблема затрагивает всех пользователей или только определённый регион?
  • Были ли недавние деплои или изменения конфигурации?

Этап 2: Анализ метрик

Интервьюер предоставляет данные:

  • Количество запросов (RPS) — стабильное, без аномалий
  • Среднее время ответа (latency) — выросло в 3-4 раза
  • Количество ошибок — увеличилось до 15-20%
  • Основные ошибки: Gateway Timeout (504) и Internal Server Error (500)

Из этих данных можно сделать вывод: проблема не в росте трафика, а в деградации производительности бэкенда.

Этап 3: Анализ логов

Кандидат запрашивает логи приложения и видит:

  • Много ошибок таймаута при обращении к кэшу
  • Некоторые запросы к базе данных выполняются аномально долго
  • Периодически возникают ошибки подключения к реплике БД

Этап 4: Формулирование гипотез

На основе собранной информации кандидат формулирует гипотезы:

  • Проблема с кэшем (Redis) — возможно, часть нод недоступна
  • Проблема с базой данных — возможно, реплика отстаёт или перегружена
  • Проблема с сетью между дата-центрами

Этап 5: Проверка гипотез

Кандидат предлагает конкретные действия:

  • Проверить статус Redis Cluster: CLUSTER INFO, CLUSTER NODES
  • Проверить лаг репликации в PostgreSQL: pg_stat_replication
  • Проверить сетевую связность между дата-центрами: ping, traceroute, метрики сети

Этап 6: Локализация проблемы

Допустим, выяснилось, что одна из нод Redis в первом дата-центре упала, и весь трафик пошёл на оставшиеся ноды, которые не справляются с нагрузкой. Часть запросов идёт напрямую в базу данных, вызывая её перегрузку.

Этап 7: Workaround

Быстрое решение:

  • Временно увеличить количество нод в Redis Cluster
  • Включить circuit breaker для запросов к перегруженной реплике БД
  • Перенаправить часть трафика на второй дата-центр

Этап 8: Полноценное исправление

  • Восстановить упавшую ноду Redis
  • Настроить автоматическое масштабирование кэш-слоя
  • Добавить мониторинг на отставание реплик
  • Настроить алерты на деградацию кэша

Этап 9: Корневая причина

  • Почему нода Redis упала? Возможно, нехватка памяти или ошибка в конфигурации
  • Почему не сработал failover? Возможно, проблемы с настройкой sentinel
  • Как предотвратить? Улучшить мониторинг, добавить автоматический failover, провести нагрузочное тестирование

Ключевые навыки, которые демонстрирует кандидат

  • Системный подход к диагностике
  • Умение задавать правильные вопросы
  • Знание типичных проблем распределённых систем
  • Понимание взаимосвязей между компонентами
  • Способность разделить workaround и полноценное исправление

Вопрос 6. По каким критериям оценивается кандидат на этапе troubleshooting?​

Таймкод: 00:15:38

Ответ собеседника: Правильный. Используется шесть критериев оценки. Первый — кругозор кандидата: насколько широк набор приёмов, практик и инструментов, которые он использует при решении проблемы. Второй — логичность и методичность поиска: как кандидат выдвигает гипотезы, проверяет их, отбрасывает неподтвердившиеся и собирает общую картину. Третий — способность найти быстрое решение (workaround) для устранения симптомов для пользователей, а не закопаться в исследовании. Четвёртый — докопался ли кандидат до финального исправления проблемы и способен ли объяснить алгоритм починки по шагам. Пятый — понимание корневой причины: смог ли кандидат объяснить, почему возникла ситуация, почему были такие симптомы и как алгоритм помог. Шестой — способность предложить улучшения системы, причём не на уровне «добавить больше логов», а архитектурные решения, чтобы проблема не повторялась.

Правильный ответ:

Оценка на этапе troubleshooting проводится по шести ключевым критериям, каждый из которых отражает важный аспект инженерной работы:

1. Кругозор (Breadth of Knowledge)

Этот критерий оценивает широту технических знаний и инструментария кандидата:

  • Знает ли кандидат различные типы метрик (бизнесовые, инфраструктурные, пользовательские)
  • Понимает ли разные уровни стека: сеть, ОС, приложение, база данных, кэш
  • Знаком ли с инструментами диагностики: профайлеры, анализаторы логов, системы трейсинга
  • Может ли предложить несколько подходов к решению проблемы

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

2. Логичность и методичность (Systematic Approach)

Оценивается структурированность мышления:

  • Выдвигает ли кандидат гипотезы или действует хаотично
  • Проверяет ли гипотезы последовательно или одновременно
  • Отбрасывает ли неподтвердившиеся гипотезы
  • Собирает ли разрозненные факты в единую картину

Идеальный подход: формулировка гипотезы → определение данных для проверки → получение данных → подтверждение или опровержение → следующая гипотеза.

3. Способность найти workaround (Quick Fix)

Критически важный навык для реальной работы:

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

Примеры workaround: откат деплоя, переключение на резервную систему, увеличение ресурсов, включение деградационного режима.

4. Полноценное исправление (Complete Fix)

Кандидат должен не просто устранить симптомы, но и предложить полноценное решение:

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

5. Корневая причина (Root Cause Analysis)

Глубина понимания проблемы:

  • Может ли кандидат объяснить, почему проблема возникла
  • Понимает ли связь между корневой причиной и наблюдаемыми симптомами
  • Может ли объяснить, почему предложенное решение устранит проблему
  • Понимает ли, почему проблема не была обнаружена раньше

6. Архитектурные улучшения (System Improvements)

Самый высокий уровень — способность предложить системные изменения:

  • Предлагает ли кандидат улучшения на уровне архитектуры, а не косметические исправления
  • Понимает ли, как предотвратить повторение подобных проблем
  • Предлагает ли улучшения процессов, мониторинга, тестирования

Примеры хороших предложений:

  • Внедрение circuit breaker для защиты от каскадных сбоев
  • Добавление канир-деплоев для раннего обнаружения проблем
  • Настройка SLO/SLI и алертов на их нарушение
  • Внедрение chaos engineering для проверки отказоустойчивости

Примеры слабых предложений:

  • «Добавить больше логов» (без конкретики, какие логи и зачем)
  • «Увеличить ресурсы» (без понимания, каких именно и почему)
  • «Переписать всё с нуля» (нереалистичное предложение)

Как использовать эту информацию при подготовке

Зная критерии оценки, можно целенаправленно развивать нужные навыки:

  • Расширять кругозор: изучать различные инструменты и технологии
  • Тренировать методичность: решать задачи, проговаривая ход рассуждений
  • Практиковать разделение workaround и полноценного исправления
  • Учиться проводить root cause analysis на реальных инцидентах
  • Думать об архитектурных улучшениях, а не о точечных фиксах

Вопрос 7. Какие уровни кандидатов выделяются по результатам troubleshooting и приведите пример профиля?​

Таймкод: 00:18:08

Ответ собеседника: Правильный. Формально выделяют уровни junior, middle, senior, senior+, но в реальности кандидаты проходят этапы неравномерно. Пример профиля: кандидат с хорошим кругозором и широким набором инструментов, логично и методично идёт по инциденту, находит быстрое решение для пользователей. Однако дальше проявляется недостаток опыта — он не может докопаться до конца, методично проверяет гипотезы одну за другой, но не находит корневую причину. Полноценная система не починена, root cause не найден, предложения по улучшению сводятся к добавлению мониторинга. Это профиль джуна с перспективами, которому нужно набраться опыта, и который должен работать с продвинутыми коллегами, способными помочь.

Правильный ответ:

Уровни кандидатов по результатам troubleshooting действительно не всегда соответствуют линейной шкале — кандидат может быть сильным в одних аспектах и слабым в других. Рассмотрим типичные профили:

Junior с перспективами

Как описано в ответе кандидата, это человек с хорошим потенциалом, но недостаточным опытом:

  • Хороший кругозор и знание инструментов
  • Логичный и методичный подход к диагностике
  • Способность найти workaround
  • Проблемы с доведением до корневой причины
  • Предложения по улучшению поверхностные

Такой кандидат может быть полезен в команде с сильными старшими разработчиками, которые помогут ему развить недостающие навыки.

Middle-разработчик

Типичный профиль:

  • Хорошо диагностирует проблемы в знакомых системах
  • Находит workaround и часто полноценное исправление
  • Докапывается до корневой причины в стандартных ситуациях
  • Кругозор ограничен знакомым стеком технологий
  • Архитектурные предложения скорее тактические, чем стратегические

Senior-разработчик

Ожидаемый уровень:

  • Широкий кругозор, выходящий за рамки одного стека
  • Быстрая и точная диагностика
  • Эффективный workaround с минимальным воздействием на систему
  • Полноценное исправление с учётом побочных эффектов
  • Глубокий анализ корневой причины
  • Архитектурные предложения, предотвращающие целый класс проблем

Senior+ / Tech Lead

Высший уровень:

  • Все навыки senior-уровня плюс системное мышление
  • Способность видеть проблему в контексте всей платформы
  • Предложения по улучшению процессов, а не только технических решений
  • Умение объяснить проблему и решение заинтересованным сторонам
  • Понимание бизнес-последствий технических решений

Нелинейность прохождения этапов

Важно понимать, что кандидаты часто проходят этапы неравномерно. Например:

  • Кандидат может отлично найти workaround, но не докопаться до корневой причины — это указывает на хорошие навыки реагирования, но недостаточную глубину анализа
  • Кандидат может найти корневую причину, но не предложить эффективный workaround — это указывает на аналитический склад мышления, но недостаток опыта работы под давлением
  • Кандидат может предложить отличные архитектурные решения, но плохо диагностировать — это указывает на стратегическое мышление, но слабые операционные навыки

Как готовиться к каждому уровню

Для перехода с junior на middle:

  • Практиковаться на реальных инцидентах из блогов компаний
  • Учиться доводить диагностику до конца, не останавливаясь на workaround
  • Изучать типичные корневые причины проблем в распределённых системах

Для перехода с middle на senior:

  • Расширять кругозор за пределы знакомого стека
  • Учиться видеть системные проблемы, а не точечные
  • Развивать навык быстрой диагностики в незнакомых системах
  • Практиковать архитектурное мышление

Вопрос 8. Почему из процесса найма был убран этап system design интервью?​

Таймкод: 00:19:56

Ответ собеседника: Правильный. Год-полтора назад помимо трёх технических этапов (системный инжиниринг, программирование и troubleshooting) существовал четвёртый этап — system design. Он был убран, и спикер решил разобраться почему, а также показать связь между troubleshooting и system design. System design интервью — это собеседование про проектирование системы, где кандидату даются требования и ограничения, и он должен спроектировать архитектуру. Спикер объясняет, что troubleshooting фактически пересекается с system design — последний шаг troubleshooting предполагает, что кандидат предлагает улучшения системы, чтобы сделать её более надёжной, что по сути является задачей проектирования. Таким образом, troubleshooting уже включает в себя элементы system design.

Правильный ответ:

Убирая отдельный этап system design из процесса найма, Тинькофф принял осознанное решение, основанное на анализе того, что именно проверяет каждый этап и как они пересекаются.

Что такое system design интервью

Классическое system design интервью — это сессия, на которой кандидату даются требования к системе (функциональные и нефункциональные) и он должен спроектировать архитектуру:

  • Определить основные компоненты и их ответственность
  • Выбрать подходящие технологии и протоколы взаимодействия
  • Продумать масштабирование, отказоустойчивость, консистентность данных
  • Обсудить компромиссы и trade-offs

Примеры задач: «Спроектируйте Twitter», «Спроектируйте систему обмена сообщениями», «Спроектируйте CDN».

Пересечение troubleshooting и system design

Ключевое наблюдение заключается в том, что troubleshooting уже включает в себя элементы проектирования:

  • На этапе troubleshooting кандидат анализирует существующую архитектуру, понимает её слабые места
  • Предложения по улучшению системы — это по сути задача редизайна архитектуры
  • Кандидат должен понимать, какие архитектурные решения привели к проблеме и как их исправить

Например, если проблема возникла из-за отсутствия circuit breaker, кандидат должен предложить его добавление — это архитектурное решение.

Почему убрали отдельный этап

Несколько причин для этого решения:

  • Избыточность: Отдельный system design интервью дублировал бы то, что уже проверяется на troubleshooting
  • Эффективность процесса: Убирая этап, компания сокращает время процесса найма, не теряя в качестве оценки
  • Более реалистичная оценка: Troubleshooting проверяет способность кандидата работать с реальной системой, а не проектировать идеальную систему с нуля
  • Контекст задачи: В troubleshooting кандидат работает с конкретной проблемой и конкретной архитектурой, что ближе к реальной работе

Что это значит для кандидата

Хотя отдельного этапа system design нет, навыки проектирования всё ещё проверяются:

  • Нужно понимать архитектурные паттерны и их применимость
  • Нужно уметь предлагать улучшения на уровне архитектуры
  • Нужно понимать trade-offs различных решений

Подготовка к troubleshooting автоматически включает подготовку к system design, если кандидат фокусируется не только на диагностике, но и на предложении архитектурных улучшений.

Вопрос 9. Что такое system design интервью и как оно проводится?​

Таймкод: 00:21:01

Ответ собеседника: Правильный. System design интервью — это собеседование про проектирование системы. В начале ничего нет, только название и базовый контекст — набор ограничений и ожиданий от системы, формальные функциональные и нефункциональные требования. Хороший кандидат сначала формализует задачу, понимает какие архитектурные характеристики являются ключевыми (high availability, consistency, latency, scalability и т.д. — в разных задачах разные). Затем кандидат уточняет про масштабирование — ожидаемую нагрузку, объём хранения данных, чтобы понять как обеспечить отказоустойчивость. Далее кандидат начинает проектировать: определяет границы системы, сценарии использования, публичный API. Затем прорабатывает внутреннее устройство — потоки данных, компоненты системы, happy path и edge cases. В итоге формируется концептуальная диаграмма с определёнными компонентами (реляционная БД, очереди, масштабируемые компоненты). Потом обсуждаются конкретные технологии и их способность выдерживать планируемую нагрузку. Последний этап — дополнительные вопросы со звёздочкой, дающие дополнительные баллы.

Правильный ответ:

System design интервью — это структурированный процесс оценки способности кандидата проектировать сложные распределённые системы. Разберём каждый этап подробнее.

Начало: формализация задачи

Кандидату даётся лишь название системы и базовые требования. Например: «Спроектируйте систему обмена сообщениями для миллиона пользователей». Хороший кандидат не бросается сразу рисовать диаграммы, а сначала:

  • Уточняет функциональные требования: какие функции должна поддерживать система
  • Уточняет нефункциональные требования: доступность, задержки, консистентность
  • Определяет ключевые архитектурные характеристики (architecture characteristics)

Ключевые архитектурные характеристики

В зависимости от задачи приоритеты различаются:

  • High Availability — система должна быть доступна 99.99% времени
  • Low Latency — ответ должен приходить за миллисекунды
  • Strong Consistency — данные должны быть консистентны во всех узлах
  • Eventual Consistency — допустима временная неконсистентность
  • Scalability — система должна масштабироваться горизонтально
  • Durability — данные не должны теряться

Уточнение масштаба

Кандидат задаёт вопросы о нагрузке:

  • Количество пользователей (DAU/MAU)
  • Количество запросов в секунду (RPS)
  • Объём хранимых данных
  • Соотношение чтений и записей
  • Географическое распределение пользователей

Эти цифры влияют на выбор архитектурных решений. Например, система с 1000 RPS и 1 млн RPS будут спроектированы совершенно по-разному.

Определение границ и API

Кандидат определяет:

  • Границы системы (что входит, что не входит в scope)
  • Основные сценарии использования (use cases)
  • Публичный API: эндпоинты, форматы запросов и ответов

Внутреннее устройство

Детальная проработка архитектуры:

  • Потоки данных: как данные движутся через систему
  • Компоненты системы: сервисы, базы данных, кэши, очереди
  • Happy path: как система работает в нормальных условиях
  • Edge cases: что происходит при сбоях, пиковых нагрузках, необычных сценариях

Выбор технологий

Обсуждение конкретных технологий и их обоснование:

  • Почему PostgreSQL, а не MongoDB?
  • Почему Kafka, а не RabbitMQ?
  • Как выбранные технологии справятся с нагрузкой?

Дополнительные вопросы

Вопросы со звёздочкой проверяют глубину знаний:

  • Как обеспечить zero-downtime deployment?
  • Что делать при разделении сети между дата-центрами?
  • Как мигрировать данные без простоя?

Пример: проектирование системы обмена сообщениями

Для системы с 1 млн пользователей:

  • WebSocket для real-time доставки
  • PostgreSQL для хранения сообщений
  • Redis для кэширования онлайн-статусов
  • Kafka для гарантированной доставки
  • CDN для медиафайлов
  • Шардирование по chat_id для масштабирования

Связь с troubleshooting

Как было отмечено ранее, troubleshooting включает элементы system design — кандидат должен предлагать архитектурные улучшения, что требует тех же навыков проектирования.

Вопрос 10. Почему из процесса найма был убран этап system design и как он связан с troubleshooting?​

Таймкод: 00:24:36

Ответ собеседника: Правильный. Troubleshooting и system design — это два противоположных подхода. В troubleshooting на старте есть боевая система с диаграммой архитектуры, и цель — потушить внезапно загоревшуюся систему. В system design на старте только требования заказчика, которые нужно формализовать, и цель — спроектировать систему, которая в принципе не способна возгораться. В troubleshooting проверяется подход к изучению симптомов, поиску временного лечения и полноценному фиксу. В system design проверяется подход к проектирования решения с учётом всех требований и жизнеспособность итоговой системы. Troubleshooting хорошо проходят люди с опытом в инфраструктуре и эксплуатации, а system design — те, кто проектировал новую функциональность в сложных системах. В идеальном мире инженер должен уметь и то, и другое — не просто тушить пожары, а способствовать надёжности систем. Однако по статистике кандидаты в среднем проходили system design только на уровень junior (максимум middle), то есть интервью не давало новой информации о кандидате. Поскольку интервью проводятся для того чтобы узнать что-то новое, а нового не было — этап убрали, сократив процесс найма.

Правильный ответ:

Это отличный вопрос, который раскрывает логику оптимизации процесса найма. Давайте разберём аргументацию более детально.

Два противоположных подхода

Troubleshooting и system design — это как бы два разных направления работы с системой:

Troubleshooting (реактивный подход):

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

System design (проактивный подход):

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

Разные профили кандидатов

Интересно, что эти два этапа выявляют разные компетенции:

  • Troubleshooting хорошо проходят инженеры с опытом эксплуатации, инфраструктуры, поддержки. Они привыкли работать с реальными системами, знают типичные проблемы и умеют быстро диагностировать.

  • System design хорошо проходят инженеры, которые проектировали новую функциональность, участвовали в создании систем с нуля. Они мыслят категориями архитектурных решений и trade-offs.

Идеальный инженер

В идеале инженер должен обладать обоими наборами навыков:

  • Уметь тушить пожары (troubleshooting)
  • Уметь проектировать системы, которые не загораются (system design)
  • Понимать, как архитектурные решения влияют на надёжность
  • Учиться на инцидентах и улучшать архитектуру

Почему убрали system design: статистическое обоснование

Ключевой аргумент — это данные. По статистике компании:

  • Кандидаты в среднем проходили system design только на уровень junior-middle
  • Результаты system design не давали новой информации о кандидате
  • То есть кандидат, который показывал хороший уровень на других этапах, не демонстрировал этот же уровень на system design

Это означает, что system design интервью не выполняло свою основную функцию — дифференциацию кандидатов по уровню. Если этап не добавляет информации, он становится избыточным.

Логика принятия решения

Процесс найма — это последовательность фильтров, каждый из которых должен добавлять информацию о кандидате:

  • Если этап не дифференцирует кандидатов — он бесполезен
  • Если этап дублирует информацию с других этапов — он избыточен
  • Каждый этап должен проверять что-то новое

System design не прошёл этот тест, поэтому был заменён на troubleshooting, который:

  • Проверяет уникальные компетенции (диагностика, работа с реальными системами)
  • Лучше дифференцирует кандидатов по уровню
  • Более релевантен реальной работе в компании

Что это значит для подготовки

Хотя отдельного этапа system design нет, его элементы всё ещё проверяются в troubleshooting:

  • Предложения по улучшению архитектуры — это по сути system design
  • Понимание того, как архитектурные решения влияют на надёжность — это навык проектирования
  • Умение видеть системные проблемы и предлагать системные решения — это архитектурное мышление

Поэтому подготовка к troubleshooting должна включать изучение архитектурных паттернов и принципов проектирования надёжных систем.

Вопрос 11. Как прокачаться в навыках troubleshooting и system design?​

Таймкод: 00:27:42

Ответ собеседника: Правильный. Для прокачки в troubleshooting и system design есть теоретическая и практическая составляющие. В теории можно изучать практики и подходы — например, книгу «Release It», принципы проектирования распределённых систем. Нужно знать какие компоненты и классы систем бывают, их сильные и слабые стороны, где они хорошо применяются. В практической части — если работа предполагает рост этих навыков (работа с реальными системами в команде для troubleshooting, роль архитектора для system design), это лучший способ прокачаться. Если же специальность не предполагает такого опыта, можно получить синтетический опыт: читать публичные постмортемы о крупных сложных системах, формулировать из них задачи с симптомами и решать их с друзьями. Для system design также можно изучать архитектуру крупных распределённых систем и участвовать в архитектурных като — это чемпионаты по решению архитектурных задач на проектирование в составе команды с последующей презентацией и обсуждением решений.

Правильный ответ:

Развитие навыков troubleshooting и system design — это процесс, который сочетает теоретическое изучение и практическое применение. Вот подробный план развития в обоих направлениях.

Теоретическая база

Книги для изучения:

  • «Release It!» by Michael Nygard — книга о проектировании и развёртывании production-ready систем. Описывает паттерны надёжности: circuit breaker, bulkhead, timeout, retry и другие
  • «Designing Data-Intensive Applications» by Martin Kleppmann — фундаментальная книга о распределённых системах, базах данных, потоковой обработке
  • «Site Reliability Engineering» by Google — бесплатная книга от Google о принципах SRE
  • «The Art of Scalability» by Martin Abbott — о масштабировании систем и организационных аспектах

Что нужно знать о компонентах систем:

  • Базы данных: реляционные vs NoSQL, индексы, репликация, шардирование, уровни изоляции транзакций
  • Кэши: Redis, Memcached, стратегии кэширования, инвалидация кэша
  • Очереди сообщений: Kafka, RabbitMQ, SQS, гарантии доставки, порядок сообщений
  • Балансировщики нагрузки: L4 vs L7, алгоритмы балансировки, health checks
  • CDN: принципы работы, кэширование на границе, invalidation
  • Мониторинг: метрики, логи, трейсы, SLO/SLI, алертинг

Практическая составляющая

Если работа позволяет получить реальный опыт:

Для troubleshooting:

  • Участвуйте в онкол-расписании команды
  • Анализируйте реальные инциденты, в которых участвовали
  • Проводите blameless postmortems и документируйте их
  • Участвуйте в game days — учениях по отработке инцидентов

Для system design:

  • Участвуйте в архитектурных решениях команды
  • Предлагайте улучшения существующей архитектуры
  • Проводите design review для чужих решений
  • Участвуйте в проектировании новых сервисов

Если работа не даёт нужного опыта:

Troubleshooting:

  • Читайте публичные постмортемы: GitHub Status, Cloudflare Blog, AWS Service Health Dashboard
  • Формулируйте из них задачи: возьмите описание инцидента, уберите решение, попробуйте найти его самостоятельно
  • Решайте задачи с друзьями: один играет роль джуна, другой — сеньора, меняйтесь
  • Используйте платформы: PagerDuty имеет бесплатные курсы по инцидент-менеджменту

System design:

  • Изучайте архитектуру реальных систем: блоги инженерных команд Netflix, Uber, Dropbox, Slack
  • Участвуйте в архитектурных като — чемпионатах по решению архитектурных задач
  • Практикуйтесь на платформах: Pramp, interviewing.io, Exponent
  • Решайте классические задачи: спроектируйте URL-shortener, Twitter, Uber, WhatsApp

Архитектурные като

Это формат командных соревнований по решению архитектурных задач:

  • Команда получает задачу с требованиями и ограничениями
  • За ограниченное время нужно спроектировать решение
  • Затем презентация и обсуждение с жюри
  • Разбираются альтернативные подходы и trade-offs

Преимущества этого формата:

  • Работа в команде — учит обсуждать и аргументировать решения
  • Ограниченное время — тренирует приоритизацию
  • Обсуждение с экспертами — обратная связь от опытных архитекторов
  • Видение разных подходов — расширяет кругозор

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

Неделя 1-2: Теоретическая база

  • Прочитать «Release It!» или хотя бы краткое содержание
  • Изучить основные паттерны надёжности
  • Повторить основы сетей, ОС, баз данных

Неделя 3-4: Анализ реальных инцидентов

  • Прочитать 10-15 постмортемов
  • Для каждого сформулировать: симптомы, гипотезы, корневая причина, улучшения
  • Попробовать решить задачу до чтения решения

Неделя 5-6: Практика troubleshooting

  • Найти партнёра для парной практики
  • Решить 5-10 задач в формате собеседования
  • Записать себя на видео и проанализировать

Неделя 7-8: Практика system design

  • Изучить архитектуру 3-5 известных систем
  • Решить 3-5 классических задач
  • Участвовать в архитектурном като или mock interview

Постоянная практика:

  • Регулярно читать инженерные блоги
  • Участвовать в профессиональных сообществах
  • Практиковаться в объяснении сложных концепций простым языком

Вопрос 12. Почему troubleshooting был оставлен вместо system design, если troubleshooting тоже может проверять архитектурные навыки — понимание scalability, performance, debuggability, traceability и т.д.?​

Таймкод: 00:32:13

Ответ собеседника: Правильный. Спикер соглашается, что troubleshooting действительно может быть частью system design и проверять архитектурные навыки. В troubleshooting после проработки happy path и формирования концептуальной схемы интервьюер начинает точечно бить по слабым местам — сеть упала, роутер перезагрузился, большой файл залили. Если кандидат не может объяснить, как его система будет переживать такие моменты, он получает низкую оценку. Однако каждый дополнительный этап ухудшает опыт кандидатов. поэтому было решено оставить troubleshooting, который уже включает элементы проверки архитектурного мышления, а отдельный этап system design убрали, поскольку кандидаты в среднем показывали на нём только уровень junior, и интервью не давало новой информации.

Правильный ответ:

Этот вопрос затрагивает важный аспект оптимизации процесса найма и объясняет, почему troubleshooting был выбран как более эффективный этап.

Troubleshooting как проверка архитектурных навыков

Действительно, troubleshooting проверяет многие архитектурные компетенции:

  • Scalability: кандидат должен понимать, как система ведёт себя под нагрузкой, где узкие места
  • Performance: умение находить и устранять проблемы с производительностью
  • Debuggability: понимание, как система должна быть спроектирована для удобной диагностики
  • Traceability: понимание распределённого трейсинга, корреляции запросов
  • Resilience: способность системы переживать сбои отдельных компонентов

Механизм проверки в troubleshooting

В процессе troubleshooting интервьюер целенаправленно проверяет архитектурное мышление кандидата:

  • Сначала кандидат формирует концептуальную схему системы (happy path)
  • Затем интервьюер начинает «ломать» систему: сеть упала, роутер перезагрузился, большой файл залили
  • Кандидат должен объяснить, как система реагирует на эти сбои
  • Если кандидат не может объяснить поведение системы в нештатных ситуациях — это сигнал о поверхностном понимании архитектуры

Почему troubleshooting эффективнее system design

Несколько причин, почему troubleshooting был оставлен:

  • Лучшая дифференциация кандидатов: По статистике, system design не разделял кандидатов по уровням — все показывали junior-middle. Troubleshooting лучше показывает разницу между уровнями.

  • Более реалистичный контекст: В troubleshooting кандидат работает с конкретной системой и конкретной проблемой, что ближе к реальной работе.

  • Проверка архитектурных навыков в контексте: Troubleshooting проверяет не только знание паттернов, но и умение применять их для решения конкретных проблем.

  • Меньше стресса от процесса: Каждый дополнительный этап увеличивает время и стресс для кандидата. Убирая менее информативный этап, компания улучшает опыт кандидатов.

Баланс между полнотой и эффективностью

Это классический инженерный компромисс:

  • Полнота: Чем больше этапов, тем больше информации о кандидате
  • Эффективность: Каждый этап должен добавлять новую информацию
  • Опыт кандидата: Длинный процесс утомляет и может отпугнуть хороших кандидатов
  • Стоимость процесса: Каждый этап — это время интервьюеров, которое тоже стоит денег

Оптимальное решение — минимальный набор этапов, каждый из которых даёт максимум новой информации. Troubleshooting оказался более эффективным по этому критерию.

Что это значит для подготовки

Понимая эту логику, можно лучше подготовиться:

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

Вопрос 13. Не кажется ли несправедливым просить кандидата найти root cause проблемы, если это ошибка прикладного софта или open source, на которую он не может повлиять — ведь никто не будет переписывать PostgreSQL или фреймворк?​

Таймкод: 00:35:34

Ответ собеседника: Правильный. Спикер отвечает, что задачи выбираются таким образом, чтобы root cause была достижима. Если ошибка прикладного уровня, обычно можно посмотреть, как она попала на продакшен — например, через логи деплоя. В некоторых задачах есть сниппеты кода. Обычно это не уровень глубокой проблемы в базе данных или фреймворке. Задачи не предлагают перепроектировать PostgreSQL или какой-то фреймворк — всё гораздо менее масштабно и реалистично.

Правильный ответ:

Это отличный вопрос, который показывает критическое мышление кандидата. Действительно, в реальной жизни многие проблемы связаны с багами в стороннем ПО, и инженер не может просто переписать PostgreSQL или фреймворк. Однако задачи на troubleshooting специально проектируются так, чтобы быть реалистичными и решаемыми.

Принципы выбора задач

Задачи для troubleshooting проходят тщательный отбор:

  • Достижимая root cause: Проблема должна иметь корневую причину, до которой кандидат может докопаться за отведённое время
  • Реалистичный масштаб: Это не баг в ядре Linux или ошибка в алгоритме сортировки PostgreSQL
  • Достаточная информация: В задаче заложены подсказки, которые ведут к решению

Типичные корневые причины в задачах

Обычно это проблемы на уровне приложения или конфигурации:

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

Как это реализовано в задачах

В некоторых задачах предоставляются:

  • Сниппеты кода с ошибкой
  • Логи деплоя, показывающие, когда проблема появилась
  • Конфигурационные файлы с неправильными настройками
  • Метрики, показывающие аномальное поведение

Примеры реалистичных root cause

Вместо «баг в PostgreSQL» кандидат может обнаружить:

  • Приложение не закрывает соединения с базой, пул исчерпан
  • Неправильно настроен индекс, запрос выполняется слишком долго
  • Миграция добавила колонку без default value, новые записи не создаются
  • Кэш не инвалидируется при обновлении данных, пользователи видят устаревшую информацию

Почему это справедливо

Задачи моделируют реальные ситуации, с которыми инженеры сталкиваются ежедневно:

  • Большинство проблем — это не баги в фундаментальных технологиях
  • Чаще всего проблема в том, как эти технологии используются
  • Инженер должен уметь диагностировать и решать проблемы на своём уровне

Что делать, если root cause — баг в стороннем ПО

В реальной жизни, если проблема действительно в стороннем компоненты, инженер должен:

  • Воспроизвести проблему и подтвердить, что она в стороннем коде
  • Найти workaround или обходной путь
  • Создать issue в баг-трекере проекта
  • Рассмотреть альтернативные решения, если баг критичен

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

Вопрос 14. Как воспринимаются кандидатами многоэтапные технические интервью в условиях рынка кандидата, где есть выбор и не хочется проходить длинные процессы?​

Таймкод: 00:36:56

Ответ собеседника: Правильный. Спикер подтверждает, что есть проблема — люди не очень любят проходить интервью. Однако этапы нарезаны на часовые слоты, что делает процесс более комфортным. Поток кандидатов достаточно хороший, хотя его можно улучшить. Частично этот доклад и направлен на популяризацию процесса — когда люди понимают, что это не просто блажь, а имеет причину, и что от этого можно что-то получить (опыт, фидбэк), они более согласны участвовать. Когда понятна цель, люди легче идут на процесс.

Правильный ответ:

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

Проблема длинных процессов

Кандидаты справедливо не любят длинные процессы по нескольким причинам:

  • Время: Каждый этап — это несколько часов подготовки и самого интервью
  • Стресс: Многоэтапный процесс создаёт постоянное напряжение
  • Неопределённость: Непонятно, сколько ещё этапов впереди
  • Упущенные возможности: Пока кандидат проходит один процесс, он может упустить другие предложения

Как Тинькофф решает эту проблему

Компания предпринимает несколько мер для улучшения опыта:

  • Часовые слоты: Этапы нарезаны на часовые интервалы, что делает процесс более предсказуемым и менее утомительным
  • Прозрачность: Кандидат заранее знает, сколько этапов и что на них будет
  • Ценность для кандидата: Процесс позиционируется не как экзамен, а как возможность получить опыт и обратную связь

Почему кандидаты соглашаются на длинный процесс

Несколько факторов делают процесс привлекательным:

  • Понимание цели: Когда кандидат понимает, зачем нужен каждый этап, он более мотивирован участвовать
  • Обратная связь: Тинькофф известен качественной обратной связью, даже для тех, кто не прошёл
  • Интересные задачи: Troubleshooting — это не скучные алгоритмические задачи, а реальные проблемы
  • Репутация компании: Тинькофф — один из лидеров рынка, и работа там считается престижной

Роль прозрачности

Доклад, на который ссылается спикер, — часть стратегии по улучшению восприятия процесса:

  • Когда люди понимают логику за процессом, они менее склонны воспринимать его как «блажь»
  • Понимание того, что troubleshooting проверяет реальные навыки, а не абстрактные знания, повышает мотивацию
  • Осознание того, что от процесса можно получить ценный опыт, меняет отношение к нему

Конкуренция за кандидатов

В рынке кандидата компании конкурируют не только зарплатами и условиями, но и процессом найма:

  • Компании с длинными и непонятными процессами теряют кандидатов
  • Компании с короткими, но нерелевантными процессами нанимают не тех людей
  • Оптимальный процесс — достаточно короткий, чтобы не отпугнуть, и достаточно глубокий, чтобы оценить кандидата

Рекомендации для кандидатов

Если вы выбираете между компаниями с разными процессами найма:

  • Оцените, насколько процесс прозрачен и понятен
  • Узнайте, будет ли обратная связь
  • Подумайте, чему вы можете научиться в процессе
  • Сравните не только длину, но и качество процесса

Рекомендации для компаний

Если вы проектируете процесс найма:

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

Вопрос 15. Как готовятся задания для troubleshooting — под стек кандидата или под стек команды, которая ищет человека, учитывая гетерогенность стека в компании?​

Таймкод: 00:38:06

Ответ собеседника: Правильный. Спикер отвечает, что при подготовке задания компоненты фиксируются на уровне классов — например, реляционная база данных, но не конкретная СУБД. Если кандидат привык работать с определённым инструментом и предлагает его, интервьюер может уточнить, куда конкретно смотреть, и объяснить джуну, что делать. Кандидату верят — если он способен внятно объяснить гипотезы и инструменты, это приемлемо. Также интервьюер записывает timeline действий кандидата, который прикладывается к результатам собеседования. Если есть сомнения в адекватности предложенного инструмента, можно обратиться к внутренним экспертам для проверки.

Правильный ответ:

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

Принцип абстракции при подготовке заданий

Задания для troubleshooting готовятся на уровне классов компонентов, а не конкретных технологий:

  • Реляционная база данных вместо PostgreSQL/MySQL/Oracle
  • Кэш вместо Redis/Memcached
  • Очередь сообщений вместо Kafka/RabbitMQ
  • Балансировщик нагрузки вместо Nginx/HAProxy

Этот подход имеет несколько преимуществ:

  • Универсальность: Задание подходит для кандидатов с разным опытом
  • Фокус на навыках: Проверяется понимание принципов, а не знание конкретных инструментов
  • Гибкость: Кандидат может предлагать решения на основе своего опыта

Работа с разными стеками кандидатов

Если кандидат предлагает инструмент, с которым он знаком:

  • Интервьюер уточняет конкретные команды и метрики
  • Объясняет «джуну», что делать
  • Кандидату верят, если он может внятно объяснить свои действия

Например, если кандидат говорит «нужно посмотреть pg_stat_activity», а в задаче используется MySQL, интервьюер может сказать «в MySQL это будет SHOW PROCESSLIST» и продолжить.

Документирование процесса

Интервьюер записывает timeline действий кандидата:

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

Этот timeline прикладывается к результатам собеседования и позволяет:

  • Восстановить ход рассуждений кандидата
  • Проверить адекватность предложенных инструментов
  • Получить обратную связь от экспертов, если есть сомнения

Обращение к внутренним экспертам

Если интервьюер сомневается в адекватности предложенного кандидатом инструмента или подхода:

  • Можно обратиться к внутренним экспертам по конкретной технологии
  • Эксперт подтвердит или опровергнет предложенное решение
  • Это позволяет корректно оценить кандидата, даже если он использует незнакомый инструмент

Гетерогенность стека в компании

Тинькофф — большая компания с разнообразным стеком:

  • Разные команды используют разные технологии
  • Нет единого стандарта на все проекты
  • Важно оценивать принципиальное понимание, а не знание конкретного инструмента

Поэтому задания на уровне классов компонентов — это осознанный выбор, который:

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

Что это значит для подготовки

Готовясь к troubleshooting, фокусируйтесь на:

  • Понимании принципов работы классов компонентов
  • Умении объяснить, какие метрики и логи нужно смотреть и почему
  • Способности адаптировать свои знания к незнакомым инструментам
  • Навыке формулировать гипотезы и планировать эксперименты

Конкретные команды и синтаксис менее важны, чем понимание того, что происходит внутри системы.

Вопрос 16. Как проводится прокачка сотрудников внутри компании по troubleshooting — используются ли учения с симуляцией реальных инцидентов?​

Таймкод: 00:40:16

Ответ собеседника: Неполный. Спикер честно признаётся, что не может полностью ответить на этот вопрос, так как он не очень знаком с внутренними учениями. Он технический директор одного из управлений и находится немного в стороне от этого процесса. Он знает, что для проведения troubleshooting интервью есть перечень источников, нужно пройти обучение, провести несколько пилотных интервью, получить заключение. Но как именно устроены внутренние учения по troubleshooting, он не подскажет.

Правильный ответ:

Спикер честно признаётся, что не владеет полной информацией о внутренних процессах прокачки сотрудников. Однако он делится тем, что знает о подготовке интервьюеров для troubleshooting.

Подготовка интервьюеров для troubleshooting

Для тех, кто проводит troubleshooting интервью, существует структурированный процесс обучения:

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

Что известно о внутренних учениях

Хотя спикер не может детально описать внутренние процессы, можно предположить, что в компании существуют практики, характерные для крупных технологических компаний:

Game Days (учения по инцидентам)

Это симуляции реальных инцидентов, где команды отрабатывают свои действия:

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

Chaos Engineering

Практика намеренного внесения сбоев в систему для проверки её устойчивости:

  • Chaos Monkey (Netflix) — случайное отключение инстансов
  • Latency Monkey — искусственное внесение задержек
  • Chaos Mesh — инструмент для Kubernetes

Blameless Postmortems

Анализ реальных инцидентов без поиска виноватых:

  • Что произошло?
  • Как было обнаружено?
  • Как было устранено?
  • Что можно улучшить?

On-call ротация

Система дежурств, где инженеры по очереди отвечают за работоспособность сервисов:

  • Инженер получает алерты и должен на них реагировать
  • Это реальный опыт troubleshooting в production
  • Ротация позволяет распределить нагрузку и опыт между командой

Внутренние митапы и обмен знаниями

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

Рекомендации для тех, кто хочет прокачаться

Если вы хотите развить навыки troubleshooting внутри своей компании:

  • Предложите провести game days в своей команде
  • Участвуйте в on-call ротации
  • Анализируйте реальные инциденты и документируйте их
  • Проводите blameless postmortems
  • Изучайте постмортемы других компаний
  • Участвуйте в архитектурных като и других форматах обмена опытом

Вопрос 17. Как компания мотивирует и продаёт вакансии, учитывая что в байтинговых компаниях бытует мнение об обязательной вовлечённости 24/7 и отсутствии свободного времени, а в легенде troubleshooting кандидат как раз в отпуске получает звонок о проблеме?​

Таймкод: 00:41:40

Ответ собеседника: Неполный. Спикер не успел ответить на этот вопрос, так как время доклада закончилось. Вопрос остался без ответом.

Правильный ответ:

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

Контекст: байтинговые компании и их репутация

Банковские и финтех-компании действительно имеют репутацию мест, где:

  • Высокая нагрузка и постоянная вовлечённость
  • Длинные рабочие часы
  • Сложно поддерживать work-life balance
  • Онкол-дежурства и необходимость реагировать на проблемы в любое время

Эта репутация частично основана на реальности, но часто преувеличена.

Ирония с легендой troubleshooting

Действительно, в легенде troubleshooting кандидат — лид-инженер, который уходит в отпуск, но получает звонок от джуна с проблемой. Это может восприниматься как отражение реальности, где нельзя полностью отключиться от работы.

Как компании продают вакансии несмотря на это

Крупные компании используют несколько стратегий:

Интересные задачи и сложные вызовы

  • Масштаб систем и нагрузки, с которыми мало где столкнёшься
  • Возможность работать с современными технологиями
  • Реальные бизнес-задачи, влияющие на миллионы пользователей

Компенсация и бонусы

  • Конкурентоспособные зарплаты
  • Бонусы за результат
  • ДМС, фитнес, другие привилегии

Профессиональный рост

  • Возможность учиться у сильных коллег
  • Внутренние митапы, конференции
  • Карьерные треки и развитие

Культура и процессы

  • Попытки внедрить здоровые рабочие практики
  • Гибкий график, удалённая работа
  • Ограничение переработок

Реальность про онкол и дежурства

В современных компаниях ситуация с дежурствами часто лучше, чем кажется:

  • Ротация: Дежурства распределяются между командой, не один человек дежурит постоянно
  • Компенсация: За дежурства часто предусмотрена дополнительная оплата или отгулы
  • Автоматизация: Хороший мониторинг и алертинг уменьшают количество ночных звонков
  • Культура: Тренд к тому, чтобы инженеры могли отдыхать, а не были на связи 24/7

Как оценить компанию при выборе

Если вы рассматриваете предложение и хотите понять реальную ситуацию:

  • Спросите на собеседовании: Как устроены дежурства? Как часто? Какая компенсация?
  • Почитайте отзывы: Glassdoor, Habr Career, отзывы бывших сотрудников
  • Поговорите с сотрудниками: Через LinkedIn или знакомых
  • Оцените процессы: Наличие SRE-команды, автоматизация, культура постмортемов

Баланс между вызовами и качеством жизни

Важно понимать, что сложные задачи и высокая нагрузка — это две разные вещи:

  • Сложные задачи — это когда интересно, есть вызов, растёшь профессионально
  • Высокая нагрузка — когда много рутины, дедлайнов, стресса

Хорошие компании стараются давать первое без второго, но это не всегда получается.

Что спросить на собеседовании

Если вас волнует баланс, задайте вопросы:

  • Как устроены дежурства в команде?
  • Какова средняя продолжительность рабочего дня?
  • Есть ли гибкий график или удалённая работа?
  • Как компания относится к переработкам?

Ответы на эти вопросы помогут принять осознанное решение.

Вопрос 18. Почему в легенде troubleshooting кандидат находится в отпуске и ему звонят — не демотивирует ли это, и как компания продаёт вакансий в условиях рынка кандидата?​

Таймкод: 00:42:12

Ответ собеседния: Правильный. Спикер объясняет, что легенда с отпуском специально создана для ограничения канала коммуникации — кандидат не взял с собой ноутбук, у него только мобильный телефон. Если бы он взял ноутбук, то скорее всего сам всё починил и сказал джуну «спабо». Ограниченный канал коммуникации создаёт формат, похожий на Dungeons & Dragons — game master рассказывает, что происходит, а кандидат через ограниченный канал даёт указания. Идеально было бы дать кандидату реальный стенд для работа, но это нетривиально в реализации. Что касается продажи вакансий — коллеги хорошо работают над рассказыванием о роли, подходах, стеке. В компании инженер не только тушит пожары, но и может влиять на надёжность систем, работая в тесном взаимодействии с командой разработки. Это ближе к каноническому пониманию роли, что привлекает кандидатов.

Правильный ответ:

Этот вопрос объединяет два важных аспекта: методологию проведения troubleshooting и позиционирование компании на рынке труда. Разберём оба.

Зачем нужна легенда с отпуском

Легенда с отпуском — это не случайный выбор, а продуманное методологическое решение.

Ограничение канала коммуникации

Кандидат в отпуске и у него только мобильный телефон — это способ ограничить его возможности:

  • Если бы кандидат имел доступ к ноутбуку, он мог бы сам залезть в логи, метрики, базы данных
  • Вместо этого он должен координировать джуна, который выполняет все действия
  • Это проверяет не только технические знания, но и коммуникативные навыки

Формат, похожий на Dungeons & Dragons

Спикер проводит интересную аналогию:

  • Game master (интервьюер) описывает ситуацию, отвечает на вопросы
  • Игрок (кандидат) принимает решения на основе ограниченной информации
  • Кандидат должен задавать правильные вопросы, чтобы получить нужную информацию

Это создаёт уникальный формат, который проверяет:

  • Способность работать с неполной информацией
  • Умение формулировать вопросы
  • Навыки коммуникации и объяснения
  • Способность координировать другого человека

Почему нельзя дать реальный стенд

Идеальный вариант — дать кандидату реальную систему для диагностики:

  • Это потребовало бы подготовки изолированного окружения
  • Нужно было бы симулировать реальные проблемы
  • Стоимость и сложность такой подготовки очень высока
  • Формат с джуном-интервьюером проще масштабировать

Как компания продаёт вакансии

В условиях рынка кандидата компания делает акцент на нескольких вещах:

Роль инженера в компании

Важное отличие от «тушения пожаров»:

  • Инженер не только реагирует на инциденты, но и влияет на надёжность систем
  • Работа в тесном взаимодействии с командой разработки
  • Возможность предлагать и внедрять архитектурные улучшения
  • Это ближе к каноническому пониманию роли Site Reliability Engineer

Позиционирование роли

Компания показывает, что роль предполагает:

  • Проактивную работу над надёжностью, а не только реактивное тушение
  • Влияние на архитектурные решения
  • Работу с современным стеком технологий
  • Профессиональный рост и развитие

Что рассказывают кандидатам

Коллеги из HR и технические команды:

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

Баланс между вызовами и возможностями

Компания позиционирует себя как место, где:

  • Есть сложные технические вызовы (масштаб, нагрузка, распределённые системы)
  • Есть возможность влиять на результат, а не просто выполнять задачи
  • Есть профессиональное развитие и обучение
  • Есть современные практики и инструменты

Что это значит для кандидатов

Понимая эту логику, можно лучше оценить предложение:

  • Уточните, какова роль инженера в реальности: только реактивная работа или есть проактивная?
  • Спросите о соотношении troubleshooting и разработки
  • Узнайте о возможности влиять на архитектуру
  • Оцените, насколько описание роли соответствует вашим ожиданиям

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

Вопрос 19. Какие красные флаги и положительные сигналы можно выделить на troubleshooting интервью, и проверяете ли вы процессуальную часть решения инцидента?​

Таймкод: 00:45:22

Ответ собеседника: Правильный. Среди красных флагов спикер выделяет токсичное поведение во время инцидента — когда кандидат обвиняет других («кто-то сломал», «я говорил что так работать не будет»), напоминает команде что пользователи страдают уже полчаса, но при этом не предлагает починить. Такой налет токсичности — явный минус. Положительный сигнал — когда кандидат рассказывает не только техническую часть, но и как он видел бы улучшение процесса, как предотвратить повторение инцидента. Процессуальная часть засчитывается в плюс, если кандидат имеет связную картину и может поделиться видением улучшений процесса.

Правильный ответ:

Этот вопрос о поведенческих аспектах troubleshooting — то, что отличает хорошего инженера от просто технически грамотного. Разберём красные флаги и положительные сигналы подробнее.

Красные флаги (Red Flags)

Токсичное поведение во время инцидента

Это один из самых серьёзных негативных сигналов:

  • Обвинение других: «Кто-то сломал», «Это не моя зона ответственности»
  • Демонстрация осведомлённости без действия: «Я говорил, что так работать не будет»
  • Напоминание о проблемах без решения: «Пользователи страдают уже полчаса» (но при этом не предлагает починить)

Такое поведение показывает, что кандидат:

  • Не понимает приоритеты во время инцидента
  • Склонен к обвинениям, а не к решению проблем
  • Не подходит для работы в команде в стрессовых ситуациях

Другие красные флаги:

  • Паника и хаотичные действия: Кандидат начинает проверять всё подряд без системы
  • Игнорирование workaround: Продолжает искать root cause, пока пользователи страдают
  • Отказ от коммуникации: Не объясняет свои действия, не задаёт вопросы
  • Поверхностный анализ: Останавливается на первом найденном симптоме, не копает глубже
  • Непонимание приоритетов: Фокусируется на некритичных деталях, пока система не работает

Положительные сигналы (Green Flags)

Процессуальное мышление

Кандидат думает не только о техническом решении, но и о процессах:

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

Другие положительные сигналы:

  • Системный подход: Последовательная диагностика, а не хаотичный перебор
  • Баланс между workaround и root cause: Сначала устраняет симптомы, потом копает глубже
  • Коммуникативные навыки: Умеет объяснить сложные вещи простым языком
  • Спокойствие под давлением: Не паникует, действует методично
  • Учёт побочных эффектов: Думает о том, как решение повлияет на другие части системы

Процессуальная часть решения инцидента

Да, процессуальная часть проверяется и засчитывается в плюс. Что именно оценивается:

Коммуникация во время инцидента

  • Как кандидат общается с «джуном»
  • Умеет ли объяснить сложные концепции
  • Задаёт ли уточняющие вопросы
  • Даёт ли понятные инструкции

Управление инцидентом

  • Понимает ли кандидат приоритеты
  • Умеет ли разделить workaround и полноценное исправление
  • Думает ли о коммуникации с заинтересованными сторонами

Пост-инцидентный анализ

  • Предлагает ли улучшения процессов
  • Думает ли о предотвращении повторения
  • Понимает ли ценность blameless postmortems

Примеры хорошего и плохого поведения

Плохо:

Кандидат: «Кто деплоил эту версию? Я же говорил, что это сломается! 
Пользователи уже полчаса страдают, а вы тут сидите...»

Хорошо:

Кандидат: «Давай сначала вернём систему в рабочее состояние. 
Попробуй откатить последний деплой. Параллельно посмотри логи, 
чтобы понять, что именно изменилось. После того как система заработает, 
разберёмся, почему это произошло и как предотвратить в будущем.»

Что это значит для подготовки

Готовясь к troubleshooting, помните:

  • Технические навыки — это только часть оценки
  • Поведение под давлением тоже оценивается
  • Демонстрируйте системный подход и спокойствие
  • Предлагайте улучшения процессов, а не только технические решения
  • Объясняйте свои действия и задавайте вопросы
  • Фокусируйтесь на решении, а не на обвинениях

Вопрос 20. Какие существуют площадки для практической тренировки навыков troubleshooting, помимо самостоятельных упражнений с другом?​

Таймкод: 00:47:21

Ответ собеседника: Неполный. Спикер честно признаётся, что не очень знаком с этой темой и не может подсказать конкретные площадки для тренировки troubleshooting. Он сам ориентировался на чтение постмортемов и анализ архитектур крупных систем. Спикер упоминает, что кандидат предложил в качестве примера CyberDefend и аналогичные платформы, где нужно чинить развалившиеся кластеры, но спикер не может подтвердить или порекомендовать конкретные ресурсы.

Правильный ответ:

Спикер честно признаётся, что не владеет полной информацией о площадках для тренировки. Однако можно дополнить его ответ известными ресурсами.

Платформы для тренировки troubleshooting

CyberDefenders

Как упомянул кандидат, это платформа для практических упражнений:

  • Нужно чинить развалившиеся кластеры
  • Анализировать логи и метрики
  • Диагностировать проблемы в реальных сценариях

Другие полезные платформы:

Hack The Box

  • Платформа для практики в области кибербезопасности
  • Многие задачи требуют troubleshooting навыков
  • Есть разделы по сетям, веб-приложениям, инфраструктуре

Kubernetes Goat

  • Намеренно уязвимый кластер Kubernetes
  • Для практики диагностики проблем в контейнерных средах

Gremlin

  • Платформа для chaos engineering
  • Позволяет практиковаться в обработке сбоев
  • Есть бесплатные учебные материалы

PagerDuty

  • Имеет бесплатные курсы по инцидент-менеджменту
  • Обучает процессам реагирования на инциденты
  • Полезно для понимания процессуальной части

Дополнительные ресурсы

Постмортемы для анализа

  • GitHub Status — публичные отчёты об инцидентах GitHub
  • Cloudflare Blog — детальные разборы сбоев
  • AWS Service Health Dashboard — история инцидентов AWS
  • Last Week in AWS — еженедельная рассылка с анализом инцидентов

Книги с практическими примерами

  • «The Practice of Cloud System Administration» — том 2 посвящён troubleshooting
  • «Debugging» by David Agans — общие принципы отладки
  • «Systems Performance» by Brendan Gregg — производительность систем

Практика на работе

Лучший способ прокачать навыки — реальный опыт:

  • Участвуйте в on-call ротации
  • Анализируйте реальные инциденты в команде
  • Проводите game days — учения по симуляции сбоев
  • Участвуйте в blameless postmortems

Самостоятельная практика

Если нет доступа к реальным системам:

  • Разверните домашний кластер Kubernetes и ломайте его намеренно
  • Используйте Terraform для создания инфраструктуры и её разрушения
  • Анализируйте постмортемы и пытайтесь решить задачу до чтения ответа
  • Практикуйтесь с друзьями в формате «один ломает, другой чинит»

Рекомендуемый план подготовки

  1. Теория: Прочитать 2-3 книги по troubleshooting и распределённым системам
  2. Анализ: Изучить 10-15 постмортемов от крупных компаний
  3. Практика: Решить 5-10 задач на CyberDefenders или аналогичных платформах
  4. Симуляция: Провести 3-5 учений с друзьями в формате troubleshooting интервью
  5. Реальный опыт: По возможности участвовать в on-call и анализе реальных инцидентов

Вопрос 21. На каком этапе технического интервью задаются вопросы о моделях OSI, портах, отличии процесса от потока и подобные базовые вопросы?​

Таймкод: 00:48:40

Ответ собеседника: Правильный. Спикер отвечает, что такие вопросы задаются на первом техническом этапе — системном инжиниринге (system engineering). Это этап, где инженер задаёт вопросы из большого списка, покрывающего темы от сетей и операционных систем до распределённых систем. Спикер не проводит этот этап сам и не помнит полный перечень вопросов, но подтверждает, что это именно первый технический этап собеседования.

Правильный ответ:

Базовые технические вопросы задаются на этапе системного инжиниринга (System Engineering Interview). Это первый технический этап собеседования, который проверяет фундаментальные знания инженера.

Что такое системный инжиниринг интервью

Этот этап оценивает понимание фундаментальных аспектов работы систем:

  • Сети: модель OSI, TCP/IP, HTTP/HTTPS, DNS, TLS
  • Операционные системы: процессы, потоки, память, файловые системы
  • Распределённые системы: консистентность, доступность, теорема CAP
  • Базы данных: индексы, транзакции, уровни изоляции
  • Общие концепции: кэширование, балансировка нагрузки, масштабирование

Типичные вопросы на этом этапе

Сети:

  • Расскажите о модели OSI. Какие уровни вы знаете?
  • Чем отличается TCP от UDP?
  • Что происходит при вводе URL в браузере?
  • Как работает TLS handshake?

Операционные системы:

  • Чем отличается процесс от потока?
  • Что такое виртуальная память?
  • Как работает сборщик мусора?
  • Что такое контекстное переключение?

Распределённые системы:

  • Объясните теорему CAP
  • Что такое консистентность и какие её виды бывают?
  • Как работает распределённый консенсус?

Почему это важно

Эти базовые знания необходимы для troubleshooting:

  • Понимание сетей помогает диагностировать проблемы с подключениями
  • Знание ОС помогает находить проблемы с производительностью
  • Понимание распределённых систем помогает видеть системные проблемы

Как подготовиться

Для подготовки к этому этапу:

  • Повторите основы сетей (модель OSI, TCP/IP, HTTP)
  • Изучите основы ОС (процессы, потоки, память)
  • Почитайте о распределённых системах (теорема CAP, консистентность)
  • Практикуйтесь в объяснении сложных концепций простым языком