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

Вторая часть нашего слесарно‑айтишного балета будет с элементами 18+, поэтому уберите от экранов джунов.

Сегодня в попытках «Выйти из АйТи» мы посетим пару собеседований, проведём оценку компаний по косвенным, но важным моментам взаимодействия с human resources, и получим оффер в очень интересном месте...

Раньше мой вечер выглядел так: 15 вкладок с туториалами, ещё 10 с обсуждениями на стэке и вопрос в голове: «а зачем я вообще согласился на эту жесть».

Решил месяц потестить нейросети, чтобы хоть как-то себя разгрузить. В итоге собрал 15 простых и полезных промптов, которые могут помочь сэкономить время на ресёрче и вернуть силы на всё остальное.

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

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

Наши варианты: специалисты выгорают (или нет) и хотят пробовать что-то новое, специалисты хотят расти в квалификации или узнать новые навыки, специалисты просто хотят больше зарабатывать.

А еще мы поняли, что для тех, кто уже в профессии, всё это — не обязательно повод увольняться и идти искать себя заново. Гораздо менее стрессовая опция в таком случае — переход внутри компании на другое направление, и чаще всего из не IT — в IT. 

Для этой статьи мы опросили наших коллег из Хабра, которые меняли специализацию, не меняя компанию, и переходили в IT, ну или просто кардинально меняли и сферу, и компанию.

Привет! Меня зовут Ксюша Бердникова, я исследователь в Контур.Удостоверяющий Центр. Меня очень вдохновляет наставничество и системный подход к нему, поэтому в статье хочу обсудить: какие шаги, привычки и приемы помогают выстроить эффективную систему наставничества и как наставнику сохранять фокус на своих задачах, не теряя баланс.

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

Есть два вопроса, которые задают на любом собеседовании:

1. Почему вы ушли с последнего места работы?
2. Почему вы хотите работать у нас?

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

Привет, Хабр! Меня зовут Лера, я технический писатель в Авито. Моя страсть — не только создавать продукты и синхронизировать команды, но и находить книги, которые помогают расти профессионально: разбираться в людях, выстраивать процессы и быть лидером, за которым хочется идти. Сегодня я делюсь с вами разбором бестселлера Джули Чжо «Из чего сделан менеджер, или Что предпринять, когда все смотрят на тебя?» — книги, которая стала настольной для тех, кто только стал менеджером или руководителем. Эта статья — выжимка ключевых идей, адаптированная для менеджеров и технических специалистов. Здесь вы найдете конкретные советы, примеры из IT-контекста и ответы на вопрос: «Как управлять так, чтобы команда росла, а вы не выгорали?».

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

Трансформация руководителя из «подавителя» в лидера требует глубокой внутренней работы, осознания проблемы и выхода из привычной устоявшейся среды обитания.

В данной статье будут рассмотрены: портрет руководителя Кирилла; цикл использование - подавление - слив сотрудника; результаты для Команды и Бизнеса; ключевые трансформации и мой личный опыт.

Портрет руководителя Кирилла

Кирилл – это обобщенный образ руководителя, препятствующего развитию нижестоящих сотрудников или не заинтересованный в развитии других граней личности сотрудника.

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

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

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

Сегодня я пришел с небольшими спойлерами из новой серии нашего подкаста «Скрамное ИТ». В свежем выпуске мы залезли в одну из самых неудобных тем — тот момент, когда задачи, которые еще вчера вдохновляли, вдруг начинают вызывать тоску, и когда возникает желание сделать CTRL+Z… в карьере. 

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

Обычно все начинается с мелочей. Сначала просто устаешь чуть быстрее. Потом замечаешь, что стал по-другому относиться к задачам. А однажды ловишь себя на мысли, что всерьез рассматриваешь вариант сменить карьерный трек. 

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

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

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

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

Подготовил для вас roadmap, что важно в 2025 году знать успешному DevOps-инженеру. Пригодится как джуну, так и спецу с опытом, чтобы валидировать свои навыки.

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

Вы «должны» проводить 1-on-1.
А зачем?

Знаете, зачем они нужны — по-настоящему?
Или пробовали, но всё свелось к «ну, как дела?»
Может быть, встречи идут — но ничего не меняется?

Что ж, давайте разбираться:

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

Дело в том, что в университетах и на курсах аналитики обычно учат хард-скиллам: как группировать и анализировать данные, как строить отчёты и делать из них выводы. Но никто не учит вести переговоры с заказчиком, грамотно оценивать риски и учитывать другие детали, которые напрямую влияют на репутацию аналитика.

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

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

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

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

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

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

Дисклеймер: в статье приведены скриншоты из моих личных переписок с разработчиками. Публикация таких переписок одной из сторон не требует согласия другой (согласно законодательства РФ).

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

Я буду рассказывать с прицелом на американский рынок, потому что готовлю IT менеджеров к работе в Штатах или с американскими компаниями, сама живу и работаю в Остине (Техас) и в курсе новостей и требований сообщества.  

Я собрала ресурсы, которые прошли проверку на bullshit, на соотношение времени/усилий к пользе и на актуальность ко всему, что происходит на рынке. 

Итак, если вы IT менеджер и собираетесь работать по-английски, то вам нужны ресурсы, которые подготовят вас

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

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

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

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

I. Видео с Mark Rose

Марк 20 лет проработал продаком в гугл, сейчас он консультирует стартапы. Его видео можно найти на нескольких платформах в Youtube, в том числе и у него на сайте в разделе Watch and Learn. Он человек своей среды: эксперт из Силиконовой Долины, но без токсичной позитивности и воды, плюс с большим опытом работы в Европе, в том числе в постсоветских странах. В частности, одним из клиентов его собственного стартапа в свое время были World of Tanks. Марк провел какое-то время в Минске и работал с командой. Во-первых, Марк дает отличные советы по прохождению всех этапов интервью. Во-вторых, обратите внимание, как он пользуется английским языком: на простоту словаря и при этом точность и гибкость формулировок.

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

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

За год изучения вопроса и погружения в тематику посмотрел большое количество текстов и видео. Если все эти материалы сжать в одну эмоцию, то это однозначно будет «страдание». Дизайнеры страдают… Недавно попалось видео в котором молодая дизайнерка рассказывала трагическую и поучительную историю своего трудоустройства, сравнимую по накалу страстей ни много ни мало с самим Гамлетом. Фабула: заказчики дураки, а я в белом пальто стою красивая. Ну, и конечно, не обошлось без советов космического масштаба и космической же глупости…

Высокая конкуренция — это всегда стресс, но это не значит, что действовать нужно наугад в надежде, что в итоге количество перейдет в качество… может не перейти. Про графический дизайн не берусь судить, но в дизайне интерфейсов, UX/UI главная задача — сделать удобно, понятно и эстетично. Ровно эти же требования предъявляются и к хорошему портфолио т.е. умелый UX/UI дизайнер вынужден подходить к своему портфолио «юиксово», но к сожалению так бывает далеко не всегда.

Я задумал написать серию небольших статей в жанре «что такое хорошо и что такое плохо» в отношении портфолио UX/UI дизайнера. Надеюсь, эти скромные труды хотя бы немного снизят градус страданий от отказов и игнора со стороны потенциальных работодателей.

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

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

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

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