Всем привет. Меня зовут Александр и более 10 лет своей профессиональной карьеры я провожу собеседования QA инженеров.  За все время у меня не было промахов в найме по профессиональным качествам, только несколько несбывшихся ожиданий по росту сотрудников (например кандидат с бэкграундом в разработке не развился в автоматизации, а предпочел остаться в ручниках). В этой статье я хочу поделиться с вами информацией, как проходят интервью в QA, в чем я вижу современную проблему интервью в области тестирования, а также как я «вскрываю» кандидатов, достигая высоких показателей качества найма. Также в этой статье рассмотрим пример резюме, которое мне прислали с вопросом: «Соответствует ли их представление об уровне senior с моим». На примере этого резюме я покажу, на что я обращаю внимание при скрининге резюме и по какому принципу я выбираю точки для прощупывания кандидатов. Ну и, наконец, дам рекомендации соискателям о том, как и что стоит писать в резюме, чтобы не попасть в неловкую ситуацию на собеседовании. За последние несколько лет на рынке появилось множество школ, обещающих вход в IT без профильного образования и золотые горы «без регистрации и смс». Все, что для этого нужно – пройти 2-3х месячный курс, на котором тебе расскажут все про тестирование, научат автоматизации тестирования, помогут с составлением резюме, портфолио, и подготовят к прохождению собеседования.  Ключевые пункты в самом конце – помогут в составлении резюме и подготовят к прохождению собеседования. Это наводит нас на мысль, что при прохождении собеседования задаются шаблонные вопросы, зная ответы на которые, вы впечатлите интервьюера и получите предложение о работе. И вот на рынке появляются сотни, если не тысячи вчерашних выпускников курсов, с одинаковыми резюме, одинаковыми заявленными скиллами, инструментами. Кто-то даже с опытом работы в IT. Масла в огонь добавило изменение формата собеседований. Если раньше собеседование в IT состояло из 2 этапов: первичный скрининг со стороны HR и техническое собеседование, на котором присутствовало несколько технических экспертов из разных областей, то сегодня количество этапов выросло, а количество задействованных людей упало, что создало снежный ком сложностей в качественной оценке кандидатов. Во многих компаниях сегодня собеседование проводится в несколько этапов: Первичный обзвон кандидатов. Эдакий Handshake. На этом этапе узнают о вакансии/кандидате общую информацию и договариваются о более тесном общении. Как правило, никаких технических вопросов не обсуждается. Общение с HR. На этом этапе HR рассказывает о компании, проектах, внутренней жизни, а также общается на общие и профессиональные темы с кандидатом. Цель этого этапа – создать образ компании у кандидата, а также получить максимум информации для принятия решения о следующем этапе собеседования. Этот этап можно назвать созданием первичного образа с обеих сторон. Техническое собеседование – проверка заявленных в резюме умений и навыков, проверка технических навыков со стороны технических экспертов. Финальное интервью – итоговое собеседование, на котором присутствуют ответственные за принятие решений о найме. В идеальном мире должно происходить следующее:  На первичном обзвоне отсеиваются ребята, кому в принципе не интересна вакансия, компания, кто не ищет работу и т.д. На этапе интервью с HR отсеиваются ребята, которые фундаментально не подходят компании (запросы по ЗП, условия работы, профиль, софт скиллы и т.д.) На техническом интервью отсеиваются соискатели, которые не обладают необходимым уровнем знаний и навыков для работы в компании, либо к которым есть вопросы по перспективам развития.  На финальном интервью проводится итоговая проверка результатов предыдущих двух этапов и отсев на этом этапе должен быть минимальным. На практике же я регулярно сталкиваюсь с ситуацией, что на последнем этапе отсеивается 90% кандидатов. Подобная тенденция пугает. Она говорит о том, что этап технического собеседования не справляется с задачей и пропускает через себя буквально всех. Как упоминалось раньше, задача технического собеседования – выяснить, подходит ли кандидат под запросы компании. Здесь стоит обозначить, что может искаться специалист на конкретную позицию для закрытия конкретной задачи, в таком случае на собеседовании задаются точечные вопросы и крайне важны ответы именно на них. Но в большинстве случаев в компаниях есть запрос на специалиста и возможность провести ротацию внутри, то есть ищется кандидат, который будет способен справляться со среднестатистическими задачами.  Соответственно, возникает потребность ответа на 2 вопроса: Подходит ли кандидат? А как Кандидат 1 показал себя в сравнении с Кандидатом 2? Ведь обычно общение ведется с несколькими кандидатами, и из них выбираются наиболее подходящие.  Пункт (2) приводит нас к тому, что появляется формальный чеклист, или шаблон для проведения собеседования, по которому проходит общение со всеми кандидатами.  С одной стороны, эта шаблонность позволяет нормировать оценку кандидатов, с другой стороны – она создает ту самую предсказуемость собеседования и возможность «конвейерной подготовки» кадров, способных пройти собеседование. Так из чего же состоит среднестатистическое техническое собеседование в компаниях, специализирующихся на web разработках? В первую очередь – это знакомство с кандидатом и его техническим опытом. Задаются общие вопросы по предыдущему опыту работы, используемым инструментам, классам решаемых задач. Целью этого этапа является сверка написанного в резюме с тем, что рассказывает кандидат, получение информации о личном вкладе кандидата в работу.  Общие технические вопросы. По сути, это проверка теоретических знаний: Вопросы по теории тестирования, техникам тест дизайна Тестовая документация Вопросы о жизненном цикле бага SQL Автоматизация тестирования Практическая часть По итогу практической части появляется систематизированная оценка кандидата. Поскольку вопросы унифицированы, то и отчеты по кандидатам можно сравнивать друг с другом. На основании этой оценки принимается решение о приглашение кандидата на финальное интервью. Финальное интервью проводят ответственные за принятие решений о найме. Как правило это руководитель отдела и/или директор по персоналу.  Задача финального интервью – убедиться в корректности оценки кандидата на предыдущих этапах, соотнести запросы кандидата с его уровнем, а также получение информации для принятия решения о том, на какую именно позицию/проект лучше подойдет кандидат. Обычно на финале общаются на общие темы, выясняются мотивы и цели кандидата на ближайшее время, задаются более глубокие вопросы по его предыдущему опыту и техническим навыкам, а также может даться задача с открытой дискуссией, максимально приближенная к реалиям работы компании. И этой статьи бы не было, если бы не печальный факт: большая часть кандидатов не проходит финальное интервью. В итоге формальность превращается в настоящий разнос и шоковую терапию для кандидатов. И вот мы подошли к ключевому вопросу – как же получается, что кандидаты, отлично прошедшие 2 предыдущих этапа, которые показали теоретические знания, решили практические задачи, валятся на финале? Для начала обозначу вопросы, которые я ставлю перед собой при проведении любого интервью:    1.       Насколько кандидат приукрасил свое резюме? Рекомендации некоторых работодателей явно содержат призывы к приукрашиванию информации в резюме. И это можно понять, ведь если тебя не позвали на собеседование, то ты точно не получишь желанный оффер. В итоге компании подобными призывами сами подготовили почву для пускания пыли в глаза интервьюерам. Зная это, я выбираю из написанного в резюме наиболее интересные мне вопросы. Например: нагрузочное, кроссплатформенное тестирование. Цель – выяснить, перечислено ли в резюме все, что кандидат где-то видел/слышал, или же это имеет практическое подтверждение. Если кандидат отвечает на эти вопросы, я не буду углубляться в более простые темы. Однако, если кандидат валится, я начинаю нащупывать истинный уровень достоверности написанного. 2.       Насколько кандидат разбирается в том, что он указал в резюме? Этот пункт очень тесно связан с предыдущим. Я внимательно слушаю кандидата и задаю пару дополнительных вопросов, ответить на которые можно только если ты действительно работал с тем, о чем говоришь. Например, кандидат рассказывает про нагрузочное тестирование, и я задаю ему вопросы про инструменты, подходы, причины выбора того или иного подхода. Это нужно для того, чтобы понять, сможет ли кандидат решить аналогичную задачу в других условиях, выбрав правильный инструмент, учтя внешние факторы и условия, или же пойдет по проторенной дорожке, которая может быть тупиковой. 3.       Какой технический уровень и потенциал кандидата? В этой части я задаю вопросы кандидату по указанным в резюме навыкам, языкам программирования, инструментам, либо по его профилю работы. Например, кандидат работал в области создания продуктов, связанных с фото-видео, при этом занимал ведущую позицию. Я буду задавать ему вопросы про тонкости тестирования этих направлений, критерии оценки, способы анализа дефектов. Задам вопросы на понимание. Или же кандидат рассказывает про автоматизацию, свой путь в изучении программирования, пройденные курсы. В таком случае я могу спросить про типы и структуры данных, их различия. Попрошу решить простую алгоритмическую задачу. Могу спросить, как бы кандидат архитектурно решал задачу написания тестов на множество фич, у которых флоу пересекается на 80%. На данном этапе я получаю довольно подробную информацию о том, насколько кандидат глубоко погружается в ту проблематику, с которой работает, насколько у него развит кругозор, какими техническими навыками обладает. 4.       Насколько кандидат умеет применять теорию на практике? Умеет ли он выбирать из множества инструментов и подходов оптимальные? К этому моменту я знаю, что кандидат знает теорию, может даже ее объяснить. Однако есть разница между знанием теории и умением применить ее на практике. Для ответа на эти вопросы нужны задачи. И, чем она проще, тем более обширную информацию ты получаешь. Подойдет любая простая задача: В программе есть поле ввода, которое принимает на вход значения от (-10; 10] . Необходимо протестировать это поле.  Часть кандидатов предлагает просто перебрать все значения. Тогда я увеличиваю диапазон до миллионов. После ответа кандидата, независимо от сделанных предложений, я спрашиваю, может стоит что-то добавить, убрать, как-то оптимизировать решение. Это создание стрессовой ситуации, в которой часто приходится работать на практике (а все ли я проверил, ничего ли не упустил). И я оцениваю уверенность кандидата в том, что он только что сделал. Насколько он осознает свое решение и способен ли он на нем настоять. Другим примером задачи является задачи с открытым критерием приемки (например, программа работает с данными и должна отрабатывать за отведенное время).  5.       Какова мотивация и есть ли кадровые риски? Самая субъективная часть. Здесь я оцениваю невербалику, что и как говорится. Какие вопросы задает кандидат, как отвечает на мои вопросы. Строю причинно-следственные связи. Пример риска: кандидат занимается английским языком с репетитором. Уточняем его текущий уровень – кандидат говорит, что b1. Задается вопрос о цели изучения языка – в этот момент важна невербалика. Если кандидат начинает играть взглядом, подбирать слова, то это сигнал. Мы получаем кадровый риск в ближайшее время переезда кандидата зарубеж.  Так в чем же проблема? Проблема в том, что у большинства кандидатов не подтверждаются заявленные в резюме навыки, отсутствует понимание областей, с которыми они работают, отсутствует умение пользоваться теорией на практике. По сути, кандидаты умеют отвечать на теоретические вопросы, умеют решать типовые практические задачи, знают типовые инструменты, могут рассказать про их использования на учебных задачах, но стоит сделать шаг в сторону и все, кандидат теряется и не знает, что и как делать. Из практики: собеседовал кандидата, у которого были заявлены языки программирования, который старается всегда разобраться в том, что и как работает. Занимается самообразованием, решает задачи, проходит курсы по программированию. Является ведущим автоматизатором. Рассказывал про инструменты, какой лучше и т.д. По факту не знаком с типами и структурами данных в профильном языке, не смог перемножить числа в цикле. Не видит логических проблем в коде.  Что имеем по итогу? По итогу мы имеем множество часов потраченного времени кандидата на все этапы интервью, потраченное время руководителей и чувство безнадежности в поиске подходящих кандидатов. Ведь пока ты общаешься с тем, кто тебе не подходит, нужный кандидат может собеседоваться в другое место и успешно быть принятым туда на работу.  Так как же нам повысить уровень кандидатов, которых приглашаем на собеседование и как не доводить ситуацию до столько низкой конверсии на финальном этапе? Рассмотрим на примере резюме, которое мне попало через адресную рассылку с вопросом «соответствует ли их видение senior QA инженера моему»? Итак, мне прислали резюме senior QA инженера с опытом работы 5 лет. Работает на «галере» (это как плюс, т.к. большое количество используемых инструментов, кругозор, так и потенциальный риск в виде глубины погружения в предметную область). Довольно продолжительный срок работы и за это время я ожидаю увидеть определенный рост сотрудника по ходу профессиональной карьеры. Данные будут максимально обезличены. Также я не буду приводить сюда все данные из резюме, поскольку оно довольно объемное. Буду оперировать ключевыми тезисами и аспектами, на которые я обращаю внимание. Для начала посмотрим на шапку: Инженер QA с огромным опытом тестирования мобильных приложений, настольных приложений и веб-приложений. В своей работе в основном использовал ручное тестирование, также был QA инженером по автоматизации тестирования в некоторых проектах. В будущем хотел бы работать с Selenium и Appium. Мне нравится QA-тестирование, есть большое желание улучшать свои навыки, особенно в тестировании. Уровень английского позволяет проходить технические собеседования и работать в международной команде разработчиков. Резюмируем: у кандидата опыт работы с web, mobile и desktop, ручник. Хочет развиваться в автоматизацию. Отдельно заявлены навыки автотестов на JS и тестирование клиент-серверных приложений. Дальше представлена табличка компетенций по годам. Я сразу выделил пункты, на которые я буду дальше акцентировать внимание. Видим, что у кандидата опыт работы 5 лет, и все эти 5 лет он занимался планированием тестирования, выбором инструментов тестирования и тест анализом. Это сразу пункты на глубокие вопросы, т.к. я сильно сомневаюсь, что junior QA инженер занимается подобными лидовскими задачами. Смотрим в колонку инструментов и технологий и видим, что указаны 3 нативных инструмента автоматизации тестирования мобильных приложений: UIAutomator, XCTest и Espresso, выше заявлено желание развиваться в Appium, который тут не указан и опыта работы с которым у кандидата нет. Добавляем в копилку вопросы - какие задачи решал, почему хочет развиваться в Appium? Спускаемся в опыт. На последнем проекте работает 2 года. Среди обязанностей – автоматизация тестирования (при этом указано 2 фреймворка – CodeceptJS и PlayWright), разные виды тестирования (среди прочего и модульное тестирование), а также «расширение использования в технологиях автоматизации». Но мы помним, что выше нам представляются как ручник, который хочет развиваться в Selenium.  Среди достижений указано, что «с нуля переделал процесс тестирования в команде, переделал все тестовые артефакты, написал несколько сотен E2E тестов», также перечислены другие достижения в автоматизации. Несколькими проектами ниже снова видим тот же самый проект, и его обязанности – выбор программы и методов тестирования, управление задачами и т.д. Между двумя появлениями этого проекта указан срок меньше года. То есть написано, что он по сути сначала выстроил процесс, который потом сам же и переделал. Добавляем в копилку вопросов - что было переделано, причины. Также обращаем внимание, что автоматизация не заявлена. Смотрим, что же было между двумя появлениями на проекте в области автоматизации? А там не было ничего. Обводим в кружок вопросы про автоматизацию и Selenium. Добавляем вопросы, почему выбраны именно те инструменты, которые указаны? Смотрим резюме дальше и видим, что на каждом проекте 80% обязанностей – копипаста. Более того, на проектах, где в инструментах указаны Android Studio, UIAutomator, Espresso присутствует также «кроссбраузерное тестирование», которое обычно ассоциируется с web-приложениям.  Подмечаем, что в доброй половине мобильных проектов заявлен ADB и больше ничего из инструментов работы с мобилкой. На этом этапе уже можно сделать определенные выводы и обозначить для себя отправные точки для собеседования: Вопросы по терминологии. Необходимо синхронизироваться по терминологии, чтобы правильно друг друга понимать. На примере кандидата: Модульное тестирование (англ Unit test), которое присутствует на «ручных» проектах - что имеется ввиду, как выполнялось? Что и по какой причине «с нуля переделывал» за собой Отличия между тестированием мобильных и Web приложений Инструментарий мобильного тестирования - что делал с помощью заявленных инструментов, какие задачи решал Автоматизация веб - вопросы по выбору инструментов, почему применяет одно, а хочет развиваться в другом? Почему заявляет о себе как о ручнике, если больше половины карьеры отмечено, что занимается автоматизацией? Вспоминаем, что мне задали вопрос, совпадает ли мое видение senior QA инженера с их видением? Я не могу ответить на этот вопрос без общения с человеком, однако вопросы выше наглядно указывают на точки, в которые я будут «тыкать» при общении и на основании чего я буду делать свои выводы. Из примера выше можно увидеть, что помимо самого собеседования крайне важным является этап подготовки. Безусловно, шаблонизация полезна, однако задайте себе вопрос – вы хотите оценивать начинающих специалистов и экспертов с огромным опытом по одной и той же шкале? Для эффективного проведения технического интервью необходимо ответить на следующие вопросы: Какие навыки я ожидаю от кандидата? На основании этого выстраивать список общих вопросов. Насколько глубоко кандидат владеет знаниями? Для этого необходимо проанализировать резюме и выделить ключевые моменты, на основании которых будут делаться выводы Если стек кандидата не совпадает со стеком интервьюера/компании, как оценить уровень? Для этого можно давать абстрактный пример на любом языке, спрашивать, понятно ли, что делает код, при необходимости объяснить, и задавать фундаментальные вопросы по его оптимизации, архитектуре, скрытым дефектам на уровне логики и т.д. Как человек рассуждает? Для этого достаточно дать ему задачу с открытой дискуссией (например описываем ситуацию: мы добавляем товар в корзину, видим все нотификашки, но при переходе в корзину товара нет. Как будешь анализировать дефект?). Понимает ли кандидат разницу между тестированием разных типов приложений? Примеры вопросов, на основании которых можно получить много полезной информации о кандидатах: Мы ввели URL в адресную строку и нажали Enter. Что происходит между этим событием и открытием сайта? В чем отличие между Web и Mobile тестированием? Тестирование интервала значений Бытовой кейс с фактом проблемной ситуации. Задача кандидата – описать, как он будет анализировать проблему. Отлично подходят кейсы, в которых ты сам упустил дефект Тестирование страницы  Вопросы автоматизаторам: Самая сложная задача, которую приходилось решать? Какие бывают структуры данных? В чем отличие между статическими и динамическими структурами данных? Как реализовать ожидание элемента на экране, время загрузки которого нам неизвестно? Алгоритмическая задачка (желательно простая задача, в которой есть множество решений) Кусок кода тестов на анализ Цель всех этих вопросов – получить более глубокое представление о кандидате, а также быть более уверенным в выводах. Нужно сходить с проторенной дорожки теоретических вопросов и смещаться в практическую плоскость. Ведь, по сути, не сильно важно, знаю ли я названия всех техник тест дизайна, их определения и т.д., гораздо важнее то, умею ли я применять их на практике, умею ли я рассуждать, погружаться в новую предметную область, понимаю ли я свою предметную область. И, получив ответы на эти вопросы, я могу с высокой уверенностью выбрать действительно тех, кто мне подойдет и с кем можно не просто закрывать задачи тестирования проектов, но и совершать качественный рывок вперед, который выгоден всем. При составлении резюме старайтесь придерживаться определенных принципов: Навыки должны идти в порядке убывания. Самый сильный должен идти первым. Это касается и инструментов, языков программирования и т.д. Пишите так, чтобы вы могли аргументировать написанное. Если я на несколько подряд идущих вопросов не получу ответ, то, как собеседующий, я буду разочарован, и будет очень сложно исправить положение за оставшееся время. Если есть достижения – пишите. Это характеризует вас как профессионала больше, чем список инструментов и должностных обязанностей. Придерживайтесь формулы XYZ для составления резюме: X - Чего я достиг Y - Как это измерялось Z - Что я для этого сделал Пример: Обычное резюме: занимался автоматизацией тестирования mobile XYZ подход: Повысил покрытие автотестами (X) с 15 до 75% и существенно повысил стабильность автотестов (Y), изменив архитектуру и подход к написанию автотестов (Z).  Первое впечатление очень важно. Большинство решений о приеме принимается в первые минуты общения. Помните, что QA инженер это не про тыкать кнопочки и заводить баги. Это гораздо шире. Расширяйте кругозор, ставьте себя на место пользователей, разработчиков, заказчиков. Чем больше вы знаете об окружающем мире, тем вы ценнее как специалист и тем выше вы поднимаете себе планку роста.  Надеюсь, данная статья была вам полезна. Коллегам - успехов в найме классных сотрудников! Соискателям – надеюсь, моя статья поможет вам увидеть точки роста и сподвигнет вас к покорению новых высот!  Руководитель отдела тестирования