Чем заменить тестовое задание на собеседовании?

управление
#1

Всем добрый день.

Опишу свою ситуацию вкратце: большая компания в Европе, у которой очень много сотрудников из команий-партнеров, расположенных в Индии. Я непосредственно вовлечена в процесс собеседования новых сотрудников, в том числе и из Индии. Кандидаты на роль автоматизаторов должны выполнить тестовое задание - написать простенький фреймворк для 2-3 тестов по требованиям (поиск в Гугле), прикрутить репорт и причесать весь проект, чтобы он запускался на любой машине. После ревью тестового задания мы созваниваемся с кандидатом, проходимся по написанным тестам, задаем вопросы и принимаем решение брать или нет.

Я бы хотела этот процесс поменять по несколим причинам:

  • кандидатам нужно тратить несколько часов на задание, что не слишком-то приветствуется начиная с мидл уровня. Не хочется тратить время специалистов зазря.
  • некоторые кандидаты просто переиспользуют один раз написанный фреймворк и подгоняют под тестовое задание. Что не проверяет почти никаких навыков автоматизации.
  • в комании уже есть свой тестовый фреймворк, и навыки его построения с нуля не так уж и важны.

Поделитесь идеями, как можно усовершенствовать процесс?

Я думала над идеей написать свое небольшое приложение с багами и кривыми тестами к нему, давать кандидату и просить проанализировать и улучшить. Здесь может быть проблема в том, что комании в Индии очень заинтересованы в продаже нам инженеров, и могут начать сливать им всё, что нужно исправить еще перед интервью. Переписываить задание каждые 2-3 месяца будет для нас очень накладно.

Что еще можно сделать?
Спасибо!

%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%96%D1%81%D1%82

1 лайк
QA Weekly #5_2019: тестовое задание, организовать работу QA, Git, Rest-Assured.
#2

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

После такой кодинг сессии - уже спрашивать по опыту и глубине знаний.

#3

Спасибо, но мне кажется, вы не дочитали мое сообщение до конца.
Это как раз то, чего бы я хотела избежать, так как через 5 собеседований hrы соберут примерный лист недочетов и смогут подготовить по нему следующих кандидатов.

#4

Тогда мне видится только вариант с начальной фильтрацией кандидатов с помощью грамотно подобранного набор задач на Codility (ограниченных по времени) + для прошедших этот этап - техническое интервью с секцией кодинга.

1 лайк
#5

Так, давайте по пунктам:

Не жалейте их, им нужна работа и они должны делать свое дело. Тут все просто. Да, это не должно доходить до маразма в целый рабочий день, но считаю 2-3 часа потратить ради вакансии - норма.

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

А вот тут бы я поспорил. Да, они не важны сейчас, когда и фреймворк есть и архитектор на месте. А представьте что архитектор ушел и нужно хорошенько перелопатить фреймворк, что делать тогда? Хотябы базовые вопросы по архитектуре тестового фреймворка был должны кмк.

Теперь предложения:

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

#6

А как вы видите проект, который сам бы рандомизировался? Звучит красиво, но у меня не хватает фантазии на реализацию.

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

С вашими пунктами я в большинстве согласна, один только комментарий по поводу фреймворка. Все архитекторы и автоматизаторы от синьора и выше (я не про набор скилов сейчас, а только про название роли), сидят у нас в головном офисе в Англии. И какие бы ни были “аутсорсеры” умнички, они рефачить фрейворк не будут сами по себе. Поэтому и не так важны эти скилы.

#7

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

  • В чем отличие css и xpath?
  • Какой локатор можно назвать “гибким”?
  • Какой из “локатор1” и “локатор2” гибче?
  • Какие функции xpath локаторов вы применяли и зачем они нужны?
  • Если айди или классы динамические - как будете строить локатор?
  • И тд…

Думаю после таких вопросов будет сразу понятно о кандидате много, в том числе готовили его HRы к разговору с вами или нет.

Пользуйтесь этим

3 лайка
#8

Поняла вас, спасибо! :slight_smile:

#9

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

3 лайка
#11

Если такой пример дадут кандидату он даже разговаривать с вами не будет, просто встанет и молча уйдёт))

#12

Да, вот к чему-то подобному я и склоняюсь. Скорее всего возьмём за основу наш тестовый фреймворк, обережем его хорошенько и напишем парочку кривых тестов.
Спасибо!

#13

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

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

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

Самое странное, что я в последнее время слышал на интервью:
– вот есть массив элементов, сделай сортировку массива по таким-то критериям (все на листике)
– отличия Java 8,9,10,11 между собой
– вот список коллекций, какие из них невалидны (и ты сидишь разглядываешь строки, написанные от руки за пару минут и естественно путаешься)
– (тоже интересное) расскажи какие паттерны знаешь, минимум 10 штук и какие антипаттерны, причем надо давать им названия как в литературе
– (“мое любимое”) целый час вопросы по силабусу ISTQB Fundamental level от принципов тестирования и до “роли в команде”, я был в шоке когда спустя 8 лет в отрасли меня такое спрашивали.
– ну еще одно: надо написать SQL скрипт с джойном 5 таблиц, тоже на листике.

Как говорится имхо

9 лайков
#14

Зачем в таком случае вообще что-то спрашивать на собеседовании. Просто спрашиваешь - “автоматизировать могешь?” или “код на джава писать умеешь” - берем тебя в гугл сразу). Все равно - что тратятся деньги на поиск кандидата, его адаптацию и тд.

#15

А как вы обычно понимаете, как человек соображает?
Я тоже всеми руками за то, чтобы понять, комфортно мне с человеком или нет. Это в несколько раз сложнее сделать, когда собеседование по телефону и нет возможности оценить поведение по разным критериям. И вот сидишь, слушаешь и пытаешься за 30-40 минут понять кто там на том конце.
С хоть каким-то тестовым заданием получается более предметный разговор.

#16

Надо исходить из задач, подумать какие качества вам нужны от человека и на основе их построить общение, конечно же это трудно, но еще ж не просто так есть испыт.срок.

Мы давали ряд задач, от банальных SQL, вопросов по API тестированию и до неправильно описанных user story, важным было решать их вслух, чтобы мы понимали как он думает и вообще думает ли.
Ну и дальше: “а вот если так”, а “если такой сценарий и такой-то функционал”, “как бы ты мог это решить”.
Были случаи когда кандидаты увешанные сертификатами, но простых вещей не знали, думать - не думали.
Научиться писать тесты - дело двух недель, я например не стесняюсь говорить, что загуглю если не знаю как решить чего-то, даже разработчики 80% пользуются инетом и честно признают этот скил, а мы почему-то решили, что мы особенные и требуем знания всего и вся от человека на интервью, хотя по факту в работе у него будет интернет и любой вопрос решится в течении минут, максимум часа.
Надо изменить чуть-чуть свое отношение к людям.

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

Важно быть гибким, например: я писал UI тест, тут проблема от коллег - “иногда падает какой-то сервис в системе”, пошел помог - написал нагрузочный тест, нашли причину, что каждый 5й запрос в очереди падает, всё - тикетом занимается теперь разработчик, вернулся к своему UI тесту, тут узнал, что моя фича работает через API - загуглил и узнал, что есть Rest Assured библиотека - подключил, гляну мануал - написалл 10 тестов для проверки API.
Хотя этого никто не спрашивал на интервью и никто мне не ставил задачу, есть бизнес, которому нужен данный функционал, мы помогаем бизнесу. Точка.

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

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

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

5 лайков