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

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до 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 про неадекватність технічного експерта. Кааамон, вам треба з колін тестування підняти, а ваш експерт каже, що юніт та інтеграційне тестування не потрібні.