testengineer.ru

Домой Обучение Автоматизированное тестирование Что можно ✔️ и чего нельзя ❌ делать на собеседовании по тестированию

Что можно ✔️ и чего нельзя ❌ делать на собеседовании по тестированию

Автор

Дата

Категория

“Каждый из нас попал на работу после успешного собеседования. Конечно, успешными были не все попытки. Здесь попробую подытожить свой собственный опыт: как со стороны собеседуемого, так и со стороны собеседующего.

✔️ Что делать

Думать о влиянии на прибыль компании, а не только о рабочих задачах

Старайся думать о своих рабочих обязанностях в контексте того, как они влияют на прибыль компании, в которую ты нанимаешься. 

Если когда-то пришлось написать 1000 автотестов, но они, в основном, не очень, и на эти тесты смотрели с раздражением  — это не успех, а, скорее, потеря оплаченного работодателем времени.

Если написал три автотеста, интегрировал их в build-pipeline, и команда получила первый фидбек через полчаса после деплоя — ты будешь выглядеть выгоднее.

Если на прошлой работе тебе удалось чуть-чуть улучшить то, что называется “quality culture”; внедрить в своем отделе тестирование нового, полезного типа; или быстро исправить чей-то код — возле твоей фамилии нарисуется зеленая галочка.

Пиши свое резюме именно в таком стиле — сосредоточься на том, как твое участие в компании выглядит с точки зрения ее руководства, которое думает о выгоде.

Всегда спрашивай о текущем состоянии проекта в компании, в которую собираешься трудоустроиться. Спрашивай, в каком состоянии автоматизация, и какие планы на будущее?

Это поможет сразу понять, в каком состоянии проект. Если процессы хорошо организованы, и основа написана, то тебе придется лишь добавлять что-то по мелочи и далее поддерживать существующие тесты, что проще. Если ты идешь на абсолютно новый проект — тогда все процессы и инструменты придется интегрировать, или даже где-то создавать с нуля.

Если есть некий словесный концепт будущего фреймворка автоматизации — стОит спросить о выборе технологий, чтобы понять, насколько широка свобода выбора.

Лучше знать все о проекте до того, как к него войдешь. И если человек интересуется, это оставляет хорошее впечатление.

Будь готов к вопросу “Приходилось ли более-менее самостоятельно имплементировать решение по автоматизации/пайплайн/процесс?”

Здесь лучше не врать. Если во всем помогали devops-ы или разработчики — просто скажи это.

Кандидат не может претендовать на приличную должность, если он всего лишь исправлял уже написанные кем-то несложные тесты, или добавлял новые простейшие тесты в существующем фреймворке, даже если он делал это 3-4-5 лет подряд.

Могут задать вопросы “А зачем ты сделал то-то, и сделал именно таким образом? А был способ проще и быстрее?”

Однажды пришлось собеседовать кандидата и я спросил его о тестировании игры, в разработке которой он участвовал. Он ответил мне: “да мы просто создавали билд, устанавливали его и играли”. Это может быть нормальный ответ для новичка, но никак не для “инженера программного обеспечения”, с 10 годами опыта, о чем было указано в его резюме.

Попроси фидбек после собеседования

Это поможет понять, где тебе нужно подтянуться.

За время моей практики в качестве интервьюера, лишь несколько человек попросили фидбек. Примечательно, что все они были приняты к нам позже, и я заметил что они развивались в профессиональном плане гораздо быстрее других тестировщиков.

Всегда читай то, что называется “профиль компании” и готовься к интервью, учитывая этот профиль

Я когда-то провалил собеседование из-за того, что почти не готовился к сложным вопросам по автоматизации UI-тестирования. А это была компания, основным продуктом которой были веб-сайты и веб-технологии, завязанные на интерфейс.

Покажи интервьюерам свои “поделки” на собеседовании

Чтобы было что показать, хотя бы иногда заходи на Gitgub и оставляй там свое творчество, и хотя бы иногда участвуй в “народных” и хайповых опенсорсных проектах.

Это самый правильный способ создать портфолио. Не стесняйся показать свои проекты и решения, даже если они кажутся “слишком простыми” для серьезной компании. Ты всегда сможешь “допилить” их позже, когда станешь более опытным.

Чего лучше не делать

Не надо загружать весь код тестового фреймворка на Github

Вместе со всеми логинами, паролями, и деталями инфраструктуры, только чтобы показать ее интервьюеру.

Если во время дистанционного собеседования очень плохая связь, лучше сразу сказать это

Сюжет из моего опыта: собеседование с демонстрацией экрана, а скорость интернета была очень низкой. Пришлось много раз повторять “Что вы сказали?”, и интервьюер решил что у меня плохо с английским, и отправил отказ, с соответствующим фидбеком.

Не говори интервьюеру: “Я не особо вникал как работает этот код — просто скопировал его с StackOverflow, он же хорошо работает”

Конечно, все мы делаем это время от времени, а с другой стороны, если делать так слишком часто и еще бравировать этим, то интервьюер может решить, что ты не любишь вникать в детали.

Вовсе не обязательно перечислять в своем послужном списке абсолютно все ИТ-технологии, с которыми ты соприкасался хотя бы в малейшей степени

Все, что ты укажешь в своем CV, могут спрашивать на собеседовании. То, что ты написал на Ruby тест из разряда “Открыть браузер и запустить поиск в Гугле”, не должно подразумевать, что ты идеально знаешь Ruby. Твой “Список технологий” не может быть бесконечен.

Не выходи на видео-собеседование в неудобный для себя момент

Например, если не очень опрятно одет или простужен. Не выключай камеру в неожиданный момент.

Не говори на собеседовании, что все, абсолютно все, должно быть автоматизировано через UI-end-to-end-тестирование

Знай о других типах и уровнях тестирования и автоматизации, и показывай это.

Не перехваливай какой-то один фреймворк “Sе” или инструмент “Q”, говоря что это самый-самый лучший выбор для всякой возможной задачи в любом проекте

Инструменты бывают под разные задачи, технологии тоже — будь отрыт к новым инструментам и технологиям. Об инструментах для автоматизированного тестирования мы написали отдельную статью.

Не говори, что ревью кода, касается только разработчиков

И что ты не любишь этим заниматься. Воспринимай код в автоматизации как продакшен-код, что касается его ясности и качества.

Удачи на собеседованиях!

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь

$1100*
медианная зарплата в QA в ноябре

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Последние комментарии