Привет, друзья!
Я Илья Попов, действующий senior android разработчик, ментор начинающих андроид-разработчиков и автор телеграм-канала Android Dev Notes.
Составляем программу обучения
Итак, вы приняли решение стать андроид-разработчиком. Как найти дорогу в этом океане неизвестного впереди?
Раз наша цель – работа в андроид-разработке, то первое, что нужно сделать – изучить рынок вакансий и понять, а что от вас вообще нужно работодателям?
Идите на основные сайты для поиска работы (hh, superjob, career.habr, geekjob, getmatch и тд) и проанализируйте пару десятков вакансий джуниоров и то, какие требования в них фигурируют чаще всего. Составьте себе список навыков, библиотек, фреймворков, инструментов для освоения.
Следующее, с чем надо определиться: к какому из пунктов приступать первым? Здесь два варианта:
самостоятельно изучить программы существующих курсов в интернете и на этой основе попытаться понять, в какой последовательности что обычно учат
попросить помощи в составлении программы у компетентного разработчика, который занимается обучением начинающих
Эта программа не будет высечена на камне – вам может потребоваться её изменять, а часто придётся импровизировать и отходить от неё. Но вы теперь не плывёте в океане наудачу – у вас есть маяк. А дальше дело за малым – поднимайте якорь, надувайте паруса и вступайте на тернистый, но интересный путь разработчика!
Лайвкодинг
Важный навык, который вам нужно освоить для успешного прохождения большинства собеседований, и к которому бывает непросто заранее подготовиться: лайвкодинг.
Лайвкодинг – это программирование под присмотром.
Это распространённый способ проверки того, а умеете ли вы, собственно, программировать? Сложно поверить, но на собеседования реально порой приходят люди, которые начитались книжек и решили, что этого достаточно, а сами за код практически не садились, или решали какие-то банальные задачки, переписывая код с экрана ютуба.
Кроме того, лайвкодинг – это программирование в довольно стрессовой ситуации. Под присмотром на работе вы, конечно, кодить будете редко, а вот в стрессовой ситуации "Вася, фичу надо было отдать на ревью вчера, какой статус у задачи?!" вы будете оказываться регулярно, и работодателю важно понимать, что вы в этой ситуации не впадёте в ступор :)
Лайвкодинги бывают разные: могут дать задачки на алгоритмы, могут дать порефакторить плохой/не работающий код, или дать простую задачу типа "Вот метод из API, напиши необходимые классы для отображения контента из этого метода".
Как подготовиться? Найдите того, кто согласится за вами смотреть в процессе программирования, а сами под его присмотром прорешайте десяток-другой easy задач на leetcode, (http://leetcode.com/) и добавьте несколько новых фич в свой проект-портфолио. Заодно и код-ревью с ним попрактикуйте.
Совет: перед выполнением задания на собеседовании обязательно уточните, можно ли писать псевдокодом, или код должен компилироваться.
Псевдокод – описание логики кода без точной реализации, порой даже на русском языке. Это сильно ускоряет процесс, а на собеседовании время сильно ограничено.
И, напоследок: важно понимать, что ваши первые несколько собеседований, скорее всего, провалятся. Важно скрупулёзно записывать после каждого собеседования все вопросы, на которые вы не знали ответа или не до конца знали, и обязательно заполнить эти пробелы прежде, чем идти на следующее. Собеседования – это отдельный навык, который нужно тренировать даже крутым
разработчикам. С каждым разом будет всё лучше :)
7 принципов подготовки тестового задания
Выдержать баланс между простотой и демонстрацией навыков.
Не надо злоупотреблять усложнением кода, но продемонстрируйте самые важные навыки и понимание технологий, которые успеете за отведённое время. Каждое усложнение кода, которое вы делаете ради демонстрации своих умений, опишите в Readme своего репозитория, в который выкладываете код.
Делать задание самому.
Если компания известная, то есть соблазн загуглить, какое тестовое они дают, и есть шанс найти на гитхабе чьё-то сделанное задание и скопировать себе.
Не делайте так. Вы должны уметь объяснить каждую строчку кода и каждое решение, иначе вы сами себя потопите.Сделайте задание за разумный срок или быстрее.
Если вам говорят «да за сколько сделаешь, за столько и сделаешь» – это не означает, что можно на расслабоне делать задание столько, сколько хотите. Постарайтесь или на собеседовании добиться хотя бы среднего ожидаемого времени, или оценить его сами, если вам хватает компетентности. Если понимаете, что не сможете приступить сразу – обязательно скажите об этом. Скажите «приступлю через 3 дня, в четверг вечером». На тестовое задание редко тратят больше 3-5 дней. Не надо сидеть над ним по 10+ дней. Но не надо и спешить отдавать сырой проект на следующий день.
Сразу продумайте структуру приложения.
Делайте так, как написано в ТЗ. Если не написано – уточните у работодателя, есть ли у вас карт-бланш на любое решение.
По структуре обычно предлагают делать всё по Clean, в отдельных слоях. Со своими учениками я дополнительно отделяю presentation, domain и data в отдельные модули, если вам хватает навыков и времени – сделайте так же. Или сделайте разделение на core-feature модули, без разницы.
Для презентейшн-слоя я рекомендую MVVM, как самую распространённую и несложную.
Первым делом – внимательно прочитайте задание и продумайте верхнеуровневую структуру папок/классов, и сделайте под них пустые заглушки, которые потом будете заполнять.
В каком порядке что писать?
Сначала сделайте сетевой слой: реализуйте апи и попробуйте в вашем фрагменте-заглушке вывести в консоль тот контент, который потом будете отображать. На этом моменте вы проверите работу апи, научитесь его маппить, при необходимости обрабатывать ошибки.
Потом реализуйте всю необходимую вёрстку.
И последним шагом соедините полученные данные и view: заполните заглушки во вьюмодели, отобразите контент.
Проверка работоспособности.
Желательно успеть проверить работу приложения на реальном устройстве, не только на эмуляторе. Можете написать в Readme, на каком устройстве проверяли.
Readme
Желательно написать Readme в своём репозитории, в котором подробно объяснить все неочевидные решения: например, что клиновые юзкейсы вы ввели для демонстрации навыков, а вообще они тут не нужны, потому что являются бессмысленным проксированием методов репозитория; а в отображаемом списке вы за отведённое время не успели сделать лоадер, но понимаете его необходимость.
Так вы подстелите себе соломку и покажете, что пишете код осознанно.
Поиск первой работы: подготовка
Давайте сразу уточним: если вы ещё не работали андроид-разработчиком, значит вы ещё не являетесь джуном, а тем более миддлом. Какие бы у вас ни были навыки, вы пока только кандидат на первую работу. Если до этого у вас была работа в IT, особенно в смежных сферах (бэкенд / iOS) – это сильно сыграет вам в плюс.
Да, раньше войти в IT было проще, но это не повод руки опускать. Джуны с опущенными руками точно никому не нужны, и если вы отчаялись, не успев даже найти работу – в IT вам делать нечего.
Подход к поиску работы – такой же, как и раньше: набраться терпения и стучаться во все двери, параллельно качать навыки. У кого-то получается с первого раза, у кого-то с пятьдесят первого.
На ваш гитхаб работодатели смотрят. Проект желательно делать настолько сильный, насколько можете: Clean Architecture и MVVM, DI, REST с кэшированием, сможете в многомодульность – совсем хорошо. А если ещё и опубликуете и решите проектом какую-то мелкую реальную проблему – ещё круче (но это уже скорее миддл-уровень).
Пройдите успешно одно-два мок-собеседования на джуна, убедитесь в наличии необходимых навыков. Обязательно укажите это в резюме.
С точки зрения абсолютного большинства работодателей, миддлом без опыта реальной работы стать практически невозможно, сколько навыки ни качай. Однако, если все остальные способы не сработают, я бы и на низкооплачиваемые вакансии миддла попробовал пооткликаться. Некоторые работодатели под миддлом подразумевают не уровень навыков, а самостоятельного разработчика. Теоретически, таковым может стать и джун, хотя результат его работы будет хуже – но, учитывая пониженный оклад, некоторые компании это может устроить.
Поиск первой работы: способы поиска
Откликаться на все платные и бесплатные стажировки, они регулярно бывают у крупняков типа яндекса, тинькоффа, рэдмэдробота, домру и прочих. Конкурс будет жёсткий, харды нужны сильные. Скорее всего надо будет твёрдо знать Java Core, алгоритмы, коллекции и уметь в юнит-тесты.
Откликаться на все вакансии на всех сайтах с поиском работы: Junior Android Developer, Android Developer. И мониторить все телеграм-чаты с поиском работы в вашей сфере.
Лайфхак: можно воспользоваться промтами в гугле:
"site:hh.ru | site:<...> | site:<...> android developer"Легче всего попасть на "галеры" – проектную разработку в какую-нибудь студию, которая на аутсорсе или аутстаффе клипает проекты для всех подряд. У них обычно требования минимальные. Там будет не "милая приятная айтишечка", но для первого опыта подойдёт.
Сам я работу джуном когда-то нашёл через линкедин. Просто искал там всех андроид-разработчиков senior/lead уровней и писал им в холодную "возьмите меня в команду миддлом, я хороший".
Также я в холодную писал во все студии мобильной разработки, которые нашёл.
Плюс знаю кейс, как кандидат пришёл после курсов гикбрейнса с весьма слабыми знаниями и попросился на стажировку. И для него эту стажировку открыли, т.к. для компании это весьма мягкий способ дёшево получить разработчика в будущем.
Заметьте – не компания выложила стажировку и он на неё откликнулся, а он сам инициировал стажировку в компании своей активностью. Берите пример. Можете даже попробовать усилить этот кейс и придумать оффер со стажировкой самим, и присылать его компаниям, например: "Я бесплатно постажируюсь у вас по ГПХ 3 месяца, потом устраиваюсь к вам и 3 месяца будет испытательный со сниженным окладом, а потом будет оклад по рынку."
Отдать резюме на вычитку кому-нибудь, кто имеет отношение к найму: лиду, hr-у. Соберите от них обратную связь и внесите исправления.
Участвовать в опенсорсе, активно делать туда пулл-реквесты. Вас будут ревьюить, там можно познакомиться с кем-нибудь и попроситься в команду. Аналогичный подход с участием в хакатонах. + всё это пойдёт в резюме и тоже будет полезно.
Ещё раз: готовьте лоб и ломайте им стены.
Стены поддадутся. Я и сейчас регулярно слышу о кейсах успешного устройства джунами. Да, не так часто, как раньше, но слышу.
А если не хотите пробивать стены сами – приходите ко мне на индивидуальные консультации или просто приходите в мой канал Android Dev Notes.
