Никто не будет думать о твоем повышении кроме тебя
Сейчас читаю нахваленную многими книгу The Software Engineer's Guidebook, автора сайта pragmatic engineer и уже разобранную нами "Growing as a Mobile Engineer"
Книга мне уже нравится и много мыслей заходят. Возможно, будет серия постов про самые интересные мысли и советы.
Первые главы сразу говорят, что нет никаких четких критериев роста. Помню свою позицию, когда я ждал помощи. Думал, придя в крупную компанию за мое развитие должен взяться мой менеджер и работадатель. Ведь я ресурс и в их заинтересованности чтоб этот ресурс развивался. Со стыдом вспоминаю свою наивность.
Наша среда обитания — очень динамичная и непостоянная. Нужно всегда держать руку на пульсе, а те, кто перестал практиковаться, следить за ней из первых рядов и ушел учить жизни и успеху — уже устарели или имеют искаженную картину.
Более того, сценарий и роадмапы карьерного пути сильно отличаются где вы работаете — стартап это или бигтех. Не везде упорный труд приведет вас к повышению и к желаемым ожиданиям. А еще более важный совет: никогда не будет постоянных критериев роста.
Новички в индустрии всегда ругаются, что нет четких критериев между грейдами. Жалуясь на нее, обвиняя третих лиц. Но создать предсказуемые условия в самой динамической среде — утопия. Наша индустрия не терпит регламенты и законы. То, что вчера работало — сегодня упадет из-за санкций или перевернется из-за ИИ. Позиция нытья — детсткая и проигрышная.
Сейчас я все сильнее выстраиваю фундамент развития в нашем сообществе. Один из них — быть проактивным и не зависеть от менторов, руководителей, гайдов и роадмапов. Развивать любознательность, смелость и крепкость. Создавать инфраструктуру для взаимопомощи. Самим их строить и отвечать за свой рост. Брать ответственность в свои руки и не быть нытиками, которые жалуются на сломанную индустрию.
Сейчас читаю нахваленную многими книгу The Software Engineer's Guidebook, автора сайта pragmatic engineer и уже разобранную нами "Growing as a Mobile Engineer"
Книга мне уже нравится и много мыслей заходят. Возможно, будет серия постов про самые интересные мысли и советы.
Первые главы сразу говорят, что нет никаких четких критериев роста. Помню свою позицию, когда я ждал помощи. Думал, придя в крупную компанию за мое развитие должен взяться мой менеджер и работадатель. Ведь я ресурс и в их заинтересованности чтоб этот ресурс развивался. Со стыдом вспоминаю свою наивность.
Наша среда обитания — очень динамичная и непостоянная. Нужно всегда держать руку на пульсе, а те, кто перестал практиковаться, следить за ней из первых рядов и ушел учить жизни и успеху — уже устарели или имеют искаженную картину.
Более того, сценарий и роадмапы карьерного пути сильно отличаются где вы работаете — стартап это или бигтех. Не везде упорный труд приведет вас к повышению и к желаемым ожиданиям. А еще более важный совет: никогда не будет постоянных критериев роста.
Новички в индустрии всегда ругаются, что нет четких критериев между грейдами. Жалуясь на нее, обвиняя третих лиц. Но создать предсказуемые условия в самой динамической среде — утопия. Наша индустрия не терпит регламенты и законы. То, что вчера работало — сегодня упадет из-за санкций или перевернется из-за ИИ. Позиция нытья — детсткая и проигрышная.
Сейчас я все сильнее выстраиваю фундамент развития в нашем сообществе. Один из них — быть проактивным и не зависеть от менторов, руководителей, гайдов и роадмапов. Развивать любознательность, смелость и крепкость. Создавать инфраструктуру для взаимопомощи. Самим их строить и отвечать за свой рост. Брать ответственность в свои руки и не быть нытиками, которые жалуются на сломанную индустрию.
Недавно произошел забавный случай. Мне писал коллега, что проводил свой собес в крупном банке с помощью нашей базы знаний. Он задавал уточняющие вопросы, рядом с методичкой открыв наш ноушен. Это приятно, но смешное в том, что кандидат отвечал ответами 1 в 1 будто читал из той же самой методички. Было одновременно забавно и приятно, что наши сборники используются по обе стороны. Но лучше все же не зубрить ответы и не списывать...
Поэтому я стараюсь собирать самые интересные и полезные вопросы. Даже если вы не готовитесь к собесам, то это поможет вам держать себя в тонус. Как решение кроссвордов или загадок по вечерам. Эту идею мы также несем с "ежедневными задачами в чате".
Любые знания и навыки атрофируются, если их не использовать. Именно поэтому многим так сложно выходить на рынок после долгих перерывов. В стрессовых условиях тратя очень много времени для нагонки формы. Уж лучше поддерживать форму регулярно и дисциплинированно.
В этом сборнике я собрал интересную тему анти-паттернов:
Также к вопросам приложены материалы для подготовки
Please open Telegram to view this post
VIEW IN TELEGRAM
Что такое анти-паттерны?
Ну и сразу готовый ответ на один из прошлых вопросов, который есть в крутейшем курсе для мобильных архитекторов (судя по отзывам). Мне очень понравилась эта формулировка, где анти-паттерны — это не самое лучшее и рискованное решение, которое было лениво выбрано и может быть заменено чем-то лучшим
Эта формулировка для тех, кто говорит, что их не существует 🙂
https://www.youtube.com/watch?v=Btm3CTI6eMA
Ну и сразу готовый ответ на один из прошлых вопросов, который есть в крутейшем курсе для мобильных архитекторов (судя по отзывам). Мне очень понравилась эта формулировка, где анти-паттерны — это не самое лучшее и рискованное решение, которое было лениво выбрано и может быть заменено чем-то лучшим
Эта формулировка для тех, кто говорит, что их не существует 🙂
https://www.youtube.com/watch?v=Btm3CTI6eMA
YouTube
Clean iOS Architecture 101: What is an anti-pattern?
This is why you should avoid anti-patterns in your iOS/Swift codebases.
Excerpt from the iOS Lead Essentials Podcast #014
You can also find us on ↴
Twitter ☛ https://twitter.com/essentialdevcom
Facebook ☛ https://facebook.com/essentialdeveloper
Instagram…
Excerpt from the iOS Lead Essentials Podcast #014
You can also find us on ↴
Twitter ☛ https://twitter.com/essentialdevcom
Facebook ☛ https://facebook.com/essentialdeveloper
Instagram…
Почему стало сложно найти работу?
Хорошая статья, которая объясняет почему стало и будет сложнее искать работу. Прогнозы не очень хорошие и понятно одно — находить работу будут не все. Давайте по пунктам:
🟣 Количество выпускников компьютерных наук самое большое в истории. Предложений на рынке стало больше.
🟣 Дорогое образование. Люди ищут более прибыльные специальности такие как компьютерные науки и тп.
🟣 Технологии и компьютеры очень популярны. Вся наша жизнь связана с ними, поэтому больше людей хотят их изучать.
Рынок вакансий уменьшился. Стали меньше публиковать вакансии и чаще увольнять.
🟣 Изменения процентных ставок и налоговых обложений заставили компании ужесточить найм.
🟣 FAANG'и начал нанимать меньшее количество людей.
🟣 Нанимать стало сложнее из-за большого количества обмана и лжи.
Повлиял ли на это AI?
🟣 В найм сотрудников стали меньше вкладываться, а больше в ИИ.
🟣 AI юзается для создания резюме, которые подходят под фильтр и проходят hr-скрининг. В результате кандидаты, что юзают AI для создания резюме, получают больше приглашений на собеседования, даже если они не соответствуют требованиям.
Ну а самый главный вывод — стоять на месте и не развиваться смертельно опасно
Хорошая статья, которая объясняет почему стало и будет сложнее искать работу. Прогнозы не очень хорошие и понятно одно — находить работу будут не все. Давайте по пунктам:
Рынок вакансий уменьшился. Стали меньше публиковать вакансии и чаще увольнять.
Повлиял ли на это AI?
Ну а самый главный вывод — стоять на месте и не развиваться смертельно опасно
Please open Telegram to view this post
VIEW IN TELEGRAM
r y x, r
Why does getting a job in tech suck right now? (Is it AI?!?)
A lot of new CS grads have been noting that is really hard to get a job. I’ve personally been contacted by a couple people, including outside of Twitter, about the difficulty of finding a job…
Почему if/else — это плохо
В чате сообщества мы уже недели полторы спорим о коде: что считается сложно, а что плохо; когда полезны комментарии; полезно ли помечать код MARK'ами; насколько полезны if/else.
Давайте разберемся когда же if/else считается плохой практикой.
1. Злоупотребление if/else может привести к проблемам чтения и дебагинга
2. Чаще лучше использовать guard, чем if/else
3. Не используйте if/else для проверки типов
Также в FAANGA'ах считается, что каждое использование if/else или bool флага приводит к усложнению чтения и поддержки кода в 4 раза.
Материалы для знакомста:
🟣 Don’t write if-statements
🟣 Stop Using If Statements In Your Swift Code
🟣 Why We Should Avoid Using `else` in Programming
В чате сообщества мы уже недели полторы спорим о коде: что считается сложно, а что плохо; когда полезны комментарии; полезно ли помечать код MARK'ами; насколько полезны if/else.
Давайте разберемся когда же if/else считается плохой практикой.
1. Злоупотребление if/else может привести к проблемам чтения и дебагинга
2. Чаще лучше использовать guard, чем if/else
3. Не используйте if/else для проверки типов
Также в FAANGA'ах считается, что каждое использование if/else или bool флага приводит к усложнению чтения и поддержки кода в 4 раза.
Материалы для знакомста:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Не секрет, что крупная компания в резюме влияет на успешность трудойстройства.
Если в вашем резюме есть опыт работы в яндексе/вк/сбере/любой_бигтех, то устроиться проще. Как думаете, с чем это связано?
Если в вашем резюме есть опыт работы в яндексе/вк/сбере/любой_бигтех, то устроиться проще. Как думаете, с чем это связано?
Final Results
52%
Сложность отбора. Если человек прошел сложные собесы, то значит чем-то заинтересовал
21%
Сложные задачи. Обычно в крупных компаниях интересней и сложнее задачи.
18%
Особое понимание корпоративной культуры.
16%
Опыт и компетенции. Сотрудник может быть полезен рассказав секреты конкурентов
46%
Похожий опыт из проверенных на рынке компаний. Многие компании — это университет для роста
17%
Все перечисленное
8%
Для меня компании не сильно важны
6%
Другое
Если тех.дир Тинька начал решать литкод, то ждем алгособесы в тиньке?
Ну а пока все наивно надеются, что алго-собесы вымрут и их отменят, мы в сообществе уже решили ~150 задач и ежедневно решаем и делимся кодом (иногда эмоционально). Где разрабы из JetBrains, Яндекса, Авито, Тинька и других компаний дают фидбэк и точки роста каждому.
Каждый сам выбирает готовить ли сани летом.
Ну а пока все наивно надеются, что алго-собесы вымрут и их отменят, мы в сообществе уже решили ~150 задач и ежедневно решаем и делимся кодом (иногда эмоционально). Где разрабы из JetBrains, Яндекса, Авито, Тинька и других компаний дают фидбэк и точки роста каждому.
Каждый сам выбирает готовить ли сани летом.
Forwarded from Teamlead Good Reads – ежедневные советы про менеджмент людей и команд (Egor Tolstoy)
Как Leetcode влияет на прохождение интервью
Ребята, которые делают сервис мок-интервью, продолжают делиться интересными данными. В этот раз они проанализировали корреляции между тем, насколько много задач и какого уровня прорешал кандидат с тем, какой перфоманс он показывал на собеседованиях.
👉В целом корреляция между решением задач на Leetcode и успешным прохождением интервью довольно сильная.
👉На силу корреляции влияет количество решенных задач и их сложность. При этом количество влияет только до определенного порога, после 500 задач эффект перестает расти так сильно.
👉Рейтинг на Leetcode не коррелирует с успешностью интервью.
👉Прорешивание сложных задач в два раза эффективнее, чем задач средней сложности. Каждые 50 сложных задач ведут к повышению успешности прохождения интервью на 7%.
Ребята, которые делают сервис мок-интервью, продолжают делиться интересными данными. В этот раз они проанализировали корреляции между тем, насколько много задач и какого уровня прорешал кандидат с тем, какой перфоманс он показывал на собеседованиях.
👉В целом корреляция между решением задач на Leetcode и успешным прохождением интервью довольно сильная.
👉На силу корреляции влияет количество решенных задач и их сложность. При этом количество влияет только до определенного порога, после 500 задач эффект перестает расти так сильно.
👉Рейтинг на Leetcode не коррелирует с успешностью интервью.
👉Прорешивание сложных задач в два раза эффективнее, чем задач средней сложности. Каждые 50 сложных задач ведут к повышению успешности прохождения интервью на 7%.
Сделал большую статью в ноушене. Тема пуш-уведомлений очень интересная и ее можно долго обсуждать. Особенно, если вы делаете мессенджер. Наши мобильные приложение имеют уникальный инструмент, который помогает как юзерам получать быстро информацию, так и разработчикам и маркетологам доставлять важные предложения. Поэтому каждый разработчик должен знать наше уникальное предложение мобильных устройств.
В этой статье разберемся в работе пуш уведомлений:
Please open Telegram to view this post
VIEW IN TELEGRAM
Какая будет последовательность в консоли?
Anonymous Quiz
21%
1, 2, 3, 4
7%
1, 4, 3, 2
4%
1, 3, 2, deadlock
10%
1, deadlock
39%
1, 2, deadlock
16%
1, 4, 2, deadlock
4%
Ошибка компиляции
Ну что, врата в ад открываются сегодня в 18:00 по мск.
Я не собирался туда идти, но многие подписчики жаловались на плеер в телеге. Ведь все видео в закрытом канале и смотреть на 1,5 часа видос там неудобно.
Что я буду делать в ютубе? Все видео там не будут выкладываться, а я пойду по стратегии классических писателей. Где для широкой аудитории будут выходить понятные и популярные видосы, а другие останутся для закрытой аудитории, которая захотела погрузиться детальней.
Это еще сделано для того, что банально мне хочется повышать качество контента, а редактировать или заниматься монтажом каждого видео я не смогу физически.
Напоминаю, что еще есть другие выпуски и они пока в закрытом доступе:
Посмотрим как дельше пойдет с видео. Мы запланировали еще парочку крутых роликов, где будут воркшопы и другие форматы. Вы всегда можете быть гостем или ведущим.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
iOS Мок-собеседование по систем дизайну | Проектируем инстаграм с разработчиком из крупного банка
System Design называют по разному. Где-то эту секция называется архитектурой, а где-то проектированием.
В данном ролике мы попытаемся поделиться своим опытом и показать как бы мы провели секцию, если бы проектировали приложение инстаграма.
В роли интервьюера…
В данном ролике мы попытаемся поделиться своим опытом и показать как бы мы провели секцию, если бы проектировали приложение инстаграма.
В роли интервьюера…
1 19 5 5
Смотрел недавно отрывок "лекции" от очередного ментора с накрученным опытом и оценил всю "полезность" знаний, которые он дает. В своем ролике он говорит об "инженером мышлении" где советует сначала сверстать UI, а только потом подойти к проектированию и декомпозиции фичи...
Это какой-то особый скилл говорить умные слова с уверенным видом, но ни слова не понимать их реальное значение.
Объясняю на пальцах почему этот подход неправильный и опасный. Мне нравится, как эту часть разобрали в книге "Mobile System Design":
1. Верстать UI сразу экран хорошая практика только когда вы делаете соло проект в стартапе, где не важен дизайн и конечный результат. В больших командах это не выйдет, так как в 99% множество кейсов не учтены дизайнерами и продактами
2. Множество требований — сырые и непроработанные. Наша задача как инженеров сначала оценить дизайн по имеющийся бизнес логике. Насколько быстро и дешево бэк может отдать нам данные, которые отрисовал дизайнер. Есть ли у нас необходимые компоненты и требования. Чаще, нарисованные дизайн, это лишь примерное ожидание конечного результата, которое может быть множество раз переделано.
3. Сколько стоят компоненты для DesignKit. Часто дизайнеры обладают невероятной фантазией, которая может быть слишком сложна в разработке и избыточна для бизнеса. Обязанность UI разработчика подсветить сложность или неэффективность дизайна и предложить альтернативы, а не слепо доверять каждому слову и макету.
В итоге, подход «верстать дизайн, а потом думать» — это как «строить здание, ломать, а потом перестраивать». Все этапы проектирования должны быть до стройки.
Впервую очередь задачу нужно начинать с декомпозии, согласований и оценки. А только потом к реализации. Иначе будет тупиковый путь.
Ну и главный совет — скептично относиться к информации в интернетах. Особенно от людей с малым колличеством опыта в неподходящих для вас корпорациях или забросивших практику, агрессивно предлагающих свое менторство. Ищите окружение практиков, а не новичков. В чатах новичков часто много искажений из-за отсутствия критики и оценки от тех, кто имеет реальный опыт.
Please open Telegram to view this post
VIEW IN TELEGRAM
Вы разраб с большим количеством опыта. У вас на руках офферы на одинаковую сумму во все компании.
От какой компании бы отказались впервую очередь?
От какой компании бы отказались впервую очередь?
Anonymous Poll
27%
Сбер
22%
VK
23%
Яндекс
10%
Т-банк
8%
Авито
5%
Озон
37%
Вайлберис
11%
Альфа
19%
МТС
20%
Все херня
Советы по прохождению алгоритмических собеседований
На моей практике около 300 проведенных собесов. Это не считая моков и работы с менти. Реальные собесы сильно отличаются от тестовых: совсем другой уровень напряжения и стресса; тайминги; требования и конкуренция.
В реальном бою больше всего я провел алгоритмические собесы. Есть две причины:
🟣 Я сам хуже всего их прохожу
🟣 В крупных компаниях алгоритмы могут проводить любые разрабы. Андроид или бэк разраб легко могут отсобесить иосера.
Почему необязательно знать язык программирования, чтобы собесить другие платформы? Потому что на алгоритмах не оценивают знание синтаксиса и, иронично, даже знание редких алгоритмов.
Давайте же разберемся что же оценивают на алгоритмических собеседованиях:
1. Умение рассуждать вслух. Никто не ждет от вас секундного ответа. Впервую очередь все задачи направлены на то, чтобы кандидат ранее с ними не столкнулся и умел доступно объяснять свое решение, а не выдал его молча. Показывал, как он работает в условиях неопределенности и за границами привычного скоупа задач.
2. Поиск корнер-кейсов. Никто не дает вам полных условий. В каждой задаче есть специально не озвученных 3-4 кейса, которые кандидат должен сам найти. Если кандидат ждет идеально описанных условий и требований, то это плохой кандидат
3. Никто не ждет от вас алгоритмов. Ирония в том, что в алгоритмических задачах необязательно знать специфичных алгоритмов и зубрить тонны книг и матан. Можно и без них написать хороший код, но чаще сложно и это приходит через тонны практики.
4. Никто не ждет от вас шаблонного решения от чатгпт. Чатгпт не заменит разрабов, но многих заменят люди, которые лучше пользуются чатгпт. Код от разраба с "базой" сильно отличается от кода без "базы", даже если оба гуглят и используют ИИ. Ибо, в конечном счете, разраб принимает решение удовлетворяет ли код его критериям.
5. Не спеши отдавать код. Твоя задача не отдать первое попавшееся решение. Нужно еще перепроверить. Все мы ошибаемся
6. Уделяй внимание неймингу. Не забывай, что от тебя ожидается не только рабочее решение, но и простое, и понятное.
7. Будь вежлив и дружелюбен. Помни, что тебя оценивают не только по хардам, но и софтам. Много случаев, когда разработчик начинал психовать и токсичить, когда встречался со сложной задачей. Тебя оценивают не просто как генератора хороших идей, но и коллегу в команду.
На моей практике около 300 проведенных собесов. Это не считая моков и работы с менти. Реальные собесы сильно отличаются от тестовых: совсем другой уровень напряжения и стресса; тайминги; требования и конкуренция.
В реальном бою больше всего я провел алгоритмические собесы. Есть две причины:
Почему необязательно знать язык программирования, чтобы собесить другие платформы? Потому что на алгоритмах не оценивают знание синтаксиса и, иронично, даже знание редких алгоритмов.
Давайте же разберемся что же оценивают на алгоритмических собеседованиях:
1. Умение рассуждать вслух. Никто не ждет от вас секундного ответа. Впервую очередь все задачи направлены на то, чтобы кандидат ранее с ними не столкнулся и умел доступно объяснять свое решение, а не выдал его молча. Показывал, как он работает в условиях неопределенности и за границами привычного скоупа задач.
2. Поиск корнер-кейсов. Никто не дает вам полных условий. В каждой задаче есть специально не озвученных 3-4 кейса, которые кандидат должен сам найти. Если кандидат ждет идеально описанных условий и требований, то это плохой кандидат
3. Никто не ждет от вас алгоритмов. Ирония в том, что в алгоритмических задачах необязательно знать специфичных алгоритмов и зубрить тонны книг и матан. Можно и без них написать хороший код, но чаще сложно и это приходит через тонны практики.
4. Никто не ждет от вас шаблонного решения от чатгпт. Чатгпт не заменит разрабов, но многих заменят люди, которые лучше пользуются чатгпт. Код от разраба с "базой" сильно отличается от кода без "базы", даже если оба гуглят и используют ИИ. Ибо, в конечном счете, разраб принимает решение удовлетворяет ли код его критериям.
5. Не спеши отдавать код. Твоя задача не отдать первое попавшееся решение. Нужно еще перепроверить. Все мы ошибаемся
6. Уделяй внимание неймингу. Не забывай, что от тебя ожидается не только рабочее решение, но и простое, и понятное.
7. Будь вежлив и дружелюбен. Помни, что тебя оценивают не только по хардам, но и софтам. Много случаев, когда разработчик начинал психовать и токсичить, когда встречался со сложной задачей. Тебя оценивают не просто как генератора хороших идей, но и коллегу в команду.
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Продолжаю писать статьи про пуш-уведомления. В прошлой мы узнали виды пушей и как их настраивать. В этой же будет более практичная инфа.
Как-то на одном собеседовании в банк меня спросили: "Умеет ли по умолчанию пуш уведомление открывать гифку, фото или проигрывать видео?"
Как раз для этого вопроса я подготовил статью. Узнаем:
Записал даже видео туториалы
Please open Telegram to view this post
VIEW IN TELEGRAM