Наш студент сделал расшифровку записи собеса, делимся с вами! Кстати, решение экзамена уже выложено на нашем курсе бэкенд про, ии агенты про и алгоритмы про.
➡️ Записаться.
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