Вопросы для собеседования Java-разработчика

Что хотим услышать

• int примитив: хранит значение, не может быть null, дешёвый
• Integer объект-обёртка: может быть null, нужен в коллекциях и дженериках
• Автоупаковка через Integer.valueOf и кеш -128..127
• Сравнение Integer через equals, а не ==
• NPE при распаковке null
• В горячем коде упаковка даёт лишние объекты и нагрузку на GC

Если ответил, копните глубже

Что хотим услышать

• Класс объявляет зависимости, а не создаёт их
• Слабая связанность: зависимость от интерфейса
• Простые юнит-тесты: мок через конструктор
• Контейнер управляет жизненным циклом и скоупом
• Контейнер добавляет сквозную функциональность через прокси: транзакции, кеш

Если ответил, копните глубже

Что хотим услышать

• Null-safety в системе типов: NPE ловится при компиляции
• Меньше шаблонного кода: data class, свойства, вывод типов, именованные и дефолтные аргументы
• Функции расширения, лямбды и удобная stdlib для коллекций
• Корутины для асинхронного кода без колбэков
• Полная совместимость с Java: можно смешивать в одном проекте
• Выражения вместо операторов: if, when, try возвращают значения

Если ответил, копните глубже

Что хотим услышать

• WHERE фильтрует строки до группировки, HAVING фильтрует группы после
• В WHERE нельзя агрегаты, в HAVING можно
• Порядок: FROM, WHERE, GROUP BY, HAVING, SELECT
• Условия без агрегатов лучше писать в WHERE: меньше строк до группировки
• Пример: WHERE status = 'paid' и HAVING SUM(total) > 10000

Если ответил, копните глубже

Что хотим услышать

• Same-origin policy: скрипт не может читать ответы другого origin (схема, хост, порт)
• CORS: сервер заголовками Access-Control-Allow-* разрешает конкретным origin читать ответы
• Проверяет браузер, сервер отвечает всегда; вне браузера CORS не действует
• Простые запросы уходят сразу, остальные после preflight OPTIONS
• С куками нужен credentials: 'include', Allow-Credentials: true и точный origin вместо *

Если ответил, копните глубже

Что хотим услышать

• Вертикальное: мощнее машина, код не меняется, есть предел и единая точка отказа
• Горизонтальное: больше узлов, нужен stateless или распределённое состояние
• Stateless-сервисы приложения масштабируют горизонтально в первую очередь
• БД часто сначала масштабируют вертикально и репликами, шардирование позже
• Горизонтальное даёт отказоустойчивость, но добавляет сложность

Если ответил, копните глубже

Что хотим услышать

• Называет, что такое n (и m, если входов несколько)
• Считает циклы: вложенные перемножаются, последовательные складываются
• Помнит скрытые циклы: includes, indexOf, slice, sort, spread
• Отдельно оценивает память, включая стек рекурсии
• Сравнивает с ограничениями: при n до 10⁵ O(n²) уже не годится

Если ответил, копните глубже

Что хотим услышать

• граф зависимостей от точки входа
• трансформация: TS, JSX, современный синтаксис, CSS
• резолв пакетов из node_modules
• склейка в чанки, минификация, tree shaking
• хеши в именах для долгого кеша
• dev-сервер с HMR и source maps

Если ответил, копните глубже

Что хотим услышать

• Жёсткая ссылка: ещё одно имя того же inode, равноправное с оригиналом
• Данные живут, пока счётчик ссылок больше нуля и файл никто не держит открытым
• Жёсткую нельзя на каталог и между разными ФС
• Символьная: отдельный файл, внутри которого путь к цели
• Символьная ломается при удалении или переносе цели, зато работает с каталогами и через ФС
• Пример: symlink на текущий релиз current -> releases/42 для атомарного переключения

Если ответил, копните глубже

Что хотим услышать

• Две-три стороны, а не список из десяти
• Каждая подкреплена примером
• Стороны связаны с вакансией
• Нет пустых слов вроде «стрессоустойчивый, коммуникабельный» без доказательств
• Уверенно, без хвастовства

Если ответил, копните глубже

Что хотим услышать

• Всегда по значению
• Для объектов копируется ссылка, а не объект
• Метод может менять состояние объекта через копию ссылки
• Присваивание параметру новой ссылки не видно снаружи
• Пример со swap двух объектов, который не работает

Если ответил, копните глубже

Что хотим услышать

• Топик делится на партиции, партиция это упорядоченный лог
• Offset это позиция сообщения, потребитель хранит свой offset
• Сообщения не удаляются после чтения, хранятся по retention
• Consumer group: партиция на одного потребителя группы
• Ключ определяет партицию и порядок
• Репликация: лидер и реплики

Если ответил, копните глубже

Что хотим услышать

• Платформенный поток = поток ОС, дорогой; виртуальный управляется JVM
• Continuation: при блокировке стек сохраняется в куче, носитель освобождается
• Выигрыш в пропускной способности для I/O, не для CPU
• Pinning в synchronized в Java 21-23, исправлен в 24
• Не пулить, ограничивать семафорами; осторожно с ThreadLocal
• Spring Boot 3.2+: spring.threads.virtual.enabled, проверить пул соединений БД

Если ответил, копните глубже

Что хотим услышать

• Page делает count, Slice нет
• OFFSET линейно дорожает с глубиной
• Keyset (seek) пагинация по индексированному ключу, ScrollPosition и Window
• Стабильная сортировка с уникальным ключом
• Нельзя join fetch коллекций с пагинацией
• Проекции вместо сущностей

Если ответил, копните глубже

Что хотим услышать

• Компилятор генерирует методы интерфейса, переадресующие делегату
• Переопределяются только нужные методы
• Композиция вместо наследования, работает с final-классами
• Делегат фиксируется при создании
• Делегат не видит переопределений обёртки: нет полиморфизма через this

Если ответил, копните глубже

Что хотим услышать

• UPDATE создаёт новую версию строки, старая остаётся с xmax; DELETE только помечает версию
• Каждая транзакция видит версии по своему снимку, поэтому чтение не блокирует запись и наоборот
• VACUUM удаляет версии, которые уже никому не видны, обновляет visibility map и замораживает старые строки
• Долгие транзакции и забытые слоты репликации мешают очистке и раздувают таблицы
• Autovacuum настраивают по таблицам: autovacuum_vacuum_scale_factor, лимиты стоимости; мониторинг через pg_stat_user_tables
• HOT-обновления и fillfactor уменьшают нагрузку на индексы

Если ответил, копните глубже

Что хотим услышать

• Реконнект с экспоненциальной задержкой и джиттером, сброс задержки после успеха
• Heartbeat: ping/pong с таймаутом, при пропуске закрыть и переподключиться
• Нумерация сообщений: после реконнекта клиент сообщает последний id, сервер досылает пропущенное
• Очередь исходящих сообщений с клиентскими id, идемпотентность на сервере против дублей
• Реакция на online/offline и видимость вкладки, повторная авторизация при истёкшем токене

Если ответил, копните глубже

Что хотим услышать

• Требования: личные и групповые чаты до 1 000 участников, доставка онлайн и офлайн (push), история, статусы «доставлено» и «прочитано»; порядок сообщений в чате; медиа и сквозное шифрование вне рамок
• Оценка нагрузки: 50 млн DAU по 40 сообщений ≈ 2 млрд в сутки ≈ 20 000 RPS записи, в пике ~60 000; 10 млн одновременных соединений, ~100 000 на gateway → ~100 gateway; 2 млрд × 200 байт ≈ 400 ГБ в сутки, ~150 ТБ в год без реплик
• API: WebSocket: send {chat_id, client_msg_id, text}, ack {msg_id}, события new_message, read; HTTP: GET /chats/{id}/messages?before=...
• Данные: чаты и участники в PostgreSQL, сообщения в Cassandra/ScyllaDB с ключом партиции chat_id и сортировкой по msg_id, реестр user_id → gateway в Redis с TTL
• Компоненты: gateway-серверы с соединениями, сервис сообщений (сохранить, присвоить id, разослать), сервис присутствия, push-сервис для офлайн, очередь для фан-аута в группах
• Узкие места: большие группы (фан-аут через очередь), дубли при переотправке (client_msg_id для идемпотентности), переподключения и догрузка пропущенного, горячие чаты, падение gateway

Если ответил, копните глубже

Что хотим услышать

• начать с самого рискованного и ценного для бизнеса: оплата, вход, ключевые сценарии
• несколько e2e smoke-тестов на критичные пути
• unit-тесты на чистую логику: расчёты, форматирование, утилиты
• интеграционные тесты компонентов и API на новых и изменяемых местах
• тесты в CI как обязательная проверка PR
• регрессионный тест на каждый найденный баг, борьба с флаки

Если ответил, копните глубже

Что хотим услышать

• Воспроизвести и уточнить симптом: таймаут, refused, ошибка TLS, 5xx
• DNS: dig +short, правильный ли IP, не истёк ли домен
• Сеть и порт снаружи: curl -v, nc -zv host 443; refused или timeout
• На сервере: слушает ли процесс и на каком адресе (ss -tlnp), отвечает ли локально
• Фаервол на хосте и в облаке, балансировщик и его health checks
• Логи прокси и приложения, сертификат и его срок

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже

Что хотим услышать

• Инвариантность дженериков и зачем нужны wildcard
• addAll: Collection<? super T> приёмник, элементы как producer
• max: Collection<? extends T> и Comparator<? super T>
• PECS как правило выбора
• Wildcard только в параметрах, не в возвращаемых типах

Если ответил, копните глубже

Что хотим услышать

• База на сервис, нет 2PC
• Саги: локальные транзакции и компенсации, хореография или оркестрация
• Outbox для надёжной публикации событий
• At-least-once доставка и идемпотентные потребители
• Eventual consistency и как её показывать пользователю
• Мониторинг зависших саг и ручной разбор

Если ответил, копните глубже

Что хотим услышать

• Источник: MutableStateFlow с текстом запроса
• debounce, чтобы не слать запрос на каждую букву
• filter по длине и distinctUntilChanged
• flatMapLatest отменяет устаревший запрос
• catch для ошибок, flowOn или main-safe репозиторий
• stateIn в ViewModel с WhileSubscribed

Если ответил, копните глубже