Как устроены System Design и troubleshooting в Т-банке

Как устроены System Design и troubleshooting в Т-банке Дают их бэкендерам и фуллстекам на любом грейде. Джуну достаточно простого решения, мидлу еще нужно закрыть функциональные требования, сеньору ещё и нефункциональные (масштабирование, точки отказа, инфра). Дают их обычно после секции по языку/стеку. Подробный гайд по внутренним протоколам Т-банка в прикрепленном файле. Спасибо нашим выпускникам, которые делятся с нами инсайдерской информаций! Систем дизайн. Тебе дают задачу и 60 минут. Интервьюер играет продакта — у него можно уточнять всё. Главный критерий простой: есть решение или нет. Не смог сам собрать даже требования, считай завалил секцию. На практике это выглядит так: тебя просят спроектировать, допустим, сервис доставки. И первое, что ты должен сделать спросить: сколько пользователей, какой RPS, сколько дата-центров, какой SLA, есть ли легаси. Потом выбрать стек и обосновать каждый выбор требованиями. Потом компоненты и API. Потом верхнеуровневая схема: где кеш, где балансировка, где точки отказа. Потом производительность и безопасность. На каждом шаге могут подловить. Интервьюер может намеренно подсказать кривое решение и смотреть, согласишься или нет. Troubleshooting. Тебе описывают архитектуру и говорят: «техподдержка жалуется, сайт не работает» или «алерт: 500-х стало в 10 раз больше». Дальше ты задаёшь вопросы, а интервьюер отвечает, что ты при этом увидишь. Подробнее в прикрепленном файле. Там мы разобрали 6 реальных кейсов troubleshooting, чеклисты ответов и шпаргалку концепций. Этого хватит, чтобы понять структуру интервью. Но одной теории мало, нужна и качественная практика, которую мы даем на наших курсах Бэкенд СТАРТ и Бэкенд ПРО с помощью семинаров, домашнего задания, пет проектов, доступа к закрытой базе собесов, пробных собеседований и наставников из индустрии. ➡️ Записаться Подписаться: @postypashki_old