- Разберитесь в условии задачи
- Подготовьте тестовые данные
- Притормозите и обдумайте
- Просите подсказку
- Начинайте с брутфорса
- Пишите псевдокод
- Пишите чистый код
- Сделайте дебаг
- Запустите код
- Просите фидбэк
Допустим, вы хотите стать высокооплачиваемым SDET (Software Development Engineer in Test). С чего начать? Начните с решения 100-150 задач по алгоритмам и структурам данных на Leetcode. Создавайте брутфорс-решение, а затем оптимизируйте его. Это что касается учебы и подготовки к собеседованию.
Имейте в виду, что большинство интервьюеров обращают внимание не столько на сами решения, сколько на ваши подходы к их поиску.
В этой статье мы дадим вам десять советов, которые помогут вам куда лучше подготовиться к техническим QA-интервью.
1. Разберитесь в условии задачи
Большинство людей очень нервничают на технических собеседованиях. А из-за этого недостаточно внимательно читают вопрос или условие задачи.
Если вы не до конца поняли, что от вас требуется, не стесняйтесь переспросить и уточнить.
Вот несколько вопросов, которые можно задать как себе самому (для самопроверки), так и интервьюеру:
- Какими могут быть входящие данные?
- Данные какого типа нужно получить на выходе?
- Есть ли какие-то ограничения при решении этой задачи?
- Насколько большим должен быть тестовый набор данных?
Дополнительный совет. Вопросы нужно задавать правильно. Формулируйте их в стиле «а если…» и сразу оговаривайте граничные случаи. Это поможет лучше спроектировать тесты.
2. Подготовьте тестовые данные
Пора показать ваши навыки тестировщика. Большинство интервьюеров попросят вас создать как минимум три тестовых набора данных (для позитивных и негативных тестов и граничных случаев). Эти тестовые данные могут использоваться для юнит-тестов и для разработки на основе тестирования (TDD).
Дополнительный совет. Когда закончите работу над датасетами, уточните у интервьюера, соответствуют ли они его ожиданиям.
3. Притормозите на минутку и обдумайте возможные варианты решения
Если вы решили достаточно задач на Leetcode, скорее всего вам уже встречалась похожая задача. Но не надо это показывать интервьюерам, иначе получите другой вопрос. Лучше выделите себе несколько минут на обдумывание решения с учетом ваших данных и ограничений.
Дополнительный совет. Важно постоянно коммуницировать с интервьюером. Особенно это касается онлайн-собеседований. Коммуницировать нужно даже при обдумывании решения!
4. Попросите подсказку
Что, если вам так и не удалось придумать решение? Наберитесь наглости и попросите интервьюера помочь вам или подсказать что-нибудь. Чаще всего это срабатывает, поскольку многие интервьюеры искренне желают вам успеха.
Дополнительный совет. Не забудьте поблагодарить за помощь. Покажите, что вы умеете общаться с людьми и быть вежливым.
5. Всегда начинайте с брутфорс-решения
Даже если вы знаете несколько оптимизированных решений, рекомендуется все равно начинать с брутфорс-подхода. Исключение — если интервьюер прямо определил какие-то требования. Если у вас есть ограничение по времени, тогда хотя бы упомяните брутфорс-решение и его сложность.
Дополнительный совет. Очень важно проговаривать сложность и ресурсы, необходимые для того или иного решения.
6. Сперва напишите псевдокод
Лайв-кодинг сессии на собеседованиях длятся примерно 45-60 минут. Обычно вы получаете 1-2 задачи, к которым могут прилагаться дополнительные вопросы по автоматизации во фронтенде и бэкенде, agile и т. п. В среднем на каждое задание отводится 15-20 минут.
Работая над сложной задачей, будет хорошей идеей сперва написать псевдокод решения. Это поможет вам не потеряться и сложить в голове четкий план.
Дополнительный совет. Прежде чем приступить к написанию настоящего кода, покажите ваш псевдокод интервьюеру. Во-первых — чтобы убедиться, что вы на правильном пути. Во-вторых — интервьюер может что-нибудь посоветовать.
7. Пишите чистый код
Когда пишете код решения, придерживайтесь рекомендаций по написанию чистого кода.
Имена переменных и функций должны соответствовать общепринятым соглашениям о нейминге. Оставляйте короткие и осмысленные комментарии. Используйте подходящие встроенные методы.
Правда, что касается встроенных методов, лучше уточнить у интервьюера, можно ли вам их использовать, потому что многие возражают.
Дополнительный совет. Практикуйтесь писать код в простом текстовом редакторе. Многие интервьюеры используют для собеседований платформы для шеринга кода, а там не всегда есть функции автодополнения.
8. Сделайте дебаг своего кода с тестовыми данными
Как тестировщик вы можете тяготеть к запуску тестов, а не к отладке. Но это может быть большой ошибкой.
Лучше начать с дебага каждой строчки кода, а затем показать код интервьюеру. Не забывайте проговаривать вслух сложность каждого своего решения (О-нотация).
Дополнительный совет. Спросите интервьюера, не хочет ли он запустить тесты на каких-то особых тестовых данных. Часто бывает так, что ваше решение для интервьюера новое, и ему может быть интересно посмотреть, будет ли ваш код работать с его тестовыми данными.
9. Запустите код со всеми тестовыми данными
Если все предыдущие этапы прошли хорошо, сделайте глубокий вдох и запустите свой код со всеми вашими наборами тестовых данных. Если что-то работает не так, займитесь отладкой (с разрешения интервьюера).
Дополнительный совет. Когда пишете юнит-тесты, внимательно следите за проверками, которые сравнивают ожидаемые и фактические результаты.Это сэкономит время на отладку.
10. Попросите фидбэк
Ура, мы дошли до финала! Пора попросить интервьюера дать вам фидбэк по вашему техническому собеседованию. Непременно делайте пометки. Если вам посоветуют что-то улучшить, скажите, что займетесь этим прямо сегодня.
Удачи на собеседовании!
