Что спрашивают на собеседовании тестировщика
Чек-лист подготовки к собеседованию на позицию ручного web-тестировщика
Самые популярные вопросы:
Какие методики тестирования Вы знаете?
модульная/компонентная: проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по отдельности;
интеграционная: предназначена для проверки связи между компонентами, а также взаимодействия с различными частями системы.
системная: высокоуровневая проверка функционала всей программы или системы в целом.
приемочная: проводится на этапе сдачи готового продукта заказчику.
Именно в этом порядке программное обеспечение подвергается испытанием.
Расскажите про виды тестирования?
Все виды тестирования программного обеспечения, можно условно разделить на следующие группы:
связанные с изменениями, то есть после исправления бага/дефекта необходимо повторное тестирование, с целью убедиться, что внесенные изменения действительно решили проблему.
Что такое нагрузочное тестирование и чем отличается от стресс тестированием?
Какие бывают подходы тестирования?
Всё зависит от доступа к коду программного обеспечения.
Что такое чек-лист и как его оформлять?
Литературы по тестированию множество и вам всё не перечитать, это и не нужно! Выбирайте книгу более современную и тоньше.
Что такое web приложение? Однозначно, это клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Поэтому не избежать вопросов про сетевые протоколы взаимодействия. Могут быть общие вопросы:
Какие интернет протоколы Вам известны?
На собеседование достаточно будет рассказать про основные протоколы, углубляться в эту тему не следует. Наиболее известные протоколы:
HTTP (Hyper Text Transfer Protocol)
FTP (File Transfer Protocol)
POP3 (Post Office Protocol)
SMTP (Simple Mail Transfer Protocol)
Но основная часть вопросов будет про http и https:
Расскажите какие между ними различие?
http — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных.
https — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности.
Как же ответить на вопрос «в чем отличия?», ответ кроется в их определении, а именно: https не является отдельным протоколом передачи данных, а представляет собой расширение протокола http с надстройкой шифрования; передаваемые по протоколу http данные не защищены, https обеспечивает конфиденциальность информации путем ее шифрования.
Какие Вам известны методы протокола http, расскажите вкратце о каждом?
HTTP определяет множество методов запроса, которые указывают, какое желаемое действие выполнится для данного ресурса.
Метода GET в HTTP используется для получения информации от сервера. Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
Метод HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
Метод POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
Метод PUT заменяет все текущие представления ресурса данными запроса.
Метод DELETE удаляет указанный ресурс.
Метод CONNECT преобразует существующее соединение в тоннель.
Метод OPTIONS используется для получения параметров текущего HTTP соединения.
Метод TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.
Метод PATCH используется для частичного изменения ресурса.
Отвечая на этот вопрос можете перечислить только основные методы.
Расскажите о структуре http-запроса и ответа?
Не пугайтесь этого вопроса, здесь следует упомянуть только про основные части http запроса: строка запроса, заголовки, тело сообщения. Нужно обратить внимание, что между заголовками и телом сообщения находится пустая строка (в качестве разделителя), она представляет собой символ перевода строки. При получении ответного запроса от сервера, тело сообщения обычно представляет собой содержимое веб-страницы.
Для расширения кругозора рекомендую прояснить понятия «Транспортный уровень», «Уровень сети интернет», «Канальный уровень».
Основы Web-программирования
Веб-приложение — клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Поэтому вопросы на собеседовании по этой теме обязательно будут!
Почему не открывается гиперссылка?
При ответе на вопрос необходимо уточнить, что у пользователя устойчивое интернет соединение. Даны следующие вводные: пользователь заходит на популярный ресурс с новостями, нажимает на «Срочная новость!», но страница не открывается. Самый простой способ разобраться в причине, это воспользоваться браузерной консолью. Открыли консоль, выбрали элемент с гиперссылкой, и анализируем какой веб-адрес указан. Самая популярная ошибка, которую находят тестировщики, это неверно указанный веб-адрес.
Почему не соответствует цвет кнопки дизайну?
Посмотреть цвет кнопки можно аналогичным способом через браузерную панель, и сравнить кодировки цвета.
Расскажите про браузерную консоль.
Панель Elements показывает разметку страницы точно так же, как она рендерится в браузере, так же можно посмотреть, как бы выглядела открытая страница на каком-нибудь девайсе с другим расширением экрана.
Панель Network. Основная функция данной вкладки – запись сетевого журнала. Она дает представление о запрашиваемых и загружаемых ресурсах в режиме реального времени.
Панель Performance. Данная вкладка используется при необходимости полного обзора затраченного времени.
Панель Memory. Данная панель дает возможность профилировать время исполнения и использование памяти веб приложением или страницей, таким образом помогая понять где именно тратится много ресурсов и как можно оптимизировать код.
Панель Application. Предназначена для исследования загруженных элементов.
Если у вас есть основы знаний HTML, CSS, JS это будет огромным плюсом, хотя бы следует развиваться в этом направлении, чтобы стать хорошим специалистом!
Что же именно входит в основы?
А что же с API?
Сложность тестирования API (программный интерфейс приложения) заключается в отсутствии пользовательского интерфейса. Поэтому нужно настроить с необходимым набором параметров среду тестирующую API, а затем проанализировать результаты теста. Какие же вопросы могут таиться:
Чем отличается REST от SOAP протокола?
REST — это архитектурный стиль. SOAP — это формат обмена сообщениям, имеет веб-сервис WSDL с прописанными методами, которые можно удаленно вызывать.
REST работает только по HTTP/HTTPS, SOAP с любым протоколом прикладного уровня: SMPT, FTP, HTTP, HTTPS, POP3.
REST более простой, гибкий и быстрый, SOAP типизированный, но в некоторых случаях лучше визуализируется за счет применения им синтаксиса похожего на HTML разметку.
Какой формат передачи информации используется в SOAP, а какой в REST?
REST использует Json и XML, SOAP только XML.
Какие инструменты вы знаете для тестирования API?
Отвечая на этот вопрос, опирайтесь на свой опыт. Список самых популярных инструментов: SoapUI, Postman, REST-Assured, Fiddler, Karate, JMeter.
Информации по API в свободном доступе огромное количество, поэтому вы сможете разобраться в этом разделе.
Как быть с автоматизацией?
Во многих компаниях активно используется автоматическое тестирование. Часто разбором результатов прогонов и анализом занимаются ручники. Поэтому нужно иметь небольшое представление, как строится процесс автоматизации и какие инструменты используются.
Если раньше в работе сталкивались с автоматизацией, то расскажите подробнее какой использовался технический стек, как происходил разбор тестов, и какой был алгоритм действий, если автотест падал с ошибкой.
Большим плюсом будет опыт работы с GIT и с базами данных.
Как провести неидеальное собеседование тестировщика и почему идеальных не бывает
Дрейк и не знал, насколько был близок к подбору правильного тестировщика.
Рано или поздно может настать момент, когда к вам придут с просьбой найти тестировщика. Можно, конечно, почитать какую-нибудь литературу про тестирование – например, «Тестирование Дот Ком» Романа Савина. Да только, вполне возможно, кандидаты её тоже читали.
Поэтому я хочу поделиться своим взглядом на то, какие вопросы задавать и на какие качества обращать внимание при собеседовании вашего первого тестировщика.
Последние 5 лет я работаю в Яндекс.Деньгах руководителем отдела тестирования и регулярно собеседую людей на позиции тестировщиков. Приходилось проводить собеседования как по хорошо знакомым продуктам, так и по тем, про которые самому пришлось узнать за пару минут до интервью. Со временем я составил оптимальный для себя путь прохождения квеста, которым и хочу поделиться в статье.
#1 Сжигайте письма к Санте
Наверное, в деле собеседований самое важное – идти без мысли «скорее всего, это наш человек». В моей практике не раз встречались идеальные резюме, как будто специально написанные под нашу вакансию. Во-первых, они действительно могут быть просто под вас написаны, а во-вторых, в реальном общении человек может оказаться тяжелым или просто необщительным. Поэтому, если кандидат не подойдет, предварительный настрой на найм именно его будет психологически тяжело изменить.
Справедлив и вариант от обратного, когда вы заранее негативно настроены к человеку из-за слабого резюме – о собеседовании уже договорились и отменять как-то некрасиво. Если договорились пообщаться, то будьте беспристрастны.
К слову об общительности и опрятном виде – для тестировщика это важные, близкие к необходимым качества. Какой бы баг он ни обнаружил, приходится объяснять разработчикам, почему это ошибка и как ее воспроизвести – по понятным причинам делать все это нужно в благожелательном тоне. Без навыков общения тут не обойтись, потому что на резкую критику по поводу найденных багов легко получить негатив в ответ.
Это может показаться неоднозначным, но я рекомендую не заострять внимание на небольшом опоздании кандидата на собеседование, особенно если он позвонил и предупредил. Пунктуальность у инженеров не самое распространенное качество. К тому же с секундомером утром на входе все равно никто не стоит и найти офис с первого раза новому человеку не всегда просто.
Еще я не люблю популярные в наши дни стрессовые собеседования, особенно на инженерные позиции. Вы ведь не менеджера по урегулированию конфликтов ищете, а специалиста по QA. В его работе стресс связан не с конфликтами, а с уровнем ответственности за пропущенные ошибки. Поэтому в нашем деле лучше обойтись без криков на собеседовании и нарочно пролитого кофе – пусть этим занимается кто-нибудь из сферы биржевой торговли.
#2 Предложите протестировать ваш продукт
Когда нанимаешь человека на новую для себя и компании должность, непонятно, о чем вообще его спрашивать. Тут часто возникают две крайности:
%candidacy_name% должен уметь все, включая администрирование и навыки моделирования ракетных двигателей. На всякий случай.
Оба варианта одинаково ужасны и порождают массу странных и ненужных вопросов, создавая собеседующему неприглядный имидж в глазах кандидата. Проще идти от реальных обязанностей человека. Если тестировщик будет проверять новые сборки продукта и искать в них ошибки – предложите кандидату сделать именно это.
Предварительно составьте описание продукта или сервиса. Если продукт слишком большой, возьмите ту его часть, которой и будет заниматься потенциальный идеальный кандидат. Желательно при этом не подниматься до такого уровня абстракции, где будет два больших квадрата – фронтэнд или бэкенд, – дайте больше конкретики по вашей системе. Совсем замечательно, если спросите про что-то, что и сами не понимаете, как тестировать. В конце концов, не зазорно быть немного меркантильным.
Например, мы просим протестировать наш небольшой сервис под названием «Напоминатель» – письменные напоминания о том, что какой-то платеж нужно будет вот-вот совершить. Удобен он тем, что не очень понятно, как его тестировать: как получить напоминание, которое должно прийти через месяц, как проверить, что если напоминание поставлено на 31 число месяца, то в условном феврале оно придет 28, а не 29-ого.
Каждый тестировщик должен быть хоть немного и аналитиком. Поэтому на собеседованиях мы часто просим людей рассказать, как бы они сами создали продукт или сервис, который им предлагается протестировать. С тем же напоминателем просим описать, где бы хранились его записи (после этого даже самые недогадливые понимают, что там, где хранятся напоминатели, хранится и дата следующего события), какой бы механизм выбрасывал оповещения. Если вам нужен не monkey clicker, а осознающий свои поступки человек, то это хороший способ проверить его на тот самый «аналитический склад ума».
Надеюсь, что вы не будете указывать «аналитический склад ума» в требованиях к кандидату. А если указали, то не продолжайте чтение, пока не поправите объявление.
Нелишне спросить все то же самое, но про тот продукт, который тестировщик уже проверял раньше. Спросите про архитектуру, как была устроена система. В процессе задайте пару вопросов формата «а зачем вы так сделали?», чтобы человек описал хотя бы общими словами, почему он принял именно такое решение. Главное, чтобы он не пожимал плечами со словами: «я-то откуда знаю – я простой тестировщик».
#3 Проверьте, насколько он «в IT теме»
Представьте, что вас забросили на парашюте в центр Китая. Без денег и телефона, без знания языка. То же самое произойдет, если вы в свою команду приведете умного и всячески приятного в общении человека. Он и команда разработчиков просто не будут понимать друг друга, и вам придется нанимать кого-нибудь вроде героини Эми Адамс из «Прибытия», чтобы она научила нового специалиста этому непонятному птичьему языку. Ведь, помимо умения составлять правильные алгоритмы тестов, тестировщик должен общаться с разработкой и продуктовой командой на одном языке.
К такому собеседованию как раз удобно привлекать разработчиков из своей команды – разумеется, они легко «завалят» кандидата, но вы сможете оценить кругозор нового человека и его общее понимание, где он оказался. Например, банальные фразы про JIRA, Bitbucket, сертификаты и IDE могут быть наскальной азбукой для совсем новичков в профессии.
Если разработчиков почему-то не привлечь, то спросите в лоб: что такое интернет? Что мне только не отвечали на эту банальность: от «ну это сайты» и до «это то, что позволяет общаться между собой». Часто люди просто уходили глубоко в себя, а после встречи бурно возмущались, что им задают такие глупые и бесполезные вопросы.
Важно также предложить кандидату составить не особенно сложный алгоритм для какого-то действия или теста. Так вы убедитесь, что ему это не впервой и с алгоритмами он знаком. К этому навыку я еще добавляю умение быстро считать в уме. Конечно, это спорный момент, но для плодотворной работы полезно уметь посчитать выражения из кода в уме – без предварительной сборки проекта и калькулятора.
#4 О тестовых заданиях
Согласен, что тестовое задание сродни практике – позволяет лучше оценить знания. Но обычно кандидаты не горят желанием их выполнять, потому что это долго, муторно и непонятно, стоит ли игра свеч. Да и проверяющие не всегда добросовестно относятся к тесту. Например, они могут отложить проверку результатов на несколько дней (а кандидат торопился, делал) или проверять «по трафарету». Если решение вылезает за границы идеального трафарета – кандидат бракуется, что не правильно. Вы ведь помните про ход мысли и его приоритет над правильным решением?
На мой взгляд, тестовое задание в большинстве случаев не нужно, но, надо признать, есть ряд оправданных исключений:
Вы ищете не junior тестировщика, а автоматизатора, то есть уже состоявшегося специалиста со своим карьерным путем. В таком случае может оказаться проще оценить заявленное владение технологиями и проверить опыт работы.
У вас в компании высокая степень формализма при написании многочисленной документации, и нужно быть точно уверенным, что кандидат способен письменно излагать свои мысли и не страдает дислексией. Но вообще это можно проверить, дав кандидату ноутбук и попросив завести описание какого-нибудь бага.
По одной такой задаче нам как-то пришло полторы тысячи писем. На второй сотне сообщений о багах вы впадаете в дзен и перестаете реагировать на внешние раздражители. Заодно можно быстро, без регистрации и СМС научиться медитации.
#5 Что делать, когда вогоны сносят планету
Любопытное наблюдение я сделал после работы в нескольких крупных компаниях – тестировщики часто развивают свою карьеру не в сторону разработки, а в сторону проектного управления. В сущности, это неудивительно, так как в основе обеих профессий лежит навык общения с людьми. Тестировщику тоже важнее сохранять корректность и нейтралитет, чем знать пару дополнительных языков программирования.
Спросите кандидата, как он будет справляться с относительно невозможными ситуациями. Относительно – потому что не стоит спрашивать у него, что он будет делать, когда вогоны сносят его планету, и почему у него нет с собой полотенца.
Если ранжировать качества кандидатов, то на первое место я с особой помпой поставлю ум, а на второе – остроумие. Поэтому всегда спрашиваю, какие книги читал кандидат. Причем это не обязательно должны быть книги по тестированию.
Один из наших старших тестировщиков устроился в Яндекс.Деньги после письма, которое начиналось со слов: «Я ничего не знаю о тестировании, но очень хочу у вас работать». Это было три года назад, и с тех пор он сначала избавился от приставки «младший», а потом получил «старшего». Леша, привет!
Собеседование для QA: резюме, вопросы на интервью, переговоры о зарплате + полезные ссылки
Спросили Алексея Петрова pifagor_mc, Head of QA Сбермаркета, про интервью QA-инженеров и записали ответы. А ещё для подготовки прикрепили ссылки, которые он советовал — ищите их в конце статьи.
В тексте говорим только про собеседования:
3 основные рекомендации по составлению резюме для QA
Из каких блоков состоит стандартное интервью
Поделюсь рецептом, который встречаю, и пользуюсь им, когда сам собеседую.
В g-mate — много крутых вакансий для QA. Используйте бот @g_jobbot, чтобы получать вакансии по своему профилю прямо в Telegram.
Самый популярный кейс, чтобы составить представление, что будет на интервью
Открытием для 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». Они актуальные, очень рекомендую.
Есть пара ссылок про инвертированное собеседование: какие вопросы задавать и зачем. Это архиважно: когда перед тобой сидит кандидат, и на вопрос о компании или продукте не знает, что ответить — выглядит не очень. И наоборот, на моём опыте был человек, который погуглил наши статьи на Хабре, почитал, что пишут СМИ, установил продукт, сделал тестовый заказ, записал несколько баг-репортов, сопроводительное письмо — это подкупает.
Несмотря на то, что по многим позициям у нас кандидат диктует условия, так или иначе — компании выбирают сотрудников, и вовлечённость играет в этом роль. Поэтому помимо всех этих ссылок — рекомендую изучить, чем занимается компания, что за продукт и какая специфика.