Мы пережили блокировку ноушена.
На всякий случай мы рыли окопы, пытались перейти в альтернативы.
База знаний соощества работает и не удалена. Остаемся в ноушене, но кому-то нужно включить 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
Что выведется в консоль?
Anonymous Quiz
11%
5, 10
5%
Ошибка компиляции
8%
10, 10
33%
5
38%
10
5%
nil
Почему вам нужен ментор
Пару месяцев назад я разочаровался в менторстве, но благодаря новой системе мотивации на рынке, где поощряют менторство, и многим умным людям пересмотрел. Это не поменяло моего отношения к куче низкокачественных специалистов, которые используют беззащитность и наивность новичков и продают советы по накрутке как что-то полезное и высококачественное.
Я скорее увидел другую сторону. Качественную культуру взаимного роста. Где огромное множество существует хороших менторов, которых так просто не найдешь в интернете и чьи услуги не всегда доступны. Кто не впихивает свою "консультацию", а использует это как инстурмент развития.
Белых и серых менторов, кто помогает расти себе и другим. Делятся своей уникальной экспертизой, выходят за границы запроса "пройти собесы", развивают инженерную культуру и площадки для взаимообогащения. Разбираются в педагогике и дают хорошие ориентиры для дальнейшего обоюдного сотрудничества. Таким мне больше нравится быть.
Более того, я продолжаю искать ментора себе, который будет подсвечивать точки роста и помогать распутывать узлы.
Вот хороший выпуск от ex топов крупных компаний как майрософт и jetbrains. Авторы разбирают крутые вопросы:
🟣 Зачем менти нужно идти к ментору
🟣 Различие между коучем и ментороством
🟣 Зачем ментору менторство
🟣 Гросс майндсет
🟣 Конфлиткты интересов и многое другое
Пару месяцев назад я разочаровался в менторстве, но благодаря новой системе мотивации на рынке, где поощряют менторство, и многим умным людям пересмотрел. Это не поменяло моего отношения к куче низкокачественных специалистов, которые используют беззащитность и наивность новичков и продают советы по накрутке как что-то полезное и высококачественное.
Я скорее увидел другую сторону. Качественную культуру взаимного роста. Где огромное множество существует хороших менторов, которых так просто не найдешь в интернете и чьи услуги не всегда доступны. Кто не впихивает свою "консультацию", а использует это как инстурмент развития.
Белых и серых менторов, кто помогает расти себе и другим. Делятся своей уникальной экспертизой, выходят за границы запроса "пройти собесы", развивают инженерную культуру и площадки для взаимообогащения. Разбираются в педагогике и дают хорошие ориентиры для дальнейшего обоюдного сотрудничества. Таким мне больше нравится быть.
Более того, я продолжаю искать ментора себе, который будет подсвечивать точки роста и помогать распутывать узлы.
Вот хороший выпуск от ex топов крупных компаний как майрософт и jetbrains. Авторы разбирают крутые вопросы:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Почему вам нужен ментор?
Андрей Бреслав (ex-JetBrains, а теперь основатель стартапа) и Александр Ложечкин (ex-Microsoft, ex-Amazon, а теперь CIO в банке) рассуждают, спорят, делятся опытом, и просто болтают на темы развития людей, руководства, технологий и всего остального.
Сайт…
Сайт…
Никто не будет думать о твоем повышении кроме тебя
Сейчас читаю нахваленную многими книгу 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