Про собеседования в IT - часть вторая: резюме, этапы собеседования, размер ЗП

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

Смотрите также: Про собеседования в IT - часть первая

Короткий глоссарий

• Софтскиллы - как ты общаешься, договариваешься, работаешь с людьми. Технически всё знать и при этом не подойти команде - вполне реальная история;
• Хардскиллы - технические знания и навыки. Что знаешь, что умеешь, какие задачи можешь решить;
• Грейд - условный уровень специалиста: Junior, Middle, Senior и промежуточные варианты вроде Middle+;
• Оффер - предложение о работе с конкретными условиями.

Какую работу я искал

Я искал позицию системного инженера грейда Middle+. Хотя названия вакансий были разные - DevOps, SysOps, системный администратор, техопс. В моём поиске за ними часто стояли похожие задачи, но далеко не всегда. На одно название тут ориентироваться нельзя.

Подготовка резюме

Резюме - момент, который многие игнорируют. Ошибка. Нужно подойти обдуманно, понимая текущий контекст.

Задачи, стек и результаты

Главное правило - просто перечислять навыки смысла нет. Интересуют конкретные задачи и результаты. Какие проекты реализовали? Какие проблемы решали? Что стало лучше после вашей работы?

Например, в резюме это может выглядеть так:

• Внедрил централизованный контроль доступа к Linux-серверам, что сократило число инцидентов, связанных с ошибками прав, примерно на 30%;
• Автоматизировал изменение конфигураций и сбор информации с помощью Bash и Ansible, что сократило время выполнения части текущих задач примерно на 50%;
• Разработал и внедрил инструмент резервного копирования, который объединил работу с файлами и дампами баз данных.

Такие вещи любят, даже обожают. Но цифры должны откуда-то браться. Если заявляешь про сокращение инцидентов, конечно, хорошо бы иметь статистику, например, из ticket-системы за конкретный период. Но общий посыл такой: ваши утверждения должны быть аргументированными. И вы, конечно, должны понимать, с чем сравниваете. Придумать красивый процент легко, а вот объяснять его…

Не всё обязательно измерять в процентах. Внедрил контроль версий для конфигураций, наладил сбор инвентарных данных, сделал резервное копирование - это тоже конкретный результат. Главное, чтобы за формулировкой было понятно, что изменилось, а не просто “участвовал в улучшении процессов”.

ИИ и оформление

Для поиска и первичного отбора могут использоваться алгоритмы и ИИ. Значит, резюме должно быть понятным не только человеку. Сначала я написал резюме так, как представляю его сам. Потом скинул в ChatGPT с просьбой привести в порядок - с учётом автоматизированной обработки. Параллельно общался со знакомыми HR, смотрел примеры их резюме, чтобы понять текущие тренды.

Но здесь есть нюанс: после нейросети текст нужно перечитать и вернуть ему человеческий вид. Длинные тире, фигурные кавычки и множество списков являются маркерами ИИ, даже для самих ИИ (в такое время живём). Резюме пока ещё всё-таки про вас как специалиста с определённым уровнем квалификации.

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

Тут же возникает современная специфика отбора: история с overqualified и underqualified. В первом случае для каких-то вакансий ты выглядишь слишком квалифицированным, во втором - недостаточно. Нужна золотая середина: показать подходящий опыт, не спрятать важное и не пытаться выглядеть человеком, который умеет вообще всё. И по технической части, и по софтскиллам.

“Сильно опытных”, насколько мне известно, сейчас тоже не везде жалуют. Где-то опасаются высоких зарплатных ожиданий, где-то - что человеку быстро станет скучно и он уйдёт. Поэтому, если вы динозавр с 20-летним стажем в IT, детально расписывать каждый год трудовой деятельности смысла не вижу. Важно не только то, сколько лет вы работаете, но и чем занимались в последнее время.

Технологии развиваются стремительно, поэтому я рекомендую делать акцент на релевантном опыте: база + стек, который нужен для конкретной вакансии. Это не значит, что старый опыт нужно вычеркнуть или что фундаментальные знания больше никому не интересны. Просто администрирование сервера двадцать лет назад и задачи, которые вы можете решать сейчас, - не одно и то же. Последние релевантные места работы можно описать подробно, более ранние - короче. Так, сказать без экскурсии по всем версиям Windows Server, которые вы застали.

С другой стороны, если вы джун-джун, в качестве опыта вполне можно указать свои пет-проекты или домашнюю лабораторию. Подняли стенд на Proxmox, настроили мониторинг, автоматизировали развёртывание через Ansible - уже есть что обсудить.

Главное, чтобы за этим стояла ваша работа и вы могли содержательно ответить на вопросы: зачем сделали именно так, с какими проблемами столкнулись, как проверяли результат. Сам по себе запущенный по чужой инструкции проект ещё мало о чём говорит. А вот если вы разобрались, как он работает и почему ломается, - это уже совсем другой разговор.

Фото, курсы и подтверждения

Фото - тоже часть резюме. Я бы выбирал обычное, на котором нормально видно лицо, без лишнего креатива.

Курсы, повышение квалификации и подтверждающие документы лучше не забывать. Если есть возможность прикрепить (свежие) сертификаты, особенно доступные через Госуслуги, - нужно прикрепить. Если на самой платформе есть профильные тесты (а они там есть) или курсы с отметкой о прохождении - это тоже рекомендую использовать. Только не путать подтверждение прохождения курса с реальным умением применять знания.

Желаемый доход я в резюме указывал. С точки зрения алгоритмов мне показалось это логичным. Вероятнее всего, HR-системы выполняют фильтрацию в том числе по зарплатной “вилке”, которой они располагают. Но это ещё не значит, что на собеседовании нужно сразу называть окончательную сумму. К этому вернусь отдельно.

Поиск на платформе

Я начал откликаться на вакансии на одном известном портале. Честно скажу - почти в 99% случаев это были отказы. Сперва я даже начал немного сомневаться в себе.

Но через некоторое время я узнал, в чём причина. Сама платформа поиска работы сегодня не создана для нормального взаимодействия с человеком. Как бы печально это ни звучало. Лежит там резюме, лежит себе. Уверен, не все знают, но для компаний доступ к резюме/контактам кандидатов платный, и это тоже влияет. Встречается и схема, при которой один HR покупает открытие резюме, а потом передаёт контакты коллегам по другим каналам связи. Так экономят на бюджете. Но связывать все отказы только с устройством платформы я бы не стал, хотя иметь это в виду важно.

Всего на платформе пришло буквально несколько предложений. Одно - с релокацией в глубинку за неоправданно низкий для такого переезда оклад. Не интересовало, рассматривать не стал. Остальное общение происходило совсем не там.

Основной контакт через мессенджеры

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

Чаще всего предлагали сначала интервью-знакомство с HR - примерно полчаса, общие вопросы-ответы, проверка взаимного интереса. Реже предлагали идти сразу на техническое собеседование.

Типичная схема прохождения

Статистика по всему процессу поиска выглядела так:

• HR-интервью - примерно 15 штук. Стандартный формат: 30 минут, ознакомление, базовые вопросы, проверка взаимного интереса;
• Техническое интервью - примерно 7-8 штук. Основной этап, до которого я доходил после знакомства с HR;
• Завершающий этап - буквально несколько встреч. После технического интервью, перед решением компании про оффер.

На техническом интервью уже идут серьёзные вопросы про опыт, квалификацию, конкретные задачи, которые ты решал. И тут история из резюме должна сходиться с тем, что ты можешь рассказать и показать.

Почти сразу на первом техническом собесе меня решили погонять по выводу стандартного менеджера процессов Linux - top.

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

После чего мы в течение всего технического интервью дотошно разбирали каждый пункт в выводе данной команды.

Это, что называется, база. Поэтому, если для вас это актуально, настоятельно рекомендую заглянуть сюда для “повторения матчасти”: Разбор вывода утилиты top.

Про ИИ

Ситуация на рынке IT сейчас, мягко говоря, неоднозначная. По моим ощущениям, он переполнен низкоквалифицированными кадрами, а также “настоящими” самозванцами, а не только теми, кто имеет такой синдром. Я говорю про “айти-волчат” и прочих вкатунов, которые учатся не столько работать, сколько проходить собеседования и продавать несуществующий опыт. И речь тут не о новичках как таковых - все когда-то начинали. Речь про сознательный обман. На этом фоне специалистам, у которых есть неподдельный интерес к технологиям, желание в них разбираться и реальный опыт, становится сложнее найти достойную работу.

Вероятно, вы уже видели разного рода видеоролики, в которых “хитрый кандидат” победил эту жизнь и обманом прошёл все этапы интервью в “большую компанию” с помощью ИИ. Тот в реальном времени слушает вопросы и подсказывает ответы в полупрозрачном окне. На видео всё выглядит красиво. Только проходить собеседования и потом самостоятельно решать рабочие задачи - немного разные навыки. Отчасти понимаю тут работодателя: становится всё сложнее здраво оценить квалификацию кандидата. Он действительно понимает, о чём говорит, или просто хорошо зачитывает сгенерированный ответ? Отсюда, как мне кажется, и дополнительные проверки, и растущее число этапов собеседований. Причём проходить всё это приходится в том числе людям, которые ничего не выдумывали и пришли со своим опытом. Но такова наша реальность, и с ней придётся как-то работать.

Со стороны работодателя законтрить подобное, на мой взгляд, проще через Live Admining, о котором пойдёт речь чуть ниже. Не просто спросить команду, а дать задачу, посмотреть на действия кандидата и попросить объяснить, что он проверяет и почему. Это не волшебная защита от любых подсказок, но разницу между пониманием и зачитыванием готового ответа так увидеть гораздо проще.

А пока моя рекомендация для всех тру системных инженеров - не использовать подобных помощников на самих собеседованиях. При наличии опыта и профессиональных навыков такой суфлёр скорее будет мешать: нужно одновременно слушать вопрос, читать подсказку и пытаться встроить её в собственный ответ. Лучше своими словами объяснить ход мысли, а где-то честно сказать “не помню, но проверял бы вот так”, чем уверенно озвучить то, чего сам не понимаешь. ИИ для подготовки и разбора пробелов - одна история. Скрытый суфлёр, который проходит интервью вместо тебя, - совсем другая.

Два отказа

Во время последнего поиска я прошёл почти все технические собеседования, но было и два отказа.

Первый отказ - по софтскиллам. Я прошёл все технические вопросы, но компании нужен был специалист, готовый много общаться с заказчиками параллельно с технической работой. Мне это не очень интересно, я готов был делать это максимум на 30% рабочего времени. Им же нужно было порядка 50%. Отказ был логичен.

Второй отказ - по хардскиллам. Это было самое интересное интервью. Трёхчасовое, с практикой. Вот об этом подробнее.

Live Admining - как это работает

Если у программистов есть Live Coding во время интервью, то для администраторов есть Live Admining. Суть простая - тебе дают доступ через браузер к виртуальной консоли сервера и просят выполнить несколько заданий.

Вот какие задачи мне давали:

Задача 1: Починить сеть

На Linux-машине был сетевой интерфейс, но доступа к нужной подсети не было. Машины в этой сети были недоступны. В этой задаче помогло изменение префикса подсети через команду ip: нужно было расширить диапазон адресов, которые машина считала своей локальной сетью. Рассчитать нужную маску помогла установленная утилита ipcalc.

Интересный нюанс: сделать это удалось наживую, без остановки и повторного запуска сетевого интерфейса. Через ip можно добавить на интерфейс дополнительный IP-адрес с нужным префиксом, не удаляя существующий. В конфигурации из задания этого оказалось достаточно - нужные хосты сразу стали доступны.

Решение далеко не идеальное и не на постоянку. Для рабочей инфраструктуры нужно отдельно разбираться с адресацией, маршрутами и сохранением настроек. Но тут суть в другом: интервьюер наблюдает за ходом ваших мыслей и действий. Что проверяете, какую гипотезу выдвигаете и понимаете ли, почему после изменения всё заработало.

ip -br addr show dev ens18
ip route get 192.168.11.20

sudo ip addr add 192.168.10.11/23 dev ens18

ip -br addr show dev ens18
ip route show dev ens18
ip route get 192.168.11.20
ping -c 3 192.168.11.20

sudo ip addr del 192.168.10.11/23 dev ens18

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

Задача 2: Проблема с резолвингом DNS

Не резолвилось имя хоста. Сетевые пакеты отправлялись, но имя сервера в IP-адрес не преобразовывалось.

Я почти сразу сообразил, что проблема в /etc/nsswitch.conf - нужно было поправить настройку поиска имён в строке hosts. Именно там задаётся, какие источники использовать для разрешения имён и в каком порядке. Одного наличия DNS-серверов в /etc/resolv.conf недостаточно, если обращение к DNS-серверам не включено в эту цепочку.

# Разрешение имени через системные механизмы, с учётом nsswitch.conf
getent ahostsv4 example.org

# Отдельный запрос к DNS - без учёта порядка источников в nsswitch.conf
dig example.org A

# Какие источники используются для разрешения имён и в каком порядке
grep -E '^[[:space:]]*hosts:' /etc/nsswitch.conf

# Настроенные DNS-серверы
cat /etc/resolv.conf

Задача 3: Что занимает место на диске?

Это была самая интересная задача. На первый взгляд казалась простой, но на самом деле имела несколько вариантов. Место закончилось, а где оно - не сразу понятно. Я вспомню минимум четыре причины такой картины:

• Скрытые файлы (dot-файлы) - самый очевидный вариант. Их легко пропустить, например, если считать размер через du -sh *: обычная звёздочка в shell, как правило, не захватывает имена с точкой в начале;
• Удержание дескриптора процессом - распространённая ситуация, когда процесс держит открытым уже удалённый файл. В каталоге файла больше нет, но место не освобождается, пока не будет закрыт последний дескриптор;
• Резерв для root-пользователя - например, в ext4 часть блоков может быть зарезервирована и недоступна обычным пользователям. Часто это 5%, но зависит от настроек. Это не потерявшиеся файлы, а отдельная причина, почему не всё свободное место доступно;
• Bind mount - смонтированная поверх директории другая директория скрывает её прежнее содержимое. Сверху может быть пусто, а под точкой монтирования лежат тяжёлые файлы, которые никуда не делись.

Было ещё несколько вариантов, но дальше уже не вспомню. Интервьюер подсказывал в некоторых моментах, особенно с bind mount и резервом - об этом я не знал в то время.

# Занятое и доступное место, тип файловой системы
df -hT /

# Размер каталогов первого уровня, без перехода на другие файловые системы
sudo du -xhd1 /

# Удалённые файлы, которые всё ещё открыты процессами
sudo lsof +L1

# Дерево монтирований
findmnt

sudo tune2fs -l /dev/sda2 | grep -E 'Block count:|Reserved block count:|Block size:'

С одной стороны, задача тривиальная, а с другой стороны она может проявиться вот в таком специфическом случае, где решение не очевидно.

А потом теория

После практических заданий было множество теоретических вопросов. Все вопросы были про Linux - сугубо Linux-вопросы.

Вот в чём была фишка: вакансия называлась “DevOps Инженер”, но про Kubernetes, Terraform, Ansible, Docker, Python-скрипты - ни слова. Только Linux. Я был даже удивлён немного.

Вот вам и разные названия вакансий. Смотреть нужно на задачи и ожидания конкретной команды, а не только на слово DevOps в заголовке.

По итогу мне пришёл отказ, но опыт я получил хороший. Ведь на подобных собеседованиях он нарабатывается активнее всего.

Основной задачей по данной вакансии было управление огромной инфраструктурой с помощью инструментов автоматизации, основным из которых является Puppet (IaC, инфраструктура как код, описанная на языке Ruby). Опыт работы с данной системой у меня был минимальный, но выглядело интересно.

Возможно, кто-то даже знает, что это за компания)

Вопрос желаемого дохода

За весь процесс поиска ни разу не пришлось вслух произнести желаемую цифру. Всегда отвечал уклончиво: “Рассматриваю предложения от той суммы, что указана в резюме”. То есть ориентир уже был, но окончательный ценник я не фиксировал.

Есть такое негласное правило: кто первый назвал цифру, тот проиграл. Не закон природы, конечно, но логика понятна. Определить - значит ограничить.

Нужно оставлять себе пространство для манёвра. Вообще прохождение собесов в IT (про другие сферы не могу утверждать) - это всё игра в кошки-мышки.

На этапе перед оффером HR может спросить, рассматриваете ли вы другие предложения. Стоит дать понять, что вы деловая колбаса нарасхват, а не просто сидите и ждёте решения одной компании.

Следующий вопрос - есть ли уже другие офферы. Сказать “да, есть один-два, ответ по ним просят дать до конца этой или следующей недели” - способ обозначить сроки. Старайтесь сильно не ограничивать потенциального работодателя, но дайте понять, что вы трофейная рыба, которая может достаться другому.

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

Также могут попросить назвать сумму в оффере конкурента. Сперва это может показаться некорректным, но для вас это явный плюс. Другого оффера по факту может и не быть. Но вы вольны ответить примерно так: “сумма в другом оффере примерно на 10-15% выше, чем сумма в моём резюме” (главное тут, не переиграйте самого себя). Таким образом можно обозначить разницу, не называя точную цифру. Но будьте осторожны. Сам интерес HR к другим предложениям - ещё не обещание, что вам дадут оффер или предложат зарплату больше. В любом случае, считаю правильным оставить потенциальному работодателю возможность предложить ценник повыше.

Что ещё посмотреть

Видео про собесы, в которых могут быть полезные советы. Они уже не учитывают часть нынешних реалий вроде использования ИИ, но с точки зрения этапов собеса и софтскиллов всё ещё полезны.

• Как написать Резюме | Что писать, если нету опыта
• Как пройти первое собеседование | Что отвечать и что НЕ Говорить
• Что говорить, если НЕ знаешь ответ
• Что не забыть спросить | Когда нужно послать интервьюера подальше
• Как улучшить свой Job Offer | Не только Деньгами

Выводы

Собеседования - это непростой процесс, особенно сегодня, и далеко не всегда ты проходишь, даже если хорошо знаешь своё дело. Иногда загвоздка в софтскиллах, иногда в хардскиллах, иногда просто в том, что ты недостаточно знаешь какую-то специфичную область. А иногда вы с компанией просто ищете разное, как получилось у меня с долей общения с заказчиками.

Live Admining оказался интересным форматом, куда более реалистичным, чем просто ответы на вопросы, но и более стрессовым. Он показывает ваши знания и способность ориентироваться в системе в реальном рабочем режиме, да и ещё когда за вашими действиями наблюдают.

Если вам интересно, в следующей части я расскажу про полный список тем и материалов, которые я себе составил и изучал/повторял при подготовке к собеседованиям - со ссылками на статьи, шпаргалки, видео, с комментариями про то, что стоит учить в первую очередь 🤔

👨‍💻Ну и…

Не забывайте про нашу телегу📱и чат 💬

Или может хотите стать соавтором? Тогда клик сюда🔗

Всех благ✌️

That should be it. If not, check the logs 🙂