10 типичных «софтовых» ошибок на собеседовании

Российский рынок труда для IT-специалистов вновь оживился. Мне регулярно приходится собеседовать кандидатов в команду «Иннотех». За сотни проведённых интервью скопился список типичных ошибок на пересечении hard и soft skills, которые чаще всего допускают претенденты на lead-позиции. Их исправление повысит шансы на получение желаемой должности.

1. Нет ответа на конкретный вопрос

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

Рассмотрим реальный пример вопроса системному аналитику:

Вопрос: расскажите, для каких классов задач, на ваш взгляд, стоит применять асинхронные коммуникации и message-брокеры?

Ответ: асинхронный транспорт позволяет нам не ждать результата выполнения интеграционного запроса в рамках основного потока. А очереди на RabbitMQ мы активно применяли в одном из проектов, где задачи — бэктесты торговых стратегий — могли выполняться часами и даже сутками.

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

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

Вывод: без навыка чётко ставить вопросы и давать чёткие ответы будет сложно построить продуктивную коммуникацию с другими членами команды.

2. А порассуждать?

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

Рассмотрим такой вопрос: как вы думаете, системному аналитику стоит проектировать API своего сервиса или лучше оставить это полностью на откуп разработчикам?

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

От более опытных специалистов, разумеется, ожидается формулирование чётких аргументов по пунктам с готовностью защитить каждый. Ну и 80-й lvl достигается, когда кандидат может защитить несколько точек зрения, разграничив их по конкретным классам задач и процессам.

Вывод: не стоит пренебрегать возможностью продемонстрировать и навыки логического мышления, и умение аргументированно защищать свою позицию. До собеседования можно потренироваться в дебатах с коллегами по цеху или перед зеркалом. Кстати, в «Иннотех» уже проходили дебаты по теме «Разделение на PO и аналитика оправдано».

3. Нечёткое позиционирование

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

Пример хорошего ответа: последние 5 лет работал в телекоме на ведущей позиции, поэтому в этом домене однозначно senior, а вот в банкинге опыта ранее не было, поэтому скорее middle/middle+.

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

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

4. Шаблонная мотивация

Мотивация к работе — один и ключевых «софтовых» признаков, на базе которых принимается решение о кандидате. Все мы работаем за деньги, и это нормально. Разумеется, возможна ситуация, когда, кроме финансового фактора, кандидата не интересует ничего другого, однако чаще всего в нашей сфере это не совсем так.

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

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

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

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

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

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

5. Обилие негатива

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

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

Для позиций senior/lead обязательно задаём вопросы «А что вы сделали, чтобы исправить ситуацию?», «Обсуждали ли проблему с руководством?», «Предлагали ли свои решения?». Если ответы неконкретные, то весьма вероятно, что на новом месте сотрудник будет так же накапливать в себе негатив и рано или поздно «взорвётся» и уйдёт.

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

6. Книжная и не очень лексика

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

Пример: применив кэш второго уровня, мы получили прирост производительности запросов к базе на 30–40%.

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

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

Пример ответа на вопрос (далее цитаты из статьи на wiki): REST — архитектурный стиль взаимодействия компонентов распределённого приложения в сети… REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиасистемы…

Такая лексика в устной речи наводит на мысль, что ответ был заучен или читается с той самой статьи на экране. Более того, термин «гипермедиасистема» так и просится, чтобы в разговорной речи убрать пресловутую «гипермедиа».

Вывод: здорово владеть профессиональной терминологией и применять её, но не менее важно сохранять диалог живым, не перегружая его книжной лексикой.

7. Непонимание своей миссии

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

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

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

И вроде бы явно не глупость и во многом соответствует действительности, только здесь опять же смотрим пункт №1. Мост между заказчиком и командой разработки — это не только архитектор, но и бизнес-аналитик, и руководитель проекта, и product owner, а вот задачи у каждого свои. При этом, разумеется, нет никаких сомнений в том, что общее представление о своём назначении имеется и у джуна, и у лида.

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

8. Нежелание работать с документацией

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

Стартап из классической команды двух пицц может спокойно расти и развиваться годами без единого ТЗ. Но даже весьма средних размеров банк не обойдётся без документации. Поэтому, когда на собеседовании кандидат явно демонстрирует нежелание работать с документами и артефактами, это ясно даёт понять, что если всё же придётся с ними столкнуться, то работа будет вестись спустя рукава, а ещё и демотивировать. Причём это будет касаться не только аналитиков и технических писателей, но и разработчиков, QA и других.

Пример с диалогом на позицию старшего QA:

— Расскажите, каким образом, на ваш взгляд, лучше вести учёт тест-кейсов в интеграционном проекте в банке.

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

Разумеется, здесь можно и нужно поспорить, так как отсутствие документации по тестовым планам и сценариям может привести на проекте к массе проблем: bus-фактор ключевых QA, сложный и долгий процесс передачи знаний новому сотруднику, невозможность эффективной автоматизации тестирования и так далее. Но самое главное про кандидата в этом ответе уже стало понятно: раз он сам не любит работу с документацией, то тестирование сможет построить только в команде из 2–3 человек, но это не будет масштабируемой и системной организацией процессов.

Вывод: в собеседованиях любого типа компаниях больше начинающего стартапа стоит быть готовым к вопросам о документации. Противники её ведения имеют существенный риск не стать team player.

9. Незнание хороших и плохих процессов

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

Реализации модных Scrum и Kanban могут сильно различаться между компаниями. На проектных интервью мы регулярно спрашиваем, по каким процессам кандидат работал ранее, насколько они были качественными, как их можно было бы улучшить.

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

Диалог с разработчиком уровня middle+/senior:

— Вы упоминали о том, что в текущем проекте у вас накапливается много техдолга, на который никогда не было времени, в результате чего он рос как снежный ком. Как бы вы предложили решить этот вопрос?

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

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

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

10. Неискренность

Общаясь с аналитиком, архитектором, разработчиком, мы всегда так или иначе примеряем на себя возможность работать с ним в команде. Поэтому даже случайно продемонстрированные кандидатом soft skills будут ожидаться от него и в будущей работе.

Чем более непонятным для собеседующего остаётся кандидат после проектного интервью, тем больше будет сомнений в пользу офера. Любая скрытность, наигранность, неискренность, фальшь, уход от ответа будут заведомо трактоваться не в его пользу.

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

What’s next

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

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