12.02.2024

Как НЕ стоит проходить технические собеседования QA-инженеру

Вернуться назад

Привет, Хабр! Меня зовут Глеб Боос, я работаю руĸоводителем департамента центра ĸомпетенций. Последние шесть лет провожу собеседования и технические ревью QA-инженеров и лидов. 

Прошедшей осенью мне посчастливилось выступить на самой рок-н-ролльной конференции для тестировщиков, SQA Days, с темой про нюансы в технических собеседованиях как в роли собеседующего, так и в роли собеседуемого. 

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

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

Полная запись выступления есть на YouTube (ссылочка приложена ниже), так что если для вас удобнее в качестве альтернативы тексту формат видео, то подписывайтесь на канал, ставьте палец вверх и т.д:)

Ссылка

Основные проблемы

 

Для начала сделаем небольшое ревью для нахождения болевых точек процессов собеседований. В качестве выборки я взял последние 100 собеседований, которые провел в этом году. Во время проведения собеседований стараюсь максимально (насколько это возможно) конспектировать и тезисно записывать основные моменты по hard и soft-скиллам кандидата, что позволяет делать в будущем довольно точную ретроспективу.

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

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

Давайте немножко поиграем в мультивселенные собеседований!  Для этого предлагаю ввести двух персонажей. Пусть у нас есть добрый сосед человек-паук, но в нашей вселенной он будет добродушным кандидатом на позицию QA-инженера, а своенравный главный редактор газеты Daily Bugle будет выступать в роли технического эксперта, который проводит собеседования и оценивает уровень знаний Питера.

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

Сюжетная линия Питера

Предположим, что Питер Паркер решил открыть свое резюме и попробовать найти для себя ту самую работу мечты. Главная проблема, которая возникает на этом этапе: непонимание того, «Кто я» на айтишном рынке труда. Эта проблема снежным комом может пройти по всему этапу собеседования и привести в итоге к не самым хорошим последствиям. Самое главное, к чему приводит такая проблема – несоответствие ожиданий и реальности. Ее решение на самом деле заключается как в большом и плодотворном анализе рынка, так и в коммуникациях: с экспертами, друзьями, коллегами и т.д., для того, чтобы понять как необходимый уровень зарплаты, так и необходимый уровень компетенций для этих вилок.

Сюжетная линия Джоны

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

Сюжетная линия Питера

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

Сюжетная линия Джоны

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

Сюжетная линия Питера

Питер приходит на собеседование мечты, на его первый этап и не понимает, почему рекрутер не может объяснить ему, на каких фреймворках гоняются автотесты и почему рекрутер не может рассказать про степень покрытия тестами функционала. Проблема, которая больше актуальна для Junior или Middle-специалистов, к сожалению, встречается и у грейдов повыше. Даже если перед вами не обычный рекрутер, а IT-рекрутер, все равно необходимо делать скидку на то, что он оперирует исключительно теми данными, которые у него от технического эксперта, а транслировать и объяснить их более детально у него просто банально не хватает компетенций, так как это не заложено в его роли и обязанностях. Тут все довольно просто: если у вас есть огромный список технических вопросов, где вам необходимо узнать о том, сколько топиков в кафке на тестовом контуре и по какому принципу Lead делать ревью кода ваших автотестов, лучше отложить это до следующего этапа уже непосредственно с тех.экспертом, либо же непосредственным участником команды. Помни, что IT-рекрутер – твой лучший друг и не нужно кидать в него камни за то, что он знать и не должен.

Сюжетная линия Джоны

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

Сюжетная линия Питера

Следующая проблема, с которой может столкнуться Питер Паркер – это отсутствие подготовки к техническому собеседованию. К сожалению, опыт подсказывает, что  пройти тех.собес на 10/10, опираясь исключительно на свой опыт, далеко не всегда удается, так как как минимум могут быть несоответствия текущему опыту и тем потребностям, которые описаны в вакансиях, а еще многие тех.вопросы могут быть построены на оценку общего кругозора. Например, если раньше самым популярным вопросом про API был из разряда “а чем отличается REST от SOAP”, то сейчас могут спокойно задать вопрос про знание (хотя бы в теории) таких API-стилей как gRPC или GraphQL. Подготовка необходима еще и в том случае, если какие-то базовые вещи в силу тех или иных причин забылись на уровне деталей, так как использовались давно. Фраза “блин, давно с этим работал, уже не помню все моменты по этой теме”, на мой взгляд, является одной из самых обидных как для кандидата, так и для тех.эксперта.

Сюжетная линия Джоны

Банально, но у Джоны может возникать ровно такая же проблема. Вполне распространенная практика, что в отсутствии возможности делегировать собеседование от одного тех.эксперта другому для 100% покрытия компетенции,  возникает потребность провести оценку знаний по тем направлениям в тех.части, где у тех.эксперта может не хватать знаний или они могут полностью отсутствовать. Для этого необходимо заранее проводить оценку резюме, что обсуждалось на этапе ранее, а также провести самоподготовку по тех.части. С учетом того, что в роли собеседующих обычно выступают QA в роли Middle и выше (обычно Senior или Lead), опыт и широкий кругозор позволяют эксперту верхнеуровнево ознакомиться с незнакомой темой для того, чтобы вести диалог с кандидатом. Но тут, конечно же, все очень индивидуально и зависит от потребности.

Сюжетная линия Питера

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

Сюжетная линия Джоны

Структурность ответа очень сильно зависит от того, какой план собеседования предлагает технический эксперт. К сожалению, основной проблемой на этом этапе со стороны тех.эксперта, как это не странно, это отсутствие эмпатии к кандидатам.  В какой-то момент количество собеседований может достичь объема конвейера и для собеседующего это превращается в процедуру решения однотипных квестов с отсутствием индивидуального подхода. Стоит учитывать, что для большинства кандидатов процесс прохождения любого, а в особенности технического, этапа собеседования является большим стрессом. Идеальным, но довольно сложным при выше описанном конвейерном подходе является стратегия индивидуального плана для каждого кандидата. Если брать мой опыт, то я в начале каждого собеседования после этапа знакомства рассказываю кандидатам план предстоящей беседы: “Мы с тобой сначала пообщаемся по твоему опыту, далее обсудим.

Сюжетная линия Питера

Очень часто на этапе развернутых ответов на технические вопросы кандидаты пытаются добавлять в ответ очень и очень много лишней информации, либо  совершать подмену ответа. Тут может быть несколько причин: первая – за счет “воды” сделать свой ответ на вопрос более объемным и развернутым, а вторая – за счет подмены ответов вывести тех.эксперта в ту колею вопросов-ответов, которая удобна самому кандидату.

Например, в первом случае у меня бывают такие кейсы, когда я задаю кандидатам вопрос “расскажи про архитектурный стиль REST”, а при ответе кандидат пытается очень сильно размазывать ответ, рассказывая по-большей части про SOAP/gRPC/GraphQL и т.д. Или же бывают кейсы, когда кандидаты не знают, как ответить на тот или иной вопрос и стараются ответить через ту тему, в которой они ориентируются лучше. На самом деле что в том подходе, что в другом, чего-то криминального нет, если это используется в меру и без перегибов. Перегибы возникают, когда подобная тактика используется для ответа буквально на каждый вопрос. Однако, стоит учесть, что для структурности ответа лучше отвечать на тот вопрос, который был задан изначально.

Сюжетная линия Джоны

Невнимательность к деталям – основная проблема Джона при проведении технического ревью. Анализ таких деталей может помочь выявить расхождения реального опыта и заявленного в резюме/озвученного при ответах, а также помочь составить наводящие вопросы для того, чтобы полностью раскрыть уровень знаний кандидата. Речь здесь не только про анализ ответов тех, кто хочет как-то обмануть, но и помочь вытянуть тех, кто из-за специфичности в коммуникациях (скромность, волнение) не может дать полноценный и развернутый ответ на технические вопросы. При отсутствии внимания к ответам вполне себе неплохой технический специалист из-за своей скромности и закрепощенности может быть оценен сильно ниже реального уровня.

Общая сюжетная линия Питера и Джоны

Тут все просто и банально: будьте тактичными и уважайте друг друга. На мой взгляд стресс-собеседование в IT – это необходимое зло. Но при прочих равных вряд ли кто-то из вас выберет проект, где на тех. беседе вас жестко прессовали или принижали ваши достижения, а в альтернативу собеседования, где у вас был душевный диалог, где вы разошлись в отличном и приподнятом настроении. На моей практике был кейс, когда собеседующий очень высокого уровня по должности буквально с порога необоснованно кидался такими фразами как “разве это достижения? Пустышка” или “ну разве кто-то строит так процессы? Это вообще халтура какая-то”. Не самые приятные впечатления, после которых вряд ли захочется выбрать эту команду/проект в качестве дальнейшего продолжения карьеры.

Сюжетная линия Питера

Питер Паркер, рассказывая о том, какой он молодец, говорит, что он своими руками победил Джокера и переиграл самого Загадочника. Чувствуете подвох?  Одна из самых больших проблем, которую я замечаю в рамках собеседования, это притягивание чужих заслуг в свое портфолио. Очень часто я сталкиваюсь с ситуацией, когда, например, в резюме указан опыт работы с Kafka, а на деле оказывается, что она просто была в архитектуре системы в смежной команде, но тестировал ее кто-то другой. Или же человек пишет о том, что он выстраивал процессы в команде с нуля, а после череды вопросов по этой теме выясняется, что процессы строил лид, а он лишь поддерживал их в необходимом состоянии. Здесь стоит самостоятельно оценивать риски, если вы планируйте идти таким путем, так как если в рамках собеседования тех.эксперт не сможет выявить эти несоответствия, то при решении уже “боевых” задач может возникнуть риск большого фиаско.

Сюжетная линия Джоны

Основная проблема, которая возникает на следующем этапе – шаблонность и зацикленность на экзаменационном формате. Тут есть сразу два общих момента: первый – это тот самый конвейер, о котором говорили ранее, а второй – это эффект пестицида, когда одни и те же вопросы уже не позволяют релевантно оценить кандидата. Здесь стоит обратить свое внимание на то, что стоит готовить свой список вопросов по хардам для кандидата, опираясь на резюме, а также на сами требования к позиции. С точки зрения софтов необходимо тоже быть гибким при подборе вопросов, так как в разные проекты и продукты могут требоваться люди с совсем разными софт навыками. Где-то очень сильно будет превалировать коммуникабельность и открытость, а где-то наоборот будут решать стрессоустойчивость и умение работать в сжатых сроках, где-то будет требоваться полноценный селф-тайм-менеджмент, а где-то необходимо будет жестко подстраиваться под рабочий график команды.

Общая сюжетная линия Питера и Джоны

В рамках моего опыта, когда я был в роли кандидата, возникали такие моменты, когда после последнего тех.вопроса сюжет завершался фразой “Глеб, спасибо, на это все, хорошего дня!”, а после этой фразы тех.эксперт грациозно отключался от онлайн-встречи.  Не самое приятное и тактичное  завершение беседы особенно в те моменты, когда у тебя еще накопилась гора вопросов по стеку технологий, подходам к тестированию и т.д.

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

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

Общая сюжетная линия Питера и Джоны

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

Общая сюжетная линия Питера и Джоны

Читерить – плохо! Но не всегда:)

Самый плохой обман – это тот, который был раскрыт по ходу собеседования. Самый распространенный кейс читерства на собеседованиях – “гугление”. Но всегда ли это плохо? На мой взгляд – не всегда. Если кандидат обладает тех.экспертизой высокого уровня и использует шпаргалку для того, чтобы вспомнить ключевые слова и через пару секунд выдать развернутый ответ своими словами, то это говорит о том, что человек умеет быстро находить и/или анализировать информацию, что является очень полезным навыком. С другой стороны выступают “плохие читы”, когда кандидат явно тянет с ответом на вопрос, возникает долгая и неловкая пауза, которая периодически прерывается постукиванием по клавиатуре или клацанием мышки.

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

Какие итоги?

В заключение хочу сказать несколько важных моментов про то, какие есть подводные камни.

Во-первых стоит учесть, что идеальные метчи случаются крайне и крайне редко.

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

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

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

Спасибо за то, что дошли до конца этого сюжета и удачи вам в поиске вашей работы мечты!

Похожие новости

Innovative People — партнер конференции Jpoint 2024

24–25 апреля в Москве пройдет конференция для опытных Java-разработчиков Jpoint....

PRODUCT SESSION: развитие цифровых продуктов

4 апреля компания Innovative People провела экспертную PRODUCT SESSION про...

Оценка аналитика: взгляд со стороны IT-рекрутера

В новой статье для Хабра вы узнаете о том, как...

PRODUCT SESSION от Innovative People

4 апреля в Москве мы проводим экспертную сессию про роль...

Все статьи

Оставить заявку





Заявка отправлена успешно

Наши менеджеры свяжутся с вами в ближайшее время