Приятного времени суток, уважаемые читатели! Эта статья не претендует на роль полезного руководства, но скорее представляет собой интересные наблюдения за рынком труда. Здесь мы опустим тему растущих ожиданий от кандидата, а остановимся на более абсурдной вещи. Буду рад услышать ваше мнение по этому поводу и поделиться своими мыслями в комментариях.
Безусловно, сегодня в сфере информационных технологий любой специалист должен обладать широким кругозором и глубокими знаниями не только в своей узкоспециализированной области, но и в смежных с ней областях. Это и определяет профессионализм и высокий уровень квалификации специалиста. Однако, изучив множество вакансий на рынке труда и пройдя через ряд собеседований в различных компаниях, я обратил внимание на один печальный тренд.
Хотя я не могу говорить за всю ИТ-индустрию в России, я хочу поделиться своими наблюдениями о сфере, в которой работаю — автоматизации тестирования ПО. Судя по описаниям вакансий, беседам с HR-специалистами и техническим интервью, в российских компаниях часто наблюдается некоторое искажение понятий.
Год назад, приступая к поиску работы, я прошел через серию собеседований, и каждое собеседование, хоть и было специфичным в зависимости от продукта и компании, имело общий тренд.
В разных компаниях, начиная от стартапов и заканчивая крупными корпорациями, можно было заметить сходство в требованиях к кандидатам на позицию автоматизатора тестирования ПО. Они ожидали от соискателя знание различных методов тестирования, практический опыт применения техник тест-дизайна, уверенное владение языком программирования и библиотеками автоматизации, умение разрабатывать тестовые фреймворки, опыт ведения тестовой документации и дугие мелочи связанные напрямую с тестированием и смежными областями. Однако, сейчас компании часто под заголовком «Ищем AQA engineer для автоматизации тестирования» ищут кого угодно, но только не AQA.
Хотел в продуктовую команду, а попал в сервисную
Да, на данный момент для многих специалистов в области тестирования это главная проблема. Когда вы выбираете карьерный путь инженера по обеспечению качества программного обеспечения, вы не особенно радуетесь возможности работать в поддержке второй (или первой) линии. С другой стороны, компании часто нуждаются в таких специалистах, потому что они играют важную роль в команде и являются ключевыми исполнителями. Это "всезнайки", которых можно направить решать любые не решенные задачи в области тестирования, разработки, развертывания и т.д. Согласитесь, в любой компании нужны свои супергерои! Однако до недавнего времени профессия специалиста поддержки не расценивалась как отдельная от тестирования (возможно, тут я не прав в своих наблюдениях, исправьте в комментариях), и на курсы по этой специальности никакие школы не зазывали. Компании просто были вынуждены искать таких героев в тестировании. И, я считаю, в этом нет никакой проблемы. проблемы начинаются позже.
Ровно тогда, когда компании, стремясь заполучить таких специалистов, начинают маскировать работу в поддержке под работу инженера по обеспечению качества. Вот пара красочных примеров.
Не так давно я работал в компании, занимающейся разработкой веб-сервиса для врачей. Продукт был отличным, команда - профессиональной, а компания - очень лояльной и открытой. Но мое пребывание там продлилось всего полгода. На собеседовании мне детально рассказали о процессах в компании, о том, как распределены задачи между ручным и автоматизированным тестированием. Одно меня смутило — неделю в месяц я должен был работать в поддержке второй линии. Однако, по факту, в течение полугода я посвятил всего две недели разработке тестовых фреймворков и автоматизации. Остальное время уходило на ручное тестирование и поддержку. Это было далеко не то, чего я ожидал, и тем более не соответствовало обещаниям, данным мне при приеме на работу.
Собеседовался в одну из крупнейших IT-компаний на рынке России. Прошел интервью с HR и знакомство с командой. Мне рассказали, над каким продуктом работает команда, задали стандартные вопросы по QA и попросили рассказать о теории. В целом, я остался доволен этими этапами. Однако спустя какое-то время HR сообщила, что направила мое резюме в другой отдел, так как тот, где я собеседовался первоначально, "временно приостановил набор". Меня сразу пригласили на техническое собеседование, где, несмотря на мой двухлетний опыт, требовали слишком много. Ожидали, что я знаю два языка программирования, умею разрабатывать фреймворки, настраивать тестовое окружение, выстраивать процессы CI/CD и писать пайплайны, а также решать задачи разработки и прочее.В конце собеседования, когда я задал вопросы, стало ясно, что эта команда не продуктовая, а сервисная. Они помогают другим направлениям с их задачами (учитывая, что это крупная IT-компания с более чем 10 направлениями и продуктами). Более того, их команду сложно назвать командой, так как в течение года у них был только один человек - тимлид, а я должен был стать вторым.
Есть ли проблема?
Я знаю, что существует острая проблема с тем, что кандидаты часто преувеличивают свои навыки и опыт в резюме. Однако, мне кажется, что также остро стоит и обратная проблема. Нет ничего плохого в том, чтобы привлечь кандидата интересными задачами, которые, по факту, могут оказаться более рутинными. В целом, можно понять, почему стартапы и маленькие компании приукрашивают условия работы и задачи.
Если с монотонностью задач можно смириться, то стоит ли мириться с явной подменой понятий и ложью? Если компании могут выявить ложь кандидата на собеседовании или испытательном сроке, то у кандидата не всегда есть достаточно времени, чтобы выявить ложь со стороны компании. Более того, мне кажется, что такой подход искусственно завышает требования к специалисту, поскольку ему приходится владеть несколькими предметными областями одновременно. Это ведет к проблемам с дефицитом кадров, поскольку редко кто способен пройти столь жесткий отбор.
Рынок диктует, что для успешной карьеры в IT необходимо обладать всеми навыками одновременно. В результате, позиции, которые предполагались для начинающих специалистов (junior), часто занимают сотрудники среднего (mid-level) и старшего (senior) уровня, поскольку только их компетенций достаточно для выполнения обязанностей на начальном уровне. В то же время, поиски специалистов на более высокие позиции (senior и lead) затягиваются на долгие месяцы.