Управление персоналом *

Привет! Меня зовут Женя Авдеев, я менеджер проектов в IT-департаменте Финама. Если ты студент техвуза и хочешь не просто «летнюю практику ради галочки», а реальный опыт в айти-команде — читай дальше.

Константин Шибков (на Хабре sendelust)  —  эксперт Skillbox и Java-разработчик, который искренне любит собеседования. Не только проходить их сам, но и обсуждать чужие. Он расспрашивает знакомых, какие им попались задачи, а потом разбирает их вместе с участниками своего алгоритмического клуба JavaKeyFrame. Ведёт телеграм-канал «Три монитора», где делится личным опытом. Мы поговорили с Константином о том, почему техническое интервью — это не пытка, а интеллектуальное удовольствие, как проводить собесы по-человечески, зачем нужны задачки «на подумать» и почему иногда лучше не отвечать сходу, а сначала задать встречный вопрос.

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

— Ну, это всегда какой-то челлендж. Есть элемент соревнования: сможешь ли ты решить задачу, пройдёшь ли ты интервью. Это не про поиск работы. Мне интересно просто попробовать — а вот возьмут ли, а что там спросят. Иногда задачи попадаются нестандартные, и сам подход к ним бывает необычный. Это своего рода хобби — не то чтобы серьёзное, но точно увлекает.

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

— Честно говоря, чего-то супернеобычного, наверное, не вспомню. Больше всего удивляет, когда... вообще ничего нет. Вот человек рассказывает: «Пришёл на собес, они такие — пойдём пообедаем. Сходили в кафешку, поболтали». И всё. Никаких задач, ничего. Вот это реально выбивает.

А вот когда дают задачи сложные или вообще непонятные, зачем они нужны — это уже другое удивление. Такое, скорее, отрицательное. Типа: «Ну и зачем это всё было? Зачем я сюда пришёл? Какой в этом смысл?» Такое чувство пустой траты времени.

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

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

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

Почему в современном менеджменте столько глупости? Почему руководители принимают идиотские решения, верят в переработки, садистское отношение к сотрудникам и не умеют думать на 2 шага вперёд?

В прошлый раз мы разобрали, какие различные исторические явления, религия и рабовладение обеспечили массовое распространение корпоративной шизы.

В этот раз рассмотрим, как создающие системы инженеры сменились на сиюминутных барыг.

Привет, Хабр! Мы в Рунити верим, что собеседование — не гонка за правильными ответами, а диалог на равных. В этом интервью расскажем, как мы нанимаем DevOps-инженеров в команду. Внутри о том, что мы предлагаем кандидатам вместо стресс-интервью, замысловатых тестовых и бесконечных этапов отбора. От нас — внимание к глубине опыта и интерес к подходам кандидата. 

Эксперты Рунити — Анна Попова, рекрутмент-партнер, и Тимур Парфенов, директор департамента эксплуатации, поделятся тем, как мы оцениваем инженеров, на что смотрим в резюме и какие навыки стоит подсветить. Приятного «разворачивания» статьи! 

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

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

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

Если вы уже в команде, будь вы Middle или Senior разработчик — значит, ваши технические навыки уже на уровне. Они проверены и подтверждены на этапе найма или в процессе работы. Люди без подтвержденных хардов просто не попадают в продуктовые команды. 

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

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

Привет! Я Саша, продакт системы управления проектами YouGile. Хочу рассказать, как мы сделали голосовые сообщения в нашем внутреннем мессенджере удобными даже для тех, кто их ненавидит. Причем быстро, дешево и с помощью доступных всем инструментов — если захотите, сможете повторить (наверное).

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

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

Привет, Хабр! Я Никита Иванов, техлид команды «Видео» в KION. В ИТ я уже девять лет, а последние пять работаю с Go. Сегодня расскажу, какую задачу считаю идеальной для собеседования на позицию Go-разработчика. Этот текст — переработка моего доклада с митапа МТС True Tech Go, видеоверсию можно посмотреть тут.

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

Меня зовут Вера Кокотова, я руководитель группы технических архитекторов 1С в компании КРОК. Устроилась в компанию 11 лет назад начинающим разработчиком и прошла большой увлекательный путь до эксперта по технологическим вопросам. Кроме того, последние пять лет я активно участвую в найме технических специалистов. 

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

Минцифры кричит о нехватке миллиона IT-специалистов, министр труда и социальной защиты заявляет о «всего» ста тысячах. Параллельно рынок труда захлестнула волна сокращений. А тут ещё и слухи об AGI — суперумном ИИ, который захватит все рабочие места. Парадокс? Нет, скорее болезненная трансформация от иллюзий к реальности. 

На связи CEO Surf Владимир Макеев. Я в разработке с 2011 года, почти с самых истоков развития мобильных приложений в РФ. Сегодня поделюсь своим взглядом на то, как накопленный кризис управленческих иллюзий повлиял на IT-сферу и почему за последний год уволили так много специалистов. И как на ситуацию влияет развитие ИИ, который может заменить разработчиков.

Привет! На связи Евгений Антонов. Я работаю ведущим техническим менеджером проектов в Yandex Infrastructure. А также руковожу парой команд (разработчиков и менеджеров) и факультативно занимаюсь IT‑консалтингом. Ещё я автор телеграм‑канала «Тимлид Очевидность» и ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

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

Как вы, возможно, догадались по названию, речь пойдёт о многозадачности.

Если загуглить «Бирюзовые компании в РФ», первые вкладки будут мало чем отличаться друг от друга по содержанию, в том числе и по списку компаний. Все дело в том, что такое словосочетание не то что в России, в мире возникло относительно недавно. Его предложил Фредерик Лалу в своей книге «Открывая организации будущего» в 2014 году, обобщив уже тогда имеющиеся кейсы «дебюрократизации» в менеджменте на западе. Это при том, что модный сегодня «тойотовский» Kanban на 10 лет старше полета на Луну.

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

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

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

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. Публикую перевод интересной статьи для техлидов от технического консультанта Авива Бен-Йосефа, автора книги The Tech Executive Operating System.

«У нас никто никогда не сдаётся!» «Посмотрите, какой хакатон мы провели!» «Мы жёстко закладываем время на борьбу с техдолгом».

На первый взгляд — правильные и вдохновляющие лозунги. Но на деле это просто рекомендации, которым имеет смысл следовать… если вы хотите управлять посредственной командой.

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

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

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

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

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

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