Архив недели @ddalexiv
Понедельник
Всем привет! На этой неделе с вами @ddalexiv. Я Android Framework разработчик в Яндекс.Авто, до этого работал Android-разработчиком в Bookmate. Закончил и потом преподавал в Школе Мобильной Разработки от Яндекса.
Супер-провокационный план на неделю, stay tuned :)
"СЛЫШЬ ТЫ ЧО Я СИНЬЁР" или можно ли в России получить нормальный CS бэкграунд, чтобы пойти после первого курса на джуна в Яндекс или поехать на стажировку в фаанг?
"Нужно больше алгоритмов" или что происходит во время 6-8ми часов собеседований в Яндекс
У Бабы Нюры из Простодырово офферы на синьора в фб, Элл, Амазон, нетфликс и гугл, ЖМИ, чтобы узнать секрет её энергетической клизмы...
История Яндекс.Авто или как сделать продукт, с которым можно уйти на повышение в сбер
Как разрабатывать 6 форков Android'a одновременно и н̶е̶ поехать кукохой
TBA
Поклонение Бреславу и Замесину или эмпатия в код-ревью
Сегодня поговорим про то, есть ли хорошее высшее образование в России
Я очень часто слышу мнение, что в России нет смысла идти в универ, если ты хочешь стать разработчиком. Ну то есть это можно сделать для корочки (которая редко бывает нужна в реальности), для нетворкинга или для того, чтобы ещё 4 года не думать об армии.
Все эти причины не похожи на то, что должен давать универ в идеальном мире - кругозор, опыт и возможность легко устроиться на работу. При этом в качестве решения проблемы с высшим образованием у разработчиков часто предлагается поехать учиться в другую страну или ботать курсы.
Я понимаю, почему у нас сформировался такой bias относительно Computer Science специальностей в России. Скорее всего многие основывают его на своем негативном опыте обучения в универе, который был какое-то время назад.
Я сам слышал очень много историй, когда вуз рекламирует свою специальность как возможность стать современнным программистом, при этом в реальности в учебном плане оказываются тонны матана и в лучшем случае винформы на паскале.
Да и если мы возьмем например состояние высшего образования лет 10 назад, то кажется объективно мест, где реально могли научить хотя бы хорошо программировать (пусть даже с тоннами матана) было по пальцам пересчитать.
Эти места (например ФИВТ или ВМК МГУ) не очень рекомендовали к поступлению для промышленных разработчиков с мотивацией о том, что туда идут очень много олимпиадников и есть большой шанс стать таким же после выпуска :)
Мне кажется, что за 10 лет ситуация не кардинально, но сильно изменилась. Теперь появились вузы, где хорошо учат именно промышленной разработке и стало больше вузов, в которых хорошо учат матану + программированию.
Думаю многим интересны примеры, сделаю несколько постов про них
ПМИ ВШЭ СПБ
habr.com/ru/company/hse…
spb.hse.ru/ma/inpro/
Глянем программу на сайте вышки. Там есть курсы по плюсам, unix, джаве, фукнкционалке на хаскелле, проект по Android'у или курс про альтернативные языки для jvm. Неплохо для универов, которые всегда позади индустрии, да?
Чуть позже накидаю ещё :)
ПМИ ФКН ВШЭ hse.ru/ba/ami/
Я сам учился на соседней специальности, поэтому довольно хорошо знаю, что там происходит. В первый год питон и плюсы. Во второй очень крутой курс с кодревью по операционкам, где нужно дописывать части небольшой ос, например реализовать локи
Как раз после первого курса на этой специальности многие идут в Яндекс стажерами-джунами или едут на Google STEP, а после второго уже на обычные стажировки в фаанг. Это происходит из-за хороших алгоритмов и плюсов с питоном, которые преподают сами яндексоиды)
То есть базовый минимум, чтобы пройти собеседование уже есть, а в ходе стажировок можно получить боевой опыт разработки реальных проектов. На старших курсах можно выбрать специализацию, например ML или распределенные вычисления и получить более практические навыки.
Таким образом после выпуска с таких программ получается полноценный разработчик с хорошей теоретической подготовкой и неплохим резюме из стажировок и универских проектов. Так реально устроиться на мидла или даже сеньора в тот же Яндекс или поехать на new-grad в фаанг.
Были случаи, когда людям, которые работали в Яндексе парт-тайм со 2-3 курса к моменту окончания универа уже предлагали стать тимлидами. Конечно не ясно, хорошо ли это рано работать и учиться кое-как. Я думаю всё зависит от уверенности человека в конкретной специализации.
То есть если ещё возникают сомнения, то возможно ещё есть смысл поучиться чуть дольше, походить на стажировки и посмотреть что вообще ещё есть.
ПИ ФКН ВШЭ
hse.ru/ba/se/
Я учился на этом направлении, поэтому могу много рассказать про него. На первом курсе C# - особенно круто, если это первый язык, потому что в него сильно проще въехать, чем в плюсы например. На втором курсе джава.
Матан в целом заканчивается на втором курсе, дальше уже курсы по проге или project management. Казалось бы звучит идеально, не так ли? Но на самом деле есть проблемы. Поскольку это направление не подконтрольно Яндексу, как ПМИ, то там есть некоторые прямо странные преподы.
Например у нас была женщина, которая преподавала Project Management не по PM book, а через лабораторные в ms project, где нужно было считать критический путь для проектов обязательно учитывая выходные(!) И да, это были примерно все знания, которые я вынес с этого курса.
Но были и очень крутые курсы, например функционалка от @shwars, мини-курс от @_bravit по еде в корпоративных столовых (на самом деле по Idris), курс по проектированию интерфейсов от career.habr.com/pmanahov или курс по гибким методологиям от CTO Touch Bank linkedin.com/in/borisak/
При этом алгоритмы тоже есть, но они не такие крутые, как на ПМИ. В итоге если у вас есть большое отвращение к математике и вы хотите быть разработчиком, то можете идти сюда, но готовьтесь к тому, что будет много "странного"
Думаю это происходит из-за того, что многие преподаватели, которые преподают вроде бы прикладные предметы либо имеют довольно давний опыт в индустрии, либо имеют только академический опыт. По Талебу им не хватает "skin in the game" Но даже среди них есть крутые тоже :)
ФИВТ МФТИ
mipt.ru/diht/
Тут я сильно подробнее не расскажу, но слышал, что часто выбирают между ним и ПМИ в вышке. Знаю, что оттуда тоже очень популярно ездить на стажировки в фаанг, поэтому думаю там всё тоже хорошо с программой, но доля матана вероятно велика.
Теперь ещё места про которые я слышал, но не могу поручиться за то, что там хорошо.
Всем известное по олимпиадам ИТМО, в котором огромное количество направлений для разработчиков, даже была программная инженерия.
Бауманка, в которой вроде бы хороший ИУ8 для безопасников и направления, связанные с электроникой. Они даже проводят экскурсии в Minecraft :DD
В итоге в 2020 есть довольно много хороших бакалавриатов для разработчиков. При этом я наверняка не назвал про все, поэтому помогайте :)
Стоит ещё добавить, что есть и дополнительное образование, например ШАД, ТехноПарк, Computer Science Center цель которых как раз и подготовить разработчиков к современной индустрии.
Ну и конечно не стоит забывать и полностью про онлайн формат, например praktikum.yandex.ru и geekbrains.ru которые стали уже очень годными. (Практикум уж точно)
Насколько я понял, тут модно делать треды story of my life, поэтому поехали)
Программирование первый раз встретил в кружке по информатике в 6 классе. У нас был крутой препод, у которого много учеников ездили на всерос по инфе. Но для тех, кто только начинает было оч тяжело, мы скорее просто переписывали код с доски и впадали в ступор при любой ошибке.
В итоге я забил на кружок и примерно в 9-10 классе возник вопрос что вообще делать в жизни. При этом в школе на самой информатике мне нравилась прогать, потому что там обычно нужно было делать что-то простое по сравнению с кружком, я даже ходил на школьные олимпиады тогда)
Так я и решил стать программистом.
А на чем пишут все крутые программисты? - подумал я.
Конечно на C++ - ответил интернет.
В итоге тогда я принял очень неправильное решение, скачал какую-то классическую книжку по плюсам причем ещё на английском и начал сам пытаться въехать в структуры данных и ооп, а позже готовиться к олимпиадкам. Ретроспективно понимаю, что потратил этот год очень неэффективно.
Было бы круто в тот момент найти ментора или сгонять в ЛКШ. Но тем не менее в 11 классе я получил диплом на супер халявной олимпиаде по информатике от ИТМО и поступил в московскую вышку. При этом я долго выбирал между ПИ и ПМИ на ФКН и в итоге побоялся математики и выбрал ПИ.
Хотя сейчас уже не уверен, что это был правильный выбор. На первом курсе нас нормально прокачали в C# (по классике вышки отчислив треть курса). Летом я решил, что С# какой-то древний язык, вендор-лок и вообще ничего интересного на нем не напишешь))
В итоге решил уйти в Android-разработку, начав проходить курсы на курсере. А вот кстати если бы @dodopizzadev предлагала бы стажировки на ПИ ФКН, где целый год учат шарп, то может быть я бы не вел этот твиттер сейчас)
После курсов на курсере начал постепенно искать стажировку/школу. Их было в 2015 году прям супер мало, сейчас с этим гораздо лучше. Я пробовал податься в школу от @REDMADROBOT, но не прошёл.
Сделал тестовое для стажировки в @YotaPhone_DE, но оттуда так и не ответили. Зато сейчас у нас в Я.Авто тимлид оттуда) В итоге я нашел только @OneTrakRussia и пошёл туда работать пару месяцев за бесплатно, а потом уже перешёл на оплачиваемую стажировку.
После этого могу дать важный совет - не ходите на бесплатные стажировки, все нормальные компании могут хоть немного заплатить)
В итоге Onetrak оказался типичным российским стартапом для имиджа фаундера, который постоянно пиарился в Справедливой России тем, что он поднимает с колен росиийские технологии. Хотя по факту мы писали только софт и заказывали из Китая девайсы с уже готовым апи для блютуса.
Здесь должна быть шутка про то, что мы в Я.Авто делаем тоже самое, но на самом деле это уже не так и в следующих выпусках узнаете почему ;)
Но не смотря на это в Onetrak были крутые разработчики, у которых можно было поучиться, с одним из них мы позже работали в Я.Авто, а второй ушел в Авито. Передаю привет Артёму и Ване)
@mobileunderhood "Корочка" упрощает эмиграцию, разве нет?
Всё так, спасибо, я забыл упомянуть этот поинт. Например на H1-B нужно иметь либо бакалавриат, либо 12 лет опыта, что довольно много. Для рабочей визы в канаду корочка тоже дает больше баллов. twitter.com/xuzintimur/sta…
Пока я стажировался в Onetrak Яндекс внезапно открыл набор на "Мобилизацию" - это 4 школы (Android, фронт, менеджмент и дизайн), которые идут одновременно, а в конце объединяются в команды и делают вместе проекты.
Я сделал тестовое (до сих пор стыдно за здоровенную rx-цепочку в презентере) и прошёл в Мобилизацию. В целом это было прям супер круто, узнал больше, чем за год самостоятельного изучения Android'a до этого.
Помимо прокачки знаний языка и платформы для меня особенно запомнилась доп лекция про Dagger, который до этого был для меня черной магией. А также ликбез по Teamcity от @the_very и лекция про git от @gurugray, благодаря которым я не использовую гитовый UI студии и merge.
Особенно были полезны код-ревью домашек, общение с опытными разработчиками и опыт реального проекта. Как будто работаешь в стартапе и узнаешь, что сдать супер базовый MVP в срок гораздо лучше чем накидать идеальную архитектуру и не успеть.
Ещё как раз во время Мобилизации я ходил на военку, поэтому получилась такая двойная Мобилизация) instagram.com/p/BKC197sDgH8/
Незадолго до конца Мобилизации мне поднадоело в Onetrak и закрадывались мысли, а что если в Яндекс не возьмут и я решил поискать работу. Нашёл вакансию джуна в bookmate.com, прособеседовался и прошёл. Благо после теории на мобилизации это было не так сложно.
Так я попал в первую в своей жизни крутую продуктовую команду. По технологиям всё было тоже гораздо современнее (на дворе 2016), начинали рефакторить проект на МVP, Dagger и Rx. Аудитория Bookmate на тот момент была уже довольно большой,
поэтому там я в первый раз столкнулся с разбором странных крэшей в RecyclerView и ConcurrentModificationException из-за того, что забыли добавить синхронизацию по коллекции.
Вообще в Bookmate была очень крутая рабочая атмосфера. Перестрелки с нерфами в офисе, пижамный день. После Onetrak для меня было поразительно как на общем собрании сотрудников могут открыто рассказывать о финансовых результатах компании.
После Мобилизации и всего двух технических собеседований в Яндекс (нам зачли школу за некоторые собесы), мне предложили пойти в Яндекс.Коллекции и некий новый проект в геосервисах. В Яндекс.Коллекции меня не взяли, да и я сам не особо туда хотел.
А вот стартап внутри Яндекса звучало интересно. Ещё финальная секцию у меня проводил сам руководитель нового продукта linkedin.com/in/andreyvasil… Как вы могли заметить у него тогда получилось меня заинтересовать)
Ещё тогда HRы сказали мне, что наняли "крутого тимлида", им оказался @bwdude, которого я тогда вообще не знал, но его голос казался мне подозрительно знакомым))
To be continued в части про Я.Авто
А Вова, кстати, в Яндексе работал тогда!
Вторник
Recruiter: Do you have a CS background? Me: Yes, absolutely My CS background: https://t.co/eDnPsr0CDN
Идеально завершит эту цепочку твитов следующий мем
twitter.com/dan_abramov/st…
Начну традицию открывать каждый день с мема)
Сегодня поговорим про собеседования в Яндекс.
Относительно собеседований в Яндекс довольно давно сформировалось мнение, что туда проходят только олимпиадники, а обычные работяги заваливаются на алгоритмах. Можно посмотреть хотя бы на то, как заминусили Лешу Шаграева на хабре habr.com/ru/company/yan…
По-моему, это мнение отчасти правда, а отчасти нет. Давайте разберемся почему так и для начала поймём что из себя представляют собеседования в Яндекс и узнаем почему их так много. Для мобильного разработчика флоу собеседований выглядит следующим образом
HR Скрининг (может быть пропущен при реферере)
Предварительное собеседование
Онсайт (порядок не важен)
2.1 Секция с написанием кода
2.2 Секция по платформе
2.3 Секция по архитектуре (обычно для >=мидл)
2.4 АА-секция (алгоритмы)
Финальные секции (от 1 до 3)
В итоге может получиться от 5 до 9 секций.
Можно заметить, что большую роль в увеличении количества собеседований играют финальные секции. В Яндексе очень редко бывают такие специальности разработчиков, которые работают только в одной команде и больше нигде.
Даже в нашем редкой специализации в разработке Android-прошивок это как минимум не только Яндекс.Авто, но ещё и колонка и телевизоры. Android-команд в Яндексе много десятков, поэтому тут можно сказать, что треть собеседований добавляется автоматически из-за размера компании.
Далее может возникнуть резонный вопрос - зачем нужны целых 4 секции на onsite? Неужели не будет достаточно 2? Тут хорошего ответа у меня нет, но я думаю, что обычно в Яндексе стремятся быть максимально уверены в человеке, которого нанимают.
Благо поток людей довольно большой из-за силы технического бренда. Как результат, я не помню ни одного случая, чтобы разработчик в моей или соседней командах не проходил испытательный срок.
Теперь давайте пройдемся по каждому собеседованию чуть подробнее.
Предварительное собеседование - тут все довольно просто, это несложная задача/две + немного теории. Обычно цель этого этапа узнать опыт кандидата, примерный уровень и проверить навыки написания кода.
2.1 Секция с написанием кода. Здесь дают либо большую задачу с несколькими итерациям (как в реальной жизни) или же 2-3 небольших задачи. Причем самая сложная из задач не сложнее, чем leetcode medium.
2.2 Секция по платформе. Тут основная цель проверить знания кандидата по Java и Androidу. Иногда здесь могут дать задачку с написанием кода, но иногда и просто набор теоретических вопросов.
2.3 Секция по архитектуре
Это классическое System Design интервью, с разницей лишь в том, что дизайнить нужно не распределенную систему, а мобильное приложение. Цель собеседования - оценить кругозор и глубину знаний кандидата.
2.4 АА-секция (алгоритмы)
Это самое сложное собеседование для многих кандидатов и про него больше всего спорят нужно ли оно. В целом это почти как секция написания кода, только её проводит опытный интервьювер и задачи немного сложнее (но все-равно в пределах leetcode medium).
Здесь уже присутствует элемент догадки до решения, а так же огромное количество возможностей посадить баг. При этом если одну из остальных секций можно завалить и перепровести потом, то отрицательный фидбек с большой вероятностью означает отказ в найме.
Финальные секции
Тут все как обычно, её проводит нанимающий менеджер (обычно тимлид) и задает какие-то специфичные для конкретной команды вопросы. Тут в целом оценивается насколько разработчик будет "fit" в конкретную команду.
Если разработчик понравился многим командам, то у него появляется выбор между командами.
Чуть ниже поясню свою точку зрения по этой теме, а пока опрос для вас - "Нужна ли алгоритмическая секция для мобильных разработчиков?"
Тут под алгоритмами подразумевается решение задач из Cracking the Coding Interview, то есть по типу leetcode/hackerrank.
В опросе предсказуемо побеждает ответ нет, поэтому поделюсь своей позицией. В моем небольшом опыте проведения "Секции с написанием кода" (легкая алгоритмическая секция) и последующей работы с людьми, которые её проходили действительно есть корреляция
между результатами секции и тем насколько человек быстро и качественно выполняет задачи на работе. При этом естественно корреляции между результатами этой секции и общим уровнем разработчика я не замечал, потому что кроме этого есть довольно независимые навыки.
Например опыт во внутренностях Android'a или умение автономно решать большие задачи. Поэтому я скорее считаю, что алгоритмическая секция нужна, но задачи, которые задают на АА-секции (которая более сложная) все-таки требуют больших алгоритмических навыков,
чем реально необходимо мобильным разработчикам. Но опять же повторюсь, у меня нет опыта сотен собеседований и руководства десятками разработчиков, в отличие от Леши Шаграева. Возможно, что действительно и результаты АА-секции коррелируют с абстрактным качеством разработчиков.
Тут конечно ещё стоит озвучить аргумент к позиции за, который работает во многих больших компаниях, особенно в бекенде. Поскольку в Яндексе например очень много внутренних разработок, то довольно большой скоуп скиллов приходиться качать заново при приходе в компанию,
поэтому есть смысл спрашивать у разработчиков именно абстрактное умение писать код. В целом если так подумать, то этот аргумент не сильно, но применим и к Android'у, ведь никогда не знаешь что произойдет с мобильной разработкой через несколько лет,
может быть выйдет Fuchsia и мы все будем писать на Dart или победит Kotlin-multiplaform и все iOS разработчики будут пересаживаться со свифта. Да и даже если так не произойдет, то умение научиться поднимать простой рест-сервак или грепать логи YQL'ем иногда пригождается в работе
Последнее, что хочу добавить про собеседования. Этот флоу довольно кастомизируемый в разных частях компании в плане проведения секций, естественно можно проводить дополнительные секции или заменять некоторые из озвученных в зависимости от специализации разработчика.
Например, я слышал, что во многих компаниях, точно в Lyft и Bolt, есть секция с live-codingом небольшого приложения в студии. Я в Яндексе такой не видел, но мне кажется было бы круто, если бы она появилась в каких-то командах.
Кажется с помощью неё можно идеально оценить практический срез знаний кандидата, так же посмотреть как он дебажит код или строит архитектуру.
Среда
Сегодня поговорим про то, как получить оффер в FAANG для мобильного разработчика
Учитывая разницу в качестве жизни у нас и в Европе/штатах, а так же, что среди разработчиков распространено знать английский, то многие рано или поздно задумываются о том, чтобы завести трактор. Ниже я расскажу некоторые подводные камни и лайфхаки при релокейте из России.
Как вы могли заметить по предыдущим твитам, своего опыта переезда у меня нет, но у меня много друзей, которые успешно переехали и я тоже ресерчил этот вопрос. Первый вопрос, которые обычно возникает - зачем нужно переезжать и куда можно переехать?
Про это есть отличные доклады от @nekdenis youtube.com/watch?v=TsZ3wi…
youtube.com/watch?v=B3F3Yq…
В них подробно разбираются флоу переезда, а так же основные направления их особенности и для каждого табличка с средней зп, налогами и типичными расходами, вроде аренды или детского сада.
Дальше обычно стоит задача узнать какие компании перевозят в нужную страну, а какие нет. В случае FAANG'a это сделать довольно легко - везде кроме нетфликса ответ да, причем фб и гугл не релокейтит напрямую в штаты. Для других компаний и во время эпидемии это уже не так легко
Поэтому не найдя никаких списков компаний, которые перевозят разработчиков из России я решил сделать свой
engineer-petr.github.io
Там можно найти список из более 50ти компаний, которые перевозят разработчиков из Росссии с указанием стран и статуса хайринга из-за ковида.
Буду рад, если найдутся желающие актуализировать информацию, добро пожаловать в репку github.com/Engineer-Petr/…, можно просто даже через создание issue или ответ под этим постом.
После того, как вы определились c набором компаний, начинается довольно длинный процесс собеседований. Ниже поделюсь лайфхаками, которые помогут вам сильно увеличить свои шансы на успех
Подготовьтесь перед прохождением собеседований.
Оказывается, существует целая индустрия для подготовки к собеседованиям. Если вы выбрали FAANG, то стоит точно научиться решать medium с leetcode за полчаса.
Есть даже специальные группы для подготовки к интервью, например t.me/FaangInterview Если знаете ещё, накидывайте
На leetcode постоянно сливают какие задачи попадаются на собеседовниях или в Online Assessment в faang. Если вы очень хотите попасть в какую-то конкретную компанию, то стоит обратить на это внимание leetcode.com/discuss/interv…
Есть бесплатный сервис pramp.com для тренировки собесов. Сначала вы 30 минут выступаете в роли собеседующего, а потом собеседуют вас. Качество интервью там среднее (много индусов), но если ставить собес на вечер (утро в US), то можно попасть на native спикеров
Есть условно-бесплатный сервис interviewing.io Похоже на прамп, но нужно заполнить анкету и ждать инвайта, поэтому аудитория лучше. Мне в первый раз попался русский разработчик из Apple. Важно, что там можно купить интревью с реальным разрабом из фаанг за 100$
Начинайте процесс собеседования с конца вашего списка приоритетов. Можете податься в компании в которые вы точно не пойдете чтобы получить опыт в собеседованиях и в English speaking. А если у вас и получится туда пройти, то их офферы помогут поторговаться с целевой компанией.
Всегда подавайтесь через реферала, это сильно увеличивает ваши шансы попасть на HR скрининг до которого в больших компаниях серьезный фильтр по резюме.
Реферала легко найти в профильных чатиках или зайдя на вкладку люди нужной вам компании в LinkedIn. Там в топе обычно ваши 2-ые контакты, которым можно написать. Рекомендую писать русским разработчикам, которые сами переехали, они с большой вероятностью смогут пореферить.
Перед отправкой резюме рекрутеру прогоните ваше резюме через app.grammarly.com В идеале скиньте native спикеру или просто уже переехавшему знакому) Не знаю, насколько реально на это обращают внимание, но многие рекомендуют так делать.
Не стестняйтесь тюнить резюме под конкретную вакансию. Наверняка в вашем опыте много вещей, которые вы сделали на последнем месте работы, поэтому можете оставить те, которые будут релевантны под конкретную вакансию. Это поможет вашему резюме пройти фильтр рекрутера.
Если вы недавно закончили вуз и у вас уже много опыта работы, то имеет смысл убрать дату окончания универа и возвраст из резюме. Насколько я понимаю, в европе и штатах не принято работать во время универа, поэтому весь опыть до graduation date рекрутер может проигнорировать.
Когда вам будут назначать не стесняйтесь спросить что будет на интервью и готовиться именно к тому типу интервью (leetocode, system design), который вам назначили
Если вы идете в фаанг не на new-grad мобильным разработчиком, то c большой вероятностью вам придется проходить system design для бекенда. Чтобы к нему подготовиться есть много разборов популярных задач на youtube, например youtube.com/watch?v=ZgdS0E…
Если вы прошли в фаанг, то конечно не стесняйтесь торговаться. Не смотря на то, что может показаться как-будто крутая компания смиловалась над вами и вам нужно прямо сейчас принять оффер, вам могут предложить минимум вилки из-за того, что вы не знаете рынок в этой стране.
Чтобы узнать какая вилка сейчас актуальна можно использовать levels.fyi и teamblind.com (двач про фаанг) Так же есть крутая классическая статья про то, как торговаться - kalzumeus.com/2012/01/23/sal…
Истории успеха переезда и больше советов можно найти на том же leetcode или в профильных чатах и группах
vk.com/internship_it
t.me/sns_traktor
t.me/FloodInterview
t.me/sns_internships (про стажировки)
Если вы опытный Engineering manager (L6-L7 в терминах гугла), а не разработчик, то будте готовы, что весь ваш опыт руководства тоже скорее всего не засчитают и предложат собеседоваться на Senior разработчика
Подсказывают, что ещё конечно же есть всем известный Cracking the Coding Interview, если не читали, то вперед. А так же чуть более простая альтернатива leetcode - hackerrank.com
Спросили как тренировать behavioral interview Такая опция есть на pramp или можно посмотреть видеогайд youtube.com/watch?v=PJKYqL…
В целом можно найти список вопросов для фб или амазона и выписать свои ответы на них, чтобы в случае чего не тупить и сразу вспомнить свои мысли)
Что делать после переезда или где задать вопросы про жизнь в другой стране непосредственно людям оттуда? Есть гига-чат в телеграме Startup Never Sleeps, в котором есть подчаты по регионам. На самом деле он не про стартапы, а просто про IT сообщество
t.me/startupneversl…
Небольшой оффтоп
Вообще чаты SNS - крутая тема, там есть чаты про карьеру, зп, филиал двача тоже, даже свои локальные мемы про Кузьмина, который сломал систему и переехал из гугла в хуавей в мск на 850к))
Четверг
Не стоит забывать, что собеседоваться можно не только для оффера, но и покатушек по разным странам на онсайты. Сейчас естественно это не актуально из-за коронавируса. В моей команде был разработчик, который так ездил раз 10, мы прозвали его HR-туристом.
С коронавирусом появляются и новые возможности для прохождения собеседований. Можно безбожно читерить начиная от кучи шпор, заканчивая друганом, который будет беспалевно гуглить во время собеседования. Если подумать, то такая возможность появляется once in a lifetime)
Сегодня поговорим про историю Яндекс.Авто. Актуальность мема станет понятна ближе к концу)
В паре твитов расскажу чем мы занимаемся, а то нас очень часто путают с автономными автомобилями и авто.ру (поговаривают, что Воложу не нравится наше название, но ничего лучше не придумали).
Мы встраиваем все сервисы Яндекса релевантные в автомобиле в бортовой компьютер. Фото
Ну или в новом дизайне вот так
Яндекс.Авто зародился после простой установки Android-приложений Навигатора, Яндекс.Радио, Яндекс.Стора и других приложений Яндекса в бортовой компьютер (головное устройство, aka ГУ) Toyota RAV4 в 2016. Тойоте понравилось и она предложила нам сделать Яндекс не просто приложением,
а основным UI своей Android-системы. Так наняли трех Android-разработчиков (включая меня), одного дизайнера и стартовала разработка продукта. Довольно быстро мы поняли, что хотим сделать свой набор приложений (приложение FM-радио, звонилка, настройки) и лончер.
В автомобиле особенно неудобно нажимать на тачскрин, поэтому во всех дизайнах проскакивала фича с несколькими приложениями на одном экране, как на фотке снизу навигатор + музыка. Так мы поняли, что приложением здесь не обойдешься и придется лезть в систему.
Не смотря на то, что ни у нас не было опыта кастомизации андроида, буквально за пару дней мы запилили эмулятор, который отрисовывал бары, сжимающие окно приложения. Это в целом похоже на стандартный режим split-screen в Android 7, но нам был нужен другой UX.
Мы сделали его через изменения в PhoneWindowManager, которые размещает окна в UI (окно приложения, навбар, статусбар, диалоги). А ещё время поджимало и мы поняли, что писать отдельное приложение для каждой фичи - долго.
В итоге мы решили запихнуть все наши приложения в лончер и получить то, что на сейчас модно называть "суперапп". Последствия от этого решения мы огребаем до сих пор и даже начали "распил" лончера, где выносим его части в систему или отдельное приложение.
Почему плохи такие супераппы - падение одного компонента по дефолту тянет всю систему, что не очень похоже на Fault tolerance, которого хочется в автомобиле. Ещё из-за этого при тестировании сложно быстро понять в каком компоненте ошибка, потому что падает сразу всё.
Так же у супераппов долгое время старта приложения из-за загрузки всего кода приложения, а не on-demand. Сначала у нас был Android 4.4, поэтому мы огребли с этим по полной) В Automotive быстрые чипы и новые Android'ы доходят долго из-за тяжелого процесса R&D и тестирования железа
При этом как и в любом монолите код довольно быстро становится запутанным из-за отсутствия явно указанных зависимостей. А так же растет размер апк и время сборки. В самые тяжелые времена мы доходили до размера лончера в 150мб.
Если вспомнить хорошие решения, которые мы сделали на момент начала разработки, то мы сразу же изолировали всю работу с vendor-specific API в отдельное приложение, которое назвали "сервисы". Собственно это был фактически набор bindable сервисов, с которым общался лончер по AIDL.
Как пример такого API, которое разное на разных вендорах - API для управления FM-тюнером. Поскольку до Android 10 не было стадартного апи для радио, поэтому каждый вендор придумывал своё. И с помощью этого компонента Яндекс.Авто работает на на множестве разных автомобилей.
Ближе к релизу мы начали расширять команду, наняли опытного разработчика из Yota Devices. Он помог нам с интеграцией изменений в оконной системе в реальный девайс и рассказал как нужно сделать "сервисы" по-нормальному (перенести их прошивку и сделать сдк для приложений)
В итоге мы успели зарелизится почти в срок - примерно через 9 месяцев после начала разработки. Думаю, что для софта в автомобиле это мировой рекорд :) Обычно разработка там длится годами. Вот фото команды на презентации Я.Авто (это разрабы, менеджеры, тестировщики и дизайнеры)
Это был сентябрь 2017 года, мы были первым железным продуктом Яндекса, тогда ещё не было ни Алисы, ни Яндекс.Станции.
Ну ладно, ещё был Яндекс.Кит когда-то давно)
После релиза у нас сформировалась очередь из автопроизводителей, которые хотели нас к себе встроить, но пожалуй самой интересной нашей интеграцией была интеграция в Яндекс.Драйв, потому что каршеринг запускался буквально за 4 месяца (хотели вообще за 2)
Нам надо было портировать свои изменения в Android'e и написать "сервисы" для двух устройств, которые запускались в каршеринге. И не забыть про механизм сброса после поездки между пользователями. Естественно получилось не оч, что подтвердил обзор Варламова
youtube.com/watch?v=dNP9GW…
После этого мы поняли, что большое количество проблем у нас идет не от софта, а не от железа и с китайским партнером сделали железку, которая удовлетворяла нашим требованиям.
Для каршеринга заодно переделали механизм сброса - перешли на честных пользователей в Android и выпилили наши ручные очистки кэша приложения. И для каждого нового клиента мы стартуем все приложения в Guest пользователе,
который потом автоматически удаляется со всем пользовательскими данными. Заодно сделали так называемый "кросслогин", когда ваш Яндекс-аккаунт автоматически появляется во всех приложениях Яндекса на ГУ, когда вы садитесь в каршеринг.
То есть можно просто сказать "Алиса, поехали домой" и "Алиса, включи мою музыку" и построится маршрут до вашего дома и включится ваш плейлист. Насколько мы знаем, ни в каком каршеринге в мире такой фичи нету)
Через год Варламов выпустил ещё одно видео, где отметил, что мы зря времени не теряли. youtube.com/watch?v=4__qVg…
Таким образом к осени прошлого года у нас уже было достаточное количество устройств в проде, ГУ почти в каждой машине каршеринга, а так же возможность установить нас в старую машину - auto.yandex
Но при этом были и проблемы - из-за технического долга и долгого релизного цикла мы не успевали релизить необходимые фичи и пропускали дедлайны. Насколько я понимаю это и разногласия в vision продукта привели к тому, что руководитель Я.Авто ушел в сбер vc.ru/tech/109081-ko…
Вместе из ним ушла небольшая часть команды, которая к текущему моменту разрослась до 60 разработчиков. Я в определенный момент перешел в отдельную команду, которая занимается Android Framework разработкой, то есть портирует Я.Авто на новые устройства.
В разработке приложений тоже было много изменений, у некоторых приложений появила целая отдельная команда. Особенно интересно взаимодействие между нашей командой и командой разработки приложений. Мы провайдим им API, который сначала был в форме AIDL сервисов.
С этим было много проблем, во первых нужно уметь обрабатывать дисконнекты от сервисов, во вторых с ними полностью нельзя работать с главного потока, что усложняет код приложений.
На самом деле вызовы binder быстрее, потому что весь Android SDK в них, поэтому неблокирующие вызовы к сервисам вполне можно делать на главном потоке (ровно так же, как мы можем делать startActivity с главного потока).
Теперь вопрос в аудиторию - как в Android можно подключиться к своему bindable service синхронно на главном потоке?
Подсказка, обычный serviceConnectionCallback вызывается тоже на главном потоке и поэтому если после bindService ждать вызова коллбэка, то будет дедлок (главный поток залочен на вызов коллбэка на главном потоке)
Таким образом это процесс сможет на своем главном потоке получить коллбэк к сервису и после этого отдать инстанс сервиса в binder thread.
Если ничего не поняли, то это норма, я сам очень долго въезжал в этот хак. Влад Кузнецов, который у нас это придумал, даже делал доклад на эту тему
youtube.com/watch?v=YhS8bi…
Пятница
@mobileunderhood Еще имеет смысл на Glassdoor заглянуть, там тоже попадаются актуальные задачи с интервью
Правильно подсказывают, что на glassdoor имеет смысл заглянуть, там для многих компаний есть содержание собеседований
twitter.com/evnik0/status/…
Тема сегодняшнего дня - как иметь 6 форков Android'a и оставаться при этом ментально здоровым :)
При разработке Яндекс.Авто мы сразу поняли, что чем больше у нас изменений в самом Android'e, тем дольше происходит процесс портирования этих изменения на новую версию Android или новый девайс.
Таким образом, мы с самого начала старались минимизировать изменения, которые у нас были в AOSP. А если все-таки они нужны, то поставлять их в удобном виде для интеграции. Например в случае с изменениями в оконной подсистеме мы остановились на варианте,
когда изменения в самих исходниках это буквально одна строчка, а наш код поставляется в отдельно подключаемом джарнике при сборке Android'a. Но помимо изменений в самом фреймворке, нам нужно было каждый раз портировать наш компонент "сервисов" на новое устройство, потому что
в стоковом Android не было какого-то либо стандартного API для управления кондиционером или получения оборотов двигателя. Google тоже активно смотрел на различные варианты использования Android'a, заметил автомобильный юзкейс и уже в 2016 году показывал на Google IO
прототип форка Android'a для автомобилей. Идея такая же, как и в Android Wear для часов, Android TV для телевизоров и Android Things для IoT - взять Android, добавить в него немного нужного, убрать немного ненужного и получить ещё один вектор дистрибуции ОС и своих сервисов :)
Так и начал разрабатываться Android Automotive OS - flavour Android для встраивания в автомобили. Влад из нашей команды подробно рассказывал о нём на AppsConf youtube.com/watch?v=w_gvym…
Ниже я немного освежу доклад Влада о том, как мы сейчас используем Android Automotive
Самое главное, что дает нам Android Automotive - стандарт работы с автомобильными апи. С ним появляются API, которых нам так не хвататло - например, для получения данных из CAN-шины, обработки кнопок руля, настройки звука для различных динамиков.
При этом стоит заметить, что Android Automotive OS официально не зарелижен, но не смотря на это уже используется в некоторых моделях Volvo - там Android 9 без Google Play. Ещё несколько авто на подходе. Важно, что гугл не открывает эту систему для third-party apps со своим UI.
Но если вы разрабатываете музыкальное приложение, то вендор сможет сам отрисовать UI за вас, используя ваши реализованные MediaSession и MediaBrowserService как провайдеры данных. Аналогичная история с мессенджерами, которые могут показывать только свои уведомления
Возможно в будущем Google договорится с автопроизводителями на распространение обычных приложений, но тут пока есть есть несколько нерешенных проблем, например стандартный UI Android приложений неудобно использовать в автомобиле и
пока что нет какого-то фреймворка для построения удобного UI, как например в случае с Android TV.
При этом естественно ваш плеер не сможет поменять температуру в салоне, даже если бы разработчики и хотели поддать жару на "Highway to Hell". Это произойдет потому что для того, чтобы использовать CarHvacManager из нового Car API потребуется специальный пермишен с правами
"system|signature", то есть он выдается только для системных приложений или для приложений, которые подписаны ключом прошивки.
Давайте посмотрим на изменения в Android Automotive OS. По картинке ниже можно заметить, что всё припилено как бы "сбоку" - так и есть, по факту Automotive это просто новые сервисы в Car Service, то есть обычный Android от них не зависит и может работать без них
При этом Car Service даже не работают в процессе system_server, поэтому если вдруг они упадут, то в хорошем случае временно перестанут работать фичи, завязаные на автомобиль, не затрагивая остальной фреймворк, например навигатор продолжит навигиторовать.
Давайте посмотрим использование Car API на примере. Мы хотим добавить попап "Заглушите двигатель" при использовании Яндекс.Заправок в Яндекс.Авто. Сначала мы подключим к нашему приложению библиотеку Car (пока можно собрать только по исходникам в аоспе) android.googlesource.com/platform/packa…
После этого мы можем создать объект Car и подключиться к нему. В коллбэке после подключения мы получим CarSensorManager, который отвечает за подписку на изменения состояния автомобиля. Код очень напоминает получение системных сервисов из Android'a :)
После получения CarSensorManager мы можем работать с ним как с обычным Android SDK, просто подписывамся на листенер и проверяем, что стейт зажигания сейчас статус выключено. Так просто мы вы считали данные автомобиля, вы восхитительны!
Для нас так же приятным дополнением к стандартизированным API является то, что часть логики платформы, которую мы раньше писали сами с Android Automotive можно использовать из коробки.
Например, раньше у нас был самописный сервис, который подписывался на данные от датчика света и менял тему в системе в зависимости от времени суток (если у пользователя выбрана "Авто" тема в настройках).
В Android Automotive уже есть готовый сервис, который делает тоже самое и приложению настроек достаточно лишь обратиться к этому сервису. Но учитывая, что релиза ещё не было, с Android Automotive наверняка должны быть какие-то проблемы.
На самом деле так и есть, например в случае с сервисом для изменения темы API к нему приходится писать самому, какого-то готового просто нету. Но как говорится - недопиленный стандарт это лучше, чем его отсутствие, поэтому мы не жалуемся :)
Небольшое изменение в расписании, завтра поговорим про эмпатию в код-ревью, а потом вместе выберем тему для воскресенья)
Суббота
Сегодня поговорим про эмпатию в код-ревью.
Я не слышал раньше, чтобы эта тема поднималась в росиийском IT-сообществе, поэтому мне кажется будет интересно поговорить об этом и у вас всегда есть опция закидать меня ссаными тряпками и сказать, что у нас тут не гейропа, а особый путь :D
Что такое эмпатия? Про это есть супер-доклад от @abreslav youtube.com/watch?v=Oz4NaO…
Там очень хороший ликбез по поводу того что такое эмоции, почему их можно показывать на работе и к чему хорошему это приводит :)
Почему мне кажется важным говорить об эмпатии? Мне кажется, что в российском IT культура общения инженеров сильно отличается от общемировой. Я слышал несколько историй разработчиков, которые после переезда сталкивались с фидбеком о том,
что во время дискуссий собеседникам кажется, что они настроены грубо и враждебно. В целом понятно, почему такое происходит - у нас принято все говорить прямо и по делу, это начинается со физ-мат школы, где ошибки не проговариваются, а отмечаются красной ручкой. И продолжается
в универе, где почти всегда лекции проводятся с позиции, что есть всегда правый непредрекаемый авторитет - преподаватель, у которого последнее слово в любой дискуссии. После того, как разработчики выпускаются из универов и приходят на работу, то оказывается, что
тут уже нету такого непредрекаемого авторитета и приходится общаться на равных. У многих это получается, но иногда получается споры, как у слайда из доклада выше.
Я думаю, что в код-ревью как раз довольно часто не хватает эмпатии, потому что по определению это процесс критики вашей работы. Для начала поделюсь своей историей про то, как меня заинтересовала эмпатия в код-ревью
Когда мы только начинали делать Яндекс.Авто у нас почти не было культуры хорошего ревью. Пулл-реквесты в несколько тысяч строк ревьювились за десятки минут. Возможно, это было нормально для степени развития продукта и задач, которые были тогда.
Сейчас нас уже не 3 человека и нет задачи сделать быстро, а есть задача сделать максимально качественно, поэтому, я заметил, что в некоторых командах ревью проводится максимально серьезно. Подсвечиваются даже опечатки, неправильная грамматика в комментариях к коду и
разводятся диспуты относильно неймингов.
Не могу точно сказать насколько правильно ревьювить код настолько строго, но могу точно сказать, что сейчас мы проводим ревью кода хорошо в контексте снижения количества ошибок и снижения сложности понимания кода.
Но как говорится всегда должно быть одно но)
После того, как меня стали ревьювить в некоторых командах, то периодически у меня возникало чувство, что ревьюверы не пытаются помочь мне в написании кода и доведении качественного решения до продакшена во время,
а скорее заботятся лишь об одном - о том, чтобы закоммиченный код строго соответсвовал их майндсету и манере написания кода. То есть я не чувствую то, что ревьювер находится в моей же команде, а не работает против меня.
После такого ощущения я пошёл немного происследовать этот вопрос и понять один ли я такой или нет. Выяснилось, что на эту тему уже много статей, например
google.github.io/eng-practices/…
medium.com/@sandya.sankar…
pullrequest.com/blog/7-habits-…
Из них особенно часто в некоторых командах я очень часто видел нарушения следующих best practices из статей выше:
Be kind.
Explain your reasoning.
Unhelpful behavior #1: passing off opinion as fact
Unhelpful behavior #4: asking judgmental questions
Давайте разберем несколько правил ревью, которые мы нарушали
Unhelpful behavior #1: passing off opinion as fact / Explain your reasoning.
Вместо того, чтобы написать
This component should be stateless.
Рекомендуется объяснить свою точку зрения более аргументированно, потому что в код-ревью ни у кого нету 100% объективной позиции.
Например можно написать вот так
Since this component doesn’t have any lifecycle methods or state, it could be made a stateless functional component. This will improve performance and readability. Here is some documentation.
Unhelpful behavior #4: asking judgmental questions / be kind
Вместо того, чтобы написать
“Why did you use threads here when there’s obviously no benefit to be gained from concurrency?”
Можно написать
“The concurrency model here is adding complexity to the system without any actual performance benefit that I can see. Because there’s no performance benefit, it’s best for this code to be single-threaded instead of using multiple threads.”
Такие вопросы подразумевают, что существовало более простое и очевидное решение, а также заставляет человека написавшего код защищаться, потому что адресованы не только к коду, но и к нему самому.
После того, как я поделился своими мыслями с нашим тимлидом, мы обсудили в общем чатике температуру кодревью в наших командах и как минимум некоторые люди заинтересовались этой темой и стали изменять тон своих комментов на ревью
Мне кажется, что вопрос эмпатии в код-ревью стал более актуален с момента, когда мы все сидим по домам и общаемся друг другом только письменно, где сложно считать эмоции человека, если они не написаны явно.
@mobileunderhood Главное - использовать мемы и гифки. В фб есть встроенные в phabricator поиск по мемам и можно добавлять свои. Новый тренд - "мотивирующие картинки". https://t.co/yb2h2LbNsq
По-моему это best practices для эмпатии в код-ревью! twitter.com/ruggerprogramm…
К чему приводит отсутствие эмпатии после код-ревью? Я помню, что как-то после рабочего дня один из разработчиков в нашей команде в шутку сказал, что после прохождения ревью из 50 комментов ему уже "жить не хочется".
По-моему в этой шутке была доля правды, потому что в целом восприятие большого потока критики требует определенного эмоционального интеллекта и усилий. По-моему как раз работа ревьюверов заключается в том, чтобы снизить количество этих усилий.
Например, мы часто пользуемся таким лайфхаком - в каждом ревью пытаемся отмечать не только вещи, которые кажутся неправильными, но и вещи, которые сделаны круто. Это позволяет немного перетянуть процесс ревью из критики в некий небольшой фидбек с плюсами и минусами
Давайте выберем тему на завтра
Воскресенье
Сегодня поговорим про то как разрабатывать AOSP
Для начала давайте поймем что такое андроид. Вкратце, это linux + своя system-wide реализация jvm (ART) cо своим байткодом (dex). На ART работает сам Android Framework, который позволяет приложениям отрисоввываться и взаимодействовать друг с другом или самим фреймворком.
Каждое приложение в Android работает в отдельном процессе и IPC происходит не стандартными средствами линукса (пайпы, сокеты), а через binder - драйвер в ядре. Binder был придуман для того, чтобы превратить апи ОС из набора системных вызовов в object-oriented OS environment 😎
Все интенты на запуск компонентов из других приложений (активити, сервисов, бродкастов), которые вы посылаете на самом деле являются binder транзакциями. Так же любое обращение к Android SDK, например получения пакетов, установленных на устройстве это тоже binder транзакция
Но не смотря на то, что вызовы Android SDK это чаще всего IPC их можно вызывать с главного потока. Binder находится в ядре, поэтому оверхед будет минимальным. Google постоянно оптимизирует производительность binder, потому что от этого зависит скорость работы все приложений.
Давайте посмотрим как устроен сам фреймворк. Все системные сервисы, такие как ActivityManagerService, PackageManagerService работают в процессе system_service. Если ваш телефон просто так перезагрузился, то с большой вероятностью один из системных сервисов упал и
произошёл soft reboot - показалось бутлого, процесс system_service рестартанул, при этом вся линуксовая часть работала и не перезагружалась. Тоже самое можно сделать командой adb shell stop. Это быстрый способ перезагрузить только фреймворк и он часто юзается при разработке.
Как собрать AOSP? Тут хороших гайдов огромное количество, официальная документация гугла очень подробная, даже есть кодлаба - source.android.com/setup/start
Добавлю лишь то, что процесс сборки довольно долгий. Нужно выкачать 200гб + несколько часов cold билд
При этом стоит заметить, что в итоге вы получите img файлы (прошивку) для эмулятора и сможете запустить его на вашем компьютере. Чтобы собрать прошивку на ваш любимый смартфон вам нужны исходники производителя, а так же device binaries - реализация вендором HAL Android'a.
HAL - Hadrware Abstraction Layer (почти дословно набор плюсовых хэдеров), которые вендор должен заимплементить, чтобы андроид заработал на его железке. Чтобы найти исходники для своего девайса можно глянуть на xda-developers.com - сообщество разработчиков модов андроида
Некоторые вендоры, например Sony или сам гугл выкладывают свои device binaries в общий доступ. С помощью них можно собрать себе стоковый андроид (без GMS), который запустится например на пикселе. developers.google.com/android/drivers
Важный дисклеймер!
Пожалуйста, не пытайтесь собрать Android на маке. Это возможно, но это путь уровня установки себе Gentoo. Гугл официально не рекомендует этого делать и не гарантирует, что в будущем ничего не сломается. А обычно в новой версии андроида хаки для сборки меняются.
Основная проблема в том, что Android местами референсит апи линукса прям с хостовой системы. При этом если вы попытаетесь поднять linux VM и собраться на ней, то отвалится аппаратное ускорение для эмулятора из-за того, что вы встроили себе виртуалку(эмулятор) в виртуалку)
Код аоспа лежит в монорепозитории, который является просто набором существующих гитовых репозиториев. Для удобной работы с ними написали специальную тулзу - repo. Пожалуй, аосп монорепозиторий это одна из немногих вещей, которая удерживает нас от переезда в Яндексовую монорепу :D
Android до 7.0 собирался мейком. То есть для каждого модуля есть Android.mk, в котором вы прописываете как его собрать. При сборке вы выбираете так называемый таргет - тоже mk файл, который описывает какие модули должны войти в сборку. После Android 7.0 начался
переход на Soong - новую билдсистему (Make уже 44 года, пора на пенсию). При этом из-за быстрого этапа конфигурации модулей и легковесности инкрементальная сборка андроида очень быстрая - минуты при изменения кода во фреймворке.
Если посмотреть на директорию out после сборки Android'a, то можно заметить, что на выходе у нас не один img файл, а много. Например system.img - в котором содержится сам framework, vendor.img - в котором содержатся дополнительные приложения или sdk от вендора.
То есть довольно частым юзкейсом при разработке Android'a является перепрошивка только того img, в котором были изменения.
Если мы можем менять код прошивки, то нам открываются множество возможностей для наших приложений. Перечислю несколько из них. Во-первых мы можем сделать приложение системным или подписывать его ключом прошивки, чтобы они получили какие угодно пермишены.
Во-вторых мы можем сделать приложение persistent. Это значит, что система не будет убивать ваше приложение при нехватке памяти (вообще никогда). А при крэше нашего приложения система будет запускать его ещё раз.
На этом мой crash-course закончен - задавайте ваши вопросы)
Забыл важную деталь - поскольку вторая и третья буква в AOSP это опен-сорс, то вы можете засабмитить ваш багфикс или фичу в апстрим. Для этого даже есть специальный github для repo - gerrit.
Кстати фреймворк с недавнего времени тоже можно писать на котлине, котлин завели в систему сборки, в systemui он уже тащится
Сегодня поговорим про то, как получить оффер в FAANG для мобильного разработчика https://t.co/hJHvwUraLv
Дайджест тредов недели
Story of my life - twitter.com/mobileunderhoo…
Есть ли хорошее высшее образование в России - twitter.com/mobileunderhoo…
Собеседования в Яндекс на Android-разработчика - twitter.com/mobileunderhoo…
Как получить оффер в фаанг - twitter.com/mobileunderhoo…
Сегодня поговорим про то как разрабатывать AOSP https://t.co/bilAsqiSlW
История Яндекс.Авто - twitter.com/mobileunderhoo…
Android Automotive - twitter.com/mobileunderhoo…
Эмпатия в код-ревью - twitter.com/mobileunderhoo…
Android Framework разработка - twitter.com/mobileunderhoo…
Всем спасибо за неделю! Было интересно поделиться своими идеями, надеюсь вам понравилось! С вами был @ddalexiv, подписывайтесь на канал, ставьте лайки под видео)
Дайджест тредов недели Story of my life - twitter.com/mobileunderhoo… Есть ли хорошее высшее образование в России - twitter.com/mobileunderhoo… Собеседования в Яндекс на Android-разработчика - twitter.com/mobileunderhoo… Как получить оффер в фаанг - twitter.com/mobileunderhoo…
Ссылки на треды этой недели можно найти в twitter.com/mobileunderhoo…
