Всегда ходите на собеседования

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

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

Автор статьи рассказывает почему IC8 инженер из Меты посоветовал ему всегда быть "острым":

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

🟣 Искать работу лучше, пока есть текущая. Даже для того чтобы убедиться, что текущее место лучше рыночных предложений.

🟣Всегда нужно иметь на руках несколько предложений. Так вы увеличиваете шансы улучшить условия.

🟣Некоторые навыки, как эффективное решение алгоритмов, можно прокачать только усердной подготовкой. Чем больше времени между собесами, тем сложнее все вспоминать.

Ну а лучшие материалы для подготовки и чат с практикующими разрабами из всех компаний мира тут 😬

Не ходите часто по собеседованиям

В противовес предыдущему посту я хочу поделиться своими и чужими мыслями почему не стоит часто ходить на собесы. Основано на реальных данных.

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

Рынок вакансий все меньше, а значит и выбора.

🟣Вас забанят. Компании замораживают ваш статус на полгода/год и повторно пройти интервью нельзя.

Это особенно критично при внезапной потери работы.

🟣Рост внутри компании лучше. Выражу непопулярное мнение, но не всегда скачки по компаниям это хорошо. Чаще новое место может быть всего на 10-15% больше от текущего бюджета. Задачи, процесс и коллектив хуже. На долгосрочной дистанции это скорее проигрыш, а не победа. Прыгая туда сюда, в поисках себя, можно потерять драгоценное время. Начать разгоняться и быстро остановиться, заново собирая ресурсы и вникая в работу.

А если вы работаете не на галере, то лучше держаться за хорошее место.

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

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

Product Minded engineers

Продолжаю читать на отпуске лучшую книгу про карьерный рост «the software engineer’s guidebook». В ней поднимается тема опыта работы в продуктовых командах. О продуктовом мышлении говорят многие, но лучше формулировки, чем в этой книге, я пока не встречал.

Успешный оффер давно перестал быть только требованиям к техническим скиллам

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

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

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

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

Почему product minded engineers становятся более привлекательными специалистами?

🟣проактивность

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

🟣понимание бизнеса

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

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

🟣любопытство

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

🟣сильные коммуникативные навыки.

Продуктовый инженер отлично общается со всеми. Уважительно относится к чужому труду. Не критикует и не считает других врагами. Готов всегда помочь и выручить каждого.

🟣находит компромиссы.

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

🟣находит конструктивные корнеркейсы.

Продуктовый инженер ищет реалистичные корнер-кейсы, а не те, что возникнут с ничтожно малой вероятностью

🟣быстрые циклы разработки.

Продуктовый инженер впервую очередь доносит полезные фичи пользователю и умеет быстро понимать и находить фидбэки от них

🟣комплексные навыки в решении проблем.

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

Если вы еще не начали ее читать, то очень советую.

А я напоминаю, что сейчас последние дни скидок и скоро выйдет много уникального контента:
🟣 подкаст про систем дизайн глазами руководителей и инженеров
🟣 воркшоп по Swift Concurrency
🟣 интервью с крутой иос разработчицей из Apple
🟣и много других полезных подборок

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

Как быть хорошим инженером

Мы уже выяснили, что быть хорошим инженером — это не только классно красить кнопки, но и целый лист требований, которые расширяются. Мы уже писали про Product Minded Engineers.

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

В статье дал такие определения:

🟣Хороший инженер хорошо общается письмено и устно. Его работа напрямую зависит от сотрудничества.

🟣Хороший инженер понимает процессы. Не сабботирует их, а помогают улучшить, либо нарушить.

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

🟣Хороший инженер проактивен. Нет необходимости просить его писать тесты или документацию. Он делает лучше легаси, рефакторинг, тестирование. Его качество всегда максимально подходящее под текущие обстоятельства.

🟣Хорошие инженеры упрощают. Они занимаются модульностью, стратегии для тестирования и адаптируются под сложность.

🟣Хороший инженер постоянно учится. Он не боится публично признать свои ошибки и знает, что в следующий раз сделает лучше.

🟣Хорошие инженеры командные игроки. Они распознают проблему и предлагают решение. Они не бросают проблему за ограду и не просят других ее исправить.

☕️ Как я баг исправил, который не могли найти два года

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

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

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

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

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

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

Окей. С логами понятно, но что будем трекать?

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

Так. Мы научились понимать когда main thread завис. Теперь нам нужно как-то понимать что стало причиной его зависания.

Тут тоже все тривиально. Мы берем Stack Trace и записываем его в файл и отправляем в Firebase. Стандартный

Thread.callStackSymbols

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

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

Дополнительно сделал экран в дебаг меню, который записывает в формате "Date -> Thread.callstack" логи. Чтобы можно было сразу мне отправить лог, как только получили зависание.

После релиза, спустя десяток минут, я получил первый лог. В нем сразу была показана причина зависания. Это был мертвый код, давно ушедшего разраба. Связан он был с расширения кэша картинок для либы SDWebImage

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

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

Делитесь своими метриками, которые помогли решить редкие баги

Сегодня 01.11 у меня др

Завтра я этот пост удалю, не хотел его писать, но вдохновился постом Дурова на свой др.

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

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

Я ни разу не просил рекламу и делал только то, что нравится мне. Писал то, что думал. Старался задумываться о своих читателях. Банил хейтеров.

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

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

В нем всегда одна философия — быть полезным себе и другим.

Мы сделали первыми:
- выигрывали телеграм конкурс. Интересно кста перечитывать посты того времени
- Решали алгоритмы 365 дней
- Создавали апку "Симулятор иосника"
- Создали комьюнити
- устроили марафон по проектированию
- Сделали ютуб
- И кучу всего другого

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

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

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

Поддержать вы его можете конечно же тут 🤡

💎 БУМ! Воркшоп по собеседованию на тему Swift Concurrency

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

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

Сергей делает сложный мессенджер, где на практике использовал всю мощь Swift Concurrency.

За целый час мы узнали:
🟣Какие задачи нужно давать для оценки навыков
🟣Дает ли буст Swift Councurrency в сложных приложения?
🟣Какие знания он ждет от сеньора?
🟣Как ускорил приложение с помощью SC?
🟣Какие баги были и есть в SC?
🟣А также многое другое

Выпуск получился супер техническим и с кодом. Дополнительные ссылки и полезные ресурсы прилагаются

🧬 Получить доступ к этому видео можно тут