Всем привет. Меня зовут Александр и более 10 лет своей профессиональной карьеры я провожу собеседования QA инженеров.

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

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

Также в этой статье рассмотрим пример резюме, которое мне прислали с вопросом: «Соответствует ли их представление об уровне senior с моим». На примере этого резюме я покажу, на что я обращаю внимание при скрининге резюме и по какому принципу я выбираю точки для прощупывания кандидатов.

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

Проблематика

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

Ключевые пункты в самом конце – помогут в составлении резюме и подготовят к прохождению собеседования.

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

И вот на рынке появляются сотни, если не тысячи вчерашних выпускников курсов, с одинаковыми резюме, одинаковыми заявленными скиллами, инструментами. Кто-то даже с опытом работы в IT.

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

Из каких этапов состоит собеседование

Во многих компаниях сегодня собеседование проводится в несколько этапов:

  1. Первичный обзвон кандидатов. Эдакий Handshake. На этом этапе узнают о вакансии/кандидате общую информацию и договариваются о более тесном общении. Как правило, никаких технических вопросов не обсуждается.

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

  3. Техническое собеседование – проверка заявленных в резюме умений и навыков, проверка технических навыков со стороны технических экспертов.

  4. Финальное интервью – итоговое собеседование, на котором присутствуют ответственные за принятие решений о найме.

В идеальном мире должно происходить следующее:

  1. На первичном обзвоне отсеиваются ребята, кому в принципе не интересна вакансия, компания, кто не ищет работу и т.д.

  2. На этапе интервью с HR отсеиваются ребята, которые фундаментально не подходят компании (запросы по ЗП, условия работы, профиль, софт скиллы и т.д.)

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

  4. На финальном интервью проводится итоговая проверка результатов предыдущих двух этапов и отсев на этом этапе должен быть минимальным.

На практике же я регулярно сталкиваюсь с ситуацией, что на последнем этапе отсеивается 90% кандидатов.

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

Как проходит техническое интервью в QA

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

Соответственно, возникает потребность ответа на 2 вопроса:

  1. Подходит ли кандидат?

  2. А как Кандидат 1 показал себя в сравнении с Кандидатом 2? Ведь обычно общение ведется с несколькими кандидатами, и из них выбираются наиболее подходящие.

Пункт (2) приводит нас к тому, что появляется формальный чеклист, или шаблон для проведения собеседования, по которому проходит общение со всеми кандидатами.

С одной стороны, эта шаблонность позволяет нормировать оценку кандидатов, с другой стороны – она создает ту самую предсказуемость собеседования и возможность «конвейерной подготовки» кадров, способных пройти собеседование.

Так из чего же состоит среднестатистическое техническое собеседование в компаниях, специализирующихся на web разработках?

  1. В первую очередь – это знакомство с кандидатом и его техническим опытом. Задаются общие вопросы по предыдущему опыту работы, используемым инструментам, классам решаемых задач. Целью этого этапа является сверка написанного в резюме с тем, что рассказывает кандидат, получение информации о личном вкладе кандидата в работу.

  2. Общие технические вопросы. По сути, это проверка теоретических знаний:

    1. Вопросы по теории тестирования, техникам тест дизайна

    2. Тестовая документация

    3. Вопросы о жизненном цикле бага

    4. SQL

    5. Автоматизация тестирования

  3. Практическая часть

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

На основании этой оценки принимается решение о приглашение кандидата на финальное интервью.

Финальное интервью

Финальное интервью проводят ответственные за принятие решений о найме. Как правило это руководитель отдела и/или директор по персоналу.

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

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

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

И вот мы подошли к ключевому вопросу – как же получается, что кандидаты, отлично прошедшие 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 инженера с их видением?
Я не могу ответить на этот вопрос без общения с человеком, однако вопросы выше наглядно указывают на точки, в которые я будут «тыкать» при общении и на основании чего я буду делать свои выводы.

Как увеличить конверсию на техническом интервью?

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

Для эффективного проведения технического интервью необходимо ответить на следующие вопросы:

  1. Какие навыки я ожидаю от кандидата? На основании этого выстраивать список общих вопросов.

  2. Насколько глубоко кандидат владеет знаниями? Для этого необходимо проанализировать резюме и выделить ключевые моменты, на основании которых будут делаться выводы

  3. Если стек кандидата не совпадает со стеком интервьюера/компании, как оценить уровень? Для этого можно давать абстрактный пример на любом языке, спрашивать, понятно ли, что делает код, при необходимости объяснить, и задавать фундаментальные вопросы по его оптимизации, архитектуре, скрытым дефектам на уровне логики и т.д.

  4. Как человек рассуждает? Для этого достаточно дать ему задачу с открытой дискуссией (например описываем ситуацию: мы добавляем товар в корзину, видим все нотификашки, но при переходе в корзину товара нет. Как будешь анализировать дефект?).

  5. Понимает ли кандидат разницу между тестированием разных типов приложений?

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

  • Мы ввели URL в адресную строку и нажали Enter. Что происходит между этим событием и открытием сайта?

  • В чем отличие между Web и Mobile тестированием?

  • Тестирование интервала значений

  • Бытовой кейс с фактом проблемной ситуации. Задача кандидата – описать, как он будет анализировать проблему. Отлично подходят кейсы, в которых ты сам упустил дефект

  • Тестирование страницы

Вопросы автоматизаторам:

  • Самая сложная задача, которую приходилось решать?

  • Какие бывают структуры данных? В чем отличие между статическими и динамическими структурами данных?

  • Как реализовать ожидание элемента на экране, время загрузки которого нам неизвестно?

  • Алгоритмическая задачка (желательно простая задача, в которой есть множество решений)

  • Кусок кода тестов на анализ

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

Советы соискателям

При составлении резюме старайтесь придерживаться определенных принципов:

  1. Навыки должны идти в порядке убывания. Самый сильный должен идти первым. Это касается и инструментов, языков программирования и т.д.

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

  3. Если есть достижения – пишите. Это характеризует вас как профессионала больше, чем список инструментов и должностных обязанностей.

  4. Придерживайтесь формулы XYZ для составления резюме:

    X - Чего я достиг

    Y - Как это измерялось

    Z - Что я для этого сделал

    Пример:

    Обычное резюме: занимался автоматизацией тестирования mobile

    XYZ подход: Повысил покрытие автотестами (X) с 15 до 75% и существенно повысил стабильность автотестов (Y), изменив архитектуру и подход к написанию автотестов.

  5. Первое впечатление очень важно. Большинство решений о приеме принимается в первые минуты общения.

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

Надеюсь, данная статья была вам полезна.

Коллегам - успехов в найме классных сотрудников!

Соискателям – надеюсь, моя статья поможет вам увидеть точки роста и сподвигнет вас к покорению новых высот!

Комментарии (31)


  1. KongEnGe
    00.00.0000 00:00
    +2

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


    1. lowride
      00.00.0000 00:00
      +1

      Вероятно, автор предполагает что нужно максимально отсеять неподходящих кандидатов, а на втором собеседовании, вероятно, уже другие стратегии.


    1. adalan Автор
      00.00.0000 00:00

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

      Данная статья скорее про то, как сэкономить время и себе, и кандидатам, чтобы не проходить через все этапы собеседования, чтобы не разочаровываться низким процентом найма на финале.


      1. ValeriiS
        00.00.0000 00:00

        Столько текста невпопад, чтобы в итоге написать про чуйку.

        Такой уровень современных HR, одна из причин "нехватки специалистов".

        Отсюда все эти вопросы уровня MIDDLE + на юниоров и стажистов с интернами.


    1. AllexIn
      00.00.0000 00:00

      Просто отсеивайте, пока не останется нужное вам количество.


      1. SanSanychSeva
        00.00.0000 00:00

        "будем отсеивать столько, сколько нужно!"


    1. SanSanychSeva
      00.00.0000 00:00
      +4

      Браво! Великолепный комментарий, но автор же из тестировщиков - вот и подход у него такой же: берем спеку (резюме) и тестируем заявленную функциональность. Увы, на выходе после такого тестировщика кандидатов будет вердикт - "данный кандидат не наврал в своем резюме про свои скилзы". Однако главный вопрос - справится ли он с ожидаемыми обязанностями останется не закрытым.

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

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


      1. KongEnGe
        00.00.0000 00:00
        +1

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

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


        1. SanSanychSeva
          00.00.0000 00:00

          Супер - как и в прошлый раз, радуюсь точности ваших формулировок. Осталось понять, что же делать с поиском работы на таком вот рынке труда сегодня? С уходом глобальных компаний, которые задавали планку, отечественный рекрутмент в непонятном состоянии. Даже архаизироваться до советского не получается, так как тогда кадры были в цене - подход другой. Забавно еще слышать про какие-то программы возврата ИТ специалистов - тут имеющихся не получается трудоустроить. Ну да, впрочем, программы-то тема бюджетная, а там другая логика.


    1. adalan Автор
      00.00.0000 00:00

      Попытаюсь формализовать свои критерии:

      Хард скиллы:

      1. Junior - знание + понимание теории, умение применить ее на практике. Если заявлены ЯП - знание базовых структур данных, умение написать простой код. Умение рассуждать.

      2. Middle - все, что junior + знание своей профильной предметной области, знание и понимание тех инструментов, с которыми работал. Системный подход к решению задач. Понимание внутренних процессов. Если заявлена автоматизация - умение читать и анализировать чужой код, понимание принципов работы инструментов. Алгоритмистика. Знание и умение применять архитектурные подходы. Базовые знания CI/CD

      3. Senior - Middle + глубокие знания своей предметной области, инструментов, эффективности их применения. Умение работать в условиях недостаточных вводных, учитывать при решении задач внешние факторы. Если заявлена автоматизация - знания тонкостей работы инструментов, Ci/CD, умение реализовать методы, спрятанные под капотом тест фреймворков.

      4. Lead - Senior + менеджерские качества, знания процессов, подходов к оптимизации работы команды, оценка и планирование. Умение декомпозировать задачи, оценивать риски.

      Софт скиллы:

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

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

      Если рассмотреть на примере, то, допустим, есть 3 кандидата:
      1. Супер харды, но большие вопросы по софтам

      2. Слабые харды (ниже требуемого минимума), но "рубаха-парень"

      3. Харды на грани, возможно даже чуть ниже минимума, но обучаем, широкий кругозор и хорошие софты.

      Из трех кандидатов я выберу кандидата (3). И ключевая причина - софты, кругозор и обучаемость.

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

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


  1. amkartashov
    00.00.0000 00:00

    На практике же я регулярно сталкиваюсь с ситуацией, что на последнем этапе отсеивается 90% кандидатов.

    Из статьи непонятно, решили ли вы у себя эту проблему. Какое соотношение вы получаете для своих собеседований? (процент отсеивания на последнем этапе).


    1. adalan Автор
      00.00.0000 00:00

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

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

      Но, справедливости ради, там была довольно узкая область и поток кандидатов в принципе был не такой большой, как в вебе.


  1. hostbest
    00.00.0000 00:00

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


    1. adalan Автор
      00.00.0000 00:00

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

      По вашему комментарию я приведу такой пример...

      В детстве мы часто во дворе играли в футбол, и капитаны набирали команды по принципу "драфта". То есть по очереди выбирали себе в команду игроков и общей массы.

      И задайте себе сами вопрос - если вы хотите победить, вы будете выбирать друзей, или лучших, исходя из ваших потребностей?

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

      Если ваши интересы пересекутся, то, с высокой долей вероятности, вас ждет успех.


  1. RussianTM
    00.00.0000 00:00

    Тоже провожу техническое собеседование.

    Иногда подключаюсь на этапе 0 - вместе с HR смотрим все отклики и подходящие резюме еще до первого созвона.
    Та самая незамысловатая "чуйка" работает и здесь, потому что иногда кандидаты пишут только набор тегов типа "C#, Docker, Selenium, InfluxDb, ELK" и больше ничего.
    HR может такое резюме оставить без внимания.


  1. Tatsianka
    00.00.0000 00:00

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


    1. adalan Автор
      00.00.0000 00:00

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

      Расскажите мне, пожалуйста, пример применение кросс-браузерного тестирования в мобильном приложении.

      Не кросс-платформенное тестирование, а именно кросс-браузерное. И не мобильной верстки, а именно приложения. Того, что в конечном счете попадает в маркет.


      1. Tatsianka
        00.00.0000 00:00
        +1

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

        • Большие вопросы к владению терминологией. То же Модульное тестирование (англ Unit test), которое присутствует на «ручных» проектах, и к которому в индустрии команда QA не имеет никакого отношения.


          Модульное тестирование в мануальном это один из уровней детализации:
          -модульное
          -интеграционное
          -системное

          И это если не брать автоматизацию. Так что вопросы к владению терминологией не к кандидату.



        1. fomka12
          00.00.0000 00:00

          Написал вам личное сообщение по этому комментарию, посмотрите пожалуйста


    1. Amstaff_ka
      00.00.0000 00:00
      +1

      Я тоже несколько удивилась, так как тестировала приложение для мобильного для разных браузеров. А ещё "

      Великолепным примером является простая задача: В программе есть поле ввода, которое принимает на вход значения от (-10; 10] . Необходимо протестировать это поле.

      Часть кандидатов предлагает просто перебрать все значения. Тогда я увеличиваю диапазон до миллионов."

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


    1. Sawich94
      00.00.0000 00:00

      Как мобильный тестировщик хочу уточнить, зачем "кросс-браузерное тестирование" в мобилках, да и в принципе как?
      Ведь даже если у нас фул веб, оно написано на js.

      Не берусь утверждать, но если вы имели ввиду тестирование веба на мобилках - это не тестирование мобильных приложений, поправьте если не прав.

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


  1. fomka12
    00.00.0000 00:00
    +5

    очень сомнительная статья. С самого начала автор делает заявление, что за 10 лет ни разу не ошибся, а это уже звоночек. В психологии в разных тестах (например, тест Айзенка о типе темперамента) есть вопросы, которые проверяют честность респондента. Один из них звучит примерно так: "ошибаетесь ли вы?". И если человек отвечает, что нет, то это однозначно вранье, потому что так просто не бывает. Это как если тестировщик скажет, что за 10 лет работы не пропустил ни одного бага.

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

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

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


    1. SanSanychSeva
      00.00.0000 00:00
      +3

      Да, мне тоже резанула такая самонадеянность,

      а также уверенность автора в том, что кто-то ему проводит этап номер 1 (предварительный обзвон всех кандидатов). Он даже не в курсе, что сегодня при конкурсах по 500+ человек на позицию (спасибо hh.ru за глобальную доступность всех позиций всем кандидатам !), это физически нереально, поэтому есть этап номер 0, когда либо бот, либо рекрутер-бот со списком шаблонных требований отсеивает по формальным критериям 90%+ аппликаций без любых форм контактов с кандидатами.

      Забавно при этом видеть жалобы на то, что у всех кандидатов стереотипные резюме - это не кандидаты одинаковы, а входной фильтр узкополостный! В этом плане уместнее делать случайную выборку менее 10% входных резюме, чем фильтровать по параметрам.

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


  1. Sawich94
    00.00.0000 00:00

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

    - Совет "про фактор недосказанности" пушка, хоть и не часто, но получается мелькнуть крутым опытом
    - И самое главное "Пишите так, чтобы вы могли аргументировать написанное", рассчитываю что соискатели обратят внимание.

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


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


  1. Mike-M
    00.00.0000 00:00

    От себя добавлю, что при составлении резюме старайтесь придерживаться определенных принципов:
    То есть предыдущие части статьи были написаны не Вами? :-)


    1. adalan Автор
      00.00.0000 00:00

      Подкол засчитан =)

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

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


  1. Boethiah
    00.00.0000 00:00
    +1

    Извечная проблема: не имеешь опыта работы с инструментами - не достоин вакансии:) Почему бы кандидату, который никогда не имел опыта в использовании Appium, но имеет опыт работы с другими инструментами автоматизации, не дать шанс показать себя на проекте? Ну или соискатель не имеет опыта работы, допустим, с Android studio, но ориентируется в программе - почему бы такому соискателю не дать шанс? Естественно, что прежде чем давать шансы, нужно оценить тулзовину, сложна ли она в освоении или нет.


    1. adalan Автор
      00.00.0000 00:00

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

      Особенно остро этот момент ощущается, когда ребята переходят из одной области в другую. Например из Embedded в Web. Знания инструментов нет, тонкостей работы с определенными аспектами тоже. И очень многие высококлассные специалисты получают отказы, потому что даже до джуна не дотягивают.

      И здесь я с вами полностью согласен - когда я собеседую кандидатов, мне вторично, с чем он работал. Для меня важно - понимает ли он, как решать ту или иную задачу. Инструмент освоить проще, нежели научиться думать.

      Возьмем пример из реального собеседования.

      У кандидата написано - кроссплатформенное тестирование. Задаю вопрос, что делал - отвечает, что запускал скрипт на win и *nix машине. Все.

      Но написано же кроссплатформенное тестирование, может действительно опыт был сильно ограниченный, но есть видение, как это в принципе происходит?

      Уточняем у кандидата, что за скрипт, что делал. И задаем дополнительный вопрос - как бы он протестировал работу определенной функциональности этого скрипта на разных платформах?

      И вот если кандидат не может ничего сказать, кроме как "запустить скрипт", то для меня это сигнал.

      Мы очень трепетно относимся к подобной строгости в IT. Как же так можно? Вы нелюди, не даете кандидатам проявить себя! Но давайте проведем параллель.

      Если у хирурга будет написано "опыт проведения операций на сердце", но на вопрос о том, что он делал, выяснится, что он подал зажим оперирующему хирургу. А на вопросы, как делается операция он не может ответить ничего, кроме как того, что пациента нужно разрезать, и обязательно нужно приготовить зажим, вы пойдете под нож к такому хирургу?

      Также многие забывают, что IT бывает разным, и требования в разных областях отличаются, цена ошибки также может сильно разниться.

      Раньше я работал в области разработки электроники. Цена ошибки - отзыв продукции и разорение компании.

      Затем была медицина. Думаю комментировать цену пропуска ошибки не стоит.

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

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


  1. ole325
    00.00.0000 00:00

    Все это хорошо в теории, но на практике никто не проверял, насколько хороши взятые и насколько плохие отсеянные кандидаты.

    Так же полезно разделять опыт и навыки.


  1. Seva_Morotskiy
    00.00.0000 00:00
    +1

    Достаточно спорного качества статья с технической точки зрения. Кроме того, местами пробивается неуважение к коллегам по цеху, что в наше время расценивается в профессиональном мире как "no-go".

    1) Статья из разряда "популярное творчество". Даются общие рекомендации без погружения в детали, нет плана на интервью, нет матрицы тематик, в рамках которого идет assessment QA-специалиста, приводимые live coding задания идут под маркой "Hello World!".

    В статье контент для HR-специалистов и социологов, а не инженеров. 

    2) Автор спрашивает почему во фреймворках "UIAutomator, XCTest и Espresso" не указаны языки.  Да потому что указывать, например, на чем пишутся тесты под Espresso - Kotlin или Java - смысла особо не имеет, ибо индустрия уже давно смотрит не знание конкретного языка программирования, а на общий уровень алгоритмической и инженерной подготовки специалиста. Язык программирования идет следом, и за карьеру software engineer может меняться много раз. Кроме того, этот пункт легко проверяется через ряд простейших заданий на интервью.

    3) Автор ссылается на несоответствие в мелочах в CV - модульное тестирование, "переделал с нуля", ищет связи в копипастах между проектами в части выполняемых обязанностей. Моя личная практика показывает, что даже "бледные" CV на входе не являются критерием профессионализма соискателя или индикатором отсутствия квалификации в этой области. Более того, были случаи, когда люди присылали очень посредственные CV, а потом отлично проходили собеседования и становились локомотивами целых направлений в компании. 

    Работает и наоборот - соискатели с великолепным CV c треском проваливались на собеседовании.


    4) Автор пишет, что "мне прислали резюме senior QA инженера с опытом работы 5 лет. Работает на «галере»."

    Посмотрел, где работает автор, и последние 5 мест его работы. Улыбнуло про "галеры". 


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


    1. adalan Автор
      00.00.0000 00:00

      Спасибо за комментарий.

      Написанные тезисы абсолютно верны, и я с ними полностью согласен.

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

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

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

      Также полностью согласен с тем, что содержание не отражает форму. Это истинная правда. Я лично неоднократно сталкивался с тем, что кандидат с бледным резюме оказывался неграненым алмазом. Были и ситуации ровно наоборот. Это правда жизни.