Какие AWS сервисы мы часто использовали, когда я работал в Amazon?
1) Dynamo DB - NoSQL база. Часто использовали ее как key-value storage. Время доступа к значению по ключу составляет несколько миллисекунд, при этом позволяет хранить большие объемы данных по сравнению с in-memory cache.
2) SQS - распределенная очередь. Подходит для асинхронной bulk обработки данных. Позволяет реализовать простейший back pressure механизм между двумя компонентами и сгладить пики производства данных producer и не перегрузить этими пиками consumer.
3) Amazon Redshift - Data Warehouse. Позволяет хранить и обрабатывать колоссальные объемы данных (Big Data). Позволяет делать анализ больших объемов данных, ETL и т.д.
4) RDS - распределенная SQL/реляционная база данных.
5) SNS - pub-sub сервис. Можно создавать топики и подписываться на них. Имеет куча интеграций, в том числе можно делать SMS и e-mail нотификации.
6) S3 - blob storage. Позволяет сохранять данные в виде файлов, и получать к ним доступ. Netflix использует S3 для хранения видео. Часто используется для хранения другой медиа информации, видео, картинки, аудио. Часто используется для хранения файлов и промежуточных выгрузок больших объемов данных для дальнейшей обработки.
7) SageMaker - позволяет создавать, обучать и деплоить в продакшен модели машинного обучения (ML).
8) Cloudwatch - позволяет мониторить ваш сервис в продакшене. Создавать и мониторить метрики, создавать дашборды и алармы и т.д.
9) EC2 - Самый частый сервис используемый в AWS. Позволяет вам арендовать сервера и деплоить на них ваши приложения. Позволяет делать auto-scaling в зависимости от нагрузки. Мы использовали не часто, т.к. тогда только шла миграция на EC2. Чаще использовали внутренние серваки.
10) Lambda - serverless вычисления. Вы можете просто написать какой-то код, и вам не нужно заниматься менеджментом серверов, на которых она должна выполняться. Часто используется как listener на какие-то события. Например, ее можно подписать на SNS топик и при получении нотификации Lambda будет выполнена. Или можно использовать для запуска кода по рассписанию для housekeeping работ. Очень дорогой сервис, поэтому использовали редко.
11) ElastiCache - распределенный кэш. Поддерживает Redis и Memcached.
12) Kinesis - стрим по типу Kafka. Можно дампить большие объемы данных из вашего приложения в S3, Redshift или Elasticsearch.
13) QuickSight - позволяет визуализировать данные и строить дашборды. Часто применяется для визуализации данных из Redshift.
14) Kafka - позволяет легко разворачивать и менеджить из коробки Kafka.
15) Elasticsearch - позволяет легко разворачивать и менеджить из коробки Elasticsearch. Позволяет индексировать данные и получать к ним быстрый доступ, делать поиск, строить дашборды и т.д.
AWS имеет куча других сервисов, в том числе и для Load balancing, API Gateway, Routing, авторизации и аутентификации и много чего другого. Но мы их использовали реже, т.к. были другие альтернативы, не открытые внешним клиентам.
1) Dynamo DB - NoSQL база. Часто использовали ее как key-value storage. Время доступа к значению по ключу составляет несколько миллисекунд, при этом позволяет хранить большие объемы данных по сравнению с in-memory cache.
2) SQS - распределенная очередь. Подходит для асинхронной bulk обработки данных. Позволяет реализовать простейший back pressure механизм между двумя компонентами и сгладить пики производства данных producer и не перегрузить этими пиками consumer.
3) Amazon Redshift - Data Warehouse. Позволяет хранить и обрабатывать колоссальные объемы данных (Big Data). Позволяет делать анализ больших объемов данных, ETL и т.д.
4) RDS - распределенная SQL/реляционная база данных.
5) SNS - pub-sub сервис. Можно создавать топики и подписываться на них. Имеет куча интеграций, в том числе можно делать SMS и e-mail нотификации.
6) S3 - blob storage. Позволяет сохранять данные в виде файлов, и получать к ним доступ. Netflix использует S3 для хранения видео. Часто используется для хранения другой медиа информации, видео, картинки, аудио. Часто используется для хранения файлов и промежуточных выгрузок больших объемов данных для дальнейшей обработки.
7) SageMaker - позволяет создавать, обучать и деплоить в продакшен модели машинного обучения (ML).
8) Cloudwatch - позволяет мониторить ваш сервис в продакшене. Создавать и мониторить метрики, создавать дашборды и алармы и т.д.
9) EC2 - Самый частый сервис используемый в AWS. Позволяет вам арендовать сервера и деплоить на них ваши приложения. Позволяет делать auto-scaling в зависимости от нагрузки. Мы использовали не часто, т.к. тогда только шла миграция на EC2. Чаще использовали внутренние серваки.
10) Lambda - serverless вычисления. Вы можете просто написать какой-то код, и вам не нужно заниматься менеджментом серверов, на которых она должна выполняться. Часто используется как listener на какие-то события. Например, ее можно подписать на SNS топик и при получении нотификации Lambda будет выполнена. Или можно использовать для запуска кода по рассписанию для housekeeping работ. Очень дорогой сервис, поэтому использовали редко.
11) ElastiCache - распределенный кэш. Поддерживает Redis и Memcached.
12) Kinesis - стрим по типу Kafka. Можно дампить большие объемы данных из вашего приложения в S3, Redshift или Elasticsearch.
13) QuickSight - позволяет визуализировать данные и строить дашборды. Часто применяется для визуализации данных из Redshift.
14) Kafka - позволяет легко разворачивать и менеджить из коробки Kafka.
15) Elasticsearch - позволяет легко разворачивать и менеджить из коробки Elasticsearch. Позволяет индексировать данные и получать к ним быстрый доступ, делать поиск, строить дашборды и т.д.
AWS имеет куча других сервисов, в том числе и для Load balancing, API Gateway, Routing, авторизации и аутентификации и много чего другого. Но мы их использовали реже, т.к. были другие альтернативы, не открытые внешним клиентам.
Amazon
Amazon DynamoDB
Amazon DynamoDB is a fully managed, serverless, key-value NoSQL database that runs high-performance applications at any scale, with built-in security, continuous backups, and automated multi-region replication.
👍12❤11😱2🤗1
Чем отличается Junior от Middle программиста?
Оба уровня являются начальными для программиста и в сумме на этих уровнях програмист находится от 2 до 10 лет. Обычно, рано или поздно он промоутится до Senior уровня. На котором он уже может находится очень долго, вплоть до конца карьеры. Хотя существенная часть senior программистов продолжает карьерный рост. Либо конвертируются в менеджеры или становятся Staff+/Architect в зависимости от того, как устроены роли в компании.
Но не опыт, или не только опыт, отличает Junior от Middle. Промоушены в IT не дают просто за выслугу лет. Хотя корреляция с опытом есть, т.к. нужно время, чтобы получить, а главное продемонстрировать свои скилы на следующий уровень.
Так что же отличает Junior от Middle?
1) Самостоятельность. С ростом от Junior до Senior растет самостоятельность программиста в решении задач. Junior программисту нужна большая помощь при работе над задачами, чем Middle программисту. Но многие программисты неверно трактуют самостоятельность. Многие просто перестают задавать вопросы и застревают при решении задачи, продалбывая сроки. Самостоятельность проявляется в том, что вы драйвите решение задачи самостоятельно. Сами определяете, что вам не хватает для решения задачи, что нужно уточнить или выяснить, что нужно самому покопать и т.д. Т.е. это не означает, что вы все знаете изначально и быстро сделаете задачу, никого не спрашивая. Это значит, что вы самостоятельно будете делать все необходимое для приближения решения задачи, в том числе, задавать вопросы, обсуждать, договариваться, выяснять, самому копать код, документацию или интернет. Junior программисту нужен постаянный гайденс, какие следующие шаги нужно предпринять, чтобы продвинутся в решении задачи.
2) Скоуп/размер задач. С ростом уровня, будет расти скоуп задач, над которыми вы работаете. Для Junior это какие-то микрофичи, багфиксы, root cause которых известен и т.д. Для мидла это среднего размера фичи, описание которой уже существует, багфиксы, для которых не известен root cause и фикс которых может потребовать обсуждений, алайментов или дизайна. При работе над фичей - требования определены или есть человек, который их определит, мидлу же нужно сделать небольшой дизайн и реализовать. Для Junior нужно не только детально поставить задачу, но и указать технический путь ее решения (дизайн или конкретный код, который нужно изменить).
3) Dealing with ambiguity(работа с неопределенностью). Этот скил растет при переходе между всеми уровнями. Junior практически не имеет этого скила. Ему нужно детально поставить задачу и указать технический путь ее решения. Мидл также работает с поставленной задачей, но он способен самостоятельно уточнять требования, обсуждать требования с разными людьми, делать небольшой технический дизайн. Начиная с уровня Senior и тем более с уровня Staff+ вам самому придется придумывать задачи/проблемы, но про это отдельно напишу.
4) Качество кода. Junior не имеет опыта ни в индустрии, ни в компании и команде. Его код может состоять из глупых велосипедов и антипаттернов. Чтобы стать мидлом вам нужно адаптироваться к стандартам кодирования в вашей команде и соответствовать среднему уровню. Вначале, вы будете получать множество комментариев на код ревью по качеству кода, вам нужно быстро обучаться и работать над тем, чтобы вы начали соответствовать по этому параметру вашей команде и получать комментарии по существу решаемой задачи и меньше общих замечаний по структуре кода. На уровне Senior вам же нужно задавать эти стандарты кода для команды.
5) Экспертиза в какой либо области в рамках команды. Обычно, Junior это не тот человек, к которому идут спрашивать что-либо. Даже по теме задачи, которую он решает. Мидл же углубляется как минимум в тему задачи, над которой он работает и может быть тем человеком, кто может ответить на те или иные вопросы по этой задаче или связанных с ней темам. Мидл становится person to go, по одной или более темам в рамках команды.
Оба уровня являются начальными для программиста и в сумме на этих уровнях програмист находится от 2 до 10 лет. Обычно, рано или поздно он промоутится до Senior уровня. На котором он уже может находится очень долго, вплоть до конца карьеры. Хотя существенная часть senior программистов продолжает карьерный рост. Либо конвертируются в менеджеры или становятся Staff+/Architect в зависимости от того, как устроены роли в компании.
Но не опыт, или не только опыт, отличает Junior от Middle. Промоушены в IT не дают просто за выслугу лет. Хотя корреляция с опытом есть, т.к. нужно время, чтобы получить, а главное продемонстрировать свои скилы на следующий уровень.
Так что же отличает Junior от Middle?
1) Самостоятельность. С ростом от Junior до Senior растет самостоятельность программиста в решении задач. Junior программисту нужна большая помощь при работе над задачами, чем Middle программисту. Но многие программисты неверно трактуют самостоятельность. Многие просто перестают задавать вопросы и застревают при решении задачи, продалбывая сроки. Самостоятельность проявляется в том, что вы драйвите решение задачи самостоятельно. Сами определяете, что вам не хватает для решения задачи, что нужно уточнить или выяснить, что нужно самому покопать и т.д. Т.е. это не означает, что вы все знаете изначально и быстро сделаете задачу, никого не спрашивая. Это значит, что вы самостоятельно будете делать все необходимое для приближения решения задачи, в том числе, задавать вопросы, обсуждать, договариваться, выяснять, самому копать код, документацию или интернет. Junior программисту нужен постаянный гайденс, какие следующие шаги нужно предпринять, чтобы продвинутся в решении задачи.
2) Скоуп/размер задач. С ростом уровня, будет расти скоуп задач, над которыми вы работаете. Для Junior это какие-то микрофичи, багфиксы, root cause которых известен и т.д. Для мидла это среднего размера фичи, описание которой уже существует, багфиксы, для которых не известен root cause и фикс которых может потребовать обсуждений, алайментов или дизайна. При работе над фичей - требования определены или есть человек, который их определит, мидлу же нужно сделать небольшой дизайн и реализовать. Для Junior нужно не только детально поставить задачу, но и указать технический путь ее решения (дизайн или конкретный код, который нужно изменить).
3) Dealing with ambiguity(работа с неопределенностью). Этот скил растет при переходе между всеми уровнями. Junior практически не имеет этого скила. Ему нужно детально поставить задачу и указать технический путь ее решения. Мидл также работает с поставленной задачей, но он способен самостоятельно уточнять требования, обсуждать требования с разными людьми, делать небольшой технический дизайн. Начиная с уровня Senior и тем более с уровня Staff+ вам самому придется придумывать задачи/проблемы, но про это отдельно напишу.
4) Качество кода. Junior не имеет опыта ни в индустрии, ни в компании и команде. Его код может состоять из глупых велосипедов и антипаттернов. Чтобы стать мидлом вам нужно адаптироваться к стандартам кодирования в вашей команде и соответствовать среднему уровню. Вначале, вы будете получать множество комментариев на код ревью по качеству кода, вам нужно быстро обучаться и работать над тем, чтобы вы начали соответствовать по этому параметру вашей команде и получать комментарии по существу решаемой задачи и меньше общих замечаний по структуре кода. На уровне Senior вам же нужно задавать эти стандарты кода для команды.
5) Экспертиза в какой либо области в рамках команды. Обычно, Junior это не тот человек, к которому идут спрашивать что-либо. Даже по теме задачи, которую он решает. Мидл же углубляется как минимум в тему задачи, над которой он работает и может быть тем человеком, кто может ответить на те или иные вопросы по этой задаче или связанных с ней темам. Мидл становится person to go, по одной или более темам в рамках команды.
👍29❤2
6) Getting things done. Junior, обычно, делает микрошаги, которые ему говорят и не овнит полностью задачу. Мидл же драйвит решение задачи и имеет послужной список из решеных на хорошем уровне, в разумные сроки, среднего размера для команды задач.
Это мои мысли на эту тему, пишите, что вы об этом думаете.
Это мои мысли на эту тему, пишите, что вы об этом думаете.
👍27
Задача с собеседования в Microsoft: Самое большое палиндромное число
Задача. Дана строка, состоящая только из цифр. Нужно вернуть наибольшее палиндромное число, которое может быть составлено, используя только цифры из данного числа. Необязательно использовать все цифры из заданного числа, но нужно использовать хотя бы одну цифру. Цифры можно использовать в любом порядке. Нельзя дополнять результат ведущими нулями (нулями в начале).
Ссылка на leetcode: https://leetcode.com/problems/largest-palindromic-number/description/
Пример:
Input: "444947137"
Output: "7449447"
Пример:
Input: "00009"
Output: "9"
Решение. Решение описал тут: Задача с собеседования в Microsoft: Самое большое палиндромное число
Задача. Дана строка, состоящая только из цифр. Нужно вернуть наибольшее палиндромное число, которое может быть составлено, используя только цифры из данного числа. Необязательно использовать все цифры из заданного числа, но нужно использовать хотя бы одну цифру. Цифры можно использовать в любом порядке. Нельзя дополнять результат ведущими нулями (нулями в начале).
Ссылка на leetcode: https://leetcode.com/problems/largest-palindromic-number/description/
Пример:
Input: "444947137"
Output: "7449447"
Пример:
Input: "00009"
Output: "9"
Решение. Решение описал тут: Задача с собеседования в Microsoft: Самое большое палиндромное число
LeetCode
Largest Palindromic Number - LeetCode
Can you solve this real interview question? Largest Palindromic Number - You are given a string num consisting of digits only.
Return the largest palindromic integer (in the form of a string) that can be formed using digits taken from num. It should not…
Return the largest palindromic integer (in the form of a string) that can be formed using digits taken from num. It should not…
👍10❤3
Странные тайтлы в инвест банках
Когда я планировал устроится на работу в один их крупнейших инвест банков, я не знал какие там есть роли и тайтлы у сотрудников. Тогда я привык к тайтлам типа Junior, Middle, Senior, Lead, Architect, Manager, Director и т.д. И когда я увидел у некоторых, людей, кто там работает, кого я знаю, тайтлы типа VP, я подумал нифига себе они устроились. Я знал, что инвест банки платят больше, чем средняя по больнице компания. Но для меня VP, это кто-то, кто репортит непосредственно c-team (CEO, CTO, CPO, CFO и т.д.). Т.е. тот, кто имеет в подчинение много тысяч человек и получает миллионы долларов.
Но к моему удивлению оказалось, что там этих VP жопой жуй. Там тайтлы устроены по другому.
Наглядно посмотреть соответствие тайтлов в Deutsche Bank, JP Morgan и Facebook можно тут: levels.fyi
По факту, оказалось, что VP - это Staff Software Engineer для разработчика или для менеджера - это самый низкий уровень менеджера.
Примерное соответствие тайтлов в Deutsche Bank:
1) Analyst - Junior
2) Associate - Middle
3) AVP - Senior
4) VP - Staff/Manager
5) Director - Senior Staff/Principal/Senior Manager
6) Managing Director - Distinguished Engineer/Fellow/Director of Engineering
Примерное соответствие тайтлов в JP Morgan:
1) Analyst - Junior
2) Associate - Junior
3) Senior Associate - Middle
4) VP - Senior
5) Executive Director - Staff
6) Managing Director - Senior Staff/Principal
Когда я планировал устроится на работу в один их крупнейших инвест банков, я не знал какие там есть роли и тайтлы у сотрудников. Тогда я привык к тайтлам типа Junior, Middle, Senior, Lead, Architect, Manager, Director и т.д. И когда я увидел у некоторых, людей, кто там работает, кого я знаю, тайтлы типа VP, я подумал нифига себе они устроились. Я знал, что инвест банки платят больше, чем средняя по больнице компания. Но для меня VP, это кто-то, кто репортит непосредственно c-team (CEO, CTO, CPO, CFO и т.д.). Т.е. тот, кто имеет в подчинение много тысяч человек и получает миллионы долларов.
Но к моему удивлению оказалось, что там этих VP жопой жуй. Там тайтлы устроены по другому.
Наглядно посмотреть соответствие тайтлов в Deutsche Bank, JP Morgan и Facebook можно тут: levels.fyi
По факту, оказалось, что VP - это Staff Software Engineer для разработчика или для менеджера - это самый низкий уровень менеджера.
Примерное соответствие тайтлов в Deutsche Bank:
1) Analyst - Junior
2) Associate - Middle
3) AVP - Senior
4) VP - Staff/Manager
5) Director - Senior Staff/Principal/Senior Manager
6) Managing Director - Distinguished Engineer/Fellow/Director of Engineering
Примерное соответствие тайтлов в JP Morgan:
1) Analyst - Junior
2) Associate - Junior
3) Senior Associate - Middle
4) VP - Senior
5) Executive Director - Staff
6) Managing Director - Senior Staff/Principal
Levels.fyi
Levels.fyi | Salaries & Tools to Level Up Your Career
Search 300k+ salaries for different companies, job titles, career levels, and locations. Explore our tools to help you get paid more!
👍8
Заменят ли программистов нейросети в ближайшем будущем? Update
Прошлый подобный пост я писал 6 месяцев назад, спустя год после выхода нашумевшего ChatGPT 3: Часть 1, Часть 2.
Есть ли какие-то изменения, которые повлияли на мою оценку? Какие мои текущие соображения по этому поводу?
Начну со своего личного опыта использования и реального влияния нейросетей на меня и мою работу:
1) Хайп и холивары. Хайп, по прежнему, вокруг этой темы большой. Все вокруг об этом говорят, как на работе, так и в обычной жизни. Снимается тонна видео и пишется тонна статей. Часто, при обсуждении возникает два противоположных лагеря и начинаются споры с пеной у рта. Google Trends по прежнему показывает некоторый рост популярности темы, но темп роста популярности темы замедлился. За полгода он вырос на 15%.
2) Легче стало читерить на собеседовании. Т.к. все еще много компаний проводят собеседования или полностью или частично онлайн, то с использованием ChatGPT и подобным им моделям, стало проще найти правильный и оптимальный ответ или решение задачи с собеседования. Раньше читерить тоже было возможно, но нужно было параллельно гуглить, смотреть разные сайты, на которых поиск мог быть базовым и не всегда удавалось найти быстро правильный ответ. С использованием ChatGPT, можно все спрашивать в одном окне чата и быстро получать правильные ответы на простые вопросы с собеседования, для которых не нужен большой контекст. Но в большинстве случаев читерство распознается и наказывается. Т.к. кандидат хоть и говорит правильный ответ, но он не может его пояснить или путается в тривиальных уточняющих вопросах. Смотри случаи с собеседований: Случай 1, Случай 2. Специальная галочка, про подозрения.
3) Появились ChatGPT подобные и другие тулы на основе LLM. В компании появилось много тулов на основе LLM. Как то, обычные, чат подобные, решения, так и встроенные в среду разработки и другие тулы. Тулы более кастомизированные под работу внутри компании, т.к. обученные на внутренней документации и внутреннем коде по типу Copilot. Но к их юзабельности и полезности есть вопросы. Чат подобные тулы помогают немного поправить мой кривой письменный английский. Но только при уже написанной фразе. Просить сгенерировать с нуля какой-то текст плохая идея. Текст будет написан в другой стилистике и с другим смыслом, хотя и похожим на то, что нужно. А спрашивать что-то - не лучше, чем обычный поиск. Т.к. документация в IT компаниях всегда хромает и обучение на ней не сильно прибавляет юзабилити. Тулы типа Coopilot иногда угадывают простые функции, которые хочешь написать. Вроде всяких утилитарных вещей. Что и так не заняло бы много времени или можно было бы найти на stackoverflow или внутренних ресурсах. Но это иногда добавляет немного юзабилити, что не надо много времени тратить на тупой код. Но не более того. Все остальные варианты использования провалились. Мне не понравилось качество результата или просто бесполезные для меня функции.
За полгода вышло множество новых версий и фич на LLM: ChatGPT-4o, meta.ai, google внедрил LLM во все свои продукты. Но пока, кроме wow эффекта они для меня ничего не производят. Типа выглядит круто, но буду ли я это все использовать - сомнительно. Или буду, но какого-то импакта, что это хоть кого-то заменит не видно.
За полгода я не заметил какого-то существенно приближения момента замены программистов.
Прошлый подобный пост я писал 6 месяцев назад, спустя год после выхода нашумевшего ChatGPT 3: Часть 1, Часть 2.
Есть ли какие-то изменения, которые повлияли на мою оценку? Какие мои текущие соображения по этому поводу?
Начну со своего личного опыта использования и реального влияния нейросетей на меня и мою работу:
1) Хайп и холивары. Хайп, по прежнему, вокруг этой темы большой. Все вокруг об этом говорят, как на работе, так и в обычной жизни. Снимается тонна видео и пишется тонна статей. Часто, при обсуждении возникает два противоположных лагеря и начинаются споры с пеной у рта. Google Trends по прежнему показывает некоторый рост популярности темы, но темп роста популярности темы замедлился. За полгода он вырос на 15%.
2) Легче стало читерить на собеседовании. Т.к. все еще много компаний проводят собеседования или полностью или частично онлайн, то с использованием ChatGPT и подобным им моделям, стало проще найти правильный и оптимальный ответ или решение задачи с собеседования. Раньше читерить тоже было возможно, но нужно было параллельно гуглить, смотреть разные сайты, на которых поиск мог быть базовым и не всегда удавалось найти быстро правильный ответ. С использованием ChatGPT, можно все спрашивать в одном окне чата и быстро получать правильные ответы на простые вопросы с собеседования, для которых не нужен большой контекст. Но в большинстве случаев читерство распознается и наказывается. Т.к. кандидат хоть и говорит правильный ответ, но он не может его пояснить или путается в тривиальных уточняющих вопросах. Смотри случаи с собеседований: Случай 1, Случай 2. Специальная галочка, про подозрения.
3) Появились ChatGPT подобные и другие тулы на основе LLM. В компании появилось много тулов на основе LLM. Как то, обычные, чат подобные, решения, так и встроенные в среду разработки и другие тулы. Тулы более кастомизированные под работу внутри компании, т.к. обученные на внутренней документации и внутреннем коде по типу Copilot. Но к их юзабельности и полезности есть вопросы. Чат подобные тулы помогают немного поправить мой кривой письменный английский. Но только при уже написанной фразе. Просить сгенерировать с нуля какой-то текст плохая идея. Текст будет написан в другой стилистике и с другим смыслом, хотя и похожим на то, что нужно. А спрашивать что-то - не лучше, чем обычный поиск. Т.к. документация в IT компаниях всегда хромает и обучение на ней не сильно прибавляет юзабилити. Тулы типа Coopilot иногда угадывают простые функции, которые хочешь написать. Вроде всяких утилитарных вещей. Что и так не заняло бы много времени или можно было бы найти на stackoverflow или внутренних ресурсах. Но это иногда добавляет немного юзабилити, что не надо много времени тратить на тупой код. Но не более того. Все остальные варианты использования провалились. Мне не понравилось качество результата или просто бесполезные для меня функции.
За полгода вышло множество новых версий и фич на LLM: ChatGPT-4o, meta.ai, google внедрил LLM во все свои продукты. Но пока, кроме wow эффекта они для меня ничего не производят. Типа выглядит круто, но буду ли я это все использовать - сомнительно. Или буду, но какого-то импакта, что это хоть кого-то заменит не видно.
За полгода я не заметил какого-то существенно приближения момента замены программистов.
👍13🔥3
Основные преграды на этом пути:
1) Отсутствие агентности. Все тулы или решения на основе LLM работают в режиме запрос-ответ. Т.е. нужен кто-то, кто будет эти запросы отправлять и использовать результаты работы LLM. Т.е. некий оператор. Даже в самых оптимистичных сценариях, изменится лишь стиль работы программиста. В котором, часть с написанием кода он заменит на промт-инжиниринг. Но пока и до этого далеко. Пока LLM хорошо работает с Hello World задачами из туториалов. С реальными проектами на миллионы строк, попросить его самому разобраться в коде и поменять все так как тебе нужно при очень приблизительном описании он не может. Т.е. пока нельзя даже сделать из программистов - промт-инженеров не получается. Не то, что заменить всех программистов на менеджеров, которые не могут оценить и проверить результат, который выдает LLM и тем более его использовать. Есть какие-то попытки добавить агентности, но они все основаны на захардкоженых алгоритмах и API разных тулов, которые позволяют создать pull-request и деплоить. На пальцах с нуля объяснить LLM свой тех стек и сказать иди учись, а потом давать high level задачи не получается.
2) Колоссальное число ошибок и неспособность к самопроверке. LLM всегда выдает какой-то результат. Не важно, он правильный или нет. Она выдает какой-то правдоподобный текст. Она не говорит, тут я уверена, тут нет, тут знаю, тут не знаю. Она всегда генерирует какой-то текст или код. Поэтому пока всегда нужен кто-то, кто будет это все проверять. Тот же оператор-программист.
3) Отсутствие агентности в коммуникации. Если брать не Junior программистов - то программист большую часть времени не занимается написанием кода. Существенную часть времени у него занимает общение с коллегами. Или в чатах или на митингах. Т.е. большая часть информации и мнений существует не в виде текстов, а в виде мыслей в голове или памяти. LLM не занимается самостоятельно поиском нужных людей, с кем поговорить, что и у кого нужно выяснить, о чем договориться, что обсудить и т.д.
Т.е. пока мое мнение такое, что сейчас LLM не способны заменить даже Junior программистов. Но в ближайшем будущем скорее всего смогут. Смогут ли заменить программистов начиная с уровня Middle, Senior и выше, пока не видно таких технологий. Но тогда возникает вопрос, а если заменят Junior, откуда возникнут новые Middle и Senior? Поэтому все равно придется компаниям нанимать программистов на вырост, даже если их перфоманс первый год-два будет ниже чем просто взять LLM за три копейки. Но это не значит, что полная замена никогда не произойдет. Просто, я пока не вижу таких технологий. Но все быстро развивается и нет гарантий, что они не появятся в будущем или даже в ближайшем будущем.
1) Отсутствие агентности. Все тулы или решения на основе LLM работают в режиме запрос-ответ. Т.е. нужен кто-то, кто будет эти запросы отправлять и использовать результаты работы LLM. Т.е. некий оператор. Даже в самых оптимистичных сценариях, изменится лишь стиль работы программиста. В котором, часть с написанием кода он заменит на промт-инжиниринг. Но пока и до этого далеко. Пока LLM хорошо работает с Hello World задачами из туториалов. С реальными проектами на миллионы строк, попросить его самому разобраться в коде и поменять все так как тебе нужно при очень приблизительном описании он не может. Т.е. пока нельзя даже сделать из программистов - промт-инженеров не получается. Не то, что заменить всех программистов на менеджеров, которые не могут оценить и проверить результат, который выдает LLM и тем более его использовать. Есть какие-то попытки добавить агентности, но они все основаны на захардкоженых алгоритмах и API разных тулов, которые позволяют создать pull-request и деплоить. На пальцах с нуля объяснить LLM свой тех стек и сказать иди учись, а потом давать high level задачи не получается.
2) Колоссальное число ошибок и неспособность к самопроверке. LLM всегда выдает какой-то результат. Не важно, он правильный или нет. Она выдает какой-то правдоподобный текст. Она не говорит, тут я уверена, тут нет, тут знаю, тут не знаю. Она всегда генерирует какой-то текст или код. Поэтому пока всегда нужен кто-то, кто будет это все проверять. Тот же оператор-программист.
3) Отсутствие агентности в коммуникации. Если брать не Junior программистов - то программист большую часть времени не занимается написанием кода. Существенную часть времени у него занимает общение с коллегами. Или в чатах или на митингах. Т.е. большая часть информации и мнений существует не в виде текстов, а в виде мыслей в голове или памяти. LLM не занимается самостоятельно поиском нужных людей, с кем поговорить, что и у кого нужно выяснить, о чем договориться, что обсудить и т.д.
Т.е. пока мое мнение такое, что сейчас LLM не способны заменить даже Junior программистов. Но в ближайшем будущем скорее всего смогут. Смогут ли заменить программистов начиная с уровня Middle, Senior и выше, пока не видно таких технологий. Но тогда возникает вопрос, а если заменят Junior, откуда возникнут новые Middle и Senior? Поэтому все равно придется компаниям нанимать программистов на вырост, даже если их перфоманс первый год-два будет ниже чем просто взять LLM за три копейки. Но это не значит, что полная замена никогда не произойдет. Просто, я пока не вижу таких технологий. Но все быстро развивается и нет гарантий, что они не появятся в будущем или даже в ближайшем будущем.
❤9👍5🤔2🔥1
В чем преимущество получения части компенсации в виде акций публичных компаний?
В FAANG компаниях, и во многих других Big Tech компаниях (Microsoft, Lyft, Uber, Two Sigma, Jane Street, Citadel), существенная часть вашей компенсации выдается вам в виде акций этой компании. Эти акции будут приходить вам на брокерский счет и они полностью ликвидны. Вы одним нажатием можете их продать по текущей рыночной цене и превратить их к кэш. А основное преимущество в том, что они имеют тенденцию к росту.
Давайте рассмотрим на реальном оффере в одну из FAANG компаний и посмотрим, как будет меняться компенсация, даже если человек не промоутится и работает средне для своего уровня.
Это офер на Senior позицию в FAANG в Лондон в 2020 году:
1) Базовая зп - £100k в год
2) 15% - годовой бонус
3) Акции в сумме $360k на 4 года по текущей цене в $280 за акцию. Акции будут выплачиваться равными порциями, раз в 3 месяца. Но акции будут вам выдаваться в штуках, а не в долларах. Поэтому это означает, что вам дадут 1285 акций на 4 года, которые будут приходить равными порциями раз в 3 месяца. Или 80 акций раз в 3 месяца, сколько бы они не стоили в данный момент.
Давайте посчитаем ожидаемый доход в первый год, если цена акций не изменится:
TC (Total Compensation) = £100k + £100k * 15% + 80 * 4 * $280 = £185k или $236k в год.
Теперь, скажем, он проработал 3 года в компании, не промоутился. Зп ему подняли на 20% за 3 года для компенсации инфляции. Но при этом цена акций увеличилась с $280 до $490 за акцию. Давайте рассчитаем, сколько он будет зарабатывать, если ему не давали новых акций за хороший перфоманс (рефрешеры), а только то, что было в начальном оффере.
Тогда он будет зарабатывать:
TC (Total Compensation) = £120k + £120k * 15% + 80 * 4 * $490 = £261k или $332k в год.
Т.е. просто из-за роста акций, со средним перфомансом, без учета рефрешеров (а они обычно всегда даются, даже при среднем перфомансе), его компенсация выросла на 40%.
В FAANG компаниях, и во многих других Big Tech компаниях (Microsoft, Lyft, Uber, Two Sigma, Jane Street, Citadel), существенная часть вашей компенсации выдается вам в виде акций этой компании. Эти акции будут приходить вам на брокерский счет и они полностью ликвидны. Вы одним нажатием можете их продать по текущей рыночной цене и превратить их к кэш. А основное преимущество в том, что они имеют тенденцию к росту.
Давайте рассмотрим на реальном оффере в одну из FAANG компаний и посмотрим, как будет меняться компенсация, даже если человек не промоутится и работает средне для своего уровня.
Это офер на Senior позицию в FAANG в Лондон в 2020 году:
1) Базовая зп - £100k в год
2) 15% - годовой бонус
3) Акции в сумме $360k на 4 года по текущей цене в $280 за акцию. Акции будут выплачиваться равными порциями, раз в 3 месяца. Но акции будут вам выдаваться в штуках, а не в долларах. Поэтому это означает, что вам дадут 1285 акций на 4 года, которые будут приходить равными порциями раз в 3 месяца. Или 80 акций раз в 3 месяца, сколько бы они не стоили в данный момент.
Давайте посчитаем ожидаемый доход в первый год, если цена акций не изменится:
TC (Total Compensation) = £100k + £100k * 15% + 80 * 4 * $280 = £185k или $236k в год.
Теперь, скажем, он проработал 3 года в компании, не промоутился. Зп ему подняли на 20% за 3 года для компенсации инфляции. Но при этом цена акций увеличилась с $280 до $490 за акцию. Давайте рассчитаем, сколько он будет зарабатывать, если ему не давали новых акций за хороший перфоманс (рефрешеры), а только то, что было в начальном оффере.
Тогда он будет зарабатывать:
TC (Total Compensation) = £120k + £120k * 15% + 80 * 4 * $490 = £261k или $332k в год.
Т.е. просто из-за роста акций, со средним перфомансом, без учета рефрешеров (а они обычно всегда даются, даже при среднем перфомансе), его компенсация выросла на 40%.
👍11
Построил график своих доходов за всю карьеру в IT (17 лет).
2007 - Начало
2012 - Стал Лидом
2016 - Переезд в Европу
2017 - Начало работы в FAANG
2022 - Обвал стоков, массовые сокращения, получение рефрешеров
2023 - быстрый рост стоимости акций
За все время 2.2 миллиона долларов.
Если будет интересна детализация по конкретным числам, пишите в комментариях
2007 - Начало
2012 - Стал Лидом
2016 - Переезд в Европу
2017 - Начало работы в FAANG
2022 - Обвал стоков, массовые сокращения, получение рефрешеров
2023 - быстрый рост стоимости акций
За все время 2.2 миллиона долларов.
Если будет интересна детализация по конкретным числам, пишите в комментариях
👍22
С учетом комментариев, сделал расчет зп в месяц на руки (после оплаты налогов). Также сделал зум на первых годах карьеры, до переезда. Учить многопоточность я начал в 2014. Учить алгоритмы и system design я начал в 2015.
👍16❤2👎1
Сколько выходцев из СНГ работает в FAANG/Big Tech компаниях?
Я работал в двух FAANG компаниях. Работал в Европейских офисах и неоднократно бывал в командировках в офисах США, а также постоянно взаимодействую с коллегами из разных офисов. Моя личная оценка, что в Европейских офисах выходцев из СНГ работает 10-20% на инженерных позициях. В офисах США немного меньше (5-10%) . В целом можно сделать оценку в 10% от общего числа программистов.
А сколько это в абсолютных числах?
Для этого нужно ответить на вопрос, сколько программистов в FAANG/Big Tech компаниях. Я проделал такую оценку на основе профилей в Linkedin.
Я разделил FAANG/Big Tech компании на 3 уровня, в зависимости от сложности собеседования и уровня компенсации. Tier 1 - туда сложнее всего попасть и самые высокие зп. В подборку я включил 11 компаний.
Для каждой компании приведены 3 цифры: число профилей на Linkedin, число программистов, оценка числа выходцев из СНГ. Например, Google: 287k/80k/8k - в Google работает 287k человек, из них 80k программисты, и моя оценка числа выходцев из СНГ. Или Amazon: 736k/112k/11.2k. В Amazon работает больше людей (1.5M), но половина из них не имеет профилей на Linkedin, т.к. это, в основном, рабочие складов, доставщики и т.д. Программистов всего - 112k (когда я там работал их было 100k, после был сильный рост, после были массовые сокращения). Я не уверен на 100% в этой цифре, но она дает правильный порядок величины.
Tier 1:
Google: 287k/80k/8k
Facebook: 119k/32k/3.2k
Netflix: 15k/2.5k/0.25k
Two Sigma: 2.2k/0.7k/0.07k
Всего программистов: 115k/СНГ(оценка): 11.5k
Tier 2:
Amazon: 736k/112k/11.2k
Apple: 172k/36k/3.6k
Uber: 97k/8.2k/0.8k
Lyft: 23k/1.7k/0.17k
Citadel:4.4k/0.8k/0.08k
Jane Street: 2.2k/0.5k/0.05k
Всего программистов: 159.2k/СНГ(оценка): 15.9k
Tier 3:
Microsoft: 228k/102k/10.2k
Итого:
Всего программистов (FAANG/Big Tech): 376k/СНГ(оценка): 37.6k
Т.е. по моим оценкам в топ-IT компаниях работает ~400k программистов, из них примерно 40k программистов - выходцы из СНГ. В основном, это выходцы из России, Украины, Казахстана и Белоруссии. Но представлены все страны.
Я работал в двух FAANG компаниях. Работал в Европейских офисах и неоднократно бывал в командировках в офисах США, а также постоянно взаимодействую с коллегами из разных офисов. Моя личная оценка, что в Европейских офисах выходцев из СНГ работает 10-20% на инженерных позициях. В офисах США немного меньше (5-10%) . В целом можно сделать оценку в 10% от общего числа программистов.
А сколько это в абсолютных числах?
Для этого нужно ответить на вопрос, сколько программистов в FAANG/Big Tech компаниях. Я проделал такую оценку на основе профилей в Linkedin.
Я разделил FAANG/Big Tech компании на 3 уровня, в зависимости от сложности собеседования и уровня компенсации. Tier 1 - туда сложнее всего попасть и самые высокие зп. В подборку я включил 11 компаний.
Для каждой компании приведены 3 цифры: число профилей на Linkedin, число программистов, оценка числа выходцев из СНГ. Например, Google: 287k/80k/8k - в Google работает 287k человек, из них 80k программисты, и моя оценка числа выходцев из СНГ. Или Amazon: 736k/112k/11.2k. В Amazon работает больше людей (1.5M), но половина из них не имеет профилей на Linkedin, т.к. это, в основном, рабочие складов, доставщики и т.д. Программистов всего - 112k (когда я там работал их было 100k, после был сильный рост, после были массовые сокращения). Я не уверен на 100% в этой цифре, но она дает правильный порядок величины.
Tier 1:
Google: 287k/80k/8k
Facebook: 119k/32k/3.2k
Netflix: 15k/2.5k/0.25k
Two Sigma: 2.2k/0.7k/0.07k
Всего программистов: 115k/СНГ(оценка): 11.5k
Tier 2:
Amazon: 736k/112k/11.2k
Apple: 172k/36k/3.6k
Uber: 97k/8.2k/0.8k
Lyft: 23k/1.7k/0.17k
Citadel:4.4k/0.8k/0.08k
Jane Street: 2.2k/0.5k/0.05k
Всего программистов: 159.2k/СНГ(оценка): 15.9k
Tier 3:
Microsoft: 228k/102k/10.2k
Итого:
Всего программистов (FAANG/Big Tech): 376k/СНГ(оценка): 37.6k
Т.е. по моим оценкам в топ-IT компаниях работает ~400k программистов, из них примерно 40k программистов - выходцы из СНГ. В основном, это выходцы из России, Украины, Казахстана и Белоруссии. Но представлены все страны.
👍13
Распределение по уровням в FAANG
В FAANG компаниях уровни разработчиков не ограничиваются Junior, Middle, Senior. Обычно их 6-7 уровней. Иногда даже больше. В некоторых компаниях у вас даже не меняется тайтл при смене уровня. В Facebook, например, все разработчики имеют тайтл Software Engineer, и их уровень скрыт. Этот уровень знают только их менеджеры. При этом там 7 уровней разработчиков от E3 до E9. Компенсация при этом меняется от ~$100k-150k на E3 до ~$2M-3M на E9 в год гросс.
В Amazon есть тайтлы и уровни: SDE 1 (L4), SDE 2(L5), SDE 3/Senior Software Engineer (L6), Principal (L7), Senior Principal (L8), Distinguished (L9). Т.е. в Амазоне 6 уровней. Из-за того, что они нарезаны более крупно, то они часто не соответствуют уровням и тайтлам в других компаниях. Например, SDE 1(L4) соответствуют и Junior и Middle с небольшим опытом. SDE 2(L5) - очень опытный Middle или Senior. SDE 3 (L6) - это скорее Staff Software Engineer в большинстве компаний. Principal (L7) - это скорее Senior Staff в большинстве компаний. Senior Principal (L8) - это Principal в большинстве других FAANG компаниях. Google в этом смысле хорошо соответствует уровням в Facebook.
Маппинг уровней можно посмотреть тут: levels.fyi
Сколько же разработчиков на разных уровней в процентном соотношении?
В Amazon, до массовых сокращений было примерно такое распределение: SDE 1 - 35-40%, SDE 2 - 40-45%, SDE 3 - 10-15%, Principal+ ~1-5%. После массовых сокращений соотношение могло измениться, т.к. очень часто при сокращениях увольняли людей на более низких уровнях. В Facebook сейчас: E3 - 5-10%, E4 - 25-30%, E5 ~50%, E6 - ~10-15%, E7+ ~5%. Т.е. картины похожие. Senior разработчики самые массовые - порядка половины. Мидлов и джунов осталось очень мало, меньше 30-40%. Staff порядка 10-15%. Уровни выше Staff - единицы процентов.
В FAANG компаниях уровни разработчиков не ограничиваются Junior, Middle, Senior. Обычно их 6-7 уровней. Иногда даже больше. В некоторых компаниях у вас даже не меняется тайтл при смене уровня. В Facebook, например, все разработчики имеют тайтл Software Engineer, и их уровень скрыт. Этот уровень знают только их менеджеры. При этом там 7 уровней разработчиков от E3 до E9. Компенсация при этом меняется от ~$100k-150k на E3 до ~$2M-3M на E9 в год гросс.
В Amazon есть тайтлы и уровни: SDE 1 (L4), SDE 2(L5), SDE 3/Senior Software Engineer (L6), Principal (L7), Senior Principal (L8), Distinguished (L9). Т.е. в Амазоне 6 уровней. Из-за того, что они нарезаны более крупно, то они часто не соответствуют уровням и тайтлам в других компаниях. Например, SDE 1(L4) соответствуют и Junior и Middle с небольшим опытом. SDE 2(L5) - очень опытный Middle или Senior. SDE 3 (L6) - это скорее Staff Software Engineer в большинстве компаний. Principal (L7) - это скорее Senior Staff в большинстве компаний. Senior Principal (L8) - это Principal в большинстве других FAANG компаниях. Google в этом смысле хорошо соответствует уровням в Facebook.
Маппинг уровней можно посмотреть тут: levels.fyi
Сколько же разработчиков на разных уровней в процентном соотношении?
В Amazon, до массовых сокращений было примерно такое распределение: SDE 1 - 35-40%, SDE 2 - 40-45%, SDE 3 - 10-15%, Principal+ ~1-5%. После массовых сокращений соотношение могло измениться, т.к. очень часто при сокращениях увольняли людей на более низких уровнях. В Facebook сейчас: E3 - 5-10%, E4 - 25-30%, E5 ~50%, E6 - ~10-15%, E7+ ~5%. Т.е. картины похожие. Senior разработчики самые массовые - порядка половины. Мидлов и джунов осталось очень мало, меньше 30-40%. Staff порядка 10-15%. Уровни выше Staff - единицы процентов.
Levels.fyi
Levels.fyi | Salaries & Tools to Level Up Your Career
Search 300k+ salaries for different companies, job titles, career levels, and locations. Explore our tools to help you get paid more!
👍10
Чем отличается Senior программист от Middle?
Ранее я публиковал пост про отличие Junior от Middle: Чем отличается Junior от Middle программиста?
1) Самостоятельность. Ваша самостоятельность продолжает расти. Вы можете драйвить и овнить самые большие и сложные проекты в рамках вашей команды.
2) Скоуп/размер задач. Часто, импакт ваших проектов не ограничивается только вашей командой, а распространяется и на другие команды.
2) Delivering through others. В силу того, что проекты, над которыми вы работаете, становятся большими и сложными, в одиночку вы их сделать не сможете в ограниченный промежуток времени. Поэтому вам нужно быть лидером и основным овнером проекта, но реализовывать его отдельные части могут другие программисты (Middle и Junior).
3) Dealing with ambiguity(работа с неопределенностью). Этот скил продолжает расти на всех уровнях. На уровне Senior вам нужно в рамках своего проекта или area of expertise уметь производить декомпозицию большого и сложного проекта на отдельные маленькие и понятные части, над которыми будут работать другие более junior программисты. Это достигается благодаря вашему дизайну решения, обсуждениям и согласованиям с другими людьми из вашей или других команд, благодаря вашей экспертизе или тому что вы раскопали в коде или интернете.
4) Качество кода. Вы становитесь тем, кто задает и повышает стандарты написания кода в рамках вашей команде. Это достигается собственным примером, качественными code review и установлениями общих политик написания и качества кода в рамках команды.
5) Mentorship. Вы становитесь ментором для Middle и Junior программистов в вашей команде. Помогаете онбордить людей в команду и компанию. Занимаетесь собеседованиями и наймом других программистов.
6) Экспертиза в рамках команды. Вы становитесь тем человеком, к которому идут если у них возникли какие-либо вопросы в рамках каких-либо компонент, которые овнит ваша команда. В том числе и из других команд.
7) Visibility. Т.к. часто ваши проекты распространяются и на другие команды, то про вас, вашу экспертизу, ваши скилы знают за пределами вашей команды. Вы делаете презентации, пишите доки с результатами/планами/целями работы всей команды или проекта. О вас и вашей работе знают другие менеджеры, не только ваш непосредственный менеджер.
8) Планирование. Вы один из существенных контрибьютеров в roadmap вашей команды. Вы помогаете с постановкой целей, метрик и конкретных проектов, над которыми будет работать ваша команда.
9) Unblocking others. Вы проактивно помогаете другим программистам в рамках вашей команды или проекта разблокировать себя. Проактивно находите самые приоритетные вещи, которые замедляют или блокируют других программистов и помогает их разблокировать.
10) Проактивный багфиксинг и импрувмент. Вы проактивно находите и фиксите баги в коде вашей команды или проекта. Находите способы улучшить код или его производительность.
Ранее я публиковал пост про отличие Junior от Middle: Чем отличается Junior от Middle программиста?
1) Самостоятельность. Ваша самостоятельность продолжает расти. Вы можете драйвить и овнить самые большие и сложные проекты в рамках вашей команды.
2) Скоуп/размер задач. Часто, импакт ваших проектов не ограничивается только вашей командой, а распространяется и на другие команды.
2) Delivering through others. В силу того, что проекты, над которыми вы работаете, становятся большими и сложными, в одиночку вы их сделать не сможете в ограниченный промежуток времени. Поэтому вам нужно быть лидером и основным овнером проекта, но реализовывать его отдельные части могут другие программисты (Middle и Junior).
3) Dealing with ambiguity(работа с неопределенностью). Этот скил продолжает расти на всех уровнях. На уровне Senior вам нужно в рамках своего проекта или area of expertise уметь производить декомпозицию большого и сложного проекта на отдельные маленькие и понятные части, над которыми будут работать другие более junior программисты. Это достигается благодаря вашему дизайну решения, обсуждениям и согласованиям с другими людьми из вашей или других команд, благодаря вашей экспертизе или тому что вы раскопали в коде или интернете.
4) Качество кода. Вы становитесь тем, кто задает и повышает стандарты написания кода в рамках вашей команде. Это достигается собственным примером, качественными code review и установлениями общих политик написания и качества кода в рамках команды.
5) Mentorship. Вы становитесь ментором для Middle и Junior программистов в вашей команде. Помогаете онбордить людей в команду и компанию. Занимаетесь собеседованиями и наймом других программистов.
6) Экспертиза в рамках команды. Вы становитесь тем человеком, к которому идут если у них возникли какие-либо вопросы в рамках каких-либо компонент, которые овнит ваша команда. В том числе и из других команд.
7) Visibility. Т.к. часто ваши проекты распространяются и на другие команды, то про вас, вашу экспертизу, ваши скилы знают за пределами вашей команды. Вы делаете презентации, пишите доки с результатами/планами/целями работы всей команды или проекта. О вас и вашей работе знают другие менеджеры, не только ваш непосредственный менеджер.
8) Планирование. Вы один из существенных контрибьютеров в roadmap вашей команды. Вы помогаете с постановкой целей, метрик и конкретных проектов, над которыми будет работать ваша команда.
9) Unblocking others. Вы проактивно помогаете другим программистам в рамках вашей команды или проекта разблокировать себя. Проактивно находите самые приоритетные вещи, которые замедляют или блокируют других программистов и помогает их разблокировать.
10) Проактивный багфиксинг и импрувмент. Вы проактивно находите и фиксите баги в коде вашей команды или проекта. Находите способы улучшить код или его производительность.
Telegram
FAANG Master
Чем отличается Junior от Middle программиста?
Оба уровня являются начальными для программиста и в сумме на этих уровнях програмист находится от 2 до 10 лет. Обычно, рано или поздно он промоутится до Senior уровня. На котором он уже может находится очень…
Оба уровня являются начальными для программиста и в сумме на этих уровнях програмист находится от 2 до 10 лет. Обычно, рано или поздно он промоутится до Senior уровня. На котором он уже может находится очень…
👍17❤2🔥2👻1
Какие базы данных используются в FAANG?
Разные компании используют разные базы данных по тем или иным причинам. Очень часто в FAANG используются базы данных, разработанные внутри компании. FAANG-компании исторически первыми начали работать с гигантскими объемами данных и большим числом пользователей. Начав использовать существующие на тот момент решения, они столкнулись с их ограничениями, а других решений на рынке не было. Поэтому они начали разрабатывать свои технологии, чтобы соответствовать требованиям решаемых задач. Также FAANG-компании часто хотят иметь возможность быстро кастомизировать код базы данных под свои задачи, поэтому использование сторонних решений не всегда подходит. Часть этих решений базируется на существующих на тот момент решениях и является просто надстройкой. Некоторые, по сути, создали новый вид баз данных и хранилищ, которых не было до этого.
Для примера я приведу, какие базы используются в Amazon и Fb. Существует много разных видов баз данных (SQL, NoSQL) и хранилищ. Поэтому я приведу самые распространенные базы, по типам баз и типичные use-case их использования.
1) Relational database (RBD/Реляционная база данных):
Amazon: AWS RDS (разработан внутри компании) - позволяет создавать и разворачивать базы в облаке. Поддерживает множество движков: MySQL, PostgreSQL, Amazon Aurora (совместима с MySQL и PostgreSQL, поэтому легко мигрировать существующие базы), Oracle, Microsoft SQL Server, MariaDB. Чаще, внутри компании используется Aurora, MySQL или PostgreSQL в качестве движка. AWS RDS же позволяет легко создавать кластеры реляционных баз данных, в том числе развернутые в разных регионах планеты, конфигурировать репликацию данных, бэкапы и многое другое.
Fb: MySQL с масштабными внутренними надстройками для партиционирования, кластеризации и т.д. Поверх сделан собственный слой кэша гигантских масштабов.
2) Data warehouse. Применяется для логирования гиганского объема данных из всех компонент для последующего анализа. Эти данные потом используются для получения разного рода метрик, анализа, а также данных для Machine Learning. Применяется для обработки больших объемов данных не в режиме реального времени, а асинхронно. Часто, при помощи ETL.
Amazon: Amazon Redshift (разработан внутри компании).
Fb: Apache Hive(разработан внутри компании). Всегда применяется в комбинации с движком Presto (разработан изначально внутри компании)
3) NoSQL. Основной use-case - key-value хранилище для большого числа данных (что дорого если использовать in-memory cache).
Amazon: Amazon DynamoDB (разработан внутри компании)
Fb: RocksDB (разработан внутри компании), ZippyDB (разработан внутри компании)
4) Blob. В основном, применяется для хранения медиа файлов (картинки, видео и аудио), а также больших выгрузок данных, как промежуточный этап ETL или для анализа.
Amazon: AWS S3 (разработан внутри компании)
Fb: Свое внутреннее хранилище.
Разные компании используют разные базы данных по тем или иным причинам. Очень часто в FAANG используются базы данных, разработанные внутри компании. FAANG-компании исторически первыми начали работать с гигантскими объемами данных и большим числом пользователей. Начав использовать существующие на тот момент решения, они столкнулись с их ограничениями, а других решений на рынке не было. Поэтому они начали разрабатывать свои технологии, чтобы соответствовать требованиям решаемых задач. Также FAANG-компании часто хотят иметь возможность быстро кастомизировать код базы данных под свои задачи, поэтому использование сторонних решений не всегда подходит. Часть этих решений базируется на существующих на тот момент решениях и является просто надстройкой. Некоторые, по сути, создали новый вид баз данных и хранилищ, которых не было до этого.
Для примера я приведу, какие базы используются в Amazon и Fb. Существует много разных видов баз данных (SQL, NoSQL) и хранилищ. Поэтому я приведу самые распространенные базы, по типам баз и типичные use-case их использования.
1) Relational database (RBD/Реляционная база данных):
Amazon: AWS RDS (разработан внутри компании) - позволяет создавать и разворачивать базы в облаке. Поддерживает множество движков: MySQL, PostgreSQL, Amazon Aurora (совместима с MySQL и PostgreSQL, поэтому легко мигрировать существующие базы), Oracle, Microsoft SQL Server, MariaDB. Чаще, внутри компании используется Aurora, MySQL или PostgreSQL в качестве движка. AWS RDS же позволяет легко создавать кластеры реляционных баз данных, в том числе развернутые в разных регионах планеты, конфигурировать репликацию данных, бэкапы и многое другое.
Fb: MySQL с масштабными внутренними надстройками для партиционирования, кластеризации и т.д. Поверх сделан собственный слой кэша гигантских масштабов.
2) Data warehouse. Применяется для логирования гиганского объема данных из всех компонент для последующего анализа. Эти данные потом используются для получения разного рода метрик, анализа, а также данных для Machine Learning. Применяется для обработки больших объемов данных не в режиме реального времени, а асинхронно. Часто, при помощи ETL.
Amazon: Amazon Redshift (разработан внутри компании).
Fb: Apache Hive(разработан внутри компании). Всегда применяется в комбинации с движком Presto (разработан изначально внутри компании)
3) NoSQL. Основной use-case - key-value хранилище для большого числа данных (что дорого если использовать in-memory cache).
Amazon: Amazon DynamoDB (разработан внутри компании)
Fb: RocksDB (разработан внутри компании), ZippyDB (разработан внутри компании)
4) Blob. В основном, применяется для хранения медиа файлов (картинки, видео и аудио), а также больших выгрузок данных, как промежуточный этап ETL или для анализа.
Amazon: AWS S3 (разработан внутри компании)
Fb: Свое внутреннее хранилище.
Amazon
Полностью управляемая реляционная база данных – Amazon RDS – AWS
Amazon Relational Database Service (RDS) является полностью управляемым сервисом баз данных с открытым исходным кодом, который дает возможность с легкостью пользоваться выбранной вами реляционной базой данных (в том числе, Amazon Aurora, PostgreSQL, SQL Server…
👍17🤔3
Посмотрел ролик от канала редакции про онлайн образование: https://youtu.be/OLlHpXhR29Q?si=CjbP1g7VjnM2Gx4L
Удивили истории, как кто-то решил менять профессию в уже сильно зрелом возрасте и наличии другой нормальной специальности на айтишную. Интересно, есть ли тут такие люди? Какой был ваш опыт? Я сам учился на курсах в 2006 году по Java и SQL. Но я тогда был еще студентом и курсы были от компании, которая потом многих брала на работу.
Удивили истории, как кто-то решил менять профессию в уже сильно зрелом возрасте и наличии другой нормальной специальности на айтишную. Интересно, есть ли тут такие люди? Какой был ваш опыт? Я сам учился на курсах в 2006 году по Java и SQL. Но я тогда был еще студентом и курсы были от компании, которая потом многих брала на работу.
YouTube
Мифы и правда об онлайн-образовании / Редакция
Больше трети россиян собираются сменить профессию в этом году
18+ НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН, РАСПРОСТРАНЕН И (ИЛИ) НАПРАВЛЕН ИНОСТРАННЫМ АГЕНТОМ ПИВОВАРОВЫМ АЛЕКСЕЕМ ВЛАДИМИРОВИЧЕМ ЛИБО КАСАЕТСЯ ДЕЯТЕЛЬНОСТИ ИНОСТРАННОГО АГЕНТА ПИВОВАРОВА…
18+ НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН, РАСПРОСТРАНЕН И (ИЛИ) НАПРАВЛЕН ИНОСТРАННЫМ АГЕНТОМ ПИВОВАРОВЫМ АЛЕКСЕЕМ ВЛАДИМИРОВИЧЕМ ЛИБО КАСАЕТСЯ ДЕЯТЕЛЬНОСТИ ИНОСТРАННОГО АГЕНТА ПИВОВАРОВА…
👍3