Семь раз оттесть, один раз деплой
За пару-тройку месяцев пристрастился к публикациям на Хабр.
И, чтобы это не превращать эту новую привычку в пустое графоманство, решил сфокусироваться и прикинуть в этом посте темы для следующих публикаций:
Как судить песни на онлайн-турнирах в числах?
Функция Cover в Suno для возведения нашего творчества в степень
Типовые баги в русской фонетике относительно песнен из Suno
Публикуем музыкальный альбом через сервис дистрибьютора
Что почитать начинающим тестировщикам: 6 материалов для погружения в тестирование
Привет, Хабр! Мы приготовили подборку, которая поможет глубже погрузиться в тестирование. Внутри — обзоры профессиональной литературы, популярных инструментов и библиотек, а также советы от команды Selectel. Бонус — бесплатный курс по мобильному тестированию от опытных тестировщиков.
Тестирование мобильных приложений
→ Топ-8 эмуляторов Android на ПК
Android-эмуляторов — десятки. Чтобы вам было проще выбрать, мы сравнили восемь популярных решений. Разобрали особенности каждого и объяснили, для каких задач они подходят.
→ Какие особенности важно учитывать при тестировании мобильных приложений
Мобильное тестирование — это не просто «веб в миниатюре», а отдельный мир со своей архитектурой, устройствами, операционными системами и ограничениями. В статье рассказали об особенностях мобильных платформ, с которыми тестировщики сталкиваются на практике.
→ Курс: тестирование мобильных приложений
Бесплатный курс от экспертов Selectel, Ozon, Спортс" и не только. Он подходит как новичкам, так и практикующим тестировщикам, которые хотят систематизировать знания. На начало марта доступна первая часть курса, но совсем скоро появится и вторая.
Тестирование веб-приложений
→ Стартовый набор тестировщика: инструменты, библиотеки и ресурсы
Тестирование — кропотливый труд, особенно для начинающих специалистов. Но задачу можно упростить, если прокачать знания и внедрить подходящие инструменты.
→ Полезные ресурсы для погружения в тестирование
Мало стартового набора? Держите дополнительную порцию интерактивных тренажеров, баз знаний, книг и курсов — проверенных ресурсов, к которым можно возвращаться в любой момент.
→ От макетов до кода: как AI-прототипы упростили жизнь разработчикам и тестировщикам
Если вы устали от бесконечных циклов «получить приложение → найти баг → отправить на доработку → повторить», предложите команде AI-инструменты для прототипирования. В статье рассказали, как мы используем этот подход.
44 собеса за месяца — Жив ли рынок QA/AQA на самом деле?
Последний год в IT регулярно обсуждают одну и ту же тему — рынок стал сложнее.
Вакансий меньше, требования выросли, конкуренция усилилась.
Особенно часто это можно услышать от специалистов из QA/AQA:
Мол, тестирование переполнено, вакансий мало, а найти новую работу стало почти нереально.
Я давно консультирую ребят в сфере QA и автоматизации тестирования (AQA) и регулярно наблюдаю, как специалисты выходят на рынок. Поэтому иногда вижу довольно наглядные примеры того, как ситуация выглядит на практике.
Как раз недавно один из ребят показал в нашем чатике свой календарь собеседований за декабрь — этот календарь приложил выше.
И, честно говоря, даже меня это немного удивило. За месяц у него набралось 44 собеседования.
Причём:
Во-первых, всё это происходило параллельно с основной работой.
Человек не уходил в отпуск и не ставил поиск работы на полный день — все интервью проходили между рабочими задачами.
Во-вторых, это был декабрь.
Если смотреть на рынок найма в IT, конец года традиционно считается не самым активным периодом: компании закрывают бюджеты, команды уходят в отпуска, процессы замедляются.
Тем не менее календарь получился очень плотным.
Иногда у него было по несколько интервью в день:
HR, технички, финалки, снова HR.
А если представить его лицо 11го декабря — то лучше не надо)
P.S. Выходил на рынок он как Fullstack QA/AQA, если что. В ручном тестировании естественно ситуация похуже. Но наверное основной моей задачей и являлось помочь ему с этим переходом (QA->AQA), т.к. именно тут наилучшая конверсия для QA.
И что по итогу? Оправдались ли такие усилия?
Думаю, всем это тоже будет интересно. Стоило ли оно вообще того.
Вы реально думаете, что человек, который проходил по 6 собесов в день, мог не добиться своего?)
Всё-таки в подобной ситуации очень быстро прокачиваются навыки интервью. С каждым новым собеседованием ответы становятся точнее, технические вопросы разбираются быстрее, а уверенность растёт.
В итоге этот кандидат получил 6 офферов.
Один из них оказался особенно сильным — около 490 000 рублей gross для позиции в автоматизации тестирования.
На мой взгляд, это хороший пример того, как сейчас устроен рынок.
Да, он действительно стал сложнее.
Да, требования выросли.
Но при этом рынок далеко не мёртв. Он просто стал требовательнее к кандидатам.
Те, кто активно выходят на рынок, много собеседуются, анализируют обратную связь и продолжают двигаться дальше — как правило, всё равно получают результат.
А те, кто не пытается, чаще находят объяснение, почему сейчас «не время».
Поэтому, когда в очередной раз услышите, что рынок QA/AQA окончательно умер, просто вспомните календарь из 44 собеседований за один месяц.
Спасибо, что дочитали пост до конца! Надеюсь, смог зарядить вас мотивацией, это была моя основная цель 🙂
В комментариях готов подискутировать на эту и смежные темы! Ну а в своем блоге Telegram также пишу про тестирование и автоматизацию, иногда затрагивая и общие темы развития в сфере IT. Всегда рад новым читателям!)
Уничтожаем враньё в ответах СhatGPT. Представлен промпт для нейронки, чтобы она перестала врать, придумывать, мудрить, выбрасывать несуществующие факты и цитаты, а также галлюцинировать. В промпте учтено всё, что должна делать нейронка, и что не должна исполнять во время работы. Нужно перейти в «Настройки» → «Пользовательские инструкции» и добавить туда этот текст:
СЛЕДУЙ ЭТОМУ СТИЛЮ ПИСЬМА:
ДОЛЖЕН всегда говорить правду. Никогда не выдумывать информацию, не строить предположения и не гадать.
ДОЛЖЕН основывать все утверждения на проверяемых, фактических и актуальных источниках.
ДОЛЖЕН чётко указывать источник для каждого утверждения прозрачным способом, без расплывчатых ссылок.
ДОЛЖЕН прямо сказать «Я не могу это подтвердить», если что-то нельзя верифицировать.
ДОЛЖЕН ставить точность выше скорости. При необходимости предпринимать шаги для проверки перед ответом.
ДОЛЖЕН сохранять объективность. Убирать личные предвзятости, допущения и мнения — если только они не запрошены явно и не помечены как мнение.
ДОЛЖЕН давать интерпретации только тогда, когда они подтверждаются надёжными, авторитетными источниками.
ДОЛЖЕН объяснять ход рассуждений пошагово, когда точность ответа может быть поставлена под сомнение.
ДОЛЖЕН показывать, как была получена любая числовая величина (как рассчитана или из какого источника взята).
ДОЛЖЕН излагать информацию ясно, чтобы пользователь мог проверить её самостоятельно.
ТЫ ОБЯЗАН ИЗБЕГАТЬ:
ИЗБЕГАЙ фабрикации фактов, цитат или данных.
ИЗБЕГАЙ использования устаревших или ненадёжных источников.
ИЗБЕГАЙ отсутствия деталей об источнике для любого утверждения.
ИЗБЕГАЙ подачи предположений, слухов или догадок как фактов.
ИЗБЕГАЙ «ИИ-ссылок», которые не ведут на реальный, проверяемый контент.
ИЗБЕГАЙ ответа при неуверенности, не обозначив эту неуверенность.
ФИНАЛЬНЫЙ СТРАХОВОЧНЫЙ ШАГ (ПЕРЕД ОТВЕТОМ):
«Каждое ли утверждение в моем ответе проверяемо подкреплено реальными и авторитетными источниками, и снабжено прозрачными ссылками? Если нет — перепиши ответ, пока это не будет выполнено».
Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA
В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.
Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум:
1. ВАСЯ: ВК, Альфа, Сбер, Яндекс
2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа
3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс
В целом есть множество различных вариаций и аббревиатур, но нет одной единственно правильной. Почему - везде есть свои проблемы и преимущества. Всё в большей степени зависит от проекта. Внутри одной и той же компании может быть и круто, и очень плохо.
Поэтому и нет четкого списка "топ компаний", все оценивают по разным критериям.
Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?
Чего стоит попасть туда (насколько это сложно)
У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.
Если говорить про автоматизацию тестирования и смежные роли, картина выглядит иначе. Я скажу больше, выходя на рынок как AQA - вы с большей долей вероятности попадете именно в бигтех.
Автоматизация сегодня - одна из самых востребованных зон в крупных компаниях. Большой продукт, частые релизы, много интеграций - без автотестов это сложно поддерживать.
Плюс последние годы усилили тренд на оптимизацию затрат.
Ручное тестирование постепенно сокращается, а автоматизация растет. Считается, что один AQA может закрывать задачи нескольких QA.
Поэтому спрос на автоматизаторов в бигтехе стабильно высокий.
И в этом смысле двери туда открыты куда шире, чем кажется со стороны.
Где лучше и стоит ли оно того
Я поработал много где как AQA - Ozon, WB, VK, несколько российских и западных стартапов, бигтех US.
И могу с уверенностью сказать, что тут не угадаешь, везде всё по разному. Например, в одном из криптостартапов я встретил лучшие процессы, что видел в жизни, а в двух из бигтехов - миллион токсиков, невероятную бюрократию и в целом не очень классные процессы.
Поэтому мое личное мнение - умирать ради работы в конкретной компании вообще того не стоит.
Проекты могут быть плохие и хорошие как в бигтехах, так и в мелких компаниях. Да, в бигтехах часто процессы получше, но это далеко не всегда так.
Ну а хороший оффер могут дать и там, и там.
В общем, тут стоит выбирать по сумме условий и не руководствоваться именем компании, т.к. оно часто ничего не значит.
Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.
Что в сухом остатке
При прочих равных условиях кроме записи в резюме работа в бигтехе не дает ровным счетом ничего.
Везде всё по разному и может оказаться так, что в стартапе проект будет в миллион раз лучше по всем параметрам.
Ну а строчку в резюме всегда можно придумать, если так уж хочется.
Всем спасибо за внимание! В комментариях готов подискутировать на эту и смежные темы!
В своем блоге Telegram также пишу про тестирование и автоматизацию, ну и в целом про карьеру в сфере IT. Всегда рад новым читателям!)
Вышел наш новый подкаст #Криптонит_говорит про тестирование! Мы обсудили тренды профессии, поговорили об образовании в этой сфере и узнали, почему разрыв между разработкой и тестированием сокращается (и так будет и дальше).
Смотрите и слушайте выпуск на любой удобной платформе:
· VK Видео
· YouTube
· Rutube
· Я.Музыка
В выпуске приняли участие:
· Александр Гречин, руководитель департамента тестирования в «Криптоните»;
· Алексей Москалев, ведущий инженер по автотестированию, Департамент развития платформы Голосового Антифрода, билайн.
Недавно общался с крупной зарубежной продуктовой компанией. Штат 500–1000 человек, вроде зрелые процессы, ЗП у разрабов 5000€ баг-репорты по ISO/IEC/IEEE 29119. И при этом:
«Не успеваем уделять время автотестам. Сфокусированы на скорости разработки и релизах.»
Что меня зацепило — каждый их аргумент против тестов я интерпретировал как аргумент за:
— «Слишком частые релизы» → А не потому ли они такие частые, что баги проскакивают на прод?
— «Требования постоянно меняются» → Тем более — как вы контролируете, что старое не ломается?
— «И так работают наизнос если еще и тесты заставить писать — выгорят» → А не от бесконечного ли футбола с багами они выгорают?
А как у вас? Есть автотесты на проекте? Или тоже «не до них»?
Я написал целую статью на эту тему, если все выше вам откликается рекомендую к прочтению: Нет времени на тесты — через неделю релиз
Приглашаем тестировщиков на митап. Вместе с Moscow QA подготовили три ярких доклада:
Помогите, flaky!
Екатерина Лахтина, тимлид QA UGC в 2ГИС, поделится подходом, который помогает находить и устранять flaky‑тесты, снижать ручную работу и добавлять автоматизацию.
Как прокачать автотесты с 0 до keyword-driven
Анастасия Нестерова, QA Engineer, расскажет, какие методы пробовали, где спотыкались и как в итоге выстроили процесс на стеке Playwright + TypeScript.
Вайб‑кодинг в тестировании с позиции менеджера
Виктория Дежкина, менеджер направления, поделится плюсами и минусами нового подхода в тестировании: как влияет на команду, какие есть риски и стоит ли вообще пробовать.
Представлен открытый проект AI uBlock Origin Blacklist. Это список для блокировки uBlock Origin сайтов, использующих ИИ в качестве источника контента.
«Во время просмотра веб‑страниц я иногда, довольно часто, натыкаюсь на сайты, текст на которых написан генеративным ИИ. Эти сайты не предоставляют полезной информации, имеют посредственный контент и переполнены рекламой и реферальными ссылками для заработка денег. Поэтому, когда я нахожу такие сайты, я добавляю их сюда. Ключевая идея проста: если бы я хотел, чтобы на мой вопрос ответил ИИ, я бы спросил ИИ. Если я ищу информацию в интернете, это означает, что я хочу получить ответ от человека. У человека есть опыт, мнения, идеи, креативность и много другой информации, которой он, возможно, захочет поделиться с интернетом. У ИИ этого нет. Более того, контент, созданный ИИ, может быть опасным: статьи на сайтах, созданных ИИ, не проверяются никем перед публикацией, поскольку они генерируются массово. ИИ может испытывать галлюцинации», — пояснил автор проекта.
На рынке сейчас царит жуткая путаница между совершенно разными AI-QA-ролями.
Получилось так, что я прошла через все три роли.
Если вы планируете карьерный переход, то вот в чем разница между ними:
1️⃣ QA Engineer с инструментами ИИ
Цель: Эффективность.
Реальность: Вы тестируете традиционный детерминированный продукт. Вы просто используете ChatGPT для генерации тест-кейсов или Cursor/Claude Code для автоматизации. Это «вайб-кодинг» для старых добрых задач.
2️⃣ AI QA Engineer
Цель: Базовая проверка интеграции.
Реальность: Тестирование того, как чат с LLM работает внутри условной CRM-системы. Вы проверяете, вежлив ли бот и не «поехал» ли интерфейс. Вы всё ещё используете ассерты (asserts), просто с небольшим «привкусом» нейросетей.
3️⃣ ML Evaluation Engineer (Инженер по оценке ML-моделей)
Цель: Управление хаосом в недетерминированных моделях.
Реальность: Вы не используете ассерты; вы используете статистические метрики.
Инструменты: Фреймворки для оценки (например, LM Evaluation Harness), модули метрик на Python.
Почему третий вариант — это совсем другое:
Вероятность > Детерминизм: Вы не проверяете, что 
. Вы проверяете, является ли показатель метрики 0.87 приемлемым для вашего конкретного сценария.
Стоимость как метрика: В ML Eval затраты токенов так же важны, как задержка (latency). Если ваш агент «умный», но стоит $2 за запрос — вы провалили тест.
Скорость решает всё: Здесь быстрая 7B-модель может выиграть у медленной 70B. Тестирование производительности здесь не «доп. опция», а база.
КОРОТКО
Традиционный QA = Поиск дефектов.
ML Evaluation = Измерение неопределенности.
Представлен открытый проект Hacking-Tools с набором инструментов, которыми пользуются кибербезопасники и системные администраторы, включая:
Поиск информации: показывает, какие данные о вас и компаниях уже лежат в интернете;
Проверки на уязвимости: находит дыры в сайтах, приложениях и серверах;
Инструменты взлома (для тестов): имитируют атаки, чтобы понять, где всё сломается;
Анализ Wi‑Fi и сетей: проверяют, можно ли перехватить трафик или подключиться без спроса;
Цифровая криминалистика: вытаскивают удалённые файлы, метаданные и следы активности;
Стресс‑тесты: нагружают сайты и сервисы, чтобы проверить нагрузку;
Перехват и анализ трафика: показывают, какие данные гуляют по сети;
Подбор паролей: тестируют, насколько легко взломать слабые комбинации;
Анализ сайтов: ищут скрытые страницы, баги и уязвимый код;
Реверс‑инжиниринг: разбирают программы «по косточкам», чтобы понять, как они работают;
Социальная инженерия: симуляторы фишинга и проверка сотрудников на внимательность.
Русский хакер взломал почту президента Соединенных Штатов Америки Дональда Трампа!
Так могла бы быть озаглавлена статья в каком-нибудь новостном агрегаторе, но, конечно же, это далеко от истины, хотя письма от его имени (с домена POTUS*) я все же могу отправлять. Как такое могло произойти давайте разберем под катом.
Одним из самых распространенных методов обмана людей была и остается рассылка по электронной почте. Еще до индусских колл-центров и служб безопасности банков, в начале нулевых главным средством выманивания денег были африканские e-mail'ы, которые с сожалением сообщали о кончине вашего родственника, но завещавшего вам пару десятков миллионов долларов 🇷🇺.
Со временем, специалисты по ИБ разработали антифишинговые механизмы и ПО, которые блокировали входящую почту по распространенным паттернам, включая подозрительные слова. Именно поэтому, если вы вдруг не знали, фишинговые письма содержат грамматические ошибки - банально чтобы обойти защитные механизмы. Однако сейчас не об этом.
Главными критериями определения легальности письма являются 2 доменные записи: SPF и DMARС (есть еще DKIM, который отвечает за цифровую подпись писем, но о нем как-нибудь в другой раз).
Sender Policy Framework aka SPF — это запись со списком серверов и IP-адресов, с которых разрешается рассылать письма от имени домена. Если письмо пришло с отличного от записанного в SPF айпишника или домена - письмо помечается как подозрительное.
Domain-based Message Authentication, Reporting and Conformance aka DMARC — это политика, которая задаёт сценарий действий с письмами, которые признаны через SPF подозрительными: none - ничего не делать, quarantin - пропускать, но поместить в папку спам, и reject - отклонять.
Соответственно, если у домена в DNS не прописаны SPF и DMARС, то принимаемый mail-сервер не может проверить легальность отправления и не понимает, что с ним делать дальше кроме как пропустить.
Так и случилось в текущем примере: коммерческий домен POTUS.com не имеет соответствующей записи DMARC и любой желающий может отправлять письма от его имени, включая якобы действующего президента 🇺🇸 США.
К счастью, большие почтовые корпорации типа 📧 Google и ❤️ Яндекс, даже при отсутствии или неправильной конфигурации SPF и DMARC, научились отличать фишинг от реального письма. Однако ряд других почтовиков (не будем показывать пальцем) не только пропускают такие письма, но еще и подставляют аватарки (на основе фавиконки с домена), а под письмом пишут, что оно проверено "докторским" антивирусом.
Как же установить, что проверяемый домен подвержен такой атаке? Ранее я пользовался встроенной в Kali утилитой под названием spoofcheck (проверка на спуффинг), но она просто проверяет DNS записи и говорит возможно ли заспуфить проверяемый домен или нет.
Поэтому около года назад я сделал свою утилиту 🧠 HydrAttack PoC eMailSpoofer Module, которая проверяет домен на уязвимость (чекает DNS записи), и если так оно и есть - поднимается майл сервер со всеми необходимыми настройками и отправляется спуффинговое письмо. Особенностью моего ПО является то, что в письмо вложен Excel файл с макросом, который открывает калькулятор.
В общем, за год эксплуатации моя утилита показала свою работоспособность в боевых условиях: и на реальных проектах дала жару, и в рамках Баг Баунти программ от Bi.Zone я также заработал пару тысяч. Поэтому пользуйтесь, но помните, что с большой силой приходит и большая ответственность (с).
🧠 Обязательно поделись с теми, кому это может быть полезно 📱 Телеграм | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал
*President of the United States - Президент Соединенных Штатов
Почему хороший тестировщик — это не тот, кто нашел больше всего багов
В тестировании легко попасть в простую ловушку — начать измерять свою ценность количеством найденных багов. Чем больше тикетов, тем полезнее работа. На первый взгляд логика кажется железной.
На практике все сложнее. И чем опытнее становится тестировщик, тем реже он гордится просто цифрами.
Количество багов ничего не говорит само по себе
Сто найденных дефектов могут означать две совершенно разные вещи:
продукт реально нестабилен;
тестирование началось слишком поздно.
Если баги находятся пачками в самом конце разработки, это не успех, а симптом. Хороший тестировщик старается сделать так, чтобы часть проблем не доходила до баг-трекера вообще.
Сильный тестировщик думает раньше, чем тестирует
Тестирование начинается не с чек-листов и не с автотестов. Оно начинается с вопросов.
что здесь может пойти не так;
где система уже ломалась;
какие изменения самые рискованные.
Человек, который подключается к обсуждению требований и дизайна, часто предотвращает больше дефектов, чем тот, кто просто проверяет готовую фичу.
Баг-репорт — это не обвинение
Новички иногда воспринимают баг как доказательство чьей-то ошибки. Отсюда агрессивные формулировки и желание «поймать» разработчика.
Опытный тестировщик понимает — баг-репорт это способ помочь команде. Хорошее описание проблемы экономит время всем:
понятно, что сломалось;
понятно, как воспроизвести;
понятно, почему это важно.
Чем меньше эмоций и больше контекста — тем лучше работает процесс.
Автотесты — это не самоцель
Автоматизация часто превращается в гонку — у кого больше тестов, у кого выше покрытие. Но цифры сами по себе ничего не гарантируют.
Хороший тестировщик задает другие вопросы:
ловят ли эти тесты реальные проблемы;
можно ли им доверять;
не мешают ли они менять код.
Иногда удаление десятка бесполезных автотестов приносит больше пользы, чем написание сотни новых.
Хороший тестировщик думает о пользователе, а не о сценарии
Чек-листы и тест-кейсы важны, но реальный пользователь почти никогда не действует по ним.
Он кликает не туда, вводит странные данные, прерывает процессы и возвращается позже. Умение выйти за рамки сценариев отличает опытного тестировщика от формального.
Качество — это ответственность всей команды
Одна из самых токсичных идей в тестировании — что за качество отвечает только QA. Это удобно, но не работает.
Сильный тестировщик не берет качество на себя полностью. Он помогает команде видеть риски, объясняет последствия и участвует в решениях. Но ответственность остается общей.
Карьерный рост в тестировании — это не про инструменты
Инструменты меняются быстро. Сегодня один фреймворк, завтра другой. Знание конкретного тулкита редко определяет уровень специалиста.
Гораздо важнее:
умение анализировать систему;
понимание, где искать проблемы;
способность говорить с разработчиками и бизнесом на одном языке.
Именно это делает тестировщика ценным, а не список технологий в резюме.
В итоге
Хороший тестировщик — это не тот, кто нашел больше всего багов. Это тот, кто:
помогает находить проблемы раньше;
думает о рисках, а не о галочках;
пишет понятные баг-репорты;
работает с командой, а не против нее.
Такие люди редко кричат о своих результатах. Но именно благодаря им продукт перестает ломаться в самых неожиданных местах.
Представлен открытый проект PeerWeb — децентрализованного веб‑хостинга на базе WebTorrent. Решение обеспечивает децентрализованный, устойчивый к цензуре веб‑хостинг через пиринговые сети. «Загружайте свои статические веб‑сайты и делитесь ими по всему миру, не полагаясь на централизованные серверы и не оплачивая хостинг», — пояснили авторы решения.
Как оставаться релевантным на рынке QA/AQA/SDET в 2026: опыт, харды, софты, ответы
Последнее время всё чаще слышу вопросы про состояние рынка.
Многие говорят, что рынок «умер», вакансий стало меньше, а требования выросли настолько, что найти работу почти нереально.
Часто это выглядит так: человек активно откликается, ходит на собеседования, делает тестовые задания, общается с рекрутерами.
А на выходе получает либо отказы без конкретных причин, либо формулировки вроде «вы хороший специалист, но нам нужен немного другой профиль».
Ощущение, что стало сложнее, не обманчиво. Рынок действительно изменился за последние один-два года.
Но парадокс в том, что именно в таких условиях многим стало проще выделяться. Не потому, что кандидатов стало меньше, а потому, что вырос разрыв между теми, кто выглядит релевантно, и теми, кто нет.
Я регулярно общаюсь с QA, AQA и SDET, которые находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы понимать, как именно сейчас устроен процесс найма.
И вот что я понял из всех историй: сегодня выигрывает не самый наглый кандидат (как было раньше), а тот, кто хорошо понимает свой опыт и умеет его объяснять.
Что изменилось
Еще один-два года назад часто работала простая схема: уверенное резюме плюс нормальная подача давали высокую вероятность оффера.
Во многих компаниях в детали погружались поверхностно, опыт оценивали в общих чертах, а неточности прощались, если кандидат выглядел уверенно.
Сейчас ситуация другая.
Вакансий в ряде направлений стало меньше, требования выросли, а собеседования стали заметно глубже. Интервьюеры чаще проверяют логику решений и реальный вклад кандидата в проекты.
Это не «заговор рынка», а естественная фильтрация. Когда выбор кандидатов большой, требования становятся строже.
Почему в этом есть плюсы
Жесткий рынок хорошо отсеивает слабые места. Причем чаще всего самые базовые.
На собеседованиях у ребят регулярно всплывают одни и те же проблемы:
человек говорит, что строил фреймворк, но не может связно объяснить архитектуру;
упоминает автотесты, но не понимает, почему был выбран конкретный стек;
рассказывает про CI, но путается в вопросах стабильности;
заявляет ответственность за качество, но не может описать процессы и зоны ответственности.
Большинство кандидатов «падает» не на сложных вопросах, а на уточняющих.
На этом фоне специалист, который осознанно разбирается в своем опыте и может его структурировано рассказать, сразу выглядит сильнее, даже без громких компаний в резюме.
Как сейчас смотрят на опыт
На интервью все меньше внимания уделяется формальным строчкам в резюме и все больше мышлению.
Интервьюеру важно понять:
Почему было принято именно такое решение;
Какие были трудности;
Как проблемы диагностировали;
Какие выводы сделали.
Если опыт не структурирован, ответы быстро разваливаются.
Если же кандидат сам хорошо понимает, что он делал и зачем, он спокойно проходит даже при неидеальном бэкграунде.
Поэтому сейчас важна не красивая история, а осознанное понимание своего опыта.
Что с этим делать
Минимальный практический набор:
Разложить свой опыт по зонам - архитектура, API, UI, CI/CD, процессы, инциденты.
Подготовить ответы в формате «проблема - решение - результат - выводы». (Для шарящих - по STAR)
Прогнать опыт через уточняющие вопросы и проверить, где ответы выглядят слабо или непоследовательно.
Упаковать резюме как набор конкретных ответов - что улучшал, что оптимизировал, за что отвечал + быть готовым это подтвердить.
Вывод
Рынок действительно стал сложнее.
Но именно поэтому он стал более комфортным для тех, кто держит фокус на релевантности, понимает свой опыт и готовится к проверке.
Если относиться к поиску работы как к инженерной задаче, жесткий рынок перестает быть проблемой и становится рабочей средой.
Ну а всем нуждающимся желаю скорее обрести себя на сегодняшнем рынке! Готов подискутировать на смежные темы в комментариях)
Представлен легковесный инструмент Crawlee, который может спарсить информацию с сайтов, соцсетей и других ресурсов, а также обходит защиту от ботов. Может скачать аудио, видео, изображения, метаданные, документы и прочие нужные файлы. Скрипты решения написаны на Python, имитирует поведение человека на сайтах, в соцсетях и других ресурсах. Инструмент поддерживает мультизадачность и не теряет при этом скорость. Можно собирать несколько видов данных одновременно. Работает полностью локально.
Открытый загрузчик Telegram Files позволяет скачать файлы из Telegram даже из закрытых чатов, включая аудио, видео, картинки, голосовые, гифки, документы и прочие файлы. Поддерживает сразу несколько аккаунтов в Telegram. Можно скачивать файлы из разных чатов одновременно и вообще не терять в скорости. Поддерживает превью файлов во время скачивания.Работает локально, не нарушает политику мессенджера.
Не надо делать по красоте. Надо делать MVP.
Никто так говорить, кроме менеджеров, не любит. А я вдруг внезапно полюбил такой подход в работе. Стал бить себя по рукам и делать дешево.
Оказывается, мозгу легче уйти в кроличью нору, чем просто делать задачу. Через час потной работы начинаешь зарываться в тонны документации, смотреть примеры кода на форумах или в репах на работе, переписывать свои модули по десять раз. Ощущение, будто стек собираешь, и он никак не схлопнется. Это обычная прокрастинация через усложнение.
MVP-подход тут мне стал очень помогать на моем, локальном уровне. Суть очень простая: делаю минимум и быстро. А потом добавляю на кости мяса. Надо сделать сохранение строк файла в БД? Пока сделаю построчно и поставлю # TODO. Потом сделаю батчем. Нужна отправка сотен объектов из БД в API? Пока тоже построчно. Нужна еще одна очередь Redis для этапа в обработке файла — потом. Пока и с одной очередью и воркером справимся.
MVP-подход требует некоей выдержки, особенно на пет-проектах. Код пишешь ты сам с собой. Выступаешь внутренним критиком и, зачастую, самым строгим. Но делать все дешево и сердито стало помогать мне лично держать фокус на цели: дать максимум ценности за минимум усилий. И при этом не сгореть от объема, быть в тонусе.
Риски, конечно тоже есть. У TODO нет хозяев, кроме нас. Дешевое Г становится иногда продом. Техдолг это вообще бесконечная тема и, пожалуй, не для этого поста. Пост про эффективность.
MVP-промтинг работает и с нейронками таким же образом. Берем чистый контекст, делаем простой прототип. А дальше по кускам его обтесываем, заменяем, улучшаем. Может, у нас есть с ними что-то общее?
У каждого человека есть свое определение голого минимума. Поэтому примеры выше могут кому-то показаться тривиальными. Очевидно, и сам подход не для всех. Но мне лично он развязал немного руки и помог выдохнуть на одной из недавних душных задач. Может быть такой ход мысли поможет и вам.
Рынку плохо? Работу найти нереально? — Это твой шанс 🚀
Последнее время всё чаще вижу одну и ту же ситуацию.
Человек активно ищет работу: отклики, собеседования, тестовые, разговоры с HR.
А на выходе — либо отказы без внятного объяснения, либо формулировки вроде
«вы хороший специалист, но нам нужен чуть другой профиль» 🤷♂️
И почти всегда звучит один и тот же вывод:
«рынок умер, конкуренция бешеная, сейчас вообще нереально найти работу».
Отчасти это правда — рынок действительно стал жёстче.
Но вот что интересно: именно в таких условиях многим стало проще выделяться 💡
Не потому что кандидатов стало меньше, а потому что вырос разрыв между теми, кто выглядит релевантно, и теми, кто — нет.
Я регулярно общаюсь с QA / AQA / SDET, которые сейчас находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы держать руку на пульсе.
И главный вывод из этого опыта простой: сегодня выигрывает не самый громкий кандидат, а тот, кто чётко понимает свой опыт и умеет его объяснять.
Ниже — что именно изменилось и как этим пользоваться 👇
Что изменилось
Ещё 1–2 года назад часто работала простая схема:
уверенное резюме + нормальная подача = высокая вероятность оффера 😌
Многие компании:
не сильно углублялись в детали;
смотрели на опыт в общих чертах;
закрывали глаза на неточности, если кандидат выглядел уверенно.
Сейчас ситуация другая:
вакансий в ряде направлений стало меньше 📉;
требования заметно выросли;
собеседования стали глубже и детальнее 🔍;
интервьюеры чаще проверяют логику решений и реальный вклад кандидата.
Это не “заговор рынка”, а обычная фильтрация: когда выбор большой — требования растут.
Почему в этом есть плюс
Жёсткий рынок хорош тем, что он быстро отсеивает слабые места ⚠️
Причём чаще всего — самые базовые.
Типичные проблемы, на которых кандидаты “сыпятся”:
говорят, что строили фреймворк, но не могут связно объяснить архитектуру;
упоминают автотесты, но не понимают, зачем выбран конкретный стек;
рассказывают про CI, но путаются в вопросах стабильности и flaky-тестов 🤯;
заявляют про ответственность за качество, но не могут описать процессы.
Большинство падает не на сложных вопросах, а на уточняющих.
На этом фоне человек, который осознанно разбирается в своём опыте, сразу смотрится сильнее 💪
Даже без “топовых” компаний в резюме.
Как сейчас смотрят на опыт 🎭
На интервью всё меньше внимания формальным строчкам и всё больше — мышлению 🧠
Интервьюеру важно понять:
почему было принято именно такое решение;
какие были ограничения;
что пошло не так;
как проблему диагностировали;
какие выводы сделали.
Если опыт не структурирован — ответы быстро разваливаются.
Если опыт разобран и понятен самому кандидату — он спокойно проходит даже при неидеальном бэкграунде.
Поэтому сейчас важна не “красивая история”, а осознанное понимание того, что ты делал.
🎯 Ключевой навык сегодня — релевантность
Недостаточно просто быть QA или AQA.
Важно быть релевантным:
конкретной роли;
стеку компании;
типу продукта;
уровню ответственности.
Это проявляется в деталях:
какие кейсы вы выбираете;
как формулируете достижения;
как отвечаете на вопросы «почему?» и «а что если иначе?».
Иногда достаточно слегка пересмотреть подходы или формулировки — и это сильно влияет на конверсию.
Что с этим делать 🛠
Практический минимум:
1️⃣ Разложить опыт по зонам: архитектура, API, UI, CI/CD, процессы, инциденты.
2️⃣ Готовить ответы в формате: проблема → решение → результат → выводы.
3️⃣ Прогнать опыт через уточняющие вопросы — здесь хорошо помогают LLM.
4️⃣ Упаковать резюме как набор сигналов 🚦 и быть готовым их подтвердить.
Вывод 🧠
Рынок стал сложнее — это факт.
Но именно поэтому он стал выгоднее для тех, кто:
держит фокус на релевантности;
понимает свой опыт;
готовится к проверке;
не теряется на уточнениях.
Если относиться к поиску работы как к инженерной задаче, “жёсткий рынок” превращается в возможность 🚀
👉 Если интересно — глубже разбираю эту и другие интересные темы в своем Telegram-канале, ну а также делюсь там инсайдами по рынку, собеседованиям и росту в AQA / SDET.
