“Каждый из нас попал на работу после успешного собеседования. Конечно, успешными были не все попытки. Здесь попробую подытожить свой собственный опыт: как со стороны собеседуемого, так и со стороны собеседующего.
✔️ Что делать
Думать о влиянии на прибыль компании, а не только о рабочих задачах
Старайся думать о своих рабочих обязанностях в контексте того, как они влияют на прибыль компании, в которую ты нанимаешься.
Если когда-то пришлось написать 1000 автотестов, но они, в основном, не очень, и на эти тесты смотрели с раздражением — это не успех, а, скорее, потеря оплаченного работодателем времени.
Если написал три автотеста, интегрировал их в build-pipeline, и команда получила первый фидбек через полчаса после деплоя — ты будешь выглядеть выгоднее.
Если на прошлой работе тебе удалось чуть-чуть улучшить то, что называется “quality culture”; внедрить в своем отделе тестирование нового, полезного типа; или быстро исправить чей-то код — возле твоей фамилии нарисуется зеленая галочка.
Пиши свое резюме именно в таком стиле — сосредоточься на том, как твое участие в компании выглядит с точки зрения ее руководства, которое думает о выгоде.
Всегда спрашивай о текущем состоянии проекта в компании, в которую собираешься трудоустроиться. Спрашивай, в каком состоянии автоматизация, и какие планы на будущее?
Это поможет сразу понять, в каком состоянии проект. Если процессы хорошо организованы, и основа написана, то тебе придется лишь добавлять что-то по мелочи и далее поддерживать существующие тесты, что проще. Если ты идешь на абсолютно новый проект — тогда все процессы и инструменты придется интегрировать, или даже где-то создавать с нуля.
Если есть некий словесный концепт будущего фреймворка автоматизации — стОит спросить о выборе технологий, чтобы понять, насколько широка свобода выбора.
Лучше знать все о проекте до того, как к него войдешь. И если человек интересуется, это оставляет хорошее впечатление.
Будь готов к вопросу “Приходилось ли более-менее самостоятельно имплементировать решение по автоматизации/пайплайн/процесс?”
Здесь лучше не врать. Если во всем помогали devops-ы или разработчики — просто скажи это.
Кандидат не может претендовать на приличную должность, если он всего лишь исправлял уже написанные кем-то несложные тесты, или добавлял новые простейшие тесты в существующем фреймворке, даже если он делал это 3-4-5 лет подряд.
Могут задать вопросы “А зачем ты сделал то-то, и сделал именно таким образом? А был способ проще и быстрее?”
Однажды пришлось собеседовать кандидата и я спросил его о тестировании игры, в разработке которой он участвовал. Он ответил мне: “да мы просто создавали билд, устанавливали его и играли”. Это может быть нормальный ответ для новичка, но никак не для “инженера программного обеспечения”, с 10 годами опыта, о чем было указано в его резюме.
Попроси фидбек после собеседования
Это поможет понять, где тебе нужно подтянуться.
За время моей практики в качестве интервьюера, лишь несколько человек попросили фидбек. Примечательно, что все они были приняты к нам позже, и я заметил что они развивались в профессиональном плане гораздо быстрее других тестировщиков.
Всегда читай то, что называется “профиль компании” и готовься к интервью, учитывая этот профиль
Я когда-то провалил собеседование из-за того, что почти не готовился к сложным вопросам по автоматизации UI-тестирования. А это была компания, основным продуктом которой были веб-сайты и веб-технологии, завязанные на интерфейс.
Покажи интервьюерам свои “поделки” на собеседовании
Чтобы было что показать, хотя бы иногда заходи на GitHub и оставляй там свое творчество, и хотя бы иногда участвуй в “народных” и хайповых опенсорсных проектах.
Это самый правильный способ создать портфолио. Не стесняйся показать свои проекты и решения, даже если они кажутся “слишком простыми” для серьезной компании. Ты всегда сможешь “допилить” их позже, когда станешь более опытным.
❌ Чего лучше не делать
Не надо загружать весь код тестового фреймворка на Github
Вместе со всеми логинами, паролями, и деталями инфраструктуры, только чтобы показать ее интервьюеру.
Если во время дистанционного собеседования очень плохая связь, лучше сразу сказать это
Сюжет из моего опыта: собеседование с демонстрацией экрана, а скорость интернета была очень низкой. Пришлось много раз повторять “Что вы сказали?”, и интервьюер решил что у меня плохо с английским, и отправил отказ, с соответствующим фидбеком.
Не говори интервьюеру: “Я не особо вникал как работает этот код — просто скопировал его со StackOverflow, он же хорошо работает”
Конечно, все мы делаем это время от времени, а с другой стороны, если делать так слишком часто и еще бравировать этим, то интервьюер может решить, что ты не любишь вникать в детали.
Вовсе не обязательно перечислять в своем послужном списке абсолютно все ИТ-технологии, с которыми ты соприкасался хотя бы в малейшей степени
Все, что ты укажешь в своем CV, могут спрашивать на собеседовании. То, что ты написал на Ruby тест из разряда “Открыть браузер и запустить поиск в Гугле”, не должно подразумевать, что ты идеально знаешь Ruby. Твой “Список технологий” не может быть бесконечен.
Не выходи на видео-собеседование в неудобный для себя момент
Например, если не очень опрятно одет или простужен. И не выключай камеру в неожиданный момент.
Не говори на собеседовании, что все, абсолютно все, должно быть автоматизировано через UI-end-to-end-тестирование
Знай о других типах и уровнях тестирования и автоматизации, и показывай это.
Не перехваливай какой-то один фреймворк “Sе” или инструмент “Q”, говоря что это самый-самый лучший выбор для всякой возможной задачи в любом проекте
Инструменты бывают под разные задачи, технологии тоже — будь отрыт к новым инструментам и технологиям. Об инструментах для автоматизированного тестирования мы написали отдельную статью.
Не говори, что ревью кода касается только разработчиков
И подчеркивать, что ты не любишь этим заниматься. Воспринимай код в автоматизации как продакшен-код, что касается его ясности и качества.
Удачи на собеседованиях!
