Как проводить собеседования🗣
[часть 1]

Обычно подбор кандидата проводится в несколько этапов:
- встреча с HR
- техническое собеседование (может быть разделено на несколько этапов)
- встреча с командой

Я хочу поговорить именно о техническом собеседовании и как к нему подходить со стороны нанимающего.

Стандартный план технического собеседования QA
(присутствие и отсутствие этапов зависит от вакансии):

1. Знакомство
- вы рассказываете о формате встречи
- кандидат описывает свой прошлый опыт и свои навыки.
2. Вопросы на базу теории тестирования.
3. Технический блок
- специфика тестирования: web/mobile/backend/desktop
- автоматизация тестирования
4. Практический блок
- задачи на теорию тестирования (тест-дизайн, локализация и прочее)
- ситуационные вопросы
- лайв-кодинг
5. Вопросы от кандидата

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

Поговорим о каждом поподробнее

Выстраивание процесса

Для построения хорошего процесса я бы изучила следующий материал

- Лучший дизайн процесса собеседований: объясняет, почему сейчас мы часто строим собеседования неправильно, как лучше выстраивать вопросы, как в этом поможет матрица компетенций и еще куча всего. По мне одно из лучших чтений на эту тему.
- Теория по собеседованиям: какие виды существуют, как подготавливаться, какие вопросы лучше задавать и все в этом направлении.
- Видео “Как проводить собеседования, чтобы было интересно кандидату и не обидно HR”: очень нравится подход, описание и общие шаги.
- Изучить чужой опыт, например, как проходит интервью в Тинькофф

О вопросах и подготовки себя поговорим в следующей части 🔜

💡Вопросы на собесе Junior/Middle QA

I. Общие:
1. Почему ищешь новую работу
2. Что не так с текущей компанией
3. Почему заинтересовала наша компания
4. Как пришел в тестирование и почему

II. Теория:
1. Что такое тестирование
2. Отличия тестирования и QA
3. Цикл разработки ПО
4. Атрибуты тест-кейса
5. Атрибуты баг-репорта
6. Приоритет и Серьезность
7. Виды тестирования
8. Если мы тестим АПИ, это черный или белый ящик
9. Уровни тестирования
10. Функциональное и нефункционально тестирование
11. Регресс. Как, когда, где и зачем
12. Жизненный цикл дефекта
13. Техники тест-дизайна
14. Виды тестовой документации
15. Зачем нужен Postman, Swagger, Git
16. Что такое CI/CD. Какие инструменты применяются
17. Протокол http
18. IP адрес
19. Основные методы запросов (GET POST PUT DELETE)
20. Что такое куки. Что там есть
21. Что такое кэш. Как используется, почему важен нам
22. Заголовки http-запросов
23. Коды ответов
24. Что такое JSON. Как выглядит
25. Что такое XML. Чем отличается от JSON
26. Что такое АПИ
27. Разница между REST и SOAP
28. Что такое web socket
29. Разница между tcp и udp
30. Клиент-серверная архитектура. Кластер серверов, кластер БД, балансировщик
31. Что такое микросервисная архитектура

III. Опыт:
1. Какие виды тестирования применял. Почему?
2. Какую документацию писал?
3. Работал ли с Линукс? Какие команды использовал?
4. Тестил ли мобилки
5. Какой у вас процесс тестирования
6. Что можно было бы улучшить
7. Куда хочешь развиваться
8. Какая архитектура у вас была, какие технологии использовались
9. Общался ли с пользователями? Как обрабатывали баг репорты от юзеров?
10. Какие стенды у вас были, как происходила раскатка новых фич
11. Что делал после релиза на прод?
12. Кто определял priority и severity?

IV. Практические задачи:
1. Разраб говорит, что заведенный тобой баг - не баг и фиксить он это не будет. Твои действия?
2. Репорт от пользователя: не приходят пуши в мобильном приложении. Как и где будешь искать причину?
3. Что делать, если времени на тестирование не хватает? Как выставишь приоритеты?
4. Что будешь делать, если вечером перед релизом нашел критичный баг? (не блокер)
5. Как выстроишь процесс с нуля? Приложение уже есть, тестирования нет
6. Сайт с тестовыми заданиями, 1 и 2 челлендж

❓Как вам список? Чего не хватает? Какие интересные вопросы задавали вам на собесах?

Другое по теме:

💡12 вопросов на интервью для Senior QA
💡Подборка Телеграм-ресурсов для поиска работы в IT
❓Где искать работу на Европу?

#hardskills #softskills #interview

Горящий Тестер 🐞 QA, Тестирование

Выложил новое мок-собеседование Automation на Java на английском языке с Ариной Левадной.

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

Один из терминов, с которым можно встретиться, это идемпотетность. Этот термин предложил американский математик Бенджамин Пирс.

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

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

Часто об идемпотетности говорят в контексте REST, идемпотентность означает, что выполнение одного и того же HTTP-запроса несколько раз приведет к тому же результату, что и выполнение этого запроса один раз. Несколько примеров идемпотентных операций в REST:

1. GET запросы: Получение информации через GET запрос всегда идемпотентно, так как он не изменяет состояние сервера.

2. PUT запросы: Этот запрос используется для обновления ресурса на сервере. Если вы отправите PUT запрос с теми же данными несколько раз, это не повлияет на состояние ресурса на сервере. Например:

PUT /users/123
   {
       "name": "John",
       "age": 30
   }
   

Если этот запрос будет выполнен несколько раз, информация о пользователе с идентификатором 123 будет обновлена до "John", 30, но состояние сервера не изменится.

3. DELETE запросы: Удаление ресурса с помощью DELETE запроса также является идемпотентной операцией. Если вы отправите DELETE запрос для удаления ресурса, его повторное выполнение не изменит состояние сервера. Например:

DELETE /users/123

Если этот запрос будет выполнен несколько раз, ресурс с идентификатором 123 будет удален, и состояние сервера не изменится.

POST не считается идемпотентным, так как может использоваться для создания новых ресурсов.

Однако часто возникает потребность делать POST запрос идемпотентным принудительно, так как повторное выполнение POST запроса с теми же данными может привести к созданию дубликата ресурса или ошибке, если ресурс уже существует, например, запрос create user имеет смысл сделать идемпотентым для того, чтобы избежать дубликатов.

Отличный ресурс с бесплатными курсами по тестированию и другими полезными материалами.

И еще один от этого же автора