Обновить
776.58

Python *

Высокоуровневый язык программирования

Сначала показывать
Порог рейтинга

Здравствуйте! Сегодня хочу вам представить микроядро rMach.

моя реализация handoff scheduling
моя реализация handoff scheduling

Это проект микроядра в 700 с чем то строк кода. Финальный билд говорит что ядро потребляет 19.9 кб в RAM.

На самом деле в ядре могут быть недочёты и части которые можно оптимизировать, но в принципе работает.

Я реализовал там:

  1. Reference counting (на порты) - чтобы не жрали память порты которые не кто не использует.

  2. Send once (право SERVER) - да, он самый.

  3. VM для изоляции и вытеснение. Нет, не virtual memory, а virtual machine.

  4. Handoff scheduling - имеет недочёты, но в целом работает.

  5. O(1) планировка на стероидах битовых масках.

  6. IPC на портах - как в Mach.

Да, снова MicroPython, но уже думаю над C.

А что с Pech? Да ну так себе - к примеру можно обойти изоляцию зная фичи Python'а.

Взломать rMach почти не возможно. Не обещаю, но вроде не возможно.

Как всегда (нет) - пост хотел в "Я пиарюсь", но - карма не позволяет.

Ссылка: https://github.com/SystemSoftware2/rMach

Если найдете баг - пожалуйста, скажите, я буду рад.

Также пример программы на моей VM:

CREATE_PORT
STORE my_port

PUSH 42
PUSH 0
FETCH my_port
SEND

FETCH my_port
RECV
PRINT
HALT

Удачи!

Теги:
+1
Комментарии1

Представлен открытый проект rembg — легковесный скрипт на Python, который поможет убрать фон даже с самых сложных картинок. Удаляет фон за секунды и не грузит ПК.

Теги:
+2
Комментарии0

Открытый проект Dangerzone позволяет преобразовать любой документ в безопасный PDF. Решение работает с , таблицами, картинками и другими форматами документов, распаковывает и проверяет их в изолированном пространстве — даже если внутри вирус, локальному ПК ничего не грозит. На выходе получается безопасный файл для просмотра.

Теги:
+1
Комментарии0

Открытый проект Cheat-Sheets предоставляет учебны материалы для Python, Rust, Swift, JavaScript, Kotlin, Go, Git, и других проектов. Там есть все важнейшие концепции, правила, стили программирования, фреймворки, библиотеки и прочее. Внутри также курсы по Git, Docker, базам данных, а также алгоритмам. Все материалы разделили по уровням сложности, к каждой главе есть контрольные вопросы и десятки задач. Все концепции авторы объясняют на конкретных примерах и разжевывают до последней строчки кода.

Теги:
+4
Комментарии0

Всем привет. Хотелось узнать, сложно ли развивать Telegram бот.
Нашел на просторах habr такую статью:
https://habr.com/ru/articles/778588/
Мой бот только на русском языке, поэтому статьи писал на Яндекс Дзен (0 просмотров, пост скорее всего удалили), DTF (лучший источник пользователей, комментят и заходят в бота), habr (написал пост-рекламу - не помогла).
Еще есть реддит, но я новый пользователь (там с этим беда - карма маленькая (попаду в ад)).

Что посоветуйте делать? Только не бейте)
Ну и соответственно ссылка на бота:
http://t.me/drinking_buddy_2025_bot

Всем спасибо)

Теги:
-2
Комментарии0

Про Созвоны

Любой руководитель в распределенной команде сталкивался с ситуациями, когда команда начинает гореть от созвонов. Спринт задачами набили, оценили, а потом половину не сделали. Из-за чего? Не попали в оценки. Были влеты..

А еще была куча общих встреч, ретро, планнингов, скрам-баннингов и интерраптов, которые на доске и в таймшите не увидишь.

Инженеры так не любят созвоны, потому что у них неосязаемый импакт и definition of done. Они мыслят задачами, мерж-реквестами, зелеными тестами, чем-то с измеримым результатом. Сел за задачу, вник и сделал. КПД в идеальных условиях напоминает воркера. В очередь пришла задача — он ее обработал и закрыл, ждет следующую. В перерывах гладит кота или пузо.

Когда инженер сидит на звонках, которые его напрямую не касаются, его пропускная способность падает из-за ложных сигналов. Он не может нормально параллельно работать. Надо либо час вникать, либо мозг выключается в мемы, либо на встречу в принципе забивают. Многие созвоны вообще не для инженеров. Они для менеджеров.

Для внеплановых статусов менеджер не всегда заранее знает, кто ему по факту нужен, и зовет «на всякий». На созвонах, кроме ведущего и ЛПР, участники в принципе нужны подстраховать. Вася может понадобиться. А может и не понадобиться. И опять сидит Вася без камеры, без микрофона и грустит. Ждет, когда все закончится, чтобы вспоминать, на чем он там остановился.

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

Кто поможет создать правильный шумовой барьер и дать команде работать, при этом отдавая в проектный офис нужную информацию? Как по мне, это не обязательная боль инженера. Побороть проблему — роль хорошего лида.

  1. Урон от звонков надо вбирать в себя лиду. Его обязанность — знать контекст по верхам о проблемах и задачах вверенной команды. Отстаивать их интересы, обрабатывать обратную связь. Таков путь, отделяющий лида от сеньора-помидора.

  2. Лиду надо собирать дашборды, таблицы, фильтры, регламенты, схемы. Запросы на оперативную информацию не должны отнимать ресурсов. Все по полочкам: база знаний, закладки, конфля, raycast шорткаты, ИИ-агента с MCP натравить на Confluence и Jira (если ИБ по шапке не даст). Надо и свой ресурс беречь и дать просящему удочку вместо рыбы.

  3. От лишних звонков можно отказываться. Без конфронтаций, просто фильтровать: «А зачем? Вот все ответы на вопросы». Либо можно договориться многие задачи сделать асинхронно. Таска в джире с исполнителем и сроком и поехали.

  4. Проектам нужна карта компетенций. Для тех ситуаций, где нужно глубже вникнуть в предметную область, это ок — привлечь инженера вместо лида. Важно знать, какого. Классический мем: девять женщин не могут родить ребенка за месяц. С этим стереотипом «больше-лучше» карта компетенций помогает бороться.

  5. Звонок на час — плохой дефолт. 45 минут — уже лучше. 30 минут — еще лучше. 15 можно не ставить, есть мессенджер и почта.

  6. Звонки должны ставиться по календарю. Вызванивать минута в минуту — моветон хотя бы потому, что есть правда неотложные ситуации. Но не все звонки — неотложные.

  7. У звонков должны быть повестки. Приглашенные должны иметь возможность понимать, о чем пойдет речь. В идеале, нужна ссылка на доки или задачи. Без этого участники идут на звонок вслепую и тратят время, чтобы понять, что от них хотят.

Побуду адвокатом дьявола. На некоторые звонки команду лидам брать надо. Так можно узнать полезную информацию с полей. Ребята могут раскрыться, вовлечься. Вполне смогут затащить какой-то каверзный проект и унести его в перфоманс ревью.

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

Зло — звонки не оптимизировать. А инженера с его очередью лучше оставить в цикле и не засорять эфир.

Теги:
+3
Комментарии1

Не смогли смириться с поражением - и к чему нас это привело. Как мы воскресили ИИ-помощника для поиска работы

Привет, Хабр.

В декабре наш ИИ-ассистент для поиска работы фактически перестал работать.
Изменения на стороне платформ, ограничения, поломанные сценарии - всё то, из-за чего большинство подобных проектов обычно закрываются или уходят в «заморозку».

Самый логичный вариант был простой:

«Ну ок, рынок поменялся, едем дальше».

Но мы решили иначе.

Мы не смогли смириться с тем, что квалифицированные специалисты по-прежнему тратят часы жизни на клики, шаблонные отклики и бесполезную рутину.
Поэтому вместо точечных фиксов мы решили не чинить старое, а пересобрать всё с нуля.

Так начался путь к OfferMate 2.0.

Главная мысль оказалась неожиданно простой:

Автоматизация должна быть не только быстрой, но и естественной.

Настоящий цифровой ассистент должен вести себя как человек:

  • выбирать вакансии осмысленно;

  • работать с паузами и приоритетами;

  • не выглядеть как бот;

  • и не ломаться при реальной нагрузке.

Именно вокруг этого принципа мы и пересобрали архитектуру продукта.

Что теперь умеет OfferMate 2.0

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

👤 Имитация человеческого паттерна поведения
Система воспроизводит действия пользователя: паузы, разную скорость, приоритеты.
Это делает работу максимально естественной и безопасной.

✍️ Персонализированные сопроводительные письма
Каждое письмо формируется под конкретную вакансию и компанию - на основе вашего опыта и требований позиции.

📈 Контроль и аналитика
Пользователь видит, что происходит в системе, и может управлять стратегией поиска.

🧩 Новые функции

  • автоматическое прохождение онлайн-тестов;

  • поддержка одновременных откликов с нескольких аккаунтов.

Про релиз

12 февраля в 12:00 мы открываем доступ к OfferMate 2.0.

Первая волна будет ограничена 50 пользователями, а доступ открыт на 3 дня.
Это осознанное ограничение - чтобы сохранить стабильность системы и быстро собрать качественную обратную связь.

Поучаствовать в тестировании в числе первых можно будет в нашем телеграм канале, в нём делимся всеми новостями проекта:

👉 https://t.me/offermatecrew

Буду рад вопросам и обсуждению в комментариях

Теги:
+2
Комментарии0

Открытый проект ebook2audiobook превращает любую электронную книгу в полноценную аудиокнигу. Работает просто: закидываете epub, pdf или даже обычный txt и на выходе получаете готовый аудиофайл с главами, нормальной озвучкой и метаданными. Подойдёт, если не любите читать глазами, но хотите слушать книги в дороге или на тренировке. Работает локально на ПК и поддерживает множество языков и даже умеет клонировать голос. Можно озвучить книгу своим голосом или профессиональным диктором. Идеально для студентов, тех кто учит языки, или просто хочет слушать свои книги офлайн без подписок и облаков.

Теги:
+5
Комментарии0

Обновлён учебный курс Welcome to the Python Programming Hub по Python с полного нуля до уровня продвинутого разработчика за 3 месяц. В репозитории сотни материалов для изучения Python, а также Data‑аналитики, машинного обучения, Data Science. Там есть вся база по Python с первых строчек кода до комплексного ООП, лямбда‑функций, замыканий и других сложных концепций языка. Изучение всех необходимых базовых библиотек, которые должен знать каждый уважающий себя разработчик на Python: JSON, Math, NumPy, Pandas, а также фреймворка Django. Материалы по всем актуальным и полезным API, машинному обучению, распознаванию речи, парсингу, компьютерному зрению, работе с изображениями и даже видео, алгоритмам и автоматизации процессов. Также даётся детальное представление о различных специализациях Python‑разработчиков, которые можно освоить и реализовать несколько пет‑проектов. В каждой главе представлены исчерпывающие примеры кода, картинки, объяснения, квизы и контрольные вопросы.

Теги:
+2
Комментарии3

лайкните пост кто сейчас вайбкодит свои продукты и напиши в комментах что делаете. очень интересно!

вайб кодинг
вайб кодинг
Теги:
-24
Комментарии5

Почему хороший тестировщик — это не тот, кто нашел больше всего багов

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

На практике все сложнее. И чем опытнее становится тестировщик, тем реже он гордится просто цифрами.

Количество багов ничего не говорит само по себе

Сто найденных дефектов могут означать две совершенно разные вещи:

  • продукт реально нестабилен;

  • тестирование началось слишком поздно.

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

Сильный тестировщик думает раньше, чем тестирует

Тестирование начинается не с чек-листов и не с автотестов. Оно начинается с вопросов.

  • что здесь может пойти не так;

  • где система уже ломалась;

  • какие изменения самые рискованные.

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

Баг-репорт — это не обвинение

Новички иногда воспринимают баг как доказательство чьей-то ошибки. Отсюда агрессивные формулировки и желание «поймать» разработчика.

Опытный тестировщик понимает — баг-репорт это способ помочь команде. Хорошее описание проблемы экономит время всем:

  • понятно, что сломалось;

  • понятно, как воспроизвести;

  • понятно, почему это важно.

Чем меньше эмоций и больше контекста — тем лучше работает процесс.

Автотесты — это не самоцель

Автоматизация часто превращается в гонку — у кого больше тестов, у кого выше покрытие. Но цифры сами по себе ничего не гарантируют.

Хороший тестировщик задает другие вопросы:

  • ловят ли эти тесты реальные проблемы;

  • можно ли им доверять;

  • не мешают ли они менять код.

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

Хороший тестировщик думает о пользователе, а не о сценарии

Чек-листы и тест-кейсы важны, но реальный пользователь почти никогда не действует по ним.

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

Качество — это ответственность всей команды

Одна из самых токсичных идей в тестировании — что за качество отвечает только QA. Это удобно, но не работает.

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

Карьерный рост в тестировании — это не про инструменты

Инструменты меняются быстро. Сегодня один фреймворк, завтра другой. Знание конкретного тулкита редко определяет уровень специалиста.

Гораздо важнее:

  • умение анализировать систему;

  • понимание, где искать проблемы;

  • способность говорить с разработчиками и бизнесом на одном языке.

Именно это делает тестировщика ценным, а не список технологий в резюме.

В итоге

Хороший тестировщик — это не тот, кто нашел больше всего багов. Это тот, кто:

  • помогает находить проблемы раньше;

  • думает о рисках, а не о галочках;

  • пишет понятные баг-репорты;

  • работает с командой, а не против нее.

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

Теги:
+5
Комментарии3

Сразу оговорюсь, это пост- реклама.

Написал Telegram бота для знакомств (поиск собутыльника). Пользователь отправляет свою геопозицию (широту и долготу), а боту нужно предложить людей, живущих рядом.
Нашел на просторах интернета HTTP Геокодер от Яндекса. Что-то около 25000 запросов в месяц бесплатно. Ты отправляешь запрос с широтой и долготой, а сервис тебе населенный пункт (район, улица и т.д.).
Ссылка на сервис:
https://yandex.ru/maps-api/products/geocoder-api
Подключить его не сложно (документация хорошая).

Приведу пример запроса:

PARAMS = {
        "apikey":"ваш api key",
        "format":"json",
        "lang":"ru_RU",
        "kind":"locality",
        "geocode": "долгота, широта"
    }

    #отправляем запрос по адресу геокодера.
    try:
        r = requests.get(url="https://geocode-maps.yandex.ru/1.x/", params=PARAMS)
        #получаем данные
        json_data = r.json()
        #вытаскиваем из всего пришедшего json именно строку с полным адресом.
        address_str = json_data["response"]["GeoObjectCollection"]["featureMember"][0]["GeoObject"]["metaDataProperty"]["GeocoderMetaData"]["AddressDetails"]["Country"]["AddressLine"]
        #возвращаем полученный адрес
        return address_str
    except Exception as e:
        logger2.error(e, exc_info=True)
        #если не смогли, то возвращаем ошибку
        return "error"

Поменяйте только ваш apikey и широту с долготой. Запрос вернет населенный пункт по заданным данным (долгота и широта).

Ссылка на моего бота:
http://t.me/drinking_buddy_2025_bot

Спасибо за внимание

Теги:
-2
Комментарии0

Ближайшие события

Яндекс.Музыка заблокировала доступ к сервису на уровне аккаунта. Уже 3 месяца поддержка “разбирается

С ноября у меня полностью заблокирован доступ к Яндекс.Музыке на уровне аккаунта (bearded-rocker@yandex.ru). Не отдельный девайс, не браузер, не приложение — аккаунт целиком.

TL;DR

  • Я использую официальный API Яндекс.Музыки

  • В какой-то момент доступ к Яндекс.Музыке для моего аккаунта был молча заблокирован

  • Блокировка воспроизводится во всех клиентах: веб, мобильные приложения, устройства

  • Смена токенов, переустановка приложений, другие устройства — не помогает

  • В поддержке заведены тикеты ещё с ноября

  • Прошло больше 4 месяцев — доступа нет, решения нет

Предыстория

Осенью я начал пользоваться Яндекс.Музыкой и колонкой с Алисой. Чтобы не терять годы истории из Spotify, я написал небольшой сервис, который синхронизирует мои плейлисты и треки через неофициальный API Яндекс.Сервис какое-то время нормально работал, после чего доступ к Яндекс.Музыке для моего аккаунта внезапно пропал полностью.

Симптомы выглядят так:

  • Яндекс.Музыка не работает нигде:— веб— iOS / Android— устройства с Алисой

  • Это не связано с VPN, IP или устройством

  • Это не выглядит как клиентская ошибка

  • Это выглядит как account-level блокировка внутри сервиса

  • в Браузере получаю ответ (в dev tools):

{ "name": "forbidden", "message": "403 Forbidden: "{"name":"API access restricted","message":""}"", "requestId": "99f13438-a1c9-43a7-9d7d-7de00bd3ea49.1"}

Яндекс.Музыка заблокировала доступ к сервису на уровне аккаунта. Уже 3 месяца поддержка “разбирается”
Яндекс.Музыка заблокировала доступ к сервису на уровне аккаунта. Уже 3 месяца поддержка “разбирается”

Я сразу обратился в поддержку Яндекс.Музыки. После стандартных проверок они подтвердили, что проблема не на моей стороне, и завели тикет “на инженеров”.

На сегодняшний день:

  • есть два тикета, заведённых ещё в ноябре: 25103113405032668, 25121613434183682

  • каждый новый оператор начинает диалог заново

  • снова предлагается “обновить браузер / переустановить приложение”

  • затем снова: «да, мы видим проблему, инженеры занимаются»

Я не прошу ничего экстраординарного:

  • Восстановить доступ к Яндекс.Музыке для моего аккаунта bearded-rocker@yandex.ru, я плачу за Plus, Алису-Pro и хочу пользоваться этими сервисами.

Сейчас же ситуация выглядит так:

  • платный сервис недоступен

  • тикеты “живы”, но без движения

  • сроков, статуса и ответственного нет

@yandex please help 🙏

Теги:
+7
Комментарии12

Копипаста в Python редко выглядит как копипаста

В Python-проектах дублирование кода почти никогда не выглядит как «один файл скопировали в другой». Чаще это повторяющиеся структуры, контрольные потоки и оркестрационная логика, которые со временем начинают незаметно расползаться по коду.

Формально всё выглядит по-разному: другие имена, другие константы, чуть иной порядок.
Но архитектурно — это одно и то же решение, просто размноженное.

Я хочу рассказать про CodeClone — инструмент, который я написал для поиска именно такого дублирования. Он не сравнивает строки и токены, а работает на уровне **нормализованного Python AST и графов управления потоком (CFG).

Почему текстовые clone-detectors не работают

Большинство инструментов ищут дублирование через строки, токены или поверхностное сравнение AST. Это отлично ловит copy-paste, но почти бесполезно, когда код:

  • переименован,

  • отформатирован по-другому,

  • слегка отрефакторен,

  • но реализует один и тот же сценарий.

В реальных проектах это часто:

  • одинаковые цепочки валидации,

  • повторяющиеся request/handler пайплайны,

  • скопированная оркестрационная логика,

  • похожие try/except или match/case конструкции.

Идея: сравнивать структуру, а не текст

В CodeClone я пошёл другим путём:

  1. Код парсится в Python AST.

  2. AST нормализуется (имена, константы, аннотации убираются).

  3. Для каждой функции строится Control Flow Graph.

  4. Сравнивается структура CFG, а не исходный код.

Важно: CFG здесь — структурная абстракция, а не модель выполнения. Цель — найти повторяющиеся архитектурные решения, а не доказать семантическую эквивалентность.

Что именно ищется

Функциональные клоны (Type-2)

  • Функции и методы с одинаковой структурой управления:

  • if/else, циклы, try/except, with, match/case (Python 3.10+).

  • Инструмент устойчив к переименованию, форматированию и type hints.

Блочные клоны (Type-3-lite)

  • Повторяющиеся блоки внутри функций: guard-clauses, проверки, orchestration-фрагменты. Используется скользящее окно по CFG-нормализованным инструкциям с жёсткими фильтрами, чтобы снизить шум.

Почему инструмент намеренно консервативный

Один из принципов проекта:

Лучше пропустить клон, чем показать ложный.

CodeClone не использует ML, вероятностные коэффициенты или эвристические скоринги.
Если клон найден — его можно объяснить и воспроизвести. Это важно при использовании в CI.

Baseline и CI

В живых проектах дубликаты уже есть, поэтому CodeClone работает в baseline-режиме:

codeclone . --update-baseline

Baseline коммитится в репозиторий, а в CI используется:

codeclone . --fail-on-new

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

Про Python-версии

AST в Python не полностью стабилен между версиями интерпретатора. Поэтому версия Python фиксируется в baseline и должна совпадать при проверке. Это сделано ради детерминизма и честности результатов.

Итог

CodeClone не заменяет линтеры или type-checkers. Он полезен, если проект живёт долго, код растёт, и хочется вовремя замечать архитектурное дублирование, а не разбираться с его последствиями позже.

Исходники

GitHub: https://github.com/orenlab/codeclone
PyPI: https://pypi.org/project/codeclone/

Теги:
+3
Комментарии1

Открытый проект 8mb.local — Self‑Hosted GPU Video Compressor умеет сжимать видео любых размеров в десятки раз. Нужный размер пользователь выбирает сам, а компрессор подстроится. По возможности сохраняет качество. Можно выбрать кодек, битрейт и даже обрезать видос во встроенном редакторе. Всё работает локально.

Теги:
+1
Комментарии0
Настройка Clawdbot
Настройка Clawdbot

Clawdbot: когда обезьяне дали гранату 🤡

Совсем недавно Clawdbot хайпанул. И тут такое началось... Это не цирк, это хуже.
Добрый дядя из гайда советует прокинуть туннель через ngrok или развернуть это дело на VPS с открытым портом.

Итог: любой школьник находит ваш IP или ngrok-адрес и получает RCE (удаленное выполнение команд) от вашего имени.

Судя по последним новостям агенты и сами не против опубликовать куда нибудь ваши тонны. Так, между делом.

Какой-то цифровой эксгибиционизм. Отберите у них Докер, пока не поздно.

Теги:
+3
Комментарии1

Вышел Nanobot: сверхлёгкая версия Clawdbot (сейчас Openclaw), которая на 99% проще и позволяет запустить ИИ‑помощника менее чем за минуту. Clawdbot кажется слишком сложным, а в Nanobot разберётся даже новичок. Весь движок умещается всего в ~4000 строк кода на Python, тогда как Clawdbot это огромный монстр на 400 000 строк. Nanobot запускается за минуту и готов помогать вам в повседневных задачах, включая анализ рынка в реальном времени: непрерывный мониторинг и сбор аналитики, разработку ПО, помощь в комплексных проектах, управление делами и оптимизация рабочего времени, персональный помощник по знаниям.

Теги:
0
Комментарии0

Как оставаться релевантным на рынке QA/AQA/SDET в 2026: опыт, харды, софты, ответы

Последнее время всё чаще слышу вопросы про состояние рынка.
Многие говорят, что рынок «умер», вакансий стало меньше, а требования выросли настолько, что найти работу почти нереально.

Часто это выглядит так: человек активно откликается, ходит на собеседования, делает тестовые задания, общается с рекрутерами.
А на выходе получает либо отказы без конкретных причин, либо формулировки вроде «вы хороший специалист, но нам нужен немного другой профиль».

Ощущение, что стало сложнее, не обманчиво. Рынок действительно изменился за последние один-два года.
Но парадокс в том, что именно в таких условиях многим стало проще выделяться. Не потому, что кандидатов стало меньше, а потому, что вырос разрыв между теми, кто выглядит релевантно, и теми, кто нет.

Я регулярно общаюсь с QA, AQA и SDET, которые находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы понимать, как именно сейчас устроен процесс найма.
И вот что я понял из всех историй: сегодня выигрывает не самый наглый кандидат (как было раньше), а тот, кто хорошо понимает свой опыт и умеет его объяснять.

Что изменилось

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

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

Это не «заговор рынка», а естественная фильтрация. Когда выбор кандидатов большой, требования становятся строже.

Почему в этом есть плюсы

Жесткий рынок хорошо отсеивает слабые места. Причем чаще всего самые базовые.

На собеседованиях у ребят регулярно всплывают одни и те же проблемы:

  • человек говорит, что строил фреймворк, но не может связно объяснить архитектуру;

  • упоминает автотесты, но не понимает, почему был выбран конкретный стек;

  • рассказывает про CI, но путается в вопросах стабильности;

  • заявляет ответственность за качество, но не может описать процессы и зоны ответственности.

Большинство кандидатов «падает» не на сложных вопросах, а на уточняющих.
На этом фоне специалист, который осознанно разбирается в своем опыте и может его структурировано рассказать, сразу выглядит сильнее, даже без громких компаний в резюме.

Как сейчас смотрят на опыт

На интервью все меньше внимания уделяется формальным строчкам в резюме и все больше мышлению.

Интервьюеру важно понять:

  1. Почему было принято именно такое решение;

  2. Какие были трудности;

  3. Как проблемы диагностировали;

  4. Какие выводы сделали.

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

Поэтому сейчас важна не красивая история, а осознанное понимание своего опыта.

Что с этим делать

Минимальный практический набор:

  1. Разложить свой опыт по зонам - архитектура, API, UI, CI/CD, процессы, инциденты.

  2. Подготовить ответы в формате «проблема - решение - результат - выводы». (Для шарящих - по STAR)

  3. Прогнать опыт через уточняющие вопросы и проверить, где ответы выглядят слабо или непоследовательно.

  4. Упаковать резюме как набор конкретных ответов - что улучшал, что оптимизировал, за что отвечал + быть готовым это подтвердить.

Вывод

Рынок действительно стал сложнее.
Но именно поэтому он стал более комфортным для тех, кто держит фокус на релевантности, понимает свой опыт и готовится к проверке.

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

Ну а всем нуждающимся желаю скорее обрести себя на сегодняшнем рынке! Готов подискутировать на смежные темы в комментариях)

Теги:
-3
Комментарии0

Открытый учебный проект 30 Days of Python помогает освоить синтаксис и концепции языка программирования за месяц. Там есть основная база Python от настройки окружения до мощного ООП, организации кода и паттернов проектирования. Каждый день — новая тема. После каждого урока есть десятки вопросов для самопроверки и упражнений для повторения. При этом каждый следующий урок опирается на предыдущий.

Теги:
+1
Комментарии0
1
23 ...