Спросили Алексея Петрова pifagor_mc, Head of QA Сбермаркета, про интервью QA-инженеров и записали ответы. А ещё для подготовки прикрепили ссылки, которые он советовал — ищите их в конце статьи.
В тексте говорим только про собеседования:
Про метрики качества продукта, смерть QA — смотрите в записи вебинара на Ютубе.
По своему опыту скажу, что на чтение одного резюме у интервьюера в среднем уходит 1–1,5 минуты, он смотрит лист по диагонали. И если эти атрибуты выполнены, резюме прочитают чуть внимательнее. Чтобы «продать» себя, есть одна минута, поэтому важно подчеркнуть самые интересные случаи из опыта.
Поделюсь рецептом, который встречаю, и пользуюсь им, когда сам собеседую.
Количество интервью зависит от специфики работы и этапов найма в конкретной компании. Если есть возможность, стараюсь уложиться в одно собеседование, больше двух очень не люблю.
Открытием для QA этот кейс не станет: тестирование простейшей формочки, формы поиска или авторизации/регистрации. Практика показывает, что очень многие специалисты не могут решить эту задачу в полной мере, сообразно тому, что ожидают IT-компании. Тестировщики подходят к ней с точки зрения теории тестирования, классов эквивалентности, анализа граничных значений, строят графы переходы состояний. При этом забывают о продуктовом тестировании, когда фокус идёт не на комбинаторику и техники типа pairwise, а на сценарии, с которыми сталкивается реальный пользователь.
Наверное, теперь придётся исключить из собеседований этот вопрос! Но приведу пример. Форма авторизации: логин-пароль, всё просто. Логин по маске либо телефон, либо имейл, пароль имеет какое-то ограничение. Большинство кандидатов начинают перебирать комбинаторные варианты: введу много пробелов, ещё что-то такое. А для пользователя важны другие кейсы: при существующем аккаунте, пускай при корректной связке логин-пароль (имейл+пароль, номер телефона+пароль) пускает, по несуществующей связке — не пускает. Дробить тут можно бесконечно. Почему-то забывают про кейс с восстановлением пароля. Я регулярно сталкиваюсь с тем, что забываю пароль от очередного сервиса, и надо его восстанавливать.
По старому тебя не должно пускать, а по новому — должно. Именно по таким кейсам можно посмотреть, как кандидат владеет техниками тест-дизайна, может ли он от них абстрагироваться и думать о продукте не как о наборе кнопочек и формочек, а как о пользовательском сценарии, с которым сталкивается самый обычный пользователь.
В тестировании безусловно играет роль и product vision. Сейчас есть такая модная штука: shift-left testing. Тестирование подключается как можно раньше, включается в процедуру планирования, проработки требований. Такой подход всё популярнее во многих крупных компаниях, и разумеется, что QA-инженер понимает, какое есть продуктовое видение. Пусть в бэклоге заложено 15–20 задач: зачем мы их делаем, какую пользу приносим пользователю — в зависимости от этого строятся кейсы. Например, хотим повысить ретеншн у мобильного приложения. Значит всё, что связано с реактивирующими пушами — для нас в высоком приоритете. Поэтому они должны работать идеально, как часы: приходить ровно, таргетировать человека в то место, куда должны, и так далее. Безусловно, QA должен понимать, зачем и как это происходит.
Есть альтернативный подход: shift-right testing. QA-инженер не начинает работу, когда тикет приходит в состоянии ready for test — подключается раньше, и не бросает её, когда тикет перешел в tested. Инженер помогает зарелизиться, помогает сопровождать в продакшене.
Речь и про регрессионные тесты, которые в будущем повторяются и говорят о том, что данный функционал не деградировал. Речь и про продуктовые метрики. Нередко, глядя на них, можно сделать предположение, что что-то пошло не так: смотрим на тот же DAU, а он резко просел после последнего релиза. Может, по техническим метрикам мы это не уловили, на регрессах проблемы нет, но всё равно это сигнал разобраться, что пошло не так, что повлияло на эти события. Плюс не надо забывать А/В-тестирование, feature toggling и так далее. Многие компании выпускают фичи на часть аудитории, QA вместе с продуктовыми аналитиками оценивают, оправдывает ли фича возложенные на неё надежды, если да — занимаются раскаткой дальше. QA не должны бросать фичу, протестировал — не значит, что работа закончена.
Позволю себе отойти в сторону: 50-60% кандидатов фейлится на вопросе про свой самый большой провал. Очень многие комплексуют признаваться в неудачах. Ощущение, что они начитались книг про успешный успех и думают, будто все истории построены на череде исключительно успешных кейсов. Это не так: не ошибается только тот, кто ничего не делает.
Я призываю всех искренне и прямо рассказывать о собственных неудачах. Не пытаться увиливать, спихивать ответственность на коллег, обстоятельства, фазы луны. Если человек хорошо рассказывает про собственные фейлы, например, как проанализировал их с помощью техники «Пять почему» или Диаграммы Исикавы, разобрался в причинах ошибок и устранил их, что сделал для того, чтобы проблема не повторялась — это очень подкупает. Если вам задают такой вопрос — будьте искренними, это ключ к успеху.
Если говорить про то, что спрашивать интервьюеров — советую задавать вопросы, применимые на практике, не абстрактные. Например, человек собеседуется на позицию специалиста по ручному тестированию, а спрашивает, что в компании с автоматизацией, нагрузочным тестированием, какие перспективы стать тимлидом — хотя сам — джуниор.
Спрашивайте то, что максимально релевантно функциональной нагрузке в будущей компании: как будет проходить испытательный срок, какие будут задачи, как понять, прошли ли вы испытательный срок или нет, есть ли kpi. Можно сразу задать встречный вопрос о негативных аспектах в работе в компании, о факапах — это актуальный вопрос для обеих сторон. Я предельно искренне рассказываю, если есть проблемы, неотлаженный процесс или мало автоматизации — прямо говорю и не преследую цели любыми способами заманить к себе специалиста. Люди ошибаются, и в компании тоже есть ошибки.
Центральный навык — самообучаемость. Бесконечно часто бывает, кандидат рассказывает, как хочет погрузиться в специфику мобильного тестирования или автоматизацию, хочет стать тимлидом — а злой и коварный работодатель не даёт ему это сделать. Поэтому он ищет работу, где сможет себя проявить, и ждёт, что его, как в «Волшебнике из страны Оз», возьмут за ручку и по дороге из желтого кирпича поведут в мир новых знаний и компетенций.
Всё-таки хочется, чтобы человек был сам заинтересован в собственном обучении. Конечно, работодатели предоставляют возможности для роста внутри компании: конференции, митапы, посещение профильных мероприятий, бюджеты на обучение и прочее. Но важно, чтобы человек сам делал шаги в этом направлении: пет-проект по автоматизации, ссылка на Github, а там — да, может быть, «карманные» тесты, на основе роликов в Ютубе или курсов Udemy. Но уже это показывает, что инженер не стоит на месте, а обозначил себе цель и идёт ей навстречу, не ждёт чуда.
Второе: важно, чтобы человек излучал уверенность. Иногда встречаешь кандидатов, просишь рассказать, какие http-методы он знает. Неуверенным голосом он говорит: «get, post, кажется, patch, put… delete… options...». Спрашиваешь, в чём отличия get и post, а в ответ: «ну, я не уверен… по-моему, один получает, другой создаёт объект, или что-то такое...». Если видно, что человек выдаёт правильные ответы на собеседовании, но делает это очень неуверенно — в реальной работе его съедят.
Модная концепция, набирающая обороты в продуктовых командах: есть закреплённый тестировщик, и он единственный и самый компетентный QA в команде. Если на планировании он будет точно так же говорить: «ой, ну не знаю, может, не стоить брать, я могу не успеть» — это не прокатит. Человек должен излучать уверенность: такая черта характера не позволит проскочить багам на уровне «и так сойдет». QA должен убедить коллег, привести аргументы, что так делать не стоит.
Ещё — автономность в работе. Всё чаще в продуктовых командах QA работают в одиночку или в паре. В сервисной модели есть большой отдел тестирования, есть тимлиды — можно забиться в уголок и отсидеться, а проблемы решит старший товарищ, ведущий инженер, тимлид, руководитель группы. В продуктовых так не получится, и компаний с похожим подходом компаний всё больше. Поэтому надо прокачивать уверенность и автономность.
А отсюда — и инициативность. Нужно её прокачивать, не бояться выражать мнение, подсвечивать проблемы. Может, попросить добавить новый статус? А может, начать делать код-ревью? Сопротивление и легкая конструктивная оппозиция. Для всего этого, безусловно, должна быть инициативность.
И всё равно — на одних софт скиллах далеко не уедешь, под ними должна быть техническая подложка. Опытный интервьюер быстро смекнёт, если человек умеет только рассуждать.
Сразу скажу, что рынок очень сильно поломался ковидом и удалёнкой. География присутствия расширилась, и у многих компаний поменялись установки.
Джуны — от 20 тыс. до 100 тыс. рублей. Найти работу с большой зарплатой сложно, одними курсами не обойдёшься, но устроиться можно. К тому же сильно зависит от региона.
У миддлов зарплаты тоже отличаются в зависимости от региона, компании, в каком секторе она работает. Финтех обычно платит больше всего — область специфичная. Для миддла — от 70–80 тыс. до 150–160 тыс. Тут ещё вопрос, кто какой уровень считает миддлом — в моём представлении, это сформировавшийся QA, который представляет, куда развиваться, чувствует почву под ногами, понимает, что хочет, может ответить на «пять почему».
Сеньоры: нижняя граница — от 100–120 тыс. рублей. Я видел ребят-сеньоров, не лидовых, кто на своей позиции получает 300 тысяч. Это даже не зарубежные компании, такие зарплаты существуют внутри российского рынка. Единственное, нужно отдавать отчёт, что если сфера — криптовалютный блокчейн и подобное, есть риск, что в понедельник вы проснётесь, а тимлид написал: извини, работы больше нет, зарплаты нет, ноутбук можешь оставить себе. Как ни печально, такие истории я слышал.
Тимлиды получают от 140 тыс. до 300 тыс., для хэдов я видел вакансии до 500 тысяч рублей. Все цифры называю с учётом налогов.
Не хочется стрелять себе в ногу… Но опять же: краеугольный момент, насколько человек вовлечён и замотивирован работать. Никому не хочется давать оверпрайс сеньору, которые работал в крутых организациях, но общается свысока. И наоборот.
Лайфхак — давать вилку с небольшой «горкой», так, чтобы даже отступив от верхней планки, держать марку. Нормальная техника, если назвал: от 100 до 150, а по факту устроит и 130, к такому можно прибегать.
Ещё два пункта: честность, даже в таких базовых вещах, как назвать свой текущий уровень дохода. И аргументация — по опыту, если было 100 тыс., а хочу 150 тыс., но есть действительно понятные аргументы, та же ипотека — такой подход намного лучше сработает.
Важно быть честным, если вопрос финансов — определяющий. Неприятные ощущения остаются от беседы с человеком, который всё собеседование бьёт себя пяткой в грудь, говорит про развитие и интерес к продукту, желание работать в продуктовой команде, а потом называет цифру в 140 тыс., при текущей 95 тыс. Про таких невольно думаешь: и рыбку съесть, и косточкой не подавиться.
Здорово, если деньги становятся не самоцелью, а дополнительной наградой, плюс хочется соразмерности. Безусловно, ни для кого не секрет, что переход в другую компанию сопряжен с ростом з/п. Но если это не выпячивается — то вызывает симпатию. И, честно скажу, бывали случаи, когда я давал сверх ожиданий, как дополнительный мотиватор. В тех случаях я понимал, что человек стоит больше, к тому же эта история с Даннингом-Крюгером: часть людей себя недооценивает. Им важно показать, что они классные специалисты, в том числе в финансовом эквиваленте. Поэтому если у меня есть возможность и есть бюджет, я захеджирую свои собственные риски: что через полгода-год, почувствовав уверенность в себе, специалист не пойдет смотреть рынок. Дам ему хорошие деньги — и он будет работать не один год.
У меня и моих бывших коллег есть несколько статей типа «как подготовиться к собеседованию на тестирование бэкенда» или «какие есть требования/ожидания от QA». Они актуальные, очень рекомендую.
Есть пара ссылок про инвертированное собеседование: какие вопросы задавать и зачем. Это архиважно: когда перед тобой сидит кандидат, и на вопрос о компании или продукте не знает, что ответить — выглядит не очень. И наоборот, на моём опыте был человек, который погуглил наши статьи на Хабре, почитал, что пишут СМИ, установил продукт, сделал тестовый заказ, записал несколько баг-репортов, сопроводительное письмо — это подкупает.
Несмотря на то, что по многим позициям у нас кандидат диктует условия, так или иначе — компании выбирают сотрудников, и вовлечённость играет в этом роль. Поэтому помимо всех этих ссылок — рекомендую изучить, чем занимается компания, что за продукт и какая специфика.
В тексте говорим только про собеседования:
- какое резюме прочитают внимательно, какое — закроют через пару секунд,
- о чём спросят на интервью вас и о чём стоит спросить работодателя,
- какие soft skills прокачивать QA-инженеру
- и как обсуждать зарплату на интервью.
Про метрики качества продукта, смерть QA — смотрите в записи вебинара на Ютубе.
3 основные рекомендации по составлению резюме для QA
- Объём не более 1,5 страниц. Это то, что бросается в глаза сразу — резюме должно быть лаконичным. Многие пытаются написать «Повесть временных лет», и описать опыт в десятках, сотнях строчек. Старайтесь делать выжимку самого важного: больше 3 листов интервьюер не читает, лучше всего — одна страница или полторы.
- Описаны результаты. Здорово, когда резюме структурировано по принципу «зона ответственности + достижения». То есть не просто написано, что сотрудник работал работу, участвовал в тестировании, а сформулирована понятная зона ответственности: за что отвечал, что с него спрашивали. И в работе любого специалиста существуют достижения: знаковые релизы, выпущенные фичи, карьерный рост — это очень важно, надо указывать.
- Опыт и инструменты соответствуют. Например, если человек занимался мобильным тестированием — упомянут инструментарий, характерный для мобильного тестирования, прямо ключевые слова. Например, Fiddler, Charles, Android Studio, Xcode и так далее. Если тестировал бэкенд — Insomnia, Postman, что-то такое. Когда видишь только опыт без инструментов, возникает вопрос, насколько поверхностно специалист знаком с работой. И наоборот — если использованные инструменты выглядят как ключевые слова без реального опыта применения. Например, указан Zabbix, а инженер всю жизнь занимался клиентским тестированием — наверное, он очень мало работал с Zabbix.
По своему опыту скажу, что на чтение одного резюме у интервьюера в среднем уходит 1–1,5 минуты, он смотрит лист по диагонали. И если эти атрибуты выполнены, резюме прочитают чуть внимательнее. Чтобы «продать» себя, есть одна минута, поэтому важно подчеркнуть самые интересные случаи из опыта.
Из каких блоков состоит стандартное интервью
Поделюсь рецептом, который встречаю, и пользуюсь им, когда сам собеседую.
- Сначала — представить компанию, описать процессы, рассказать про команду и ожидания от будущего коллеги. Сразу скажу, в этой части люблю оставлять «ловушки»: о чём-то сознательно не рассказываю, чтобы на этапе вопросов от кандидата ему было, о чём спросить, а мне — можно было углубиться в подробности.
- Дальше — очередь кандидата: его опыт, контекст применения инструментов, методик. Как часто они в компании релизили, что делали, зачем, почему. На этом этапе меньше интересует рассказ про продукты. Иногда люди уходят в дебри, говорят про тонкости реализации архитектуры их приложений. Это здорово, но самое важное для меня — инструменты, подходы, решения различных кейсов.
- Следующий этап — собственно решение кейсов. У меня есть своё собрание вопросов, которые использую для разных профилей: для мобильных тестировщиков одни, для специалистов по бэкенду — другие, для кроссфункциональных тестировщиков — третьи.
- Завершает обязательный этап с вопросами от кандидата. Есть такое понятие как инвертированное собеседование. Это для меня как интервьюера круче всего. Когда создается впечатление, что не ты собеседуешь, а тебя собеседуют: задают вопросы, как устроен процесс разработки, что с CI/CD, как у вас автотесты, а какой фреймворк, зачем, почему… В этот момент понимаешь, что специалисту не всё равно, он вовлечён, а еще понимаешь, что его волнует. И для себя делаешь пометки: например, человек больше смотрит вширь. Очень важно, чтобы человек задавал вопросы, которые помогали бы ему подстраховаться от ошибок, которые он совершил на прошлом месте. Если человек рассказывает, почему ушёл из прошлой компании и на собеседовании не подкладывает себе соломки под ту же причину — для меня это тревожный звонок.
- Под конец — оргвопросы. Зарплатные ожидания: всегда прошу озвучить кандидатов минимум, исходя из базовых потребностей — дети, семья, ипотека. И максимум: если у человека есть адекватная профессиональная оценка собственных навыков, компетенций по рынку — это здорово. По возможности я стараюсь прямо давать кандидатам обратную связь, чтобы у них было понимание, как всё прошло. Хотелось бы, чтобы собеседования проходили в таком свободном формате — это позволяет расстаться на позитивной ноте, даже если конкретно сейчас кандидат на место не подходит. У меня много примеров, когда с кандидатами расстались по причине «сейчас не время», и спустя какой-то период мы с ними работаем.
Количество интервью зависит от специфики работы и этапов найма в конкретной компании. Если есть возможность, стараюсь уложиться в одно собеседование, больше двух очень не люблю.
Talent Partner в боте @g_jobbot поможет упаковать резюме так, чтобы заинтересовать интервьюеров, и ответит на все вопросы по собеседованию. Бот просто и быстро настраивается: сфера, зарплата, локация (например, «релокейт»). Подходящие вам варианты будут приходить в Телеграм.
Самый популярный кейс, чтобы составить представление, что будет на интервью
Открытием для QA этот кейс не станет: тестирование простейшей формочки, формы поиска или авторизации/регистрации. Практика показывает, что очень многие специалисты не могут решить эту задачу в полной мере, сообразно тому, что ожидают IT-компании. Тестировщики подходят к ней с точки зрения теории тестирования, классов эквивалентности, анализа граничных значений, строят графы переходы состояний. При этом забывают о продуктовом тестировании, когда фокус идёт не на комбинаторику и техники типа pairwise, а на сценарии, с которыми сталкивается реальный пользователь.
Наверное, теперь придётся исключить из собеседований этот вопрос! Но приведу пример. Форма авторизации: логин-пароль, всё просто. Логин по маске либо телефон, либо имейл, пароль имеет какое-то ограничение. Большинство кандидатов начинают перебирать комбинаторные варианты: введу много пробелов, ещё что-то такое. А для пользователя важны другие кейсы: при существующем аккаунте, пускай при корректной связке логин-пароль (имейл+пароль, номер телефона+пароль) пускает, по несуществующей связке — не пускает. Дробить тут можно бесконечно. Почему-то забывают про кейс с восстановлением пароля. Я регулярно сталкиваюсь с тем, что забываю пароль от очередного сервиса, и надо его восстанавливать.
По старому тебя не должно пускать, а по новому — должно. Именно по таким кейсам можно посмотреть, как кандидат владеет техниками тест-дизайна, может ли он от них абстрагироваться и думать о продукте не как о наборе кнопочек и формочек, а как о пользовательском сценарии, с которым сталкивается самый обычный пользователь.
В тестировании безусловно играет роль и product vision. Сейчас есть такая модная штука: shift-left testing. Тестирование подключается как можно раньше, включается в процедуру планирования, проработки требований. Такой подход всё популярнее во многих крупных компаниях, и разумеется, что QA-инженер понимает, какое есть продуктовое видение. Пусть в бэклоге заложено 15–20 задач: зачем мы их делаем, какую пользу приносим пользователю — в зависимости от этого строятся кейсы. Например, хотим повысить ретеншн у мобильного приложения. Значит всё, что связано с реактивирующими пушами — для нас в высоком приоритете. Поэтому они должны работать идеально, как часы: приходить ровно, таргетировать человека в то место, куда должны, и так далее. Безусловно, QA должен понимать, зачем и как это происходит.
Есть альтернативный подход: shift-right testing. QA-инженер не начинает работу, когда тикет приходит в состоянии ready for test — подключается раньше, и не бросает её, когда тикет перешел в tested. Инженер помогает зарелизиться, помогает сопровождать в продакшене.
Речь и про регрессионные тесты, которые в будущем повторяются и говорят о том, что данный функционал не деградировал. Речь и про продуктовые метрики. Нередко, глядя на них, можно сделать предположение, что что-то пошло не так: смотрим на тот же DAU, а он резко просел после последнего релиза. Может, по техническим метрикам мы это не уловили, на регрессах проблемы нет, но всё равно это сигнал разобраться, что пошло не так, что повлияло на эти события. Плюс не надо забывать А/В-тестирование, feature toggling и так далее. Многие компании выпускают фичи на часть аудитории, QA вместе с продуктовыми аналитиками оценивают, оправдывает ли фича возложенные на неё надежды, если да — занимаются раскаткой дальше. QA не должны бросать фичу, протестировал — не значит, что работа закончена.
Что спрашивать интервьюеров на собеседовании
Позволю себе отойти в сторону: 50-60% кандидатов фейлится на вопросе про свой самый большой провал. Очень многие комплексуют признаваться в неудачах. Ощущение, что они начитались книг про успешный успех и думают, будто все истории построены на череде исключительно успешных кейсов. Это не так: не ошибается только тот, кто ничего не делает.
Я призываю всех искренне и прямо рассказывать о собственных неудачах. Не пытаться увиливать, спихивать ответственность на коллег, обстоятельства, фазы луны. Если человек хорошо рассказывает про собственные фейлы, например, как проанализировал их с помощью техники «Пять почему» или Диаграммы Исикавы, разобрался в причинах ошибок и устранил их, что сделал для того, чтобы проблема не повторялась — это очень подкупает. Если вам задают такой вопрос — будьте искренними, это ключ к успеху.
Если говорить про то, что спрашивать интервьюеров — советую задавать вопросы, применимые на практике, не абстрактные. Например, человек собеседуется на позицию специалиста по ручному тестированию, а спрашивает, что в компании с автоматизацией, нагрузочным тестированием, какие перспективы стать тимлидом — хотя сам — джуниор.
Спрашивайте то, что максимально релевантно функциональной нагрузке в будущей компании: как будет проходить испытательный срок, какие будут задачи, как понять, прошли ли вы испытательный срок или нет, есть ли kpi. Можно сразу задать встречный вопрос о негативных аспектах в работе в компании, о факапах — это актуальный вопрос для обеих сторон. Я предельно искренне рассказываю, если есть проблемы, неотлаженный процесс или мало автоматизации — прямо говорю и не преследую цели любыми способами заманить к себе специалиста. Люди ошибаются, и в компании тоже есть ошибки.
Soft skills для QA: 3 качества, которые стоит прокачивать в себе по твоему мнению
Центральный навык — самообучаемость. Бесконечно часто бывает, кандидат рассказывает, как хочет погрузиться в специфику мобильного тестирования или автоматизацию, хочет стать тимлидом — а злой и коварный работодатель не даёт ему это сделать. Поэтому он ищет работу, где сможет себя проявить, и ждёт, что его, как в «Волшебнике из страны Оз», возьмут за ручку и по дороге из желтого кирпича поведут в мир новых знаний и компетенций.
Всё-таки хочется, чтобы человек был сам заинтересован в собственном обучении. Конечно, работодатели предоставляют возможности для роста внутри компании: конференции, митапы, посещение профильных мероприятий, бюджеты на обучение и прочее. Но важно, чтобы человек сам делал шаги в этом направлении: пет-проект по автоматизации, ссылка на Github, а там — да, может быть, «карманные» тесты, на основе роликов в Ютубе или курсов Udemy. Но уже это показывает, что инженер не стоит на месте, а обозначил себе цель и идёт ей навстречу, не ждёт чуда.
Второе: важно, чтобы человек излучал уверенность. Иногда встречаешь кандидатов, просишь рассказать, какие http-методы он знает. Неуверенным голосом он говорит: «get, post, кажется, patch, put… delete… options...». Спрашиваешь, в чём отличия get и post, а в ответ: «ну, я не уверен… по-моему, один получает, другой создаёт объект, или что-то такое...». Если видно, что человек выдаёт правильные ответы на собеседовании, но делает это очень неуверенно — в реальной работе его съедят.
Модная концепция, набирающая обороты в продуктовых командах: есть закреплённый тестировщик, и он единственный и самый компетентный QA в команде. Если на планировании он будет точно так же говорить: «ой, ну не знаю, может, не стоить брать, я могу не успеть» — это не прокатит. Человек должен излучать уверенность: такая черта характера не позволит проскочить багам на уровне «и так сойдет». QA должен убедить коллег, привести аргументы, что так делать не стоит.
Ещё — автономность в работе. Всё чаще в продуктовых командах QA работают в одиночку или в паре. В сервисной модели есть большой отдел тестирования, есть тимлиды — можно забиться в уголок и отсидеться, а проблемы решит старший товарищ, ведущий инженер, тимлид, руководитель группы. В продуктовых так не получится, и компаний с похожим подходом компаний всё больше. Поэтому надо прокачивать уверенность и автономность.
А отсюда — и инициативность. Нужно её прокачивать, не бояться выражать мнение, подсвечивать проблемы. Может, попросить добавить новый статус? А может, начать делать код-ревью? Сопротивление и легкая конструктивная оппозиция. Для всего этого, безусловно, должна быть инициативность.
И всё равно — на одних софт скиллах далеко не уедешь, под ними должна быть техническая подложка. Опытный интервьюер быстро смекнёт, если человек умеет только рассуждать.
Зарплата по грейдам: про какие цифры может идти речь, к чему стремиться
Сразу скажу, что рынок очень сильно поломался ковидом и удалёнкой. География присутствия расширилась, и у многих компаний поменялись установки.
Джуны — от 20 тыс. до 100 тыс. рублей. Найти работу с большой зарплатой сложно, одними курсами не обойдёшься, но устроиться можно. К тому же сильно зависит от региона.
У миддлов зарплаты тоже отличаются в зависимости от региона, компании, в каком секторе она работает. Финтех обычно платит больше всего — область специфичная. Для миддла — от 70–80 тыс. до 150–160 тыс. Тут ещё вопрос, кто какой уровень считает миддлом — в моём представлении, это сформировавшийся QA, который представляет, куда развиваться, чувствует почву под ногами, понимает, что хочет, может ответить на «пять почему».
Сеньоры: нижняя граница — от 100–120 тыс. рублей. Я видел ребят-сеньоров, не лидовых, кто на своей позиции получает 300 тысяч. Это даже не зарубежные компании, такие зарплаты существуют внутри российского рынка. Единственное, нужно отдавать отчёт, что если сфера — криптовалютный блокчейн и подобное, есть риск, что в понедельник вы проснётесь, а тимлид написал: извини, работы больше нет, зарплаты нет, ноутбук можешь оставить себе. Как ни печально, такие истории я слышал.
Тимлиды получают от 140 тыс. до 300 тыс., для хэдов я видел вакансии до 500 тысяч рублей. Все цифры называю с учётом налогов.
Как торговаться о зарплате
Не хочется стрелять себе в ногу… Но опять же: краеугольный момент, насколько человек вовлечён и замотивирован работать. Никому не хочется давать оверпрайс сеньору, которые работал в крутых организациях, но общается свысока. И наоборот.
Лайфхак — давать вилку с небольшой «горкой», так, чтобы даже отступив от верхней планки, держать марку. Нормальная техника, если назвал: от 100 до 150, а по факту устроит и 130, к такому можно прибегать.
Ещё два пункта: честность, даже в таких базовых вещах, как назвать свой текущий уровень дохода. И аргументация — по опыту, если было 100 тыс., а хочу 150 тыс., но есть действительно понятные аргументы, та же ипотека — такой подход намного лучше сработает.
Важно быть честным, если вопрос финансов — определяющий. Неприятные ощущения остаются от беседы с человеком, который всё собеседование бьёт себя пяткой в грудь, говорит про развитие и интерес к продукту, желание работать в продуктовой команде, а потом называет цифру в 140 тыс., при текущей 95 тыс. Про таких невольно думаешь: и рыбку съесть, и косточкой не подавиться.
Здорово, если деньги становятся не самоцелью, а дополнительной наградой, плюс хочется соразмерности. Безусловно, ни для кого не секрет, что переход в другую компанию сопряжен с ростом з/п. Но если это не выпячивается — то вызывает симпатию. И, честно скажу, бывали случаи, когда я давал сверх ожиданий, как дополнительный мотиватор. В тех случаях я понимал, что человек стоит больше, к тому же эта история с Даннингом-Крюгером: часть людей себя недооценивает. Им важно показать, что они классные специалисты, в том числе в финансовом эквиваленте. Поэтому если у меня есть возможность и есть бюджет, я захеджирую свои собственные риски: что через полгода-год, почувствовав уверенность в себе, специалист не пойдет смотреть рынок. Дам ему хорошие деньги — и он будет работать не один год.
Ресурсы для подготовки к собеседованию
У меня и моих бывших коллег есть несколько статей типа «как подготовиться к собеседованию на тестирование бэкенда» или «какие есть требования/ожидания от QA». Они актуальные, очень рекомендую.
Есть пара ссылок про инвертированное собеседование: какие вопросы задавать и зачем. Это архиважно: когда перед тобой сидит кандидат, и на вопрос о компании или продукте не знает, что ответить — выглядит не очень. И наоборот, на моём опыте был человек, который погуглил наши статьи на Хабре, почитал, что пишут СМИ, установил продукт, сделал тестовый заказ, записал несколько баг-репортов, сопроводительное письмо — это подкупает.
Несмотря на то, что по многим позициям у нас кандидат диктует условия, так или иначе — компании выбирают сотрудников, и вовлечённость играет в этом роль. Поэтому помимо всех этих ссылок — рекомендую изучить, чем занимается компания, что за продукт и какая специфика.
Подготовка к собеседованию
- Собеседование для собеседующих (Хабр)
- Погружение в Charles Proxy (Хабр)
- Образ современного тестировщика. Что нужно знать и уметь (Хабр)
- Что должен знать тестировщик бэкенда (Хабр)
- Обратное собеседование (Github)
Потренироваться
- Тестовые площадки для тренировок настоящих ниндзя (блог Noveo)
- Can’t Unsee
Помощь
- Software Testing
- Automated Testing
- Testbase
- Про Тестинг
- Качество и тестирование ПО (Youtube)
Конференции и митапы
- SQA Days
- Heisenbug 2020 Moscow
- TestCon Moscow 2020
- Podlodka
Школы
- GeekBrains
- Яндекс.Практикум
- Нетология
- Otus.ru
Авторские программы
- QA.Guru
- RFT.QA
Пошабашить
- uTest
- TestBirds
Telegram-каналы
- https://t.me/qa_ru
- https://t.me/qa_bad_company
- https://t.me/qaevents
- https://t.me/yetanotherqa
- https://t.me/radioqa
Книги
- Тестирование Дот Ком или Пособие по жестокому обращению с багами в интернет-стартапах, Роман Савин
- Тестирование программного обеспечения. Базовый курс
- 5 лучших книг по тестированию ПО от Натальи Руколь
- Книга для начинающих тестировщиков
В g-mate — много крутых вакансий для QA. Используйте бот @g_jobbot, чтобы получать вакансии по своему профилю прямо в Telegram.
