Comments 33
Ну, хорошо, как убедить себя, что произвольный кандидат вам не подходит, вы изложили достаточно подробно и с примерами. А вот как нанять подходящего -- как было проклятой тайной, так и осталось :)
Вероятно, автор предполагает что нужно максимально отсеять неподходящих кандидатов, а на втором собеседовании, вероятно, уже другие стратегии.
Как понять, подходит кандидат или нет - та самая незамысловатая "чуйка". Практика показывает, что она намного надежней тестов, поскольку учитывает софт скиллы.
Когда я собеседую кандидатов, я уже понимаю, кто мне нужен.
Если у меня позиция автоматизатора на определенном проекте, я прекрасно понимаю, какие мне нужны качества и уровень кандидата.
Аналогично по ручникам. В зависимости от проекта и состава имеющейся команды я понимаю, могу ли я себе позволит инвестировать больше в развитие кандидата, или мне нужен сотрудник с твердой базой и знаниями в определенных областях.
Данная статья скорее про то, как сэкономить время и себе, и кандидатам, чтобы не проходить через все этапы собеседования, чтобы не разочаровываться низким процентом найма на финале.
Просто отсеивайте, пока не останется нужное вам количество.
Браво! Великолепный комментарий, но автор же из тестировщиков - вот и подход у него такой же: берем спеку (резюме) и тестируем заявленную функциональность. Увы, на выходе после такого тестировщика кандидатов будет вердикт - "данный кандидат не наврал в своем резюме про свои скилзы". Однако главный вопрос - справится ли он с ожидаемыми обязанностями останется не закрытым.
Я как-то общался с одним умным директором софтового PnL на тему, почему мы так неэффективно набираем людей - по факту потом просто с кем-то везет, а с кем-то нет! Он сказал интересную мысль, что мы тестируем кандидатов по навыкам в тулзах, которых много и в каждом месте они свои, но после полугода работы любой технарь освоит локальные тулзы на должном уровне. Однако ни через полгода, ни через год кандидат не станет тем, кем не был по личностным качествам и образованию. Поэтому по скилзам можно брать людей только на проект - наемников, а в постоянный коллектив нужно больше смотреть на мотивацию и личностные качества. А для этого человека нужно раскрыть на собеседовании, а не застрессовать проверками на устойчивость психики.
Однако статья полезная - вот портрет того, с кем вы встретитесь на собеседовании, изучите его по данной статье.
Я не думаю, что это фича только тестировщиков. Просто сейчас, когда рынок чутка качнулся в сторону нанимателя, опять из людей полезло лучшее в плане того, что "я их всех на чистую воду выведу". В итоге имеем массу методик доказывания "кандидат не то, что написал о себе в резюме, ща мы ему стыдно за это сделаем на пять лет наперед", но ни разу решение задачи "как распознать того, с кем можно работать, с минимальным отсевом".
В конце концов, насобачить за примемлемое время практикам конкретной компании можно практически любого, кто в индустрии провел от пяти лет, а вот воротить нос на почве "да он не знает, как в книжках называется этот вид процесса (не то, что я), значит, и специалист никудышний" -- это, конечно, самолюбованию потрафит, но вопрос найма задвинет подальше по шкале времени.
Супер - как и в прошлый раз, радуюсь точности ваших формулировок. Осталось понять, что же делать с поиском работы на таком вот рынке труда сегодня? С уходом глобальных компаний, которые задавали планку, отечественный рекрутмент в непонятном состоянии. Даже архаизироваться до советского не получается, так как тогда кадры были в цене - подход другой. Забавно еще слышать про какие-то программы возврата ИТ специалистов - тут имеющихся не получается трудоустроить. Ну да, впрочем, программы-то тема бюджетная, а там другая логика.
Попытаюсь формализовать свои критерии:
Хард скиллы:
Junior - знание + понимание теории, умение применить ее на практике. Если заявлены ЯП - знание базовых структур данных, умение написать простой код. Умение рассуждать.
Middle - все, что junior + знание своей профильной предметной области, знание и понимание тех инструментов, с которыми работал. Системный подход к решению задач. Понимание внутренних процессов. Если заявлена автоматизация - умение читать и анализировать чужой код, понимание принципов работы инструментов. Алгоритмистика. Знание и умение применять архитектурные подходы. Базовые знания CI/CD
Senior - Middle + глубокие знания своей предметной области, инструментов, эффективности их применения. Умение работать в условиях недостаточных вводных, учитывать при решении задач внешние факторы. Если заявлена автоматизация - знания тонкостей работы инструментов, Ci/CD, умение реализовать методы, спрятанные под капотом тест фреймворков.
Lead - Senior + менеджерские качества, знания процессов, подходов к оптимизации работы команды, оценка и планирование. Умение декомпозировать задачи, оценивать риски.
Софт скиллы:
Помимо классических аспектов вроде общения, невербалики, я крайне ценю кругозор, умение быстро погрузиться в предметную область, умение слушать и слышать. Это хорошо заметно, когда даешь подсказки, либо дополнительные вводные в задачах.
По итогу выбор делается по принципу: хард скиллы позволяют выполнять задачи, не потребуется инвестировать несколько месяцев в обучение. Софт скиллам отдается очень большой вес. И оценка перспектив развития сотрудника (эти последние пункты я и называю "чуйкой").
Если рассмотреть на примере, то, допустим, есть 3 кандидата:
1. Супер харды, но большие вопросы по софтам
2. Слабые харды (ниже требуемого минимума), но "рубаха-парень"
3. Харды на грани, возможно даже чуть ниже минимума, но обучаем, широкий кругозор и хорошие софты.
Из трех кандидатов я выберу кандидата (3). И ключевая причина - софты, кругозор и обучаемость.
Обучать придется всех, и моя задача найти того, чье обучение пройдет наиболее быстро, гладко, и чей потенциал не ограничится этими начальными задачами.
Также стоит отметить, что критерии могут отличаться в зависимости от того, насколько "горит" та или иная вакансия. но это тема, заслуживающая отдельного поста, т.к. там придется лезть в вопросы бюджетов, законодательства, бизнеса, развития, ROI и т.д.
На практике же я регулярно сталкиваюсь с ситуацией, что на последнем этапе отсеивается 90% кандидатов.
Из статьи непонятно, решили ли вы у себя эту проблему. Какое соотношение вы получаете для своих собеседований? (процент отсеивания на последнем этапе).
На текущем месте работы я вскрыл эту проблему и она в процессе решения. Проблема как раз на этапе технического собеседования - шаблонность вопросов и ответов.
На предыдущем месте работы, где я провел огромное число собеседований, мы придерживались другой системы собеседований.
Если кратко, то был скрининг со стороны HR + один очный этап длительностью час-полтора с экспертами + в некоторых случаях технический тест на пару часов. По итогу компании такие собеседования обходятся дороже, но календарно они очень быстрые, и оценка кандидатов была более широкой.
Конверсия была высокой за счет отсева на этапе скрининга со стороны HR.
Но, справедливости ради, там была довольно узкая область и поток кандидатов в принципе был не такой большой, как в вебе.
Добрее и терпимее надо быть к людям, иначе упускаете много вкусного. Не забывайте, что процесс найма - взаимный и Вас точно так же тестируют те, кто пришел к Вам устраиваться. В противном случае с теми, кого Вы в итоге наймёте, будет очень неприятно работать.
Вы правильно говорите, что собеседование - это взаимная история. И именно поэтому очень важны в том числе и вопросы соискателей.
По вашему комментарию я приведу такой пример...
В детстве мы часто во дворе играли в футбол, и капитаны набирали команды по принципу "драфта". То есть по очереди выбирали себе в команду игроков и общей массы.
И задайте себе сами вопрос - если вы хотите победить, вы будете выбирать друзей, или лучших, исходя из ваших потребностей?
По поводу "будет неприятно работать" - это зависит от множества факторов. Нанимаются не набор качеств, а люди, личности. И итоговый результат работы зависит во многом от того, как вы сможете выстроить совместную работу. Будешь ли ты, как работодатель, закрывать потребности сотрудника, будет ли он разделять твои ценности, и будешь ли ты прислушиваться к потребностям сотрудника.
Если ваши интересы пересекутся, то, с высокой долей вероятности, вас ждет успех.
Тоже провожу техническое собеседование.
Иногда подключаюсь на этапе 0 - вместе с HR смотрим все отклики и подходящие резюме еще до первого созвона.
Та самая незамысловатая "чуйка" работает и здесь, потому что иногда кандидаты пишут только набор тегов типа "C#, Docker, Selenium, InfluxDb, ELK" и больше ничего.
HR может такое резюме оставить без внимания.
После заявления, что для мобильных приложений не применяется кросс-браузерное тестирование, статья "профессионала" выглядит нелепо.
Я вполне могу чего-то не знать. Это нормально. И готов исправить недочеты в статье, если таковые есть.
Расскажите мне, пожалуйста, пример применение кросс-браузерного тестирования в мобильном приложении.
Не кросс-платформенное тестирование, а именно кросс-браузерное. И не мобильной верстки, а именно приложения. Того, что в конечном счете попадает в маркет.
Мобильные приложения бывают не только нативные. Гибридные, которые качаются из маркета, тоже могут использовать браузер. Как раз на таком проекте и работаю. И да, у нас тоже есть для них автоматизация.
И еще:
Большие вопросы к владению терминологией. То же Модульное тестирование (англ Unit test), которое присутствует на «ручных» проектах, и к которому в индустрии команда QA не имеет никакого отношения.Модульное тестирование в мануальном это один из уровней детализации:
-модульное
-интеграционное
-системноеИ это если не брать автоматизацию. Так что вопросы к владению терминологией не к кандидату.
Я тоже несколько удивилась, так как тестировала приложение для мобильного для разных браузеров. А ещё "
Великолепным примером является простая задача: В программе есть поле ввода, которое принимает на вход значения от (-10; 10] . Необходимо протестировать это поле.
Часть кандидатов предлагает просто перебрать все значения. Тогда я увеличиваю диапазон до миллионов."
Это, по-моему, вот первое и самое элементарное, что должен знать тестировщик. Не вяжется, как с таким серьезным подходом к собеседованиям, как у автора, такие люди вообще доходят до собеседования
Как мобильный тестировщик хочу уточнить, зачем "кросс-браузерное тестирование" в мобилках, да и в принципе как?
Ведь даже если у нас фул веб, оно написано на js.
Не берусь утверждать, но если вы имели ввиду тестирование веба на мобилках - это не тестирование мобильных приложений, поправьте если не прав.
В голове крутится только тестирование моков, т.к. иногда они ведут на веб-страницу сервиса и открываются в выбранном по умолчанию браузере, только если так.
очень сомнительная статья. С самого начала автор делает заявление, что за 10 лет ни разу не ошибся, а это уже звоночек. В психологии в разных тестах (например, тест Айзенка о типе темперамента) есть вопросы, которые проверяют честность респондента. Один из них звучит примерно так: "ошибаетесь ли вы?". И если человек отвечает, что нет, то это однозначно вранье, потому что так просто не бывает. Это как если тестировщик скажет, что за 10 лет работы не пропустил ни одного бага.
Собственно, остальная статья лишь подтвердила опасения. Изначально автор подходит к кандидатам как к лжецам, которые врут в резюме. Эта проблема отчасти существует, но не носит массовый характер, при этом она характерна для молодых специалистов без опыта. Для мидлов и синьоров эта ситуация если и бывает, то редко. Тем не менее у автора статьи изначально была обозначена проблематика (см. картинку лошади) - в резюме кандидат герой, на собесе бестолочь. В такой парадигме предвзятости и агрессии автора к кандидатам, любому специалисту, в том числе тому кто действительно профи и в резюме все ок, будет некомфортно общаться.
На протяжении всей статьи красной линией идет не желание найти хорошего кандидата, а отсеить плохих, везде плохие, ух какие плохие, надо из отсеять. Вспоминается Шариков из Собачьего сердца: "мы их душили, душили...".
Если говорить о пользе статьи, то советы соискателям либо банальны: "Пишите так, чтобы вы могли аргументировать написанное", либо спорные, например, про то, что надо писать достижения, которые якобы скажут что-то о профессионализме или совсем уж странный совет: "В резюме должен быть фактор недосказанности." - прямо как в девушке должна быть загадка, так и в резюме нельзя раскрывать все, а то сложно будет собеседующему придумывать вам вопросы. Не пишите все, облегчите жизнь собеседующему. А то, что такой подход недописанного резюме может кого-то раздражать как раз за то, что у представителя работодателя неполная информация о ваших навыках, автор статьи разумеется не учитывает.
Да, мне тоже резанула такая самонадеянность,
а также уверенность автора в том, что кто-то ему проводит этап номер 1 (предварительный обзвон всех кандидатов). Он даже не в курсе, что сегодня при конкурсах по 500+ человек на позицию (спасибо hh.ru за глобальную доступность всех позиций всем кандидатам !), это физически нереально, поэтому есть этап номер 0, когда либо бот, либо рекрутер-бот со списком шаблонных требований отсеивает по формальным критериям 90%+ аппликаций без любых форм контактов с кандидатами.
Забавно при этом видеть жалобы на то, что у всех кандидатов стереотипные резюме - это не кандидаты одинаковы, а входной фильтр узкополостный! В этом плане уместнее делать случайную выборку менее 10% входных резюме, чем фильтровать по параметрам.
Однако статья полезная тем, что рисует нам портрет типичного собеседователя - будьте готовы к такому! Цитата из Собачьего сердца весьма уместна - профессиональный собеседователь должен раскрыть кандидата, а не зачморить. Но увы - именно таковы сегодняшние реалии.
Скажу как соискатель, вся статья в общем и целом звучит адекватно, рад что она вышла из песочницы т.к. есть хорошие советы тем, кто только составляет резюме.
- Совет "про фактор недосказанности" пушка, хоть и не часто, но получается мелькнуть крутым опытом
- И самое главное "Пишите так, чтобы вы могли аргументировать написанное", рассчитываю что соискатели обратят внимание.
Меня как-то раз унизили вопросами в зарубежной компании из-за написанного git в инструментах, хоть и работал с ним год назад, поэтому ребят, указывайте только то за что шарите и можете рассказать.
Так же спасибо за эту перспективу со стороны интервьюера, никогда не задумывался о том как размышляет собеседник, и вот так сразу, за пару минут применить на себе его роль - оч круто.
От себя добавлю, что при составлении резюме старайтесь придерживаться определенных принципов:То есть предыдущие части статьи были написаны не Вами? :-)
Подкол засчитан =)
Правильнее сказать, что это мои предпочтения к составлению резюме.
Вообще тема содержимого резюме - тот еще раскрученный вентилятор... Посмотреть рекомендации разных компаний и рекрутеров по составлению резюме, так по доброй половине пунктов рекомендации будут строго противоположными.
Извечная проблема: не имеешь опыта работы с инструментами - не достоин вакансии:) Почему бы кандидату, который никогда не имел опыта в использовании Appium, но имеет опыт работы с другими инструментами автоматизации, не дать шанс показать себя на проекте? Ну или соискатель не имеет опыта работы, допустим, с Android studio, но ориентируется в программе - почему бы такому соискателю не дать шанс? Естественно, что прежде чем давать шансы, нужно оценить тулзовину, сложна ли она в освоении или нет.
А вот это очень правильный замечание. Вы правы, что многие компании ищут себе готового кандидата, который умеет в наши инструменты.
Особенно остро этот момент ощущается, когда ребята переходят из одной области в другую. Например из Embedded в Web. Знания инструментов нет, тонкостей работы с определенными аспектами тоже. И очень многие высококлассные специалисты получают отказы, потому что даже до джуна не дотягивают.
И здесь я с вами полностью согласен - когда я собеседую кандидатов, мне вторично, с чем он работал. Для меня важно - понимает ли он, как решать ту или иную задачу. Инструмент освоить проще, нежели научиться думать.
Возьмем пример из реального собеседования.
У кандидата написано - кроссплатформенное тестирование. Задаю вопрос, что делал - отвечает, что запускал скрипт на win и *nix машине. Все.
Но написано же кроссплатформенное тестирование, может действительно опыт был сильно ограниченный, но есть видение, как это в принципе происходит?
Уточняем у кандидата, что за скрипт, что делал. И задаем дополнительный вопрос - как бы он протестировал работу определенной функциональности этого скрипта на разных платформах?
И вот если кандидат не может ничего сказать, кроме как "запустить скрипт", то для меня это сигнал.
Мы очень трепетно относимся к подобной строгости в IT. Как же так можно? Вы нелюди, не даете кандидатам проявить себя! Но давайте проведем параллель.
Если у хирурга будет написано "опыт проведения операций на сердце", но на вопрос о том, что он делал, выяснится, что он подал зажим оперирующему хирургу. А на вопросы, как делается операция он не может ответить ничего, кроме как того, что пациента нужно разрезать, и обязательно нужно приготовить зажим, вы пойдете под нож к такому хирургу?
Также многие забывают, что IT бывает разным, и требования в разных областях отличаются, цена ошибки также может сильно разниться.
Раньше я работал в области разработки электроники. Цена ошибки - отзыв продукции и разорение компании.
Затем была медицина. Думаю комментировать цену пропуска ошибки не стоит.
Аналогично по другим направлениям, с которыми я работал и продолжаю работать. Цена ошибки в этих отраслях очень высока, и это одна из причин, по которым я ставлю высокие требования к кандидатам. Я готов научить инструментам, я готов погружать в предметную область, но только если кандидат демонстрирует способность к этому обучению.
В то же время я прекрасно понимаю, что есть множество других направлений бизнеса, где можно закрыть глаза на многие вещи, что-то в принципе не делать. И в этих компаниях действительно нет столь острой необходимости требовать от кандидатов глубоких знаний и понимания работы в разных областях.
Все это хорошо в теории, но на практике никто не проверял, насколько хороши взятые и насколько плохие отсеянные кандидаты.
Так же полезно разделять опыт и навыки.
Достаточно спорного качества статья с технической точки зрения. Кроме того, местами пробивается неуважение к коллегам по цеху, что в наше время расценивается в профессиональном мире как "no-go".
1) Статья из разряда "популярное творчество". Даются общие рекомендации без погружения в детали, нет плана на интервью, нет матрицы тематик, в рамках которого идет assessment QA-специалиста, приводимые live coding задания идут под маркой "Hello World!".
В статье контент для HR-специалистов и социологов, а не инженеров.
2) Автор спрашивает почему во фреймворках "UIAutomator, XCTest и Espresso" не указаны языки. Да потому что указывать, например, на чем пишутся тесты под Espresso - Kotlin или Java - смысла особо не имеет, ибо индустрия уже давно смотрит не знание конкретного языка программирования, а на общий уровень алгоритмической и инженерной подготовки специалиста. Язык программирования идет следом, и за карьеру software engineer может меняться много раз. Кроме того, этот пункт легко проверяется через ряд простейших заданий на интервью.
3) Автор ссылается на несоответствие в мелочах в CV - модульное тестирование, "переделал с нуля", ищет связи в копипастах между проектами в части выполняемых обязанностей. Моя личная практика показывает, что даже "бледные" CV на входе не являются критерием профессионализма соискателя или индикатором отсутствия квалификации в этой области. Более того, были случаи, когда люди присылали очень посредственные CV, а потом отлично проходили собеседования и становились локомотивами целых направлений в компании.
Работает и наоборот - соискатели с великолепным CV c треском проваливались на собеседовании.
4) Автор пишет, что "мне прислали резюме senior QA инженера с опытом работы 5 лет. Работает на «галере»."
Посмотрел, где работает автор, и последние 5 мест его работы. Улыбнуло про "галеры".
Summary: За сим откланиваюсь с надеждой, что автор будет менее щепетилен к форме, и более внимателен к содержанию, что позволит ему не пропустить кандидатов, которые могли бы усилить его компанию.
Спасибо за комментарий.
Написанные тезисы абсолютно верны, и я с ними полностью согласен.
Только статья несколько про другое. Она про то, что я на своем опыте сталкиваюсь с множеством кандидатов, которые знают теорию, но не могут в практику. И проблематика в том, что техническое интервью не выполняет своей прямой функции.
По поводу галер не понял комментарий. Зная специфику работы на галерах, я понимаю как потенциальные сильные стороны кандидата, так и слабости, которые нужно будет проверять на интервью.
Равно как и остальные пункты в разборе CV - это якоря, от которых я отталкиваюсь при общении про опыт и решаемые задачи.
Также полностью согласен с тем, что содержание не отражает форму. Это истинная правда. Я лично неоднократно сталкивался с тем, что кандидат с бледным резюме оказывался неграненым алмазом. Были и ситуации ровно наоборот. Это правда жизни.
Так много едких комментариев, однако не совсем понимаю зачем так придираться. Я вот лично не увидела никакой агрессии или недоверия. На мой взгляд совершенно нормально, что человека просят подробнее рассказать про свой предыдущий опыт и пояснить что в его понимании значит владеть навыком.
Так же считаю, что структура довольна наглядна:
Определись кто тебе нужен, выпиши софт и хард скилы и ищи. Логично, понятно и просто. Предположу что в какой то момент у читающих резонирует прочитанное с личным опытом на столько, что остальное из памяти стирается.
Большое спасибо автору за статью) обязательно пишите ещё!
Собеседование в QA или Кошки-Мышки XXI века