Собеседование "по другую сторону": опыт поиска Junior QA Engineer

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

Но не каждый сидел с другой стороны, в качестве интервьюера.

Мне вот посчастливилось принять участие в подборе помощника для себя. Попробую поделиться опытом. Эта статья может быть полезна как для ребят, готовящихся к своему первому собеседованию на Junior QA Engineer, так и тем, у кого это собеседование будет первым в качестве интервьюера по технической части.

Итак, погнали.

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

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

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

Requirements:

• Previous work experience as a QA Engineer (0,5+ years)
• Solid understanding of testing principles
• Familiarity with Agile methodologies and agile testing approaches
• Experience in writing and executing test cases
• Experience with TestLink, Jira, Git
• An ability to learn quickly
• Analytical skills
• Good communication skills
• Desire to learn QA automation processes
• Basic knowledge of Python or/and Node.JS is a plus
• Basic knowledge of MVC and REST is a plus
• Basic knowledge of RTB mechanisms is a plus
• Intermediate English IS A MUST

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

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

Скрининг - процесс отбора кандидатов на следующий этап - контактный звонок.

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

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

1. 95% отправителей резюме - выпускники курсов по тестированию.

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

Этому есть две возможных причины.

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

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

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

2. Парим урезанный ISTQB Foundation(и это при оптимистическом сценарии, а есть еще и пессимистический, когда на занятиях пересказывают Савина)

3. Тратим по пол часа на каждого студента, составляя ему резюме, на которое клюнут.

....

4. PROFIT!!11


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


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

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

- Гит? Ой, да когда-то что-то читал, но не особо помню, что там. Если надо - выучу.

- CSS? Ну каскадная таблица стилей, да. HTML там, верстка.

- Selenium? Ну я знаю, что это такая штука, чтобы автотесты записывать. Ну нам рассказывали о нем, но я не работал.

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


3. Умение читать техническую документацию - это еще не Fluent English.

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

Еще больнее становится, когда находишь грамматические ошибки в резюме, составленном на английском, с указанным в нём уровне Upper-Intermediate/Advanced.


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

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


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


1. Почему именно тестирование?

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

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


2. Кем себя видите в тестировании? Техническим специалистом или на руководящей позиции через тестирование, как отправную точку?

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

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

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


3. Есть ли найденный вами дефект, которым вы гордитесь больше всего?

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

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


4. Какие профессиональные ресурсы читаете? Откуда берете знания?

Большинство опрошенных называют в кач-ве опорных точек Святую Троицу: Савина, Канера, Калбертсона.

Некоторые говорят про ДОУ и хабр. И(сюрприз-сюрприз) о школе Портнова.

Достойный кандидат упомянет хотя бы пару специализированных форумов, пару блогов(Дж. Баха, Google Testing Blog), расскажет о книге Уиттакера. Укажет на конференции, которые посещал, или записи которых смотрел. Вспомнит о Руколь. Заикнется о Stack Exchange.

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


5. REST API, коды ответов cервера по протоколу HTTP.

Здесь никакого рокет-сайенса не ждал. Хотелось просто услышать определение о том, что такое REST, и человеческое описание основных, но непопулярных кодов ответов(403, 502, 302, 204). Работая с веб-сервисами, часто невозможно найти root cause возникшей проблемы без обращения к консоли или анализу запроса и ответа на него, пришедшего от сервера.

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


6. Начальный тег HTML-документа, сокрытие элемента средствами CSS.

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


7. Есть удаленный репозиторий по ссылке http://1.2.6.192/test.git. Какие шаги нужно выполнить для того, чтобы подтянуть этот репозиторий локально?

Тут всё просто. Проверяем умение человека работать с системами контроля версий. Как ни странно, этот вопрос тоже оказался неподъемным для большинства кандидатов.

Какого ответа я жду:

1. Проверить, установлен ли git локально(мы же тестировщики, помните?)

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

3. Сделать git init/checkout/pull ИЛИ git clone для репозитория, если предыдущие два шага не выявили проблем.

К сожалению, такого ответа не дал никто.


8. Вопросы по техникам тестирования, указанным в резюме.

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

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

И да, лично я ненавижу регрессию. =)


9. У вас есть доступ к серверу на Linux без графической оболочки. Вам нужно собрать максимум информации о нём. Какими командами будете пользоваться?

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


И мы плавно переходим к изюминке каждого собеседования.


Практическое задание.

Практическое задание на эту позицию формировалось с нуля. За основу брался так любимый всеми интервьюерами на позицию QA Engineer-ов калькулятор.


Вот, как он выглядел:

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


И, собственно, дефекты, которые должны были найти соискатели.


1. Лишняя буква "l" в слове "Wellcome".

2. Недостающая буква "r" в слове "corect" внутри окна подтверждения.

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


3. Отсутствие кнопок "0", "С", "+/-" и других управляющих элементов функционала.

4. Неправильное расположение цифровых кнопок(Расположены инвертированно, относительно стандартной раскладке для калькулятора).

5. Отсутствие символа "."


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

С дефектом под номером 5 связан отдельный вопрос: "Каким образом возможно видеть подобную цепочку действий, если точка в функционале отсутствует?". Задавался он для того, чтобы понять, на каком уровне люди взаимодействуют с продуктом и исследуют ли они его достаточно, чтобы делать выводы. А ответ был очень простым - точку очень легко можно ввести с клавиатуры.


6. Неподходящее обозначение кнопки для умножения(mul).

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


7. Проблемы с расположением элементов.


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


8. Неочевидные решения по функционалу элементов.


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


9. Инвертированное положение кнопок Yes и No в окне подтверждения.


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


Наиболее запомнившиеся мне кандидаты были готовы завести от 10 до 18(рекорд) баг-репортов.

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


Резюмируя...

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


1. Тестирование - это не просто. И с этим надо смириться. Оно не проще разработки, а местами даже сложнее. Помните это.


2. Курсы - не панацея и не самый короткий путь в индустрию. Только желание + упорство + практика + уверенность в себе = успех на собеседовании.


3. Будьте готовы отвечать кровью за каждую написанную в резюме строчку.


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


5. Развивайтесь. Сколько бы вы не прочитали. этого всегда будет мало. Всегда. Не останавливайтесь и не зацикливайтесь на одном подходе, одном ресурсе, одной методологии.


6. Если вы действительно всерьёз настроены на то, чтобы получать хорошие офферы - займитесь английским и Linux'ом. А если еще и разберетесь с основными принципами работы мобильных ОС - цены вам не будет.

7. Практикуйтесь. Всегда и везде. Набивайте руку на всём, на чём только можно. И поворачивайте мозги(Савин, привет!) в сторону тестирования. Это неоценимый скилл.


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



→ Credits to
Собеседование "по другую сторону": опыт поиска Junior QA Engineer