Вопросы на собеседовании в техническую поддержку
На техническом интервью в поддержку почти не бывает вопросов с подвохом. Проблема в другом: кандидат отвечает определением из конспекта, а интервьюер ждал объяснения механики. Разберём пять вопросов, где это расхождение видно отчётливее всего.
Что на самом деле проверяют
Интервьюер редко хочет услышать формулировку из учебника. Он проверяет, понимаете ли вы, что происходит внутри — потому что в работе вам придётся разбирать ситуации, которых не было ни в одном конспекте.
Отсюда простое правило: любой ответ лучше строить не вокруг термина, а вокруг того, как это выглядит на практике. Фраза «а на работе это проявляется так-то» стоит больше, чем три точных определения подряд.
Второе, что оценивают, — как вы рассуждаете, когда не знаете ответа. Сказать «не сталкивался, но рассуждал бы так» — нормально. Молчать или выдумывать — плохо, причём выдумывать хуже.
«Чем TCP отличается от UDP?»
Типичный ответ: TCP гарантирует доставку, UDP — нет. Формально верно, и на этом кандидат обычно останавливается.
Интервьюер ждёт продолжения: а каким образом гарантирует? Здесь нужно рассказать про установку соединения перед передачей данных, про подтверждения получения, про повторную отправку потерянных сегментов, про восстановление порядка на стороне получателя.
Дальше — чем за это платят. Соединение надо установить, подтверждения занимают время, потерянный сегмент придётся ждать, а вместе с ним встанет вся очередь. Для передачи файла это правильный размен, для голосового звонка — нет: там лучше потерять кусочек звука, чем получить его с задержкой в две секунды.
И примеры. По TCP работает почти всё привычное: веб, почта, обращения к базам данных. По UDP — голос и видео в реальном времени, часть игр, DNS-запросы, сбор метрик и логов, где потеря отдельного пакета некритична.
Хороший финал ответа — практический: «в работе это всплывает, когда разбираешь, почему часть трафика теряется молча, без ошибок в логах».
«Что происходит, когда вводишь адрес в браузере?»
Классика жанра, которую спрашивают именно потому, что по глубине ответа сразу видно уровень. Плохой вариант звучит как «браузер отправил запрос, сервер ответил, сайт открылся» — это описание результата, а не процесса.
Разворачивать стоит примерно так:
- браузер проверяет собственный кэш, затем системный, затем обращается к DNS-серверу, чтобы получить IP-адрес по доменному имени;
- по полученному адресу устанавливается TCP-соединение, для HTTPS сверху добавляется TLS-рукопожатие с проверкой сертификата;
- отправляется HTTP-запрос с заголовками — среди них
Host, куки, данные авторизации; - запрос почти наверняка попадает не прямо в приложение, а сначала на балансировщик или обратный прокси, который решает, куда его направить;
- приложение формирует ответ, отдаёт код состояния и тело;
- браузер разбирает HTML и подтягивает остальное: стили, скрипты, картинки — каждый элемент отдельным запросом;
- страница отрисовывается.
Отдельный плюс кандидату — упомянуть, что на каждом из этих шагов что-то может сломаться, и знание цепочки как раз и позволяет локализовать проблему: не открылось вообще, открылось без стилей, открылось с ошибкой авторизации — это три разные точки отказа.
«В чём разница между GET и POST?»
Ответ «GET получает данные, POST отправляет» верен и совершенно недостаточен. Интервьюера интересуют следствия, а не назначение.
Параметры GET-запроса находятся прямо в адресной строке, а значит попадают в историю браузера, в закладки, в логи веб-сервера и прокси, в заголовок Referer при переходе на другой сайт. Отсюда практическое правило: пароли и персональные данные в GET не передают. У POST данные лежат в теле запроса — в логах их по умолчанию не видно, хотя в открытом HTTP они точно так же передаются незашифрованными.
Есть и разница в поведении: GET-ответы кэшируются, GET-запрос безопасно повторить, а вот повторная отправка POST может создать второй заказ — отсюда предупреждения браузера при обновлении страницы после отправки формы.
Для поддержки это не абстракция. Когда разбираешь заявку, GET-запрос можно восстановить прямо из логов, а вот тело POST придётся искать в логах приложения — если их вообще пишут.
«Как работают cookies?»
Здесь кандидаты обычно перечисляют, что в куках хранится: сессия, настройки, просмотренные товары. Это ответ пользователя, а не инженера.
Инженерный ответ начинается с того, кто их устанавливает. Сервер присылает заголовок Set-Cookie, браузер сохраняет значение и дальше сам подставляет его в каждый следующий запрос к этому домену.
Дальше — атрибуты, и они важнее содержимого. Домен и путь определяют область видимости: куке, выставленной для одного домена, на другом взяться неоткуда. Срок жизни делит куки на сессионные, исчезающие при закрытии браузера, и постоянные. Флаг Secure запрещает отправку по незащищённому соединению. Флаг HttpOnly закрывает доступ к куке из JavaScript и защищает от кражи сессии через межсайтовый скриптинг. Атрибут SameSite управляет отправкой куки при переходах с других сайтов.
Почему это спрашивают у поддержки: изрядная доля заявок вида «меня постоянно разлогинивает» или «не работает вход» упирается именно сюда — в срок жизни, область видимости или несовпадение домена после переезда сервиса.
«Чем LEFT JOIN отличается от обычного JOIN?»
Вопрос, на котором чаще всего возникает пауза — потому что кандидат не уверен, какой JOIN считается «обычным».
Считается INNER. Он оставляет только те строки, для которых нашлось совпадение в обеих таблицах. LEFT JOIN берёт все строки левой таблицы и подставляет совпадения из правой, а где их нет — ставит NULL.
Разница вылезает сразу же, как только вы делаете отчёт. Классическая ситуация: нужно вывести всех пользователей и количество их обращений. С INNER JOIN из ста пользователей в отчёт попадут восемьдесят — те двадцать, что ни разу не обращались, просто исчезнут. С LEFT JOIN они останутся, а функция подсчёта проигнорирует NULL и покажет у них ноль.
Для поддержки это не теория: тихо пропавшие из выгрузки строки — одна из самых неприятных ошибок, потому что запрос отработал без ошибок и результат выглядит правдоподобно.
Как отвечать
Объясняйте простыми словами и приводите примеры — понимание видно именно через них, а не через точность формулировок. Если вопрос кажется слишком простым, значит, от вас ждут глубины: разворачивайте.
Не бойтесь уточнять сам вопрос, это не признак слабости. «Вы про клиентскую или серверную часть?» — нормальная реплика, которая показывает, что вы понимаете контекст.
И держите в голове, что техническая часть — не единственное, что оценивают. На собеседовании в поддержку почти наверняка спросят, как вы поступите, если пользователь агрессивен, если вы не знаете решения, если задача висит третий день без движения. Ответы на эти вопросы весят не меньше, чем определение TCP.