Привет, Хабр! Меня зовут Полина Белокрыс, я промпт-инженер в hh.ru. Моя команда развивает ИИ-ассистента для работодателей, который берёт на себя рутинные задачи и помогает бизнесу сосредоточиться на главном — внимательной работе с подходящими кандидатами. В этой статье расскажу, как на самом деле устроен промптинг в продакшене — и почему написать промпт сложнее, чем просто поболтать с ChatGPT.

Статья будет полезна промпт-инженерам, начинающим ML-инженерам и инженерам GenAI, которые работают с языковыми моделями и хотят лучше понимать, как пишутся промпты для продуктовых систем.

Каждый год мы проводим исследования рынка труда, в том числе, конечно, сферы ИТ. И делимся результатами с Хабром — у нас в блоге можно посмотреть предыдущие, за 2023 и 2024 годы. А сегодня предлагаем читателям свежие сводки.

Мы разобрались с тенденциями рынка ИТ-вакансий, провели параллели с общей ситуацией на рынке труда в РФ, выяснили, что происходит с удалёнкой и какие навыки остаются наиболее востребованными в ИТ, как изменились зарплаты и у кого они продолжают расти, кто получает больше ожидаемого, а кому приходится пересматривать запросы. 

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

Привет! Меня зовут Карина, я QA-инженер в hh.ru. Наша компания растёт, а вместе с ней — число команд, вовлечённых в разработку и функционал. Появляются новые сервисы, базы данных, очереди. Каждый компонент требует слаженной работы и надёжной поддержки на тестовых стендах.

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

Мы проводим Школу программистов hh уже в 16-й раз. За это время через программу прошли сотни студентов, 115 выпускников в итоге стали частью команды hh и продолжают с нами работать. Формат Школы остается практичным и прозрачным: три месяца теории и четыре месяца командного проекта под руководством наших инженеров — реальная работа над продуктом с ментором из компании, а не сухие учебные примеры.

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

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

Привет, Хабр! Меня зовут Данила Максишко, я руковожу отделом продуктовых исследований и клиентского опыта в hh.ru. В статье я хочу поделиться историей ресёрча, который многое дал компании. Речь пойдёт о главной странице hh.ru для работодателей, которую мы успешно обновили с помощью исследователей.

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

Привет, Хабр! Меня зовут Виталий Барабанов, я iOS-разработчик в hh.ru. Недавно мы столкнулись с проблемой: пришёл фидбэк от пользователей о тормозах и фризах в мобильном приложении. Но чтобы установить их причину, нам не хватило данных, которые по дефолту собирает Apple.

Что делать в такой ситуации? А запилить собственный сбор метрик: с какой угодно фильтрацией, сбором любой информации, интеграцией со своей аналитикой и наблюдением в дебаг-панели! В статье я хочу поделиться с Хабром, как мы это сделали, сколько времени потратили и как интерпретировали результаты.

Привет! Меня зовут Саша Тотилас и я руковожу командой разработки в hh.ru. Хочу поделиться с Хабром результатами A/B-эксперимента: при оптимизации одного из экранов нашего приложения мы ускорили загрузку контента и выяснили, как это влияет на продуктовые метрики, а также собрали интересные инсайты.

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

Что любят все разработчики? Конечно, автоматизировать рутинные повторяющиеся действия! Я расскажу, как в этом может помочь язык Stencil, широко известный в узких кругах iOS-разработчиков.

Привет. Я Паша Мартышев, CTO hh.ru. Хочу поделиться тем, как мы применяем LLM в разработке и внедряем нейросети в работу коллег, разработчиков и не только. Недавно у нас неплохо получилось сделать это с помощью Вайбатона – внутреннего хакатона по вайбкодингу, и рассказ я построю на его материале. 

Вообще интеграция нейросетей в работу сейчас в тренде и будет в тренде ещё долго, тут мы не оригинальны. Но у нас получилось успешно популяризовать AI-инструменты среди коллег с помощью внутреннего хакатона – мы вовлекли больше 300 человек, получили 42 завершенных проекта, некоторые из которых можно сразу внедрять в работу. Это наглядный эффект. А также интересный способ через вайбкодинг познакомить с AI сотрудников, которые им не очень активно пользуются.

Надеюсь, наш опыт будет полезен читателям.

Привет! Меня зовут Андрей Максимкин. Я iOS-разработчик в hh.ru. В своих статьях (тут, тут и не только) мы уже не раз говорили о большой любви к тестам и их важной роли в нашем процессе разработки. В этой статье хочу поделиться опытом использования snapshot-тестов, начиная с этапа внедрения. Статья будет полезна для QA и iOS-разработчиков разных уровней. Обсудим не только теорию, но и напишем реальный snapshot-тест — как в нашей практике.

Вместо вступления

Сначала расскажем про snapshot-тесты и для чего они нужны. Snapshot тесты — это метод тестирования, который используется для защиты внешнего вида компонентов и интерфейсов от незапланированных изменений. Они позволяют зафиксировать эталонное состояние компонента и в дальнейшем использовать как образец. Это помогает выявлять изменения в пользовательском интерфейсе, которые могут возникнуть в результате обновлений кода.

В hh.ru мы активно разрабатываем нашу собственную дизайн-систему (ДС). Дело в том, что компоненты ДС могут иметь широкий набор свойств: цвета, размеры, скругления. Проверять корректность, например, цветов обычным ручным тестировщикам на длинной дистанции невозможно, поэтому возникла потребность автоматизировать проверки. Кроме того, при рефакторинге кода некоторые компоненты могут сломаться — хотелось бы находить такие проблемы сразу. Snapshot-тесты показались лучшим решением этих проблем.

Когда-то давно в hh.ru уже были snapshot-тесты. На тот момент они были написаны на экраны приложения. Эти экраны часто меняли свой дизайн, тесты вели себя нестабильно и падали, поэтому их приходилось переписывать. В итоге от snapshot-тестов отказались. Так что в своей новой попытке внедрения snapshot-тестов решили не писать тесты для экранов, а только для ДС. 

Про выделение микросервисов из монолита рассказывали много, но у каждого свой путь – в статье расскажем про наш.

От простейшего выделения сервиса в модуль в начале до решения проблем разрыва транзакций, SQL Join-запросов, задержек асинхронного API и непосредственно выделения нового сервиса. Использование event-driven архитектуры, редизайна модели данных и интеграционного слоя как основных подходов в процессе выделения.

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

Хорошая стратсессия помогает превратить поток мнений в согласованный план, в который команда верит и готова его реализовать. И ключ здесь — организация процесса.

Я Соня, Product Operations manager в hh.ru. Моя суперсила — создавать структуры, где люди смело говорят о важном, зная, что будут услышаны, а бизнес-цели достигаются по плану без шантажа и манипуляций. В этой статье я поделюсь прикладными советами, как можно превратить стратегическую сессию из дорогостоящих посиделок в место сбора команды с общей целью. 

В каждой компании есть необходимость выстроить систему observability. В hh.ru мы перестраивали архитектуру под большее количество данных несколько раз — сейчас имеем на входе 24к RPS, 1 миллион спанов в секунду, 5к инстансов сервисов. Если вы — инженер, который находится в процессе построения или перестройки собственной системы трейсинга, этот доклад — для вас.

Привет, Хабр! Я — Александр Казанцев, уже более десяти лет в разработке. Когда-то был инженером на пивзаводе и могу рассказать, из чего делают пенное; но сегодня — о другом.

Привет! Меня зовут Андрей, я исследую клиентский и пользовательский опыт в hh.ru. В статье расскажу, как нашей команде удалось вовлечь компанию в рисёчи и тем самым повысить их полезность.

Меня зовут Никита Сбитнев, я — продакт hh.ru. И сегодня я расскажу, зачем и для кого мы запустили тесты по ИТ-навыкам, кто их разрабатывал, как устроены задания и какие результаты уже получили.

Привет, меня зовут Андрей и я автоматизатор (остальные в кругу хлопают в знак сочувствия) в hh.ru. В статье расскажу, как мы ввели карантин автотестов, повысив стабильность релизов и скорость доставки.

Никто не любит очереди и ожидания. Мы не любим стоять в очередях и ещё больше не любим лезущих вне очереди. Сверхэффективный ад порой представляют как бесконечную, зацикленную саму на себе очередь... В конце концов, что есть символ неизбывной печали и тоски, как не Хатико.

Знаете, кто ещё больше не любит ожидания? Бизнес. Бизнес очень не любит, когда ожидания копят важные проекты и инициативы. Согласно исследованиям средняя эффективность потока в Delivery составляет 35%, а всё остальное время - задачи ждут. (Данные на основе опросов специалистов — ссылка. Метаанализ тысяч workflow от Nave - ссылка ) Справедливо, что ключевая точка роста для ускорения поставки — уменьшение ожиданий.

Именно об этих "фантастических" ожиданиях и пойдёт речь в статье. Я расскажу о системной работе с блокировками и зависимостями, которые повинны в значительном количестве задержек. Мы погрузимся в необходимую теорию, рассмотрим наш успешный практический кейс в hh.ru и, что особенно ценно, я поделюсь конкретными пошаговыми инструкциями по настройке Jira & n8n, а также способами работать с визуализацией блокеров в удобных плагинах, чтобы вы могли применить этот подход у себя.

Этот материал будет полезен IT-менеджерам, тимлидам, руководителям проектов, delivery менеджерам и руководителям функций — всем, кто стремится более осознанно и эффективно распоряжаться временем и ресурсами.

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

Именно в такой ситуации оказываются многие зрелые продуктовые сервисы. Рассмотрим пример Соискательского JobBoard в HeadHunter — это сервис, который отвечает за весь пользовательский опыт людей, которые ищут работу: от поиска вакансий до откликов на них. Я — Анвар, Сервис Деливери лид этого сервиса. Моя зона ответственности — эффективные процессы поставки ценности. Покажу, как несколько продуктовых команд учатся договариваться и синхронизироваться. Как они достигают общих целей без дирижёра.

Мы в hh очень любим UI-тесты, ими покрывается практически вся функциональность наших приложений, и даже backend-разработчики прогоняют тесты мобильных платформ перед развертыванием своих фич. Однако наши механизмы UI-тестирования разрабатывались более 8 лет назад и с тех пор почти не изменились.

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

Поэтому мы пересмотрели наши подходы к UI-тестированию и теперь готовы поделиться наработками с сообществом в виде open-source проекта — Rafinad. В этой статье расскажем, что он умеет и как им пользоваться.

Привет! Меня зовут Андрей Максимкин, я iOS-разработчик в hh. Мы в команде активно используем async/await подход при написании нового кода, а также активно применяем при переписывании старого. В процессе работы сталкивались с некоторыми интересными и не самыми очевидными моментами — их и рассмотрим в статье.

Работа с различными потоками — очень важная часть разработки мобильных приложений под iOS. Грамотное распределение нагрузки положительно влияет на скорость работы приложения, а значит, и на пользовательский опыт. До Swift 5.5 для работы с многопоточностью в основном использовали фреймворки GCD и NSOperation. Начиная с версии Swift 5.5 стал доступен функционал async/await. В статье мы кратко расскажем о базовых принципах данного подхода и сделаем акцент на проблемах и особенностях, которые необходимо знать при написании кода. Информация будет полезна тем, кто уже знаком с функционалом async/await, а некоторые примеры могут быть интересны и более продвинутым разработчикам.