Как провести неидеальное собеседование тестировщика и почему идеальных не бывает


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


    Рано или поздно может настать момент, когда к вам придут с просьбой найти тестировщика. Можно, конечно, почитать какую-нибудь литературу про тестирование – например, «Тестирование Дот Ком» Романа Савина. Да только, вполне возможно, кандидаты её тоже читали.


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


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


    #1 Сжигайте письма к Санте


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


    Есть даже расхожее название псевдо-идеальных резюме – «письма к Санте». К ним стоит в начале добавлять: «Дорогой Санта, сделай так, чтобы в следующем году я знал: ...» А в конце: «Best regards, Tommy».

    Справедлив и вариант от обратного, когда вы заранее негативно настроены к человеку из-за слабого резюме – о собеседовании уже договорились и отменять как-то некрасиво. Если договорились пообщаться, то будьте беспристрастны.


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


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


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


    #2 Предложите протестировать ваш продукт


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


    • %candidacy_name% должен уметь все, включая администрирование и навыки моделирования ракетных двигателей. На всякий случай.


    • %candidacy_name% должен быть отличным разработчиком.

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


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


    Например, мы просим протестировать наш небольшой сервис под названием «Напоминатель» – письменные напоминания о том, что какой-то платеж нужно будет вот-вот совершить. Удобен он тем, что не очень понятно, как его тестировать: как получить напоминание, которое должно прийти через месяц, как проверить, что если напоминание поставлено на 31 число месяца, то в условном феврале оно придет 28, а не 29-ого.


    Каждый тестировщик должен быть хоть немного и аналитиком. Поэтому на собеседованиях мы часто просим людей рассказать, как бы они сами создали продукт или сервис, который им предлагается протестировать. С тем же напоминателем просим описать, где бы хранились его записи (после этого даже самые недогадливые понимают, что там, где хранятся напоминатели, хранится и дата следующего события), какой бы механизм выбрасывал оповещения. Если вам нужен не monkey clicker, а осознающий свои поступки человек, то это хороший способ проверить его на тот самый «аналитический склад ума».


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

    Нелишне спросить все то же самое, но про тот продукт, который тестировщик уже проверял раньше. Спросите про архитектуру, как была устроена система. В процессе задайте пару вопросов формата «а зачем вы так сделали?», чтобы человек описал хотя бы общими словами, почему он принял именно такое решение. Главное, чтобы он не пожимал плечами со словами: «я-то откуда знаю – я простой тестировщик».


    #3 Проверьте, насколько он "в IT теме"


    Представьте, что вас забросили на парашюте в центр Китая. Без денег и телефона, без знания языка. То же самое произойдет, если вы в свою команду приведете умного и всячески приятного в общении человека. Он и команда разработчиков просто не будут понимать друг друга, и вам придется нанимать кого-нибудь вроде героини Эми Адамс из «Прибытия», чтобы она научила нового специалиста этому непонятному птичьему языку. Ведь, помимо умения составлять правильные алгоритмы тестов, тестировщик должен общаться с разработкой и продуктовой командой на одном языке.


    К такому собеседованию как раз удобно привлекать разработчиков из своей команды – разумеется, они легко «завалят» кандидата, но вы сможете оценить кругозор нового человека и его общее понимание, где он оказался. Например, банальные фразы про JIRA, Bitbucket, сертификаты и IDE могут быть наскальной азбукой для совсем новичков в профессии.

    Если разработчиков почему-то не привлечь, то спросите в лоб: что такое интернет? Что мне только не отвечали на эту банальность: от «ну это сайты» и до «это то, что позволяет общаться между собой». Часто люди просто уходили глубоко в себя, а после встречи бурно возмущались, что им задают такие глупые и бесполезные вопросы.


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


    #4 О тестовых заданиях


    Согласен, что тестовое задание сродни практике – позволяет лучше оценить знания. Но обычно кандидаты не горят желанием их выполнять, потому что это долго, муторно и непонятно, стоит ли игра свеч. Да и проверяющие не всегда добросовестно относятся к тесту. Например, они могут отложить проверку результатов на несколько дней (а кандидат торопился, делал) или проверять «по трафарету». Если решение вылезает за границы идеального трафарета – кандидат бракуется, что не правильно. Вы ведь помните про ход мысли и его приоритет над правильным решением?


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


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


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


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

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


    #5 Что делать, когда вогоны сносят планету


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


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


    Примеры подходящих вопросов:
    • «Два ПМа приходят к тебе и просят быстро протестировать их проект, который нужно релизить вечером. Что ты будешь делать?»
    • «ПМ укатил в отпуск и не сказал, должна ли стоять по умолчанию галочка в пункте «да, я хочу получать ежесекундные напоминания о трансфере Неймара», а разработчик говорит, что в гробу он его видел и галочка стоять не должна. Стоит ли заводить баг или нет?»

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


    Один из наших старших тестировщиков устроился в Яндекс.Деньги после письма, которое начиналось со слов: «Я ничего не знаю о тестировании, но очень хочу у вас работать». Это было три года назад, и с тех пор он сначала избавился от приставки «младший», а потом получил «старшего». Леша, привет!

    Яндекс.Деньги
    63,57
    Как мы делаем Деньги
    Поделиться публикацией

    Комментарии 13

      +2
      нужно быть точно уверенным, что кандидат способен письменно излагать свои мысли и не страдает дислексией

      https://en.wikipedia.org/wiki/List_of_people_diagnosed_with_dyslexia
        +1

        Спасибо за ссылку, вот вам ответочка :)
        https://ru.wikipedia.org/wiki/Систематическая_ошибка_выжившего

          0
          http://www.austinlearningsolutions.com/blog/38-dyslexia-facts-and-statistics.html
          It is estimated that 1 in 10 people have dyslexia

          People with dyslexia excel or even gifted in areas of art, computer science, design, drama, electronics, math, mechanics, music, physics, sales and sports
        +1
        кстати да, по пятому пункту, у меня схожая история, на фирму я шел тестировщиком, а попал на проект по автоматизации. Когда его передали другой фирме, наши ребята забрали меня в команду разработчиков, как начинающего разработчика, но необходимость писать ui тесты (на нашей embedded- системе занятие довольно муторное) опять сделала меня автоматизатором. Потом я просто прямым текстом отказался становиться разработчиком, а пожелал остаться тестировщиком. Чтобы не требовали сертификаты по яве сдавать и прочую муть. Живу отлично, пишу автоматизацию на весь цех, помогаю молодым-разработчикам. Разработчиком становиться не собираюсь. Хорошим все равно не стану, а плохим лучше не надо. Насмотрелся.
        Да и на фирму я устроился тоже так, послал наобум резюме на тестировщика, и когда не ответили пошел спросить почему, и узнать что нужно чтобы быть тестировщиком. Через два дня позвонили, позвали на интервью и взяли на испытательный (решила проявленная инициатива, как мне потом рассказывал кадровик) Но, будем честными до конца, и ситуация решила, человечка им надо было подменить, который два проекта по-полставки делал.
          0
          Хорошо все сложилось, мои поздравления! И про сочетание «хочу» и обстоятельств верно подметили — еще Джобс что-то такое про соединение точек в жизни говорил.
          +1

          «Два ПМа приходят к тебе и просят быстро протестировать их проект, который нужно релизить вечером. Что ты будешь делать?»


          Это по моему только в Яндексе толпа ПМ орет друг на друга кому достанется тестеровщик, просит поработать в обед и сделать все быстрее, чем обычно. Вместо того, чтобы выбрать одного ПМ решающего приоритет работ, планировать когда и что и наконец просто нанять тестеровщик сколько положено.
          Ну и обязательно задать вопрос на интервью как выбраться из #опы, которую сами и придумали.

            0
            Работая в Яндекс.Деньгах, не встречал, чтобы толпа на кого-то орала. Но как бы хорошо ни были выстроены процессы, накладки могут случиться везде. В штатной ситуации люди обычно действуют по уму и вполне осознанно, а вот если все идет не так – нужна смекалка, логика и какая-то внутренняя воля. И вопрос про двух ПМов — как раз на проверку этих качеств.
              0
              С уверенностью скажу за Яндекс.Маркет. И наверняка у вас тоже самое ибо процесс к этому склоняет. Вам кажется, что у вас идет рациональное обсуждение на митинге ПМ-ов, а по факту ресурсы получает тот, кто больше всех ноет. Тихий ПМ — мертвый ПМ.
              Это вопрос уровня… А что делать если надо оттестировать то на что нет спецификации? А что делать если разработчик говорит, что фиксить баг не будет? А что делать, если ПМ говорит, что молодец Вася, хотя ты нашел багов в два раза больше и сделал больше релизов?
              Эти вопросы не должны возникать в нормальных процессах. Смекалка — это как протестировать одним тестом два тест кейса. Или какие выбрать тесты из 2000, так как времени есть только на 400.
              Вы тестируете выживет ли человек в вашей среде. Вместо того, чтобы сесть и один раз подумать, что изменить в процессах, чтобы такого просто не могло быть.
            0
            Примеры подходящих вопросов:

            «Два ПМа приходят к тебе и просят быстро протестировать их проект, который нужно релизить вечером. Что ты будешь делать?»
            «ПМ укатил в отпуск и не сказал, должна ли стоять по умолчанию галочка в пункте «да, я хочу получать ежесекундные напоминания о трансфере Неймара», а разработчик говорит, что в гробу он его видел и галочка стоять не должна. Стоит ли заводить баг или нет?»


            А как бы вы сами ответили?
              0
              Два ПМа приходят к тебе...

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

              ПМ укатил в отпуск

              С разработчиком точно цапаться не стоит, сказать «ок, понял». Потом — если ПМ укатил в отпуск, то он должен оставить кого-то, кто уполномочен принимать решения за него, то к нему и идти. Но лучше всего — на ближайшем скраме или любом подобном митинге, если есть такие, где присутствует вся команда, голосом сказать, что есть такая проблема.
              А баг — да, стоит завести, не помешает.
              0
              Что делать если не удается найти тестировщика? Согласны даже на юниора, но с задатками роста. Зп средняя по рынку, из требований только немного sql.
                0
                — А как вы определяете задатки роста, если не секрет?
                — «Зп средняя по рынку» — вы на таких условиях в ресторане согласитесь есть? «А сколько у вас стоит то-то? — Как в среднем по рынку!»
                — «из требований только немного sql» — я правильно понимаю, что индусы или там удаленщик с Дальнего Востока вам тоже подойдут?

                Если честно, мне просто хочется понять, а какой ответ вы хотели бы получит, написав настолько неконкретно? Или цель была только в озвучивании риторического вопроса?
                  0
                  Я подумал, что может быть, кто-то имеет опыт и сможет помочь.
                  В вакансии есть вилка, вполне конкретная 50-80тр, подойдет и индус и Дальний Восток, работа удаленная полный день, не фриланс. Задатки роста… тут скорее интуитивно, если человек энергичен, задает целевые вопросы, имеет хотя бы небольшой опыт для вакансии, на которую претендует. Увы, не все могут на элементарные вопросы ответить. Косвенно о человеке свидетельствует опыт работы по 1-3 месяца на каждом месте.

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

              Самое читаемое