Comments 30
Сам себе и напишу комментарий. Какая классная статья, молодец автор.
Кармы у меня нет, Жека. Держи комменатрий - вот это статья! Мое почтение!!
Да, определённо нужно начинать с решения простых задач, но главное на них не засиживаться.
Я тоже QA и помню свое первое лайв кодинг интервью, перед которым я нарешал кучу простых задач и задач средней сложности, где каждая из задач была на "отдельную тематику" - а-ля перевороты строк, подсчёты гласных и тп, а на интервью мне попалась комплексная задача, где нужно было сначала распарить API ответ и дальше пройти ещё шагов 10, решая маленькие задачи по преобразованию данного ответа и извлечению данных из него. И я откровенно поплыл, не ожидая такой задачи.
А в наши дни мне нравится решать задачи с LLM: задаешь промпт С тематикой задачи, в котором просишь оценить правильность решения и затем показать оптимальное решение. И таким образом образом очень удобно решать задачи по темам, которые тебе интересны сегодня или сразу комплексные задачи. И особенно полезно видеть, как порой далеко мои решения от оптимальных.
Я кстати не уверен, что в тренажерах вообще задачи есть по принципу «распарси ответ от API». Могут попросить пройтись по структуре словаря и что-то с ним сделать. Но задачи буквально взаимодействие с API могут что угодно в себя включать: клиент написать, обработать варианты ответа, покрыть тестами, ретраер сделать с экпоненциальным бэк-оффом, датаклассы показать, какие использовать умеешь. Короче тут оч зависит от фантазии и садизма интервьюера :) Хотя может и вакансия этого требует.
Для подготовки к собесу я ЛЛМ использовал в таком же, как ты ключе один раз, но для другого кейса. Там конкретно на собесе была анонсирована задача «сделай код ревью». Вот для этой темы ЛЛМ попросить написать функцию с парой-тройкой багов и стилистических косяков, а потом пройтись с код-ревью и послушать ее фидбэк – мне очень понравилось, руку набил.
Действительно отличная статья и, что важно, актуальная относительно рынка QA. К сожалению многие коллеги по цеху до сих пор живут реалиями 2018 года, когда для QA было достаточно уметь читать и писать.
Последние пару лет "традиционное" QA все больше смещается в сторону SDET. Особенно с появлением LLM, возможности встраивать плагины в IDE и, соответственно, быстро накидывать не только АТ, но и простые QA инструменты.
Так что статья крутая - помогает трезво взглянуть коллегам на реалии рынка QA.
Если в ЛЛМ задать вопрос, «как выйти на западный рынок QA», в ответ будет два ключевых тезиса, помимо языкового барьера и разрешения на работу:
1. Требуется SDET-скиллсет
2. Нужен пет-проект с демонстрацией разных видов тестов.
У нас очень развитый рынок айти, но мы отстаем по внедрению ИИ в процессы. То, как это работает на западе нас рано или поздно догонит и нужно заранее готовиться уже сегодня. Наш рынок будет похожим.
Тут надо отметить, что запад, западу рознь, говорю, как человек, работающий на западе 😁
делись, что у вас спрашивают)
Из последнего, в 2025 искал (и нашёл) работу на рынке Германии, если вкратце (вкратце, потому что рассказывать можно долго планирую запилить пост на эту тему тут 😁).
Интервью 3-4 этапа, по тех части в основном были задания на дом по автоматизации (но и лайв кодинги тоже, но реже), а затем след. этап тех собес.
Тех собесы прямо очень разные, все зависело от уровня собеседующего. Были, как приколы, где собесил явно джун и вопросы были: что такое тестирование черного/белого ящика, верификация /валидация 🤣. Были собесы, где вопросы с упором на понимание процессов тестирования. Были такие, где я рассказывал о своём опыте и исходя из моего рассказа, мне задавали уточняющие или ситуационные вопросы.
Кстати, QA-инструменты с помощью ЛЛМ вообще отдельная тема для статьи.
Господь, тут нельзя стереть комменты мимо треда :)
А qa-щикам то нахрена олимпиадные задачи?
Было бы полезно дать еще п.22 ответ на вопрос "А кроме как пройти собес еще где-то алгосы нужны?". Ведь это же один из тех вопросов, которые задают люди, которые не понимают помешанности компаний на ало-секций. И ведь действительно, в production коде мы же не пишем алгосы. Применяем стандартные подходы. Немного, конечно, задумавшись какие структуры данных и Big O под капотом лежит.
Хороший вопрос. Может тема для поста.
Компании можно понять. Языков программирования масса, фреймворков со своими приколами для каждого языка тоже куча. Как в таких условиях проверить технический уровень кандидата? 2ГИС например пишет авто-тесты на фрейм-ворке Vedro. Предположим, они будут требовать на собесе писать на нем. Какой процент кандидатов они отсекут? Я с ведром раньше не работал. А если он только на Java, а я знаю питон?
Вместо этого компаниям гораздо проще найти кандидатов, если для них взять единую договоренность, которая вне зависимости от ЯП или фреймворка покажет технический уровень кандидата. Не просто так алгоритмы это де-факто стандарт, люди тоже не дураки.
Да и не сказать, что прям вот алгоритмы ничего не показывают в технических навыках сотрудника. Попутно же виден его ход мысли, код-стиль, работа с документацией, тестами, насмотренность. Можно комментировать, что пишешь, показывая харды и софты.
Ну и, наконец, алгоритмы в работе QA может и мало где нужны. Но у разработчиков вполне могут быть задачи на обработку данных, в которых нужно доработать логику сортировки данных, поиска данных, парсинга строк и тд. Для базы вполне сгодятся алгоритмы.
Категорически отказываюсь от собесов с лайвкодингом, потому что… после 20 лет разработки, написание кода стало процессом интимным и перед кем попало код не пишу. А вот парное программирование (с сотрудником нанимателя) вполне себе, только почему-то все отказываются. Хотя я в основном работаю с имеющимися клиентами или нахожу уютные проекты без этой корпоративной фигни, поэтому пока могу избегать лайвкодинг, так как собеседуюсь редко.
Хорошая статья, мне понравилась
Спасибо за статью. Мне о на лично показалась полезной. Закинул +1 в карму и +1 в рейтинг. Таких статей на подобную тему раньше не встречал на Хабре. В любом случае видно, что автор старался, вкладывал душу в сое детище. Это всегда похвально. Понимаю это не по наслышке. Успехов!
Прекрасная статья, огромное спасибо! Особенно запомнился пункт об отладчике — обязательно начну активно его использовать. И в целом, материал вдохновляет на активные действия.
Отличная статья, спасибо автору!
Как готовиться к cобеседованию с лайв-кодингом QA