Карьера в IT-индустрии

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

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

Это схема, которая описывает типы объектов в вашей системе и возможные отношения между пользователями и этими объектами (ролями, функциями защиты и привилегиями).

Классическая ситуация:

«Я данные отправил!»

«А я не получил!»

«А они зависли где-то, потому что формат не тот!»

Пример из практики: комплексный проект по рефакторингу системы управления доступами. Интеграция приложения по управлению доступами на основе ролей и привилегий (это наша Новая система) с другими информационными системами (ИС) в контуре предприятия (например, управление учетными записями, авторизация пользователей и прочие).

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

В Яндекс Практикуме прошёл вебинар «Разбор резюме и собеседования бизнес-аналитика и аналитика данных» — эксперты и работодатели проводили мок-интервью и разбирали резюме выпускников. Делимся самым важным.

Disclaimer: Я разрабатываю платформу для создания рабочих инструкций и он-бординга новых сотрудников, поэтому регулярно общаюсь с HR‑специалистами и руководителями о проблемах адаптации. Для этой статьи провел дополнительные интервью с HR‑директором компании с опытом массового найма (500-1500 человек в год) и специалистом по адаптации из крупного ритейла. Имена изменены по их просьбе.

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

В пятницу она приходит к директору: "Я увольняюсь. Это не мое."

Директор в шоке. Три месяца искали кандидата, месяц обучали, вложили ресурсы. Показатели были нормальными. Что пошло не так?

А вот Екатерина уходит с чувством, что некомпетентна. При этом объективно она справлялась.

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

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

Cегодня поговорим о, наверное, самом серьезном этапе собеседования — live‑coding. На этом этапе вас просят писать код в реальном времени, под пристальным взглядом интервьюера.

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

Привет, Хабр. Меня зовут Алексей Бруевич, и я руковожу продуктовой разработкой Почты Mail. Хочу поделиться своим опытом и наблюдениями о том, с какими барьерами сталкиваются руководители в рамках своей работы. Я управляю командами уже больше 7 лет, и за это время собрал большой опыт и «зоопарк» проблем руководителей, когда заходит вопрос о развитии команды. Считаю, что материал будет полезен всем, кто задумывается о развитии команды и себя. 

Хочу поговорить о парадоксе, в который мы сами себя загоняем: мы не верим в осуществимость своих желаний только потому, что считаем невозможным договориться с человеком, от которого зависит их осуществление. Самый главный баг, который мы часто не чиним, — это наше собственное убеждение в том, что «договориться невозможно». Исправление этого бага открывает дорогу для реализации всех остальных идей.
Весь наш опыт убеждает н��с в том, что в некоторых ситуациях попытка открыто обсудить вопрос с высокой вероятностью приведет к проблеме: когда мы вынуждены проявить несогласие или ожидаем несогласие от другого, то есть риск испортить отношения, проиграть, оказаться виновным / неправым, потерять лицо, впустую потратить время и т.д. Поэтому мы либо избегаем обсуждения — ведь «оно бесполезно», «будет только хуже», «ему/ей всё равно ничего не объяснишь». Либо (если чувствуем в себе силы — а у нас их часто бывает хоть отбавляй, если мы уверены в своей правоте) мы бросаемся в бой. Обе этих реакции естественны для нас, так как мы не чувствуем себя в безопасности.

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

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

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

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

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

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

На связи команда курса «Архитектура программного обеспечения» в Яндекс Практикуме. В этом материале мы расскажем, как ответили на запрос рынка и разработчиков и стали готовить инженеров в области архитектуры ПО, а также какие изменения внесли в курс совсем недавно.

Прохладное утро... Щелчок... Зажигалка подносится ко рту, где своей очереди ждет сигарета.

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

У каждого из нас есть события, которые становятся триггерами нашего взросления

Разбираю оптимальный путь в NLP: какие темы не нужны, что важно выучить, и как за 6 месяцев выйти на уровень Middle. Внутри — ошибки обучения, приоритеты и подробный роадмап с вопросами для самопроверки.

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

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

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

На одной из предыдущих работ нужно было собрать свои достижения в области кибербеза. У меня были различные найденные уязвимости. Но, я даже не знал: были ли им присвоены CVE? Я этим не занимался. Занимались ли вендоры - не в курсе. Тогда я вспомнил ситуацию с выявлением мной уязвимости в антивирусе Agnitum и взгрустнул: CVE не был зарегистрирован. Год назад я вспомнил эту историю и задумался: а можно ли оформить CVE сейчас, спустя 12 лет после обнаружения уязвимости? Ситуация осложнялась тем, что вендора уже много лет как нет. И его сайта, конечно, тоже. Но, раз вы читаете этот текст - то мне это удалось (за этот кейс я попал в топ-10 Pentest award 2025 - номинация "Раз bypass, два bypass"). Но, путь занял почти год. И вот как это было (спойлер: помог сервис WayBack).

Перед тем, как понять, какие вопросы задавать, надо понять, нафига мы их вообще задаем.

Типичный аргумент: «надо что‑то спросить, а то они решат, что я — немотивированная тухлая капуста». В общем, для работодателя аргумент валидный: если человеку настолько ничего неинтересно, что даже чувство самосохранения не просыпается и нет страха устроиться в совсем неподходящее место, у нас проблема. Лучше найти кого‑то, кто еще не настолько мертв внутри.

Но когда люди задают вопросы лишь бы задать, они начинают спрашивать бестолковую ерунду, например: «в какой тулзе ведете задачи?». Шансов, что там будет что‑то, что не джира (или, на худой конец, трелло) слишком мало, и нет смысла тратить на это время.

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

Фича может ехать в прод квартал силами шести человек — или за две недели одним разработчиком. Разбираю, почему один дорогой автономный инженер часто выгоднее команды «дешёвых».

Привет! Меня зовут Аня, я работаю системным аналитиком в InfoWatch на продукте Device Monitor. Это система контроля утечек информации на рабочих станциях, позволяющая организации контролировать и блокировать вынос конфиденциальных данных за пределы ее безопасного контура.

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

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

Disclaimer — ещё разок отмечу, что речь именно о вредных советах, а не о руководстве к действию. Более того, в описании хороших практик в конце статьи тоже есть нюансы, и не всё так однозначно, так что приглашаю всех заинтересованных в комменты, подискутировать.

Вредные советы

#1 Аналитик — он и в Африке аналитик

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

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

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

За последние несколько месяцев ко мне в разное время обратились три или четыре человека с просьбой порекомендовать им что-нибудь, чтобы "нау��иться прогать". Особенность всех из них - наличие неплохого базового образование, общее понимание многих концепций, но лишь на теоретическом уровне. Короче, все так, как было у меня в свое время. Ответив им несколько раз примерно одно и то же в телеграме, я понял, что все это можно написать один раз, выложить в публичный доступ и расшаривать. Так и родилась идея этой статьи.

Привет, Хабр. Это дайджест по сетям и кибербезопасности: от DevSecOps и защиты Kubernetes до пентеста, SOC, SIEM и дизайна сетей ЦОД. Мы собрали открытые уроки и курсы, которые помогают не просто «держать инфраструктуру в зелёном», а проектировать её с учётом современных угроз, требований регуляторов и реальных атак. Если вы отвечаете за устойчивость сервисов, безопасность данных или развитие корпоративной инфраструктуры — здесь можно точечно закрыть пробелы в навыках или выстроить для себя системный маршрут обучения.