Вот теперь я Тим лид команды из 3 андроид разработчиков и мне нужно собрать такую же iOS команду. И если по андроиду у меня были посредственные, но достаточные знания, то по iOS все было значительно хуже :)
Но я уже согласился, отступать нельзя!

Передо мной возникли следующие вопросы: Как их вообще набирать? Что писать в профиле кандидата на подбор? Что спрашивать на собесе?

Разумеется первые собесы были просто «топ 10 вопросов iOS на собеседовании» из первого запроса в Гугле. В чем отличие классов от структур, разница между value/reference type, как реализованы структуры данных. Не смотря на примитивность подхода, но я сходу не смог никого найти — люди с 2-3 годами опыта не могли ответить на базовые вопросы.

Сейчас такие вопросы обычно дают на скрининге, чтобы отсеять совсем слабых кандидатов, лет 5-6 назад много где можно было получить синьорскую лычку за ответы на них 😂

В общем, провел 10 собесов, наняли одного стажера, без коммерческого опыта :)

Решил попробовать поменять структуру собеса и в итоге давал простую задачку — из готовой апишки вывести на экран список формата image, noscript, subnoscript, date. На это давалось минут 40 и 20 минут обсуждали решение

И этот вариант тоже практически провалился: из 5 кандидатов, только один сделал более менее рабочее решение, остальные городили дикие велосипеды: вместо списка просто создавали 10 переменных «per1, per2, per3…» и выводили отдельными вьюшками на экран

Финально, мы наняли одного стажера и одного senior разработчика. Не смотря на то, что как проводить собес я не знал — наняли мы довольно неплохих ребят и, таким образом, моя команда стала уже 3 android и 2 iOS разработчика

С этой командой мы приступили к разработке приложения для увеличения оплодотворяемости коров 🐮

Сегодня хотел бы поговорить про фазовые переходы у руководителей :)

Что я подразумеваю под этим термином? У разработчиков есть более менее очерченные границы — intern, junior, middle, senior, примерно состоявшиеся ожидания от каждой из ролей. У руководителей чаще всего такой градации нет, а ожидания сильно размыты и отличаются от компании к компании

Но есть кое что общее: подходы к управлению командами исходя из количества подчиненных и их компетенции. Верхнеуровнево, думаю, всем очевидно, что подход к управлению 3 джунами будет сильно отличаться от управления 15 мидлами-синьорами. Мне в силу неопытности и быстрого карьерного роста это было не понятно, это было реально больно!

Почему? Мой опыт в менеджменте начался с управления командой из двух джунов и стажера. На этом этапе был тотальный микроменеджмент и, наверное, это был верный подход в той ситуации. Я буквально все делал сам и делегировал только самые простые и рутинные задачки. Разумеется, с этого я начинал гореть, но это не ощущалось, пока команда была маленькой. Я успевал перформить за нескольких человек и на этом фоне мне доверили расширение команды.
Когда команда стала больше 5 разработчиков — решать рабочие задачи за 8-часовой рабочий день я успевать перестал. Тут должна быть история как я мастерски овладел навыком делегирования и все пошло как по маслу, но делегирование на команде Джунов работает так себе. На деле я овладел навыком работы по 12 часов 😂

Это был первый фазовый переход, с которым я не справился.

Давайте попробуем добавить интерактива в мои монологи:
У вас есть команда из 6 джуно-мидлов, задачи в принципе решаются, но код после них нерасширяемый, изменения вносить невозможно, а количество багов растет быстрее количества фичей. Чтобы вы сделали на моем месте?

Продолжаем историю про бурный рост команды

В предыдущем посте было предположение, что чтобы наладить работу в команде я отправил их в Android academy)
Предположение хорошее, и, наверное, нужно было так и поступить и это позволило бы проще достичь результата, но тогда я почему-то об этом не подумал

В той ситуации мне очень помогли общие тех синки, на которых ребята делали свои доклады в стиле академии — есть какая-то тема, которую один человек разбирает и готовит презу, остальные смотрят, впитывают и задают вопросы. У нас был общий беклог проблем в проекте, которые мы последовательно разбирали. Подход довольно интересный и решает сразу довольно много проблем.
1. Пробелы знаний в команде закрываются сами по себе, Лиду не нужно прокачивать всех отдельно, ставить ИПР и следить за результатом их выполнения
2. Инженеры учатся более структурировано выражать свои мысли и презентовать их остальной части команды
3. Команда сама выявляет проблемы в проекте и сплочается для их решения

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

Поговорим про следующий фазовый переход

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

В чем была проблема в этот момент? Команда способна была решать задачи самостоятельно, но эти задачи надо было сформулировать, перевести с бизнесового языка на язык разработки. На тот момент этой задачей занимался я: поболтать с продактом, бизнесом, узнать что хотят, подсветить чего не хватает, верхнеуровнево расписать что нужно и тд. Сделать это на команду 3 Android + 3 iOS особой проблемы не составляло.

Но команда снова начала расширяться, стало 5 Android + 5 iOS . Управлять 10 разработчиками уже довольно проблематично и вообще с точки зрения коммуникации общаться с 10 людьми уже довольно непростая и выматывающая задача

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

По традиции вопрос к аудитории — что будем делать со сложившейся ситуацией?

Заработался и не добил финальную часть как я стал Тим лидом :)

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

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

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

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

Чтобы не совершать моих ошибок, хотел бы поделиться несколькими советами:
1. У команды и у мини-лидов должен быть среднесрочный роадмап с четкими целями и сроками их реализации
2. Если команда начинает нарушать сроки, нельзя включаться в процесс и тащить все факапы на себе. Это реально сложно, потому что все проблемы, возникающие перед командой, Лид уже много раз решал, а минилид сталкивается с ними впервые. Нужно именно научить минилида диагностировать эти проблемы(!) и решать их
3. Для того чтобы минилиды справились со свалившейся на них ответственностью, нужно заранее подсвечивать потенциальные проблемы с помощью наводящих вопросов, например:
- Все ли у нас хорошо с активностью «А»?
- Есть ли у команды все необходимое для решения задачи?
- Есть ли какие-то ограничения, которые не позволят реализовать нашу цель?
- справляешься ли ты со своей нагрузкой? Нужно ли что-то пересмотреть
4. Научить минилидов уточнять требования — самая большая проблема разработчиков, что они принимают все требования как аксиому, что приводит к куче переделываний
5. Изучить принцип ситуационного управления. Не буду детально описывать что это и как работает — это легко гуглится)

В следующей статье хочу описать как я стал head of, но буду рад вашим вопросам и разобрать какие-то из ваших кейсов :)

Как я подтягивал английский.

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

Мои принципы прокачки английского
+ цель - хочу спокойно проходить все этапы (алгоритмы, дизайн, behavioral) на английском (британский, американский, разные акценты).
+ хочу при заданном затраченном времени получить максимум результата.
+ не хочу заниматься “3 раза в неделю по часу вечером в течение полугода чтобы отличать все времена perfect между собой”
+ не хочу делать однотипные упражнения

Общая система
Занимался английским 40 минут каждое утро во время завтрака, так привычка английского закрепилась за завтрак. Иногда делал перерыв и потом занимался еще минут 40. На выходных минут по 20-30 чисто слова повторял.

Набор упражнений
1. Словарный запас. Взял топ 1000 частотных слов, пролистал и все что не знаю закинул в анки карты и повторял. Потом взял топ 3к слов.

2. Умение говорить, умение писать и грамматика. Взял кучу вопросов к behavioral , накидал ответы через голосовой ввод -> закинул в Grammarly , чтобы проверить ошибки -> темы, в которых ошибаюсь прочитал в Murphy и поделал упражнения.

3. Слушание. Смотрел выступления на ютубе или daily dictation и устраивал себе диктант. Либо пересказывал своими словами и опять в пайплайн грамматики.

4. Умение говорить. Нашел преподов на italki из стран с высоким уровнем английского, но низкими доходами: Кения, Филлипины, ЮАР, Нигеия, Малайзия. С ними устраивал мок-собеседования либо общение с неожиданными вопросами от них и разбором.

5. Читал фоном книги на англ, сериалы. Но это я обучением не считаю, это потребление контента.

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


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

Как я запромоутился до head of

Под head of все понимают разное, в некоторых команиях руководитель Android+iOS небольшой команды — уже head of, но я под этим подразумеваю момент, когда у Лида появляются другие Лиды в подчинении

И так, как я им стал? Команда, которую я собрал уже начала хорошо перформить, но на тот момент об этом знала команда, я и мой Лид. Пришло время поработать над visibility результатов команды внутри компании.

Как это можно сделать? Обычно в компаниях есть общие tech demo, у нас такого не было и мест, где показать какая у тебя Крутая команда особо не было. Значит надо взять все в свои руки и создать условия самому!
На тот момент команда строилась по схеме McKinsey. Была матричная структура с платформенными и продуктовыми командами и в планах было построение дополнительной абстракции в виде платформенных стримов. Например, у вас есть в компании 20 мобильных команд, все команды никак не взаимодействуют между собой, знания не шарятся, наработки не переиспользуются — нужно создать что-то что будет это делать. Так как это была огромная неповоротливая корпорация очень долго от слов к делу не переходило
Ну и я взял все в свои руки, создал эту сущность и нагло стал владельцем этого процесса :)

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

Что сработало?
1. Команды начали узнавать друг о друге
2. Команды смогли проще решать технические проблемы
3. Появилась возможность подсвечивать глобальные проблемы и проектировать варианты их решения
4. Появилась возможность строить технические процессы на более высоком уровне — общая дизайн система, общий артифактори, общие правила и бейзлайны
5. О команде узнало большее количество людей и под мои проекты стало проще выделение ресурсов — практически в один момент моя команда выросла с 10 до 20 разработчиков

Что не сработало?
1. Моя роль была формальной, никакой официальной лычки «батя мобилки» у меня не было. Это не позволяло с ноги заходить в команды и диктовать свои правила. Все драйвилось на личном авторитете, продвигалось, но все шло очень медленно. Вывод — любая инициатива без полномочий работает плохо или не работает вовсе
2. Так как лычки не было, финально чтобы что-то реализовать мне приходилось убеждать разрабов, их лидов, продактов, топов уровня CTO/VP. Учесть интересы всех просто не возможно и в итоге все это сводилось к тому, чтобы убедить VP что-то сделать, а он уже своим авторитетом все продавливал. Но проблема была в том, что человеку уровня VP это нафиг не нужно. Вывод — если на уровне культуры и процессов компании это не заложено, то можно на этом сильно задолбаться и сгореть :)

Итогов не будет, с Новым годом всех 😎

Новый год уже прошел, пора включаться в рабочие процессы!

Как стать Android-разработчиком в 2023 году

В 2012 я начал изучать программирование, начал с сайтов на CMS и заказал этот логотип, думая что создам всемирно известную студию по созданию сайтов. Думал наберу разрабов и буду путешествовать на пассивный заработок от этой деятельности :)

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

И тогда я заметил в Гугл трендах и Яндекс аналитике, что веб трафик начал постепенно снижаться в пользу мобильного и уже в 2014 я начал изучать разработку под Android. Через пол года сделал свое первое приложение, одно, другое, суммарно наклепал больше 50 однотипных приложений. Начал зарабатывать с этого значительно бОльшие суммы с рекламы в них

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

Есть ли что-то про что вам было интересно почитать? Объявляю заявошную на статьи :)

Про первые шаги в работе руководителем

Постарался коротко, но получился адский лонгрид. Читаем, комментируем, говорим, что я не прав и все вообще не так - welcome 🙂

https://telegra.ph/Pervye-shagi-v-rabote-rukovoditelem-01-12

Пока решатся что-то делать, ты уже СТО и можешь сам поувольнять их всех :)

Статья "Как стать Android разработчиком в 2023" вызвала бурный интерес и сюда подписалось довольно много начинающих разработчиков
После общения с вами понял, что не до конца понимаю боли аудитории и хочу провести небольшой опросик среди начинающих разработчиков -- forms.gle/Rt7EowarZYY6DFR86

Опрос анонимный, но опционально можете оставить свой контакт, прохождение займет 5-10 минут, поделитесь пожалуйста

Пытаюсь дооформить уроки для одного курса, и фоточки для анонса второго, но вот это все сильно мешает :)

Закончил лениться и дооформил анонс курса по Jetpack Compose от Android Academy
Регистрируйтесь, будет интересно!
https://habr.com/ru/news/t/712122/

Параллельно с Android Academy я начинаю подготовку к сезону Android Crew #10
Нужна ваша помощь! Какие доклады от топовых спикеров вы хотели бы послушать?
KMM, Multi-module project, Мок-собесы?
Жду ваших набросов 🙂

У меня кстати есть чатик @ermolnikchat
Сейчас там обсуждаем только реакции на мои посты, но буду рад двустороннему общению, поотвечать на ваши вопросы -- вступайте 🙂

Шаббат шалом, чемпионы и чемпионки!

Концентрация Android-курсов в этом чате в последние дни просто зашкаливает
Предыдущие курсы были больше для Middle-уровня и выше, пришло время сделать что-то для Trainee-Intern уровня

Хочу показать курс-марафон для начинающих инженеров

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

И вот, я попробовал решить эту боль -- предлагаю вместе собраться и создать свой первый pet-проект по отображению фильмов

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

Детальная информация о том, что и как -- тут

Для того чтобы оставить заявку -- пишите @ermolnik
Вопросы оставляйте тут в комментариях