Заметки тимлида // Канал Саши Шутай

Сегодня мой коллега спросил: «А тебе сложно увольнять?» Я ответил, что сам процесс увольнения — это напряженная ситуация для меня. Чтобы снизить накал, я готовлюсь к разговору: 1. Собираю фактуру: почему я решил расстаться с сотрудником. Невыполненные обещания, плохо реализованные задачи, сорванные KPI, результаты 360 опроса коллег и т. д. Это всё пригодится, чтобы аргументировать решение. 2. Увольнение не должно стать сюрпризом для сотрудника. Само решение зреет не один день. Поэтому я предварительно провожу с сотрудником встречи, рассказываю о своих ожиданиях и наших общих проблемах. К моменту увольнения человек обычно сам понимает, к чему всё идет. 3. Продумываю, какие компенсации мы готовы предложить. Если это вообще возможно. 4. Ищу способы помочь человеку с новой работой. Для этого можно поговорить с HR-специалистом. Возможно, навыки сотрудника пригодятся вашим партнерам. Можно подготовить рекомендательное письмо. Про саму встречу Я предпочитаю вести разговор по методу гамбургера. Суть проста: чередуем хорошую и плохую обратную связь. Так проще начать тяжелый разговор. К тому же сотрудник сразу понимает, что с ним начинают «говорить гамбургером» и интуитивно готовится к плохим новостям. Про критику Критика не должна быть десктруктивной. «Ты пишешь отвратительный код!» — это деструктивно, вызовет только агрессию. «Сделанное решение не оптимально. Сам понимаешь, его нужно перерабатывать, чтобы соответствовать всем требованиям», — это более конструктивно. Как закончить разговор Старайтесь закончить чем-нибудь хорошим: поблагодарите человека за труд, подбодрите. Расскажите, как вы можете помочь с поиском новой работы. Увольнение — редкое явление в компаниях с хорошей корпоративной структурой. Скоро расскажу, какие ошибки руководителя в работе со сложными сотрудниками приводят к расставанию.

Как стать тимлидом, или Что вас ждет по другую сторону разработки — часть 3 Часть 1 \ Часть 2 Тимлид — это в первую очередь про работу с людьми, планирование ресурсов и соответствие навыков команды потребностям бизнеса. Поэтому прямые обязанности тимлида — управлять кадрами, нанимать сотрудников, развивать их, мотивировать и иногда увольнять. Начнем с найма. Вы будете драйвить процесс поиска новых сотрудников, составлять профиль кандидата для HR и проводить собеседования. Если долго не можете найти хорошего специалиста Попробуйте доработать вакансию, добавить интересных современных технологий. Посмотрите, насколько предлагаемая зарплата соответствует рынку. Можно предложить руководству запустить реферальную программу или подключить к поиску кадровое агентство. Если нужно оптимизировать время на подбор Составьте вопросы для быстрого скоринга. Они должны быть связаны с техническими требованиями проекта. Эти вопросы рекрутер сразу задаст кандидату и сможет отсеять нерелевантных. Тогда до очного собеседования дойдут более подходящие. Я не очень доверяю первичному отсеву по резюме. Часто «звёздочки» не умеют рассказывать про свой крутой опыт, а мимокрокодилы приписывают себе лишнего. Тем временем по ответам на 5 вопросов уже можно что-то сказать о кандидате. Вы один, кандидатов много, работы тоже много, а времени мало. Поэтому техническое собеседование можно делегировать Senior-разработчику или техлиду. Расскажите им о требованиях, которые вы предъявляете, покажите список ключевых вопросов. Сами подключайтесь на повторку для опроса по софт-навыкам и мотивации, если этого требуют ваши процессы. В следующей части поговорим про онбординг.

Мой друг и напарник Даня Соловьев недавно написал статью про наше новое коробочное решение для создания карьерных сайтов. Это бекенд инструмент позволяющий быстро разработать брендированный HR портал с целью поиска сотрудников. Он имеет интеграции с Хантфлоу, HeadHunter, Superjob, Авито Работа, Хабр Карьера. Достаточно изменить описание вакансии в админке и апдейт произойдёт на всех площадках. Соответственно, все отклики с этих площадок аккумулируются в едином месте. Позволяет создавать лендинги под вакансии, подразделения и контентные страницы. Собирать аналитику по вакансиям, откликам, планировать стратегию найма. А главное это всё очень гибко: можно собрать свой дизайн, реализовать любую функциональность и внедрить свои идеи по продвижению HR бренда. Узнать больше про основные фичи: https://habr.com/ru/companies/agima/articles/772552/ Буду благодарен, если поднасыпете кармы 🙂 А если заинтересовало решение, то присоединяйтесь к нашему митапу https://hrmeetup.agima.ru/ Расскажем подробнее про коробку, продемонстрируем работу и покажем, как карьерные сайты упрощают труд рекрутеров, удешевляют поиск сотрудников и улучшают конверсию найма.

При проектировании приложений на микросервисной архитектуре приходится выбирать технологии для микросервисного взаимодействия. В последнее время стало модно использовать для этого GraphQL. GraphQL — это язык запросов для API, разработанный Facebook. С точки зрения нагрузки на сеть он эффективнее и гибче, чем традиционный REST API. Ключевая идея GraphQL в том, чтобы запрашивать только те данные, которые нужны, и получать их в едином запросе. В сравнении с REST, когда каждая точка API отдаёт определенный набор полей. Запрос GraphQL выглядит как структурированный JSON-объект, где указываются необходимые поля и вложенности. Например:

{ user(id: 123) { name email posts { title content } } }

Этот запрос запрашивает имя и электронную почту пользователя с ID 123, а также заголовки и содержание всех его постов. GraphQL также поддерживает мутации для изменения данных на сервере и подписки для реального времени. Чем он может быть полезен для SOA? GraphQL позволяет объединить запросы к разным микросервисам в один, что снижает количество запросов. Это особенно полезно в среде с большим числом микросервисов. Выглядит здорово, но всё ли так гладко и удобно? На самом деле этот язык запросов не является серебрянной пулей и порой привносит только холивары и проблемы. О них я расскажу в следующем посте.

При работе над сложными приложениям мы часто сталкиваемся с необходимостью буферизации данных и асинхронного взаимодействия между разными компонентами. Например, вы приняли много заказов на сайта и должны их передать во внешний сервис. Он имеет свою доступность, нагрузку и мало от вас зависит. Если сразу после получения заказа вы одной попыткой синхронно отправите его в сервис, есть риск, что из-за высокой нагрузки или сетевых проблем заказ не будет передан. Чтобы этого избежать, можно внедрить асинхронное межсервисное взаимодействие. Когда заказ получен, он попадает в очередь. Фоновый скрипт разбирает очередь из заказов и пересылает их в сервис. Если при отправке заказа возникли проблемы, он никуда не теряется и снова попадает в очередь. Это только один из маленьких примеров, когда в разработке требуются брокеры очередей. Брокеры очередей — это программное решение, которое используют для асинхронного взаимодействия между компонентами приложения или между разными приложениями. Брокеры обеспечивают надежную доставку сообщений и буферизацию данных в случае временных сбоев. Существует несколько видов брокеров очередей: ✔️ Очереди сообщений. Этот вид брокера очередей нужен для передачи сообщений от отправителя к получателю. Сообщения помещаются в очередь отправителем и извлекаются получателем. При этом брокер управляет доставкой и обработкой сообщений в нужном порядке. Примеры таких брокеров: Apache Kafka, RabbitMQ и Apache ActiveMQ. ✔️ Очереди событий. Этот тип брокера очередей используется для обработки событий и уведомлений. События могут быть отправлены нескольким получателям, которые могут подписаться на интересующие их события. Примеры брокеров событий: Apache Kafka, Amazon SNS (Simple Notification Service) и Google Cloud Pub/Sub. ✔️ Очереди запросов-ответов. Этот вид брокера очередей позволяет отправителю отправить запрос, а получателю ответить на него. Очередь служит для управления запросами и ответами, гарантируя соответствие запросов и ответов. Примерами могут служить RabbitMQ с использованием шаблона RPC (Remote Procedure Call) или некоторые функции Apache Kafka. ✔️ Топики и публикация-подписка. В этой модели брокера очередей сообщения публикуются в топики (темы), и получатели могут подписываться на топики, которые их интересуют. Когда сообщение отправляется в топик, оно будет получено всеми подписанными на него получателями. Примеры: Apache Kafka, MQTT (Message Queuing Telemetry Transport) и MQTT-SN (MQTT for Sensor Networks). __ Брокеры очередей могут помочь в построении надежных, масштабируемых и асинхронных систем, способных обрабатывать большие объемы данных и обеспечивать устойчивость к сбоям.

Как стать тимлидом, или Что вас ждет по другую сторону разработки — часть 2 Часть 1 Сегодня поговорим об ответственности. Именно от тимлида зависит, насколько успешным будет проект: — Сроки реализации влияют на то, когда продукт выйдет на рынок. — От ресурсного планирования зависит, выйдет ли проект за бюджет. — Общение со стейкхолдерами формирует ожидания от проекта. — Качество продукта влияет на лояльность пользователей. Разберем подробнее, какая ответственность ложится на тимлида. Сроки и бюджеты Первое, с чем сталкиваются тимлиды, это сроки, бюджеты и распределение ресурсов. Вам придется контролировать поток бюджета, ФОТ и рентабельность команды. Будет здорово, если вы изучите виды трудовых договоров, поймете, как считаются налоги, и будете планировать и распределять финансы, поступающие в команду. Общение с бизнес-заказчиком Для бизнеса тимлид — единственный представитель технической части проекта. Вместе с проджект-менеджером вам нужно выяснять потребности бизнес-заказчика. Поэтому придется развивать навыки дипломатии и умение отстаивать позицию. Так вы сможете контролировать поток задач и планировать работу на комфортных команде условиях. Качество Одно дело — написать код, другое — сделать продукт удобным для пользователя. Главный совет тут: интегрируйтесь с отделом качества на всех технических этапах проекта. Кризисное управление и Disaster plan Тимлид отвечает за жизнеспособность проекта. У всех случаются аварии: из-за сети, сервера или неудачного релиза. Поэтому задача тимлида — проработать комплекс мер, чтобы предупредить или исключить аварии. Если на проекте есть нестабильный участок, лучше завести тикет и просчитать риски. Опасный код стоит выделять в отдельные сервисы, чтобы он не ронял всю систему. Как с этим справиться Кажется, что ответственность — это естественно и легко, но на самом деле не всё так просто. Технические задачи, постоянные вопросы менеджеров и разработчиков, решение конфликтов, умение требовать выполнения поручений — это эмоциональная нагрузка и стресс. Разбейте рабочий день на интервалы по разным типам активности: ревью, консультации, встречи, исследования. И старайтесь их придерживаться. Никто вас не заставляет моментально отвечать на все сообщения в чатах (кроме аварийных), берите паузу на ответ, если вы заняты другими делами. В следующем посте расскажу о процессах найма сотрудников в роли тимлида.

Как стать тимлидом, или Что вас ждет по другую сторону разработки Прежде чем меня назначили тимлидом, я много лет работал разработчиком. Команды были разные, стили управления тоже. Я суммировал этот опыт и подготовил серию постов. Они предназначены тем, кто только начинает тимлидский путь. Почему разработчики становятся управленцами Есть особый кайф в том, чтобы работать только с технологиями. Вот документация, вот исходный код — бери и разбирайся. Нужно, чтобы в To do был только один тикет. А в случае конфликта приоритетов — сообщи тимлиду и менеджеру. Но чем дальше — тем сложнее абстрагироваться от внешних процессов. Иногда приходится договариваться, иногда отстаивать решения. Сложные задачи требуют обсуждения. И всё это выводит специалиста из зоны комфорта. Тут-то и начинается развитие коммуникативных и менеджерских навыков. Думаю, у разработчиков это в крови: чинить то, что сломано, будь это код или рабочий процесс. В том и в другом случае ты решаешь задачу, ищешь оптимальный путь из точки A в точку B. А дальше программист начинает брать на себя функции тимлида: — делегировать рутинную работу младшему сотруднику; — формализовывать и давать установки по реализации задач; — налаживать механизм контроля сроков и требовать их соблюдения; — вести техническое ревью. Вся эта работа не специфична для линейного разработчика, поэтому такое погружение в рутину менеджера заставляет задуматься о должности тимлида. Но перед тем как им стать, стоит ответить себе на вопросы: — Так ли всё хорошо в работе руководителя?  — Стоит ли рассматривать рост в тимлида как обязательный этап в развитии карьеры программиста, или это совсем другая профессия?  — Как от кода перейти к управлению людьми?  Когда я становился тимлидом, не до конца осознавал весь объем работы: ответственность, сроки, бюджеты, команда, технологии. Это было сложно, но сейчас я понимаю, что оно того стоило. В следующем посте поговорим про новую ответственность и как ее не бояться.

👴 Как работать со старожилами компании, которые стали неэффективными В каждой компании, которая на рынке хотя бы 10–15 лет, целый пласт сотрудников-старожилов. Это те ребята, которые пришли работать сто лет назад, проявили себя как супергерои, но потом как-то подсдулись. Они делали сложнейшие проекты, были опорой производства, были незаменимы. Но технологии шагнули вперед, процессы в компании поменялись, а они так и остались в прошлом. Я не сторонник идеи, что с такими сотрудниками надо прощаться. Есть другие способы вернуть их в реальность. 1. Обсуждение и обратная связь. Начните с честного разговора. Расскажите сотруднику, что заметили спад в его производительности. Спросите, что у него с мотивацией и как можно помочь. Часто люди признаются, что отстали от гонки технологий и боятся не догнать коллег. 2. Оценка навыков и потребностей. Оцените навыки и остаточные знания сотрудника. Когда человек годами варится в одном проекте, он забывает, как работать над другими. Часто, таким старожилам нужно обучение или переподготовка. И этого хватит, чтобы они вернулись в строй. 3. План развития и обучения. Разработайте план развития сотрудника. В нем должно быть не только обучение, но и тренинги, а еще поддержка. Можно зафиксировать, какие технологии нужно освоить сотруднику, в формате KPI. Новые знания он должен применять на практике. 4. Создание мотивации. Обдумайте систему мотивации. Если он с вами десяток лет, вы ему нравитесь и он хочет с вами работать. Но нужно его зажечь. Вот несколько вариантов: переключить его на интересный проект, ввести систему бонусов, пересмотреть трудовой договор, поменять должность. 5. Регулярное отслеживание результатов и поддержка. После первого же разговора назначьте даты контрольных срезов. Так вы будете отслеживать достижения сотрудника, а он будет чувствовать вашу поддержку. Учиться — это непросто. Возвращаться в строй после череды поражений — еще сложнее. Поэтому показывайте сотруднику, что вы в него верите. 6. Оценка и принятие решения. Если приложенные усилия не помогли и сотрудник продолжает оставаться неэффективным, придется задуматься о расставании. Не все готовы меняться, это нормально. И помнить о таком варианте развития событий нужно с самого начала. ⚠️ По моему опыту, из пяти старожилов только трое адаптируются под новую реальность и начинают работать на современных и технологичных проектах. Важно помнить, что подход к каждому сотруднику должен быть уникальным. Учитывайте личные обстоятельства и потребности. А главная цель — помочь ему восстановить его производительность.

Бесплатное тестовое задание — да или нет: https://habr.com/ru/companies/agima/articles/765556/ Наш рекрутер Аня Шабаева заметила, что тестовое задание — это больная тема как для кандидатов, так и для работодателей. Чтобы понять, что именно смущает в тестовом тех и других, она провела серию опросов. А их результатами делится в статье на Хабре. По ссылке выше интересные данные о том, каким должно быть задание, чтобы не спугнуть кандидата. А еще несколько интересных примеров.

Кто из нас не сталкивался с ситуацией, когда одна из систем начинает деградировать, но в неё продолжают приходить запросы из внешних источников, которые добивают сервис? Из курса физики мы знаем, что в электрическую схему прибора нужно добавлять предохранительный выключатель. Он не дает отправить запрос к неработающему элементу цепи, чтобы предотвратить перегрузку или сбой. Когда строишь архитектуру ПО, тоже стоит использовать предохранитель — чтобы сделать систему устойчивой при работе с удаленными сервисами или компонентами. Этим предохранителем будет шаблон проектирования, который так и называется — паттерн «Предохранитель» (или Circuit Breaker). Основная идея паттерна «Предохранитель» в том, что перед выполнением операции код проверяет текущее состояние операции. Например, перед вызовом удаленного сервиса или базы данных. Если операция активна и работает нормально, код выполняется. А если она несколько раз завершилась неудачно, то с помощью «предохранителя» запросы на выполнение этой операции временно блокируются. Это позволяет избежать дополнительных неудачных запросов и дает сервису время восстановиться. Основные концепции паттерна «Предохранитель»: Состояния • Закрыто. В этом состоянии операция доступна и выполняется нормально. • Открыто. В этом состоянии операция блокируется, и все запросы на выполнение отклоняются. • Полуоткрыто. Переходное состояние, когда после определенного времени или условия «предохранитель» позволяет одному запросу пройти для проверки состояния операции. Счетчик ошибок Паттерн «Предохранитель» ведет счетчик неудачных попыток выполнения операции. Пороговое значение ошибок Когда количество неудачных попыток достигает определенного порогового значения, «предохранитель» переводит операцию в состояние «Открыто». Таймаут Паттерн может использовать временные интервалы для переключения состояний, например для перехода из «Открыто» в «Полуоткрыто». Этот паттерн может быть реализован на разных уровнях архитектуры, включая приложение, слой доступа к данным или даже сетевой уровень. Всё зависит от конкретных требований и контекста системы.

На днях дочитал книгу «Проект "Феникс"». Роман о том, как DevOps меняет бизнес к лучшему». Авторы: Ким Джин, Спаффорд Джордж, Бер Кевин. И вот что хочу сказать. «Проект "Феникс"» — это не просто книга о DevOps. Это путеводитель в мир инноваций и трансформации бизнеса. Автор сочетает теоретические знания с захватывающим сюжетом, что делает книгу увлекательной и при этом полезной. Даже для тех, кто не эксперт в IT. Герой романа использует различные управленческие техники, берется за проект на стадии полного провала и в итоге достигает блестящих результатов. Конечно же, что-то в книге идеализировано, но для меня это не проблема. Главное, что автор глубоко понимает тему и может ярко, понятно и на жизненных примерах объяснить сложные концепции. Рекомендую к прочтению. Она и информативна, и вдохновляет на позитивные изменения в IT. Да и в целом.

Недавно я писал, как у нас устроены стажировки. И упоминал, что ключевое звено обучения в AGIMA — менторы. А вчера ребята из Хабр Карьеры опубликовали исследование о менторстве в IT. По их данным, 73% опытных специалистов становятся наставниками. Так что самое время рассказать подробнее, кто такие менторы и как мы с ними работаем. Наши менторы — это действующие тимлиды и Senior-разработчики, которым интересно обучать менее опытных коллег. Как правило, это люди с хорошей эмпатией, готовые разжёвывать информацию, умеющие преподнести материал и мотивировать учеников. В нашей компании менторство — добровольное занятие, мы никого не заставляем. Человек должен прийти к этому сам. Кто-то может обучать, а кто-то нет. Но менторство — это и не хобби. Мы выделяем под это рабочее время специалистов, подгоняем под это их проектную нагрузку. Часто встает вопрос: кто будет менторить самих тимлидов и Senior-разработчик? Чтобы они тоже развивались и росли, мы создаём архитектурный комитет. Он состоит из мощных технических лидов и архитекторов. Любой специалист, если столкнулся с техническими сложностями, может обратиться в этот «совет джедаев». Они помогут разобраться. А если сотрудник заинтересован, мы разрабатываем ИПР. Про концепцию наших ИПР я расскажу в следующих постах. Расскажите, есть ли менторство в ваших компаниях. Как вы подбираете менторов? Как обучаете?

Друзья, всем привет! Меня зовут Александр Шутай, я руководитель направления PHP в AGIMA, а также админ этого канала. Многие меня знают, как преподавателя с курса для тимлидов, я вел вебинары модуля про управление командой. Хочу перестать скрываться за бездушной аватаркой админа, сделать канал чуть более открытым, личным и живым! Поэтому не пугайтесь, что изменилось название. Я буду также рассказывать про лучшие практики управления разработчиками, какие новые фишки и процессы мы внедряем у себя в AGIMA. А также будут настоящие и порой поучительные истории и ситуации из нашей айтишной жизни.

Привет! Как вы, наверняка, уже слышали, в AGIMA мы с большим увлечением организовываем увлекательные образовательные мероприятия. В этот раз мы с нашей командой готовим для вас онлайн-митап под названием "Чат-боты и языковые модели: автоматизируй, нанимай, упрощай, формализируй". Мы гарантируем, что контент будет необычайно полезным. Прежде чем приступить к подготовке, мы провели ряд встреч с представителями известных брендов, чтобы узнать, какие чат-боты существуют, кто внедряет языковые модели и как все это сказывается на бизнесе. Мы приложили максимум усилий, чтобы программа включала в себя доклады с самыми интересными кейсами. Так что здесь не будет ничего лишнего - только то, что уже применяют крупные компании. Эксперты из СДЭК, Маруси ВК, РЖД и AGIMA.AI поделятся своим опытом: - Как создать уникального голосового ассистента с конкретной личностью, характером и голосом. - Как запустили чат-бота для IT-поддержки в корпоративном мессенджере РЖД. - Какие возможности предоставляют чат-боты и как они влияют на качество обслуживания клиентов. - Что представляют собой языковые модели и как они облегчают ведение бизнеса. Участие совершенно бесплатно, вам просто нужно зарегистрироваться. Мы ждем всех!

Руководитель нашей Flutter/iOS-разработки Саша Ворожищев теперь ведет свой телеграм-канал: https://t.me/WizAlx_will_tell. Он пишет о том, как, зачем и где быть разработчиком в 2023 году. Это не новостной канал, а канал с честным мнением обо всем, что происходит на рынке разработки. А главное, Саша собирает там полезные артефакты: - статьи о мобильной разработке; - исследования; - классные новые подходы; - тренды в IT; - кейсы AGIMA и т. д. Ну а кроме работы — немного юмора и музыки. Если вы мобильный разработчик или собираетесь им стать, подписыватесь на канал Саши. Там интересно.

Как мы строим процесс стажировок 👩‍🎓👨‍🎓 Стажировки — это классный инструмент как для компании, так и для начинающих разработчиков. Мы гордимся тем, что даем вчерашним студентам мощный старт в IT. Причем учатся они сразу на интересных и крупных проектах. Поэтому и к подбору стажеров мы подходим серьезно. Ищем ребят с горящими глазами. И саму стажировку готовим загодя: определяем квоту, вакантные места, ресурс менторов. Не круто, когда в компании толпа равнодушных стажеров, которые относятся к стажировке как к скучному и необязательному делу. Заинтересованных ребят мы ищем по группам IT-университетов и среди выпускников онлайн-платформ: Яндекс Практикум, Нетология и т. д. Тем, кто откликнулся, даем тестовое на разработку чего-нибудь простого, но интересного. Например, формы обратной связи с оценкой или формы бронирования мест в кинотеатре. И несколько теоретических вопросов. С теми, кто круто сделал задачки, встречаемся и просим объяснить ход работы реализованной программы. Оцениваем эрудированность, мотивацию и желание поскорее влиться в IT. И конечно же, рассказываем про нас, чему мы научим, что предложим и как будет проходить стажировка. Мы разработали программы обучения, состоящие из теории, упражнений и промежуточных экзаменов. Темы содержат ссылки на материалы, тесты, критерии приемки и имеют временной лимит на изучение. После успешного прохождения первой трети обучения и сдачи первого экзамена стажер подключается к проекту, вливается в команду и начинает перенимать опыт более опытных коллег. Каждый ученик прикреплен к ментору, зафиксировано расписание встреч по разбору накопившихся вопросов и контрольных срезов по успеваемости. Стажировка оканчивается сдачей финального теоретического экзамена по пройденным материалам и опросом 360 от членов команды. Мы любим наших учеников, предлагаем конкурентные условия сотрудничества и составляем индивидуальный план дальнейшего развития. А теперь расскажите в комментариях, как вы проводите стажировки. Интересно узнать про необычные практики и методы.

Как настроить уровни доступа к функционалу в CMS Bitrix: https://habr.com/ru/companies/agima/articles/757884/. Наш PHP-разработчик Максим Баюров в новой статье на Хабре рассказывает, как расширять уровни доступа к функционалу сайта. Вы узнаете: - в каких случаях это требуется; - всегда ли нужно что-то дорабатывать; - как ускорить такую доработку. В качестве примера в статье приводится доработка в CMS Bitrix. Разбираем конкретные проблемы и тонкости процесса. Всё это по ссылке выше.

Как мы внедрили опросник перед собеседованиями Мы растём, а это значит, постоянно нуждаемся в новых ребятах. Разработчики, тимлиды — наш основной костяк, который нужно усилять, взращивать и искать на рынке. Каждый день мы получаем десятки откликов на вакансии. Наши рекрутеры неустанно работают, чтобы связаться с кандидатами, рассказать о предложении, узнать пожелания соискателя и договориться о техническом интервью. Перед тем как выстроить чёткий процесс первичного отбора по откликам, мы искали ответы на вопросы: 🤔Как понять, что человек действительно подходит по техническим знаниям? 🤔Как соискателю понять, какие навыки будет необходимо использовать в работе? Порой, из описания вакансии неочевидно, какие скиллы будут являться ключевыми. А из шаблонного резюме неясно, насколько глубокими являются знания кандидата. Изначально просили рекрутеров проводить мини-интервью по заготовленным вопросам, но сухие ответы “да/нет/не использовал” представляют мало ценности для характеристики человека. И такой формат не даёт кандидату никакой информации о технологических вызовах будущих задач. Пробовали отправлять кандидатам тестовые задания. Большинство из них отказывались. И мы их можем понять, не всем хочется тратить 2 часа и пилить тестовое на каждый отклик из HH, которых может быть десятки. Также в тестовом всё-таки трудно оценить кругозор человека. 📌Решили взять лучшее из этих подходов и сформировать удобный инструмент для первичной оценки кандидата. Он должен охватывать наши требования по знаниям, показывать, с чем придётся работать, и его использование не должно превышать 15-20 минут. Стали использовать простое решение — опросник на основе гуглоформы. Ответ на каждый вопрос должен быть развёрнутым. Постарались сформировать такие вопросы, чтобы на них нельзя было однозначно ответить “да” или “нет”. Теперь по широкому ответу можем оценить глубину знаний. Все вопросы должны охватывать скоуп используемых технологий и основываться на практике. Старались подобрать такие вопросы, чтобы ответы на них нельзя было быстро нагуглить. Например, один из вопросов на позицию Laravel developer: ❓Являются ли фасады Laravel паттерном фасада и почему? Для ответа на данный вопрос нужно разбираться в фасадах Ларавеля. Знать, что такое структурный паттерн “Фасад” и уже основываясь на этом опыте, провести быстрый анализ и ответить на вопрос. Другие примеры наших вопросов: ❓ Отличия взаимодействия двух систем через REST и MQ (своими словами); ❓ Что под капотом (представляют из себя) у индексов в БД? А какие ещё методы для быстрого скорринга кандидатов используете вы?

Руководитель мобильной разработки Миша Вассер написал крутую статью о том, как мы оптимизировали процессы разработки приложений и зачем это нужно: https://vc.ru/life/802592-kak-my-uskorili-razrabotku-mobilnyh-prilozheniy-na-30-zapisyvayte-recept. Чем быстрее мы сдаем проекты, тем выгоднее нам и нашим заказчикам. Но как это ускорить? Стоять над разработчиком с кнутом и заставлять писать код день и ночь? Набрать огромную команду? В статье ответы на эти вопросы, а также: — Стандартные модули в приложениях. — Способы ускорения разработки. — Наш подход и его преимущества. — Как ещё можно автоматизировать разработку. Материал по ссылке выше, а пообщаться с Мишей можно в его Твиттере: https://twitter.com/mishawasser.