За прошедшие два года работы на фрилансе мне довелось пройти множество собеседований в качестве кандидата, а также проинтервьюировать достаточно людей на свои два пет-проекта и в команду на текущую работу. И по моим личным ощущениям – 99,99% типовых технических собеседований на тестировщика НЕ РЕШАЮТ поставленную задачу: нанять компетентного человека на проект, который сработается с командой и останется надолго.  

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

• как человек сможет вписаться в команду?

• насколько он исполнителен, ответственен и внимателен к деталям?

• совпадает ли его темп и режим работы с принятыми у нас?

• действительно ли он обладает навыками и компетенциями, заявленными в CV?

 А ещё есть ряд вещей, которые всегда раздражали меня как соискателя, когда я оказывался “по ту сторону двери”.

Ниже мой личный Топ того, что меня всегда бесило

 I. Типовой набор технических вопросов на собеседованиях

 Если вы уже работаете в профессии 1-3-5 лет и более, то отвечать десятый раз за неделю (в режиме два собеседования в день) на скучные вопросы в духе: а что такое inner join? А зачем нужен мок-сервер? Как снять логи с андроид-устройства? – вас уже будет просто тошнить (и рекрутёру это тоже будет заметно). Особенно когда через неделю вам снова напишут: спасибо за уделённое время и внимание к нашей вакансии, вы классный специалист, но мы нашли на эту позицию индуса/пакистанца/китайца, который готов работать 6/1 дней в неделю за зарплату на 500 $ меньше, чем хотите вы.

Если вы джун практически без реального опыта и просто старательно зазубрили ответы на все вопросы, используя гайды типа “Топ-100 вопросов на собеседовании для QA” с Хабра или Dou.ua, то при столкновении с реальными задачами на собеседовании вам это тоже мало поможет. Ну а кроме того, простите, но при должном усердии можно даже попугая или мартышку научить на них отвечать так, что они посреди ночи будут спросонок давать правильные ответы. Но, увы, это никак не поможет понять насколько хорош будет кандидат на реальном проекте.

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

Да, реальность такова, что люди после обучения в школах класса “войти в Ай-Ти с ноги за 3 месяца” отвечают на вопросы лучше, чем мидлы, которые только уволились и начали искать работу. Почему? Потому что пока мидлы “работу работали” на реальных проектах – trainee/junior QA зубриликак отвечать на типовые вопросы, как правильно проходить сито отбора hr и производить «вау‑эффэкт» на нанимателя.

Вполне реальный кейс, когда я опрашивал одного выпускника таких курсов: он идеально отвечал на вопросы по теории (вот прямо по учебнику шпарил), но когда его “отправили в поле” с элементарным вопросом по DevTools (вот сайт, найди мне урл откуда наше видео проигрывается и запрос) – всё, ступор. “Внутрь заложено, а наружу не выходит” (сарказм).

И собес c мидлом: “я вообще не помню, чем там BDD от TDD отличается, мы пытались эту хрень у себя внедрить на проекте лет 5-7 назад (тогда это было модно) и очень быстро пожалели, потому что стали тратить огромное количество времени на поддержание тестовой документации в актуальном состоянии, замедлился процесс разработки и вместо проектирования архитектуры все упоролись в написание тестов до кода. В итоге мы отказались от этого говна и вернулись к старому-доброму waterfall’у, порезанному на спринты”.  

III. Лайв-кодинг и разные нетипичные задачки в режиме реального времени

Я лично знаю достаточно хороших специалистов (с которыми я долго, комфортно и плодотворно работал), для кого собеседование – это уже стресс. А от необходимости срочно перформить на результат расшарив экран, когда их будут с кислым выражением лица критически оценивать два лида (Team Lead + QA Lead) они просто растеряются и начнут тупить или ошибаться (сам такой).  

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

Беда в том, что ни hr’ы, ни лиды на собесах этого обычно не понимают. И холерики блестяще пощёлкав на время задачки вроде “сколько раз за сутки стрелки часов, минутная и часовая, находятся одновременно в одном и том же положении” проходят на позиции, где на самом деле нужны люди прогнозирующие риски, а не борющиеся с последствиями.

(Если кому интересно ­– я на этом вопросе завис на пару минут, а потом просто снял механические часы с руки и начал крутить стрелки. Но девочка-hr сказала, что раз я не могу посчитать такую элементарную задачку в голове, то мне пока рано претендовать у них в компании на позицию Senior QA. Спасибо! Пошел я на ***!!)

IV. Протестируй наш сервис “здесь и сейчас”!

Человек не знает, что у вас “под капотом”. RabbitMQ или Apache Kafka? Рассылка сразу улетает или по крону? Один сервер или маршрутизация настроена? И так далее и тому подобное... Это тоже самое, что cпросить “как мне попасть из Парижа в Дакар?” – Речь идёт о ралли или авиаперелёте (а можно ещё на поезде с пересадками, автостопом, на круизном лайнере, etc)?

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

Тестировщик может прийти из другой сферы (из EdTech допустим в разработку биржевой/трейдинговой платформы) и для него (исходя из его предыдущего опыта) будет релевантной другая очерёдность проверок. Более того, я не хочу совершать лишних телодвижений. Сначала я хочу понять архитектуру проекта, узнать его состояние (сервера валятся под нагрузкой? баги на проде есть?), понять приоритеты юзеров и бизнеса. А только после этого уже начинать думать КАК и ЧТО я бы проверял.

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

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

2. постараться, чтобы от этих 60-90 минут (не зависимо от будущего результата – оффер или отказ) была польза и мне, и кандидату.

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

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

Мой топ-10 вопросов на собеседовании QA

1) Тебе (не) повезло – тебя наняли первым техническим специалистом в старт-ап. Твоя задача вместе с hr найти себе будущего QA-Лида. Как ты это будешь делать и на что обращать внимание? Какие вопросы задавать?

(Здесь нет правильного ответа – и авторитарный, и демократический стиль руководства вполне себе ок. Мне важно понять какая картинка идеального QA-отдела у человека в голове и что для него/неё (не) приемлемо. Да и людям иногда вместо шаблонов полезно подумать и понять, чего они хотят на самом деле и с кем хотят работать)

 2) HR сразу после того как сообщила мне, что тебя оформили ушла в декрет, а я в отпуск ни оставив никаких инструкций. У тебя есть Jira c бэклогом продукта, прод + тестовый стенд, дежурный разработчик и небольшие фронтовые задачки на 4 часа в день примерно. Что будешь делать? Как будешь начинать знакомство с проектом? Как будешь самоонбордиться? Как наводить порядок?

(На самом деле чек-лист онбординга в компанию с разбивкой по дням уже есть и подробно расписан. Суть в том, что у нас зачастую на аутстаффе небольшие проекты которые делаются за 1-3 месяца, где вся команда состоит одного-двух разработчиков и одного тестировщика. В свою очередь, над несколькими такими командами стоит один PM и один MQA Team Lead – т.е. я. Бывает, “прилетают” проекты в духе – у нас кривой сайт, сделанный 5 лет назад другой командой – доведите его до ума. Без сложной архитектуры и взаимозависимостей (например, простенькая LMS), но где надо включить голову и посидеть-потыкать, самостоятельно разобраться за короткий срок. Поэтому “самоонбординг” – must have).

3) Ты только приступил к работе в понедельник и тебе тут же прилетел тикет от саппорта: клиент жалуется, что оплата не проходит. К сожалению, больше ничего выяснить не удалось – клиент долго матерился, а потом бросил трубку. При этом ты знаешь, что в пятницу вечером был релиз фичи, но она без лейблов/тегов {billing} и вроде как не могла затронуть этот функционал.

У тебя есть доступ к логам в Sentry (только на проде - на тест их было лень подключать), доступ к БД (только на тестовый стенд – на прод не дают), доступ к RabbitMQ с помощью дежурного разработчика (везде), доступ к админкам (на тесте у тебя, на проде права выдать не успели – только у саппорта) и тестовые юзеры оставшиеся от предыдущего QA (прод + тест). Не забывай про возможность накатывать-откатывать ветки на тесте.

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

(мне важно понять КАК человек думает, сколько лишних телодвижений он (не) будет совершать и какой у него реальный опыт – потому что типовые баги очень легко предвидеть когда у тебя есть 2-3 года реального опыта, а не “накрученного” на курсах)

4) Назови свои сильные стороны (навыки, тулзы) и зоны роста. И если можешь, опиши каким специалистом (обладающим какими компетенциями) ты себя видишь через 1-3 года. Если вообще не хочешь развиваться – это тоже ок (стабильные, предсказуемые мидлы без шила в жопке нам тоже нужны). Просто объясни причину.

(Если вместо “слабых сторон” я говорю “зоны роста” - больше вероятность, что человек честно ответит, Что он не умеет/плохо умеет и честно ответит Куда он хочет расти)

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

На этом этапе я могу понять можем ли мы предоставить человеку возможности роста (или он уйдет через полгода от нас в AQA) и человек может примерно представить чему он может научиться у нас и насколько ему будет это интересно. Ну и заодно задуматься о своём будущем.

5) У тебя же есть сайты со сложной архитектурой, которыми ты постоянно пользуешься? Давай выбери любой такой сайт (кроме ПорноХаба), пошарь экран, зайди туда и попробуй за 10 минут найти 10 багов или придумать 10 импрувментов, чтобы ты там улучшил.

(Мне важно понять насколько у нас с человеком совпадает “чувство прекрасного” и насколько он перфекционист или пофигист, которому всё “и так сойдёт”. Эстетствующий мизантроп который всех задолбает наклепав 100500 импрувментов на ровном месте тоже вариант не очень – нужно знать меру и уметь посмотреть на проект как со стороны QA, так и со стороны Бизнеса)

6) Отлично. А теперь расскажи, как бы ты проектировал тестовое покрытие для него. Какие блоки с сьютами тест-кейсов делал бы, по какому принципу разбивал бы тест-кейсы по группам и как приоретизировал? Какие виды и типы проверок использовал бы? Сколько времени, по твоему мнению, займет написание и прогон таких тестов?

(Я очень рад, что все джуны уже выучили техники тест дизайна и знают, чем отличается ad-hoc testing от exploratory testing, но я хочу понимать, как человек будет это применять на практике без необходимости нанимать его на испытательный срок и не задалбывая тестовыми заданиями. И мне важно знать насколько его оценки объема работы и трудозатрат совпадают с моими)

7) С какой тулзой, ПО, софтом, БД ты никогда ранее не работал (но о которых слышал краем уха)? … Ага, хорошо. Теперь подожди пару минут – я придумаю тебе задачку на это. Используй гугл, ChatGPT, любые другие доступные подсказки (хоть помощь ментора в телеге). Смысл в том, чтобы понять, как ты адаптируешься к новым и неизвестным тебе ранее вещам, потому что в работе ты постоянно будешь сталкиваться с этим.

(Сегодня у нас проект с MongoDB, завтра надо адаптивную верстку в BrowserStack проверять, послезавтра плагины к сайту на WordPress прикручивать. Не обязательно знать всё – важно умение и готовность разбираться с чем-то новым постоянно)

8) Ты один тестировщик на проекте. У тебя есть входящие таски от сапорта (немного и редко), текучка (небольшие задачки на фронт ежедневные); техдолг из багов (с которыми надо разобраться) от предыдущего QA; “так себе” работающий тестовый стенд и периодически “набегающие” PM & QA Lead (одному нужно чтоб ты демо провел заказчику, а другой дергает тебя на созвоны по утрам, чтоб узнать статус задач). Какой ты видишь свою зону ответственности? Как будешь приоретизировать задачи? Как будешь работать с доской?

(На самом деле борда настроена и протокол взаимодействия, включая межкомандные таски, тоже подробно расписан уже на все случаи жизни. Я хочу знать понимает ли человек как работает Скрам и канбан-доска [не по определению с ютубчика, а реально] и  где его надо будет “подпинывать”, а где он может сам проявить инициативу. Одним надо, чтобы их не беспокоили и не мешали делать дело – сами во всем разберутся, другим наоборот – чёткий план и обратная связь каждый день)

9) Представь, что всё плохо. Вот прямо реально хуже некуда. Заказчик неадекватен и врывается с “гениальными идеями” посреди спринта (бросайте свои задачи, мне на завтра нужен вот этот функционал из бэклога на другом сайте), Лиды от такой жизни ушли в запой, PM сорвалась на тебе с утра пораньше после диалога с заказчиком, а разработчик уже пилит на автопилоте “продукт кодосодержащий”. А ты вообще линейный специалист – от тебя ничего не зависит. Что будешь делать с задачами и конфликтом?

(Я хочу понять, как человек будет действовать в агрессивной ситуации и способен ли он разделять проблемы/ошибки и людей)  

10) Ты упоминал, что учишься кодить (проходил курсы по автоматизации тестирования, сам что-то писал в свободное время или изучал, etc). Давай сейчас вместе зайдем на CodinGame и займемся парным программированием. Порешаем вместе пазлы в команде. Наша задача будет – победить других буржуев-оппонентов и написать работающий код быстрее других.

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

В итоге я получил win-win conversations:

1. Джун может получить от меня наброски своего карьерного трека, а я прокачать свои менторские скилы;

2. Мидл будет чувствовать себя комфортно и сможет “сыграть на своём поле”, где мы будем в равных условиях, применяя теорию тестирования на любом его сайте на практике без лишних нервов;

3. Синьор (который решит забежать к нам пока не найдёт свою работу AQA/SDET – да, было и два таких товарища) – сможет почилить, покодить just for fun вместе со мной под пивко с пиццей, заодно поправив мой костыльный код или обсуждая айти за жизнь))

В целом, вот такими, были мои первые собеседования. Я считаю, что мне удалось сделать их интересным, комфортными, полезным и познавательным для меня и для кандидата и избавиться от “раковой опухоли” тестовых заданий.

На этом у меня всё. Надеюсь, мой материал был для вас полезным и познавательным. С вас плюсик в карму, подписка, комментарий, а с меня новые статьи ;)