🌃 Тысяча и одно собеседование
Статья за авторством Carlos Arguelles, бывший Bar Raiser в Амазон. За свою карьеру провел больше 1000 собеседований.
Carlos поделился своей любимой задачей по алгоритмам, которую уже задавал порядка 500 раз и которая, по его мнению, на 95% совпадает с итоговым решением.
Дополню пару интересных инсайтов:
1️⃣ Для меня гораздо важнее сама беседа, чем код, который человек пишет на доске.
Многие стремятся сразу написать сходу супер оптимальное решение. Хотя, интервьюер оценивает не только код, но и способ мышления. Какие вопросы задает кандидат, подмечает ли edge cases, как оценивает решения, сколько помощи требует. В конце концов, собеседование это поиск ответа на вопрос «Смогу ли я работать с этим человеком?».
2️⃣ Наиболее грамотные кандидаты, прежде чем переходить к написанию кода, должны задавать уточняющие вопросы.
В реальности инженеры постоянно сталкиваются с неоднозначностью. Задача в джире обычно только название 🙂. Никто из нас не спешит сразу писать код, как только получил тикет от менеджера. Скорее всего будут вопросы, уточнения, дискуссия. Чем опытнее разработчик, тем более глубокие вопросы он задает.
Поэтому алгоритмическую секцию можно представлять как разработку фичи в миниатюре.
3️⃣ Более грамотные специалисты догадываются, что скорость поиска O(1), необходимую для превращения O(n²) в O(n), может обеспечить словарь (Map). Лучшие же кандидаты предусмотрительно отмечают недостаток такого подхода, заключающийся в использовании O(n) памяти. Здесь повышение скорости достигается за счёт увеличенного потребления памяти.
Часто, на собеседованиях, как и на работе, есть несколько способов решить одну и туже задачу. Так вот интервьюер оценивает наше понимание плюсов и минусов каждого предложенного подхода. Поэтому, нужно уметь считать сложность и знать время и память основных структур данных и алгоритмов. Это домашняя работа кандидата.
➡️ Ссылки на статьи
https://habr.com/ru/companies/ruvds/articles/775570/
https://medium.com/geekculture/memoirs-of-an-amazon-bar-raiser-718e36241310
Статья за авторством Carlos Arguelles, бывший Bar Raiser в Амазон. За свою карьеру провел больше 1000 собеседований.
Carlos поделился своей любимой задачей по алгоритмам, которую уже задавал порядка 500 раз и которая, по его мнению, на 95% совпадает с итоговым решением.
Дополню пару интересных инсайтов:
1️⃣ Для меня гораздо важнее сама беседа, чем код, который человек пишет на доске.
Многие стремятся сразу написать сходу супер оптимальное решение. Хотя, интервьюер оценивает не только код, но и способ мышления. Какие вопросы задает кандидат, подмечает ли edge cases, как оценивает решения, сколько помощи требует. В конце концов, собеседование это поиск ответа на вопрос «Смогу ли я работать с этим человеком?».
2️⃣ Наиболее грамотные кандидаты, прежде чем переходить к написанию кода, должны задавать уточняющие вопросы.
В реальности инженеры постоянно сталкиваются с неоднозначностью. Задача в джире обычно только название 🙂. Никто из нас не спешит сразу писать код, как только получил тикет от менеджера. Скорее всего будут вопросы, уточнения, дискуссия. Чем опытнее разработчик, тем более глубокие вопросы он задает.
Поэтому алгоритмическую секцию можно представлять как разработку фичи в миниатюре.
3️⃣ Более грамотные специалисты догадываются, что скорость поиска O(1), необходимую для превращения O(n²) в O(n), может обеспечить словарь (Map). Лучшие же кандидаты предусмотрительно отмечают недостаток такого подхода, заключающийся в использовании O(n) памяти. Здесь повышение скорости достигается за счёт увеличенного потребления памяти.
Часто, на собеседованиях, как и на работе, есть несколько способов решить одну и туже задачу. Так вот интервьюер оценивает наше понимание плюсов и минусов каждого предложенного подхода. Поэтому, нужно уметь считать сложность и знать время и память основных структур данных и алгоритмов. Это домашняя работа кандидата.
https://habr.com/ru/companies/ruvds/articles/775570/
https://medium.com/geekculture/memoirs-of-an-amazon-bar-raiser-718e36241310
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥20❤3
📈Люди увольняются, акции поднимаются
Spotify анонсировала, что сократит штат на 17% это примерно 1500 сотрудников.
Акции Spotify подпрыгнули на 7% после того, как компания объявила о сокращении штата сотрудников на 17% в рамках меры по сокращению расходов из-за замедления роста.
Генеральный директор Дэниел Эк упомянул во внутренней записке, что компания слишком быстро расширялась в 2020 и 2021 годах.
«В 2020 и 2021 годах мы воспользовались возможностью, предоставленной более дешевым капиталом, и вложили значительные средства в расширение команды, улучшение контента, маркетинг и новые вертикали»
Напомню, что это уже третья волна увольнений в Spotify за этот год. В январе штат сократился на 6%, а в июне еще на 2% 😐
➡️ Ссылка на новость
https://www.cnbc.com/2023/12/04/spotify-to-lay-off-17percent-of-employees-ceo-daniel-ek-says.html
Spotify анонсировала, что сократит штат на 17% это примерно 1500 сотрудников.
Акции Spotify подпрыгнули на 7% после того, как компания объявила о сокращении штата сотрудников на 17% в рамках меры по сокращению расходов из-за замедления роста.
Генеральный директор Дэниел Эк упомянул во внутренней записке, что компания слишком быстро расширялась в 2020 и 2021 годах.
«В 2020 и 2021 годах мы воспользовались возможностью, предоставленной более дешевым капиталом, и вложили значительные средства в расширение команды, улучшение контента, маркетинг и новые вертикали»
Напомню, что это уже третья волна увольнений в Spotify за этот год. В январе штат сократился на 6%, а в июне еще на 2% 😐
https://www.cnbc.com/2023/12/04/spotify-to-lay-off-17percent-of-employees-ceo-daniel-ek-says.html
Please open Telegram to view this post
VIEW IN TELEGRAM
😢11❤4😱4👍1🤷1
🎄Что ждет FAANG в 2024 году?
Найм в Meta вырос на 800% с января, в Netflix на 300%.
Вы просили хороших новостей, получайте 🙂
Сайт interviewing.io на основе своих данных, подготовил предсказания на 2024 год. Сервис отслеживает, кто в какие компании готовится, какие мок-интервью покупает и кто в конце концов получает оферы.
И так поехали:
• В 2024 году FAANG начнет нанимать больше инженеров. Сейчас только Meta и Netflix агрессивно нанимают, но в следующем году остальные компании последуют их примеру.
• С января 2024 года найм мидлов и синьоров значительно вырастет.
• Как минимум ближайшие 6 месяцев компенсационный пакет не изменится (зарплаты, бонусы, акции).
• Как минимум следующие полгода, компании будут продолжать пытаться убедить кандидата принять офер на ступень ниже. В FAANG есть вероятность 57% что вам предложат грейд ниже вашего. В других компаниях этот показатель 37%.
• По крайней мере, в течение следующих 6 месяцев рекрутеры будут испытывать большую нагрузку, а это означает, что не стоит откликаться на вакансию на сайте, лучше напрямую связаться с рекрутером.
• Не смотря на благоприятный прогноз, рынок еще долго не вернется к прежнему состоянию.
➡️ Ссылка на статью
https://interviewing.io/blog/when-is-hiring-coming-back-predictions-for-2024
✔️ Поставь 🎄, если в следующем году точно получишь офер в MAANG.
Найм в Meta вырос на 800% с января, в Netflix на 300%.
Вы просили хороших новостей, получайте 🙂
Сайт interviewing.io на основе своих данных, подготовил предсказания на 2024 год. Сервис отслеживает, кто в какие компании готовится, какие мок-интервью покупает и кто в конце концов получает оферы.
И так поехали:
• В 2024 году FAANG начнет нанимать больше инженеров. Сейчас только Meta и Netflix агрессивно нанимают, но в следующем году остальные компании последуют их примеру.
• С января 2024 года найм мидлов и синьоров значительно вырастет.
• Как минимум ближайшие 6 месяцев компенсационный пакет не изменится (зарплаты, бонусы, акции).
• Как минимум следующие полгода, компании будут продолжать пытаться убедить кандидата принять офер на ступень ниже. В FAANG есть вероятность 57% что вам предложат грейд ниже вашего. В других компаниях этот показатель 37%.
• По крайней мере, в течение следующих 6 месяцев рекрутеры будут испытывать большую нагрузку, а это означает, что не стоит откликаться на вакансию на сайте, лучше напрямую связаться с рекрутером.
• Не смотря на благоприятный прогноз, рынок еще долго не вернется к прежнему состоянию.
https://interviewing.io/blog/when-is-hiring-coming-back-predictions-for-2024
Please open Telegram to view this post
VIEW IN TELEGRAM
🎄53🙏7❤4🔥4👍3
🦕 40 лет Turbo Pascal
Сам язык Pascal появился 1970 году, благодаря профессору Niklaus Emil Wirth. С того времени были созданы различные компиляторы, для работы с этим языком.
Чтобы создать исполняемый файл, приходилось несколько раз прогонять программу через компилятор и записывать данные на дискету, что занимало много времени.
Инженер Anders Hejlsberg увидел возможность ускорить работу компилятора, делая все операции в памяти. Так он написал новый компилятор для Pascal, который взяла под свое крыло компания Borland.
В 1983 году появилась первая версия Turbo Pascal. Borland продавала ее за какие-то $49.99, в то время как конкуренты продавали за сотни и тысячи долларов. Скорость компилятора и его стоимость стали причиной стремительного роста популярности.
В 1987 году у Turbo Pascal появился интерфейс с меню, а в 1988 вышла пятая версия со знаменитым голубым бэкграундом и пошаговым дебагером. 🩵
Последняя официальная версия 7.0 вышла в 1992 году. Стоит отметить, что помимо Turbo Pascal, компания продавала более дорогую версию Borland Pascal с дополнительными фичами для Windows.
К сожалению звезда Turbo и Borland Pascal начала медленно угасать с появлением нового поколения инструментов, таких как Delphi, Visual Basic 3, C++.
➡️ Ссылка на статью
https://www.theregister.com/2023/12/04/40_years_of_turbo_pascal
━━━━━━━
Turbo Pascal был первым языком, с которого я начал свой путь в программирование. Удобный, быстрый, простой. До сих пор пальцы помнят «var begin end».
Мы решали олимпиадные задачи на Паскале. На нем не было готовых реализаций сортировок, очередей, хэш таблиц, все приходилось писать самому. Помню, как мы радовались, когда в папке с freepascal можно было найти готовую реализацию быстрой сортировки.
Кстати, на https://codeforces.com/ можно решать задачи на Паскале. Leetcode к сожалению его не поддерживает.
✔️ Есть тут те, кому олдскулы свело? Кто писал на Pascal, Basic, Cobol?
Сам язык Pascal появился 1970 году, благодаря профессору Niklaus Emil Wirth. С того времени были созданы различные компиляторы, для работы с этим языком.
Чтобы создать исполняемый файл, приходилось несколько раз прогонять программу через компилятор и записывать данные на дискету, что занимало много времени.
Инженер Anders Hejlsberg увидел возможность ускорить работу компилятора, делая все операции в памяти. Так он написал новый компилятор для Pascal, который взяла под свое крыло компания Borland.
В 1983 году появилась первая версия Turbo Pascal. Borland продавала ее за какие-то $49.99, в то время как конкуренты продавали за сотни и тысячи долларов. Скорость компилятора и его стоимость стали причиной стремительного роста популярности.
В 1987 году у Turbo Pascal появился интерфейс с меню, а в 1988 вышла пятая версия со знаменитым голубым бэкграундом и пошаговым дебагером. 🩵
Последняя официальная версия 7.0 вышла в 1992 году. Стоит отметить, что помимо Turbo Pascal, компания продавала более дорогую версию Borland Pascal с дополнительными фичами для Windows.
К сожалению звезда Turbo и Borland Pascal начала медленно угасать с появлением нового поколения инструментов, таких как Delphi, Visual Basic 3, C++.
https://www.theregister.com/2023/12/04/40_years_of_turbo_pascal
━━━━━━━
Turbo Pascal был первым языком, с которого я начал свой путь в программирование. Удобный, быстрый, простой. До сих пор пальцы помнят «var begin end».
Мы решали олимпиадные задачи на Паскале. На нем не было готовых реализаций сортировок, очередей, хэш таблиц, все приходилось писать самому. Помню, как мы радовались, когда в папке с freepascal можно было найти готовую реализацию быстрой сортировки.
Кстати, на https://codeforces.com/ можно решать задачи на Паскале. Leetcode к сожалению его не поддерживает.
Please open Telegram to view this post
VIEW IN TELEGRAM
🫡21👍5❤2🤯2😢2☃1
🤿 Как саботировать работу?
ЦРУ во время второй мировой войны выпустило книгу «Simple Sabotage». В ней изложены различные способы, с помощью которых злоумышленники могут подорвать производительность компании.
Если злоумышленник например, с порога начнет совать палки в колеса коллегам и менеджерам, то его быстро вычислят и уволят. Поэтому саботировать тоже нужно уметь правильно.
Некоторые советы вечны и применимы к нашей области:
1. Все должно быть по правилам и с соблюдением бюрократии. Не допускайте «срезания углов» и быстрых решений.
2. Много говорите и как можно дольше. Рассказывайте личные истории и анекдоты.
3. Старайтесь все вопросы оставлять для «дальнейшего изучения». Привлекайте как можно больше людей к обсуждению, не меньше пяти.
4. Как можно чаще поднимайте проблемы, которые не относятся к делу. Требуйте точных формулировок, соблюдения процессов и протоколов.
5. Возвращайтесь к уже решенным вопросам и пробуйте вновь начать дискуссию о целесообразности решения.
6. Советуйте всем действовать осторожно и избегать спешки. Говорите, что спешка может привести к затруднениям в дальнейшем.
7. Поднимайте вопрос о правомерности. Может ли какая-то группа людей принимать определенные действия или нет, не противоречит ли это юрисдикции департамента и политике компании.
➡️ Ссылка на статью
https://erikbern.com/2023/12/13/simple-sabotage-for-software.html
━━━━━━━━━
Как по мне, гайд выглядит обратной стороной Agile разработки.
Этот пост не для того, чтобы кто-то начал саботировать свою команду, а больше чтобы понять, нет ли рядом с вами такого человека.
А еще более важный вопрос, не являемся ли мы сами дезертирами?
Ведь даже если человек не хочет навредить компании, он подсознательно может саботировать работу тимлида, менеджера, команды, которая ему чем-то неугадила.
❓Анонимный опрос:
Поставь 😈, если хоть раз в жизни специально затягивал работу, мешал коллегам или докапывался до мелочей
😇, если не наблюдал за собой такого
ЦРУ во время второй мировой войны выпустило книгу «Simple Sabotage». В ней изложены различные способы, с помощью которых злоумышленники могут подорвать производительность компании.
Если злоумышленник например, с порога начнет совать палки в колеса коллегам и менеджерам, то его быстро вычислят и уволят. Поэтому саботировать тоже нужно уметь правильно.
Некоторые советы вечны и применимы к нашей области:
1. Все должно быть по правилам и с соблюдением бюрократии. Не допускайте «срезания углов» и быстрых решений.
2. Много говорите и как можно дольше. Рассказывайте личные истории и анекдоты.
3. Старайтесь все вопросы оставлять для «дальнейшего изучения». Привлекайте как можно больше людей к обсуждению, не меньше пяти.
4. Как можно чаще поднимайте проблемы, которые не относятся к делу. Требуйте точных формулировок, соблюдения процессов и протоколов.
5. Возвращайтесь к уже решенным вопросам и пробуйте вновь начать дискуссию о целесообразности решения.
6. Советуйте всем действовать осторожно и избегать спешки. Говорите, что спешка может привести к затруднениям в дальнейшем.
7. Поднимайте вопрос о правомерности. Может ли какая-то группа людей принимать определенные действия или нет, не противоречит ли это юрисдикции департамента и политике компании.
https://erikbern.com/2023/12/13/simple-sabotage-for-software.html
━━━━━━━━━
Как по мне, гайд выглядит обратной стороной Agile разработки.
Этот пост не для того, чтобы кто-то начал саботировать свою команду, а больше чтобы понять, нет ли рядом с вами такого человека.
А еще более важный вопрос, не являемся ли мы сами дезертирами?
Ведь даже если человек не хочет навредить компании, он подсознательно может саботировать работу тимлида, менеджера, команды, которая ему чем-то неугадила.
❓Анонимный опрос:
Поставь 😈, если хоть раз в жизни специально затягивал работу, мешал коллегам или докапывался до мелочей
😇, если не наблюдал за собой такого
Please open Telegram to view this post
VIEW IN TELEGRAM
😇16😈13👍6
#️⃣ Удалил код, сел в тюрьму
Если вы когда-нибудь захотите напакостить своей компании из-за увольнения, вот пример почему этого делать не стоит.
Miklos Daniel Brody разработчик в банке, который был уволен, когда подключил к рабочему компьютеру флешку с порнографией.
Разъяренный таким решением, Brody не вернул рабочий лаптоп, снес всю кодовую базу компании, оставив насмешки над коллегами в коде, запустил скрипт для удаления всех логов, а также внес изменения в инфру из-под других учетных записей. Еще он выписал себе промокод от имени банка на сумму 5000$.
После начала расследования, Brody сказал, что его лаптоп украли из машины. Но ему это не помогло, его посадили на два года и обязали выплатить компенсацию в размере 529000$.
➡️ Ссылка на новость
https://www.bleepingcomputer.com/news/security/cloud-engineer-gets-2-years-for-wiping-ex-employers-code-repos
Если вы когда-нибудь захотите напакостить своей компании из-за увольнения, вот пример почему этого делать не стоит.
Miklos Daniel Brody разработчик в банке, который был уволен, когда подключил к рабочему компьютеру флешку с порнографией.
Разъяренный таким решением, Brody не вернул рабочий лаптоп, снес всю кодовую базу компании, оставив насмешки над коллегами в коде, запустил скрипт для удаления всех логов, а также внес изменения в инфру из-под других учетных записей. Еще он выписал себе промокод от имени банка на сумму 5000$.
После начала расследования, Brody сказал, что его лаптоп украли из машины. Но ему это не помогло, его посадили на два года и обязали выплатить компенсацию в размере 529000$.
https://www.bleepingcomputer.com/news/security/cloud-engineer-gets-2-years-for-wiping-ex-employers-code-repos
Please open Telegram to view this post
VIEW IN TELEGRAM
😐10🤔5👍3☃1
🏰System Design: розовые замки
Если говорить честно, то интервью на System Design немного оторвано от реальности. На собеседовании нас просят спроектировать систему, которая выдержит миллион активных пользователей, сохранит терабайты данных, будет устойчива к разным сценариям отказа.
Но в реальности нас ждет проект, который писался годами, если не десятилетиями, руками множества разработчиков. Код, который уже не такой гибкий к изменениям, который имеет свои костыли и велосипеды. Ограничения в выборе стэка: нельзя использовать NoSQL, нельзя в зоопарк добавить Кафку, нельзя использовать веб-сокеты и так далее.
То есть вероятность того, что придется писать сервис абсолютно с нуля низкая. Но даже если и придется писать новый проект, никто не будет начинать с микросервисов и огромных кластеров базы данных (если только вы не пишите мессенджер Aitu или сервис Threads). Скорее всего это будет MVP, который решает главную боль пользователя и затем, разработчики будут итеративно улучшать продукт.
Получается такой когнитивный диссонанс, на собеседовании проектируешь Instagram, а на работе пытаешься подстраиваться под реалии проекта. Мне кажется, это немного разные навыки.
Более честным подходом было бы изначально предлагать кандидату придумать архитектуру с маленькой нагрузкой и смотреть, предложит ли он супер дорогое решение или дешевое и быстрое. И потом постепенно накидывать новые вводные, и наблюдать, какие минимальные архитектурные изменения человек предлагает.
✔️ Мораль такая, что уметь адаптироваться под задачи проекта и совершенствовать сервис исходя из нагрузки, важнее, чем проектировать системы в вакууме.
Если говорить честно, то интервью на System Design немного оторвано от реальности. На собеседовании нас просят спроектировать систему, которая выдержит миллион активных пользователей, сохранит терабайты данных, будет устойчива к разным сценариям отказа.
Но в реальности нас ждет проект, который писался годами, если не десятилетиями, руками множества разработчиков. Код, который уже не такой гибкий к изменениям, который имеет свои костыли и велосипеды. Ограничения в выборе стэка: нельзя использовать NoSQL, нельзя в зоопарк добавить Кафку, нельзя использовать веб-сокеты и так далее.
То есть вероятность того, что придется писать сервис абсолютно с нуля низкая. Но даже если и придется писать новый проект, никто не будет начинать с микросервисов и огромных кластеров базы данных (если только вы не пишите мессенджер Aitu или сервис Threads). Скорее всего это будет MVP, который решает главную боль пользователя и затем, разработчики будут итеративно улучшать продукт.
Получается такой когнитивный диссонанс, на собеседовании проектируешь Instagram, а на работе пытаешься подстраиваться под реалии проекта. Мне кажется, это немного разные навыки.
Более честным подходом было бы изначально предлагать кандидату придумать архитектуру с маленькой нагрузкой и смотреть, предложит ли он супер дорогое решение или дешевое и быстрое. И потом постепенно накидывать новые вводные, и наблюдать, какие минимальные архитектурные изменения человек предлагает.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍31
Телеграм-каналы об ИТ в Казахстане, за которыми стоит следить в 2024 году👨💻
В этом году ИТ-сфера Казахстана радовала нас хорошими новостями. Многие стартапы привлекли серьезные раунды инвестиций (в том числе и от зарубежных инвесторов) и выходили на рынки других стран по всему миру: Юго-Восточная Азия, MENA, Европа, США и т.д. Чтобы не упустить важные события из мира ИТ, мы решили собрать подборку телеграм-каналов об ИТ в Казахстане, за которыми стоит следить в 2024 году.
👉Для удобства поместили все в специальную 📂 папку IT KZ
1. Astana Hub – канал крупнейшего технопарка в Центральной Азии. Новости стартап-комьюнити, анонсы многочисленных обучающих, инкубационных и акселерационных программ и ивентов. Прямые эфиры по актуальным для стартапов темам с экспертами отрасли, истории успехов казахстанцев (и не только) в ИТ, а также выгодные предложения и ивенты от партнеров Astana Hub.
2. Digital Business – популярное медиа про ИТ в Казахстане. Стараемся первыми сообщать о сделках, новых проектах стартаперов, важных событиях в ИТ-отрасли страны и мира. Развиваем сообщество казахстанского бизнеса, увлеченного digital-технологиями.
3. BlueScreen – надежный источник ключевых новостей, тенденций и достижений в ИТ – сфере. На канале вы найдете качественные статьи, интервью, обзоры и аналитические материалы, которые помогут быть в курсе последних тенденций всего ИТ- мира.
4. Kolesa Group – международная продуктовая ИТ-компания из Казахстана. В своем канале ребята делятся экспертизой по востребованным ИТ-направлениям. Также анонсируют оплачиваемые стажировки, ивенты, выпуски Kolesa Podcast, записи докладов и другие полезности.
5. Возможности startup-course.com – на канале рассказывают о конкурсах, где можно выиграть грант на свой стартап, а также ивентах, событиях, мероприятиях, мастер-классах и всей стартап-движухе в 17 городах Казахстана.
6. Datanomika – канал сооснователя компании Datanomix.pro Александра Полоротова про монетизацию, управление корпоративными данными и внедрение Self Service BI
7. Almaty IT Community – чат, где вы можете узнать о предстоящих ивентах сообщества, трендах в мире ИТ, обсудить проекты и идеи, найти для себя эксперта или эдвайзера. Мы стремимся собрать идеи и проекты, направленные на развитие профессиональных навыков, поддержку образовательных программ и создание благоприятной среды для молодых талантов, стремящихся внести свой вклад в ИТ-сферу. Наша миссия – объединить представителей технологичной сферы
8.BigTechDream – канал разработчика в Canva (Сидней) Тимура Тибеева, где он дает взгляд изнутри на мир собеседований и Big Tech. Здесь вы узнаете не только о том, как успешно пройти различные этапы собеседований в MAANG, но и найдете ценные материалы по стратегиям карьерного роста. А еще Тимур делится свежими новостями из динамичного мира Big Tech.
9.Стартап слезам не верит – это информационное пространство от холдинга MOST, созданное для предпринимателей, инвесторов и всех, кто интересуется стартап-культурой и инновациями. Канал предлагает свежие новости о венчурных сделках, аналитические статьи, экспертные мнения и истории успеха от основателей проектов.
Ссылка, чтобы сразу подписаться на все каналы и следить за важными новостями ИТ-сферы Казахстана — https://news.1rj.ru/str/addlist/u9LheiS-E8hjMjZi
В этом году ИТ-сфера Казахстана радовала нас хорошими новостями. Многие стартапы привлекли серьезные раунды инвестиций (в том числе и от зарубежных инвесторов) и выходили на рынки других стран по всему миру: Юго-Восточная Азия, MENA, Европа, США и т.д. Чтобы не упустить важные события из мира ИТ, мы решили собрать подборку телеграм-каналов об ИТ в Казахстане, за которыми стоит следить в 2024 году.
👉Для удобства поместили все в специальную 📂 папку IT KZ
1. Astana Hub – канал крупнейшего технопарка в Центральной Азии. Новости стартап-комьюнити, анонсы многочисленных обучающих, инкубационных и акселерационных программ и ивентов. Прямые эфиры по актуальным для стартапов темам с экспертами отрасли, истории успехов казахстанцев (и не только) в ИТ, а также выгодные предложения и ивенты от партнеров Astana Hub.
2. Digital Business – популярное медиа про ИТ в Казахстане. Стараемся первыми сообщать о сделках, новых проектах стартаперов, важных событиях в ИТ-отрасли страны и мира. Развиваем сообщество казахстанского бизнеса, увлеченного digital-технологиями.
3. BlueScreen – надежный источник ключевых новостей, тенденций и достижений в ИТ – сфере. На канале вы найдете качественные статьи, интервью, обзоры и аналитические материалы, которые помогут быть в курсе последних тенденций всего ИТ- мира.
4. Kolesa Group – международная продуктовая ИТ-компания из Казахстана. В своем канале ребята делятся экспертизой по востребованным ИТ-направлениям. Также анонсируют оплачиваемые стажировки, ивенты, выпуски Kolesa Podcast, записи докладов и другие полезности.
5. Возможности startup-course.com – на канале рассказывают о конкурсах, где можно выиграть грант на свой стартап, а также ивентах, событиях, мероприятиях, мастер-классах и всей стартап-движухе в 17 городах Казахстана.
6. Datanomika – канал сооснователя компании Datanomix.pro Александра Полоротова про монетизацию, управление корпоративными данными и внедрение Self Service BI
7. Almaty IT Community – чат, где вы можете узнать о предстоящих ивентах сообщества, трендах в мире ИТ, обсудить проекты и идеи, найти для себя эксперта или эдвайзера. Мы стремимся собрать идеи и проекты, направленные на развитие профессиональных навыков, поддержку образовательных программ и создание благоприятной среды для молодых талантов, стремящихся внести свой вклад в ИТ-сферу. Наша миссия – объединить представителей технологичной сферы
8.BigTechDream – канал разработчика в Canva (Сидней) Тимура Тибеева, где он дает взгляд изнутри на мир собеседований и Big Tech. Здесь вы узнаете не только о том, как успешно пройти различные этапы собеседований в MAANG, но и найдете ценные материалы по стратегиям карьерного роста. А еще Тимур делится свежими новостями из динамичного мира Big Tech.
9.Стартап слезам не верит – это информационное пространство от холдинга MOST, созданное для предпринимателей, инвесторов и всех, кто интересуется стартап-культурой и инновациями. Канал предлагает свежие новости о венчурных сделках, аналитические статьи, экспертные мнения и истории успеха от основателей проектов.
Ссылка, чтобы сразу подписаться на все каналы и следить за важными новостями ИТ-сферы Казахстана — https://news.1rj.ru/str/addlist/u9LheiS-E8hjMjZi
🍾8👍6☃1
🏆ICPC NERC Finals
Во-первых всех с Новым Годом, друзья 🌲
2024 это почти 1024, а значит нас всех ждет удача в этом году 🙂
А теперь к новости
В декабре уже прошлого года прошло знаковое событие для нашего региона - финал Евразийского региона по ICPC (International Collegiate Programming Contest).
ICPC - это ежегодное соревнование по спортивному программированию среди студенческих команд. В команде участвует по три человека. Чтобы дойти до финала, нужно пройти отборочные соревнования.
Финал региона проходил в 4 городах: Санкт-Петербург, Астана, Новосибирск, Кутаиси. За 5 часов нужно было решить максимальное количество задач из 12 возможных.
🥇Первое место заняла команда из МФТИ «Yolki-palki» (Nagibin, Evteev, Mustafin), которая единственная решила все 12 задач.
🇰🇿Отдельно отмечу команду из AITU университета, которая заняла 14 место и имеет шанс отобраться на финал: jaujurek 3 bala (Biakhmet, Oralkhanov, Kamzabek). Пожелаем удачи ребятам. 💪
➡️ Если хотите попробовать порешать задачи, на Codeforces есть архивный контест.
https://codeforces.com/contest/1912
➡️ Турнирная таблица
https://neerc.ifmo.ru/archive/2023/standings.html
➡️ Условия задач
https://neerc.ifmo.ru/archive/2023/nef-2023-statement.pdf
Во-первых всех с Новым Годом, друзья 🌲
2024 это почти 1024, а значит нас всех ждет удача в этом году 🙂
А теперь к новости
В декабре уже прошлого года прошло знаковое событие для нашего региона - финал Евразийского региона по ICPC (International Collegiate Programming Contest).
ICPC - это ежегодное соревнование по спортивному программированию среди студенческих команд. В команде участвует по три человека. Чтобы дойти до финала, нужно пройти отборочные соревнования.
Финал региона проходил в 4 городах: Санкт-Петербург, Астана, Новосибирск, Кутаиси. За 5 часов нужно было решить максимальное количество задач из 12 возможных.
🥇Первое место заняла команда из МФТИ «Yolki-palki» (Nagibin, Evteev, Mustafin), которая единственная решила все 12 задач.
🇰🇿Отдельно отмечу команду из AITU университета, которая заняла 14 место и имеет шанс отобраться на финал: jaujurek 3 bala (Biakhmet, Oralkhanov, Kamzabek). Пожелаем удачи ребятам. 💪
https://codeforces.com/contest/1912
https://neerc.ifmo.ru/archive/2023/standings.html
https://neerc.ifmo.ru/archive/2023/nef-2023-statement.pdf
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22👍5❤1🤮1
🐒Software Developer vs Software Engineer
Задавались ли вы вопросом, почему иногда пишут Software Developer, а иногда Software Engineer? В чем разница?
Software Developer - если очень просто, это программист, который специализируется на одном языке программирования или фреймворке. Поэтому чаще всего к названию приписывается название технологии: Java Developer, .NET developer. Считается, что такой специалист помимо кода, может еще и писать тесты, писать документацию, дизайнить решения. Но он ограничен рамками одного языка.
Software Engineer - это специалист, который обладает набором навыком и знаний, чтобы проектировать и создавать системы. Инженер также пишет код, можно сказать, что Software Development это подмножество Software Engineering. Но в отличии от Developer, инженер не привязывается к одному языку программирования. В зависимости от требований, он может сменить стэк. Будь водой, друг мой. 🚰
Я встретил такое описание, software engineer - это тот, кто строит ресторан и описывает меню, а software developer - это те, кто готовят блюда из этого меню.
Software Engineer обычно получает больше, чем Software Developer.
В русском языке мы не предаем такого значения этой разнице. Мы все-таки чаще используем слово «разработчик» как для developer, так и для engineer, хотя можно найти вакансии «программиста-инженера».
Если ты девелопер ставь 👾
Если ты инженер ставь 🗿
Ставь 🕊, если свободен от этих ярлыков, навешанных корпорациями
Задавались ли вы вопросом, почему иногда пишут Software Developer, а иногда Software Engineer? В чем разница?
Software Developer - если очень просто, это программист, который специализируется на одном языке программирования или фреймворке. Поэтому чаще всего к названию приписывается название технологии: Java Developer, .NET developer. Считается, что такой специалист помимо кода, может еще и писать тесты, писать документацию, дизайнить решения. Но он ограничен рамками одного языка.
Software Engineer - это специалист, который обладает набором навыком и знаний, чтобы проектировать и создавать системы. Инженер также пишет код, можно сказать, что Software Development это подмножество Software Engineering. Но в отличии от Developer, инженер не привязывается к одному языку программирования. В зависимости от требований, он может сменить стэк. Будь водой, друг мой. 🚰
Я встретил такое описание, software engineer - это тот, кто строит ресторан и описывает меню, а software developer - это те, кто готовят блюда из этого меню.
Software Engineer обычно получает больше, чем Software Developer.
В русском языке мы не предаем такого значения этой разнице. Мы все-таки чаще используем слово «разработчик» как для developer, так и для engineer, хотя можно найти вакансии «программиста-инженера».
Если ты девелопер ставь 👾
Если ты инженер ставь 🗿
Ставь 🕊, если свободен от этих ярлыков, навешанных корпорациями
🕊60👾26🗿25👍5❤2🤮2
🧚♀️Brag Document
Бывало ли такое, что за неделю до ревью начинаете вспоминать всю проделанную работу, пролистываете тикеты, просматриваете пулл реквесты, читаете чаты? Забывали ли указать что-то важное в своем self-evaluation? Расстраивались ли, когда менеджера упускали ваши достижения при оценке вашей работы?
Хочу с вами поделиться практикой, которую относительно недавно начал сам применять. Чуть позже я узнал, что ее используют много умных ребят и она называется brag document.
Brag Document, дословно переводится как «хвастающийся документ». Суть его в том, чтобы описывать свои достижения не в конце, а во время всего цикла работ. Поставил себе цель сдать сертификацию, занес запись в документ. Сделал крутую фичу, описал ее и ее результат в документе. Сделал код ревью лучше, занес как достижение в документ.
Есть пару причин, почему стоит ввести такой документ.
1️⃣ Ты не помнишь все, над чем ты работал
Пока ты в контексте, тебе легче вспомнить все нюансы и сложности, за полгода самые важные детали могут потускнеть в памяти.
2️⃣ Твой менеджер тоже не помнит всего, что ты сделал
Раз ты не можешь все запомнить, как это сделает твой менеджер? У него/нее еще пару таких как ты. Чтобы защитить твою оценку, твоему менеджеру нужна помощь.
📃Шаблон такого документа:
Цели на предстоящий год/полугодие
Проекты
• Что именно ты сделал в этом проекте?
• Какую пользу принес проект?
Взаимодействие и менторство
• Где/как/кому ты помог как эксперт разобраться с проблемой?
• Менторил ли стажеров? Помогал ли новичкам в команде?
• Какие процессы ты улучшил?
• За какие проекты ты считаешься ответственным? Какие проекты ты ревьюишь код?
• Какие важные вопросы ты помог решить?
• Был ли feature lead в команде?
• Выступал ли в компании?
Дизайн систем и документация
• Какие дизайн доки ты написал и для чего?
• Какую документацию ты написал/исправил и для чего?
Польза компании
• Тут можно описать, что полезного ты принес компании, помимо своего проекта / команды.
• Например, придумал 5 задач для собеседований
Что нового ты узнал?
• Какие навыки и знания ты приобрел недавно?
• Например, как запускать Java на калькуляторе
Вне работы
• Ведешь ли блог?
• Выступаешь ли как спикер?
• Участвуешь ли в опен-сорс проектах?
• Решаешь лучше всех leetcode?
➡️ Ссылка на статью
https://jvns.ca/blog/brag-documents/
Если честно это так просто и очевидно, что я иной раз корю себя за то, что не додумался до этого раньше. Уже веду его два месяца, посмотрим, как он покажет себя на ревью.
✔️ Сохрани себе в закладках, чтобы не потерять шаблон
Бывало ли такое, что за неделю до ревью начинаете вспоминать всю проделанную работу, пролистываете тикеты, просматриваете пулл реквесты, читаете чаты? Забывали ли указать что-то важное в своем self-evaluation? Расстраивались ли, когда менеджера упускали ваши достижения при оценке вашей работы?
Хочу с вами поделиться практикой, которую относительно недавно начал сам применять. Чуть позже я узнал, что ее используют много умных ребят и она называется brag document.
Brag Document, дословно переводится как «хвастающийся документ». Суть его в том, чтобы описывать свои достижения не в конце, а во время всего цикла работ. Поставил себе цель сдать сертификацию, занес запись в документ. Сделал крутую фичу, описал ее и ее результат в документе. Сделал код ревью лучше, занес как достижение в документ.
Есть пару причин, почему стоит ввести такой документ.
1️⃣ Ты не помнишь все, над чем ты работал
Пока ты в контексте, тебе легче вспомнить все нюансы и сложности, за полгода самые важные детали могут потускнеть в памяти.
2️⃣ Твой менеджер тоже не помнит всего, что ты сделал
Раз ты не можешь все запомнить, как это сделает твой менеджер? У него/нее еще пару таких как ты. Чтобы защитить твою оценку, твоему менеджеру нужна помощь.
📃Шаблон такого документа:
Цели на предстоящий год/полугодие
Проекты
• Что именно ты сделал в этом проекте?
• Какую пользу принес проект?
Взаимодействие и менторство
• Где/как/кому ты помог как эксперт разобраться с проблемой?
• Менторил ли стажеров? Помогал ли новичкам в команде?
• Какие процессы ты улучшил?
• За какие проекты ты считаешься ответственным? Какие проекты ты ревьюишь код?
• Какие важные вопросы ты помог решить?
• Был ли feature lead в команде?
• Выступал ли в компании?
Дизайн систем и документация
• Какие дизайн доки ты написал и для чего?
• Какую документацию ты написал/исправил и для чего?
Польза компании
• Тут можно описать, что полезного ты принес компании, помимо своего проекта / команды.
• Например, придумал 5 задач для собеседований
Что нового ты узнал?
• Какие навыки и знания ты приобрел недавно?
• Например, как запускать Java на калькуляторе
Вне работы
• Ведешь ли блог?
• Выступаешь ли как спикер?
• Участвуешь ли в опен-сорс проектах?
• Решаешь лучше всех leetcode?
https://jvns.ca/blog/brag-documents/
Если честно это так просто и очевидно, что я иной раз корю себя за то, что не додумался до этого раньше. Уже веду его два месяца, посмотрим, как он покажет себя на ревью.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25❤4🔥3
🙋Как заработать 300К тенге за один день?
Хотите забустить свою подготовку к алоритмическим собеседованиям? Получить выброс андреналина, пытаясь дописать решение за минуту до конца? Познакомиться с такими же интересными людьми как и вы? 🙂
Студенческое отделение Назарбаевского университета NU ACM организовывает NU OPEN 2023! 🏆.
Это соревнование направлено на поддержку молодых людей, интересующихся программированием, технологиями и решением алгоритмических задач. Одной из целью данного соревнования также является поддержка школьников и девушек в IT.
Формат контеста:
• 3 человека в команде
• Длительность 5 часов
• Задачки по алгоритмам и структурам данных
Есть два режима:
• онлайн - участвовать может кто угодно, откуда угодно
• оффлайн - можно получить призы. Пройдет в стенах Назарбаевского университета. Вам должно быть не менее 16 лет, и в настоящее время вы должны учиться в школе или на бакалавриате
📅 Крайний срок регистрации: 17 января, 23:59
🏎️Дата проведения NU OPEN: 20 января
🏆 🌟 Призовой фонд:
🥇 1-е место: 300 000 тенге + Мерч
🥈 2-е место: 100 000 тенге + Мерч
🥈 2-е место: 100 000 тенге + Мерч
🥉 3-е место: Эксклюзивный Мерч
🥉 3-е место: Эксклюзивный Мерч
UPD: Форма регистрации https://docs.google.com/forms/d/e/1FAIpQLSfG-gR2bCq64YoW2pa8UJnMWwCsWUeYMeIPxUFVMtaibzSaIA/viewform
━━━━━━━
🦆 Теперь вопрос. Если у вас есть онлайн команда и не будет хватать одного человека, дайте мне знать. Присоединюсь и попробую порешать с вами. 🙂
Хотите забустить свою подготовку к алоритмическим собеседованиям? Получить выброс андреналина, пытаясь дописать решение за минуту до конца? Познакомиться с такими же интересными людьми как и вы? 🙂
Студенческое отделение Назарбаевского университета NU ACM организовывает NU OPEN 2023! 🏆.
Это соревнование направлено на поддержку молодых людей, интересующихся программированием, технологиями и решением алгоритмических задач. Одной из целью данного соревнования также является поддержка школьников и девушек в IT.
Формат контеста:
• 3 человека в команде
• Длительность 5 часов
• Задачки по алгоритмам и структурам данных
Есть два режима:
• онлайн - участвовать может кто угодно, откуда угодно
• оффлайн - можно получить призы. Пройдет в стенах Назарбаевского университета. Вам должно быть не менее 16 лет, и в настоящее время вы должны учиться в школе или на бакалавриате
📅 Крайний срок регистрации: 17 января, 23:59
🏎️Дата проведения NU OPEN: 20 января
🏆 🌟 Призовой фонд:
🥇 1-е место: 300 000 тенге + Мерч
🥈 2-е место: 100 000 тенге + Мерч
🥈 2-е место: 100 000 тенге + Мерч
🥉 3-е место: Эксклюзивный Мерч
🥉 3-е место: Эксклюзивный Мерч
UPD: Форма регистрации https://docs.google.com/forms/d/e/1FAIpQLSfG-gR2bCq64YoW2pa8UJnMWwCsWUeYMeIPxUFVMtaibzSaIA/viewform
━━━━━━━
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍5
🙅♀️Ошибки в английском
Недавно на работе мой коллега намекнул, что мне стоит использовать какой-нибудь инструмент, чтобы выявлять грамматические ошибки при написании документов на английском языке.
Вначале это меня задело. Я подумал да какая разница какие есть ошибки, если суть все равно понятна. Ведь важна не форма, а содержание. Ну забыл пару артиклей, поставил пару неправильных окончаний, подумаешь.
Потом до меня дошло. Я на протяжении всей свой жизни подвергал сомнению компетенции людей, которые не могли правильно донести свои мысли. А теперь сам же попал в эту же ловушку.
Ведь если я буду читать важный документ и буду видеть грамматические ошибки, то мой фокус автоматически переключится на них. Вполне вероятно, что я или упущу суть документа или просто не захочу дочитывать этот документ до конца. В редких случаях я даже могу возмутится, что так коверкают язык.
То есть, когда я пишу с ошибками, я таким образом неосознанно компроментирую свой текст и подрываю свой авторитет.
В общем установил Grammarly и теперь вроде как все стало лучше.
Поэтому инсайт, грамматика важна для коммуникации, а значит и для карьерного роста.
⁉️ Бывали ли у вас похожие ситуации?
Недавно на работе мой коллега намекнул, что мне стоит использовать какой-нибудь инструмент, чтобы выявлять грамматические ошибки при написании документов на английском языке.
Вначале это меня задело. Я подумал да какая разница какие есть ошибки, если суть все равно понятна. Ведь важна не форма, а содержание. Ну забыл пару артиклей, поставил пару неправильных окончаний, подумаешь.
Потом до меня дошло. Я на протяжении всей свой жизни подвергал сомнению компетенции людей, которые не могли правильно донести свои мысли. А теперь сам же попал в эту же ловушку.
Ведь если я буду читать важный документ и буду видеть грамматические ошибки, то мой фокус автоматически переключится на них. Вполне вероятно, что я или упущу суть документа или просто не захочу дочитывать этот документ до конца. В редких случаях я даже могу возмутится, что так коверкают язык.
То есть, когда я пишу с ошибками, я таким образом неосознанно компроментирую свой текст и подрываю свой авторитет.
В общем установил Grammarly и теперь вроде как все стало лучше.
Поэтому инсайт, грамматика важна для коммуникации, а значит и для карьерного роста.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤24👍11💯2😁1
👨🦳За выслугу лет
Нам всегда говорят, что на рост влияют два типа скиллов - софт скиллы и хард скиллы. Недавно услышал об их третьем сводном брате, навык контекста компании.
Допустим есть два идентичных разработчика, что по софт-скиллам, что по хард-скиллам. Они устраиваются в одну компанию, но первый на полгода раньше, чем второй.
За эти полгода первый разработчик знакомится с людьми, изучает свой проект, спрашивает с лида за костыли. Первый инженер зарабатывает кредит доверия и набирается знаний, как следствие, у первого разработчика больше возможностей сделать значимый вклад, чем у второго. Вполне вероятно, что оценка на ревью у первого будет выше, чем у второго. Звучит логично, верно?
В отличии от софт и хард скиллов, навык контекста компании нарабатывается временем. Как раз-таки этот третий навык и помогает проявлять в полной мере мягкие и жесткие навыки, как выключатель из Alan Wake. А еще при переходе в новую компанию этот навык полностью обнуляется и нужно начинать с самого начала.
Наверняка у вас, как и у меня, на работе был коллега, который в принципе не сильно превосходит вас по способностям, а иногда даже и уступает. Но почему-то к этому коллеге всегда приходят с вопросами, коллегу просят прочитать дизайн документы, постоянно прислушиваются к нему, даже как он/она говорят довольно тривиальные вещи. А все потому, что коллега уже давно в компании, участвовал в принятии важных решений и много раз вытаскивал прод из того света. И ему доступны больше возможностей, чем вам.
✔️ Поэтому если вам кажется, что вы никак не растете в компании, это ошибка. Как минимум вы обрастаете связями, авторитетом, контекстом и желанием свалить оттуда.
Нам всегда говорят, что на рост влияют два типа скиллов - софт скиллы и хард скиллы. Недавно услышал об их третьем сводном брате, навык контекста компании.
Допустим есть два идентичных разработчика, что по софт-скиллам, что по хард-скиллам. Они устраиваются в одну компанию, но первый на полгода раньше, чем второй.
За эти полгода первый разработчик знакомится с людьми, изучает свой проект, спрашивает с лида за костыли. Первый инженер зарабатывает кредит доверия и набирается знаний, как следствие, у первого разработчика больше возможностей сделать значимый вклад, чем у второго. Вполне вероятно, что оценка на ревью у первого будет выше, чем у второго. Звучит логично, верно?
В отличии от софт и хард скиллов, навык контекста компании нарабатывается временем. Как раз-таки этот третий навык и помогает проявлять в полной мере мягкие и жесткие навыки, как выключатель из Alan Wake. А еще при переходе в новую компанию этот навык полностью обнуляется и нужно начинать с самого начала.
Наверняка у вас, как и у меня, на работе был коллега, который в принципе не сильно превосходит вас по способностям, а иногда даже и уступает. Но почему-то к этому коллеге всегда приходят с вопросами, коллегу просят прочитать дизайн документы, постоянно прислушиваются к нему, даже как он/она говорят довольно тривиальные вещи. А все потому, что коллега уже давно в компании, участвовал в принятии важных решений и много раз вытаскивал прод из того света. И ему доступны больше возможностей, чем вам.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍31😁11❤1🤔1
🧧Письма счастья 2024
Я знаю, что вы не любите плохие новости. Но я скажу то, что для тебя не новость: мир не такой уж солнечный и приветливый. Это очень опасное, жесткое место, и если только дашь слабину, он опрокинет с такой силой тебя, что больше уже не встанешь.
• Twitch увольняет 500 сотрудников
https://themessenger.com/tech/twitch-layoffs-amazon-cuts-jobs-livestreaming
• Amazon увольняет несколько сотен
https://www.cnbc.com/2024/01/10/amazon-layoffs-hundreds-of-jobs-cut-in-prime-video-and-mgm-studios.html
• Google сокращает тысячу человек
https://www.theverge.com/2024/1/11/24034124/google-layoffs-engineering-assistant-hardware
• Meta уволила 60 менеджеров в Инстаграм
https://www.engadget.com/meta-reportedly-laid-off-60-technical-program-managers-at-instagram-095558424.htm
• Discord увольняет 170 человек
https://www.theverge.com/2024/1/11/24034705/discord-layoffs-17-percent-employees
Неприятно слышать это в новом году. Хотелось верить, что мой новогодний тост помог и все плохое осталось в прошлом году, но нет.
Знаете, чего я не понимаю. Что даже если компания практикует массовые увольнения, у нее всегда есть открытые вакансии и всегда есть те, кто проходят собеседования.
Как-будто компании легче уволить пачку людей и нанять с рынка новых на другие проекты, нежели постараться внутри перевести сотрудников в другие команды. Возможно, я чего-то не понимаю.
🤔Что делать дальше?
А что тут поделаешь? Пока остальные отчаиваются и заедают грусть остатками салатов, можно расти как разработчик, периодически собеседоваться и находить кайф в сложных литкодовских задачах.
Рынок наладится, появятся новые BigTech компании, умные и мотивированные всегда будут нужны.
Увольнения временны, а лайк под этим постом вечен ☝️
Я знаю, что вы не любите плохие новости. Но я скажу то, что для тебя не новость: мир не такой уж солнечный и приветливый. Это очень опасное, жесткое место, и если только дашь слабину, он опрокинет с такой силой тебя, что больше уже не встанешь.
• Twitch увольняет 500 сотрудников
https://themessenger.com/tech/twitch-layoffs-amazon-cuts-jobs-livestreaming
• Amazon увольняет несколько сотен
https://www.cnbc.com/2024/01/10/amazon-layoffs-hundreds-of-jobs-cut-in-prime-video-and-mgm-studios.html
• Google сокращает тысячу человек
https://www.theverge.com/2024/1/11/24034124/google-layoffs-engineering-assistant-hardware
• Meta уволила 60 менеджеров в Инстаграм
https://www.engadget.com/meta-reportedly-laid-off-60-technical-program-managers-at-instagram-095558424.htm
• Discord увольняет 170 человек
https://www.theverge.com/2024/1/11/24034705/discord-layoffs-17-percent-employees
Неприятно слышать это в новом году. Хотелось верить, что мой новогодний тост помог и все плохое осталось в прошлом году, но нет.
Знаете, чего я не понимаю. Что даже если компания практикует массовые увольнения, у нее всегда есть открытые вакансии и всегда есть те, кто проходят собеседования.
Как-будто компании легче уволить пачку людей и нанять с рынка новых на другие проекты, нежели постараться внутри перевести сотрудников в другие команды. Возможно, я чего-то не понимаю.
🤔Что делать дальше?
А что тут поделаешь? Пока остальные отчаиваются и заедают грусть остатками салатов, можно расти как разработчик, периодически собеседоваться и находить кайф в сложных литкодовских задачах.
Рынок наладится, появятся новые BigTech компании, умные и мотивированные всегда будут нужны.
Увольнения временны, а лайк под этим постом вечен ☝️
💯38👍15❤7😭4🔥3😁1🤮1
В жизни многих разработчиков бывали ситуации, когда в офере была хорошая зарплата, но занижали позицию, например сеньору предлагали уровень мидла.
В целом понижение позиции - это не есть плохо. При переходе из маленькой компании в BigTech такое понижение даже ожидаемо. У меня такое было при переходе в Яндекс.
Почему так происходит?
1. У разных компаний, разные ожидания от титулов и соответственно разные зарплатные вилки. Senior в Amazon и Senior в стартапе это не одно и то же.
2. Разные компании по разному платят сотрудникам, кто-то больше акциями, кто-то больше зарплатой, кто-то больше бонусами. К примеру OpenAi очень щедр на акции, в то время как у Netflix высокая базовая зарплата.
3. Компенсации в целом быстро растут. Исследования показывают, что при переходе из компании в компанию, по деньгам растешь чуть быстрее, чем если долго сидеть на одном месте. Как следствие, ребята которые годами в одной компании, могут получить офер ниже по грейду, но выше их текущей зарплаты.
4. Разный стэк технологий. Иногда компании могут предложить офер пониже, если кандидат не очень знаком с определенной технологией.
5. Наше любимое - интервью. Если не очень хорошо себя показать на собеседовании - вполне вероятно, что предложат позицию на ступень ниже.
Как избежать понижения грейда?
1. Иметь конкурирующие оферы. Когда у кандидата есть предложение от другой компании с позицией повыше, найм-менеджера могу постараться пересмотреть фидбек и предложить условия получше.
2. Поизучать компанию и позиции. Может быть так, что Middle в новой компании выполняет примерно то же самое, что и Senior в текущей.
3. Пообщаться с нанимающим менеджером, если не согласны с уровнем. Иногда менеджер может пройтись по отзывам с интервью и увидеть, что в принципе человек подходит под позицию выше.
Важен ли вообще уровень?
Многие говорят, что уровень ничего не значит, важнее деньги. Но так говорят обычно те, кого устраивает их титул в компании.
Уровень важен, так как он все-таки показывает социальный статус в компании, авторитет, опыт, уважение.
https://blog.pragmaticengineer.com/the-seniority-roller-coaster/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15❤2🔥2🤮1
Важно ли для вас, чтобы везде к вашей должности приписывали титул Middle/Senior/Staff/etc?
Если будет время, поделитесь в комментариях своими мыслями
Если будет время, поделитесь в комментариях своими мыслями
Anonymous Poll
33%
Да
51%
Нет
15%
it depends (напишу в комментах)
❤1
👩🚀Советы после 15 лет в IT
Статья от Ryan O’Neill, который за 15 лет успел поработать как в маленьких стартапах, так и в FAANGовских компаниях. Ryan делится советами, которые он открыл для себя за это время.
• Не уходите в крайности
У каждого правила есть исключения, у каждого архитектурного решения есть трейдофы.
• Умение отлаживать сильно недооценено
Всегда продумывайте, если будет ошибка на проде, как будете ее дебажить. Оставляйте логи, трейсы, метрики.
• Проекты опаздывают, частенько
Разработка всегда непредсказуема, могут возникнуть причины, когда не получится сделать фичу в срок. Старайтесь всегда держать в курсе своих стейкхолдеров, если сдвигаются сроки или есть блокеры.
• Проактивно управляйте своим объемом задач
Люди всегда будут хотеть докинуть новых задач к проекту, нужно уметь защищаться. Необязательно сразу говорить «нет», лучше сказать, что тогда сроки изменятся.
• Staging почти всегда сломан
Тестовые среды никогда не будут точной копией прода. Старайтесь проверить свой фунцкионал до прода, но не бойтесь тестировать на проде. Не забывайте использовать feature flags.
• Действия вознаграждаются
В то же время, просто говорить про проблему или постоянно жаловаться - нет.
• Берите на себя ответственность за свои проекты
Это не только про код. Введите себя так, как будто вы лично ответственны за успех проекта.
• Вы часть огромной организации
Разработка это не центр вселенной. Помимо вас в компании много сотрудников, которые также работают над успехом проекта. Знакомьтесь с людьми из разных департаментов (юристы, маркетологи, финансисты). Это даст более широкое понимание бизнеса и вы будете лучше понимать разные управленческие решения.
• Задавайте тупые вопросы
Наверняка у человека рядом такой же вопрос в голове. Задавайте вопросы, раскрывайте контекст задачи. Никто не запомнит сам вопрос, но все запомнят ответ.
• Вы не вернетесь к техдолгу
Не обманывайте себя. Старайтесь сразу сделать все правильно и свести к минимуму техдолг. Вы не вернетесь к этому долгу, если только он он не потребует капитального рефакторинга.
• Наслаждайтесь
Иногда даже не верится, что кто-то платит высокую зарплату за, что и так нравится делать - писать код. Это весело 🙂
➡️ Ссылка на оригинальную статью
https://roughlywritten.substack.com/p/random-thoughts-15-years-into-software
━━━━━━
Мне особенно понравилось про техдолг. Я так верю, что когда-нибудь, когда закрою все срочные задачи, у меня будет достаточно времени, чтобы порефакторить все TODO.
Ставь 🦄, если тоже веришь, что рано или поздно закроешь весь бэклог по техдолгу.
Статья от Ryan O’Neill, который за 15 лет успел поработать как в маленьких стартапах, так и в FAANGовских компаниях. Ryan делится советами, которые он открыл для себя за это время.
• Не уходите в крайности
У каждого правила есть исключения, у каждого архитектурного решения есть трейдофы.
• Умение отлаживать сильно недооценено
Всегда продумывайте, если будет ошибка на проде, как будете ее дебажить. Оставляйте логи, трейсы, метрики.
• Проекты опаздывают, частенько
Разработка всегда непредсказуема, могут возникнуть причины, когда не получится сделать фичу в срок. Старайтесь всегда держать в курсе своих стейкхолдеров, если сдвигаются сроки или есть блокеры.
• Проактивно управляйте своим объемом задач
Люди всегда будут хотеть докинуть новых задач к проекту, нужно уметь защищаться. Необязательно сразу говорить «нет», лучше сказать, что тогда сроки изменятся.
• Staging почти всегда сломан
Тестовые среды никогда не будут точной копией прода. Старайтесь проверить свой фунцкионал до прода, но не бойтесь тестировать на проде. Не забывайте использовать feature flags.
• Действия вознаграждаются
В то же время, просто говорить про проблему или постоянно жаловаться - нет.
• Берите на себя ответственность за свои проекты
Это не только про код. Введите себя так, как будто вы лично ответственны за успех проекта.
• Вы часть огромной организации
Разработка это не центр вселенной. Помимо вас в компании много сотрудников, которые также работают над успехом проекта. Знакомьтесь с людьми из разных департаментов (юристы, маркетологи, финансисты). Это даст более широкое понимание бизнеса и вы будете лучше понимать разные управленческие решения.
• Задавайте тупые вопросы
Наверняка у человека рядом такой же вопрос в голове. Задавайте вопросы, раскрывайте контекст задачи. Никто не запомнит сам вопрос, но все запомнят ответ.
• Вы не вернетесь к техдолгу
Не обманывайте себя. Старайтесь сразу сделать все правильно и свести к минимуму техдолг. Вы не вернетесь к этому долгу, если только он он не потребует капитального рефакторинга.
• Наслаждайтесь
Иногда даже не верится, что кто-то платит высокую зарплату за, что и так нравится делать - писать код. Это весело 🙂
https://roughlywritten.substack.com/p/random-thoughts-15-years-into-software
━━━━━━
Мне особенно понравилось про техдолг. Я так верю, что когда-нибудь, когда закрою все срочные задачи, у меня будет достаточно времени, чтобы порефакторить все TODO.
Ставь 🦄, если тоже веришь, что рано или поздно закроешь весь бэклог по техдолгу.
Please open Telegram to view this post
VIEW IN TELEGRAM
🦄32👍6❤5🔥3
🗿Подсказки по System Design
Вопросы по System Design бывают сложные и порой непросто выявить и устранить узкие горлышки системы. Но практически для любой проблемы, есть общепринятые подходы для ее решения.
Инженер Google Dinesh Varyani пишет классные посты по тематике собеседований в MAANG. Один из недавних постов про System Design, ссылка в конце поста. Привожу список советов из требований к системе и как их можно решить.
1. For a Read-Heavy System - Consider using a Cache.
2. For a Write-Heavy System - Use Message Queues for async processing
3. For a Low Latency Requirement - Consider using a Cache and CDN.
4. Need 𝐀tomicity, 𝐂onsistency, 𝐈solation, 𝐃urability Compliant DB - Go for RDBMS/SQL Database.
5. Have unstructured data - Go for NoSQL Database.
6. Have Complex Data (Videos, Images, Files) - Go for Blob/Object storage.
7. Complex Pre-computation - Use Message Queue & Cache.
8. High-Volume Data Search - Consider search index, tries or search engine.
9. Scaling SQL Database - Implement Database Sharding.
10. High Availability, Performance, & Throughput - Use a Load Balancer.
11. Global Data Delivery - Consider using a CDN.
12. Graph Data (data with nodes, edges, and relationships) - Utilize Graph Database.
13. Scaling Various Components - Implement Horizontal Scaling.
14. High-Performing Database Queries - Use Database Indexes.
15. Bulk Job Processing - Consider Batch Processing & Message Queues.
16. Server Load Management & Preventing DOS Attacks- Use a Rate Limiter.
17. Microservices Architecture - Use an API Gateway.
18. For Single Point of Failure - Implement Redundancy.
19. For Fault-Tolerance and Durability - Implement Data Replication.
20. For User-to-User fast communication - Use Websockets.
21. Failure Detection in Distributed Systems - Implement a Heartbeat.
22. Data Integrity - Use Checksum Algorithm.
23. Efficient Server Scaling - Implement Consistent Hashing.
24. Decentralized Data Transfer - Consider Gossip Protocol.
25. Location-Based Functionality - Use Quadtree, Geohash, etc.
26. Avoid Specific Technology Names - Use generic terms.
27. High Availability and Consistency Trade-Off - Eventual Consistency.
28. For IP resolution & Domain Name Query - Mention DNS.
29. Handling Large Data in Network Requests - Implement Pagination.
30. Cache Eviction Policy - Preferred is LRU (Least Recently Used) Cache.
31. To handle traffic spikes: Implement Autoscaling to manage resources dynamically
32. Need analytics and audit trails - Consider using data lakes or append-only databases
33. Handling Large-Scale Simultaneous Connections - Use Connection Pooling and consider using Protobuf to minimize data payload
➡️ Ссылка на оригинальный пост
https://www.linkedin.com/posts/dinesh-varyani_system-design-golden-rules-activity-7153594539398594560-w6PQ
✔️ Сохраните шпаргалку себе на будущее
Вопросы по System Design бывают сложные и порой непросто выявить и устранить узкие горлышки системы. Но практически для любой проблемы, есть общепринятые подходы для ее решения.
Инженер Google Dinesh Varyani пишет классные посты по тематике собеседований в MAANG. Один из недавних постов про System Design, ссылка в конце поста. Привожу список советов из требований к системе и как их можно решить.
1. For a Read-Heavy System - Consider using a Cache.
2. For a Write-Heavy System - Use Message Queues for async processing
3. For a Low Latency Requirement - Consider using a Cache and CDN.
4. Need 𝐀tomicity, 𝐂onsistency, 𝐈solation, 𝐃urability Compliant DB - Go for RDBMS/SQL Database.
5. Have unstructured data - Go for NoSQL Database.
6. Have Complex Data (Videos, Images, Files) - Go for Blob/Object storage.
7. Complex Pre-computation - Use Message Queue & Cache.
8. High-Volume Data Search - Consider search index, tries or search engine.
9. Scaling SQL Database - Implement Database Sharding.
10. High Availability, Performance, & Throughput - Use a Load Balancer.
11. Global Data Delivery - Consider using a CDN.
12. Graph Data (data with nodes, edges, and relationships) - Utilize Graph Database.
13. Scaling Various Components - Implement Horizontal Scaling.
14. High-Performing Database Queries - Use Database Indexes.
15. Bulk Job Processing - Consider Batch Processing & Message Queues.
16. Server Load Management & Preventing DOS Attacks- Use a Rate Limiter.
17. Microservices Architecture - Use an API Gateway.
18. For Single Point of Failure - Implement Redundancy.
19. For Fault-Tolerance and Durability - Implement Data Replication.
20. For User-to-User fast communication - Use Websockets.
21. Failure Detection in Distributed Systems - Implement a Heartbeat.
22. Data Integrity - Use Checksum Algorithm.
23. Efficient Server Scaling - Implement Consistent Hashing.
24. Decentralized Data Transfer - Consider Gossip Protocol.
25. Location-Based Functionality - Use Quadtree, Geohash, etc.
26. Avoid Specific Technology Names - Use generic terms.
27. High Availability and Consistency Trade-Off - Eventual Consistency.
28. For IP resolution & Domain Name Query - Mention DNS.
29. Handling Large Data in Network Requests - Implement Pagination.
30. Cache Eviction Policy - Preferred is LRU (Least Recently Used) Cache.
31. To handle traffic spikes: Implement Autoscaling to manage resources dynamically
32. Need analytics and audit trails - Consider using data lakes or append-only databases
33. Handling Large-Scale Simultaneous Connections - Use Connection Pooling and consider using Protobuf to minimize data payload
https://www.linkedin.com/posts/dinesh-varyani_system-design-golden-rules-activity-7153594539398594560-w6PQ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26👍5🥱1
🧗♀️От хорошего к великому
Удобные работники и амбициозные управленцы. Или как в погоне за слабостями, не упустить свои сильные стороны.
Просто упростим по максимуму и представим две категории сотрудников: работники и управленцы.
Так вот, как-то давно услышал такую мысль: управленцы прокачивают свои сильные стороны, а работники устраняют свои слабости. Порассуждаем об этом в контексте разработчиков и менеджеров.
🧑💻Работники закрывают слабости.
От работников ожидают, что у них есть все базовые навыки, чтобы эффективно выполнять свою работу. Поэтому если какой-то скилл проседает, то его стараются подтянуть. Если представить компетенции, как спицы колеса, то у специалиста должен получится более менее сбалансированный круг.
Я думаю, это применимо и для разработчиков. Чтобы вырасти от стажера до синьора, в первую очередь нужно работать над своими пробелами в хард скиллах, коммуникациях, работе в команде. Если человек пишет классный код, но токсичит в команде, скорее всего ему будут помогать устранить именно токсичность.
Индивидуальные сильные качества влияют конечно, но если не закрывать слобости, то расти будет сложнее.
👩🏫Управленцы прокачивают сильные стороны.
Попробую пояснить и этот тейк. У управленцев есть качества, которые позволили ему стать управленцем, определенные индивидуальные навыки человека привели его к этой позиции. Поощряя и улучшая сильные стороны, человек растет.
Например если человек умеет отлично договариваться, но не очень делает презентации. То лучше поставить его ответственным за договора, чем пытаться воспитать в нем спикера. Пользы будет больше.
В разработке мне кажется это применимо и для разработчиков, выше чем синьор, и для тех/тим лидов, и для менеджеров.
Я нахожу подтверждения этой мысли в книге «Staff Engineer» от Will Larson. Там он приводит архетипы стафф разработчиков: кто-то умеет организовывать работу и управлять командой, кто-то умеет правильно планировать архитектуру и предвидеть множество потенциальных проблем, а кто-то очень хорош в решении срочных/важных проблем.
То есть, даже по карьерной лестнице individual contributor мы рано или поздно упремся в потолок. И чтобы его преодолеть, придется сосредоточиться на своих сильных сторонах.
🤔Как узнать свои сильные и слабые качества?
Круто, если с вами есть человек, который готов дать честный и конструктивный фидбек. А возможно вы человек, который умеет рефлексировать и самостоятельно оценивать свои сильные и слабые стороны.
Для всех остальных:
• Есть бесплатный тест 16 Personalities
https://www.16personalities.com/
• Есть платный тест от Gallup
https://www.gallup.com/cliftonstrengths/en/252137/home.aspx
✔️ Мораль. Вы важны, ваши личные качества важны, не теряйте свою уникальность, развивайте свои сильные качества.
Удобные работники и амбициозные управленцы. Или как в погоне за слабостями, не упустить свои сильные стороны.
Просто упростим по максимуму и представим две категории сотрудников: работники и управленцы.
Так вот, как-то давно услышал такую мысль: управленцы прокачивают свои сильные стороны, а работники устраняют свои слабости. Порассуждаем об этом в контексте разработчиков и менеджеров.
🧑💻Работники закрывают слабости.
От работников ожидают, что у них есть все базовые навыки, чтобы эффективно выполнять свою работу. Поэтому если какой-то скилл проседает, то его стараются подтянуть. Если представить компетенции, как спицы колеса, то у специалиста должен получится более менее сбалансированный круг.
Я думаю, это применимо и для разработчиков. Чтобы вырасти от стажера до синьора, в первую очередь нужно работать над своими пробелами в хард скиллах, коммуникациях, работе в команде. Если человек пишет классный код, но токсичит в команде, скорее всего ему будут помогать устранить именно токсичность.
Индивидуальные сильные качества влияют конечно, но если не закрывать слобости, то расти будет сложнее.
👩🏫Управленцы прокачивают сильные стороны.
Попробую пояснить и этот тейк. У управленцев есть качества, которые позволили ему стать управленцем, определенные индивидуальные навыки человека привели его к этой позиции. Поощряя и улучшая сильные стороны, человек растет.
Например если человек умеет отлично договариваться, но не очень делает презентации. То лучше поставить его ответственным за договора, чем пытаться воспитать в нем спикера. Пользы будет больше.
В разработке мне кажется это применимо и для разработчиков, выше чем синьор, и для тех/тим лидов, и для менеджеров.
Я нахожу подтверждения этой мысли в книге «Staff Engineer» от Will Larson. Там он приводит архетипы стафф разработчиков: кто-то умеет организовывать работу и управлять командой, кто-то умеет правильно планировать архитектуру и предвидеть множество потенциальных проблем, а кто-то очень хорош в решении срочных/важных проблем.
То есть, даже по карьерной лестнице individual contributor мы рано или поздно упремся в потолок. И чтобы его преодолеть, придется сосредоточиться на своих сильных сторонах.
🤔Как узнать свои сильные и слабые качества?
Круто, если с вами есть человек, который готов дать честный и конструктивный фидбек. А возможно вы человек, который умеет рефлексировать и самостоятельно оценивать свои сильные и слабые стороны.
Для всех остальных:
• Есть бесплатный тест 16 Personalities
https://www.16personalities.com/
• Есть платный тест от Gallup
https://www.gallup.com/cliftonstrengths/en/252137/home.aspx
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍3❤2
👩💼Три совета от топ менеджера ex-Facebook, ex-Stripe
В 2015 году Raylene Yung была самым молодым инженерным директором в Фейбуке. Позже она присоединилась к Stripe, где сформировала команду по управлению продуктами, определила процессы карьерного роста и подбора персонала, руководила основным платежным направлением и запустила глобальный инженерный центр компании в Сингапуре.
В статье «The Engineer’s Guide to Career Growth — Advice from My Time at Stripe and Facebook» Yung дает много дельных советов, но я приведу лишь ее советы по карьерному росту для разработчиков.
• Стремитесь быть самым ценным, но наименее критичным.
Иногда бывает, что проект полностью завязан на вас, вы играете решающую роль будет ли проект существовать или провалится. Вы становитесь потенциальным узким горлышком, единственной точкой отказа. Это не есть хорошо.
Лучше инженеры и менеджеры стараются быть ценными, добавляя свой опыт и знания в проект, эффективно общаясь с коллегами и помогая команде решать проблемы.
• Хотите добиться успеха в качестве менеджера? Стремитесь к эмоциональному равновесию.
Со стороны разработчика, работа под проектом это как взбираться на холм. Иногда все получается и можно забраться быстро и высоко, а иногда проект закрывается и нужно опять начинать сначала. В любом случае, есть связь «эффективная работа» -> «прогресс проекта».
Но у менеджеров все работает по другому. Можно очень сильно стараться и увидеть плоды своих работ только через год. Задачки менеджера отличаются от задач инженера, работа с людьми подразумевает множество решений и нет одного правильно. Поэтому очень легко уйти в эмоциональный минус.
• Не старайтесь просто карабкаться по карьерной лестнице, изучайте максимум на каждом шагу.
Многие компании предлагают два выбора: или расти как инженер (IC) или развиваться как менеджер. Но на самом деле карьера инженера не является линейной, люди могут переключаться между ролями на протяжении всей своей карьеры.
Поэтому не переключайтесь бездумно между ролями или не стоит полностью отказываться от параллельного пути.
Сосредоточьтесь на обучении и не беспокойтесь о направлениях и карьерных лестницах.
➡️ Ссылка на статью
https://review.firstround.com/the-engineers-guide-to-career-growth-advice-from-my-time-at-stripe-and-facebook
В 2015 году Raylene Yung была самым молодым инженерным директором в Фейбуке. Позже она присоединилась к Stripe, где сформировала команду по управлению продуктами, определила процессы карьерного роста и подбора персонала, руководила основным платежным направлением и запустила глобальный инженерный центр компании в Сингапуре.
В статье «The Engineer’s Guide to Career Growth — Advice from My Time at Stripe and Facebook» Yung дает много дельных советов, но я приведу лишь ее советы по карьерному росту для разработчиков.
• Стремитесь быть самым ценным, но наименее критичным.
Иногда бывает, что проект полностью завязан на вас, вы играете решающую роль будет ли проект существовать или провалится. Вы становитесь потенциальным узким горлышком, единственной точкой отказа. Это не есть хорошо.
Лучше инженеры и менеджеры стараются быть ценными, добавляя свой опыт и знания в проект, эффективно общаясь с коллегами и помогая команде решать проблемы.
• Хотите добиться успеха в качестве менеджера? Стремитесь к эмоциональному равновесию.
Со стороны разработчика, работа под проектом это как взбираться на холм. Иногда все получается и можно забраться быстро и высоко, а иногда проект закрывается и нужно опять начинать сначала. В любом случае, есть связь «эффективная работа» -> «прогресс проекта».
Но у менеджеров все работает по другому. Можно очень сильно стараться и увидеть плоды своих работ только через год. Задачки менеджера отличаются от задач инженера, работа с людьми подразумевает множество решений и нет одного правильно. Поэтому очень легко уйти в эмоциональный минус.
• Не старайтесь просто карабкаться по карьерной лестнице, изучайте максимум на каждом шагу.
Многие компании предлагают два выбора: или расти как инженер (IC) или развиваться как менеджер. Но на самом деле карьера инженера не является линейной, люди могут переключаться между ролями на протяжении всей своей карьеры.
Поэтому не переключайтесь бездумно между ролями или не стоит полностью отказываться от параллельного пути.
Сосредоточьтесь на обучении и не беспокойтесь о направлениях и карьерных лестницах.
https://review.firstround.com/the-engineers-guide-to-career-growth-advice-from-my-time-at-stripe-and-facebook
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤3🔥1