Подготовка к интервью

Вопросы на собеседовании в ВКонтакте

5 вопросов с собеседований в ВКонтакте

5 вопросов 1620 компаний 353 технологии

Что проверяют на интервью

Как устроена подборка

Подборка объединяет вопросы, отмеченные на этапах интервью в ВКонтакте. Здесь можно понять структуру технической проверки и заранее повторить связанные темы. В подборке чаще встречаются темы: prometheus, opentelemetry, kafka.

Каталог

Результаты поиска

Найдено: 5
System Design

Вы разъехались с одного кластера на шесть. Объясни по деталям: как было организовано сетевое взаимодействие между кластерами после разъезда, как переносили stateful-компоненты — Patroni, Kafka, Redis — без даунтайма, и по какому принципу решали, какой сервис в какой кластер едет?

Разделение кластеров проектируют по границам ответственности, требованиям изоляции и зависимостям; перенос stateful-систем требует отдельных процедур.

Читать ответ
Поведенческий

Time-to-market с 4 дней до 6 часов — за счёт чего конкретно? Расскажи, где живёт логика скаффолдинга, как обеспечивали идемпотентность при создании ресурсов, что происходит, если пайплайн упал на середине, и почему самообслуживание не распространяется на Yandex Cloud?

Такое сокращение time-to-market нужно объяснять измеренным устранением конкретных ожиданий и ручных этапов, а не только внедрением шаблонов.

Читать ответ
System Design

Таймауты в чекауте раз в сутки, метрики приложения чистые. Объясните полностью: почему проблема не была видна на уровне приложения, как трейсинг помог локализовать разрыв между ingress и подом, почему conntrack заполнялся только на части нод, какие конкретные лимиты и настройки ядра меняли и почему taint на отдельный пул нод был правильным решением, а не resource limits или NetworkPolicy.

Переполнение conntrack — гипотеза, которую нужно подтвердить на проблемных нодах; запросы, потерянные до приложения, могут не попасть в его метрики.

Читать ответ
System Design

Ты говоришь, что перешёл с Prometheus на VictoriaMetrics и внедрил трейсинг на 120+ сервисов. Расскажи подробно: как вы мигрировали исторические данные без потери и слепой зоны в алертинге, какую схему семплирования выбрали в OpenTelemetry и почему именно tail-based, и как SLO-алертинг через burn rate помог снизить ложные срабатывания на 60%?

Миграцию наблюдаемости проводят с перекрытием сбора и сверкой данных, а снижение шума подтверждают измерениями до и после.

Читать ответ
System Design

Минус 35% потребления ресурсов и более 100K RPS. Расскажите, как методически считали реальное потребление и убеждали команды менять requests, почему сняли CPU-лимиты и чем это рискованно, как устроены pre-scaling и overprovisioning перед пиком, что конкретно настраивали в Nginx и какие сервисы принципиально не перевели на spot-инстансы и почему.

Такие результаты подтверждают сопоставимыми измерениями и объяснением компромиссов, а не только числом RPS или процентом экономии.

Читать ответ