Меня зовут Вадим, я тестировщик в ЮMoney. Недавно моя знакомая разработчица из Канады искала работу в тестировании, в том числе в российских компаниях, и обратила внимание, что у нас собеседования сложнее: они более долгие, детальные и насыщенные техническими вопросами. У меня зарубежного опыта нет, но впечатления от интервью в наших компаниях позитивные — ищут скрупулёзно и надолго, готовы растить сотрудников и обращают внимание на софты. 

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

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

Где тестировщику искать работу в 2024 году: через мессенджер, сайт с вакансиями или Хабр

Я начал искать работу QA в феврале этого года. Откликался на вакансии на трёх площадках: hh, Telegram и Хабр. Больше всего мне понравился Telegram — там самая быстрая обратная связь от эйчаров. Кстати, именно там мы встретились с ЮMoney — познакомились, я отправил резюме на рабочую почту рекрутера, мы договорились об интервью. 

Почему в мессенджере удобно: 

  • Можно пообщаться с эйчаром напрямую — написать ему в личку.

  • Уведомления приходят быстро, и видно, что твой отклик заметили. 

  • Общение живое, можно оперативно договориться о созвоне или встрече. 

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

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

Какие тестировщики сейчас нужны 

Выбор вакансий QA такой большой, что глаза разбегаются. В основном ищут тестировщиков уровня Middle и Senior с опытом работы более двух-трёх лет. Обязательное требование, которое часто встречается, — опыт от года в написании автотестов на определённом языке программирования (далее — ЯП). 

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

Какие этапы собеседования ждут тестировщика 

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

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

У меня был примерно двухлетний перерыв в использовании требуемого языка. Если вы планируете откликаться на вакансии QA, советую повторить требуемый ЯП сразу, потому что времени на подготовку дают мало — около суток.

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

Также на собеседовании был этап разбора написанного кода — и, по классике, написание запросов SQL, с которым я справился на отлично. Мне сказали, что я очень сильный мидл и что мне подготовят оффер. Но в итоге взяли сеньора, а теперь ищут джуна. ?‍♂️ К такому повороту событий нужно быть готовым и не расстраиваться — будут новые варианты.

Каждое техническое собеседование длится около двух часов

Иногда и больше, но никак не меньше. На технических собеседованиях мне не задавали вопросов по типу «Какая цель тестирования?», «Дайте определение такому-то виду тестирования». Такие вопросы часто встречались три года назад, когда я искал работу перед приходом в ЮMoney. В основном мы разбирали кейсы, которые могут возникнуть в процессе работы, например:

  • У тебя есть стенд, на котором пройден регресс. Пришёл проджект-менеджер и сказал, что в завтрашний релиз надо включить ещё одну фичу. Что будешь делать?

  • Пришла таска, доки нет.

  • Можно ли релизить фичу с багами?

  • Есть короткое описание фичи. С чего начнёшь тестировать, если времени мало?

В ЮMoney техническое собеседование было самым интересным и сложным из всех. На интервью была большая команда, задавали всеобъемлющие вопросы на «порассуждать». Были и задачи на чтение логов, где нужно пояснить, что случилось, на каком этапе и что сделать, чтобы решить задачу. Подробно обсуждали бэкенд-части и базы данных.

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

О чём чаще всего спрашивают тестировщиков на технических собеседованиях

  • На всех собеседованиях спрашивали про объектно-ориентированное программирование (ООП), проверяли знания ЯП и работу во фреймворках, знание бэкенд-части (разбор логов и технических кейсов), SQL или Mongo, Docker, Linux и CI/CD. 

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

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

  • Я удивлялся, когда от меня ждали более глубокого понимания CI/CD-систем — к этому готов не был, и приходилось погружаться в теорию. Спрашивали, например, чем CI отличается от CD и какие преимущества дают те или иные технологии. 

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

Были и очень странные собеседования, где по технической части почти не спрашивали 

Однажды на мой вопрос «А как вы будете оценивать уровень компетенции?» мне ответили: «Будем смотреть, как человек говорит и какой он. Всё равно у нас нет знаний, чтобы оценить ответы». Собеседование проходило в Skype, его проводил директор компании, одетый в белый махровый халат. На созвоне присутствовала и эйчар. Оффер я не получил. Очевидно, или плохо говорил, или оказался неподходящим человеком. 

На другом собеседовании интервьюеры уже на на 11-й минуте заявили, что я им подхожу и меня берут. Я заподозрил что-то неладное и решил, что лучше поищу ещё варианты.

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

— Давно работаешь тестировщиком? 

— Ну… месяц. 

Было заметно, что его это смутило. 

— Как собираешься оценивать мою компетентность?  

— А у меня правильные ответы записаны. 

Собеседование мы закончили через 15 минут, когда список вопросов был исчерпан. Это была какая-то онлайн-школа по тестированию, не особо известная, искали преподавателя. Результатами собеседования я не стал интересоваться по понятным причинам. 

Если вы подошли команде по софтам, скорее всего, вам простят пробелы в знаниях и недостаток опыта 

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

Такое обычно внимательно слушают и всегда задают вопросы в духе «Почему меняешь работу?», «Что тебе важно на новом месте?». Я старался быть честным и говорить прямо, потому что эта часть собеседования иногда даже важнее, чем техническая. 

После обратной связи и получения офферов я пинговал эйчаров

Интересным компаниям я так и писал — мол, получил офферы в другие места, но ваш для меня приоритетный, можете ли ускорить обратную связь? Это помогало: отвечали сразу — либо да, либо нет. 

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

Чем отличаются собеседования в QA три года назад и сейчас

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

  • В 2021 году мои отклики просматривали, если я прикладывал ссылку на свой GitHub. 

  • В 2024-м больше спрашивали по технической части и задавали более сложные вопросы с лайвкодингом и демонстрацией логов (по типу «Что тут произошло?» и «Как бы ты решил этот вопрос как разработчик?»). 

  • Собеседования стали дольше: за час никак не управиться, а чаще всего и за два. 

  • Теории в собеседованиях стало меньше. Требуют больше понимания технологий, а не зазубренных ответов. 

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

Выводы

  • С каждым новым собеседованием я убеждался, как разнится стек — во всех компаниях он уникальный. 

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

  • Радует то, как наши специалисты стараются и с огнём в глазах развивают тестирование в своей компании — я почувствовал это на собеседованиях. 

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

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


Если вы тестировщик, который планирует искать работу или уже находится в поиске, задавайте вопросы в комментариях — буду рад дать совет. Кстати, сейчас в QA ЮMoney открыто несколько вакансий — откликайтесь.

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


  1. Azot-8778
    07.05.2024 18:02

    Скажите, пожалуйста, насколько сейчас реально найти работу QA без опыта работы?


    1. yanpurvenes
      07.05.2024 18:02

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


    1. BlueCofffee Автор
      07.05.2024 18:02

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


  1. yanpurvenes
    07.05.2024 18:02
    +2

    На технических собеседованиях мне не задавали вопросов по типу «Какая цель тестирования?», «Дайте определение такому-то виду тестирования».

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

    • У тебя есть стенд, на котором пройден регресс. Пришёл проджект-менеджер и сказал, что в завтрашний релиз надо включить ещё одну фичу. Что будешь делать?

    • Пришла таска, доки нет.

    • Можно ли релизить фичу с багами?

    • Есть короткое описание фичи. С чего начнёшь тестировать, если времени мало?

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

    . Обязательное требование, которое часто встречается, — опыт от года в написании автотестов на определённом языке программирования (далее — ЯП). 

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


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


    1. BlueCofffee Автор
      07.05.2024 18:02
      +1

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

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

      Самый первый комментарий как раз о том же, как найти работу без опыта. Читал статью пару лет назад, от имени HR. Жаловались, что компании хотят найти сотрудников с опытом, но при этом не готовы сами обучать сотрудников без опыта. Очевидно, у компаний свои мотивы. Допускаю, что мне на глаза попадались вакансии, где требовался ЯП, т.к. у меня есть опыт использования, а вакансии без требования ЯП я мог игнорировать. Тут в целом о рынке судить будет сложно, опираясь только на мой субъективный 2-х недельный опыт в поиске.


      1. yanpurvenes
        07.05.2024 18:02

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


        1. BlueCofffee Автор
          07.05.2024 18:02

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


          1. Chelyuk
            07.05.2024 18:02

            Не всегда бывает так. Хотя и довольно часто. По-хорошему, решение выпускать в релиз или нет - принимает как раз Продукт-Менеджер. Задача тестировщика позволить ему сделать информированое решение. Т.е. предоставить максимально подробный и правдивый отчёт о текущем состоянии продукта/релиза. А там уже ответственность Менеджера выпускать это или нет. Еще ему можно помочь адекватным тестпланом, в котором должно быть прописано - допустимый уровень дефектов каждого приоритета. Если допустимый уровень zero bugs, тогда можно и блокировать. Но таких продуктов не так уж и много. Все равно какой-то уровень minor/cosmetic допустим.


  1. gigimon
    07.05.2024 18:02

    Хожу на собеседования как Senior SDET (или Lead) уже последние лет 5, основной стэк у меня Python. Прошел собесов 30 примерно и за это время собесы стали лучше. Все меньше стали лайв кодить, все меньше стало тупых вопросов и бесполезных тестирований, также этапов становится поменьше. К тому же стэк, если рассматривать один язык, для тестирования один и тот же, и в каждом языке свой, как и инфраструктура в целом.

    Самое плохое, что я встречаю, это когда происходит собеседование первого QA и этим занимается далекий от этого человека (зачастую CTO или напыщенный главный разработчик), в этом случае они ждут совпадение ответа с тем, как считают они, либо ждут такую глубину, как будто собеседуют на Senior Architect Developer. (как пример, спрашивали о возможных уязвимостях в docker контейнере и теоретических возможностях его взлома, при этом в компании докер использовался как и у всех, обычной запускалкой)

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


  1. eugenekoiner
    07.05.2024 18:02
    +1

    зачем кубер докер cicd, а девопсы на что?


    1. BlueCofffee Автор
      07.05.2024 18:02

      Я тоже удивился, для чего?.. Смог ответить только на часть вопросов, и только потому что ранее брал это себе как точку роста и самостоятельно изучал. Больше удивили вопросы про ci/cd, ведь в работе все ограничивается тем, что ты выбираешь параметры и условную кнопку "Пуск" нажимаешь.


    1. Chelyuk
      07.05.2024 18:02

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


  1. maestr_o
    07.05.2024 18:02

    Привет автор. Учусь на тестировщика. Ты как прошедший уже некоторый путь на что посоветуешь делать упор?


    1. BlueCofffee Автор
      07.05.2024 18:02
      +2

      Привет!

      Самые стандартные темы: клиент-серверная архитектура (запросы поотправлять и разобраться как это все работает), чаще всего SQL, микросервисная архитектура, и + чем она отличается от монолитной, теория по тестирования, если опыта нет - будут ее спрашивать. Это первое что в голову пришло, а вообще открываешь вакансии, смотришь требования и по ним примерно учишься


  1. Fexele
    07.05.2024 18:02

    О чём чаще всего спрашивают тестировщиков на технических собеседованиях

    Удивительно насколько мой опыт поиска работы разнится в плане вопросов на собеседовании. У меня не было ни одного глубокого вопроса про Docker, Linux, устройство CI/CD. Если и были по ним вопросы, то формата с чем работал и что делал. Рассказываешь про свой опыт, подкрепляешь свой ответ дополнительным примером того, как это было релевантно в рамках своей позиции, после этого не требовались дополнительные знания.

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

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


    1. BlueCofffee Автор
      07.05.2024 18:02

      Честно, я тоже ожидал более сложных вопросов по API, и готовился. И неожиданностью было встретиться то, о чем писал. Почему у нас такие разные впечатления были, может быть дело в стеке? Хотя, я в резюме указывал, что работал с докером и линуксом, могло же повлиять, как вы думаете?


      1. Fexele
        07.05.2024 18:02

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

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


        1. BlueCofffee Автор
          07.05.2024 18:02

          А пристроить вас, судя по всему, им очень хотелось хоть куда-нибудь, главное к себе))


    1. yanpurvenes
      07.05.2024 18:02

      клиент-серверное взаимодействие спрашивали очень много

      Странный вопрос если не один проект был.

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

      А обычно так и делают. Пишут вопросы и ответы. Я еще видел в начале своей карьеры, такие листы в компании