ПостРеальное собеседование на стажировку Go‑разработчика в Т‑Банк

Реальное собеседование на стажировку Go‑разработчика в Т‑Банк Наш студент сделал расшифровку записи собеса, делимся с вами! Кстати, решение экзамена уже выложено на нашем курсе бэкенд про, ии агенты про и алгоритмы про. ➡️ Записаться. 1. «Расскажи, что такое Firewall?» Собеседование было в команду, которая разрабатывает host‑based firewall на eBPF с Control Plane в Kubernetes. Интервьюер рассказал про свою команду и задал этот уточняющий вопрос + спросил понял ли я, чем занимается команда. • Firewall – система, управляющая сетевыми доступами: пропускает или блокирует трафик на основе правил (IP, порты, протоколы). • Команда пишет распределённый firewall, который работает на десятках тысяч хостов в банке, управляется централизованно через Kubernetes. Стек: Go, eBPF, gRPC, Linux. 2. «Какой у тебя опыт с Linux и сетями?» Я сам особо не занимался бэкендом и го, знаю основы: модель OSI, TCP vs UDP (TCP надёжный с подтверждением, UDP быстрый без гарантий), маски подсетей, маршрутизацию. Линуксом владею на уровне пользователя, но готов быстро адаптироваться. 3. «Чем процесс отличается от потока? Зачем вообще нужны потоки?» • Процесс – изолированный экземпляр программы со своей памятью, файловыми дескрипторами. • Поток – легковесная единица внутри процесса, потоки разделяют память процесса. Потоки нужны для параллельного выполнения задач внутри одного процесса и эффективного обмена данными. 4. «Чем горутина отличается от треда в Go?» • Горутина – легковесный поток, управляемый рантаймом Go, а не ОС. Она занимает меньше памяти (несколько КБ), переключение между горутинами дешевле. Планировщик Go мультиплексирует горутины на системные треды (модель M:N). • В отличие от тредов, горутины не привязаны жёстко к одному системному треду. 5. «Что такое gRPC? На каких протоколах работает? В чём отличие HTTP/2 от HTTP/1.1?» • gRPC – фреймворк для удалённого вызова процедур от Google. Использует HTTP/2 в качестве транспорта и Protobuf для сериализации. • HTTP/2 поддерживает мультиплексирование запросов, сжатие заголовков, работу в дуплексном режиме. • По сравнению с HTTP/1.1, это даёт меньшую задержку и более эффективное использование соединений. 6. Задача на ревью кода Дан HTTP‑хендлер, который проксирует запросы во внешнее API и кеширует ответы, чтобы реже ходить в платное API. Найденные проблемы: • Кеш не заполнялся – после успешного запроса результат не сохранялся. ➜ Добавлена запись в map. • Проверка наличия ключа – использовалась if val != "", что ломается при пустом ответе. ➜ Использован второй параметр ok при чтении из map. • Метод POST – хендлер принимает только POST, хотя логичнее GET (но это контракт, оставлено). • Race condition – конкурентные запросы к map без синхронизации. ➜ Добавлен sync.Mutex с Lock/Unlock при каждом обращении. • Утечка памяти – кеш бесконечно растёт, нет ограничений по размеру или TTL. ➜ Нужно добавить политику вытеснения (LRU) или время жизни записей. 7. «Как бы ты добавил тесты?» Я предложил тест, который проверяет, что повторный запрос не идёт в API (счётчик вызовов), и что при параллельных запросах нет гонок – с помощью флага -race. 8. «После деплоя сервис падает через несколько дней без паники. Что делать?» Причина – кеш разрастается до заполнения памяти. Решения: • добавить ограничение на размер кеша, • внедрить TTL для записей, • настроить мониторинг памяти и алерты. Еще больше вопрос в нашем открытом банке собесов и тестовых заданий: смотрите на сайте. Подписаться: @codeof_art