Холивары о собеседованиях

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

Так вот, расскажите в комментариях, а как все-таки правильно нанимать людей!

Подход к онбордингу джунов

Когда New Relic выросли до 60 команд, они решили активнее нанимать джунов. Вот как у них выглядел онбординг:

1️⃣ Первые две недели джун работает со специально подготовленным проектом, на котором он знакомится с инфрой, процессами разработки и командными практиками.
2️⃣ Каждому джуну назначается ментор.
3️⃣ Следующим этапом джун проходит ротацию между несколькими настоящими командами. В каждой из них он находится несколько недель и работает над настоящими задачами.
4️⃣ Джуна активно подключают к общению с разными коллегами, чтобы он набрал побольше информации о том, как работает компания.
5️⃣ После нескольких ротаций, джун привязывается к команде на постоянной основе.

Фишинговые письма для проверки поведения людей

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

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

Реклама. Рекламодатель: ООО «ВК ЦИФРОВЫЕ ТЕХНОЛОГИИ». ИНН 7714415613. Erid: 2VtzqvHAgGg

🧬 Вебинар-дискуссия «Безопасность на уровне кода: как эту задачу помогает решать облако». Продолжение серии мероприятий от VK Cloud и «Лаборатории Касперского»

⏰ Когда: 21 сентября, 17:00
📍 Регистрация

Участники первого вебинара из серии «Безопасная разработка в облаке» обсуждали ИТ-ландшафт с фокусом на безопасность и специфику рынка РФ после 2022 года.

На второй встрече вы узнаете, как с помощью практик безопасной разработки снизить риски, сохранив при этом скорость выпуска новых релизов. Главный фокус вебинара — безопасность на уровне кода.

В программе:
🔸 наиболее распространенные угрозы для приложений и какие из них актуальны, например OWASP;
🔸 принципы безопасной разработки и подходы к архитектуре;
🔸 инструменты обеспечения безопасности на уровне кода: SDLC, SAST, DAST и другие;
🔸 что влияет на безопасность: логирование, мониторинг, трейсинг и OpenTelemetry;
🔸 облачные инструменты обеспечения безопасности кода.

Участники дискуссии:
🔹 Роман Ермаков, продуктовый менеджер, VK Cloud
🔹 Алексей Рыбалко, эксперт по кибербезопасности, «Лаборатория Касперского»
🔹 Илья Сидельников, начальник отдела автоматизированного анализа безопасности, VK

Вебинар будет полезен разработчикам и тимлидам команд разработки, DevOps и DevSecOps, руководителям и специалистам по ИБ, техническим и ИТ-директорам.

Зарегистрироваться

Фидбэком не решить проблему недостатка скиллов

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

Проблемы, попадающие в первую категорию, часто можно исправить быстрым фидбэком и синхронизацией ожиданий. А вот со второй категорией все сложно. Если сотруднику не хватает каких-то корных навыков для того, чтобы хорошо выполнять свою работу, бессмысленно думать, что после получения фидбэка или какого-нибудь performance improvement plan, он за месяц получит скиллы, которые не смог получить за последние годы своего опыта.

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

Как вести смоллтолки

Если вас, как и меня, ставит в тупик вопрос "How are you?", заданный в начале созвона, или, еще хуже, вы не понимаете, насколько детально нужно описывать погоду за окном, чтобы сойти за своего, это идеальный пост для обучения культуре смоллтолков.

Ключевые идеи:

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

Do your one job first

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

Пипл-менеджмент сложных инженеров

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

Смерть от тысячи микросервисов

В подавляющем большинстве случаев микросервисы принесут вам намного больше проблем в долгосроке, чем пользы в краткосроке. Думаю, вы уже и сами видите, что хайп на микросервисы довольно сильно упал, и некоторые компании, которые смогли его пережить и не загнуться от счетов от AWS, уже пытаются собрать свои монолиты по кусочкам обратно. Самые смешные примеры – это, конечно, Uber, которые были евангелистами микросервисов много лет, и Amazon Prime, хотя казалось бы.

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

На глазок как методика оценки сроков

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

Чтобы такой подход сработал, важно соблюдать несколько правил:

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

Авито ищет сразу трёх тимлидов в разные команды. Ныряйте вниз за подробностями.

➡️ Тимлид разработки в команду маркетплейса
➡️ Тимлид разработки в команду «Запчасти и аксессуары»
➡️ Тимлид разработки в команду Data Quality

ЗП обсуждается с кандидатами лично, но вот что предлагают прямо сейчас:
• Талантливая команда и возможность реализовать свои идеи в проекте с многомиллионной аудиторией;
• Мощное железо, дополнительные мониторы и всё, что нужно для комфортной работы;
• Прозрачная система премий;
• Личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
• ДМС со стоматологией с первого дня;
• Замечательный офис в двух минутах от «Белорусской»: панорамный вид на центр города, места для уединённой работы и зоны отдыха.

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

Вакансия Team lead на Go от Ozon Tech

Команда rFBS Ozon Tech развивает формат взаимодействия Ozon с продавцами, при котором они сами хранят, формируют и доставляют заказы. А Ozon работает как витрина с десятками миллионов лояльных клиентов. Компания хочет порадовать пользователей новыми фичами уже в этом сезоне распродаж.

Чтобы достичь амбициозных целей, Ozon формирует новые команды. Сейчас они в поисках тимлида с опытом разработки на Go.

Их проект — это:
— Работа в одной из самых быстрорастущих вертикалей Ozon,
— Высокие нагрузки до 300k rps,
— Архитектурные вызовы в контексте масштабируемости сервисов,
— Быстрый time-to-market,
— Возможность работать из офисов России и Казахстана / удалённо / гибридно.

Стек: Golang, PostgreSQL, Kafka, gRPC.

Узнать подробности о проекте, вакансии, бенефитах и откликнуться можно на этом лендинге.

Техническая стратегия

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

Техническая стратегия – хороший инструмент для того, чтобы снять часть такой неопределенности. Автор статьи использует фреймворк из книги Good Strategy, Bad Strategy, но прикладывает его именно к специфическому кейсу инженерной стратегии. Если кратко, то ее структура такая:

🕵️‍♀️Диагноз – теория, объясняющая проблему, которую стратегия хочет решить.
👉Направляющая политика – набор принципов и трейдоффов, которые помогают двигаться к решению проблемы.
🗺️Согласованный план – конкретные шаги по решению проблемы, соответствующие направляющей политике.

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

Как руководителю не растерять технические навыки

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

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

Обновление роадмапа для продактов

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

Как и зачем менеджеру строить команду из своих пиров

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

Один из способов выйти из такого состояния – построить команду менеджеров-пиров (на русском языке звучит по-дурацки, но хорошего аналога не придумал). Например, из руководителей отделов, которые находятся напрямую под СТО. Эта команда должна быть сосредоточена на анализе общей картины происходящего в компании и на поиске решений для общих проблем. Вот какие плюсы можно получить:

👉Не нужно ожидать вмешательства или воли СТО для того, чтобы в компании происходили полезные изменения.
👉Улучшается обмен знаниями о лучших практиках, меньше делается велосипедов.
👉Менеджерам проще учиться друг у друга.

Как планировать рост размера команды

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

Топ-менеджер: что нужно руководителю в 2023

Руководить командой в турбулентное время, выводить бизнес на новый уровень и оставаться мотивационной моделью — та еще задача.

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

Все эти навыки можно прокачать на курсе «Эффективный руководитель» от ProductStar (группа компаний РБК).
Каждому студенту курса доступен индивидуальный план карьерного развития на шесть месяцев и поддержка ментора.

По промокоду ТОП55 действует скидка 55% и курс по Бизнес-английскому от AgileFluent в подарок.

Забронируй скидку:
https://go.productstar.ru/kh5nF6

Что делать, когда сотрудник просит прибавку

Стандартные ошибки, которве можно допустить:

❌Ответить "да" или "нет", не подумав как следует.
❌Отказать, не объясняя причин.
❌Пообещать изменить зарплату, а потом не сделать это по любой причине.
❌Избегать прямого ответа на протяжении долгого времени.
❌Формировать ложные ожидания о прекрасном будущем, если ты знаешь, что оно маловероятно.

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

💬Расскажите в комментариях про то, какие фейлы, связанные с обсуждением повышения зарплаты, были у вас!

Простой подход к приоритизации по cost of delay

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

1️⃣Выпишите на стикеры все инициативы, которые есть в бэклоге.
2️⃣Отсортируйте их по срочности вдоль горизонтальной шкалы. В этот момент вообще не надо думать о важности задачи, а сосредоточиться именно на том, насколько срочно ее надо сделать. По результату разбить всю шкалу на три сектора: Whenever, Soon и ASAP.
3️⃣Теперь отсортировать карточки по важности, уже вдоль вертикальной оси. Срочность остается фиксированной, менять ее нельзя. По результату собрать три категории: Tweak, Optimizer, Game Changer.
4️⃣По итогам предыдущих шагов у вас получилась матрица 3х3. Внутри каждой клетки выделите три сектора – 1-3 месяца, 1-3 квартала, 1-3 года. Подвигайте стикеры между ними, прикинув трудозатраты на каждую инициативу.
5️⃣Как результат, вы получили отсортированный по cost of delay бэклог. Посмотрите картинку к посту – зеленые секторы самые приоритетные, желтые – средненько, а на красные можно забить.

Мне понравился этот способ тем, что оценка каждого из параметров приоритизации по отдельности позволяет быть более объективными, и не выдавать срочность за важность.