Как проходит техническое интервью на позицию облачного бэкенд разработчика

Рассказывает Андрей Корявченко, Team Leader, Product Engineering, ABBYY

Несмотря на кризис ИТ-специалисты по-прежнему востребованы. По данным Минэкономразвития РФ, в апреле-мае порядка 40% вакансий пришлось именно на ИТ-специалистов. Я занимаюсь backend-частью нового cloud-native продукта ABBYY, и найм в нашу команду не прекращался. Только за последние пару месяцев я провел десятки технических собеседований с кандидатами на должности senior-разработчиков. Почти все из них совершают типичные ошибки, поэтому я решил подробно рассказать, как проходит такое интервью. Уверен, что во многих других ИТ-компаниях процесс похожий, поэтому информация будет полезна широкому кругу программистов.

Первый этап любого отбора – это собеседование с HR-менеджером. Коллеги проверяют соответствие кандидатов формальным требованиям, их базовые soft skills, оценивают мотивацию и уточняют, какие задачи были бы интересны соискателям. Как правило, у нас есть несколько вакансий со схожими требованиям в разных отделах. Поэтому на собеседовании важно понять, что именно интересно кандидату, и рассказать ему про работу в компании, особенности проекта, команды, структуры и стека. После этого я, как нанимающий менеджер, получаю небольшую сводку о кандидате и его резюме. Мы смотрим на то, чтобы у кандидата был релевантный опыт. Важно, чтобы кандидат понимал, что такое облака, кластерные технологии. Также обращаем внимание на то, как часто он меняет работу. Если каждые полгода он переходит в другую компанию, нам такой кандидат не подойдет. Почему? Фактически сотрудник начнет приносить нам пользу только через 2-3 месяца после адаптации и погружения в процессы, поэтому брать таких кандидатов рискованно.

На этапе, описанном выше, мы отказываем только совсем небольшой части отобранных разработчиков. Следующий этап – это техническое собеседование со мной и при необходимости руководителем разработки продукта. В новых реалиях интервью проходит исключительно в онлайне. Это немного увеличивает время на выявление soft skills кандидата, но в целом не препятствует качеству отбора. Мы просим кандидатов использовать камеру. У нас был опыт общения и без камеры, но он оказался негативным, поэтому обязательно используйте видеосвязь и заранее проверяйте качество интернет-соединения.

Техническое интервью состоит из 3 частей

Часть первая

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

Пример задачи: есть агрегаторы новостей, мы предлагаем простейшие требования: количество источников, периодичность опрашивания и формирования неких RSS feeds. Нужно примерно расписать, какие сервисы и службы понадобятся. По желанию можно нарисовать схему. Так мы выявляем, знает ли кандидат, что такое очередь, надежность, как обеспечить устойчивость к сбоям, понимает ли он, что нельзя проектировать систему из расчёта, что ничего не может пойти не по плану, и что система должна нормально себя вести на негативных сценариях. Мы специально не делаем каких-то формальных описаний с точно выверенными формулировками, так как для нас один из главных навыков разработчика – это умение задавать уточняющие вопросы. В моей команде нет такого, что все задачи решаются согласно строгому алгоритму, которому нужно следовать. Кроме того, как правило, примерно половина задач связана с исследованиями. Нужно смотреть, как можно реализовать решение, какие готовые варианты существуют, какие есть альтернативы. Когда кандидат уже более-менее описал схему, можно задавать вопросы по деталям. Я, например, часто спрашиваю про REST API: как он должен выглядеть, какие нужны методы? Тут уже выявляют знания конкретных кластерных и облачных технологий, пока без особой привязки к .NET.

Кейс не предполагает длительной подготовки. Нам важно видеть, как кандидат думает и рассуждает. При этом, если кейс вызывает явные затруднения, мы задаем наводящие вопросы, даем подсказки.

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

Из областей спрашиваем про:

• ASP.NET с уклоном в версию ASP.NET Core;
• роутинг в ASP.NET и все, что с ним связано;
• middleware: для чего они нужны и как используются;
• новая конфигурация Appsettings.json и как с ней работать;
• асинхронность.

Такие вопросы подразумевают, что у кандидата больше знаний, чем в обзорной статье из интернета. То есть, как примерно устроено async/await, как это обрабатывает компилятор, что такое контекст синхронизации. Если кандидат с асинками не сталкивался, спрашиваю более классические вещи: что такое пул потоков, какие бывают примитивы синхронизации, как они работают, что такое дедлоки, гонки. Поскольку у нас все асинхронное, эти моменты очень важны для нас. Также спрашиваю про использование баз данных. Стандартного списка вопросов у нас нет – отталкиваемся от того, что умеет кандидат. Цель этой части – выяснить, действительно ли потенциальный сотрудник работал с .NET, и насколько глубоко.

На этом этапе часто выявляются два не подходящих нам типа кандидатов. Первый – человек работал в каком-то узком технологическом секторе и за его пределами ничего не знает. У нас ему будет тяжело, ведь задачи в нашем проекте разнообразны и однотипной работы почти нет. Второй тип кандидатов – тот, который на протяжении некоторого времени работает на руководящей должности и не пишет код. У нас надо уметь писать код на любой позиции до Team Leader включительно. Когда у меня есть время, я тоже пишу небольшие куски кода. Наш конечный продукт – это все же код для компаний и организаций во всем мире, и нам важно делать его качественным.

Часть вторая

В следующей части мы даем собеседнику две задачки на знание алгоритмов и умение рассуждать. В США компании FAANG (Facebook, Apple, Amazon, Netflix, Google) очень любят такие «головоломки», чтобы проверять умение разработчика применять алгоритмы в нестандартных ситуациях. Хотя мы и стараемся делать их не слишком сложными, честно говоря, за все время не было никого, кто решил бы обе задачи без подсказок. Пример такой задачи, которая на первый взгляд кажется несложной: есть массив байт размером около 1 млрд, максимально быстро подсчитайте количество единичных бит в этом массиве.

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

Часть третья

После задач мы снова отвечаем на вопросы кандидата. Иногда задаем ему несколько «жизненных» вопросов.

Все интервью укладывается в 1,5 часа.

Что касается soft skills, мы не проверяем их отдельно, но обращаем на них внимание в процессе собеседования. Доказано, что успех проекта напрямую коррелирует с показателями эмоционального интеллекта сотрудников, поэтому умение работать в команде зачастую важнее технических навыков. Если во время интервью кандидат сразу не понимает условие задачи, не может объяснить, что он придумал, замыкается, не любит озвучивать ход своих мыслей, это не добавит ему плюсов.

Советы

• Не воспринимайте техническое интервью как экзамен в институте. Это живое общение – не бойтесь что-то уточнить. Часто бывает так, что мы формулируем во время интервью задачу, и кандидат сразу бросается ее решать. Лучше остановиться, подумать, задать уточняющие вопросы. Для этого мы специально оставляем какие-то неясные моменты. Не торопитесь.
• Если вы чего-то не знаете, лучше честно признайтесь – это нормально. Всего знать невозможно. У нас был кандидат, который активно уходил от всех вопросов, ответы на которые он не знал. Это негативно отразилось на общем результате интервью. Не бойтесь быть честными.
• Продемонстрируйте ваше понимание темы, а не заученную теорию. В архитектурных задачах, например, нет единственного правильного решения – их бесконечное множество. Важно не рисовать идеальную схему, а понимать, что это такое, как это работает и почему это нужно сделать так, а не иначе. Часто бывает, что люди рисуют отличную рабочую схему, но, когда начинаешь спрашивать о деталях, они не могут дать внятный ответ. Не зубрите теорию.

Единственный способ подготовиться к техническому интервью – работать и вникать в различные задачи. Если ваша команда готовила какое-то решение, а вы работали только над его небольшим куском, который слабо связан с остальными частями решения, скорее всего, с технической частью на интервью все будет не очень хорошо. Это касается разработчиков уровня senior в первую очередь. У нас это специалисты с опытом от 5-6 лет. Причем опыт может быть разным: к нам приходят как специалисты из стартапов, так и из крупных компаний. Главное – не бояться разбираться в процессах, пробовать новое, уметь видеть общую картину. Тогда все обязательно получится!

После успешного прохождения технического собеседования кандидаты также общаются с нашим CTO. Но это уже совсем другая история ?