В чате мы начали новую рубрику. Каждый день решаем какие-то задачи для iOS.
Вы можете предлагать свои в комментах или лс @lvbond
буду иногда делиться тут
Вы можете предлагать свои в комментах или лс @lvbond
буду иногда делиться тут
This media is not supported in your browser
VIEW IN TELEGRAM
Молодым до 30 посвящается
Остальным кто после соболезнуем
Остальным кто после соболезнуем
3
This media is not supported in your browser
VIEW IN TELEGRAM
Мы все пришли сюда, чтобы нормально покодить
О слитых сборниках для собесов.
Не секрет, что уже давно по сетям ходят всякие паровозики собесов или сборники "сливов". В начале этой недели мне подогнали один из сборников за косарь рублей и я его изучал. Думал может что-то подчерпну в канал или ноушен. Но как же я ошибался... Посмотря на него я даже подумал, что мой контент стоит слишком мало, раз люди не стесняются продавать настолько абсолютно сырой материал за подписку в 2 раза дороже.
Давайте разберемся по порядку почему никакие сливы не дадут ощутимого импакта:
1. Все сливы — это записи собесов. Стоит ли говорить, что вопросы для джуна и сеньора чаще ничем не отличаются? Ожидается лишь качество ответа. Но в этих сливах был самый рофл — там просто аудиосообщения в комментах телеграма. Будто кто-то диктофоном записал свой собес без кода и тупо выложил свое эканье и бэканье. Ну или в 80% откровенно неправильную инфу.
2. Задачи решены неправильно. Обычно сливами и активной подготовкой к собесам занимаются либо стажеры, либо джуны. Уровень решения на задачи мы уже разбирали в чате. Большинству решений не дашь уровень мидл-, а чаще и джун-. До среднего мидла ответы нужно переписывать раз 10. Многие кейсы не утчены, условия недопоняты.
3. Неправильный сбор требований или понимания вопросов. Накрученный опыт и навыки не дадут скиллы и культуру, которая легко читается. Это видно по тому, как сформулированы эти "слитые задачи". Что-то в стиле "ну вот меня спросили какую-то хрень и я даже не понял о чем это". Это было в алгоритмах, где какой-то новичок не знал про оценку алгоритмов. Все это выглядело как кривой перевод с али-экспересса, где даже опытный разработчик не всегда понимает что же "слил" джуниор. Ведь он попытался связать слова, которые он не понимает, в предложения. От чего никто ничего не понял.
В общем, если кто-то верит, что можно просто пропустить десятки и сотни часов обучения и обмануть систему — вы страшно ошибаетесь. Аудит эти подходы не прошли и были разбиты. Это как посмотреть сотни видосов на ютубе по изучению английского от индусов с ярким акцентом, но забывать про практику. Попробуй теперь отмойся и переучись.
Ну а мы пришли сюда, чтобы нормально покодить и найти самые эффективные инструменты развития, не боясь трудностей и ошибок. Главное помнить, что нет никаких сеньорных вопросов, есть только сеньорные ответы и окружение.
Не секрет, что уже давно по сетям ходят всякие паровозики собесов или сборники "сливов". В начале этой недели мне подогнали один из сборников за косарь рублей и я его изучал. Думал может что-то подчерпну в канал или ноушен. Но как же я ошибался... Посмотря на него я даже подумал, что мой контент стоит слишком мало, раз люди не стесняются продавать настолько абсолютно сырой материал за подписку в 2 раза дороже.
Давайте разберемся по порядку почему никакие сливы не дадут ощутимого импакта:
1. Все сливы — это записи собесов. Стоит ли говорить, что вопросы для джуна и сеньора чаще ничем не отличаются? Ожидается лишь качество ответа. Но в этих сливах был самый рофл — там просто аудиосообщения в комментах телеграма. Будто кто-то диктофоном записал свой собес без кода и тупо выложил свое эканье и бэканье. Ну или в 80% откровенно неправильную инфу.
2. Задачи решены неправильно. Обычно сливами и активной подготовкой к собесам занимаются либо стажеры, либо джуны. Уровень решения на задачи мы уже разбирали в чате. Большинству решений не дашь уровень мидл-, а чаще и джун-. До среднего мидла ответы нужно переписывать раз 10. Многие кейсы не утчены, условия недопоняты.
3. Неправильный сбор требований или понимания вопросов. Накрученный опыт и навыки не дадут скиллы и культуру, которая легко читается. Это видно по тому, как сформулированы эти "слитые задачи". Что-то в стиле "ну вот меня спросили какую-то хрень и я даже не понял о чем это". Это было в алгоритмах, где какой-то новичок не знал про оценку алгоритмов. Все это выглядело как кривой перевод с али-экспересса, где даже опытный разработчик не всегда понимает что же "слил" джуниор. Ведь он попытался связать слова, которые он не понимает, в предложения. От чего никто ничего не понял.
В общем, если кто-то верит, что можно просто пропустить десятки и сотни часов обучения и обмануть систему — вы страшно ошибаетесь. Аудит эти подходы не прошли и были разбиты. Это как посмотреть сотни видосов на ютубе по изучению английского от индусов с ярким акцентом, но забывать про практику. Попробуй теперь отмойся и переучись.
Ну а мы пришли сюда, чтобы нормально покодить и найти самые эффективные инструменты развития, не боясь трудностей и ошибок. Главное помнить, что нет никаких сеньорных вопросов, есть только сеньорные ответы и окружение.
Премии — это чаевые
Часто слышу, что премии это обман. Но я так не считаю и не иду в компании, где их нет.
Я из семьи работяг. Учителей, которые были под вечным давлением требуемой от них образцовости. Нужно допускать минимум ошибок или придет чья-то мамка со словами «как вы наших детей воспитываете, если сами не даете пример или плохо воспитываете своих?».
В архитектуре их работы лежит преданность делу и тяжелый труд. Лимит на ошибки был минимальный. Давление и переработки. Для таких людей признание их работы и благодарность имеют особую ценность. Ведь в это вложены плоть и душа.
Это воспитание научило меня также не только уважать свою работу, но и быть благодарным за чужую хорошую работу. Кто имеет уважение и профессионализм. За это я всегда стараюсь платить чаевые или дать взамен ценность. Чтобы не угасал огонь внутри. Будь это барбер, официант, программист или кто-либо еще.
А уж если человек очарован своей работой, то он вызывает восхищение и добрую зависть. Хочется приблизиться к нему и постоять рядом дольше.
Часто слышал истории, как хорошие чаевые меняли жизнь на «до» и «после» у официантов. Им начинала нравится их работа и появлялось старание и конкуренция. Сервис и качество работы сильно улучшались. Люди придумывали целые системы и методологии.
Я не рассматриваю компании, где нет хороших премий. Там нет стимула для развития. Есть фикс оклад, который заставляет монотонно работать от звонка до звонка. Это гнетущая и неплодородная атмосфера.
А главное, без справедливой системы премирования нет культуры благодарности и мотивации делать что-то лучше.
Плоды не растут лучше без оценки за сверхрезультат
Часто слышу, что премии это обман. Но я так не считаю и не иду в компании, где их нет.
Я из семьи работяг. Учителей, которые были под вечным давлением требуемой от них образцовости. Нужно допускать минимум ошибок или придет чья-то мамка со словами «как вы наших детей воспитываете, если сами не даете пример или плохо воспитываете своих?».
В архитектуре их работы лежит преданность делу и тяжелый труд. Лимит на ошибки был минимальный. Давление и переработки. Для таких людей признание их работы и благодарность имеют особую ценность. Ведь в это вложены плоть и душа.
Это воспитание научило меня также не только уважать свою работу, но и быть благодарным за чужую хорошую работу. Кто имеет уважение и профессионализм. За это я всегда стараюсь платить чаевые или дать взамен ценность. Чтобы не угасал огонь внутри. Будь это барбер, официант, программист или кто-либо еще.
А уж если человек очарован своей работой, то он вызывает восхищение и добрую зависть. Хочется приблизиться к нему и постоять рядом дольше.
Часто слышал истории, как хорошие чаевые меняли жизнь на «до» и «после» у официантов. Им начинала нравится их работа и появлялось старание и конкуренция. Сервис и качество работы сильно улучшались. Люди придумывали целые системы и методологии.
Я не рассматриваю компании, где нет хороших премий. Там нет стимула для развития. Есть фикс оклад, который заставляет монотонно работать от звонка до звонка. Это гнетущая и неплодородная атмосфера.
А главное, без справедливой системы премирования нет культуры благодарности и мотивации делать что-то лучше.
Плоды не растут лучше без оценки за сверхрезультат
iOS Makes Me Hate
Мы все пришли сюда, чтобы нормально покодить
Media is too big
VIEW IN TELEGRAM
Вторая часть шедевра
Мы пережили блокировку ноушена.
На всякий случай мы рыли окопы, пытались перейти в альтернативы.
База знаний соощества работает и не удалена. Остаемся в ноушене, но кому-то нужно включить VPN.
В честь этого праздника я решил сделать новую рубрику. Я понял, как много контента генерирует чат и я его преступно нигде не фиксирую.
Мы пришли сюда, чтобы решать задачи. Как в Google. Как в Apple.
Только с конца августа и начала сентября мы обсудили около 30 технических вопросов, и около 20 реальных задач. Всего за 2 недели, а это больше и чаще чем подборки в ноушене, которые я делаю сам. Может пора делать журнал, с разными авторами, а не личный блог?
Я знаю, что 1/3 подписчиков не подписана на чат, а те кто подписан не всегда могут его читать. Поэтому решил сделать отдельную подборку. Теперь она моя самая любимая. Этот сборник посвящен всем вопросам и задачам, которые мы решали в сообществе, встречали на собеседованиях или на работе. Они будут в рандомном порядке, без тем и часто без ответов (так даже лучше для самостоятельного изучения).
Если ты не следишь за чатом, то это отличная возможность оставаться в курсе без активного мониторинга.Но все же ты упускаешь живое обсуждение, которое лучше помогает усвоить материал.
💎 Получить доступ к задачам можно через подписку в бусти, там последний день скидок, или в боте.
На всякий случай мы рыли окопы, пытались перейти в альтернативы.
База знаний соощества работает и не удалена. Остаемся в ноушене, но кому-то нужно включить VPN.
В честь этого праздника я решил сделать новую рубрику. Я понял, как много контента генерирует чат и я его преступно нигде не фиксирую.
Мы пришли сюда, чтобы решать задачи. Как в Google. Как в Apple.
Только с конца августа и начала сентября мы обсудили около 30 технических вопросов, и около 20 реальных задач. Всего за 2 недели, а это больше и чаще чем подборки в ноушене, которые я делаю сам. Может пора делать журнал, с разными авторами, а не личный блог?
Я знаю, что 1/3 подписчиков не подписана на чат, а те кто подписан не всегда могут его читать. Поэтому решил сделать отдельную подборку. Теперь она моя самая любимая. Этот сборник посвящен всем вопросам и задачам, которые мы решали в сообществе, встречали на собеседованиях или на работе. Они будут в рандомном порядке, без тем и часто без ответов (так даже лучше для самостоятельного изучения).
Если ты не следишь за чатом, то это отличная возможность оставаться в курсе без активного мониторинга.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Карьера в FAANG
Прежде чем давать советы по оптимизации карьерных документов, давайте разберемся в общем процессе. Если вы уже знаете правила, не спешите закрывать этот пост, дайте ему шанс передать вам новую перспективу.
Итак, в Big Tech компаниях существует процесс под названием performance review. Каждый сотрудник хочет бонус побольше. Большинство сотрудников хотят повышения позиции. Чтобы жизнь организации не превратилась в хаос все время клянчущих денег сотрудников, эти естественные желания официально признаны, и организованы в стандартизированный процесс, который и назвали performance review, или, в простонародье, perf (перф). Прежде чем обсуждать суть дела, быстро про форму:
- Заранее готовится сетка требований для уровней, о которой я много писал
- 1-2 раза в год в фиксированные даты объявляется perf
- Каждый сотрудник пишет документ, который называется self assessment. В этом документе сотрудник описывает, что он полезного сделал для мира и компании, что у него получилось особенно хорошо, а где он в себе обнаружил слабые стороны
- Сотрудник так же просит коллег, с которыми работал, написать ему "peer feedback" -- то же самое, что и self assessment, только вкратце и с точки зрения коллеги
- Сотрудник сам пишет peer feedback для коллег
- Лиды организации собираются в calibration committee и обсуждают все self assessment документы, анализируют и соглашаются (или нет) с тезисами
- Дальше идет процесс stack ranking, который изобрел лично дьявол, поэтому я про него тут писать не буду (а еще потому, что о нем бесполезно писать, все равно кандидат ничего не может сделать, чтобы на него повлиять)
- В результате обсуждения self assessment документов сотруднику назначается "рейтинг"
- От рейтинга напрямую и значительно зависит годовой бонус -- можно заработать вплоть до x1.5 от ожидаемого
Дополнительно, сотрудник может номинировать себя на повышение уровня. Да, именно так: ты просто говоришь: по сетке требований я работаю на уровень выше, вот в моем self assessment все доказательства. Потому повышайте меня, чтобы моя работа на уровень выше была и оплачена тоже на уровень выше. В этом случае добавляется несколько шагов:
- Self assessment документ становится больше / полнее / сложнее написать, ведь нужны дополнительные доказательства для новой аудитории читателей
- Дополнительно к calibration committee собирается promo committee, обычно из более старших коллег (а в Гугле раньше еще и из случайных коллег со всего Гугла)
- Второй комитет решает, одобрить ли номинирование сотрудника или нет
- Senior leaders (обычно VP) подписывают одобренные номинации, делая повышение официальным
Такова форма, а в чем же суть? Суть процесса в том, чтобы главным по процессу получения бонусов и повышений был самый заинтересованный в них человек -- сам сотрудник. Именно он сам для себя изучает ладдер, весь год выбирает правильную работу, которая ему поможет на перфе, сам собирает все нужные доказательства, сам составляет self assessment -- презентацию своих аргументов, сам анализирует, что нужно изменить в работе в следующий цикл, чтобы в следующий раз составить еще более впечатляющий документ, который приведет к еще большим бонусам. Кандидат больше всех заинтересован в финансовом вознаграждении, а значит никто больше не сможет так хорошо доказать, что он его достоин. Такой процесс убирает гигатонны микроменеджмента, назначения задач, слежки, кто что сделал. Ведь perf рассудит.
Это теория. Реальность, как всегда, вносит свои коррективы. Их я буду обсуждать в следующем посте, а сейчас я предлагаю читателям (вы же инженеры!) найти уязвимости в этом процессе и мы обсудим их в комментариях.
#perf
Итак, в Big Tech компаниях существует процесс под названием performance review. Каждый сотрудник хочет бонус побольше. Большинство сотрудников хотят повышения позиции. Чтобы жизнь организации не превратилась в хаос все время клянчущих денег сотрудников, эти естественные желания официально признаны, и организованы в стандартизированный процесс, который и назвали performance review, или, в простонародье, perf (перф). Прежде чем обсуждать суть дела, быстро про форму:
- Заранее готовится сетка требований для уровней, о которой я много писал
- 1-2 раза в год в фиксированные даты объявляется perf
- Каждый сотрудник пишет документ, который называется self assessment. В этом документе сотрудник описывает, что он полезного сделал для мира и компании, что у него получилось особенно хорошо, а где он в себе обнаружил слабые стороны
- Сотрудник так же просит коллег, с которыми работал, написать ему "peer feedback" -- то же самое, что и self assessment, только вкратце и с точки зрения коллеги
- Сотрудник сам пишет peer feedback для коллег
- Лиды организации собираются в calibration committee и обсуждают все self assessment документы, анализируют и соглашаются (или нет) с тезисами
- Дальше идет процесс stack ranking, который изобрел лично дьявол, поэтому я про него тут писать не буду (а еще потому, что о нем бесполезно писать, все равно кандидат ничего не может сделать, чтобы на него повлиять)
- В результате обсуждения self assessment документов сотруднику назначается "рейтинг"
- От рейтинга напрямую и значительно зависит годовой бонус -- можно заработать вплоть до x1.5 от ожидаемого
Дополнительно, сотрудник может номинировать себя на повышение уровня. Да, именно так: ты просто говоришь: по сетке требований я работаю на уровень выше, вот в моем self assessment все доказательства. Потому повышайте меня, чтобы моя работа на уровень выше была и оплачена тоже на уровень выше. В этом случае добавляется несколько шагов:
- Self assessment документ становится больше / полнее / сложнее написать, ведь нужны дополнительные доказательства для новой аудитории читателей
- Дополнительно к calibration committee собирается promo committee, обычно из более старших коллег (а в Гугле раньше еще и из случайных коллег со всего Гугла)
- Второй комитет решает, одобрить ли номинирование сотрудника или нет
- Senior leaders (обычно VP) подписывают одобренные номинации, делая повышение официальным
Такова форма, а в чем же суть? Суть процесса в том, чтобы главным по процессу получения бонусов и повышений был самый заинтересованный в них человек -- сам сотрудник. Именно он сам для себя изучает ладдер, весь год выбирает правильную работу, которая ему поможет на перфе, сам собирает все нужные доказательства, сам составляет self assessment -- презентацию своих аргументов, сам анализирует, что нужно изменить в работе в следующий цикл, чтобы в следующий раз составить еще более впечатляющий документ, который приведет к еще большим бонусам. Кандидат больше всех заинтересован в финансовом вознаграждении, а значит никто больше не сможет так хорошо доказать, что он его достоин. Такой процесс убирает гигатонны микроменеджмента, назначения задач, слежки, кто что сделал. Ведь perf рассудит.
Это теория. Реальность, как всегда, вносит свои коррективы. Их я буду обсуждать в следующем посте, а сейчас я предлагаю читателям (вы же инженеры!) найти уязвимости в этом процессе и мы обсудим их в комментариях.
#perf
Кодревью: Запахи кода
Делюсь небольшим контентом связанным с запахами кода. Я уже делал один и второй сборник в закрытой базе знаний.
Здесь я же хочу поделиться интересными для меня "запахами", почти как парфюмер. Кода я понюхал много и чаще споры об этих запахах возникают на кодревью.
Давайте же разберем несколько примеров:
1. Force Unwrapping и Force Casting. Многими нелюбимая вещь, которая может привести к крашем. В проде нужно свести к минимуму любой потенциальный сбой приложения
2. Переизбыток синглтонов. Сами по себе синглтоны не несут в себе зла, но их злоупотребление может сделать код сложнее. Так усложнится рефакторинг и предсказуемость.
3. Дублирование кода. Наверное, самый частый запах. Когда код повторяется в разных местах класса или приложения, то усложняется, поддержка кода и возникает риск ухудшения стабильности приложения.
4. Надуманная сложность. Одна из главных проблем охотниками за повышениями и любителей поумничать — выдувать из воздуха сложность задач и делать сложным простое. Сорри, яндекс, но ваших разрабов часто за это ругают. Нужно всегда правильно рассчитывать как можно обойтись более лаконичным решением и не усложнять без необходимости.
5. Комментарии. Комментарии важны для любого кода, поскольку они улучшают понимание разработчиками этого конкретного кода. Следовательно, комментарии можно добавлять везде, где возникает необходимость, но не слишком много, поскольку это может нарушить поток кода и усложнить его.
Основная цель комментариев — определить логику и обоснование различных частей кода и объяснить их точку зрения. Однако разработчику следует избегать переусердствовать, поскольку слишком много комментариев приведет к усложнению и баннерной слепоте, а иногда и комментированию очевидных вещей.
Делюсь небольшим контентом связанным с запахами кода. Я уже делал один и второй сборник в закрытой базе знаний.
Здесь я же хочу поделиться интересными для меня "запахами", почти как парфюмер. Кода я понюхал много и чаще споры об этих запахах возникают на кодревью.
Термин “запах кода” (code smell) некоторое время назад был введен Кентом Беком и популяризирован книгой Мартина Фаулера о рефакторинге (Refactoring: Improving the Design of Existing Code).
В русскоязычном переводе можно встретить “код с душком”. Такой перевод явно говорит о том, что речь идет о чем-то не слишком хорошем.
Давайте же разберем несколько примеров:
1. Force Unwrapping и Force Casting. Многими нелюбимая вещь, которая может привести к крашем. В проде нужно свести к минимуму любой потенциальный сбой приложения
2. Переизбыток синглтонов. Сами по себе синглтоны не несут в себе зла, но их злоупотребление может сделать код сложнее. Так усложнится рефакторинг и предсказуемость.
3. Дублирование кода. Наверное, самый частый запах. Когда код повторяется в разных местах класса или приложения, то усложняется, поддержка кода и возникает риск ухудшения стабильности приложения.
4. Надуманная сложность. Одна из главных проблем охотниками за повышениями и любителей поумничать — выдувать из воздуха сложность задач и делать сложным простое. Сорри, яндекс, но ваших разрабов часто за это ругают. Нужно всегда правильно рассчитывать как можно обойтись более лаконичным решением и не усложнять без необходимости.
5. Комментарии. Комментарии важны для любого кода, поскольку они улучшают понимание разработчиками этого конкретного кода. Следовательно, комментарии можно добавлять везде, где возникает необходимость, но не слишком много, поскольку это может нарушить поток кода и усложнить его.
Основная цель комментариев — определить логику и обоснование различных частей кода и объяснить их точку зрения. Однако разработчику следует избегать переусердствовать, поскольку слишком много комментариев приведет к усложнению и баннерной слепоте, а иногда и комментированию очевидных вещей.
С днем программиста
Хочу поздравить всех программистов с этим праздником. С самого раннего детства я увлекался компьютерами и зарабатывал только с помощью них: проходил игры за деньги, переустанавливал винду и программы, записывал dvd диски с фильмами и продавал. В моем колхозе уже с 13 лет он помогал мне зарабатывать. Ничего другого я не умел.
Уже в студенчестве я начинал писать первые сайты на фрилансе, а потом уже и приложения. В чем-то другом я никогда не видел себя. Влюбившись в свое ремесло и каждый день стараясь быть лучше.
Поздравляю всех тех, кто любит свою профессию и получает удовольствие от работы. Гигабайты счастья и здоровья вам. Триллионы сумм на офферах
Хочу поздравить всех программистов с этим праздником. С самого раннего детства я увлекался компьютерами и зарабатывал только с помощью них: проходил игры за деньги, переустанавливал винду и программы, записывал dvd диски с фильмами и продавал. В моем колхозе уже с 13 лет он помогал мне зарабатывать. Ничего другого я не умел.
Уже в студенчестве я начинал писать первые сайты на фрилансе, а потом уже и приложения. В чем-то другом я никогда не видел себя. Влюбившись в свое ремесло и каждый день стараясь быть лучше.
Поздравляю всех тех, кто любит свою профессию и получает удовольствие от работы. Гигабайты счастья и здоровья вам. Триллионы сумм на офферах
Запах кода: необоснованная сложность
Поговорим чуть подробнее про запах кода "необоснованная сложность". Прошлый пример не всем понравился и я попробую дать пояснения.
Избыточная сложность — это когда мы пытаемся сделать слишком раздутые конструкции и усложнения, где можем обойтись без ущерба к выразительности.
Когда у нас есть золотая середина между лаконичностью и понятностью.
Конечно, можно сказать, что программист просто глупый и не привык сложностям. Это универсальное оправдание любой человеческой лени. Но в больших и крупных проектах мы пишем не просто рабочий код, но и код, который проще читать.
А читать проще код, который не строит из себя умного и объясняет сложные вещи просто. Экономит множество когнитивных ресурсов и упрощает понимание.
В скриншотах я приложил более понятный пример, который встречается на собеседованиях. А также отрывок из книги "Ум программиста. Как понять и осмыслить любой код". В следующих постах мы разберем отдельные главы подробнее
Поговорим чуть подробнее про запах кода "необоснованная сложность". Прошлый пример не всем понравился и я попробую дать пояснения.
Избыточная сложность — это когда мы пытаемся сделать слишком раздутые конструкции и усложнения, где можем обойтись без ущерба к выразительности.
Когда у нас есть золотая середина между лаконичностью и понятностью.
Конечно, можно сказать, что программист просто глупый и не привык сложностям. Это универсальное оправдание любой человеческой лени. Но в больших и крупных проектах мы пишем не просто рабочий код, но и код, который проще читать.
А читать проще код, который не строит из себя умного и объясняет сложные вещи просто. Экономит множество когнитивных ресурсов и упрощает понимание.
Одна из главных задач хорошего кода в проде — упростить когнитивную нагрузку
В скриншотах я приложил более понятный пример, который встречается на собеседованиях. А также отрывок из книги "Ум программиста. Как понять и осмыслить любой код". В следующих постах мы разберем отдельные главы подробнее
Ищу экспертов с опытом
Вчера записывали мок-собес, с разрабом из известного мессенджера, "как проектировать Телеграм" и получилось очень круто. Это не был собес, а получилось нечто среднее между интервью, мок-собесом, воркшопом и подкастом.
Мне всегда были скучны подкасты и неинтересны. Из 1,5 часов обычно можно сжать до 15 минут. А тут формат систем дизайна держит внимание и не отвлекает от мыслей. Как в том меме в инстаграмах про кинотеатр для СДВГшников, где на пол экрана идет фильм, а на остальные пол экрана идет какой-то рандомный видос.
В таком уникальном формате ты получаешь сразу визуализацию мыслей, а опыт эксперта помогает узнать какие подводные камни могут ожидать тебя при разработке нетривиальных задач. Так в дружеской атмосфере мы узнали о пагинации и синхронизации сообщений, а также производительности.
Это вдохновило меня снова улучшить контент и собирать для такого формата экспертов с уникальным опытом. Поэтому ищу ребят для подкаста-интервью в формате систем дизайна:
- экспертов CI/CD
- архитекторов
- разрабов GPU
- необычных приложений
- музыкальных и видео плееров
- разрабов дизайн системы
- BDUI
- кроспплатформу
- и других
Такое интервью будет без оценок и свободным в формате воркшопа, где аудитория сразу получит лучшие практики.
Ну и если ты просто хочешь пройти собес для самопроверки, то тоже пиши
Вчера записывали мок-собес, с разрабом из известного мессенджера, "как проектировать Телеграм" и получилось очень круто. Это не был собес, а получилось нечто среднее между интервью, мок-собесом, воркшопом и подкастом.
Мне всегда были скучны подкасты и неинтересны. Из 1,5 часов обычно можно сжать до 15 минут. А тут формат систем дизайна держит внимание и не отвлекает от мыслей. Как в том меме в инстаграмах про кинотеатр для СДВГшников, где на пол экрана идет фильм, а на остальные пол экрана идет какой-то рандомный видос.
В таком уникальном формате ты получаешь сразу визуализацию мыслей, а опыт эксперта помогает узнать какие подводные камни могут ожидать тебя при разработке нетривиальных задач. Так в дружеской атмосфере мы узнали о пагинации и синхронизации сообщений, а также производительности.
Это вдохновило меня снова улучшить контент и собирать для такого формата экспертов с уникальным опытом. Поэтому ищу ребят для подкаста-интервью в формате систем дизайна:
- экспертов CI/CD
- архитекторов
- разрабов GPU
- необычных приложений
- музыкальных и видео плееров
- разрабов дизайн системы
- BDUI
- кроспплатформу
- и других
Такое интервью будет без оценок и свободным в формате воркшопа, где аудитория сразу получит лучшие практики.
Ну и если ты просто хочешь пройти собес для самопроверки, то тоже пиши
Жирный подгон вам ко дню программиста! В прошлом посте я говорил, что совершенно случайно получился новый формат. Он похож на смесь мок-интервью, воркшопа и подкастов.
В нем мы попытались спроектировать телеграм с помощью эксперта, у которого рабочий опыт был только в чатах. Чаты — это отдельный вид приложений, со своей сложностью и спецификой. В них много бизнес-логики, а процент разнообразия куда больше, чем в регулярном приложении.
Получилось очень здорово. Мы проговорили:
Такое интервью получилось куда более полезным, где ты понимаешь нюансы и тонкостей разработки. Обогащая себя новыми знаниями и увеличивая кругозор. Мне дико понравилось.
Для следующих таких интервью ищу ребят из платформенных команд, FAANG'ов или видео/аудио плееров.
Канал эксперта: @alexdevaslifestyle
Please open Telegram to view this post
VIEW IN TELEGRAM