Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як я проводжу співбесіди на посаду QA

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Я Роман Марінський, Test Engineering Lead в Intellias. Пишу та добре розумію мови Java, Kotlin, Groovy, C#, Swift, почав розвиватись в TypeScript та Python, автоматизовував тести для UI, API, Mobile Native (Espresso, XCUITest), Mobile crossplatform (react native, flutter), Desktop (сучасний та старовинний інтерфейси). Веду спільноту QA Club Lviv, наші власні заходи, курси та тренінги, також в докарантинні часи був членом ПК Selenium Camp та QAFest.

В Intellias я провів вже більш ніж 300 співбесід за останні 2 роки, тому можу поділитись своїм досвідом в цьому питанні.

Від редакції: Нещодавно ми опублікували 250+ технічних питань для QA і попросили Романа розповісти про проведення співбесіди від А до Я. Так з’явилася ця стаття.

Як забезпечити комфортне та ефективне спілкування

Мій mindset для проведення кожної співбесіди — це зробити так, щоб людині було комфортно розмовляти зі мною і вона винесла щось корисне для себе. До прикладу, якщо я бачу, що в людини визначення якогось терміну «крутиться на язику», то підкажу. Якщо людина питає, чи правильно розуміє питання або чи дала відповідь — то розповім :)

Якщо кандидату буде дискомфортно на співбесіді — через стрес вона не розкриє все, що знає та розуміє. Тому я починаю свою частину співбесіди зі «смолтолку» та під час співбесіди жартую про технології або спокійно озвучую правильну відповідь, якщо людина попросила.

Також безліч кандидатів шукає відповідь на питання — що їм слід підтягнути. Ще не було жодної людини, якій не було б чого ще підтягнути в темі забезпечення якості програмного забезпечення, оскільки цей напрямок є дуже широкою та одночасно і глибокою темою. І я даю цей зворотний зв’язок.

Перед проведенням технічної співбесіди на тестувальника та автоматизатора, я завжди маю знати деталі з проєкту, на який проводиться співбесіда — про склад команди, що за домен продукту та які задачі людина буде виконувати. Це дуже сильно може вплинути на перелік питань та на вагу запитань в оцінці людини.

До прикладу, якщо в резюме вказано щось про CI/CD — я перепитую, що саме зробив кандидат і одразу оцінюю відповідь. Якщо людина реалізувала кодогенерацію API клієнту з моделями — то скоріше за все закрию пункт про API автоматизації на «відмінно».

Так само і з тестування або процесів: якщо людина складала стратегію тестування або робила ризик-аналіз, дизайнила тест-кейси, то я навіть можу не запитати про техніки тест-дизайну.

Частини співбесіди

1. Small-talk з кандидатом

Завжди маю з чого почати: про цікавий момент в налаштуванні інструменту, що робив перед співбесідою, яка погода, котики, ще щось прокоментую. Потім ретельно представляюсь та додаю, що я можу бути чимось корисним. Озвучую, що моя співбесіда складається з блоків та перелічую їх приблизно так: «Розкажеш про свій досвід, потім — блок питань з теорії тестування, технічна теорія та навички, і технічна задача на тестування, ніякого коду, просто вголос поговоримо».

Роблю це для того, щоб людина відчувала себе комфортніше, розуміючи, що на неї чекає.

2. Питання з резюме

Зазвичай перевіряю, наскільки кандидат ініціативний. Питання можуть бути на зразок:

  • Чого досягнув на проєктах?
  • Що зроблено, виправлено в процесах на проєкті з автотестами?
  • Чи з нуля будував процеси?
  • А чому використав саме той інструмент?

3. Питання з теорії тестування і практичні приклади

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

Уточнюю, які техніки тест-дизайну знає та використовувала на практиці — якщо мені недостатньо для розуміння, як людина «дизайнить» тести.

4. Технічна теорія з автоматизації тестування (якщо вакансія на автоматизатора)

Запитую: як людина розуміє та використовує ООП, ФП, code smells, патерни проєктування, специфічні питання на розуміння мови розробки, Java, C#, TS/JS, що знає з Git, що вміє робити в CI, як використовувала Docker, k8s.

Також задаю питання з UI, API, Mobile Native, Performance тестування. Моє улюблене питання — це «Яка архітектура Selenium?», дуже часто зустрічаю здивований погляд, але часто доводиться потім самому пояснювати :)

5. Задача на покриття системи тестами

На етапі задачі я отримую остаточне бачення того, як людина розуміється в аналізі вимог, чи має абстрактне мислення і відчуття тестування тощо.

Здебільшого, питання для кожного рівня інженера — плюс-мінус однакові. Різниця полягає лише в тому, що чим більший досвід, тим глибше та ширше може бути відповідь на питання. Чим більше досвіду — тим глибше людина має розуміти, як працює інструмент під капотом, тим менше академічних визначень термінів давати.

Таким чином, на мою думку, я збільшую об’єктивність оцінки за технічними знаннями та навичками.

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

Завжди кажу, що сподобалось в знаннях людини, в розумінні підходу, знань теорії, що можна ще підтягнути (+ одразу даю чіткі матеріали для опрацювання, просто здебільшого це одне й те саме). У рамках цього блоку кажу, чи вважаю я, що людина справиться з цим проєктом чи ні — даю додатковий фідбек, що ще слід підтягнути та коли можна повторити спробу.

Також називаю рівень інженерності — Junior, Middle, Strong Middle, Senior, Principal — і кажу, що якщо людина засвоїть те, що я їй порадив підтягнути, то за який термін потенційно вона могла б піднятися на рівень вище.

Я люблю проводити співбесіди

Люблю допомагати людям з визначенням їхнього технічного рівня, люблю кандидатів, з якими можна пофілософствувати. Але, на жаль, часто доводиться співчувати людям через те, що їм ставлять жорсткі рамки, не дають бути почутими та відповідно вони не можуть розвинути свій технічний рівень. Або не дозволяють юзати високорівневі обгортки над клієнтами для автотестів (Selenium, Apache HTTP Client), не дають можливість потроху вирішувати технічний борг автотестів та тестування загалом, не дають доступ до репозитаріїв бекенду, фронтенду та мобільних застосунків.

Я маю позицію: «Якщо ви як бізнес/менеджмент не даєте розвиватись людині та не чуєте її — значить ви збільшуєте ймовірність, що людина буде факапити та піде від вас».

Хоча все одно не все так просто та однозначно :)

Поради

Для тих, хто проводить співбесіди:

  • Підготуйте свою власну форму для оцінки кандидатів та невпинно покращуйте її, додавайте нові блоки питань або видаляйте.
  • Обмежте вибір для оцінки через випадаючий список значень.
  • Додайте спеціальний блок для визначення особливих навичок кандидата. До прикладу, якщо людина працювала зі Scala + gatling, k8s, GitLab CI Pipelines тощо, то додайте і на це оцінку.
  • Додайте, якщо важливо для вас, наскільки людина добре розуміється в бізнес-домені. Адже інколи ввести в курс бізнес-домену продукту важче, ніж проводити оркестрацію браузерів через Selenoid.
  • Додайте вагу для блоків оцінок та автоматизуйте визначення рівня інженера на основі оцінок, щоб не доводилось навіть думати про те, це Strong Middle, Senior чи Principal.

Тим, хто проходить, скажу одне: завжди оцінюйте післясмак співбесіди. Якщо вам не сподобалась співбесіда, в якому тоні з вами розмовляли, які питання давали, коли дають фідбек — є велика ймовірність, що вам не сподобається працювати в тій компанії. Співбесіда — це не тільки про перевірку кандидата, чи він має відповідні знання, це і про оцінку компанії, її технічного рівня, відкритості, ефективності процесів.

P. S.

У мене був випадок, коли я прийшов на співбесіду в компанію, в якої «боліло» тестування: вони хотіли налагодити процес тестування та автоматизації тестів, навчити людей автоматизації, а питали про Garbage Collector, про те, як працює ConcurrentHashMap, які є плюшки в GraalVM в порівнянні зі звичайною JVM. Я не пішов туди та залишив їм негативний відгук на DOU про неадекватність технічного експерта. Кааамон, вам треба з колін тестування підняти, а ваш експерт каже, що юніт та інтеграційне тестування не потрібні.

👍ПодобаєтьсяСподобалось53
До обраногоВ обраному18
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Спасибі!
Дуже цікаво,доброзичливо та корисно!

привет, Рома
хорошая статья, спасибо.
Можешь обьяснить пожалуйста насчет тайтлов
кто такой Principal QA? Это Test Engineering Lead или что-то другое?)
И в чем разница между Middle и Strong Middle? Это какая-то инфляция тайтлов в компаниях или есть какой-то скрытый смысл?
Собеседование мне понравилось, фидбек сразу после интервью — это очень редко встречается.

Привіт, дякую)

В інтеліасі є базовий шаблон в делівері функції (розробці) вже дууже давно
— Associate (trainee)
— Junior Engineer
— Middle Engineer
— Strong Middle Engineer
— Senior Engineer
— Principal Engineer

Стронг мідл це людина яка ще доволі слабка в патернах, ок в мові, вже робила з нуля проєкти для автоматизації UI або API. Сініор — обовʼязково має бути вмілим і в UI і в API, і в CI
Насправді я б ще розрізняв сініорів — які тільки стають сініором та які вже досвідчені сініори, про це я теж розповідаю на співбесіді

В нашому розумінні Principal QA людина яка дуже досвідчена в UI, API, iOS, Android та в принципі може налаштувати кросплатфорену автоматизацію тестування та процес забезпечення якості.
+ використовувала >1 інструмента для Аналізу працездатності
+ дуже широго та глибоко розуміє QA як процес
+ CIайки декілька штук налаштовувала
+ Декілька мов розробки знає
стаб чи мок сервіси розробляла, ну і тощо
В нас є форма фідбеку де ми оцінюємо людей всередині та ззовні і більшість оцінок за критеріями має бути відповідно 5. А в середньому це біля 4.7 і відповідно більше

Але паралельно Прінципал рівню — можна піти по гілці Engineering Lead, де в залежності від кількості людей під тобою ти можеш бути і Senior та Principal Engineering Lead

Така модель пішла чи від майкрософт чи від ібм чи ще від когось

Моє улюблене питання — це «Яка архітектура Selenium?», дуже часто зустрічаю здивований погляд, але часто доводиться потім самому пояснювати :)

можете пояснити більше — це якесь ’підступне’ питання, звідки беруться здивовані погляди?якої відповіді очікуєте на нього?

Ну не дуже то й підступне, це питання не переврку як лююдина глибоко копала інструмент яким користується та як цікавилась його розвитком

Бачу здивування здебільшого, тому що мало хто задумується, а з яких компонент складається селеніум вебдрайвер, які забезпечують виконання дії яка описана в коді проєкта — виконалась в браузері. Підказка селенум вебрайвер це клієнт серверний додаток

Очікую правильної відповіді, але вистачає і міркувань людини, 50/50 до правильного висновку приходять, а я уточнюю деталі вже — щоб їх міркування скалались в цілісну картину
Якщо людина розкаже з історичною хронологією розвитку його архітектури то це вау

хмм, тоді питання до уточнення, що саме тут — «Яка архітектура Selenium?» — мається на увазі під Selenium-ом власне:
— Selenium як проект і його складові — IDE, Grid, RC, WebDriver і т.д.?
— selenium як бібліотека/пакет/гем/залежність і т.д. яка імпортується/прописується в тест фреймворку для подальшого використання в тестах?
— selenium як власне сам файл хром- або гекодрайвера, чи .jar-файл селеніум-сервера, чи один з селеніум докер контейнерів, який потрібно скачати і ’розгорнути’ на умовній тестовій машині, щоб мати змогу виконувати дії над браузером?
Бо з цього виглядає

з яких компонент складається селеніум вебдрайвер, які забезпечують виконання дії яка описана в коді проєкта — виконалась в браузері. Підказка селенум вебрайвер це клієнт серверний додаток

що мова про п. 3., тоді досить дивне питання, навряд чи більшість кандидатів знають це на цьому рівні. Чи це лише для певних міддл+ рівня питання?

Я здебільшого чекаю зустрічного питання про те шо я маю на увазі ну і наводжу приклад
Іноді як раз і перепитували чи маю на увазі про Селеніум як амбрелла проєкт
Чи яка структура бібліотеки, чи ще шось

так, це питання для мідл+, а навіть якщо конфʼюзяться то підказую основу на якій можна частину вгадати, зрозуміти принцип роботи та пояснити) відсотків 30 правильно відповідають с першого разу, іноді лиш можу трошки уточнити. Іншим підказую та з 2гої 3ї підказки пояснюють.
Найгірший випадок коли кажуть «ні не знаю» та на підказки теж не відповідають та не цікавляться
потім пояснюю якщо інженеру цікаво

за 5+ лет опыта хождения по интервью такого как автор я видел раза 2-3 от силы) а в конце 2019го года у меня было 2-3 интервью в день в течении 2х месяцев))
особенно весело когда тебя (мануального тестировщика) собеседуют девы)

Дякую за статтю! Виніс для себе деякі поінти )

Знаю людину, яка проходила в автора співбесіду (і зараз таких дуже багато), взяли без досвіду, після курсів на 3+к . Головне як підготуватись до співбесіди, які б підходи в інтерв’юера не були , підготувався, походив по маленьким канторах на співбесід, дописав 2роки — профіт

автор скіловий тестувальник, зараз багато де так, як зі сторони кандидатів так і з кантор, де питання 1:1 , в тестуванні так точно , в розробці важче але теж бувають кейси

Ого, вот ета поворот
Це прям соромно стає, хоча я б дізнався якщо б його звільнили, якщо він дійсно не дуже спец

Хоча все одно мушу дізнатись, хто це саме був, щоб зробити висновки
Йому дуже сильно пощастило тоді))

Хоча.. памятаю теж на початку трохи збільшив свій досвід в резюме 🙃 потім вже прибрав

Та ні, не може такого бути, людина на мідла дуууже мало імовірно могла пройти одразу з курсів, ну може це були дуже матьорі курси..

ти не дала мені спокою
Я переглянув всіх своїх кандидатів які пішли далі на проєкти від мого фідбеку (джун, мідл, сініор) і не зміг знайти людину яка збрехала в свому резюме або її звільнили під час випробувального терміну

та то триндець, я знову все перелопатив, подивися інакше на свою статистику, пробував зі всіх сторін то пошукати по тікетах — і не можу нічого такого знайти..
Але все одно не вспокоївся))

А чому нервуватися, якщо потім зашквару не було і тіп таки затягнув?)

*я не кажу, що це правильно, але як вже сталося

Можете не переживати, та людина зараз працює на іншій компанії з ще більшою зарплатою)

Ага, ось воно шо, ну значить та людина дійсно гідна того
Цікаво шо то за курси були?

значить багато вчився
молодець

Стаття дуже сподобалась. Дякую!

Останній абзац це біль, звичайно. Коли девелопери наймають автомейшна.
Але щось не знайшов цей відгук про компанію у вашому профілі.

Хм, дивно, теж не знайшов на доу, а де ж я його тоді написав, пошукаю

Негативні відгуки часом «зникають» ;-)

Ну це дивно насправді, вот тільки не можу пригадати чи в них були ще відгуки
То була співбесіда така в Pindify

Так, нам тре автомейшен, підеш ти на співбесіду, бо ти джава розробник, куа незнає джави так що давай вперед))))©

Класна стаття, побільше б таких підходів на інтервʼю, і фейспалмів буде менше (по обидві сторони)
Можна ще кілька прикладів задачок, які задаєте кандидатам?

під час перевірки технічних знань можу наводящі практичні питання задавати
— типу як зробити в гітлабі окремі репорти на оточення
— що потрібно передбачити щоб тести мали змогу запуститись в паралель — відповідь може бути ультра широкою відповідно до досвіду людини
— як має виглядати тестова сратегія якщо система розробляється такими то людьми, в неї такі то сервіси, та такий то ключовий функціонал

здебільшого імпровізую

А оці питання,вони на який рівень розраховані?

Чудова стаття. Треба собі добавити обмеження оцінок і автоматизувати рівень.

Підписатись на коментарі