Что на самом деле проверяют на собеседовании IT-специалиста

Кто на самом деле сидит в комнате

На большинстве позиций первой или второй линии поддержки вас будет собеседовать не профессиональный рекрутер. Это будет руководитель service desk или IT-менеджер, которому сейчас принадлежат заявки, которые вы будете разбирать, иногда с одним действующим техником, который задаёт технические вопросы, потому что именно ему придётся доверять вашим решениям. В небольших компаниях это может быть единственный системный администратор, который собеседует вас отчасти потому, что устал и хочет кого-то, кто сможет забирать заявки, не создавая новых проблем.

Часто сначала бывает короткий разговор с HR или рекрутером, в основном чтобы проверить зарплатные ожидания, право на работу и срок уведомления. Этот разговор не проверяет вашу техническую квалификацию, и не стоит слишком много из него выносить. Интервью, которое определяет результат — это то, что проводит человек, который будет сидеть рядом с вами.

Практическая оценка и что она на самом деле проверяет

Многие собеседования техников поддержки включают практическую часть, потому что говорить о диагностике и делать её — разные навыки. Форматы варьируются, но типичные варианты:

• Ноутбук или десктоп перед вами с заранее внесённой неисправностью — нет сетевого подключения, повреждённый профиль пользователя, принтер не ставит задания в очередь, машина не выходит с экрана входа — и вас просят найти и исправить проблему, проговаривая свои шаги.
• Сценарий на доске или устно: «пользователь звонит и говорит, что его ПК не может подключиться к сетевому диску, расскажите, что вы делаете».
• Иногда короткий письменный или онлайн-тест на темы вроде разбиения на подсети, распространённых номеров портов или чтения вывода ipconfig /all и определения, что в нём не так.
• Иногда имитация звонка или ролевая игра, где кто-то играет раздражённого нетехнического пользователя, и вы должны получить от него полезную информацию и объяснить решение без жаргона.

Проверяют не то, найдёте ли вы правильный ответ сразу. Проверяют, есть ли у вас метод. У сетевой проблемы, например, есть довольно стандартный порядок исключения: вставлен ли кабель, включён ли адаптер, показывает ли ipconfig валидный IP или APIPA-адрес (169.254.x.x, что говорит о сбое DHCP), можете ли вы пропинговать шлюз, можете ли пинговать по IP, но не по имени (что указывает на DNS), можете ли резолвить внешние адреса, но не внутренние (что указывает на конкретный DNS-сервер или проблему split-tunnel VPN). Кандидат, который начинает оттуда, вслух, показывает то, чего не показывает кандидат, который говорит «я бы попробовал перезагрузить, потом переустановить сетевой драйвер, потом переустановить систему». Второй ответ в итоге может сработать. Но это не диагностика, это последовательность догадок, и любой, кто управлял service desk, видит разницу меньше чем за минуту.

Вопросы, которые на самом деле проверяют компетентность

Несколько вопросов возникают снова и снова, и они делают больше работы, чем кажется.

«Расскажите, как бы вы диагностировали [X]». Это ключевой вопрос. Им не нужна конечная точка, им нужен порядок действий и логика на каждом разветвлении. Сильный ответ систематически сужает проблему — аппаратная или программная, локальная или сетевая, один пользователь или многие — и говорит, что покажет каждый тест, прежде чем его запускать. Слабый ответ сразу прыгает к решению, которое сработало в прошлый раз на чём-то похожем.

«Расскажите о случае, когда ваше первое решение не сработало». Это проверяет две вещи: работаете ли вы с заявками самостоятельно, а не всегда эскалируете, и документируете ли и перепроверяете, а не пробуете случайные вещи, пока одна не сработает. Если в вашем ответе нет упоминания проверки event log, повторного тестирования после каждого изменения или обновления заявки с тем, что вы исключили — это пробел, который заметят.

«Как вы расставляете приоритеты в очереди?» Реальные service desk работают по какой-то версии приоритетов и SLA — VIP-пользователь, заблокированный в системе, это не то же самое, что замятие принтера, а P1-инцидент, затрагивающий целый этаж, важнее обоих. Если вы говорите об уровнях приоритета, влиянии против срочности, или о том, как бы вы обработали P1, который появился, пока вы в середине исправления чего-то другого — вы отвечаете из опыта. Если вы говорите «я просто работаю по порядку», это говорит, что вы либо не работали в системе заявок с реальными SLA, либо не думали об этом.

«Объясните [какую-то техническую проблему] человеку, который никогда не пользовался компьютером». Это не проходной вопрос о мягких навыках. Техники поддержки большую часть дня занимаются переводом, и тот, кто не может сделать это в комнате собеседования, без реального давления, не будет делать это хорошо на звонке с раздражённым пользователем в 16:45. Обратите внимание на кандидатов, которые находят аналогию и держат её короткой, в отличие от тех, кто упрощает словарь, но сохраняет то же длинное объяснение.

Вопросы о каталогах и доступах. В зависимости от среды, ожидайте чего-то конкретного: как разблокировать учётную запись Active Directory, в чём разница между сбросом пароля и принудительной сменой при следующем входе, как бы вы добавили пользователя в группу безопасности против группы рассылки, что вы проверяете, прежде чем предоставить повышенные права тому, кто их запросил. Это не вопросы с подвохом. Они проверяют, что вы действительно использовали AD Users and Computers, или Intune, или что там использует компания, а не просто читали об этом.

Вопрос о безопасности, почти всегда. Что-то вроде «пользователь пишет вам, что кликнул по ссылке, и теперь его машина странно себя ведёт, что вы делаете в первую очередь?» Они хотят изоляцию перед расследованием — отключить от сети, пока не перезагружать, если есть шанс последующей экспертизы, сообщить наверх, не просто запустить антивирус и идти дальше. И где-то они проверят, просил ли вас когда-нибудь кто-то, утверждающий, что он менеджер в спешке, дать admin-пароль, и что вы сделали.

Как звучит поверхностный ответ

Нанимающие обычно могут определить за предложение или два, когда ответ заучен, а не прожит. Несколько паттернов встречаются часто:

• Называть решение без диагностики. «Я бы переустановил систему» как первая строка ответа, без упоминания того, что скажет вам, что переустановка действительно нужна.
• Относиться к системе заявок как к бумажной работе, а не к записи. Если вы не можете сказать, что бы вы написали в примечаниях к заявке, или описываете закрытие заявок без подтверждения исправления с пользователем — это замечают.
• Цитировать содержание сертификации без привязанной к ней истории. Знать, что DNS работает на порту 53, это не то же самое, что действительно разбирать проблему DNS. Если у вас есть CompTIA A+ или Network+, или сертификат ITIL Foundation, ожидайте, что это всплывёт — но интервьюер уже знает множество людей, которые сдали эти экзамены, не умея ничего исправить. Они зададут уточняющий вопрос, требующий, чтобы вы действительно делали это, а не просто изучали.
• Размытый язык владения. «Мы исправили» или «команда решила», когда спрашивают, что сделали лично вы.
• Никакого упоминания пользователя. Технически правильный ответ, который никогда не упоминает проверку с человеком, поднявшим заявку, читается как ответ того, кто чинит машины, а не проблемы людей.

Что на самом деле готовить

Подготовьте две-три реальные заявки, о которых можно подробно рассказать — не интересный инцидент раз в год, а обычные: принтер, который не ставил задания в очередь, разрыв VPN для одного пользователя, блокировку учётной записи, которая оказалась закешированными учётными данными на телефоне. Будьте готовы без подсказки сказать, что вы проверяли и в каком порядке, и что бы вы сделали дальше, если бы первое не сработало. Если ваша текущая или последняя работа использует конкретный стек — ServiceNow, Zendesk, Intune, SCCM, конкретную структуру AD — знайте реальные термины, которые вы там используете, потому что размытое описание читается так же, как неопытность, даже когда это не так. И если вас спрашивают о сценарии, с которым вы действительно не сталкивались, скажите об этом и всё равно рассуждайте вслух; это ближе к тому, чем на самом деле является работа, чем правильные ответы на всё.

Если вы рассылаете заявки и не получаете ответа ещё до того, как дойдёте до этого этапа, jobmarket.pro читает объявление полностью, сопоставляет его с вашим реальным опытом и готовит заявку на основе этого, а не общего резюме.