Загрузка…
Загрузка…
backend / middle / tech_deep
Формат
online
Стадия
tech_deep
Когда
within_quarter
Длительность
80 мин
01
Код
Напишите in-memory кэш, который хранит профиль по ключу UID и возвращает его: нужны два метода — положить в кэш и отдать из кэша. Кэш должен быть конкурентнобезопасным и иметь TTL (время жизни элементов).
Лайвкодинг-задача (Go). Кэш хранит профиль с вложенными заказами; разные потребители могут брать профиль/заказы и класть обратно.
02
Теория
Как реализовать TTL/выселение устаревших элементов кэша: проверять на записи, на чтении или фоновым воркером? Надо ли при чтении проходить по всем элементам мапы?
Врезка по ходу задачи. Пришли к идее проверять только запрошенный ключ + фоновый воркер для подчистки.
03
Теория
Будет ли безопасным конкурентный доступ к мапе в вашей реализации кэша? Как сделать его потокобезопасным?
Пришли к использованию мьютекса (RWMutex) и выделению критических секций.
Заметки
Транскрипт — запись одного технического собеседования (бэкенд, Go). Видео опубликовано сообществом Criminal IT (спонсор, не работодатель). Конкретное название компании-работодателя в тексте не названо; интервьюер упоминает внутренний юнит/команду «Юнити» и оговаривает, что наём не обязательно в его команду. Продукт: сервис с iOS/Android клиентами, интеграцией ChatGPT с фолбэком на Claude, использует gRPC/protobuf, PostgreSQL (десятки млн записей), Redis, Kafka, S3; ~несколько микросервисов (авторизация, картинки/S3, пуш-уведомления); деплой в Docker без Kubernetes, обсёрвабилити на Prometheus/Grafana + ElasticSearch. Структура собеседования: лайвкодинг (in-memory кэш на Go) + обширная теория по БД, Kafka, микросервисам, gRPC, Kubernetes, observability, тестам, затем рассказ интервьюера о процессе вывода фичи в релиз.
Подготовка
Готовиться к лайвкодингу на Go с конкурентностью (мьютексы, TTL-кэш) и к глубокой теории: индексы и уровни изоляции PostgreSQL, оптимистичные/пессимистичные блокировки, SELECT FOR UPDATE / SKIP LOCKED для конкурентной обработки записей несколькими подами; Kafka (партиции, consumer group, DLQ, consumer lag, гарантии доставки); микросервисные паттерны (saga, API gateway/strangler); обратная совместимость gRPC/protobuf (нумерация полей, добавление/переименование/удаление полей); базовый Kubernetes; observability и тесты.
Стиль интервьюера
Доброжелательный и поддерживающий: даёт подсказки, наводит на правильный ответ через уточняющие вопросы, не «тыкает носом» при незнании, сам объясняет недостающие темы (оптимистичные блокировки, SELECT FOR UPDATE, DLQ, гарантии доставки Kafka). Активно челленджит follow-up-ами («а если данных больше?», «почему именно так?»), просит кандидата самому отрефлексировать слабые места реализации. В конце честно оговаривает организацию найма и подробно рассказывает о внутреннем процессе разработки.
04
Код
Напишите небольшие тестовые сценарии для кэша (положить в кэш, забрать из кэша, проверить срабатывание TTL).
Без отдельного тест-фреймворка, простые сценарные проверки.
05
Теория
Если бы вы как тестировщик стали проверять вашу реализацию кэша — какие проблемы/слабые места нашли бы? Почему в GetProfile вы решили возвращать указатель, и какие риски это несёт?
Подводка к проблеме мутации данных в кэше через возвращённый указатель.
06
Теория
Как защититься от нежелательных изменений данных в кэше через вложенные заказы профиля (мутабельные поля)? Стоит ли делать глубокую копию перед возвратом?
Обсудили глубокую копию и метод копирования на уровне доменной модели профиля.
07
Теория
Расскажите про индексы в реляционных базах: для чего они нужны, какая от них польза, какие бывают (простые, составные, B-tree, hash) и с какими кейсами вы сталкивались на практике.
08
Теория
Какие отрицательные эффекты есть у индексов?
Место на диске, замедление записи.
09
Теория
Какие бывают уровни изоляции транзакций и какие аномалии (артефакты) у них есть?
Read uncommitted/committed, repeatable read, serializable; lost update, dirty read, non-repeatable read; затронули MVCC.
10
Теория
Что вы знаете про оптимистичные блокировки (в отличие от пессимистичных)? Как сделать так, чтобы не было двух параллельных апдейтов одной строки без блокировок уровня транзакции?
Кандидат не знал; интервьюер объяснил подход через версионирование строки.
11
Кейс
Есть сервис в нескольких подах в Kubernetes, каждый берёт из базы записи и обновляет их. Как сделать, чтобы разные поды брали разные записи и не пытались обновить одну и ту же (убрать гонку)?
Кандидат предлагал офсеты/шардирование; интервьюер подвёл к SELECT FOR UPDATE (SKIP LOCKED).
12
Теория
Расскажите про партиции в Kafka: что это, для чего нужны, почему нельзя просто писать всё в один топик?
Подвели к тому, что в рамках одной consumer group из одной партиции читает один консюмер — партиции нужны для масштабирования.
13
Теория
Что бы вы делали с сообщениями в Kafka, которые консюмер не может обработать (не распарсил, бизнесово не обработал)?
Кандидат предложил лог; интервьюер рассказал про Dead Letter Queue.
14
Теория
Что такое consumer lag в Kafka?
Разница между офсетом продюсера и вычитанным консюмером.
15
Теория
Какие бывают гарантии доставки в Kafka?
Кандидат не знал; интервьюер: at-least-once, at-most-once, exactly-once.
16
Теория
Расскажите, как у вас обстоят дела с микросервисами: как организовано общение между сервисами и как устроена работа с базой?
Общение по gRPC/protobuf, контракты; центральная база.
17
Кейс
Если бы у вас появился второй сервис, который ходит в базу — была бы та же база или новая? От чего это зависит?
18
Теория
Какие паттерны микросервисной архитектуры можете вспомнить и назвать?
Кандидат назвал сагу (оркестрация/хореография) и gateway/strangler (роутер).
19
Теория
Используете ли вы у себя сагу или похожие паттерны (учитывая, что у вас разные хранилища — S3, Redis, база)?
20
Теория
Что можно безопасно поменять в gRPC-контракте (proto-файле) в response, не сломав клиента без обновления контракта? Можно ли дописывать новые поля?
Подводка про числовую нумерацию полей и кодирование.
21
Теория
Что будет, если переименовать поле в proto (например address -> full_address), оставив тот же тип и номер?
Клиенты продолжат работать — имена не важны, важен номер поля.
22
Теория
Что произойдёт, если совсем убрать поле (например второе) из proto, не зарезервировав номер?
Обсудили дефолтные значения при декодировании и опасность для бизнес-логики.
23
Теория
Какой у вас опыт с Kubernetes? Для чего он нужен, какие задачи на себя берёт?
У кандидата минимальный опыт (знает про поды); их сервисы крутятся в Docker без оркестрации.
24
Теория
Расскажите про observability у вас: какие метрики собираете (Prometheus/Grafana), где логи и трассировка, как настроены трешхолды/алерты?
Бизнес- и тех-метрики, ElasticSearch для логов, алерты в Slack при пороге (например >50% ошибок).
25
Теория
Приходилось ли работать с профилировщиком? Были ли боевые кейсы (например долго работающие места, утечки памяти)?
Использовал pprof и бенчмарки для сравнения реализаций.
26
Поведенческий
Как вы относитесь к тестам? Для чего они нам вообще нужны? Нет ли ощущения, что на полстраницы кода приходится писать вдвое больше тестов?
Обсудили покрытие, цель тестов (защита при рефакторинге/релизах), у команды только юнит-тесты.