Про задачі на співбесіді автоматизатора

#testing #automation #interview

В одному з ком'юніті минулого тижня ми обговорювали задачі на співбесіді для автоматизаторів.

Які варіанти задач я зустрічав

1. Задачі на алгоритми та структури даних (на обраній мові програмування). Це можуть бути спеціалізовані платформи типу Codility або HackerRank. Якщо це перший етап інтерв'ю - то дають 1-3 простих невеличких задачі на 30 - 60 хвилин. Якщо це частина технічної співбесіди - можуть бути задачі складніші. Плюс інтерв'юер може додавати нові вимоги.
2. Задачі типу "напиши сервіс та покрий тестами". Перевіряються як загальні скіли розробника, так і знання інструментів тестування конкретного фреймворку.
3. Задачі "ось тобі шматок коду - скажи, що він робить та де можуть бути баги". Перевіряється вміння читати чужий код, знання мови програмування та вміння знаходити баги.
4. Задачі "напиши UI чи API тести прямо зараз з нуля. Ось тобі сайт чи API". Тут перевіряється наявність ваших заготовок, вміння швидко писати тести. Якщо ви давно не працювали з бібліотекою чи фреймворком (або якщо ви займались копіпастингом БДД сценаріїв у готовому солюшені) - ви легко можете завалити співбесіду.

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

Окремо про тестові завдання

Колись давно, коли панував ринок кандидата - вважалося "поганим тоном" давати тестове завдання додому.
Таке могли собі дозволити тільки компанії з хорошим брендом (куди дійсно хотілося потрапити на роботу).
Усі інші компанії могли втратити кандидата - бо кандидати могли без тестового потрапити на подібну роботу в схожу компанію.
Але зараз ринок роботодавця. Тому тестові завдання, зазвичай, треба виконувати. Якщо ви хочете отримати роботу звісно.

Які варіанти тестових я бачив

"Покрий автотестами частину функціональності чи API". Додатково може бути завдання написати спочатку тест план для фічі.

"Ось тобі репозиторій минулого інженера (не справжній, я сподіваюся) - він щось там писав. Твоя задача проаналізувати солюшен, виправити наявні помилки та запропонувати шляхи інших покращень". Дуже хороший варіант тестового - бо ви маєте змогу показати весь спектр своїх навичок та знань.

Головне правило роботи з тестовими завданнями - краще зробити менше тестів, але щоб вони працювали, стабільно, додати автоматичний запуск тестів на Github / Gitlab CI, репорти, інші корисні речі та додати README зі зрозумілим описом.
Бо якщо у вас крутий солюшен з усіма паттернами в світі, але він незрозумілий або навіть не запускається локально - то це величезний мінус.

А які варіанти задач на співбесідах зустрічали ви?

Для тих, хто готується до технічної співбесіди

#automation #interview

Сьогодні хочу поділитись підбіркою записів з технічних співбесід.
Можна подивитись, які питання задають, як взагалі проходять кодинг секції у великі компанії, типу FAANG

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

Матеріали для підготовки до behavioral інтерв'ю

#interview

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

То ж пропоную до вашої уваги невеличкі нотатки з такого роду питань.

Чому не треба зловживати ChatGPT та іншими AI інструментами для резюме

#interview

Вчора прочитав цікаву статтю від Ben Hoyt з Cannonical. І хочу поділитись головними тезами з неї.

Не зловживайте ChatGPT

Чому? Бо тексти генеруються дуже схожі та здається, що їх писав робот (особливо для носіїв мови).
Якщо англійська - не рідна вам мова, хай так буде. Пишіть так, як можете.

Не користуйтеся "квітчастою" прозою

Резюме - це не роман чи оповідання.
То ж не треба застосовувати тут усю свою літературну майстерність (залиште це для IELTS / TOEFL чи власного блогу).

Автор наводить приклад:

- had a profound mastery of Java (they’re not James Gosling)
- their journey commenced (they’re not Bilbo Baggins)
- they skillfully constructed programs (they’re not Stradivarius)
- they extended their expertise (not only an expert, but an extended one)
- they crafted Lambda functions (I prefer artisanal Lambdas)
- they leveraged Spring Boot (or did they just use it?)
- they swiftly adapted (this is getting old)
- they meticulously read documentation (good, I will hire them as a proof-reader)
- they embraced object-oriented programming (like everyone in the 90’s)
- and they brought forth robust experience (but do they bring robust Forth experience?)

Тому концентруйтеся саме на суті та пишіть простіше.

- I’m experienced with Java
- I started
- I built
- I learned
- I wrote Lambda functions
- I used Spring Boot
- I adapted
- I read the docs
- I use object-oriented programming (or drop that entirely)
- I gained experience

Не узагальнюйте

Наприклад, на питання "Як би ви описали процес додавання нових фічей на продакшн", кандидати часто пишуть так, наче скопіювали з книги:

Designing and implementing new software starts with gathering requirements, writing a specification, seeking feedback from stakeholders, and then a quality implementation. After it’s implemented, automated testing and manual QA are important. Then we deploy the software and make sure to monitor it properly.

Своїми словами можна описати це так:

I really like succinct specs and some up-front planning. When I was designing the new auth service, for example, I wrote a 3-page spec that included an architecture diagram and a brief description of the API endpoints. Before deploying to production, I think it’s important to load test a real server, so I set up a similar staging environment and measured how many concurrent requests it could serve. Once in production, monitoring is crucial: I’ve used Datadog as well as open-source tools like Prometheus to detect and diagnose issues.

Висновок

Cannonical навіть додали застереження від застосування AI інструментів для резюме в свою форму подачі.
Користуйтеся інструментами обережно.

Про знання своїх інструментів

#interview #testing #tools

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

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

Крім того, треба завжди мати відповіді на питання:
- "а чому саме цей інструмент?"
- "які є альтернативи?"
- "чому альтернативи нам не підійшли?"

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

То ж ще раз - вивчайте свої інструменти. Знайте їх сильні та слабкі сторони.

Вдалого усім тестування!

50 shades of Fibonacci

#coding #interview #python

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

Для тих, хто забув - це послідовність типу 0, 1, 1, 2, 3, 5, 8, 13, 21, ..., що описується формулою:
F(n) = F(n-1) + F(n-2), де F(0) = 0 та F(1) = 1.

Виявляється, одну й ту саму задачу можна вирішити по-різному. Кожне рішення покаже ваш рівень розуміння задачі, мови програмування та тестування негативних кейсів.

Перед тим, як дивитись приклади - пропоную самим спробувати написати код.

1. Простий та наївний підхід - обчислюємо так, як написано у формулі (з рекурсією):

def fib(n: int) -> int:
    return fib(n-1) + fib(n-2)

Але тут можна легко отримати RecursionError: maximum recursion depth exceeded

2. Покращуємо код, додаючі перевірку базових кейсів:

def fib(n: int) -> int:
    if n < 2:
        return n
    return fib(n-1) + fib(n-2)

3. Можна також застосувати техніку мемоїзації (тобто замість обчислень знову й знову - запам'ятовуємо проміжні результати):

from typing import Dict

memo: Dict[int, int] = {0: 0, 1: 1}
def fib(n: int) -> int:
    if n not in memo:
        memo[n] = fib(n - 1) + fib(n - 2)
    return memo[n]

4. Мемоїзація також є "вбудована" в сам Python:

from functools import lru_cache

@lru_cache(maxsize=None)
def fib(n: int) -> int:
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)

5. Замість рекурсії - можна вирішити задачу з циклом:

def fib(n: int) -> int:
    if n == 0:
        return n
    last: int = 0
    next: int = 1
    for _ in range(1, n):
        last, next = next, last + next
    return next

P.S. Можна ще обчислити за допомогою генераторів, але цей спосіб розберемо в наступних нотатках.

Знайти співробітників з найбільшою зарплатнею

#python #interview #coding

Всім привіт.
Сьогодні я прийшов до вас із задачею. Цю задачу можна вирішити для тренування, а можна навіть дати на співбесіді. Бо задача вкрай нескладна та можна швидко отримати рішення. Відповідь покаже рівень знання мови програмування.

Задача

"Уявімо, що ви працюєте в HR департаменті великої компанії. Вам прилетіла задача написати новий ендпоінт, який буде повертати всіх співробітників, що мають ЗП більше, ніж $100,000 на рік. Поверніть результат у вигляді набору з двох елементів - імені працівника та його зарплати".

Вхідні дані - це map такого вигляду:

employees = {'Alice': 100000, 'Bob': 99817, 'Carol': 122908, 'Frank': 88123, 'Eve': 93121}

Рішення буде наприклад таким:

top_earners = []  
for key, val in employees.items():  
    if val >= 100000:  
        top_earners.append((key,val))
print(top_earners)

Але існує трохи більш елегантне рішення, що показує можливості мови Python:

top_earners = [(k, v) for k, v in employees.items() if v >= 100000]
print(top_earners)

Або навіть:

top_earners = list(filter(lambda x: x[1] >= 100000, employees.items()))
print(top_earners)

Як бачите, на кожну проблему може бути декілька варіантів рішень. Але не забувайте PEP20 - "There should be one-- and preferably only one --obvious way to do it."

А як буде виглядати рішення на вашій улюбленій мові програмування?

Про пошук роботи

#interview

Для багатьох людей пошук роботи = пошук вакансії на DOU/Djinni/Linkedin та подання на неї.
Але чим вище у вас позиція та років досвіду, тим менше ефективності від такого пошуку.

Що ще можна зробити, щоб підвищити свої шанси знайти роботу?

Прокачайте свій Linkedin профіль (допоможіть рекрутерам знайти Вас)

- Встановіть чіткий headline: в чому ви кращі, в чому ви спеціалізуєтесь?
- Додайте опис кожної роботи та що конкретно ви там робили (можна написати навіть більше, ніж у вашому CV)
- Застосовуйте ключові слова в секції summary
- Приберіть нерелевантний досвід роботи

Шукайте на Linkedin
- продивіться вашу мережу контактів. Можливо хтось може зробити Вам рекомендацію. Або просто відповісти на питання про те, як працювати в тій чи іншій компанії
- пошукайте цікаві продукти та компанії. Дізнайтесь яких спеціалістів вони шукають (або шукали нещодавно).
- проаналізуйте вимоги вакансій - це допоможе зрозуміти ваші пробіли в знаннях та можливі варіанти росту
- напишіть пост пошуку роботи в Linkedin (це краще працює, коли у вас вже є досвід роботи)

А щоб оцінити свій рівень поточної ЗП - можна прийняти участь в літньому опитуванні від DOU.

How SQL Query works? SQL Query Execution Order for Tech Interview

#engineering #howitworks #interview

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

По-перше - це цікаво.
По-друге - дехто може задати щось подібне на співбесіді - то ж ви зможете відповісти на базовому рівні на таке питання.

📹Співбесіда на Junior QA

#testing #interview

Вчора, на запрошення Олекси з каналу QA Україна, я проводив публічну тренувальну співбесіду для кандидата на рівень Junior Manual QA.

Для чого проходити такі тренувальні співбесіди?

- дізнатись свої сильні та слабкі сторони
- отримати поради куди рухатись далі, що вчити та як практикувати знання
- отримати досвід проходження інтервʼю

❗️Я проводжу подібні співбесіди (не публічні), разом із розгорнутим зворотнім звʼязком, разом із ревʼю резюме.

Якщо у вас є бажання пройти подібну співбесіду - пишіть мені в DM. ✍️

🎙Як компанії обрати кращого тест інженера

#testing #interview

Ben Fellows поділився цікавим підходом для оцінки рівня тест інженерів на співбесіді. Зазвичай, Ben шукає кандидатів рівня 3 або 4.

Питання:

"Потрібно випустити важливий реліз, але час на тестування обмежений. Як Ви будете пріоритезувати тестові активності, в залежності від ризиків та впливу на користувача та бізнес?"

1️⃣Рівень 1 - Реактивний та сфокусований на задачі.

Я почну з тестування логіну та покупки, тому що вони найголовніші.

2️⃣Рівень 2 - Баланс між технічними та бізнес потребами, але без структурованого підходу.

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

3️⃣Рівень 3 - Використання структурованих фреймворків, пріоритезація ризиків, вибір тестових активностей в залежності від бізнес задач.

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

4️⃣Рівень 4 - Застосування системного мислення, прогнозне моделювання та безперервне покращення

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

❓А ви як думаєте? Яка відповідь найкраща?

Про вміння працювати та проходити співбесіди

#interview

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

Чим більше працюєш в індустрії, тим більшим стає коло знань та досвіду. Але коло поточних навичок може бути обмеженим - конкретною посадою чи проєктом.

Знання для проходження співбесід - це окремий великий пласт знань. Який не завжди пересікається з вашим набором знань.

У кожного технічного інтервʼюєра свій власний багаж знань. Плюс - вимоги конкретної компанії до конкретної позиції.

Задача інтервʼюєра - знайти перетин між вміннями кандидата та вимогами позиції. Можливо перетину не буде. Але тоді - треба оцінити перспективу швидкого навчання.

А ще - знання та вимоги у кожного інтервʼюєра - різні.

Шо робити? 🔽

Що ж робити в такому випадку? 🕶

Треба прийняти декілька важливих умов:

1. Проходити співбесіди непросто - ринок жорсткий й вимоги високі
2. Бути хорошим спеціалістом не дорівнює легко пройти співбесіду
3. Мати десятки років досвіду не означає, що ви відповісте на будь-які питання інтервʼюєра
4. Підтримка навичок в актуальному стані - процес постійний. Бо від звільнень не застрахований ніхто.

👉 Загальні поради:

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

Це - непросто, навіть для сіньйорів.
З мок інтервʼю та підготовкою я можу допомогти. Пишіть в ДМ або в коментарі.

Why do we fail at interviews?

#testing #interview

Невелика стаття, де я розповідаю, чому нам зазвичай складно проходити співбесіди.
А як ви проходите інтервʼю? Чи вам легко відповідати на усі питання?