Заметки о QA

(план в виде картинки)

Как рассказать о себе на собеседовании? Один из этапов собеседования - это рассказ о себе. Зачем рассказывать о себе? Ведь кажется, что резюме уже отражает весь опыт кандидата. Но в живом рассказе выделяются детали, которые важны для самого человека, подробности о процессах в компании и роли в команде, огонь в глазах при рассказе о любимом рабочем процессе и много чего ещё, что позволяет лучше понять, подходит ли кандидат нанимающей компании. Для ускорения вашей подготовки к этапу самопрезентации, хочу поделиться планом, на базе которого я строю свой рассказ. 1. Имя, должность и количество лет в профессии. 2. Рассказ о последнем месте работы. - продукт - состав команды - занимаемая роль - обязанности - соотношение автоматизации/мануального тестирования, web/mobile/desktop 3. Стек инструментов. 4. Рабочие процессы. - методология разработки на проекте - события команды (рабочие созвоны по типу дейли, груммингов, планирования) - степень влияния на продукт - участие в ревью документации - этап создания продукта, на котором начинаешь тестирование - участие во вне командных активностях компании 5. Зоны ответственности в команде/компании. - проведение релиза - онбординг - внедрение продуктов - проведение собеседований - особые достижения, на которые хочется обратить внимание 6. Подчеркнуть релевантный опыт для компании. Дополнительно можно рассказать о том, что ты ищешь в новой работе и почему хочешь сменить текущее место. Добавлю, что мне, как собеседующей, всегда приятно услышать цельный рассказ о человеке, а не вытаскивать плоскогубцами каждое слово. Полезный материал 1. Youtube-видео Самопрезентация учит нас доносить идеи

Советы для автоматизации [2] Первую часть советов можно почитать тут, также рекомендую полезные советы по инструментам для программирующих на Java. - Автоматизация тестирования - это инструмент для достижения цели, а не сама цель. Часто, когда работаешь full-stack QA, легко увлечься автоматизацией и улучшением кода, забывая о главном — обеспечении качества функционала. Поэтому хочется напомнить, что автоматизировать нужно для того, чтобы это приносило пользу бизнесу и помогало улучшить качество продукта, а не просто для того, чтобы писать код. - Чаще учите и используйте горячие клавиши в своей IDE. Не ленитесь запоминать сочетания клавиш в ваших средах разработки. Это поможет ускорить процесс написания кода и облегчить вам ежедневные повторяющиеся действия. Мои любимые сочетания клавиш (macOS, IntelliJ IDEA): cmd + click (либо b) - отображение, где метод/класс/прочее используется в коде double shift - быстрый переход к классу/функции option + cmd + l - форматирование кода (сделать по всему классу правильные отступы) cmd + w - закрытие вкладки control + options + o - удаление неиспользуемых импортов (также рекомендую включить автоматическое удаление таких импортов) shift + options + click - курсор на несколько строк cmd + d - дублирование строки без ее выделения и копирования (буду рада увидеть ваши любимые горячие клавиши в комментариях) - Тэгируйте автотесты для гибкого управления. Последнее время я стала больше ценить тэгирование и кастомизацию запуска прогонов. Чем больше становится тестов, тем проще запускать не все подряд, а только те, с которыми ты сейчас работаешь. На помощь приходят аннотации для тэгов, которые можно найти практически для любого фреймворка тестирования. - Разрабатывайте тестовые сценарии, учитывая реальных пользователей API. Покрывать тесты и придумывать варианты использования - это хорошо. Но иногда эффективнее заглянуть к тем, кто использует бэкенд. Например, фронтенд. Изучите, какие данные отправляются, какие запросы участвуют в работе и как происходит обработка ответа. Есть ли вариации, которые не описаны в ваших автотестах? Ведь именно реальные пользователи бэкенда находят баги, а не тесты в вакууме. - Воспринимайте ревью кода как возможность для роста. Изначально ревью кода вызывал у меня страх и напряжение. Но постепенно я научилась воспринимать ревью как полезный инструмент: именно в процессе ревью я улучшала качество своего кода и училась новым фишкам. Ревью кода позволяет другим указать на недостатки, которые вы могли пропустить, и научить вас больше не повторять такие ошибки. - Используйте плагины для поддержания стиля кода. Одним из способов улучшить качество кода и упростить процесс ревью является использование линтеров, например, Checkstyle. Они позволяют автоматически проверять ваш код на наличие распространенных ошибок. Например, подсветит вам неиспользуемые методы, усложнение кода и прочие несоответствия стилю. Такие инструменты помогут поддерживать высокое качество кода и избегать мелких ошибок, которые так и норовят образоваться в коде. See you soon #автоматизация #java #советы

Полезное про Selenoid Selenoid - инструмент, который позволит вам запускать ваши UI или Anrdoid автотесты параллельно и изолированно в Docker-контейнерах. Рекомендую для первоначального ознакомления обзорный гайд по Selenoid Мне нравится этот инструмент легкостью использования и минимальным порогом вхождения. На вашем компьютере всего лишь должен быть docker, в котором будут разворачиваться уже настроенные docker-контейнеры. Варианты запуска Selenoid 1️⃣Скачать подготовленный образ с помощью curl или через браузер из официального github Инструкцию для запуска образа можно почитать в документации либо рекомендую статья для windows. Для macOS мне подошла вот эта статья (это medium, поэтому запуск через VPN) 2️⃣Самостоятельно создать docker образ (либо docker-compose), файл конфигурации браузеров (browser.json) и запустить сборку контейнеров через консоль. Самостоятельное создание позволит гибко подойти к образу, необходимым вам браузерам и их настройкам Примеры для самостоятельного создания - Минимальный пример написания docker compose и browser.json - Пример docker compose + browser.json и описание работы - Настройка Selenoid для запуска UI-тестов на Android Функции, которые понравились мне ➖Selenoid UI: инструмент для визуального отображения работы с Selenoid. Позволяет просматривать результаты тестов и прочую информацию, а также подключаться к тестам в режиме реального времени* для этого необходимо включить опцию VNC в capabilities ➖ Доступ к видеозаписям прогонов В инструменте есть возможность записи видео прохождения автотестов. Мне кажется, что это очень удобная функция для добавления видео в баг-репорт. В процессе работы я столкнулась с проблемой того, что видео прогона не записывалось. Что помогло мне: - настроить файл docker-compose.yml: указать пути к папкам, где будут сохраняться видеозаписи, и прописать соответствующие команды в command - создать папки для дублирования видео из docker в файлы - настроить capabilities* в автотестах, которые можно подсмотреть на соответствующей вкладке в Selenoid UI * Capabilities определяют возможности браузера во время тестирования Также для кастомизации запуска видео рекомендую статью про Extensions (Java) Прочие рекомендации Более подробный пример работы с Selenoid (Java)

Подборка каналов про тестирование В начале этого года я делилась с вами подборкой tg-каналов про тестирование. С тех пор прошло больше полугода, и мы тщательно пересмотрели этот список, чтобы убедиться, что каждый канал предлагает уникальный и ценный контент. Сегодня я рада представить вам обновлённую версию этой подборки! Готовы погрузиться в мир тестирования? Тогда жмите на ссылку ниже и начинайте исследовать! 🌐 https://t.me/addlist/PNmSaWa9ktw2YjRi

Чем могут быть полезны Extensions в JUnit5 Extensions - список интерфейсов, которые появились в JUnit5. Они расширяют работу с жизненным циклом в автотестах. Чем поможет Сделает работу с автотестами гибкими. Например, раньше мы могли работать в рамках автотеста только с Before и After. Благодаря extensions вы можете значительно повлиять на работу автотестов, сравните хотя бы количество этапов в жизненном цикле (картинка по ЖЦ автотеста в junit5). Теперь легко повесить общую аннотацию @Something на класс автотестов, внутри которой будет реализация полноценной настройки окружения. Это позволит не дописывать в каждом новом классе велосипед, настраивающий окружение. Примеры использования интерфейсов - ExcisionCondition: может создать условие для запуска теста. Например, вы хотите запускать тесты только на ОС = Windows. Мы создаем реализацию класса и особенности запуска, добавляем его к классу и вуаля, ваш тест имеет особенности запуска. - ParameterResolver: позволяет предоставить параметры для автотестов. Например, у вас специфический тип в параметрах, и вам нужно гибко его передавать, а стандартной работы JUnit5 вам не хватает. - TestWatcher позволяет сделать что-то при падении или запуске теста. Он следит за тестами и ходом их выполнения. (полная документация всех интерфейсов в extension) В рамках extension мне очень нравится такой класс как ExecutionContext, который позволяет получить доступ к данным о тесте, его местонахождении, параметрам запускам и всем-всем, связанным с тестом. Что почитать/посмотреть Я познакомилась с Extensions благодаря выступлениям Дмитрия Тучс, которые рекомендую и вам: - Дополнительная открытая лекция с продвинутого курса по Java, где я впервые услышала про extensions - JUnit, дай пять! Переносим код в JUnit 5 Extensions - Доклад The art of JUnit extensions с Heisenbug (вторая часть этого доклада есть на сайте конференции, но ее пока нет в открытом доступе) Прочие полезные материалы: Статья про практическое применение Extensions (kotlin) Полное руководство по расширениям JUnit 5 (java) Практическое применение Extensions с канала Oleh Pendrak Руководство по расширениям JUnit 5

(обязательный мем к посту)

Про правильное формулирование, мета-вопросы и решение проблем путем редких ответов Чем дольше я работаю и общаюсь с людьми, тем чаще понимаю, как правильно сформулированный вопрос ускоряет процесс решения проблемы. Например, сегодня ко мне пришли с запросом "Не могу найти документ в системе, помоги". Я полезла в базу данных и логи двух микросервисов, чтобы проследить путь документа и обнаружила, что документ доставлен до системы. После проведенного исследования и предоставления ссылки на документ, я получила ответ: "Да, ссылка на документ у меня есть. Но вот в другую систему он не направился, а еще в статусе ошибки подписи". Тут возникает вопрос: значит коллега знал, что документ дошел до системы, но все равно спросил, где документ? Соответственно вопрос в поиске документа не стоял, а запрос оказался в другом: почему подпись не отработала. Из чего следует, что путь документа нам не нужно было отслеживать и я зря потратила на это свое время. Если бы коллега сформулировал вопрос сразу с подробностями, это сэкономило бы мне минимум 10 минут и сохранило бы силы на решение более насущного вопроса, а именно почему в подписи возникли проблемы. Проблемы с формулированием вопросов встречается постоянно, поэтому следует тщательнее подходить к этой задаче. Оттого, насколько качественно сформулирован вопрос, настолько же полноценно будет дан ответ на него. Как лучше формулировать вопрос: - описать, где и когда произошла проблема - перечислить, какие данные по проблеме собраны - описать, какие действия уже были проделаны для решения (шаг необходим, чтобы собеседник не предлагал вам уже сделанные действия) - объяснить, что требуется от человека, чтобы он тебе помог Перед отправкой перечитайте сообщение и проверьте, нет ли уже ответа на ваш вопрос в нем же. Примеры Плохой вопрос: я не могу понять, как замержить в репозиторий autotest Хороший вопрос: Мне нужно замержить новые автотесты в ветку master. При попытке мержа через консоль у меня возникает ошибка 403. Я пытался сменить пароль на новый, но это не помогло. Google подсказал, что ошибка может возникать из-за прав доступа к мастеру, но я их не могу посмотреть. Можешь ли ты объяснить, куда мне сходить для получения прав, или объяснить, что еще можно сделать? В таком случае человек сразу поймет, что ошибка заключалась в мерже в мастер без дополнительной ветки, ведь в их репозитории это запрещено. И объяснит, какой список действий нужно проделать для мержа. Что можно попробовать сделать, если вам задают плохо сформулированные вопросы Чаще всего причина плохих вопросов в лени их формулирования. В этом может помочь игнорирование вопросы на 30 минут: через пол часа вопрос порой пропадает сам по себе или становится нормально сформулированным с описанием собранных материалов и проделанных шагов. Мета-вопросы В связки с формулированием вопросов, я бы порекомендовала вам почитать про мета-вопросы, которые съедают не только ваше время, но и время собеседника. Пример мета-вопроса простой: когда ты вместо формулирования вопроса, просто пишешь "Тут?" и отвлекаешь собеседника. Подробнее почитайте по ссылке. Важно помнить, правильно сформулированный вопрос - это уже половина ответа на него. #softSkills

Блок-схема "Как выбрать язык программирования для автоматизации" В чек-листе перехода в автоматизацию (тык) я писала не только о необходимых для автоматизации навыках, но и о списке действий, которые могут помочь вам перейти в автоматизацию или развивать ее на текущем проекте. Один из главных пунктов начала знакомства с автоматизацией - это выбрать язык программирования. Я уже отмечала, что на этом этапе важнее выбрать язык и развиваться в нем, а не зарыться в выбор языка, так как на реальных работах вы можете поработать на многих языках программирования. Важнее уметь программировать, а не на чем вы это делаете. Часто бывает, что именно выбрать язык - это огромный шаг, который нас останавливает. Поэтому я постаралась немного облегчить решение и подготовила схему выбора первого языка программирования. Надеюсь, мне удалось учесть большинство особенностей, которые могут возникнуть на этом шаге, но если нет, рада буду почитать комментарии.

Мой личный путь и поиск карьерного развития Недавно мне посчастливилось поучаствовать в QA Sis Conf #2, где вместе с другими удивительными девушками я поделилась своим опытом работы в сфере тестирования и поиском путей для развития, которые использовали после года в профессии. Рекомендую к просмотру: QA Sis Conf #2 Год в тестировании - что дальше. Во время подготовки к мероприятию я задумывалась о своем пути в тестировании и о том, как я ищу новые горизонты для своего профессионального роста. И вот что произошло: я обнаружила, что у меня есть план, по которому я составляю свой карьерный трек и ставлю цели на ближайшее время. Теперь я хочу поделиться этим планом с вами: 📝Составление плана развития Статья включает в себя три ключевые части: поиск своих сильных сторон, определение зон для развития и выбор конкретных целей для достижения этого развития. Подробнее читайте в источнике🥸 Надеюсь, что план вдохновит вас на поиск будущих целей в вашей карьере!

Практики хорошего кода Чем дольше я программировала, тем больше понимала, насколько много ошибок было у меня в самом начале пути. Сегодня я хочу немного погрузиться в инструменты, подходы и принципы, которые позволят создавать качественный код с самого начала. Что помогает нам создавать красивый и расширяемый код: - Использование практик написания хорошего кода: они позволят навести порядок в коде, упростить расширение проекта и переиспользовать код, но сохранять при этом логику и читаемость и много чего еще. - Применение популярных паттернов проектирования и автоматизации, которые были уже проверены ни раз до нас: помогут найти типичный вариант рабочей структуры, что позволит не строить велосипед. - Проведение ревью в команде: обзор кода помогает выявить потенциальные проблемы и предложить улучшения, которые мог упустить человек, писавший код. - Соблюдение руководства по стилю и подключение библиотек, которые эти стили проверяют: одинаковые правила к коду позволят улучшить читаемость, быстрее решать спорные вещи в ревью и создавать согласованный код, что позволит избежать стандартных ошибок. А также позволит не создавать трех одинаковых методов, отличающихся только названием - Документирование и комментирование кода: комментирование методов и классов упростит переиспользование методов и ускорит чтение кода. Поподробнее советую почитать в этой статье. Про паттерны автоматизации я уже писала в этом посте, а сейчас хочу поговорить про практики написания кода. В статье Улучшаем код автотестов: популярные практики и их примеры я расскажу про такие подходы, как SOLID, KISS, DRY и YANGI и на примере автотестов постараюсь показать применение этих принципов. В конце вас ждут полезные материалы, в которые обязательно стоит заглянуть. #автоматизация

Блок-схема локализации бага: фронт или бэкенд? Я создала небольшую блок-схему, которая может помочь вам определить источник обнаруженного бага. Вы можете добавить множество дополнительных ветвей. Допустим, если ошибка если ошибка от бэкенда 5хх, то точно ли она корректно обрабатывается и не нужно ли изменить ее на 4хх, что будет более информативно? Здесь многое зависит от специфики вашей работы и особенностей сервера. Однако для общих случаев подойдёт и предложенная мной блок-схема, поэтому верю пользе от нее💫. (в хорошем качестве блок-схема представлена в следующем сообщении)

Логи и их применение в работе Работаете ли вы с логами в своей работе? Если нет, то давайте разберёмся, что это такое и как их можно использовать. Если да, то, возможно, я смогу рассказать вам о новых способах работы с ними. Логи — это текстовые записи, которые описывают работу программы. В них содержится информация о том, что произошло, в какой последовательности, какие значения передавались или изменялись. Что может логироваться — Изменение статусов сообщений. — Создание/изменение/удаление сущностей. — Взаимодействие с другими сервисами. — Перезагрузка и ошибки приложения. — Вызов методов. — Запуск задач. — Данные пользователей — Системная информация Созданием логов занимаются разработчики: это непосредственно содержится в коде программы (или добывается какими-то дополнительными инструментами). Поэтому важно понимать, что логи могут быть как скудными, так и очень детальными. Мы, тестировщики, также можем влиять на это и попросить увеличить их подробность и детальность. Как можно использовать логи в работе тестировщика — Провести локализацию бага: поиск в логах информации о сбоях или ошибках, застревании в каком-то статусе, неправильной обработке сообщения и получение любой информации, которая позволит нам понять, почему возник баг. — Отслеживание пути предмета тестирования: через какие статусы он проходил, как обновлял значения, куда отправлялся. Особенно это полезно при отсутствии визуальной составляющей, что упростит понимание правильной работы. — Создание подробного логирования ошибок приложения или его падения. Это полезно для быстрого реагирования поддержки на баг и поиска причины проблемы у пользователя. — Проверка интеграции с другими сервисами, их доступность и корректное взаимодействие — Анализ производительности. Логи могут содержать информацию о производительности приложения, такую как использование памяти, загрузка процессора или сетевая активность, что помогает выявить узкие места и оптимизировать работу приложения. Пример работы с логами У меня возникла ошибка, например, при создании сущности возвращается 500 и сущность не создаётся. Я понимаю, что возникла ошибка, но должна найти причину и локализовать ее. Я сразу иду в логи и изучаю историю, которая произошла в момент создания: возникла ошибка при сохранении сущности в базу данных: разработчик забыл заполнить обязательное поле, и запись просто не произошла. При отсутствии логирования процесс локализации занял бы совсем не 5 минут. Совет для работы с логами Иногда логирование неполное или к логам нет доступа, что не позволяет использовать этот инструмент в полной мере. Я всегда за то, чтобы тестировщик мог максимально использовать все инструменты в работе, ведь это улучшит процесс тестирования и проверки функционала. Поэтому при любой возможности добивайтесь доступа к логам и к их расширению, если это упростит вашу работу и улучшит процесс тестирования! Полезные материалы О чём могут рассказать логи: важный инструмент в работе тестировщика Как тестировщику работать с логами Уровни логирования как использовать логи Как снимать логи с устройств на Android и iOS Инструменты для тренировки: Kibana (программа для удобной работы с логами) и ее функции, а также тренажер для практики в Kibana #инструменты

Как проводить собеседования🗣 [часть 2] Подбор вопросов Важный этап подготовки к собеседования - это выбор вопросов. От чего я отталкиваюсь, когда составляю вопросы: - резюме кандидата и его опыт: что он делал и в чем силен - навыки и знания, необходимые именно для вакансии (в том числе учитывать материал, построенный на прошлом этапе подготовки), рекомендую статью на эту тему - упор в оценку применения теории на практике - мое обязательное знание ответа на вопрос, который я задаю! Где взять базовые вопросы, которые позволят составить ваш идеальный список: - Популярный список всех вопросов. - Вопросы про автоматизацию тестирования. - Вопросы для оценки опыта кандидата. - Чек-лист тем для собеседования. - Огромный список вопросов для QA. - "Анализ 10 000 вопросов с технических интервью: частотность и вероятность встречи". Подготовка себя как собеседующего Нам всегда кажется, что самое страшное - это быть на месте собеседуемого. Но знали бы вы, как волнительно быть с другой стороны. Один из полезных советов, как меньше волноваться, это посмотреть, как кто-то другой проводит собеседование, а особенно в первый раз поучаствовать в качестве помощника на реальном собеседовании. Если такой возможности нет, то советую приглядеться к следующим мок-собеседованиям: - Публичное собеседование QA лида. Алексей Петров, Ольга Артемьева. - Публичное собеседование: QA Lead. - Реальное техническое собеседование на работу тестировщиком Senior AQA. - Automation QA мок-собеседование. - Собеседование на микросервисный проект. - Собеседование на должность Middle QA Automation. - Публичное собеседование / мок-интервью для QA-инженера. Также рекомендую почитать об опыте нанимающего часть 1 и часть 2 Обязательно помните, что вы лицо компании. И именно благодаря вам создается впечатления о ней. Надеюсь, этот список поможет вам покорить вершину первого собеседования или улучшить текущий подбор кандидата 🥳

Как проводить собеседования🗣 [часть 1] Обычно подбор кандидата проводится в несколько этапов: - встреча с HR - техническое собеседование (может быть разделено на несколько этапов) - встреча с командой Я хочу поговорить именно о техническом собеседовании и как к нему подходить со стороны нанимающего. Стандартный план технического собеседования QA (присутствие и отсутствие этапов зависит от вакансии): 1. Знакомство - вы рассказываете о формате встречи - кандидат описывает свой прошлый опыт и свои навыки. 2. Вопросы на базу теории тестирования. 3. Технический блок - специфика тестирования: web/mobile/backend/desktop - автоматизация тестирования 4. Практический блок - задачи на теорию тестирования (тест-дизайн, локализация и прочее) - ситуационные вопросы - лайв-кодинг 5. Вопросы от кандидата Для собседования обязательно нужно подготовиться (даже когда ты собеседующий!): - выстроить процесс (например, построить матрицу компетенций, что вы хотите от кандидата) - определиться с вопросами - подготовиться к роли собеседующего Поговорим о каждом поподробнее Выстраивание процесса Для построения хорошего процесса я бы изучила следующий материал - Лучший дизайн процесса собеседований: объясняет, почему сейчас мы часто строим собеседования неправильно, как лучше выстраивать вопросы, как в этом поможет матрица компетенций и еще куча всего. По мне одно из лучших чтений на эту тему. - Теория по собеседованиям: какие виды существуют, как подготавливаться, какие вопросы лучше задавать и все в этом направлении. - Видео “Как проводить собеседования, чтобы было интересно кандидату и не обидно HR”: очень нравится подход, описание и общие шаги. - Изучить чужой опыт, например, как проходит интервью в Тинькофф О вопросах и подготовки себя поговорим в следующей части 🔜

как понять, что я норм? с этим вопросом ко мне регулярно приходят лиды на консультации, или же он всплывает в рамках совершенно других запросов. причины вопроса более, чем понятны: к лиду очень редко приходят с нормальным фидбеком, задачи придумывать себе приходится самостоятельно, никаких тебе понятных карьерных треков и матриц для самовалидации. прекрасная почва для переработок и выгорания, как будто у лида её не хватает. а что делать-то (особенно пока я не беру на менторинг хехе)? учиться авторизовывать результаты работы (и вообще замечать свою работу), формулировать свою ценность и собирать непрямой фидбек. для начала всегда даю упражнение записывать то, что ты делаешь в течение недели-двух, при чём записывать каждый чатик, каждый митинг. стараться анализировать, какой получился результат из этого действия. например, вместо "отвечала на вопросы по онбордингу" — "разблокировала прохождение онбординга, помогла разобраться с вопросами Х, У". или не "сидела на очередном планинге", а "задала вопросы по фичам в след спринт, нашла гэпы в требованиях, получила информацию для планирования работы команды". ну и не игнорируйте свою работу головой. работа лида во многом — это обдумывание вопросов и принятие решений. отрывайте оценку своей эффективности от работы руками и производимых артефактов. об остальном поговорим завтра в 18 по мск на вебинаре. а в целом подход "с тобой всё норм" будет активно использоваться на курсе :)

Сейчас я работаю full-stack QA в продуктовой команде и автоматизирую на Java. Но в будущем я мечтаю стать ✨лидом✨ . На данный момент мне не полностью понятно, из чего состоит работа, как давать фидбек, оценивать качество своей работы и еще миллион вопросов, на которые я не знала, где найти ответы. А теперь знаю. Потому что Наталья Петровская (великолепная специалистка, с которой мне повезло работать в качестве менти) создала свой курс про лидство. Подробнее про него и бесплатный вебинар в посте ниже ❤️.

Пример задачи на локализацию с собеседования👩‍🎓 На собеседованиях могу дать задачу на локализацию. Приведу пример и решения для одной из таких задач:

Есть форма входа, которая состоит из логина и пароля. Ты вводишь корректные значения, нажимаешь на кнопку войти и ничего не происходит. Какие действия ты предпримешь?

Остановись и подумай: что ты бы ответил собеседующему, какие бы действия совершил и что вообще следует сделать? Идеально, если ты выпишешь свои действия на листочке. Мой список действий можно почитать в посте