Ян Чикнизов, Гриша Скобелев: Публичное собеседование Engineering Manager
ฝัง
- เผยแพร่เมื่อ 23 ส.ค. 2024
- #engineeringmanagement #softwareengineer #agile #scrum #scrummaster #systemdesign #planning
Публичное собеседование на Engineering Manager. Будут вопросы по целеполаганию, agile/scrum, people managment (как проводить собеседования, 1-1, ИПР, работа с мотивацией). Также будут вопросы про архитектуру и будем проектировать дейтинг приложение.
Проводить собес будет невероятно крутой Ян Чикнизов 🔥 Ян прошел путь от разработчика до Engineering manager в международной компании. Занимается созданием и развитием масштабных, высоконагруженных систем, которыми ежемесячно пользуются более 50 миллионов человек. Активно участвует в качестве спикера и члена программного комитета на ведущих it конференциях
А проходить собес будет - Гриша Скобелев, Java/Go Techlead и хост книжного клуба { между скобок }.
Канал с анонсами t.me/megdu_skobok
Ламповый чат t.me/backend_m...
Boosty boosty.to/megd...
Полезные ссылки
- Книга "Мама, я тимлид! Практические советы по руководству IT-командой"
- Книга "Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо"
- Подборка книг для тимлида www.livelib.ru...
- Книга «Как пасти котов. Наставление для программистов, руководящих другими программистами», Ханк Рейнвотер
- Книга "Проект феникс"
- Книга "Цель. Процесс непрерывного совершенствования"
- Совет от Яна "Пройти сертификацию PSM/Project srum master"
Полезные ссылки
- Поддержите наш проект на Boosty boosty.to/megdu_skobok
- Канал с анонсами t.me/megdu_skobok
- Ламповый чат t.me/backend_megdu_skobkah
- Книга "Мама, я тимлид! Практические советы по руководству IT-командой"
- Книга "Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо"
- Подборка книг для тимлида www.livelib.ru/selection/2436973-luchshee-dlya-team-lead
- Книга «Как пасти котов. Наставление для программистов, руководящих другими программистами», Ханк Рейнвотер
- Книга "Проект феникс"
- Книга "Цель. Процесс непрерывного совершенствования"
- Совет от Яна "Пройти сертификацию PSM/Project srum master"
Досмотрел до половины, интересно слушать, редко что то подобное встретить на просторах ютуба, обязательно досмотрю, как говорит Гриша, плюсую))
Поржал, когда начался разговор о навешивании дополнительных обязанностей на сотрудников без предложения каких-либо бонусов. Эффективный менеджмент как он есть:)))
Очень интересно, спасибо за интервью. У меня был опыт, когда компания уходиоа из РФ. Но дела нужно было передать, иаски делать и тд. И нам предложили следующую схему. 2 зп выплачивают по-любому, но если перформишь до конца, передаешь все дела корректно и тд, то выплату получаешь совсем другую. Это сработало.
спасибо, познавательно. Ооочень поверхностные знания у Гриши ..
Спасибо за интересное интервью!
Применительно к БигТеху и FAANG компаниям, комментарии Яна обоснованы. Однако, если мы говорим про небольшие стартапы или компании на начальной стадии своей эволюции, то часть из общепринятых best practices или вообще не применимы к ним, либо зачастую даже вредны.
Расскажите, мне про полугодовое планирование, на той стадии, когда мы ищем product market fit, и прохеджированы в плане инвестиций не больше чем на ближайший квартал.
Гриша, Ян, спасибо за интервью!
Вопрос такой: Спринт имеет длительность в днях/неделях, задачи оцениваются в story point.
Да я услышал что эмпирически подбирается сколько же story point влезает в спринт, но имеет ли это смысл?
Какое преимущество (если оно вообще существует) дает оценка задач в story point по сравнению оценкой в человеко-дня/часах?
Когда мы оцениваем в стори поинтах, мы отходим от концепции измерения времени и приходим к концепции измерения сложность/не определенности задачи. Количество перерабатываемых сторипоинтов у каждой команды разное, а количество человекочасов всегда одинаковое)
мы не смогли бы провести 3 собеса, тк оно бы заняло 3 часа, тем временем виде 2:40 =))
"По спринтам живете? У вас Agile?" - сильно странный вопрос. Какая связь? Scrum - самое ущербное что есть в Agile вообще. Подходит исключительно для разработки нового в идеальных условиях.
Команда на 30 человек - нефункциональна. Надо бить по 10 хотябы и работать с ними раздельно