Загрузка…
Загрузка…
backend / middle / tech_deep
Формат
online
Стадия
tech_deep
Когда
within_quarter
Длительность
—
01
Поведенческий
Расскажи две-три самые интересные либо технически самые сложные задачи из твоей практики (которые принесли бизнес-value или были интересны с точки зрения технической разработки).
Кандидат рассказал про стабилизацию p95 латенси real-time аукциона, transactional outbox для надёжной доставки событий, CQRS для дашбордов.
02
Поведенческий
Ты сам отвечал за архитектуру? Приходилось ли согласовывать архитектурные решения (например, с архитекторами), или у тебя была свобода проектировать самому?
Follow-up к рассказу об опыте.
03
Теория
Расскажи про базовые типы в Go и немного в глубину: особенности слайсов и массивов, чем слайс отличается от массива, как с ними работать, как работает append.
Ожидались детали: алгоритм роста capacity, передача по значению/ссылке, утечки памяти через удержание базового массива.
Заметки
Техническое интервью на Go-разработчика (бэкенд) в компанию экосистемы Сбера (интервьюер: «это по сути тоже Сбер», процессы как в Сбере; название компании в тексте явно не звучит). Интервьюер — разработчик команды CDP (платформа клиентских данных, маркетинговые рассылки для Мегамаркета, Купера, Самоката), но интервью общее — в любую из команд. Структура: рассказ о 2-3 интересных задачах из опыта → теория по Go (слайсы, мапы, каналы, горутины, ошибки/паники) → лайвкодинг на Go (параллелизм: горутины, семафор, panic/recover) → SQL-задачи (join, group by, having, case, сортировка с null) → теория по Postgres (индексы, партиционирование, репликация, денормализация), Kafka, микросервисам, Docker. Кандидат — выходец из Сбертеха (до этого Иннотех), ~2+ года коммерческого опыта, уволился за 2 недели до собеседования. Следующий этап при успехе — финалы с командами, алгоритмических секций больше не ожидается. Обратную связь обещали быстро. Были проблемы со связью (звонок несколько раз прерывался).
Подготовка
Кандидат отметил, что после двух недель без практики «подкипал» на синтаксисе Go и SQL — стоит освежить базовый синтаксис (panic, скобки, запятые в SELECT, ORDER BY ... NULLS FIRST/LAST) перед лайвкодингом. Ходовые темы: слайсы/мапы/каналы/горутины под капотом, семафор на буферизированном канале, panic/recover, индексы Postgres (B-tree vs Hash, составные, GIN/GiST, частичные/функциональные), партиционирование, базовые сущности Kafka и консюмер-группы, DLQ/transactional outbox, multistage-сборка Docker.
Стиль интервьюера
Доброжелательный и поддерживающий: подсказывал при мелких синтаксических ошибках («там скобок не хватает», «запятых не хватает»), не давил, при достаточном ответе быстро переходил дальше («в целом достаточно, пойдём дальше»), сам раскрывал правильные ответы, когда кандидат затруднялся (необрабатываемые ошибки, partition pruning, DLQ). Ход интервью частично стандартизирован. В конце охотно рассказал про свою команду и процессы, честно предупредил про возможный гибридный формат.
04
Теория
Безопасен ли параллельный доступ к слайсу? Какие проблемы возникают при конкурентном изменении элементов?
05
Теория
Расскажи про каналы в Go: типы/виды каналов, какие состояния бывают, какие операции доступны и к чему приводят операции в разных состояниях (например, чтение из закрытого канала).
Буферизированные/небуферизированные каналы, nil/открытый/закрытый канал, паника при отправке в закрытый канал.
06
Теория
Расскажи про map в Go: детальная реализация под капотом, эвакуация, бакеты, сложность доступа к элементам и операций над мапой.
Кандидат рассказал про load factor 6.5, эвакуацию, бакеты по 8 ячеек, амортизированную O(1) и худший случай O(n).
07
Код
Лайвкодинг: дана функция printNumber (сигнатуру менять нельзя, внутри Sleep 1 секунда). Распечатай с её помощью числа от 1 до 10.
Разминочная часть задачи на параллелизм.
08
Код
Распараллель печать чисел с помощью горутин, чтобы все 10 значений распечатались примерно за одну секунду (порядок неважен). Программа не должна завершаться раньше горутин.
Кандидат использовал go-рутины и sync.WaitGroup.
09
Код
Добавь ограничение: одновременно должно выполняться не больше трёх горутин (паттерн семафор).
Кандидат реализовал через буферизированный канал на 3 элемента + WaitGroup.
10
Код
Создай в main горутину, которая вызывает панику с произвольной строкой, а затем обработай эту панику.
Обработка через defer + recover внутри горутины.
11
Теория
Чем являются ошибки в Go? Что такое error и как делать кастомные виды ошибок?
Ожидаемый ответ: error — это интерфейс с одним методом.
12
Теория
Есть ли в Go ошибки/паники, которые не получится обработать (перехватить через recover)?
Интервьюер привёл примеры: stack overflow и подобные фатальные ошибки. Кандидат затруднился.
13
Теория
Горутины принято называть легковесными аналогами потоков ОС. За счёт чего достигается их легковесность?
Кандидат ответил про начальный стек ~2КБ и его автоматическое расширение.
14
Теория
Помимо памяти — какие преимущества горутин с точки зрения управления (планировщик, переключение контекста)?
Follow-up к вопросу о легковесности горутин.
15
Код
SQL: даны таблицы городов (cities) и пользователей (users). Вывести одной таблицей название города и имя пользователя (JOIN).
Серия SQL-задач на лайвкодинге.
16
Код
SQL: модифицировать запрос, чтобы выводились все города; если у города нет пользователей — выводить NULL (LEFT JOIN).
17
Код
SQL: вывести одной таблицей название города и количество пользователей в городе (COUNT + GROUP BY).
18
Код
SQL: ограничить выборку только городами, в которых количество пользователей меньше двух (HAVING).
19
Код
SQL (со звёздочкой): для городов, в которых количество пользователей равно нулю, вместо нуля выводить NULL (CASE).
20
Код
SQL: изменить сортировку результата по количеству пользователей с возрастания на убывание (ORDER BY ... DESC).
21
Код
SQL: сделать так, чтобы при сортировке NULL шёл последним (NULLS LAST), а затем — чтобы при сортировке по возрастанию NULL был первым (NULLS FIRST).
Кандидат вспомнил NULLS LAST, с NULLS FIRST были затруднения.
22
Теория
Если бы написанные SQL-запросы медленно работали на продакшене, как бы ты их анализировал? Какие механизмы оптимизации применил бы?
Кандидат назвал EXPLAIN / EXPLAIN ANALYZE.
23
Теория
В чём разница между EXPLAIN и EXPLAIN ANALYZE?
24
Теория
Видишь в плане запроса Seq Scan при выборке пользователей по ID — что бы ты сделал?
Ожидаемый ответ — добавить индекс.
25
Теория
Какой индекс по структуре данных ты бы применил в таком случае? Какие типы индексов в Postgres знаешь?
Кандидат назвал B-tree, Hash, GIN, GiST, BRIN.
26
Теория
Чем отличаются B-tree и Hash индексы?
27
Теория
Какие операции (сравнения, равенство и т.д.) поддерживают B-tree и Hash индексы? Есть ли ограничения, на какие операции работает каждый индекс?
Кандидат ответил частично (hash — только равенство).
28
Теория
Может ли в индексе быть несколько столбцов (составной индекс)?
29
Теория
Составной B-tree индекс (id, name) против (name, id) — есть ли разница в порядке столбцов и почему?
Ожидаемый ответ: порядок критичен, индекс читается слева направо.
30
Теория
Если запрос — поиск пользователя по идентификатору, какой порядок столбцов в составном индексе нужен? А если поиск по имени и идентификатору одновременно — какой индекс подойдёт?
Follow-up к вопросу о порядке столбцов в составном индексе.
31
Теория
Расскажи про индексы GIN и GiST: область их применения, для чего они нужны?
32
Теория
Могут ли индексы быть по какому-то условию или с использованием функции (частичные и функциональные индексы)? Использовал ли такие?
33
Теория
Есть понятие нормализации, а есть обратное — денормализация. Что это и использовал ли когда-нибудь?
Интервьюер отметил, что нормальные формы спрашивать не будет.
34
Теория
Знаешь ли про физическую репликацию именно в Postgres?
Кандидат ответил неуверенно, вопрос свернули.
35
Теория
Какие задачи решает партиционирование в Postgres, что оно вообще даёт?
36
Теория
Как работают запросы к партиционированной таблице: таблица пользователей партиционирована по city_id (5 партиций), ты делаешь SELECT * FROM users WHERE id = 1 (без ключа партиции) — в какие партиции уйдёт запрос?
Кандидат затруднился; интервьюер объяснил: без ключа партиции запрос идёт во все партиции.
37
Поведенческий
Работал ли ты с Elasticsearch? А с ClickHouse?
Проверка опыта по технологиям; кандидат с Elastic не работал, ClickHouse знает поверхностно — темы пропустили.
38
Теория
Расскажи про базовые сущности Kafka: брокеры, топики, партиции, продюсеры, консюмеры, офсеты.
39
Теория
Если есть 5 партиций и консюмер-группа с 10 консюмерами — как они будут читать?
Правильный ответ: задействуются только 5 консюмеров, по одному на партицию.
40
Теория
А если 10 партиций и 5 консюмеров — как распределится чтение?
Ответ: распределение равномерно, по две партиции на консюмера.
41
Теория
Есть ли у продюсера возможность писать в конкретную партицию? Для чего это может быть нужно?
42
Кейс
Консюмер получил сообщение, смог его прочитать, но не смог обработать — какой подход/паттерн использовал бы? Знаком ли паттерн DLQ?
Кандидат знал transactional outbox, DLQ не назвал.
43
Теория
Расскажи о плюсах и минусах микросервисной архитектуры по отношению к монолитной. Работал ли с монолитом?
44
Теория
Какие принципы используешь при написании кода (SOLID и т.п.)? Как понимаешь принцип единственной ответственности на уровне кода (сервис/пакет)?
45
Поведенческий
Микросервисы у тебя жили в Kubernetes или где? Как поднимали Docker-контейнеры?
Кандидат: Docker + docker-compose, этим занимались девопсы.
46
Теория
Смог бы сделать Docker-образ для Go-приложения? Знаешь про multistage-сборку в Docker?
Кандидат концептуально описал multistage: большой образ для сборки, итоговый тонкий образ с бинарником без зависимостей.