Карта развития мобильного разработчика
Мы ежедневно сталкиваемся с понятиями «джун», «мидл», «сеньор», но наши представления о том, какими знаниями должен обладать разработчик на разных стадиях роста, разнятся. Отсутствие четкого плана развития и непонимание, куда двигаться дальше, часто приводят к фрустрации и необдуманным сменам места работы.
Ребята из AppsCast совместно с Head of Mobile проекта Pandao Александром Черным (@AlexChernyy) попробовали разобраться в вопросе и составить собственную карту развития мобильного разработчика с момента попадания в профессию и до руководящих постов. Под катом советы в о собеседовании джунов, где брать хороших разработчиков, рекомендации новичкам для устройства на работу, ключевые отличия джунов, мидлов и сеньоров, и важность навыка коммуникации для всех уровней.
Даниил Попов: Сегодня у нас в гостях Александр Черный, из Mail.ru проекта Pandao. Расскажи о себе чуть подробнее.
Александр Черный: Привет. Я руковожу отделом мобильной разработки в проекте Pandao, который посвящен электронной коммерции. Сейчас в штате шесть человек, а начиналось все с меня одного.
Я начинал свой путь как программист на C и Assembler, а в мобильную разработку пришел как iOS-разработчик. Первым фактором послужила личная мотивация поиска дальнейшего пути развития. Тогда вариантов была два: либо Java в финансовом секторе, либо мобильная разработка, которая только начала появляться. Я проделал большую работу по поиску людей из обеих сфер, выслушал их рекомендации и мысли. Второй фактор был случайный: сдох ноут и по совету друга я купил подержанный MacBook.
Даниил Попов: Получается, что ты прошел путь от простого разработчика до руководителя отдела?
Александр Черный: Путь был линейным. Сначала я рос как iOS-разработчик, потом у меня появился товарищ по команде, затем своя маленькая команда iOS-разработки, позже распределенная команда побольше. В какой-то момент случился переход к руководству всей мобильной разработкой.
Вход в мобильную разработку
Даниил Попов: Опираясь на твой опыт, давай обсудим этот путь подробнее и начнем с позиции джуниора. Что ты ожидаешь от начинающего специалиста, которого берешь в команду? Как человеку со стороны прийти в профессию мобильного разработчика?
Александр Черный: Самый крутой способ — выуживать всех НЕ первых из школ мобильной разработки, которые периодически устраиваются различными компаниями. В компаниях есть фиксированная величина количества джунов на количество сеньоров в команде, поэтому из этих школ себе забирают одного-двоих. Больше джунов нет возможности переварить одновременно или просто нет достаточно вакансий.
Но остальные часто не хуже тех, кого взяли к себе организаторы курсов. Я так к себе позвал в команду одного junior-разработчика, а он в соседнюю команду порекомендовал парня, с которым вместе учился.
Алексей Кудрявцев: Получается, что ребята с курсов могут быть нормальными джунами и уметь адекватно разрабатывать? Мне казалось, что у многих там мотивация быстро все пройти, чтобы поскорее начать зарабатывать, а на деле они ничего не умеют.
Александр Черный: Есть дополнительный показатель качества — это наличие у образовательных курсов обязательного предварительного отбора и контрольных точек в течение всего цикла занятий. Это означает, что у выпускника, как минимум, хватило силы воли пройти до конца, а у преподавателей терпения его обучить.
Джентльменский набор джуна
Даниил Попов: Назови по три вещи, которые джуниор должен знать из hard и soft skills?
Александр Черный: Из hard skills обязательно знать язык выбранной платформы, по возможности знать SDK платформы. Знание архитектуры для меня неважно, потому что я не понимаю, как можно понимать архитектуру, если ты не сталкивался с проблемами, которые она решает.
Интереснее услышать от джуна ответ на вопрос «Почему ты выбрал Android или iOS?».
По soft skills хотелось бы видеть от всех базовые навыки общения, так как сложности с умением разговаривать есть не только у джунов. Когда же junior-разработчик попадает в команду, важна способность подать сигнал, когда что-то идет не так. Этим многие грешат по молодости, считая, что если они не смогли что-то сделать, то это конец истории.
Даниил Попов: Как самостоятельно понять свой уровень: дорос ли ты до джуна, мидла или сеньора?
Александр Черный: Уровень измеряется относительно той команды, в которой сейчас находится разработчик.
Даниил Попов: Получается, что в одной команде можно оказаться сеньором, а в другой мидлом?
Александр Черный: Да, и тут страдает объективность, потому что от специалиста начинают требовать компетенций, наличие которых не до конца понятно. Например, тебя просят прыгнуть на три метра вверх, а ты так не умеешь. Вообще прыжки это не твое, и никто не может объяснить, зачем они вообще нужны в клиент-серверном приложении. Не прыгаешь? Значит — не сеньор.
Алексей Кудрявцев: Джуны часто приходят устраиваться на работу с уверенностью, что они уже молодцы, но при этом у них проседают тразные навыки. Какие еще сложности возникают на собеседованиях?
Александр Черный: Самая большая проблема — это оценка с чистого листа, так как про джуна ничего неизвестно: некому написать и спросить рекомендации, нет выполненных проектов.
Это хорошо лечится живым репозиторием на GitHub, пусть это всего лишь синтетический проект и написано полторы activity.
Если еще и полтора теста для этого activity написано — молодец, а если подобие архитектуры есть — надо такого брать. Примерно так я беру джунов. У меня есть еще один субъективный и сложно оцениваемый критерий — это любопытство.
Если резюмировать, вот рекомендации для джунов:
- понимать язык, знать все базовые конструкции языка, а не просто повторять то, что видели в роликах;
- никто не ждет глубокого знания SDK, так как обновления выходят часто и я уже сам перестал их отсматривать, но знать вещи на уровне жизненного цикла необходимо;
- понимать свою мотивацию и осознанно идти в профессию.
Алексей Кудрявцев: Когда я был джуном, мне казалось, что для базового понимания языка нужно пробежать через все доки Apple, знать каждый класс и функцию. Что входит в базу, по твоему мнению?
Александр Черный: Это базовый синтаксис языка, который сразу подсвечивает IDE, основные коллекции из серии «как работать с массивами/списками», «как работать с словарями/картами». По UI основные знания формируются во время написания хотя бы одного тестового проекта.
Растем в мидлы
Даниил Попов: Как перескочить из джуниора в мидл? Как в одночасье понять, что специалист перешагнул на следующую ступень?
Александр Черный: В одночасье, конечно, не понять. В самом вопросе категоризации лежит проблема. Представьте, что вы соответствуете набору критериев, но один из них не выполнен и формально нельзя перейти на следующий уровень. Я отношусь сдержанно к такому подходу, особенно в маленьких командах.
При этом есть четкие критерии, которые точно нельзя обойти. Например, уровень постановки задач и ответственности, которую за нее несешь. От джуна ты не ждешь ничего. Он прочитает задачу, за понятное написание которой несет ответственность его руководитель, и максимум задаст вопросы по неясным моментам. Ты не ждешь, что он будет размышлять, что будет, если оценивать ограниченные случаи, продумывать новую парадигму кода для решения. Мидл же начинает переходить через эту грань.
Даниил Попов: Какие навыки ты добавил мидлу сверх того, что есть у джуниора?
Александр Черный: Должно появится понимание архитектуры и приоритет на на то, ЧТО ты пишешь, а КАК.
Одна из характеристик джуниор-разработчика — для него сам факт написания кода ценен. Для мидла код вторичен, на первый план выходит задача, которую он решает.
В делении разработчиков на джунов, мидлов и сеньоров есть неудачная визуализация роста через строгую ступенчатую последовательность. В продуктовом менеджменте есть треугольник MVP — минимально жизнеспособный продукт. MVP — это линия, которая проведена не параллельно основанию, а от основания до вершины треугольника. В такой схеме вы всегда умеете всего понемногу, мидл умеет больше чем джуниор, а сеньор, теоретически, должен закрывать по компетенциям весь треугольник.
Правильнее рассматривать критерии не через «знаю/не знаю», а через «насколько глубоко знаю». Джуниор может знать о существовании, мидл знает, что внутри, а сеньор понимает, зачем это придумано.
Даниил Попов: Должен ли мидл разбираться в Computer Science? Структуры данных, алгоритмы, хэш-коллекции?
Александр Черный: Да, сложно решить прикладную задачу, не понимая работу тех же коллекций, поэтому такое требование к мидлу точно можно предъявить.
Алексей Кудрявцев: Ты упомянул треугольник компетенций, а что тогда в него входит?
Александр Черный: В упрощенном варианте из hard skills там язык, платформа и архитектура. Если смотреть глубже, то стоит воспользоваться формулой Даниила и разбивать блоки на Computer Science и Software Engineering.
Алексей Кудрявцев: Как насчет навыков, которые инженеру не всегда нужны, но могут быть полезны: дебаггинг, криптография, перфоманс?
Александр Черный: В умении пользоваться туллингом должны быть заинтересованы все инженеры. Джуниор может не уметь работать со всеми инструментами, а вот от мидла я жду того же уровня любопытства, что у джуна на входе. Уверен, что в какой-то момент ему надоест жмякать на кнопки в IDE, и он начнет учить сочетание клавиш. Вместо обкладывания логами для поиска утечек памяти он запустит прикладной инструмент.
Даниил Попов: Нужно ли мидлу интересоваться смежными областями и расширять кругозор?
Александр Черный: Я за развитие кругозора и эрудиции. Если человек проявляет такое любопытство — это хороший вектор в сторону сеньора. Он как раз отличается умение отвечать на вопрос «Почему оно существует?» Если мидл пишет простейший класс приложения, которое все относят к клиент-серверному, но не осознает, почему при https трафик не ловится, а при установке Charles все работает — это обидно. А вот джуниору я сам бы это объяснил.
Вообще мидлу больше всех не повезло. Это слишком длительная и непредсказуемая зона роста, неясно, надолго ли она растянется.
У тех же джунов проще: при постоянной занятости на проектах в адекватной команде твой рост до мидла займет от года до двух с половиной, не больше.
Даниил Попов: Что насчет soft skills для мидла?
Александр Черный: Мидл уже не должен опасаться говорить о проблемах и быть в состоянии взять фичу и проработать ее самостоятельно, возможно, еще не понимая ее взаимодействия с другими фичами. Например, прилетел таск с картинкой от дизайнера и кратко описано, что надо сделать. На основании этих вводных мидл должен сказать, какие могут быть проблемы, например, есть элемент, которого нет в системе и его придется долго делать. Это некий механизм самоцензуры относительно поступающих ему задач. Еще в этой точке добавляется навык оценки сроков.
Даниил Попов: Как насчет коммуникаций? Без них же задачу не проработать и не оценить?
Александр Черный: Да нужно уметь разговаривать с заинтересованными лицами. Не усложнять цепочку и напрямую спросить у дизайнера, зайти к разработчикам другой платформы и узнать, одинаково ли вы понимаете задачу.
Даниил Попов: Чего чаще всего мидлы не знают?
Александр Черный: Многие заваливают язык и SDK, причем в самых фантастических местах. Сколько мидлов погибло на понимании, что итератор — это объект, или вопросом, чем представлена строка — массивом или списком.
Я стараюсь проверять не уровень знаний и даже не рассуждений, а реакцию на рассуждения. Например, рассказываю, что есть три разные ситуации и компилятор ведет себя по разному. Один может от такой ситуации отмахнуться, а другой сказать, что никогда об этом не задумывался, но с ноутбуком в руках смог бы воспроизвести в IDE ситуацию, чтобы отладчик показал, в чем разница.
Поздравляем, вы — сеньор!
Даниил Попов: Какие навыки должны добавиться к мидловым, чтобы можно было себя назвать сеньором?
Александр Черный: Что делает сеньор? Он определяет техническую культуру проекта целиком, так как понимает, какую пользу принесут бизнесу все действия разработки Тут нужен и опыт, понимание бизнеса и умение рисковать. Сеньор понимает проблемы уровня «у меня фризится видос, но хочу, чтобы плавно листался». Как конкретно это будет сделано — неважно.
Сеньор — гарант технической экспертизы. К нему идут с вопросом и желанием получить конкретный набор действий.
От мидла я жду понимания, что есть виртуальная машина и она существует не просто так, от сеньора — как это можно применить с пользой.
Алексей Кудрявцев: Как насчет знаний в реверс-инжиниринге?
Александр Черный: Реверсить может кто угодно. Не бояться это сделать — это граница мидла и сеньора. Нужно понимать, где хранятся данные и ресурсы — ничего фантастического.
Интересная характеристика мидла, которая отличает его сеньора, что он всегда говорит, что готов сделать задачу, но не всегда понимает, что за этим стоит и какие будут последствия.
Для разграничения уровней можно добавить использование библиотек. Джуниор тащит любую библиотеку, если она решает проблему. Мидл тащит, но думает, что надо посмотреть, нет ли аналогичного решения в проекте. Сеньор пишет свой велосипед, чтобы ему поставили звездочек на GitHub.
Можно молча затащить библиотеку и считать, что решил проблему. Можно посмотреть на нее и увидеть, что нужен только маленький кусочек и взять только его. Можно затащить всю библиотеку из-за того, что сроки поджимали, но создать соответствующий issue, чтобы в дальнейшем поправить. Смысл именно в том, с каким уровнем понимания подходить к затаскиванию.
Даниил Попов: Сеньор должен не просто грамотно подбирать библиотеки, но и разбираться в них, в них тоже могут быть проблемы. В отличие от мидла, который все покроет try-catch, сеньор форкнет, починит и сделает pull request на эту проблему.
Александр Черный: Сеньор при добавлении библиотеки берет всю ответственность за последствия на себя. Мидл же затащит и перенесет ответственность на саму бибилиотеку или ее разработчиков.
Куда дальше?
Даниил Попов: Есть ли жизнь после сеньорства? Я вижу варианты: лид, руководитель отдела, CTO или Project management.
Алексей Кудрявцев: А как насчет технического развития: техлида, принципала или вообще сменить направление?
Александр Черный: У всех вариантов свои последствия. Да, можно перейти в менеджерские позиции, но можно остаться и в технической среде — это точно не остановка в развитии.
Даниил Попов: У меня сложилось ощущение, что набор hard skill сильно зависит от компании, в которой работаешь, и ее профиля.
Александр Черный: Это влияет. В большой продуктовой компании, типа Facebook, тысячи технических специалистов. Все из них сильно ограничены в выборе технических решений — есть утвержденный стек, есть целые инфраструктурные команды и архитектурный комитет, который принимает решения за всех. В этом случае инженер становится company locked разработчиком, который обязан использовать парадигмы компании. Со временем он становится ценнее для компании, но не факт, что эту ценность воспримут снаружи.
Даниил Попов: А что делать, если я захотел заниматься навыком, который не типичен для продукта компании?
Александр Черный: Я сначала спрашиваю человека, откуда взялась идея. Иногда люди приходят со странными желаниями и не могут объяснить их природу. Если разработчик может обосновать, то дальше нужно смотреть, насколько эта идея подходит продукту. Есть вероятность, что она все-таки пригодится бизнесу.
Важно подходить к этому процессу индивидуально. Часто оказывается, что это не лучшее, что человек может сейчас сделать.
Даниил Попов: Ты сказал, что считаешь разделение на джунов, мидлов и сеньоров нечетким. Нужно ли оно тогда?
Александр Черный: Когда команда маленькая и все про всех известно, то можно обходится без ярлыков. В огромной корпорации градация понадобится, для соблюдения трудового кодекса, чтобы перечислять зарплату.
Карты развития разработчика
Алексей Кудрявцев: Как разработчику определить точки роста?
Александр Черный: Я придерживаюсь мнения, что карьерой должен заниматься сам сотрудник, так как невозможно каждого опекать. Если человеку хочется что-то поискать, то правильный запрос — это название платформы и developer roadmap. Можно найти кучу майндмепов с подробной информацией, в какой последовательности и что развивать.
Даниил Попов: При подготовке выпуска мы посмотрели карту развития iOS-разработчика. Там столько всего, что кажется после изучения всего спектра инженер станет overqualified для 90% компаний на российском рынке.
Александр Черный: Никто же не проверяет глубину знаний. Например, я смотрю карту и вижу фреймворк Core Location, но нет конкретики, что именно в нем нужно: знать о его существовании или разбираться в низкоуровневых вещах, например, какие сопроцессоры способны в фоне выдавать дополнительную энергоэффективность.
Роадмап — это просто обзорная карта, на которую смотришь и анализируешь, в какой город уже заезжал и сфотографировался на фоне вывески на въезде. При этом роадмап не линейный и не нужно знать предыдущее, чтобы идти к следующему, можно двигаться туда, куда вам хочется здесь и сейчас.
Алексей Кудрявцев: Роадмапы не всегда полезны, так как часто не совпадают с тем, что требуется на работе, и не всегда покрывают вещи, в которых ты «плаваешь». Как составить личный роадмап?
Александр Черный: У Hackerrank недавно было исследование о том, что сейчас работодатели хотят от разработчиков. Вне зависимости от размера команды первым идет problem solving — желание работодателя услышать от инженера четкий ответ, как решить определенную проблему и за какую стоимость.
Алексей Кудрявцев: Как ты относишься к индивидуальным картам развития, где описаны компетенции, тимлидом оцениваются результаты и определяется, что дальше прокачивать?
Александр Черный: Это супер, если на это есть время у обеих сторон. Во всех разговорах о развитии есть одна неприятность: в какой-то момент сотрудник понимает, что здесь развиваться уже негде и меняет место работы в надежде на развитие. Возникает когнитивное искажение — со сменой среды перестаешь думать о реальном развитии, а все силы уходят на адаптацию на новом месте.
Алексей Кудрявцев: Тогда стоит ли ради развития менять работу?
Александр Черный: Если работодатель стабилен и позволяет решать технологические задачи, а команда разработки не меняется, то нет. Не хочется, чтобы разработчики меняли работу, чтобы решать какие-то личные проблемы. Я всегда задаю вопрос на собеседовании, какие действия принял человек, чтобы решить вопросы, которые привели к его увольнению с предыдущей работы.
Кстати, с должностью Head of development и другими менеджерскими позициями разработчика есть свои проблемы. Выше не так много людей, и эта верхушка бизнеса считает тебя самодостаточной личностью, которая должна не только помогать решать проблемы своих сотрудников, но и разбираться со своими трудностями в одиночку. Не уверен, что это правильный подход.
Даниил Попов: Что ты еще спрашиваешь на собеседовании кроме технических вопросов?
Александр Черный: В последнее время я использую кейсы из прошлых проектов наших команд. Мне важно понять, как человек реагирует на различные ситуации. Например, два разработчика по разному понимают какая роль и ответственность у View Model. Ты — третий. Как сделать, чтобы следующий год вы работали все вместе. Мне важно понять, как человек реагирует на такие ситуации. Или ты категорически не согласен с код-ревью, которое провели двое твоих коллег, а вас всего трое. Это проблема?
Я не люблю абстрактные вопросы, поэтому беру конкретный код, который обособлен настолько, чтобы можно было его понять за 30 секунд, и пытаюсь разобраться в soft skill человека.
Даниил Попов: Что для тебя важнее в кандидате: soft или hard?
Александр Черный: Есть вопросы, на которые не хочется отвечать бинарно. С возрастом я стал спокойнее воспринимать уровень hard skill. Не знать какую-то часть — не проблема. Если это принципиально. то можно дать человеку прочитать раздел документации и написать пример работы нужного элемента. В среднем soft skill преобладают, примерно 65% на 35%.
Развитие разработчика предполагает не только углубление знания платформенной разработки, но и расширение кругозора, профессионально овладение soft skill и погружение в смежные отрасли. Если вы серьезно нацелены на развитие, то не пропускайте осенний Saint AppsConf 2019. В Introductory-треке мы обещаем раскрыть максимум инсайтов от коллег из других сфер разработки, а General-трек научит правильно распоряжаться финансами и поможет с экспертной точки зрения взглянуть на защиту персональных данных. Бронируйте билеты по хорошей цене, следующее повышение — 16 сентября.
