Аналізуємо резюме Senior QA Engineer. Які проблеми помітили роботодавці і що радять змінити
Це другий випуск рубрики краш-тестів, де троє експертів розбирають CV українських ІТ-спеціалістів. Цього разу зосередимося на тестувальниках і проаналізуємо резюме QA-спеціалістки Вероніки Жигир з чотирма роками досвіду. Вона надала редакції DOU своє CV для розгляду (якщо ви теж хочете взяти участь — заповнюйте анкету).
Для розбору ми запросили QA Lead з компанії Geniusee, в яку подавалася Вероніка, а також експертів з компаній Ciklum і Sigma Software, які мають схожі вакансії.
CV Вероніки:
«Часто саме через англійську кандидатам відмовляють після першого перегляду резюме»
За шість років рекрутингу я провела сотні співбесід і переглянула та оцінила ще більшу кількість резюме. Найімовірніше, ви чули, що рекрутеру потрібно в середньому від 30 до 60 секунд, щоб зрозуміти, чи можемо ми продовжувати процес. Частково це так. Для кожної позиції є свої must have, і досвідчений рекрутер вже автоматично їх помічає. Тому важливо, щоб кандидати робили резюме більш привабливим під конкретну позицію.
Почнімо з того, що у резюме Вероніки можна було покращити.
- Позиція — QA Engineer. Але який саме? Manual, Automation чи General? Одразу зазначайте правильно вашу роль. Адже перші хвилини рекрутер витрачатиме, щоб зрозуміти, який ви все-таки тестувальник. У навичках перераховані мови програмування для автоматизації, але цього замало. Якби я розглядала Вероніку на позицію автоматизатора, довелося б зв’язатися з нею, щоб поставити уточнювальні питання, або ж витратити більше часу на вивчення резюме.
- Дуже добре, що є Summary, ніхто краще за вас не підсумує ваш досвід, досягнення та сильні сторони. Але є декілька моментів, на які я б хотіла звернути увагу.
Dedicated QA Engineer with 4 years of commercial work experience.
Тут все чудово: рекрутер відразу бачить кількість років і розуміє, чи підходить цей кандидат за цією вимогою.
I have a strong understanding of mobile development lifecycle and testing technologies.
З цього речення я розумію, що кандидатка найбільше працювала з mobile. Але якщо заглибитись у резюме, то можна знайти досвід і з тестування фронт (UI) частини. Тому сюди сміливо можна дописати Mobile and Web testing.
Excellent analytical skills and keen attention to details.
Це речення краще винести в окремий розділ Soft Skills. Підкресліть там свої сильні сторони. Знову ж, щоб дійти до певного висновку про вас, рекрутерам може забракнути
Додатково я б вказала домени, у яких доводилось працювати, адже часто клієнти шукають кандидатів з досвідом в конкретному домені.
Також у Summary можна додати персональні досягнення на роботі, якими ви пишаєтесь. У Вероніки в навичках зазначено, що вона має досвід ліда на проєкті — я б дописала це в Summary та зазначила кількість людей у команді, якою доводилось керувати.
Розділ Skills я б радила трансформувати в Technical Skills та вказати всі інструменти, з якими кандидатка працювала. Натомість усе, що не стосується цього, варто дописати у Summary чи у Soft Skills, як, до прикладу, цей рядок «Problem solving, focus on deadlines and deliverables».
Рухаємось далі: досвід. Щоб описати його, завжди варто орієнтуватись на таку структуру:
- тривалість,
- опис проєкту (тут можна вказати домен і розповісти кілька слів про проєкт),
- обов’язки,
- технічний стек, з яким працювали.
Вероніка не виносила технічний стек окремо, а дописувала інструменти в обов’язки, що також окей.
І останнє — це освіта та мови. В освіті бракує інформації про завершення навчання. Здебільшого рекрутерам важливо розуміти, чи людина ще вчиться. Тому краще одразу вказати рік завершення.
Англійська вказана на рівні Intermediate. Часто саме через англійську кандидатам відмовляють після першого перегляду резюме. Якщо ваш рівень не Upper, але ви можете пройти технічну співбесіду англійською або наступні етапи відбору з клієнтом, то краще вказати Strong Intermediate (can pass TI in English) або зазначити «Have daily communication in English. Now, I’m improving my knowledge to level B2». Я впевнена, що така незначна зміна збільшить кількість позитивних відповідей на ваше резюме у кілька разів.
Загалом резюме Вероніки є інформативним. Я б поспілкувалася з кандидаткою на співбесіді після уточнювальних запитань з резюме.
«Правило „резюме має бути на одну сторінку“ сильно переоцінене»
На DOU багато де розписані основні правила складання резюме і погляди на резюме з різних проєкцій і ролей. Я не буду додавати в цю бочку меду та інструкцій, як варто чи не варто робити. Тому пропоную інший підхід — «exploratory testing» резюме. Це думки вголос і відверті прискіпування до формулювань, які не пройшли повз мій критичний погляд — людини, за плечима якої тризначне число проведених співбесід.
Багато кандидатів не проходять першу воронку відсіювання рекрутером через те, що у резюме немає «якорів» або тегів. Це має бути короткий перелік технологій та інструментів, з якими працював інженер.
У резюме Вероніки ці аспекти є, але їх могло б бути більше, особливо в розділі technical background. Я впевнений, що людина з досвідом пробувала багато технологій і виконувала різноманітні, хай і типові завдання. Якщо вказати їх у резюме, це збільшить шанси проходження першого сита рекрутера.
Якщо сумніваєтеся, зверніть увагу на резюме архітекторів. Переважно вони рясніють усілякими технологіями та інструментами. І це при тому, що хорошому архітектору загалом вже все одно, з чим працювати, у нього достатньо досвіду, щоб розібратися практично з будь-якою технологією в найкоротші терміни.
Я не закликаю створювати CV на кілька сторінок, хоча і вважаю правило «резюме має бути на одну сторінку» сильно переоцінене. Моє правило — «у резюме не повинно бути зайвої води». Та якщо вам є чим похвалитися і для опису релевантного досвіду треба кілька сторінок, то, будь ласка, я почитаю. Головне пам’ятайте: усе, що ви скажете, може бути використано проти вас на співбесіді. ;)
Загальний вигляд документа, стилістика
Авторка обрала мінімалістичний, але ефективний шаблон для резюме. «Завжди актуальна класика», так би мовити, хоча останнім часом поширені стилістично складніші шаблони.
Немає фотографії. Не те щоб обов’язково, але дуже допомагає інтерв’юеру. Інтерв’юери ж також «люди-люди» і роблять помилки: забувають написати відгук одразу після інтерв’ю; та й коли кілька співбесід на день, все в голові переплітається! Фотографія допомагає згадати, що взагалі було на співбесіді.
Використовуються кілька шрифтів з різних сімейств в одному документі, із зарубками й без, цього краще уникати. Крім того, три різних шрифти для оформлення заголовка першого рівня виглядають дивно.
І ще одна деталь — не консистентні відступи в структурі.
Помилки. Є сучасні редактори з перевіркою орфографії й пунктуації, стилістики та формулювань. Тож я не можу зрозуміти, чому інженери з ІТ (!) галузі створюють документи з такими банальними проблемами: дужки без пробілу перед ними; пробіли перед, а не після коми; подвійні або множинні пробіли... Все це ж підсвічує автоматично будь-який редактор, я навіть не знаю, як від’єднати ці системи перевірки в Google Doc, Word, Notes тощо.
Проблеми з контекстом
Dedicated QA Engineer with 4 years of commercial work experience. I have a strong understanding of mobile development lifecycle and testing technologies. I’m passionate about building efficient testing processes and collaborating between cross-functional teams. Excellent analytical skills and keen attention to details.
Завжди цікаво спостерігати, як люди намагаються виділити головне зі свого досвіду і не завжди успішно. Як і у цьому прикладі, відзначене глибоке розуміння у мобільній розробці — чому саме в ній? Згадані «технології тестування» — я не знаю, про що це (можна, звичайно, «натягнути сову на глобус» і придумати, але це точно не наш сленг). «Побудова тестових процесів» і «колаборація між крос-функціональними командами» в одному реченні наводять на думку, що для автора ці речі розташовані десь поруч, хоча насправді це не зовсім так. Чому обов’язково «крос-функціональними», яка різниця?
... SKILLS
● Integration,regression, functional and non-functional testing
Що робить інтеграційне тестування в одному реченні з регресією, функціональним і нефункціональним? Сумніваюся, що варто було його додавати сюди. Крім того, малоймовірно, що на проєкті потрібна саме навичка інтеграційного тестування без уточнення деталей. Якщо й так, то чому не вказано «системне тестування» в цьому ж рядку? Швидко проглядаючи далі, знаходжу відповідний досвід у вигляді API Testing. Це більш конкретно. Можливо, варто було саме так і зазначати в навичках.
● Automation testing (Java, Python)
Авторка писала автоматизовані тести на Java і Python, чи підтримувала, чи готувала тест-кейси? Це має значення і такими скілами не розкидаються просто так.
● Leading QA team
Звичайно, термін «лідинг» може мати різноманітні відтінки значень, але авторка не позиціює себе як тест-лід, то чи важливо вказувати таку навичку? Не бачу опису відповідного досвіду нижче... Так само як і автоматизація — сумнівно.
● Requirements analysis
Вигляд непоганий, можна зробити ще краще, додавши чогось з цього: acceptance criteria elaboration, elicitation, negotiation with customer, etc. Але чесно — класика і дуже гарна.
● Mobile app distribution, debugging proxy tools
Фраза «дистрибуція мобільного застосунку» є незрозумілою як навичка. Так само «debugging proxy tools» — не бачу зв’язку з дистрибуцією, чому вони в одному реченні? Краще сформулювати як «web/http/traffic debugging tools...», інакше може здатися, що ми дебажимо самі проксі. Загалом тут є деяка плутанина.
● Analytics and monitoring tools (Firebase Analytics, Crashlytics, Sentry etc.)
Ще одна дрібниця, але все ж таки є комерційні назви Google Analytics for Firebase і Firebase Crashlytics.
... WORK EXPERIENCE
Jan-2021 — July-2023
Тут питання, чи резюме чекало на краш-тест протягом року, чи була декретна відпустка або авторка протягом року була без роботи? Краще це вказати, щоб я не вигадував, бо я можу уявити будь-що.
Project: Platform for logistic and manufacturing companies
Tasks performed:
● Cross-platform app testing (Flutter, Android Studio)
Тут мова про мобільний застосунок? Адже далі є явні згадки про мобільну і вебверсії, а тут вони пропущені. Flutter — зрозуміло, зазначена технологія, яка використовувалася для розробки, але чому Android Studio? І куди подівся Xcode? Дивно.
● Configuring infrastructure for integration testing (ERP system)
На мою думку, ERP-система — це серйозний продукт, і її інфраструктура повинна мати відповідні ресурси. Конфігурування інфраструктури під неї (не продукту, а саме інфраструктури) вимагає навичок системного адміністрування, а їх у резюме немає.
● IoT testing
IoT — це як окремий всесвіт. Що саме перевіряли в межах цієї активності: пристрій, застосунок чи прошивку?
● Providing estimates based on the business requirement document
Знову уточнення все руйнує і створює враження, що авторка не розуміє, про що пише. Чому лише «базуючись на бізнес-вимогах», а як щодо технологій, обмежень, ризиків, досвіду, моделі якості? Ще й стиль складний «Providing estimates». «Estimating test effort» або «QA activity effort estimation» — ось прості та місткі фрази.
● Supervising launching new products from scratch
А це точно резюме тестувальника, а не продакт-менеджера з
● Leading, managing, and assigning the task to the team
Остаточно зрозуміло, що автор не розуміє значення лідити й менеджити. Жоден керівник не зведе ці три дієслова в одне речення.
● Working with AWS infrastructure and AWS cloud watch
Я не вірю, що інженер, який працював з Amazon CloudWatch, написав би назву цього інструменту з такими помилками.
● Creating and peer reviewing the QA Test Cases/Plans (TestRail, Zephyr)
Пишномовно про прості речі, які є стандартними в тестуванні. Трохи ріже слух peer reviewing замість звичайного reviewing, QA Test Cases замість звичайних Test Cases. Я також не можу злити тест-плани під один слеш з тест-кейсами, бо розумію різну складність і призначення цих документів. Вказання інструментів — ок, але чи обидва використовувались у проєкті? Можливо, так, але тоді міграція тест-кейсів мала б з’явитися десь, хоча хто знає...
● Working closely with the team in troubleshooting critical defects
Повторно перевіряю, чи це не резюме продакт-менеджера. Загалом зрозуміло, що авторка робила, але написано дивно й уточнення зайві.
July-2019 — Jan-2021
Automation QA Engineer, DotsPlattform
Більш доречно було б написати QA Automation Engineer або Automated QA Engineer.
Project: Food delivery platform
Tasks performed:
● Manual testing (mobile apps and web apps)
Перша активність для позиції Test Automation Engineer (це вже я жартую, не витримав).
● Maintaining automated test project for UI web (Java + Selenium), and API testing
Не розумію, як «підтримка фреймворку для автоматизації системних енд-юзер тестів» може бути об’єднана в одному розділі з «тестуванням API». Чому не виділити окремий пункт для останнього?
● Test plan execution (regression, smoke, exploratory feature)
Знову зайві уточнення. Створюється враження, що автор не розуміє концепцію тест-плану, видів та підходів до тестування.
Зупинюся на цьому і сподіваюся, що вам сподобався цей підхід до аналізу резюме. Бажаю успіхів!
«Одна з важливих проблем — у резюме немає конкретних досягнень»
У резюме є як сильні, так і слабкі сторони кандидатки. З одного боку — чотири роки комерційного досвіду у сфері QA, що є значним плюсом. Ваги додає робота з автоматизацією тестування (Java, Python), веденням QA-команди, ступінь магістра в галузі комп’ютерної інженерії. Кандидатка детально описує завдання на попередніх позиціях, і це дає глибоке розуміння її досвіду.
Але також є кілька аспектів, які можна покращити. Першими впадають у вічі форматування та структура. Немає чіткого поділу на розділи, тому резюме важко сприймати. Наприклад, секції про навички, досвід роботи, освіту та мови повинні бути більш чітко відокремлені заголовками та пробілами. Використання заголовків, підзаголовків та маркерів допомогло б зробити резюме більш читабельним і структурованим.
У Summary хотілось би також побачити інформацію про ціль, яку кандидатка хотіла б досягти. Хвалити себе в резюме — правильно, але компанію зазвичай більше цікавить саме цілеспрямованість кандидата та його розуміння, куди він прагне і що хотів би отримати та дати кампанії. Фраза ‘I’m passionate about building efficient testing processes and collaborating between cross-functional teams’ звучить розмито і невпевнено, краще заміняти на щось більш впевнене. Наприклад:
«I can implement efficient testing processes and foster collaboration among cross-functional teams within the first three months».
Ще один слабкий бік — перелік навичок у резюме. Вони не структуровані, і є пропущені деталі, що стосуються тестування:
- Test planning — немає жодної інформації про створення стратегії тестування або тест плану проєкту, немає інформації щодо естимації задач або вибору необхідного покриття. Згадки про тест план та естимації вказані нижче в Tasks performed секції, але це варто було б також виносити в скіли
- Test analysis — покрито поверхнево пунктом Requirements analysis
- Test design — немає пунктів про створення тест кейсів або чек листів, немає інформації про використання технік тест дизайну
- Test implementation — відсутня інформація про конфігурування тестових оточень та створенні test execution schedule
- Test execution — навички не структуровані, та відразу дають зрозуміти, що кандидатка, наприклад, не орієнтується в класифікаціях видів та типів тестування. Наприклад, «Integration regression functional and non-functional testing» має кашу з видів, типів і рівнів тестування. Краще записати окремо рівні тестування (Unit, Integration, System, Acceptance). Потім надати інформацію про типи та види.
- Test completion — немає інформації про створення репортів, тільки фраза leading demos and presentations без деталізації.
- Monitoring and control — скіл Leading QA team може вмістити дуже багато чого, якщо людина була лідом, то бракує пунктів про створення та аналіз метрик з роботи команди та репортингу. Робота з ризиками теж пропущена.
Одна з важливих проблем — у резюме немає конкретних досягнень. Багато загальних фраз, як-от «ведення QA-команди» або «аналіз вимог» без результатів. Важливо додати приклади з кількісними показниками. Наприклад, замість «ведення QA-команди» можна вказати «знизила кількість помилок на 20% завдяки впровадженню автоматизованих тестів» або «успішно запустила 5 нових продуктів вчасно та в межах бюджету».
Ще один недолік — немає додаткових сертифікатів або курсів, які б підтверджували професійну кваліфікацію. Сертифікати ISTQB, курси з автоматизації тестування або додаткові навчальні програми можуть значно покращити враження від кандидатки. Граматичні та синтаксичні помилки можуть відштовхнути потенційних роботодавців і створити враження неохайності та недостатньої уваги до деталей.
Отже, для покращення резюме Вероніці варто переглянути його форматування, чітко розділити на розділи, додати конкретні приклади досягнень з кількісними результатами, підвищити рівень англійської мови, додати інформацію про додаткові сертифікати або курси, додати вичерпну контактну інформацію і виправити граматичні та синтаксичні помилки. Це допоможе створити більш професійне враження та підвищить шанси на успішне працевлаштування.
