Проблема: Традиционный найм в IT сломан. Мы просто боимся в этом признаться.
Вы когда-нибудь тратили 2 месяца на собеседования, чтобы в итоге получить отказ без объяснений? Или, наоборот, нанимали разработчика, который блестяще прошёл все этапы, но на деле не мог выполнить простейшую работу? Тогда эта статья для вас.
Продакшен не ломается «в целом» — он ломается в логах, сетевых правилах, бэкапах и одном неудачном деплое. Поэтому в этом дайджесте собрали образовательные ресурсы на темы, которые реально держат систему на плаву: CI/CD в GitLab, платформа на Kubernetes, observability без хаоса, сеть и безопасность. В конце — статьи, которые хабровчане уже проверили на прочность своим вниманием.
Привет, Хабр! Меня зовут Анастасия Егина, я финансовый аналитик и партнер-менеджер в компании КРОК. 20 лет назад я пришла сюда студенткой. Сегодня руковожу командой проектного учета, развиваю отношения с партнерами, внедряю инициативы, которые влияют на оптимизацию процессов компании. Как вышло, что я здесь уже два десятилетия? Моя история не про идеальный план, а про людей, кризисы, возможности и желание делать лучше.
Вокруг IT давно идёт не просто «рост рынка», а полноценная золотая лихорадка. И как в любой лихорадке, быстрее всего развивается инфраструктура вокруг добытчиков: «лопаты», «тележки», «лагеря», «еда».
В IT роль этих «лопат» выполняют облака, готовые платформы, сервисы безопасности, биллинга, аналитики, CI/CD, мониторинга, авторизации, хранилищ, очередей, интеграций, шаблонов архитектуры — и тысячи команд, которые годами шлифуют каждую деталь. В итоге на наших глазах происходит аутсорс технической сложности: сложные вещи становятся доступными дешевле, стабильнее и быстрее, чем если собирать их внтри компании.
Отсюда и провокационная мысль: во многих компаниях CTO как штатная роль не обязателен. Обязательна технологическая функция — но её уже не всегда нужно закрывать одним человеком в кресле «директора по технологиям».
Давайте разбираться, почему ваш следующий стартап может взлететь без «Возняка» на борту.
Больше не нужно готовить ответы на частые вопросы рекрутеров, вспоминать матчасть и нервничать перед камерой. Ведь можно просто поставить софт, который будет шептать правильные ответы прямо во время созвона.
Неужели это чит-код на оффер?
Привет, Я — HR Лена. Я проверила нейросеть Sobes.tech, которая помогает проходить онлайн-собеседования, и узнала, реально ли перескочить свой грейд, заметна ли нейросеть рекрутеру и почему успешно пройденный собес — вовсе не победа.
Кто торопится, спускайтесь в самый низ к выводам.
Всем привет! Меня зовут Кирилл, я один из основателей Максилекта. Но сегодня говорю не от лица компании, а как человек, наблюдающий со стороны за рынком труда.
Мы все заметили, что на ИТ-рынке сложились непростые условия. В первую очередь они чувствуются на изменении найма — я рассказывал о новых тенденциях в предыдущих статьях. А сегодня обсудим ситуацию глобальнее. Расскажу, почему, на мой взгляд, спрос на ИТ-шников упал и что нужно, чтобы вернуть его к привычному уровню.
Всем привет, этот пост посвящен двум популярным книгам по подготовке к собеседованию по системному проектированию. Я купил и прочитал обе, поэтому могу дать обзор и подготовить резюме для тех, кто заинтересован. Хотя я рекомендую прочитать обе книги. (Запомнить все из них — задача сверхчеловеческая, но достаточно будет, если вы уловите такие концепции, как «Приблизительные оценки» или «Конкурентность»).
Привет, Хабр!
Прошел все технические этапы, решил задачи на алгоритмы, обсудил архитектуру, показал опыт — и вдруг отказ. Без объяснений, с размытой формулировкой про «другого кандидата» или «культурное несоответствие». Знакомо?
Техническая часть — это только входной билет. Финальный раунд решается по совсем другим критериям. Разберем, что влияет на решение после успешной техсекции.
В первую очередь, оставлю ссылку на исходный пост. В нём HR-специалист делится криком души на тему состояния найма. Об эту тему сломаны уже сотни копий. Я начал было писать комментарий, но он вышел весьма объёмным, поэтому решил вынести в отдельный пост. Поэтому предлагаю коллегам из HR выслушать точку зрения по другую сторону баррикад, а коллегам-разработчикам поделиться опытом, чтобы облегчить жизнь нам всем. Свой же опыт я опишу ниже.
В прошлом посте мне предрекли судьбу старухи у разбитого корыта. Комментаторы справедливо заметили: «Визионер без хард-скиллов - это просто мечтатель». Я обещал не спорить, а показать результат. Время пришло.
Убираем лирику, достаем «мясо». Внутри - полный разбор архитектуры AI-платформы на n8n + Supabase + OpenAI: как реализовать рекуррентные платежи, SRS-систему повторений и генерацию PDF-дипломов, не написав и сотни строк кода вручную.
Добрый день, хабравчане!
Хочу рассказать вам свою историю. И сразу к сути: эта статья — в первую очередь, большая благодарность моей жене. Без неё этой истории просто не было бы. Если вам не интересны личные истории, а нужны только технические посты с кодом и benchmark'ами — смело пролистывайте, ничего обидного не будет.
Привет, Хабр!
В рамках киберучений CyberCamp 2025 R-Vision выступил партнёром и разработал для участников сценарий расследования инцидента в инфраструктуре крупной компании — Bravera Capital. Задача была не в том, чтобы придумать очередной CTF-квест, а в том, чтобы воспроизвести процесс расследования реальной атаки так, как он выглядит в корпоративной среде.
Часто в CTF-соревнованиях задания бывают оторваны от реальности: стеганография в картинках с котиками или бинарная эксплуатация древних сервисов, которые не встретишь в дикой природе. CyberCamp, напротив, строится на кейсах из повседневной практики ИБ.
Создавая задание для CyberCamp 2025 мы ставили цель смоделировать максимально реалистичный kill chain современной APT-группировки или оператора RaaS (Ransomware-as-a-Service). Нам было важно, чтобы участники прочувствовали ту самую «боль» настоящего Incident Response.
В этой статье разберём «кухню» сценария: почему выбрали связку Confluence + Veeam, зачем переименовывали бинарники и почему именно LockBit стал финальным аккордом. А также предложим варианты выявления подобных атак.
Два года российские нейрохирурги отказывали мне в операции, запугивая последствиями. В итоге поехал в Казахстан — сделали две паллидотомии, которые «нельзя было делать». Речь на месте, здоровье улучшается. Параллельно учу C++ и ищу работу. История о том, как не сдаваться, когда система говорит «нет».
Утро, 10:30. Вы чувствуете себя богом архитектуры. Видите систему насквозь: данные элегантно перетекают между микросервисами, в голове строится граф зависимостей, руки готовы рефакторить легаси-ядро. Ваш IQ, кажется, пробил потолок.
День, 14:30. Вы смотрите в IDE. Открыт метод на 10 строк. Читаете его пятый раз и физически не можете понять, что он делает. В голове белый шум и вязкое ощущение торможения. Вы идете за третьим кофе, пытаясь понять: "Неужели я деградирую?", "Почему я соображаю так медленно?".
Спойлер: дело не в возрасте и не в компетенции. Это просто Троттлинг (Throttling). Есть предположение, что срабатывает защитный механизм человеческого "железа", который принудительно снижает тактовую частоту, чтобы процессор не сгорел от перегрева. А виновата в этом архитектурная особенность, которую в Computer Science называют Context Switching (Переключение контекста).
Все слышали про эссе Пола Грэма "Maker's Schedule, Manager's Schedule". Но сейчас не про тайм-менеджмент. Нас интересует физика процесса, биохимия этого "перегрева". Давайте посчитаем стоимость прерывания в тактах процессора и поймем, почему попытка запустить на нашем однопоточном легаси одновременно тяжелые вычисления и архитектуру Event Loop гарантированно приводит к падению производительности.
DevOps давно перестал быть просто набором инструментов или должностью, в которой достаточно знать только Docker. DevOps стал целой культурой, интегрирующей разработку и эксплуатацию, автоматизацию, мониторинг, качество и скорость поставки изменений. К 2026 году DevOps глубже сливается с платформенной инженерией, SRE-подходами и архитектурой облаков. Соответственно, требования к инженерам растут.
Что ожидают от DevOps-специалистов в 2026 году, какие навыки становятся важными и как построить карьеру от начинающего инженера к платформенному, — объясняем в статье.
Всем привет, я Саша, инженер по тестированию ПО в Directum. Неотъемлемая часть моей работы — поиск слабых мест, недочетов системы. Фокус на недостатках оставляет отпечаток на образе мысли, взгляде. Работа требует внимания к деталям, определенного перфекционизма.
Наша айтишная реальность меняется и эволюционирует. Каждый день мы улучшаем не только процессы заказчиков, но и психологическую атмосферу в коллективе. Однако, несмотря на все блага, у этого процесса есть обратная сторона: стереотипы и ярлыки, один из которых — токсичность.
Сегодня я подготовила для вас подробный и откровенный разбор резюме.
Он будет особенно полезен тем, кто работает в сфере продаж или управляет командами.
Ко мне пришел запрос: «Посмотрите, пожалуйста, резюме руководителя отдела продаж. Что исправить, чтобы оно привлекало рекрутеров?»
Кто если не я – разберет всё подробно с объяснениями, примерами и рекомендациями.
Все ошибки в резюме повторяются у 80% кандидатов. Меняются только детали, главное обратить на них внимание и исправить.
Я нанимающий менеджер в IT уже больше 5 лет. Собирал backend, frontend, QA, devops-команды для больших и маленьких компаний. Работал и в стартапах, и в кровавых энтерпрайзах, провёл сотни техинтервью — но так плохо с наймом не было никогда.
Хочу просто покричать в пустоту интернета о том, что происходит, и, возможно, кто-то это услышит, а может даже отзовётся.
Кризис в IT длится уже несколько лет — это нормально. Компании оптимизируются и трансформируются (увольнять людей — самый быстрый и дешёвый способ оптимизации), деньги заканчиваются, проекты закрываются, людей на рынке становится всё больше. Плюс добавился AI головного мозга.
Поиск работы растягивается: откликов на вакансии уже не десятки, а сотни. Разбирать их становится невозможно, отсюда и появляются странные решения и сомнительные практики.
Некоторым людям нравятся собеседования с написанием кода. Я к их числу не отношусь.
Недавно мне на LinkedIn попался пост такого содержания:
"Мы задаём каждому соискателю тривиальную задачу на программирование. Что-нибудь вроде: «Дан список чисел, нужно вернуть сумму чётных из них». И такая задача не предполагается как сложная или заумная, и её цель не в том, чтобы кого-то отсеять, теоретически.
Это лишь базовая проверка. Разработчик или SRE с опытом от 6 до 10 лет должен решать такие во сне, согласитесь?
Оказывается, нет.
Где-то 75% кандидатов не справляются. И не только джуниоры. Я говорю о людях с приставкой «Senior» в их квалификации. О людях, которые заявляют, что учат новичков. О тех, кто говорит, что имеет за плечами годы опыта в продакшене.
Для меня это загадка".
Поначалу звучит абсурдно. С чего бы вдруг старший разработчик, который уже много лет пишет код, провалился на таком простом алгоритме? Неужели он внезапно забыл, как программировать? Возможно. Но я вижу это иначе.
Привет, читатель!
В рамках 2025 года мне довелось выступать как в качестве нанимателя в сфере ИТ, так и в качестве соискателя.
В данной статье хочу поделиться опытом и немного порассуждать о рынке, понаблюдав его с обеих сторон. Также хочу увидеть и Ваши мнения, опыт в комментариях.
Статью нацеливаю как на представителей ИТ комьюнити и HR, так и на простого читателя из других профессий.
