Собеседование "по другую сторону": опыт поиска Junior QA Engineer


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

Мне вот посчастливилось принять участие в подборе помощника для себя. Попробую поделиться опытом. Эта статья может быть полезна как для ребят, готовящихся к своему первому собеседованию на Junior QA Engineer, так и тем, у кого это собеседование будет первым в качестве интервьюера по технической части.

Итак, погнали.


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

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

Requirements:



  • Previous work experience as a QA Engineer (0,5+ years)
  • Solid understanding of testing principles
  • Familiarity with Agile methodologies and agile testing approaches
  • Experience in writing and executing test cases
  • Experience with TestLink, Jira, Git
  • An ability to learn quickly
  • Analytical skills
  • Good communication skills
  • Desire to learn QA automation processes
  • Basic knowledge of Python or/and Node.JS is a plus
  • Basic knowledge of MVC and REST is a plus
  • Basic knowledge of RTB mechanisms is a plus
  • Intermediate English IS A MUST
В идеале, человек, проходивший по резюме по всем из этих требований, получал приглашение на собеседование. На деле же было принято решение на первом контакте(телефонный звонок от HR'а) уточнять, как обстоят дела с Линуксом, Git и английским языком.
Всего на рассмотрение за две недели отбора пришло порядка 300 резюме, что лишний раз подтверждает ошибочный стереотип, плотно засевший в разумах людей, о том, что тестирование - самый простой и безболезненный способ войти в отрасль. И мы начали скринить.
Скрининг - процесс отбора кандидатов на следующий этап - контактный звонок.
Переживая з то, что есть ненулевая вероятность кого-то потерять, я фильтровал резюме очень осторожно, делая щедрые скидки на тех. скиллы(помним, что ранее уже решили - человеческие качества превыше технических скиллов). И спустя несколько часов первые кандидаты были прозвонены, собеседования назначены и началось самое интересное.
О самом процессе собеседования, вопросах, ожиданиях и интересных моментах я напишу чуть ниже в этой статье, а пока остановлюсь на некоторых наблюдениях, которые были сделаны в ходе скрининга и первых "тестовых" интервью. 

1. 95% отправителей резюме - выпускники курсов по тестированию. 
Не то, чтобы я прям хэйтил курсы по тестированию, как явление в себе. Здесь всё очень сильно зависит от конкретной организации и преподавателя. Но результаты "выпускников" почти всегда разочаровывали. 
Этому есть две возможных причины. 
Первая - мотивация человека, идущего на курсы. Часто всё сводится к "Пойду работать, буду получать доллары, покупать сыры, отрасль стабильная, работа есть, профессия востребованная, почему бы и нет". Человек не горит профессией, а фокусируется на деньгах, которые за свою работу будет получать.
Вторая - философия организаторов/преподавателей. Не буду утверждать на все 100 процентов, т.к. никогда в организации/проведении курсов по тестированию участия не принимал, но складывается ощущение, что у предоставителей подобных услуг начисто отсутствует чувство ответственности за знания, почерпнутые на курсах. Мне всё это видится как-то так:
1. Обещаем доллары и сыры, завлекая потенциальных свитчеров
2. Парим урезанный ISTQB Foundation(и это при оптимистическом сценарии, а есть еще и пессимистический, когда на занятиях пересказывают Савина)
3. Тратим по пол часа на каждого студента, составляя ему резюме, на которое клюнут. 
....
4. PROFIT!!11

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

2. Примерно две трети скиллов, описанных в резюме, человек не может подтвердить на собеседовании. 
Есть такое правило, написанное кровью, проверенное уймой потраченного зря времени и доносимое каждым здравомыслящим специалистом до своего брата: Никогда, слышишь, никогда не указывай в резюме те технологии/подходы/инструменты, по которым не будешь готов отвечать по всей строгости на собеседовании. 
- Гит? Ой, да когда-то что-то читал, но не особо помню, что там. Если надо - выучу. 
- CSS? Ну каскадная таблица стилей, да. HTML там, верстка.
- Selenium? Ну я знаю, что это такая штука, чтобы автотесты записывать. Ну нам рассказывали о нем, но я не работал. 
Всё это - следствие подхода "пойду на курсы, там меня всему научат и расскажут. А потом в бой.", возможно, имеет место такой ход мыслей "вот у Васи всё это в резюме написано, его взяли. Почитаю википедию, допишу себе, а там на месте разберемся.". И тот и другой подходы - проигрышные. Т.к. страшнее незнания определенных инструментов или технологий по специальности может быть только откровенное вранье в резюме. Как относиться к человеку, который с первых минут знакомства(скрининг и собеседование) начинает лукавить и выдавать себя за того, кем он не является?

3. Умение читать техническую документацию - это еще не Fluent English. 
Это очень больная тема, когда на собеседование приходит человек, у которого в резюме указан сильный английский, но который теряется при простом вопросе о том, чем он, в двух словах, занимался на предыдущей работе. На английском языке, конечно. 
Еще больнее становится, когда находишь грамматические ошибки в резюме, составленном на английском, с указанным в нём уровне Upper-Intermediate/Advanced.

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

Вопросы, которые я чаще всего задавал кандидатам. 


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

2. Кем себя видите в тестировании? Техническим специалистом или на руководящей позиции через тестирование, как отправную точку? 
Это очень скользкий вопрос со стороны интервьюера, т.к. единственно верного ответа на него нет. Но если ко мне приходит человек, который за полтора года сменил 3 профессии, и утверждает, что хочет с головой уходить в техническую часть - с очень большой долей вероятности, это не совсем искренний ответ.
Так же, не радует, когда человек без опыта работы утверждает, что из тестирования хочет прийти к лидовым позициям. 
Когда мне задают такой вопрос, я, как правило, отвечаю "Как пойдёт.", и мое мнение таково: если ты активно развиваешься по тех. части, опыт и возможности перейти в управление процессом/проектом к тебе придут. А если ты изначально задаешь себе установку, что здесь ты ненадолго и твоя работа — всего-навсего ступенька к позиции тех-лида или проектного менеджера, тогда стоит задуматься над самим подходом.

3. Есть ли найденный вами дефект, которым вы гордитесь больше всего? 
Этот ответ говорит о том, чем является для человека работа в отрасли. Если такой дефект он назвать затрудняется - значит на лицо схема "к дорогим сырам через тестирование". Если же он называет тривиальные вещи, с которыми люди сталкиваются в ежедневной работе постоянно - возможно, такому человеку не хватает напористости, уверенности в правильности своих действий и желания развиваться в специальности в общем и баг-хантинге в частности. 
Достойный кандидат ответит таким образом, что найденный дефект или подход к его обнаружению удивит интервьюера. 

4. Какие профессиональные ресурсы читаете? Откуда берете знания? 
Большинство опрошенных называют в кач-ве опорных точек Святую Троицу: Савина, Канера, Калбертсона. 
Некоторые говорят про ДОУ и хабр. И(сюрприз-сюрприз) о школе Портнова. 
Достойный кандидат упомянет хотя бы пару специализированных форумов, пару блогов(Дж. Баха, Google Testing Blog), расскажет о книге Уиттакера. Укажет на конференции, которые посещал, или записи которых смотрел. Вспомнит о Руколь. Заикнется о Stack Exchange.
Вообще, знания по тестированию можно черпать из любых книг по разработке программного обеспечения, т.к. в реалиях современной доставки продуктов эти процессы максимально переплетены и неразделимы.

5. REST API, коды ответов cервера по протоколу HTTP.
Здесь никакого рокет-сайенса не ждал. Хотелось просто услышать определение о том, что такое REST, и человеческое описание основных, но непопулярных кодов ответов(403, 502, 302, 204). Работая с веб-сервисами, часто невозможно найти root cause возникшей проблемы без обращения к консоли или анализу запроса и ответа на него, пришедшего от сервера. 
В основном, вопрос был подъемным. Но называли не частые коды, а определения для групп. В прочем, это не является большой проблемой. 

6. Начальный тег HTML-документа, сокрытие элемента средствами CSS. 
Это простые вопросы, призванные дать понимание о том, на каком уровне человек работал с огромным множеством аббревиатур, указанных в его резюме. И цифра дня для этого вопроса - ОДИН. Ровно столько кандидатов дало правильный ответ на оба этих вопроса.

7. Есть удаленный репозиторий по ссылке http://1.2.6.192/test.git. Какие шаги нужно выполнить для того, чтобы подтянуть этот репозиторий локально? 
Тут всё просто. Проверяем умение человека работать с системами контроля версий. Как ни странно, этот вопрос тоже оказался неподъемным для большинства кандидатов. 
Какого ответа я жду: 
1. Проверить, установлен ли git локально(мы же тестировщики, помните?)
2. Проверить, есть ли у нас права на доступ к этому репозиторию.
3. Сделать git init/checkout/pull ИЛИ git clone для репозитория, если предыдущие два шага не выявили проблем. 
К сожалению, такого ответа не дал никто. 

8. Вопросы по техникам тестирования, указанным в резюме. 
Здесь не буду разделять, так как конкретные вопросы варьировались относительно каждого кандидата, пока могу только сказать, что самые большие проблемы у соискателей с тестированием производительности и тестированием систем на мобильных устройствах. Вопросы, задаваемые в этом блоке дают понимание о том, слышал ли человек о той или иной технике или об определенном виде/методе тестирования только в теории или обладает пониманием того, как действительно он работает на практике. 
Иногда спрашивал, какие виды тестирования понравились, а какие - не очень. Как правило, это дает понять, как много времени человек тратил на изучение или работу с тем или иным видом. 
И да, лично я ненавижу регрессию. =) 

9. У вас есть доступ к серверу на Linux без графической оболочки. Вам нужно собрать максимум информации о нём. Какими командами будете пользоваться? 
Просто открытый вопрос, не имеющий правильного ответа, призванный понять, насколько глубоко человек знаком с Linux-подобными операционными системами. И тут, к сожалению, большинство людей не могли назвать даже элементарных команд, необходимых для повседневной работы с ОСью.

И мы плавно переходим к изюминке каждого собеседования. 

Практическое задание. 

Практическое задание на эту позицию формировалось с нуля. За основу брался так любимый всеми интервьюерами на позицию QA Engineer-ов калькулятор. 

Вот, как он выглядел: 



Это самый простецкий мок-ап, который был нарисован, исходя из того, что хотелось бы проверить. Само практическое задание звучало следующим образом: "Внимательно посмотрите и отметьте всё, что, по вашему мнению, достойно баг-репорта."

И, собственно, дефекты, которые должны были найти соискатели.

1. Лишняя буква "l" в слове "Wellcome".
2. Недостающая буква "r" в слове "corect" внутри окна подтверждения.
Здесь мы смотрим на знание английского языка и умение кандидата работать с очепятками визуально. Первый дефект, к слову, находили, буквально, единицы.

3. Отсутствие кнопок "0", "С", "+/-" и других управляющих элементов функционала.
4. Неправильное расположение цифровых кнопок(Расположены инвертированно, относительно стандартной раскладке для калькулятора). 
5. Отсутствие символа "."

Эти дефекты должны были дать понимание того, откуда кандидат черпает требования к качеству продукта в случае, если прямых требований нету. Есть официальные стандарты, есть индустриальные стандарты, есть продукты конкурентов, и глядя на это, можно было дать кучу правок и замечаний или, хотя бы, задать определенное кол-во вопросов по целесообразности данного инженерного решения. 
С дефектом под номером 5 связан отдельный вопрос: "Каким образом возможно видеть подобную цепочку действий, если точка в функционале отсутствует?". Задавался он для того, чтобы понять, на каком уровне люди взаимодействуют с продуктом и исследуют ли они его достаточно, чтобы делать выводы. А ответ был очень простым - точку очень легко можно ввести с клавиатуры. 

6. Неподходящее обозначение кнопки для умножения(mul). 
По правде говоря, здесь этот дефект был своеобразной пасхалкой, так как утилита для мок-апов не умела по-человечески отрисовывать звёздочку, по этому было принято решение заменить ее на сокращение от multiplication и заодно проверить умение ребят мыслить аналитически. 

7. Проблемы с расположением элементов. 

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

8. Неочевидные решения по функционалу элементов.

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

9. Инвертированное положение кнопок Yes и No в окне подтверждения. 

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

Наиболее запомнившиеся мне кандидаты были готовы завести от 10 до 18(рекорд) баг-репортов. 
Некоторые обращали внимание на картинку, подозрительно напоминающую непрогрузившееся изображение и пустой URL(побочный эффект стандартного окна браузера в утилите для создания мок-апов). 

Резюмируя...

Возьму на себя смелость подобрать список рекомендаций, основанный на опыте более чем 20 собеседований за 2 недели, проведенных с нуля. 

1. Тестирование - это не просто. И с этим надо смириться. Оно не проще разработки, а местами даже сложнее. Помните это.

2. Курсы - не панацея и не самый короткий путь в индустрию. Только желание + упорство + практика + уверенность в себе = успех на собеседовании. 

3. Будьте готовы отвечать кровью за каждую написанную в резюме строчку. 

4. Если вы в тестировании ради денег, тогда продуктовая разработка - скорее всего не ваш вариант. Ориентируйтесь на аутсорс, там проще с входным порогом и мотивацией. 

5. Развивайтесь. Сколько бы вы не прочитали. этого всегда будет мало. Всегда. Не останавливайтесь и не зацикливайтесь на одном подходе, одном ресурсе, одной методологии. 

6. Если вы действительно всерьёз настроены на то, чтобы получать хорошие офферы - займитесь английским и Linux'ом. А если еще и разберетесь с основными принципами работы мобильных ОС - цены вам не будет.

7. Практикуйтесь. Всегда и везде. Набивайте руку на всём, на чём только можно. И поворачивайте мозги(Савин, привет!) в сторону тестирования. Это неоценимый скилл. 

8. И главное, помните: каждое проанализированное заваленное собеседование приближает вас к успешному. Ничего не бойтесь, верьте в себя и у вас всё обязательно получится. 

33 комментария:

  1. Спасибо за классную статью! :)
    Поддерживаю, практически, каждую фразу. Всё по делу, здорово описан подход к подбору кандидата и, собственно, результаты увиденного. Не согласна только с пунктом про git, но это отдельная тема.
    Надеюсь, твой идеальный кандидат уже найден и не разочарует :)

    Коллега по цеху, Таня С. :)

    ОтветитьУдалить
  2. Печалит когда добился определенных результатов в IT, но хочешь что то поменять. Изучил что, как и к чему, закрепил знания на курсах (по полочкам разложил), выходишь в свет - а там на тебя смотрят как на описанных выше кандидатов....
    Желание и мотивация скоро сожгут, обратной связи 0....

    ОтветитьУдалить
    Ответы
    1. Я бы, на самом деле, не обобщал.
      Если говорить о курсах, как об инструменте для систематизации знаний, то это прекрасный инструмент и грамотная инвестиция.

      Беда же в том, что "смотрят как на описанных кандидатов", руководствуясь определенным опытом, в т.ч. опытом общения с каждым конкретным кандидатом.
      Уверен, если указанный Вами в резюме track of record является релевантным и актуальным - то строчка о прохождении курсов в данном случае будет именно плюсом, а не "отягощающим обстоятельством".

      Удалить
    2. Скажем так: достижения с иного направления. В моем случае это hardware, Data center, NOC, management. А ведь буквально 4 года назад, будучи студентом, бегал ПК чинил... Но есть и отличные знания н-р HTML+CSS (могу сверстать страничку по макету, не говоря о тестировании), администрирование винды, сети и т.п, что порой может пригодится. Был случай, на тестовом задании нашел банальщину: при загрузке программы юзер работал в default workplace. При желании можно настроить и сохранить свою рабочую область, но файл дефолтных настроек виден. И что самое смешное - его (задействованного) можно удалить прямо в окне загрузки/сохранения профиля. Мелочь, но не каждый джун догадается указать на этот недостаток.
      Есть еще то, что в резюме не укажешь! Н-р знания полученные во время учебы на программера (в один момент не понял синтаксиса, и понеслось). Могу код прочитать, знаю где делают типичные ошибки и т.д..
      Из вышенаписанного просто возникает вопрос: HR-ы смотрят вообще на образование (факультеты), карьерную лестницу? Это ценится вообще, и выделяет из массы "ололо_закончил_курсы_бирити!!11рас"?
      А так то согласен с вами - не жалею денег за курсы, инвестиция хорошая и отлично структурировала знания. Смотрю на конспект "самообразования", и то что записал на курсах - "Кровь и молоко"... ;)
      Благодарю за ответ.

      Удалить
  3. Боже мой( я узнал себя, я глупым себя не считаю, и ИТ вроде неплохо понимаю(знаю что до ИТ спеца еще далеко, но все же есть много над чем работать), но я уже почти год бьюсь по собеседованиям и все никак( за это время, я кое как выучил питон, хтмл и джс знаю с переменным успехом, участвую в фрилансе и постоянно что-то читаю, и до СЕГОДНЯШНЕГО дня я ИСКРЕННЕ не понимал, почему меня такого раскрутого, фастлернера, не берут. Но спасибо за статью.
    З.Ы. насчет курсов Вы очень пессимистичны, я их лично расцениваю(хоть мне обещали вернуть деньги если за 3 месяца я не устроюсь) как выгодное вложение, по одной простой причине: это что-то на подобии института, где тебя не учат полностью что куда тыкать, а учат думать и потом ты сам уже учишь то что тебе интересно)
    З.З.Ы. Спасибо за статью)

    ОтветитьУдалить
    Ответы
    1. Курсы бывают разные. Бывают хорошие, а бывают и не очень. И вот таких "не очень", как правило, больше, к сожалению.

      Успехов Вам и вдохновения. Не надеюсь, а уверен, что у Вас всё-всё обязательно получится!

      Удалить
  4. Простите, не совсем уловил, какой оттенок имеет упоминание школы Портнова

    ОтветитьУдалить
    Ответы
    1. С ней всё ок. Просто не ожидал, что видео-курсы Портнова будут таким же частым источником для черпания знаний, как и Савин, например.
      Я, в принципе, неплохо к ним отношусь. Базу он дает годную. Но есть варианты получше(если есть возможность читать по-английски).

      Удалить
    2. Спасибо. База действительно годная!

      Удалить
    3. "Есть варианты получше" - можно примеры в студию?)

      З.Ы., я не с вредности, просто интересно, для самообразования.

      Удалить
    4. Lessons Learned in Software Testing Канера,
      Software Testing Рона Патона,
      Software Testing: A Craftsman's approach Йоргенсена.
      И книженция по тестированию в "гибких" проектах Лисы Криспин.

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

    ОтветитьУдалить
    Ответы
    1. Вы, наверное, удивитесь, но я из аутсорса в продукт уходил на меньшие деньги. Только из-за возможности "развязать руки" и самому определять ширину рамок своих функциональных обязанностей.
      Есть люди, которым важно осознавать себя профессионалом и хорошим специалистом, а есть люди, которым важно выхватить как можно больше финансовой компенсации за ненапряжную работу 9 to 5. И вот вторых, как раз, старался фильтровать.
      Честно признаться, я за свою карьеру еще ни разу не видел недооцененных финансово хороших специалистов. А вот переоцененных сыролюбов, вносящих энтропию в процесс ради собственной материальной выгоды, встречал достаточно.

      Удалить
    2. Этот комментарий был удален автором.

      Удалить
  6. Тяжело ж как на джуна сдать, ну всё-таки большую половину б потянул.
    С любимым дефектом бы точно провалил.

    ОтветитьУдалить
  7. Ну бомбануло вас знатно.
    И в целом, я согласна с вышесказанным, за исключением пары нюансев.

    Как для джуна - собеседование с такими требованиями перебор, имхо. Это для среднего спеца уже. Но не джун.

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

    А инструменты- неделя, максимум.

    ОтветитьУдалить
    Ответы
    1. Когда на вакансию приходит больше 300 резюме, то грех не потратить немного(хотя тут можно спорить) лишнего времени и получить специалиста, работая с которым не будет необходимости тратить время на обучение работе с инструментарием, согласитесь. ;)

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

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

      Удалить
    4. Классовое деление "джун - не джун" очень условное и никому, кроме аутсорса не нужное.
      Поэтому компания ставит требования не "джуну", а человеку, с которым будет работать. У нас в компании нет этого деления (потому что в продукте оно не нужно) и нам хорошо.
      А поскольку мы живем в таком мире, где именно компания диктует, что и как должно происходить, то можно либо принять требования в том виде, в котором они есть, либо идти в какой-нибудь бодишоп, благо в Украине их хватает

      Удалить
    5. To Владимир:

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

      Джун: вот тебе входные данные, реализуй метод, который будет принимать их на вход, манипулировать ими и на выходе выдавать данные определенного формата. Покрой код тестами и пофикси миноры-тривиалы.

      Миддл: необходимо реализовать модуль с конкретным функционалом. Всё, дальше - сам. Нужно сделать MVP, отрефакторить чужой код.

      Сениор: Вот тебе MVP, нужно конвертировать его в BetterSolution и затем в BetterThanBetterSolution.

      C тестированием уровень ответственности где-то так же распределяется.

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

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

      Удалить
  8. Тоже бы провалился с любимым дефектом :-)

    ОтветитьУдалить
  9. Да и тоже Linux и Git. Linux даже сами разработчики толком не знают, кроме того, что юзают ежедневно, остальное гуглят по необходимости и тут же забывают. Также и с Git-ом, за несколько лет тестирования, Git вообще не понадобился, юзаю только когда автотесты пишу и пушу их в репку.. Думаю для джуниора - это вообще скилы не принципиальные. Тогда уже можно и docker включить в собеседование :-)

    Но про SQL - ни одного вопросика :-) Ясное дело, что тестировщик не должен писать быстрые запросы и уметь их оптимизировать, но хотя бы добывать данный из таблиц - must have..

    ОтветитьУдалить
  10. Не понимаю как можно от джуна без опыта, или с опытом 0,5 года на забытом ктулху проектом ждать знаний Гит.
    Очень меня волнует ваш вопрос "сокрытие элемента средствами CSS" - зачем вы пытаетесь отперчить кандидата вопросами по фронтэнду? Еще и джуна? Разницу между CSS2 и CSS3 он тоже должен знать?
    Вы несколько раз упоминаете мобильное тестирование - и это отдельный человек на отдельную должность. Все остальные вопросы относятся к веб тестировщику, мануальному. Возможно с перспективой на автоматизацию. Но не на мобильную разработку. Это 2 разные должности, и мне не понятны вопросы про это.
    У вас очень заметный страх "людей за сыры". Может у вас плохой опыт, но мне известны отличные профессионалы "за сыры", которые по производительности и качеству перекрывают лигу "за флаг качества". Что воздвигает человека на подвиг - не ваше дело. Важно чтоб что-то воздвигало.

    ОтветитьУдалить
  11. Требования явно не под Junior QA. Реально можно оставить пункты 3, 4, 6, 8. Практическое задание - самый лучший вопрос из всех!
    Работаю в компании, где 50+ тестеров, на все Ваши вопросы ответит лишь 5% из них. Пишите в вакансии Middle QA, так сэкономите время и не будете получать по 300 резюме.

    ОтветитьУдалить
  12. У меня только один вопрос, почему "вспомнит о Руколь" это положительный момент? Я вот до сих пор пытаюсь забыть, но не получается =/

    ОтветитьУдалить
    Ответы
    1. Это стандарт. О нем можно спорить, с ним можно не соглашаться, но игнорировать его бессмысленно.

      Удалить
  13. Хорошая статья. Но разрешите пару ложек дегтя, основанных на личном опыте
    1) Отбирая одного джуна из 100500 людей, усложнять техническую часть собеседования категорически неправильно. Человек, какой умеет тестировать, и хорошо знаком с базисом, с каким нужно работать - это мидл, с соответствующими зарплатой и задачами. Усложняйте проверки на логику, личные качества итд, но никак не тех часть. Иначе велика вероятность либо нанять овер-квалифаед человека (поработает пол года или даже меньше, пока не найдет себе мидл позицию), либо какого-то странного, ленивого, перепуганного итд (мидл, какой почему-то готов работать джуном)
    2) Разработка в среднем куда сложнее тестирования. На то, чтоб стать синьйор разработчиком, нужно куда более усилий, чем чтобы стать синьйор куа. Ну и зарплата у разработчиков в среднем выше, что логично в связи с вышесказанным.
    3) Может я неправильно понимаю понятие "продуктовая разработка", но в зарубежных продуктовый компаниях зарплаты процентов на 30 выше, чем в бодишопах (компании типа Люксофта, Епама, итд).

    ОтветитьУдалить
  14. Этот комментарий был удален автором.

    ОтветитьУдалить
  15. Предупреждение! Данный отзыв не является критикой кого либо , просто накипело.
    Прочитав вашу статью, решил поправить резюме та как за каждый пункт ты должен отвечать кровью оставил только то, что знаю или понимаю на базовом уровне убрав всё лишнее, а почему бы и нет ведь в этой сфере платят за правду, какой бы она не была и начал розсылать если раньше мне хотя бы задания высылали которые я достаточно быстро делал то после исправления никто даже не откликается. Вот интересно каким же путём кроме как добавления левой инфы или дописания тулов которые требуются фирмой можно идти что бы твоё резюме хотя бы розсмотрели и в результатет попасть на собеседование человеку после курсов без опыта но с огромным желанием развиваться и расти в данной сфере?

    ОтветитьУдалить
    Ответы
    1. Все ведь очень просто.
      Оглянитесь на инструменты, которые пришлось вычеркнуть, поработайте с ними вне коммерческого использования и подтяните свои знания в них. Затем смело возвращайте их обратно в ваше CV.
      По поводу неоткликания — могу сказать, что вы экономите свое время на интервью, которые могли бы не увенчаться успехом из-за несоответствия ожиданий обеих сторон.

      Удалить
  16. за то был бы опыт прохождения собеседований

    ОтветитьУдалить