Петр про Android и IT

Софтовые вопросы на интервью 🙂

Часто когда человек идет на софтовую секцию без подготовки, некоторые вопросы могут ввести в ступор, либо он даст ответ который не понравится интервьюеру.

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

1️⃣Расскажи о фиче которую получилось сделать и которой гордишься

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

2️⃣ Расскажи о своем самом большом провале

Ответ на этот вопрос должен быть по технике STAR(situation - target - action - result), простыми словами - ожидается что если вы совершили факап, вы сделали выводы и больше его не повторяете. Например, забыли предусмотреть миграцию базы данных, выпустили обновление - обнаружили проблему, быстро ее устранили остановив обновление, сделали хотфикс. С тех пор всегда помните про миграцию при выпуске новых версий.

3️⃣ Что для тебя потенциально важно при выборе компании, выбора основного места работы, на что смотришь

Обычные варианты ответа - интерес к проекту, микроклимат в команде, количество переработок, уровень зп

4️⃣ Что тебя мотивирует в работе?

Интерес к продукту, результаты деятельности, которыми можно поделиться с семьей/друзьями, профессиональное развитие

5️⃣ Что наоборот демотивирует?

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

6️⃣ Чувствуешь ли ты что есть где-то просадки по скиллам?

Хитрый вопрос, где вам предлагают самим обозначить свои слабые стороны. Рекомендую отвечать вширь, например, в случае Android - это может быть изучение KMP, либо каких-то специфичных технологий. Не стоит говорить что у вас есть слабости в актуальном стеке

7️⃣ Как выглядел у вас процесс разработки?

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

8️⃣ Как понимали на продукте что движетесь в правильном направлении?

Возможный ответ - продуктовые метрики из аналитики, фидбэк от пользователей, фидбэк от бизнеса

9️⃣ Что важнее интересы бизнеса или пользователей?

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

1️⃣0️⃣ Были ли задачи с высокой неопределенностью?

Попытка определить ваш уровень - чем он выше, тем чаще вы сталкиваетесь с такими задачами, тем быстрее привыкаете их решать

1️⃣1️⃣ Сталкивался ли ты с неэффективными процессами?

Все точно сталкивались с чем-то неэффективным, например, с частой сменой курса, плохим планированием или оценкой - продумайте свой вариант ответа

1️⃣2️⃣ Приходилось ли принимать рискованные решения?

Опять-таки вопрос помогает определить ваш уровень, чем он выше, тем больше рискованных решений вы принимаете. Но любой риск должен быть на чем-то основан, лучше всего когда он основан на данных(аналитике и т.п)

➡️Под конец подчеркну одну вроде бы очевидную вещь, но тем не менее ей часто пренебрегают. Как на софтовом интервью, там и на хардовом стоит проявлять интерес к продукту и компании, вникать в то что рассказывают, задавать вопросы, выражать заинтересованность. Старайтесь проводить интервью на максимально доброжелательной волне и не забудьте сделать домашние заготовки по вопросам выше, тогда шансы на успешное прохождение увеличатся.

Итоги января 💥💥💥

Давно не виделись, как вы?👋

У меня начало года выдалось максимально сконцентрированным:
⚫️ основная работа - кайфую от нового места, коллег и проекта, пока все супер интересно и позитивно
⚫️ запилил несколько видео эксклюзивно для учеников на тему подготовки к собеседованию по разным темам, где разбираю самые частые вопросы и ошибки при ответах
⚫️ стартовал разработку личного сайта (оказалось это еще тот геморрой)
⚫️ продвигаемся вперед с учениками, есть и результаты - у одного два оффера в среднего размера компании, у другого на подходе оффер в бигтех, fingers crossed 🤞
⚫️нашел интересную тему для первого публичного видоса, сейчас ее прорабатываю, есть цель закончить до середины марта (предвижу еще один геморрой, так что посмотрим)

⚡️ А что с tg-каналом - с ним тоже все в порядке, просто был меньший фокус, готовлю сейчас подробный пост про софтовое интервью, на мой взгляд тема с одной стороны недооцененная, с другой очень важная, которая легко может повлиять и на решение о приеме на работу и о размере будущей ЗП. Это будут вопросы с реальных собеседований которые проходил я или мои ученики, они будут поинтереснее классических "расскажи о своем провале / успехе". Приведу свои рекомендации как пройти эту секцию успешно.

P.S. не стесняйтесь присылать вопросы, если они есть, как минимум смогу помочь каким-то советом в личке, в идеале может получиться пост, полезный для многих

Итоги года 🎄

2024 подходит к концу, пора подвести итоги. Год был неоднозначный, но во многом и интересный - для себя я отрыл новые виды деятельности, которые мне нравятся и имеют перспективу развития. Но давайте по порядку

✅ Что получилось сделать в этом году:

🟢Уволился с престижного, но токсичного места работы
🟢Организовал большую семейную поездку в Египет
🟢Стартовал менторство, успешно помог дойти до оффера 5 людям, многим помог советами и консультациями в других форматах. Для себя открыл новый источник заработка
🟢Стартовал телеграм канал. Для меня до сих пор челлендж находить интересные темы, но понемногу у меня начало получаться это делать
🟢Сделал "небольшой" ремонт, который перерос в капитальный. Сроки изменялись четыре раза, в итоге и сроки и бюджет выросли в 2,5 раза от первоначальных
🟢Редкий год, когда лето не прошло мимо меня - много гулял с дочкой, купался в озере, восстанавливал ментальное здоровье
🟢Несмотря на все сложности и дела пробежал свою 10-ку на Московском марафоне
🟢Получил офферы в топовые компании и устроился в максимально классную команду на крутых условиях

❌ Какие цели я провалил:

🔴 Спорт - несмотря на то что пробежал десятку, не было регулярности и не смог довести показатели до целевых
🔴 Книги - маловато читал в этом году, буду исправлять в следующем, нашел для себя классную серию Метро (2033 и дальше) - советую тем кто не читал и кому интересна тема постапокалипсиса
🔴 Английский - со второй половины года не прокачивал его, а этот навык требует регулярности. Хотя и в целом у меня все неплохо, уверен что можно сделать еще лучше. Инвестиции в английский отбиваются всегда

❓Что дальше?

Буду стараться идти по нарастающей и заниматься тем, что получается и что нравится. Есть большие планы по менторству: постоянное улучшение и доработка программ, разработка нормального сайта, и одна из главных целей - выход на Youtube с качественными видео. ТГ канал также планирую развивать, есть идеи новых форматов и проектов, надеюсь получится их реализовать.

💥💥💥В завершении хочу поздравить всех с Наступающим и пожелать чтобы ваши начинания(и продолжения) в Новом году привели к крутым результатам, самореализации, заработку и развитию! 💥💥💥

Неочевидные вопросы с собесов

Технические пост про вопросы, которые были на недавних собесах⬇️⬇️⬇️

Disclaimer: не буду приводить очень подробных ответов, дам короткие, при необходимости сможете поискать по ним более подробную информацию.

1️⃣ Допустим при вставке в HashMap произойдет коллизия и в один бакет попадет много элементов, список поменятся на красно-черное дерево. На основе чего будет балансироваться это дерево, если ключи не наследуют Comparable

Ответ:
Для этого случая используется метод System.identityHashCode(obj: Object). Он всегда возвращает уникальный хэшкод для объекта, который связан с местом в памяти где он хранится. Кстати, он же используется для дефолтной реализации hashCode()

2️⃣ Когда лучше использовать Serializable чем Parcelable ?

Ответ(спорный, но его ждал интервьюер):
Несмотря на то что Parcelable быстрее и для большинства кейсов более предпочтителен, при сериализации объектов на диск или БД лучше использовать Serializable, т.к. при изменении структуры класса, Serializable позволит не потерять данные. В Parcelable сложно поддерживать структуру, если нарушить порядок записи или чтения данных, будут проблемы с восстановлением объекта.

3️⃣ inline функции - на чем все таки экономим

Ответ:
Inline имеет смысл использовать в функциях высшего порядка (т.к. тех, которые имею лямбды в параметрах) и часто принято отвечать на этот вопрос, что экономия достигается за счет того что не будут созданы объекты типа FunctionX. Обычно такой ответ удовлетворяет интервьюера, но не всегда. На самом деле нет ничего страшного в создании дополнительного объекта, есть кое-что потяжелее, на чем позволяет экономить inline, а именно на замыканиях (closure). Closure (замыкание) — это функция, которая захватывает переменные из своей внешней области видимости и может использовать их даже после завершения выполнения этой области.

4️⃣ Как работают под капотом Atomic-и

Ответ:
Внутри класса переменная, с которой работает Atomic, объявлена как volatile. Это гарантирует видимость изменений переменной между потоками, так как volatile обязывает процессор и память синхронизировать значение. Atomic-и поддерживают потокобезопасные операции с переменными без использования блокировок (lock, sychronized). Это достигается благодаря использованию низкоуровневых примитивов процессора, таких как CAS (Compare-And-Swap).

5️⃣ Choreographer и методы invalidate / requestLayout

Ответ:
Choreographer — это системный класс Android, который управляет таймингом для обновления UI. Он используется для синхронизации операций отрисовки с частотой обновления экрана (vsync).
invalidate() и requestLayout() добавляют задачи в очередь на следующий кадр через Choreographer. Это гарантирует, что изменения произойдут синхронно с циклом отрисовки. При этом:
- invalidate() добавляет задачу отрисовки.
- requestLayout() добавляет задачу измерения и расположения.
- Т.о. requestLayout() не вызовет перерисовку, для нее нужно вызвать invalidate()
Если вызвать invalidate() 100 раз - Choreographer схлопнет вызовы до одного, перерисовка не вызовется 100 раз.

💥Если готовитесь на позицию Middle/Senior разработчик, будьте готовы к вопросам про коллекции, многопоточку, GC, корутины, custom views - как правило на эти темы заходит разговор практически на любом собесе, чем выше грейд, тем больше вопросов вглубь о том как это работает под капотом. Часть из таких вопросов я сегодня и привел, надеюсь для кого-то будет полезно.

Что делает резюме непривлекательным

Резюме - первое звено в конверсии поиска работы и оно супер важно, поскольку в худшем случае может запороть весь поиск. Главное правило от которого стоит отталкиваться:

Резюме должно выглядеть профессионально и продавать вас как эксперта в своем деле.

Вот топ ошибок, которые периодически вижу в резюме, которые присылают на ревью:

🔴Промежутки работы менее года
Создает впечатление нестабильного сотрудника. Мало кому хотелось бы потратить n времени на поиск и обучение человека, который уйдет не отработав и года

🔴 Упоминание учебных проектов и курсов
Сигнализирует о недостатке реального опыта, создает впечатление вчерашнего студента и удешевляет резюме

🔴Упоминание о том что работал над проектом один
Вызывает сомнения в навыках командной работы и качестве кода. Непонятно какой код писал человек, если его никто не ревьюил

🔴Неуместное фото
Фото - фактор который может сыграть против вас. В Европе вообще не принято использовать фото в резюме, в РФ это допустимо, но убедитесь что фото "продает" вас как профессионала. Лучше вообще без фото, чем с неподходящим.

🔴Упоминание возраста
Еще один фактор, который может сыграть против очень молодого или наоборот очень опытного специалиста. К сожалению, эйджизм присутствует и лучше не давать лишнего повода для отсева по критерию возраста

🔴Непонятная структура резюме
Из резюме непонятно какие обязанности выполнял человек, каких результатов добился, какие технологии использовал. У резюме должна быть четкая структура:
- summary (коротко ваш опыт и достижения)
- опыт работы в обратном хронологическом порядке (с достижениями и тех. стеком)
- образование, навыки

🔴Опыт работы менее 3-х лет
Часто может быть стоп-фактором для многих компаний, многие делают автоотказ по этому признаку

📌Откликаться с резюме, которое может натолкнуть на неправильные ассоциации и выставить ваш опыт в неверном свете - плохая идея. Убедитесь что в вашем резюме нет этих ошибок и рекомендую попросить более опытных людей сделать ревью вашего резюме, это может значительно улучшить конверсию в отклик.

🔥 - или любая реакция если этот пост был полезен

Как улучшить прохождение скринингов

Для начала немного разберем внутрянку скрининга ⬇️⬇️⬇️

💡Основная идея скрининга - быстро отсеять неподходящих кандидатов не тратя дорогого времени разработчиков.

Стандартный формат - анкета-опросник который проводит рекрутер, в анкете должны быть четкие вопросы и ожидаются конкретные ответы. Это важно, т.к. HR не имеет тех-компетенций и не может оценить развернутые рассуждения, а сравнить с эталонным ответом - легко. Например, при такой постановке ответ будет конретный и короткий:

Какого ключевого слова нет в Kotlin ?
Варианты ответа: open abstract unblock

а в таком вопросе дать короткий конкретный ответ не получится:

Расскажи зачем нужно ключевое слово volatile?

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

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

Последнее время многие компании отходят от стандартного формата, вот несколько примеров:

➡️ Вместо созвона HR и опросника - telegram бот (или другое свое решение) с тестом и ограничением по времени в 1 минуту на ответ. При этом часто вопросы в тесте могут быть, мягко говоря, неоднозначными и вгоняют в ступор.
Такие тесты рекомендую проходить с компьютера, не с телефона и пользоваться всеми возможностями интернета и нейросетей.

➡️Рекрутер проводит созвон, на котором задает вопросы для рассуждений и делает запись звонка, затем передает разработчикам, те отсматривают запись и дают фидбэк.
Оч странный формат, т.к. во-первых, сильно тратит время разработчиков, во-вторых, HR не имеет тех-компетенций и выглядит такой скрининг очень крипово.

➡️ Скрининг-интервью с разработчиком на 30-40 минут.
Можно сказать что это упрощенный вариант тех-собеседования, он выглядит уже намного лучше предыдущего варианта, где вопросы для рассуждений задаются HR-ом, хотя и главный смысл скрининга - не тратить время разработчика, на мой взгляд, здесь теряется. Главный рецепт - готовиться как к техинтервью, выделить полноценное время для прохождения.

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

📣Как улучшить вероятность прохождения скрининга:
⚫️понимаем что формат скрининга может быть разным, стараемся заранее узнать подробности того как он будет выглядеть
⚫️готовимся под формат проведения - изучаем тех-вопросы, делаем домашние заготовки
⚫️относимся более серьезно к самому скринингу - прохождение с телефоном вместо компа может сильно снизить ваши шансы
⚫️не стесняемся использовать помощников в виде гугла и нейросетей, где это возможно

С нуля до трудоустройства

Сегодня поделюсь очень важным для меня кейсом. В большинстве случаев я помогаю ребятам доходить до результата, повышая уже имеющийся уровень. В этом же кейсе мы проделали реально большой путь от знания базовых конструкций kotlin до изучения того как пишутся современные Android-приложения, подготовки к собесам и как результат - трудоустройству.

Ниже отзыв ученика⬇️⬇️⬇️

Была цель вкатиться за 6 месяцев, на зп 200к+, при этом у меня было мало времени на обучение (часа 4 в день 5/2 и даже эти 4 часа не всегда мог выделять).

С момента обсуждения с Петром условий обучения до моего первого рабочего дня (получилось устроиться на 260к) прошло около 7.5 месяцев (задержки получились с моей стороны + всегда стоит закладывать время на прохождение собесов).

Петр с нуля научил разработке, затем подготовил к собесам и помогал разобраться с первыми тасками на работе! Я не самый одаренный человек, но объяснения Петра раскрывали материал с такой стороны, что даже до меня доходила самая суть)

Могу смело рекомендовать Петра как эксперта и не только в андроид-разработке, но и в обучении ей 👍

💎 На самом деле от себя добавлю что все получилось в том числе, потому что ученик очень мотивированный и просто трудяга, далеко не каждый сможет сконцентрироваться на цели, довериться и 7,5 месяцев фигачить.
Безумно рад что все получилось🎉🎉🎉. Кстати, фактически получили три оффера, выбрали самый подходящий и интересный.

#кейс

Круто ли быть тимлидом - мой опыт

У меня большой опыт работы на позиции Senior, с другой стороны суммарно около 5 лет я поработал в качестве Teamlead, сегодня хочу написать свои мысли на тему

Стоит ли стремиться расти в тимлида?

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

В какой-то момент ты достигаешь уровня Senior, возникает вопрос как расти дальше. И тут самый понятный вариант - это развитие в тимлида. Сама по себе идея кажется неплохой - ты становишься руководителем других программистов, что во первых звучит уважаемо💪, а во вторых должно дать прибавку к ЗП💲.

Но на моем опыте могу сказать что сама по себе это очень неоднозначная позиция, которая во-первых сильно отличается от роли разработчика, во-вторых имеет много ноюансов

Из очевидных плюсов работы тимлидом:

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

🟢 больше денег чем у простого синьора (но не всегда, об этом дальше)

🟢 больше понимаешь о продукте, требованиях, векторе развития продукта

🟢 Из этой позиции возможен дальнейшей рост по управленческой линии до СТО 

Но и минусов тоже хватает:

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

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

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

🔴 перестаешь осязать результат собственной работы, поскольку на то чтобы написать код самому остаётся мало времени

🔴появляются вопросы связанные с поддержанием духа команды, микроклиматом и разбором любых ситуаций, что тоже отнимает время и силы (и как бы не сильно оценивается)

Основная ловушка: считается что тимлид получает больше денег чем синьор. С одной стороны в среднем это так, с другой - на моем опыте часто были ситуации, когда я сам получал больше своего тимлида. Вообще ЗП связана с ценностью сотрудника и нередки случаи когда ЗП ценного специалиста выше чем его руководителя.

Еще один сайд эффект - тимлид постепенно теряет техскиллы, поскольку времени на код остается мало. Это может стать проблемой при поиске новой работы, т.к. вакансий на тимлида значительно меньше, а требования и отбор выше чем на синьора. При этом чтобы подготовиться на вакансию синьора, придется наверстать потерянные знания.

➡️Кому подойдёт работа тимлидом: тем кто хочет роста в управленца, кому надоело писать код, кто не боится взять ответственность за работу команды и готов к переработкам. Точно не стоит идти в тимлида только из-за большей ЗП и кажущейся престижности, особенно если вы не особо любите митинги и не готовы проседать по хард-скиллам

🔥 - или любая реакция если было полезно)

"Ну и зачем вам это надо?)"
- самый популярный плакат на забеге

Недавно в сториз рассказал о том, что выполнил свою годовую спортивную цель, решил написать пост, т.к. многим это было интересно, поэтому сегодня не совсем про IT и Android.

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

Основаная идея простая - раз в год сделать забег на 10 км в новом городе

Чем меня привлекает эта история:

🏃 10 км - не слишком простая дистанция и к ней нужна подготовка, это заставляет находить время на спорт, когда его вообще нет

🏃 с другой стороны дистанция не слишком сложная, чтобы оставить на ней суставы или потерять сознание (знаю такие случаи)

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

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

В этом году к списку моих финишей (Питер, Тбилиси, Павловск), добавился четвертый город - Москва. В забеге участвовало 15к человек, я прибежал 5410-м с временем 53:42, что является моим вторым временем. Но оно для меня вторично, основная цель - оставаться в форме, не забрасывать тренировки.

Кстати, слот на 10ку на московском марафоне закончился наверное где-то за полгода, если решите сделать забег на каком-то популярном турнире, учитывайте что лучше купить его сильно заранее.

Ну и отдельный кайф для меня - выбирать следующее место для забега, т.к. по моей концепции - каждый раз это должно быть новое место/город. Здесь очень много вариантов - от крутых международных туриниров, до небольших локальных, в зависимости от возможности всегда можно что-то выбрать.

P.S. заценили мой "блатной" стартовый номер?)

Backend Driven UI (BDUI) подход, плюсы и минусы

Сейчас многие компании выбирают BDUI для реализации экранов или иногда целых приложений.

Идея подхода проста - бэкенд определяет как должен выглядеть экран приложения. Т.е. в приложение прилетает условный json, который описывает верстку экрана - какие элементы должны отображаться на экране и в какой последовательности. Более навороченные версии умеют строить схемы взаимодействия между экранами, описывать действия по клику на элементах и т.п.

✅Основной плюс - этот подход отлично работает с интерфейсами, которые могут часто меняться - вам не нужно делать перевыпуск приложения в маркете, изменения можно сделать буквально за пару часов, сильно сокращается time-to-market.

На моем опыте этот подход мы использовали аж в 2016 году, когда разрабатывали приложения для контроля работы мерчендайзеров. Кстати, однажды рассказывал, какие они фокусы вытворяли, чтобы обмануть наше приложение. Так вот, мы столкнулись с проблемой того что анкета мерчендайзера часто менялась и приходилось перевыпускать приложения, что занимало много времени. После применения BDUI подхода для анкеты, ее можно было легко настраивать на сервере и обновлять, не перевыпуская приложение. После этого использовал данный подход еще в нескольких компаниях, включая Яндекс.

Однако как и другие технологии, этот подход имеет свои недостатки:

❗️ Сложность реализации - требуютcя силы бэкенд и мобильных разработчиков. В зависимости от потребности к гибкости решения, трудозатраты могут сильно расти. Необходимо учитывать множество корнер кейсов и стратегии ошибок, когда с сервера прилетает кривая верстка. Нужно закладывать много времени на тестирование.

❗️ Сложность поддержки - скорее всего вы захотите делать доработки для своего BDUI и столкнетесь с вопросами как поддерживать приложения со старыми версиями BDUI, как дорабатывать его компоненты, как версионировать и релизить новые версии BDUI

❗️ Не подходит для тяжелых вьюх, либо там где важна скорость отрисовки. Основной минус подхода - в случае когда нужна скорость отображения пользователю, плавность и хороший пользовательский опыт, лучше не использовать этот подход, т.к. в нем больше накладных расходов на отрисовку, чем в случае классического подхода

❗️ Более хитрая схема взаимодействия с бэкендом - дополнительная нагрузка на сервер, большое количество дополнительных запросов. Кроме того вам понадобится продумать что показывать пользователю на стороне приложения, пока экран не загружен, нужно ли заранее делать подгрузку данных об экране, чтобы быстрее показать ее пользователю и т.п.

⚡️Подход backend-driven UI хорошо подходит для определенных кейсов, когда интерфейс пользователя часто меняется, позволяет существенно сократить time-to-market. Но имеет свои недостатки, в виде более сложной разработки и поддержки, меньшей скорости отрисовки и дополнительных накладных расходах и плохо подойдет для сложных интерфейсов. Выбор любого инструмента для работы должен быть хорошо продуман, BDUI здесь не исключение и за очевидными бонусами стоят не совсем очевидные минусы, учитывайте это при выборе подхода.

🔥 - или любая реакция, если этот пост был полезен

Тестовые задания здорового человека курильщика

Тестовые задания уже считаются моветоном при собеседовании, т.к. занимают у кандидата больше времени, чем другие форматы. Со стороны компании тоже формат нельзя назвать удачным, т.к. есть вероятность что за кандидата задание выполнит другой человек.

Тем не менее, тестовые задания все еще встречаются и я разделяю их на две категории:
⚫️сомнительно, но окэй
⚫️ ужас-ужас

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

Для начала немного вводных. Описание тестового о котором идет речь занимает 3 листа A4, вкратце:

🔴 приложение содержит экраны - авторизация, регистрация, чаты, чат, профиль с редактированием, по каждому экрану есть подробное описание, каждый экран делает свои запросы в сеть к апишке с протухающим токеном
🔴 "Обработка ошибок и состояния загрузки"
🔴 "Стиль оформления по своему желанию, он тоже будет оцениваться."
🔴 "Проект должен быть выложен на Github, качественное ведение git"
🔴 "Приветствуются дополнения, не описанные в задании"
🔴 кастомный шрифт, валидация данных, загрузка / отображение картинок
🔴 на задание отводится до 7 дней

Вишенка на торте - само тестовое задание нужно сделать до техсобеса (и даже до созвона с hr)

Какие проблемы у такого задания:

1️⃣Задание просят сделать до техсобеса (или до первичного hr созвона)
Надо ли говорить что это очень плохая практика, т.к. вам ничего не рассказали о проекте, компании, вы не общались с людьми с которыми придется работать. Возможно вы сразу не сойдетесь или решите что стэк или компания вам не подходит. В этом случае тратить время на задание - пустая затея.

2️⃣Допустимое тестовое не должно отнимать больше 4-8 часов чистого времени, это уже негласный золотой стандарт. Если оно занимает неделю, возникает вопрос - как насчет оплаты такого тестового? Супер редко компания готова его оплатить. Поэтому если задание по вашей оценке явно занимает больше восьми часов чистого времени, я бы даже не стал думать о его выполнении.

3️⃣ Составителю тестового стоило бы подумать что конкретно он хочет проверить с помощью этого тестового, сейчас это набор очень разных и ненужных вещей, многие из них можно выкинуть и проверить вопросами на собесе.

Напоследок пара кейсов про мои кринжовые тестовые:

➡️Один раз я сам просидел неделю с тестовым заданием, выполнил его, учел все требования, но получил отказ, после чего словил выгорание и наверное еще неделю восстанавливался.

➡️С другим тестовым было ограничение в 24 часа на его выполнение, в итоге я закончил под утро, но по итогу тоже дальше не срослось.

В обоих случаях это были тестовые в крупные компании с сильным HR брендом, поэтому я согласился на их требования. Но крайне рекомендую 10 раз подумать надо ли вам тратить время на такие тестовые и такие компании, скорее всего это не оправдано и вы попусту потеряете время.

#вопрос_с_собеса
Где в Android нарушаются принципы SOLID ?

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

💚 Решение 💚

1️⃣ Single Responsibility
У класса должна быть только одна причина для изменения.

Чтобы найти нарушителя, нам нужен какой-то класс, который имеет несколько ответственностей, т.е. один занимается разными вещами. Пример - класс Context - содержит много разных ответственностей, ниже указана часть его методов:

// работа с компонентами
public abstract void startActivity(Intent var1);
public abstract ComponentName startService(Intent var1);

// работа с ресурсами
public final int getColor(int id)
public final Drawable getDrawable(int id)

// работа с файлами
public abstract FileInputStream openFileInput(String var1)
public abstract boolean deleteFile(String var1);

Какое улучшение к этому дизайну можно предложить: имело бы смысл выделить дополнительный слой абстракции под каждую группу методов, а сам Context мог бы управлять этими группами, примерно такие могли бы быть вызовы:

context.components.startActivity()
context.permissions.checkPermission()
context.files.deleteFile()

2️⃣ Open - Closed
Классы должны быть открыты для расширения, но закрыты от модификации.

Намеков на отклонение от этого принципа является использование множественные if-конструкции в коде.Например, в классе View можно увидеть метод dispatchActivityResult c кодом

if (who == null) {
       onActivityResult(requestCode, resultCode, data);
} else if (who.startsWith(REQUEST_PERMISSIONS_WHO_PREFIX)) {
        //...
} else if (who.startsWith("@android:view:")) {
        //...
} else if 

Напрашивается рефакторинг через создание специального интерфейса:

 interface ActivityResultDispatcher {
  fun canDispatch(who: String)
  fun dispatchResult(...)
 }

..и использования итерирования по массиву этих объектов, вместо if-конструкций

 val dispatchers: List<ActivityResultDispatcher>
 for(dispatcher in dispatchers) {
  if (dispatcher.canDispatch(who)) {
    dispatcher.dispatchResult(...)
  }
 }

Как результат - легко будет добавить или удалить новый кейс без внесения модификации в сам класс.

3️⃣ Liskov Substitution
Реализация может быть подставлена вместо абстракции, код не должен сломаться.

Намек на отклонение от принципа: явное приведение параметра к какой-то реализации. Пример - класс ResourcesImpl с методом:

TypedArray obtainStyledAttributes(@NonNull Resources.Theme wrapper,  
        AttributeSet set,  
        @StyleableRes int[] attrs,  
        @AttrRes int defStyleAttr,  
        @StyleRes int defStyleRes) {  
   
   final XmlBlock.Parser parser = (XmlBlock.Parser) set;
   //..   
}

при передаче в качестве AttributeSet любой имплементации кроме XmlBlock.Parser произойдет ClassCastException

4️⃣ Interface Segregation
Интерфейс не должен быть слишком раздутым, лучше иметь несколько более узкоспециализированных интерфейсов.

Намек на отклонение от принципа: при реализации интерфейса несколько методов часто остаются пустыми, используется один метод. В этом случае имеет смысл разделения интерфейсов:

public interface TextWatcher {  
    public void beforeTextChanged(...);  
    // практически всегда нужен только этот метод                           
    public void onTextChanged(...);  
    public void afterTextChanged(...);  
}

5️⃣ Dependency Inversion
Абстракции не должны зависеть от реализации, реализация должна зависеть от абстракций.

Здесь отклонением от принципа может быть неявная зависимость на какой-то объект

class Fragment {
 FragmentManager mChildFragmentManager = new FragmentManagerImpl();
}

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

P.S. как вам такой формат? 🔥 - если было полезно, буду чаще разбирать вопросы с собесов

Перспективы изучения Android

💬Периодически мне задают вопросы о перспективах инвестирования времени в изучение разработки под Android высказывая различные опасения. Хочу в этом посте раскрыть свое мнение по этим вопросам

Имеет ли смысл изучать разработку под Android, может быть Android скоро заблокируют в РФ и разработчики будут без работы?

Android - открытая, open-source операционная система, заблокировать ее целиком видится мне невозможным. Да можно доставить неприятности, например, заблокировать Google-сервисы в РФ. Но такие прецеденты уже были у Huawei, притом на глобальном рынке, по итогу они вполне себе живы, сделали свои Huawei-сервисы и выпускают телефоны. Более того им понадобилось нанять много Android программистов для разработки своих сервисов.

Не перестанут ли компании вести разработку под Android в связи с санкциями и невозможностью размещаться в Google Play?

Для Android существуют альтернативные сторы приложений, которые позволяют распространять заблокированные гуглом приложения, да и сама платформа позволяет делать установку приложений из любых источников. Поэтому компаниям интересно развитие приложений под эту платформу, они могут быть уверены что смогут из распространить. Крайне маловероятно что компании будут урезать разработку под эту платформу.

А стоит ли вообще заниматься программированием, скоро же AI заменит разработчиков, они станут не нужны?

Развитие AI действительно впечатляет, сейчас сложно спрогнозировать насколько далеко оно зайдет. Чтобы полностью заменить разработчика, потребуется держать в контексте не только код проекта(который может быть огромным), но и архитектуру всей системы, требования бизнеса, договоренности, документацию и много других переменных. Мой прогноз - AI станут крутыми помощниками для программистов, они позволят выполнять работу быстрее, возможно изменят характер работы разработчиков, но о полной замене пока очень рано говорить.

А что насчет кроссплатформы, может она вытеснить нативную разработку?

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

❗️ Хорошим маркером для понимания востребованности технологии являются вакансии, рекомендую перед тем как углубляться в изучение чего-либо, проверить насколько много вакансий открыто на рынке по нужной технологии, а также какие вилки у Junior / Middle / Senior позиций. Считаю это одним из основных критериев для подгружения в изучение какой-либо технологии, если вы рассматриваете коммерческую разработку.

Привет, ребят👋

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

🤝 О чем этот канал: Меня зовут Петр, я работаю в IT более 15 лет, последние 10 из них занимаюсь Android. Я активно помогаю другим разработчикам прокачать свои знания, вырасти в грейде и увеличить свой доход. На канале пишу про темы связанные с моим опытом, полезные для разработчиков посты, делюсь кейсами учеников и отвечаю на вопросы.

💥Истории из моего опыта:

Как впервые познакомился с Android в 2010-м году

Самые интересные проекты, в которых я поучаствовал

Как я участвовал в конкурсе Telegram

История про собеседование в Facebook
(Meta - запрещенная в РФ организация)

История как наш продукт взламывали

🔥Полезные посты:

Подход к поиску работы ч1

Подход к поиску работы ч2

Красные флаги на собеседовании

Как подготовиться к выходу на новую работу и пережить синдром самозванца ч1

Как подготовиться к выходу на новую работу и пережить синдром самозванца ч2

Нужно ли прокачивать специфический скилл для повышений ЗП

Проблема "чистого листа" у новичков

⚡️Кейсы с офферами моих учеников отмечены хэштэгом #кейс
(нажми на него чтобы найти)

💬Чтобы отправить свой вопрос или уточнить детали по поводу своего кейса - смело пиши мне, это бесплатно, кнопка ниже👇

"5 офферов за 3 недели-  такого результата у меня никогда не было"

Привет, ребят 👋

Сегодня поделюсь важным для меня кейсом: подготовка ученика на синьорную позицию. Итог: удалось получить 5 офферов практически по самому верху рынка в топовые компании РФ.

Ниже отзыв ученика ⬇️⬇️⬇️

С Петром работал 3 месяца. Расскажу, с чем конкретно он помог мне как ментор:
- разобраться с техническими нюансами современного стэка в Android,  в некоторых библиотеках я "плавал" и не знал как эффективно ими пользоваться
- устранить пробелы в понимании чистой архитектуры и её реализации, как итог сделал для себя эталонный вариант в пет проекте, которого всегда придерживаюсь, а уверенное знание не раз помогло мне на собеседованиях
- переосмыслить мой имеющийся опыт, подобрать правильные формулировки для его описания и увидеть важные детали, которые я игнорировал. и, как итог, мы составили очень привлекательное резюме: мне написало >50 эйчаров за 3 недели, сам я сделал ровно  0 откликов! (за пруфами велком в личку)
- подготовиться к техническим интервью. мок собеседование, которое предложил Пётр, заняло ~4 часа, пришлось разбить на 2 дня! охватили очень много тем, что принесло свои плоды- 5 офферов за 3 недели-  такого результата у меня никогда не было 
- понять какие редфлаги бывают у компаний и на что нужно обращать внимание исходя из своего опыта и с конкретными примерами, что помогло мне определиться с выбором лучшего оффера среди всех

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

Рекомендую, пишите!!

Как обычно я очень рад результату, значит работа была проделана не зря, это сильно мотивирует 🔥 Еще раз поздравляю и вперед к новым вершинам! 🔝

#кейс

Красные флаги при собеседовании в компании 🚩

Прохождения собеседования - двусторонний процесс, компания присматривается к кандидату, кандидат к компании.

То есть так должно быть, но на практике многие ребята стараются хорошо показать себя, но забывают присмотреться к компании. Если во время общения возникают красные флаги 🚩, стоит несколько раз подумать о продолжении процесса собеседования, т.к. скорее всего после трудоустройства все может усугубиться.

Для новичков может быть сложно распознать красные флаги, расскажу о некоторых из моего опыта, на которых я набивал шишки:

1️⃣Постоянные переработки. Из общения с представителями компании становится понятно о частых переработках. В целом в IT переработки не являются чем-то сверхестественным, но они точно не должны быть правилом, вряд ли вы захотите постоянно перерабатывать.
Пример: в описании вакансии написано что вы должны оставаться на связи на выходных или что компания приветствует сверхурочную работу

2️⃣ Агрессивный напор рекрутера. Понятно что за хорошего кандидата компании будут бороться и применять разные ухищрения, но, на мой взгляд, агрессивный пушинг точно не должен иметь места в приличной компании.
Пример: одного моего ученика компания прямо обязывала принять оффер и через несколько дней выходить на работу, без возможности дождаться фидбэка из других мест.

3️⃣ Полное отсутствие процесса разработки. Процесс разработки будет напрямую влиять на вашу жизнь, поэтому имеет смысл заранее уточнить как он выстроен. Одна из крайностей - его нет вообще.
Пример: в переписке hr пишет о том что у них "нет Jira или аналогов, задачи будут ставиться в системе Discord"

4️⃣ Чрезмерное внимание к процессу разработки. Другая крайность в которую могут впасть компании, начав слишком сильно упарываться по процессу.
Пример: в одной компании из моего прошлого опыта процесс стал самоцелью, продукт ушел на второй план. Как результат - работать стало крайне некомфортно и команда постепенно развалилась.

5️⃣ Не заходит стиль общения непосредственного руководителя. Суперважный флаг, на который обязательно надо обращать внимание. Если уже на этапе собеседования понимаешь что не заходит стиль общения, то во время работы как правило это только усугубится.

6️⃣ Странные особенности или корпоративные политики
Пример: однажды собеседовался в компанию, у которой была особенность - зарплаты любого сотрудника были в открытом доступе внутри компании. Это сразу показалось странным, почитал отзывы от бывших сотрудников, оказалось что это было не единственной странностью, по совокупности многим там было некомфортно работать.

🔥 - или любая реакция если было полезно

Поделитесь своими наблюдениями по поводу красных флагов)

C Днем Программиста‼️

Сегодня 256 день в году же, чуть не забыл, запрограммировался👨‍💻

С праздником всех причастных 🎆🎆 🎆
Желаю интересных задач, кода без 🪲, крутых коллег, адекватных руководителей и хороший чек 💲

Ну и моя любимая картинка в этот день👆

Нужно ли прокачивать специфический скилл

Периодически на консультациях ребята задают подобные вопросы ❕

Я хотел бы прокачаться в технологии Х, чтобы повысить свою ценность на рынке, чтобы за меня бы боролись компании и предлагали бы любые деньги, чтобы я у них поработал.

При этом технология Х обычно это что-то узко-профильное, для Android, например, это тонкая настройка ExoPlayer / работа с Bluetooth / работа с JNI, похожие узко-профильные вещи можно найти в любой специализации.

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

С другой стороны есть ряд вопросов:

1️⃣ Первое если - "если мы прокачаем узкие знания" - в каком состоянии при этом находятся знания широкого профиля, которые нужны каждый день для решения задач? Если они слабые, то нас не спасут узкие специфичные знания чего-либо

2️⃣ Второе если - "если компании они будут нужны" - рассчитывая на такую стратегию мы сразу сужаем круг компаний, рассматривая те, кому могут быть интересны наши специфичные знания. При этом мы автоматом можем отбросить много интересных предложений, просто потому что захотим пойти применять узкую специализацию

3️⃣ Третье если - если мы не используем наших узких знаний в работе, мы просто их теряем со временем, а эта узкая специализация продолжает развиваться и получается что время проинвестированное в нее, было потрачено зря

➡️Какой посыл этого поста? First things first - рекомендую сначала убедиться что у вас все в порядке со знаниями широкого профиля, что вы хорошо знакомы с современными технологиями и подходами разработки, хорошо ориентируетесь в основных компонентах и особенностях специализации. Практика моих учеников показывает что уже этого достаточно для выхода на миддл-синьор позиции с хорошей компенсацией 💰

⚡ - или любая реакция если было полезно

Поделитесь своими мнением по этому вопросу, если оно отличается от моего)

Подготовка к выходу на работу, часть 2
первая тут

За 15+ лет в ИТ мне много раз приходилось менять работу или выходить на новый проект, в этой части поделюсь моей подготовкой к выходу на новую работу, надеюсь кто-то подчерпнет полезные мысли


1️⃣ Хранение информации: как уже писал прежде всего нужно продумать место где фиксировать поступающую информацию и как дальше она будет упорядочиваться - для этой цели лично я использую Obsidian, т.к. по нему суперудобно делать поиск, можно строить при желании взаимосвязи заметок и т.п. Плюс каждая заметка это обычный md-файл, легко перенести в другую систему при необходимости.

2️⃣ По технической части имеет смысл начать с верхнеуровневой архитектуры - какие есть модули и системы, как они взаимодействуют друг с другом. Это полезно чтобы увидеть картину целиком без погружения в детали. Дальше при необходимости разбираться с более конкретными модулями.

3️⃣ По коду проекта понять:
➡️ общую архитектуру, какие архитектурные слои используются
➡️ есть ли многомодульность и на какой идее она построена
➡️ git-flow, именования веток, как устроен код-ревью
➡️ codestyle, принятые стандарты кода, посмотреть на общий уровень написания кода на проекте

4️⃣ Требования к продукту:
➡️ выделить основные термины и бизнес-процессы
➡️ ознакомиться с документацией, если она есть
➡️ в качестве требований также можно смотреть существующие тесты на проекте

5️⃣ Люди:
➡️ команда: роли, кто чем занимается
➡️ кто ответственный за требования / дизайн - для разных кейсов это могут быть разные люди
➡️ бадди / тимлид или другой человек который будет помогать осваиваться в проекте и к кому можно приходить с вопросами по технической стороне
➡️ понять кто больше подходит по общению из команды
➡️ наладить социальные связи, тут отлично подойдут как всякие неформальные мероприятия, так и просто кофе-брейки или совместные обеды

⚡️Нужно будет проделать много действий, зафиксировать много информации. Поэтому лучше заранее подготовиться, чтобы эту информацию было проще структурировать. Такой подход позволит быстрее освоится на проекте, постепенно получить хорошую базу знаний, что даст серьезное преимущество перед теми кто этого не делает и поможет вырасти в эксперта на проекте

⚡ - или любая реакция если было полезно

Поделитесь своими лайфхаками, если они есть, будет правда интересно)

Рубрика "вопросы от подписчиков"
На самом деле вопрос даже больше чем от подписчика - от ученика, который недавно трудоустроился. Итак вопрос

Напиши гайд в блоге как себя вести на новом месте и пережить самозванца в себе.

Просили - делаем)
Старт работы на новом месте это стресс для любого разработчика, не зависимо от уровня (как и скорее всего для людей других профессий).

Итак, что нас обычно ожидает на старте:

🟢 Техника: незнакомый код, структура проекта, инфраструктура разработки и сборки релиза

🟢 Требования: непонятный продукт, термины, функционал, роадмап / планы

🟢 Люди: отсутствие налаженных социальных связей в команде, непонятно к кому идти по разным вопросам

🟢 Процессы: неизученные процессы разработки и релизный цикл

С этими вещами и придется разбираться. Крайне редко на проекте ведется и актуализируется полноценная документация, скорее всего информация будет выдаваться обрывками и более-менее полная картина появится спустя какое-то время. Нужно заранее подумать где фиксировать эту информацию - подойдет notion, obsidian или их аналоги. Фиксировать ее нужно обязательно, иначе придется искать и разбираться повторно.

Что стоит помнить - компания заинтересована чтобы ты разобрался и начал приносить пользу

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

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

🔥 - или любая реакция если было полезно

P.S. Как вам такой формат?) Если у вас тоже есть вопросы, присылайте в личку или комментарием, я всегда открыт и постараюсь ответить