Vadim Chistiakov | IT

О книге The Software Engineer's Guidebook 📓

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

Поначалу, половина идей мне казались очевидными для разработчиков из любой компании и любого грейда с маломальским опытом. Например, чтобы держать в курсе стейкхолдеров о своей работе, поставьте созвон или напишете сообщение. Премия «кэп года» goes to Gergely Orosz! Но под конец книги я начал проникаться и все-таки это дало свою пищу для размышления. Интересно стало читать о ролях выше своей, на которых я никогда не работал.

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

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

Вы-кост или вы-профит.
Все галеры нанимают инженеров, которые по своей сути являются профитом. Деньги делаются на марже от продажи этих сотрудников другим компаниям.
Если вы работаете в команде, которая пилит пейволы, то отчасти вы-тоже команда профита.
А что если вы работаете в платформенной команде? Скорее всего, вы больше похожи на кост, хоть это и сильное упрощение.
Но я видел проявление этой логики на живом примере. Как только у компании начали заканчиваться деньги, бизнес перестает видеть ценность в автоматизации, тестах или повышении качества кодовой базы. В таком случае, весь ресурс пускают в гриндинг быстрых денег, тем самым снижая горизонт планирования до минимума. И команда платформы начинает красить кнопку "купить". И я думаю не сложно догадаться, кто первый идет «на мороз», если в компании лэйоффы.

Эта книга сможет подскать вам, как оценивать конъюнктуру в компании и команде. Как делать правильные предположения о том, стоит ли ливать с проекта или есть смысл остаться. Ведь кто-то же должен подняться по этой "лестнице".

О сеньерности и грейдах 📊

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

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

Ввести исчисляемые метрики и на их основе определить грейд пока невозможно. Нельзя сказать, что разработчик, который пишет 200 строк кода в день - джун, а если 1000, то уже сеньер. Может быть, кто-то и пытается это делать (индусы), но я не встречал рабочую систему. Годы опыта или зарплата тоже не совсем подходит. Человек мог просиживать штаны 5 лет на галере, а другой - запустить свой проект, поработать в биг-техе и получить хорошее образование за то же время. Вероятнее всего, их уровень знаний и компетенций будет разным. Что касается финансовой компенсации, можете сами найти вакансии на сеньора за 150к. Многие компании таким образом приманивают гоев на красивые тайтлы: “Senior Staff Solution Architect” - зарплата 3 ветки в месяц.

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

Почему важно понимать такие нюансы? Тогда вы перестанете задавать вопросы в стиле “Могу ли я откликаться на вакансии с опытом от 3 лет и надписью сеньер-помидор, если у меня только 2 года, и в трудовой я записан как мидл?” Ответ: конечно, можете! Все нанимающие менеджеры вкладывают в это понятие разные смыслы, и даже при низкой самооценке может быть, что знаний и умений справиться с этой работой более чем достаточно.

В моем опыте были тоже случаи, когда стандартное представление о грейдах разрушалось о действительность. В МТС после повышения моя роль называлась «эксперт», что было выше старшего разработчика. При этом моя работа была вполне обычной без Rocket science. Спустя несколько месяцев я перешел в Амедиатеку на грейд обычного разработчика с повышением зарплаты. Мои задачи стали нетривиальными, количество неопределенности, обязанностей и влияния увеличилось кратно. Это закрепило мое представление об отсутствии сакральной важности названия твоей роли.

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

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

Персональный сайт

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

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

Я решил поковыряться в новом стеке и сделать сайт самостоятельно. Конечно, можно заплатить профессионалам, но тогда я не смогу поддерживать его.
Чтобы сильно не заморачиваться, я выбрал подходящий шаблон на https://astro.build и добавил недостающие компоненты.

Сразу скажу, что у меня нет никакого опыта с веб разработкой. Знания html, css, java script - на уровне студента, поэтому я применил ChatGPT-driven-development) В целом, подход рабочий, с простыми задачами он справляется хорошо. Если не забывать подключать голову, за несколько дней на коленках можно что-то собрать. Все инструкции, как писать код, ui слой и как задеплоить на хостинг, есть на сайте.

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

Типы технических интервью для мобильного разработчика

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

А какие же варианты можно встретить, если вы рассматриваете вакансии мобильного разработчика? Исходя из моего опыта, я выделил следующие секции:

- Теоретические вопросы
- Алгоритмы
- Проектирование Класса/Библиотеки/Приложения
- Gathering requirement или Сбор требований
- Рефакторинг кода

Я уверен, можно наткнуться на любой другой формат, ведь есть компании "не такие, как все".

Но сегодня я бы хотел заглянуть в Object Oriented Design или Low Level Design.
Большой пласт знаний, который не уместится в одном посте. Умельцы из FAANG сделали на этот счет курс из 173 уроков, например.

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

NSLondon at Apple 🍏

Хочется поделиться приятным послевкусием. На днях посетил конференцию NSLondon в офисе Apple. Как и предполагалось, ажиотаж был не маленьким, и примерно 140 человек забронировали свой билет на мероприятие менее, чем за 2 минуты после открытия записи. Кажется, что участники караулили билеты как в очередях за новыми айфонами когда-то.

ИМХО доклады были посредственные. Первый походил на воркшоп и по большей части пересказывал документацию. Чат ЖПТ справился бы не хуже. Второй - опыт создания пет-проекта. В целом, ничего уникального, еще один трекер привычек. Сорри, что все обесценил)

Apple всегда подходит к созданию чего бы то ни было с размахом и большим вниманием к деталям. Будь то грандиозный проект офиса в Купертино за несколько миллиардов долларов или новая штаб-квартира в Лондоне в исторической постройке Battersea Power Station. Здание бывшей угольной электростанции в результате джентрификации превратилось в классное место притяжения, а Apple заняли 40% площадей.

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

Apple умело создали ощущение как у Чарли на Шоколадной Фабрике. Ходишь, удивляешься и к тому же нельзя ничего снимать и фотографировать. Но когда нас это останавливало) Охраны тоже было много, но, вроде бы, они лояльно закрывали глаза и замечаний никому не прилетало. Если вы тоже хотите пообщаться с сотрудниками и прийти к ним в гости, можно записаться на сессии по разным тематикам.

iOS-разработчикам, которые хотят прокачать свои навыки работы с многопоточностью – совсем скоро стартует Podlodka iOS Crew!

С 11 по 15 ноября лучшие эксперты разберут многопоточность, Swift Concurrency и алгоритмы в формате удобных онлайн-сессий.

В программе:

🔹 Александр Андрюхин проведёт нас через особенности Swift Concurrency, которых ты точно не знал
🔹 Swift 6 глазами Александра Априамашвили – как переход на новую версию поможет в повседневной работе.
🔹 Антон Марченко расскажет, как async в алгоритмах делает их быстрее.
🔹 Александр Сычев раскроет механизмы работы Thread и объяснит, как это важно для работы с многопоточностью.

Я уже бывал на подлодке, планирую присоединиться к конференции снова.

Присоединяйтесь и вы 👉 https://podlodka.io/ioscrew

А промокод ios_crew_14_nrnujZ сообщества даёт скидку в 500 руб🥳

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

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

Вот некоторые из будущих тем, которые хотелось бы рассмотреть глубже:

👉 Задания от российских компаний. Как правило системный дизайн ограничен одной фичей или проблемой. Например, дают дизайн экрана и просят описать интерфейсы, нарисовать верхнеуровневую схему и провести по флоу работы фичи. Хотя есть и исключения, например, “спроектируй мне тетрис“. Казалось бы, зачем решать проблемы тетриса в 2к24 году?

👉 Проектирование популярных приложений: Instagram, Twitter, Uber и тд. Очевидно, что за час интервью такие проблемы не решаются, но и задача не в том, чтобы подготовить production-ready решение. Собственно, в будущих разборах попробуем выяснить, что нужно делать на таком интервью, а что можно оставить за скоупом.

👉Хитрые вопросы из FAANG. В таких компаниях можно встретить совсем неожиданные вопросы. Например, вам нужно спроектировать свою структуру данных, которая будет вести себя определенным образом. Или продумать как работает аэропорт и вся его инфраструктура, не написав и строчки кода. Нелегкая задача, особенно для мобильного разработчика.

Stay tuned!

Новый чатик для подготовки к алгоритмическим интервью ✍️

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

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

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

Что вы уже найдете в чате?

🎯 Задачки, которые попадаются на интервью. Предпочтение задачам, которых нет на Leetcode и других площадках;
🎯 Решения и объяснения задач хитрых задач;
🎯 Моковые алго-интервью для всех желающих вне зависимости от уровня и языка программирования. Пара найдется всем. Тренироваться можно как на русском, так и на английском языках;
🎯 Задачи помечаются тегами компаний, в которых они встречались, и уровнем сложности (субъективная оценка, может подвергаться сомнению) Например: #Apple #medium;
🎯 Решения и объяснение выкладываем под спойлером, так будет удобнее для тех, кто хочет решить сам без подсказок. Вместе с ответом можно написать объяснение или поставить тег проблемы, например #slidingwindow;
🎯 Если у вас есть интересные задачи, не стесняйтесь выкладывать или обсуждать условия/решение с остальными.

Уже добавил свежие задачи из Яндекса, Альфа-банка, Тинькофф, Google и других компаний.

Вступить можно через boosty или tribute

Как же собеседовать эффективно?

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

Подготовительный этап
(Если вы-инженер, который проводит техническое интервью.)

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

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

Настало время интервью

- Кандидат получает текстовое описание вашей проблемы и ваш “джуновский код”;
- Его задача - затюнить это безобразие до наилучшего состояния;
- Вы легко можете направлять, обсуждать идеи, усложнять требования по ходу выполнения и смотреть, как кандидат реагирует на изменения;
- Заранее заготовить несколько фолоу аппов и в зависимости от перформанса и ожидаемого уровня от кандидата давать их как дополнительные задания.

Пример можно найти по ссылке, доступен всем.

Почему этот подход работает?

- Во-первых, я часто использовал этот способ на практике и пока не пожалел ни разу. Оценка грейда была точная и не вызывала вопросов у коллег или руководства;
- Возможность проверить сразу несколько аспектов. Умение решать задачу согласно требованиям, умение видеть проблемы/баги и исправлять их, уровень насмотренности. Также вы можете в любой момент попросить теоретическое обоснование принятых решений;
- Вы проверяете ту работу, которой действительно занимается разработчик бОльшую часть своего времени. Он видит код, читает его, пробует оптимизировать, исправить ошибки, добавляет новую логику;
- Большая свобода в интервью. Возможность подстроиться под уровень самостоятельности кандидата. Задачу можно сформулировать так, что она подойдет для оценки разработчика любого уровня и опыта;
- Не нужны узкие знания, чтобы кандидат решил задачу. Для него процесс будет комфортным и не травматичным, задание ведь уже решено вашим внутренним “джуном”. Если он не смог его улучшить - поздравляю, скорее всего перед вами джун! А пасхалки для гуру всегда можно прикопать поглубже.

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

Есть идеи, как избежать ошибок при найме? Может, просто поставить 5 этапов алгоритмических задач?

PS. Мемы в комментарии)

Топ бесячих вопросов в iOS собеседованиях ❌

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

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

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

3. Value type vs Reference Type
Кто кого захватит? Когда освободит? И прочее… Складывается впечатление, что тебя хотят подловить и обмануть, а не действительно проверить твои навыки. Код в примерах выглядит все также искусственно, и проблема переоценена.

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

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

1. Глубокая теория.
Чаще всего вам нет необходимости знать, где выделится объект в памяти, будет ли для него создана side table или что вообще такое heapObject (подставь любой булшит из своего языка). Скорее всего, вы как разработчик создаете конечный продукт, а не новый язык программирования. Проверяйте применимые знания.

Что спрашивают сейчас на интервью, можно посмотреть тут

Что думаете, найм в АйТи сломан или все нормально? Дальше напишу, как на мой взгляд выглядит хорошее интервью.

Тестовые задания 📝

Интересно поделиться своим опытом и узнать ваше мнение касательно тестовых заданий.

Хейт в их сторону понятен. Обычно заявлено, что вы потратите на него 3-4 часа, что уже больше времени любого очного собеседования. По факту кандидаты тратят на тестовые гораздо больше времени. А в финале редко можно услышать адекватный и развернутый фидбек. Сухая отписка «мы приняли тяжелое решение и решили продолжить с другим кандидатом». Скорее всего, тестовое даже никто не проверял.

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

Некоторые более осознанные компании готовы платить за тестовое. Один раз меня попросили сделать фичу, которую я уже реализовывал и понимал трудозатраты. Плата была несоразмерно мала объему работы, я отказался. Вообще, можно попросить заменить выполнение тестового на очное интервью или предложить посмотреть другие проекты на гитхабе. Не стоит бояться говорить «нет». У меня был опыт, когда я не захотел делать тестовое, но все равно дошел до оффера.

Относительно недавно один стартап из Великобритании прислал тестовое, мне показалось оно интересным, и я вместе с участниками сообщества решил сделать разбор. Решение предполагает использование современного стека на Structured Concurrency и SwiftUI. Компания помогает с рабочей визой в Юкей и разрешает работать удаленно из любой точки мира. С решением можно ознакомиться по ссылке.

Что думаете насчет тестовых заданий, готовы их выполнять? Расскажите о своем опыте.

Алгоритмы для мобильного разработчика 🙌

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

🎯 Если хотите работать в крупных российских компаниях, то придется наработать хотя бы минимальный скилл решения задач. Опираясь на свой и опыт менти, даже для Senior iOS разработчика хватит уровня easy-medium c Leetcode. Есть ли существенная разница у фронтенда и бэкенда для российского рынка - судить не могу.
🎯 В международном бигтехе ситуация посложнее, особенно в последнее время. Нарваться на hard задачу очень просто. Плюс гораздо больше вероятность, что точно такой задачи нет в интернете. В FAANG’е следят за сливами и ротируют скоуп задач. Соответственно, для подготовки потребуется больше времени.

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

Если говорить о моем опыте с алгоритмами, то не совру указав 15 лет 😄
Еще в школьные времена я выигрывал олимпиады по спортивному программированию. Когда работал в МТС, тоже участвовал в соревнованиях среди сотрудников.
Оцениваю свой уровень и навыки как достаточные для прохождения интервью, что позволило получить оффер на лида в Яндекс, но не дотянул в Google. Все-таки это реально разный уровень (привет харды на первом этапе).

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

Mobile System Design. Pagination 📑

Еще одна необходимая тема для системного дизайна - пагинация.

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

В этом разборе рассмотрим, какие типы пагинации бывают? Какой подход выбрать? И самое главное, какие преимущества и недостатки у них есть?

Один из follow up’ов на интервью может быть реализация production-ready решения. Рассмотрим и такой вариант.

Также хотелось бы поделиться дополнительными материалами по теме. Меня вдохновляли @alementuev и мой бывший руководитель @andrey_tech. По разными на то причинам, они не очень активны сейчас в создании контента о мобильном сис. дизайне, но все равно вы сможете найти полезные приемы в их видео.

Если вы не читали предыдущий разбор о Real-time notification то вам сюда)

Mobile System Design 📲

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

Если вы претендуете на высокие позиции в iOS c зарплатой от 6.000$-7.000$, сложно пройти собеседование, не разбираясь в теме системного дизайна. По опросам в чате (не забывайте добавляться, кстати), именно она набрала больше всего баллов, как самая перспективная и интересная.

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

Хочу подготовить материалы для секции системного дизайна на собеседованиях. Цель - разобраться, как отвечать на вопросы о проектировании популярных приложений, например: “Как бы ты спроектировал Uber? или менее масштабных: “Как сделать бесконечный скролл с постами?”

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

Первая тема уже доступна по ссылке: Real-time notification.

В ней подробно разобрал, какие приложения и для каких целей используют WebSocket, Server sent events, polling и push notification. Конечно с примерами и заданиями.

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

Подписывайтесь, чтобы ничего не пропустить и прийти к по-настоящему сеньерному офферу!

Паровозик собеседований 🚂

Заметил возросшую активность вокруг такой практики на рынке поиска работы как паровозик собеседований.

Для тех, кто не в курсе, поясню. Собирается группа людей, которые ищут работу по одному стеку технологий, например, iOS разработчик. Затем они по очереди ходят на собеседования в одну и ту же компанию. Интервью записывают, чтобы потом вместе обсудить вопросы/ответы. Таким образом следующий кандидат осведомлен о процессе интервью и имеет больше шансов пройти его успешно.

Тема не новая, наряду с накруткой опыта или помощи через помощника-суфлера. Индусы давно пользуются, в России только набирает популярность.

Какие есть мысли на этот счет:

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

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

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

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

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

Не хочу примерять на себя «белое пальто», но мне кажется, что, в основном, это морально-этический вопрос, также как с накруткой опыта или использованием помощников на интервью. Некоторые считают, что это нечестный способ получить работу и некий абьюз найма.

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

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

Жду ваших конструктивных мыслей и оценок по этим вопросам)

Оставлю анонимный опрос ниже.

#interview