Комментарии 18
сколько раз за сутки стрелки часов, минутная и часовая,
ну такое... это задачка из детских книжек типа кордемского, но в целом и сообразить несложно. другое дело что я хотя и довольно легко себя с подобными чувствую (как измерить большую диагональ кирпича если есть три, как перевезти огромную трубу на лодке при том что труба в неё не помещается - это из Епам на сеньора биг-дата) - абсолютно согласен что пытаться что-то выявить с помощью таких задач - полный бред. просто потому что если человек ответил правильно - большой шанс что он тупо знал задачу, нежели думал-думал и придумал.
Ну понимаешь, мне говорят что-то в духе "а сейчас будет математический вопрос" (я точно не помню) - я в голове прогоняю основные метрики, думаю про алгоритмы шифрования трафика, а мне тут вопрос про часы задают.
Что, какие часы? (какое это имеет отношение к тестированию??) Протестировать часы? А, посчитать. Да ну нафиг, щас так на практике проверим (примерный ход моих мыслей)
Это только в тестировании такая атмосфера?
За дюжину лет на ру-рынке я крайне редко (возможно, никогда) встречал задачки "на сообразительность". Хотя многие собеседования меня всё равно бесили и я с удовольствием бы их избегал и не работал вообще - настолько профессия разработчика мерзкая на пороге. Но похоже, бывает ещё хуже, а мне попадались котятки в основном.
обучающиеся на курсах часто демонстрируют невероятное упорство и желание работать, и мне это нравится. Это притягивает!
Человек работал и учился на профессию X, при очередном трудоустройстве ему задают пространные вопросы не относящиеся к конкретным обязанностям. Полно разных по уровню задачек, на которые в конкретный момент можно не ответить. А такой выходишь с собеса, а точно понял, это же имелось ввиду то-то.
Вот просто пару примеров из личного опыта (в данный момент не про текущий проект) и нанимал тогда еще не я (да, это все истории про крупные компании, где тестировщиков было 50-250 человек):
1) наняли джуна после курсов (отвечал блестяще). проект большой, сложный, онбординг реально 3 месяца - куча взаимосвязей и т.д. Но есть и план онбординга и AQA Senior приставили к нему чтоб отвечал на вопросы. День, два, три.. все нормально? - Да-да. Помощь нужна? - Нет, я сам. Прошла неделя. Пнд, дейлик. Созвон: что сделал? как успехи? - Молчание. После "допроса" выясняется что чел ничего не понял, тетсинг у себя развернуть не смог и впал в прострацию.
2) наняли (по его словам) мидл-мануал тостера. на собесе отвечал что с Постманом работал, на вопрос про авторизацию ответил про basic auth, bearer token и пр. Вышел на испытательный, первая задачка как раз про авторизацию у него. Пнд тишина, вт обед: у вас это гавно не работает (jwt у нас, как выяснилось он про него не знал). Погуглить первую попавшуюся статью на Хабре? - Нет. Спросить коллег? - Нет.
п.с. у чела 4 года опыта в резюме.
3) пришла к нам РМ, которая осталась из-за дурдома творящегося на рынке ИТ последние годы без работы. У нее помимо опыта работы РМ собственная студия (была) хенд-мейда, где она сайт принимала и тестировала сама (больше опыта нет). Искала работу парт-тайм, т.к. в декрете с маленьким ребенком, а денег не хватает. На вопросы по теории отвечала на 3-
QA lead наша настояла, что надо дать ей шанс. Дали задачку (к слову, задачка была написана хреново) - что-то про верстку и забыли про нее. Через полдня девочка приходит: так, я вашего РМ отловила, требования уточнила, с программистом созвонилась по ТимВиеверу - он мне помог развернуть тестинг, задачку в БраузерСтаке проверила - у меня там свой аккаунт с прошлой работы. Что дальше делать?
Вопрос: с кем в итоге мы проработали полтора года(я про позицию QA-junior) и кто у нас потом стал на дочернем продукте РМ и пошел вверх по карьере после выхода из декрета?
Вопрос №2. Что важнее: знание теории и правильных ответов или способность разобраться и применить это на практике?
Из описанного вами, всё зависит от удачи получается:) Возможно, нужно более детальней спрашивать про текущий стек, на который нанимаете.
Честно, не понял при чем здесь удача. Я говорю про найм специалистов уровня QA Junior+ / QA Middle (manual). К слову, QA manual - это уникальная профессия, существующая только на рынке СНГ. На том же Indeed, Glassdoor, других международных биржах найма мануальщики к QA не относятся (их называют просто "tester"и они в "пищевой цепочке" тестировщиков стоят ниже QA и вилка з/п у них ниже.
Так, вот, если человек джун/ручник, УСЛОВНО он знает 10%, 20%, 30% из того, что ему надо знать, чтобы стать хорошим специалистом в этой профессии на рынке ЕС/США. И на этом этапе карьеры на мой взгляд для гораздо важнее:
1) способность человека быстро адаптироваться, изучать новое, проявлять инициативу, готовность разбираться каждый день с тем, что он еще не умеет (потому что постоянно будут прилетать разные задачи на разных проектах, где ему надо будет подтягивать квалификацию)
2) способность и желание предвидеть баги. я бы это назвал так.
поясню на примере.
-есть тостер А - проверил задачу по DoD-ам, двинул дальше. На проде вылазит баг: меня это не касается, разбирайтесь с ПМ и разрабом, кто так хреново ДоДы писал, что это не учел. У меня все ок, рабочий день закончился, бай-бай
-есть тостер Б - пришел к разрабу, попросил написать QA Notes к задаче ему (где будет указано на что обратить внимание при проверке, что могло сломаться). У тостера Б квалификация ниже (он это осознает) и идет смотреть "вокруг". И.. сюрприз.. по итогам месяца испытательного срока у него нет пропущенных багов на прод, в отличие от тостера А.
Я говорю о том, что я смотрю больше на качества, а не заявленные навыки при найме джунов.
п.с. наверное надо уточнить, что я подразумеваю, что базовые вещи (например, коды ошибок) человек знает. Но если на вопрос "а почему вот мы щас смотрим сайт и ты не упомянул из техник тест-дизайна state transition diagram мне человек честно ответит, что он забыл/не знал это, но щас погуглит и скажет как это применить к сайту этому" - это для меня не повод ставить крест на собеседуемом (как у нас очень любят делать: он не смог ответить на это простейший вопрос по теории - все, отсекаем кандидата)
Программист въезжает в проект несколько месяцев, а тестировщик уже на следующий день, должен знать, что где сломалось, так получается? Он ещё zoom не успел настроить для дейликов, а ты ему давай тестировай.
Эмм, вы в каком-то мире розовых пони живете. Вот один из моих кейсов за последние 2 года с фриланса (фиксированный контракт на 3 месяца, оплата по результатам, все прописано по каждому пункту):
1.Компания в стадии банкротства (не де-юре, но по факту);
2.Предыдущая команда ушла практически в полном составе;
3.Нужно за 3 месяца разгрести бэклог в 1,000 тикетов/багов оставшийся;
4.Нужно за 3 месяца с РМ и владельцем решить что убивать, а что оставлять из нескольких десятков сайтов и сервисов, которые были;
5.Нужно запустить процессы (или хоты бы) написать протоколы для будущей команды тестирования. исходя из п.1-4.
Если бы я вкатывался несколько месяцев - я бы вылетал с испытательного срока на любой работе через неделю-две.
Два месяца это я конечно переборщил. Согласен с вами.
3 месяца это 12 недель 5 рабочих дней в неделе, 60 рабочих дней. 1000 тикетов делим на 60 это по 16 баго в день. Для этого нужен не просто тестировщик, а терминатор тестировщик:)
Спойлер: я справился :)
по сути 50% работы - это была работа с бэклогом: приоретизация, актуализация, обновление тасок, закрытие и cancel тасок по проектам, которые не будут поддерживаться, заморозка тасок и сайтов на которых сейчас нет команд и на которые нет денег и они не приносят прибыль.
Да, это была долгая нудная работа когда мы сидели на коллах по 6-8 часов неделю и проговаривали каждую задачу и ее необходимость.
А вот после недели такой работы уже осталось 500 тасок/багов, которые действительно имело смысл проверять.
Спасибо за статью, действительно очень полезно и познавательно. Мне нравится Ваш подход к найму. Будет здорово, если побольше компаний выберут похожую стратегию
PS: прошу прощения, но не могу не отметить, что называть в комментариях тестировщиков «тостерами» крайне неэтично😕
Ну, и индийцам опять досталось…
1.разница в ментальности/терминологии. я ведь писал выше, что последние (скоро уже 3 года) я работаю на рынке ЕС/США. в стартапах, с которыми я работал, принято разделение на QA engineer, QC, QA Analyst, tester. И эти люди выполняют немного разные задачи.
- то что у нас в СНГ называется AQA == QA в США. т.е. даже джун будет 30% времени заниматься автоматизацией, а 70% - ручным тестированием.
- то что у нас называется manual QA == tester в США.
И когда я говорю тестер/тостер я уже по привычке просто подразумеваю тестировщика, который занимается только ручным тестированием и не понимает код. ничего более
2.индусам будет доставаться еще очень много раз - вы просто не пробовали с ними работать или нанимать их.
п.с. да, я понял, что для вас "тостер" (исходя из принятых обозначений в СНГ) == пренебрежительное обращение к тестировщику
Мне очень понравились примеры из статьи, буду использовать, а понравились тем, что мы из примеров действительно поймем насколько кандидат будет глубоко копать, а это в скоупе зависит от набора компетенций, навыков, владения инструментами. И что самое главное, очень актуально в наши дни когда нужно уметь разбираться со многими технологиями с нуля.
Как найти своего идеального QA и отсеять жертв инфоцыганских курсов