Kurgan-Telecom Ru | Информационные технологии

На Хабре — регулярные посты в духе «проклятые HR’ы, 500 откликов, ноль ответов». На hh.ru — число джуниорских позиций сократилось вдвое. При этом, в нашу HR-службу приходят ребята с горящими глазами, проходят обучение — и через месяц кладут заявление, потому что надо ходить в офис (а иногда — сюрприз! - еще и в клиентский). Параллельно ходят байки про синьоров, которых сократили из крупных компаний, и теперь они соглашаются на зарплату вчерашнего стажёра — но живьем таких никто не видел, блин. А тут ещё вайбкодинг, которому едва исполнился год — и он, якобы, уже пишет за троих, и без ошибок. дададад.

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

Привет, Хабр! Я - Александр Черных, HR-директор «Диасофт».

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

Выяснилось: кто-то от имени «Диасофт» ведет полноценный найм в Telegram - с вакансиями, тестовыми заданиями и прочими атрибутами рядового рекрутмента. Только вместо оффера человек получает заблокированный телефон и требование выкупа.

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

Меня зовут Александр Черных, я HR-директор в «Диасофт», и я до сих пор сам провожу собеседования — последние два на этой неделе, стараюсь поддерживать форму, хотя уже двадцать лет, как целый директор, и мог бы не принимать участия в интервью. Но — искренне считаю, что подбор суть острие ножа рынка труда, и если ты от него отгородился условным отделом подбора персонала, то риск перестать понимать мир вокруг стремительно возрастает.

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

Статья о том, почему «лучшие хиты Queen» и «что-нибудь под пробежку» – это принципиально разные запросы, и что с этим делать ML-инженеру музыкального стриминга

Работа принята на EACL 2026 Workshop NLP4MusA. Авторы: Фёдор Бузаев, Ринат Муллахметов, Роман Богачёв, Илья Седунов, Олег Павлович, Камиль Мазитов, Дарья Пугачёва, Иван Сухарев (Zvuk, AIRI, НИУ ВШЭ, Иннополис).

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

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

Меня зовут Авдей Мартынович, больше 20 лет я занимаюсь поддержкой и развитием ИТ‑инфраструктуры для бизнеса. В этой статье разбираю, как один админ оказывается единственной точкой отказа, почему это проблема и для собственника, и для самого ИТ‑специалиста, а также какие процессы помогают снизить риски без войны и шантажа.

Одна из последних наших историй — как раз про такую ситуацию: собственник решил сократить ИТ‑расходы и внезапно осознал, насколько сильно бизнес зависит от одного человека, у которого сосредоточены ключевые доступы и знание инфраструктуры. Подробности расскажу в первой истории ниже.

1.       Преамбула

В литературе по программированию считается хорошим тоном начать демонстрацию программных средств с примитивной программы, выводящей на экран фразу "Hello, World!".

В разработке системы взаимодействующих движков на Elixir, о которой я писал в статье https://habr.com/ru/articles/1002748/, я как раз подошёл к вопросу отображения поступающих данных телеметрии на экран. Когда были готовы соответствующие базовые модули, я воодушевился идеей повторить знаменитый пример из учебника Кернигана и Ритчи. В результате у меня получилось следующее.

2.       Замысел

Сначала я придумал приём исключить из слоеной "запеканки вермишели", т.е. связей, объединяющих движки в рабочую сеть, сами... движки. В результате остались только снизу "запечённый" слой генераторов данных (не путать с тактовыми генераторами, о которых писалось ранее) и "верхняя корочка" так называемых стоков.

Термин сток заимствован из событийно-ориентированная архитектуры (EDA). Если угодно, то по-русски это будут выходные отверстий, куда данные "утекают". Напоминаю, что мы разрабатываем систему потоковой обработки данных, где данные находятся постоянно в движении.

3.       Систематизация аппаратных средств

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

Пройден "экватор" моего обучения на COO в Stratoplan и я все чаще ловлю себя на мысли:

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

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

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

Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.

Мы рассмотрим только те применения хеш-функций, которые регулярно встречаются в практике, а не что-то из разряда "100 способов измерения высоты здания с помощью барометра".

Рассматривая любительские рукодельные электронные лампы, например, [1, 2], интересно и полезно будет вспомнить и об остальных радиоэлементах, изготовлять которые ранним любителям приходилось самостоятельно и собственноручно. Кроме естественных корпусов-ящиков и контурных катушек, дросселей, трансформаторов, коллеги-предки часто были вынуждены делать и почти всё остальное — как установочные элементы — ручки, верньеры, шкалы, клеммы, включатели-переключатели, ламповые панельки, так и радиоэлементы пассивные — резисторы и конденсаторы переменные и постоянные, диоды (детекторы и выпрямители), элементы питания, в том числе и анодные (а это на минуточку — 40…80 вольт!) батареи.

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

Если вы уже разобрались с классическими сообщениями LayerZero (push-модель: отправили сообщение из одной сети и получили в другой сети), следующий шаг — научиться читать состояние других сетей, не разворачивая там свои контракты и не гоняя туда-сюда два сообщения. Для этого в LayerZero v2 есть lzRead — это request–response (pull) паттерн: контракт в исходной сети отправляет запрос (lzSend), а ответ возвращается обратно в исходную сеть и обрабатывается в lzReceive.

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

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

Мысль была такая:

волшебная палочка — это очень плохо спроектированный интерфейс.

Если посмотреть на неё не как на магический артефакт из сказок, а как на устройство взаимодействия пользователя с системой, то получается довольно странная конструкция.

Причём странная почти по всем параметрам: от физического дизайна до модели управления.

Попробуем разобрать её как обычное инженерное устройство.

Российский рынок CRM заметно «расслоился» на два мира. Первый — массовые «коробочные» решения для малого и среднего бизнеса с быстрым стартом и относительно жёсткими сценариями. Второй — корпоративные CRM‑платформы, которые выбирают крупные компании: с длительным циклом сделки, сложной организационной структурой, кросс‑функциональными процессами, требованиями по интеграциям, безопасности и высокой нагрузке.

В этом материале я решил сделать обзор корпоративных CRM-платформ, способных оказать комплексный эффект на весь бизнес — не только на воронку продаж. Разобраться в особенностях каждой из них бывает непросто, и я надеюсь вам в этом помочь!

Сегодняшняя статья основана на полугодовом опыте глубокого использования Claude Code и кучи набитых шишек. Надеюсь, это будет полезно.

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

В этой статье я хочу обсудить несколько вещей: как Claude Code работает изнутри, почему контекст засоряется и как с этим бороться, как правильно проектировать Skills и Hooks, как правильно использовать Subagents, как архитектура Prompt Caching влияет на всё, и как написать действительно полезный CLAUDE.md.

Меня зовут Илья, я мобильный разработчик в Naumen. Моя основная специализация — iOS-разработка. Я занимаюсь развитием мобильного клиента платформы Naumen Service Management Platform, а также Chat SDK в рамках Naumen Contact Center.

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

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

Привет, Хабр! Меня зовут Елизавета, я скрам-мастер стрима ДБО (веб-версия дистанционного банковского обслуживания) для банков в команде РСХБ.Цифра. Выстраиваю процессы на основе человекоцентричного подхода, помогаю команде раскрывать потенциал. В этом материале хочу поделиться с вами историей о том, как мы превратили обычную задачу по формированию команд в приятный процесс. Да, это возможно! Расскажу не только о методиках, но и человеческих взаимоотношениях, где психология — лучший друг программистов и тимлидов, которые объединяются ради создания продукта в финтехе.

Мы едим хлеб, а не смотрим на замешивание теста

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

Мы должны руководствоваться достижением цели, а не удобством процессов.

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

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

Как руководитель отдела ИИ с опытом внедрения решений в холдингах на 15 000+ сотрудников, я вижу, что только системный инженерный подход спасает проекты от превращения в «дорогой гараж».

Всем привет! Это мой первый опыт в ведение своего личного блога и более того даже в написание статей. Ну попытка не пытка.

В этом посте я честно расскажу о своем пути (от фрилансера до основателя digital студии). Где я ошибался, что помогло вырасти. Также поделюсь кое-какими мыслями, может кому то они будут интересны.

17 марта в Российском новом университете прошёл пресс-завтрак на тему «Гражданские беспилотники: от аэрофотосъёмки до сельского хозяйства». Цель мероприятия была связана с донесением до широких масс через приглашенных журналистов мысли о том, что БПЛА, даже в современных и очень непростых условиях, это отнюдь не только военные коптеры и дроны-разведчики, а средства передвижения и перемещения полезной нагрузки с огромным потенциалом для самых разных сфер и отраслей экономики.

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

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