FAANG Master

История моих оценок на перфоманс ревью(PSC) в Facebook/Meta 1) H2 2020 - TNTE (Too New To Evaluate) 2) H1 2021 - EE (Exceeds Expectations) 3) H2 2021 - EE (Exceeds Expectations) 4) 2022 - GE (Greatly Exceeded Expectations) 5) 2023 - EE (Exceeds Expectations) 6) 2024 - GE (Greatly Exceeded Expectations)

Если искали, что бы послушать в выходные, не ищите дальше Официальная музыка чемпионата мира по Microsoft Excel: https://youtu.be/xJL573PGYak

Фотки моих рабочих столов в 3 компаниях: В Deutsche Bank (в Москве, которая с видом из окна), Trivago (Dusseldorf с дашбордами в кибане) и Amazon (Luxembourg с оружием)

Мета сокращает расходы на метаверс на 30%. Последует ли очередная волна сокращений? На Метаверс были потрачены огромные деньги (50+ миллиардов долларов). Даже переименовали компанию из Facebook в Meta. Результат на картинке.

Mark Chen на подкасте у Ashlee Vance рассказал, что Марк Цукерберг пытался рекрутировать половину его подчиненных. Он не только предлагал десятки и сотни миллионов долларов за переход, но и сам приготовил суп и сам его приносил домой потенциальным новым сотрудникам. Mark Chen - Chief Research Officer в Open AI. Его линкедин: Mark Chen Он также является главным тренером сборной США на международной олимпиаде по информатике. Подкаст: https://www.youtube.com/watch?v=ZeyHBM2Y5_4

Laurent Simons получил PhD по квантовой физике в возрасте 15 лет PhD - это аналог кандидатской диссертации. В возрасте 8 лет он закончил школу, в 10 лет получил бакалавра, в 12 - магистра. И наконец в 15 защитил PhD. Дальше планирует переключиться с квантовой физики на медицину и AI. У него IQ - 145. Это вам не жаловаться на незнание того, как работает хэштаблица. Новость

Чего мне больше всего не хватает, спустя 5 лет жизни в Лондоне? Недавно исполнилось ровно 5 лет с тех пор, как я переехал в Лондон. Чего мне больше всего не хватает в Лондоне, по сравнению с жизнью в Москве? Это березки? Водка? Доставка за 10 минут? - Нет. 1) Сложно встретиться с родственниками. Живя в Москве, я мог относительно просто приехать к родственникам. Живя в Лондоне это затруднительно. Особенно в последние 5 лет. 2) Еда в кафе и ресторанах. Я бы не сказал, что в Лондоне она хуже, просто она другая. Вкусы и предпочтения в еде мало изменяются за жизнь. 3) Столовые. У нас есть столовая в офисе. Но столовых по городу нет или практически нет. Это снгшная тема. Тут только кафе и рестораны. Поесть борщ, пюрешку с котлеткой, гречку и две соски, компот можно только в русском ресторане или в доставке. 4) Фильмы и шоу на русском. В кинотеатрах фильмы только в оригинале на английском. Это, конечно, полезно, но приходится дополнительно напрегать свой мозг. Особенно, если у человека британский акцент. Про театры и постановки Шекспира я молчу, там происходящее понятно только из действий. 5) Покрытие мобильного интернета. Тут в метро практически нет интернета. Более того, даже на улице не везде ловит мобильный интернет. 6) Платные больницы и инвитро. Платные больницы и больницы по платной страховке тут есть, но экспириенс от них все же другой. Все более сложно устроено и сильно дороже. А прямого аналога инвитро нет. Есть разные аналоги, с разным набором услуг. Но большой, дешевой, во всеми возможными анализами и удобной сети нет. Смотри также: 1) Бытовые особенности жизни в Лондоне. Часть 1. 2) Бытовые особенности жизни в Лондоне. Часть 2. 3) Бытовые особенности жизни в Лондоне. Часть 3.

Вышло интервью в соавтором статьи Attention Is All You Need Интервью с Ильей Полосухиным. Он является соавтором статьи Attention Is All You Need, в которой описана архитектура трансформера(по сути - создание LLM). Open AI используя эту архитектуру, обучила ее на данных всего интернета, что привело к созданию ChatGPT. Сам Илья, сейчас занимается другими вещами. Он переключился на блокчейн. Его линкелин: Illia Polosukhin Само интервью: https://youtu.be/k17HfILvMnA

Начиная с февраля 2026 сотрудники Инстаграмма должны ходить в офис 5 дней в неделю На данный момент политика возвращения в офис (RTO) обязует ходить в офис 3 дня в неделю. Это приводит к так называемому "coffe-badging", когда люди приходят в офис на несколько часов для галочки. Начиная с февраля сотрудники в США, которые работают над Instagram, должны будут ходить в офис 5 дней в неделю. Amazon вернул 5-дневную рабочую неделю еще в январе 2025 года.

В какую из FAANG-компаний самое сложное Coding-interview? Краткий ответ: Google. Несмотря на то, что в Google дается больше времени на решение задачи и часто задача на 45 минут одна или задача + follow up, но задачи, обычно, сложнее, чем в другие компании. Google любит спрашивать динамическое программирование и задачи на графы. Кроме того, часто, это уровень leetcode hard. Остальные этапы собеседования в Google не самые сложные по сравнению с другими FAANG-компаниями. Поведенческое(гуглигес) собеседование проще, чем во многие другие компании(в тот же Amazon, например). А System Design на том же уровне, что в Meta. В Мета, на coding, всегда спрашивают по две задачи и у вас есть по 20 минут на задачу. Но большинство задач medium сложности, а также не спрашивают динамическое программирование. Более того, субтективно, вариативность задач ниже. Поэтому выучив первые 30 задач по частоте наизусть, половина из задач на вашем собеседовании, с большой вероятностью будет из этого списка.

Сколько я зарабатывал в течении последних 10 лет своей карьеры? В год, до вычета налогов: 2015 Deutsche Bank, Moscow: ₽3M/$49k 2016 Deutsche Bank, Moscow: ₽3M/$44.7k 2017 Trivago, Dusseldorf: €56.4k/$63.7k 2018 Amazon, Luxembourg: €103k/$121.5k 2019 Amazon, Luxembourg: €149k/$167k 2020 Amazon, Luxembourg: €193k/$220k 2021 Facebook, London: £214k/$274 2022 Facebook, London: £203k/$278k 2023 Facebook, London: £383k/$475 2024 Facebook, London: £575k/$730 C учетом инфляции в современных долларах 2025 года: 2015 Deutsche Bank, Moscow: $67k 2016 Deutsche Bank, Moscow: $60.3k 2017 Trivago, Dusseldorf: $84,7k 2018 Amazon, Luxembourg: $156,7k 2019 Amazon, Luxembourg: $212k 2020 Amazon, Luxembourg: $275k 2021 Facebook, London: $328.8 2022 Facebook, London: $308k 2023 Facebook, London: $508k 2024 Facebook, London: $759k С учетом инфляции, после вычета налогов, в месяц, в современных долларах и в современных рублях(в ценах 2025 года): 2015 Deutsche Bank, Moscow: $4.9k/₽378k 2016 Deutsche Bank, Moscow: $4.4k/₽340k 2017 Trivago, Dusseldorf: $4.65k/₽363k 2018 Amazon, Luxembourg: $8.52k/₽662k 2019 Amazon, Luxembourg: $10.8k/₽840k 2020 Amazon, Luxembourg: $13.9k/₽1M 2021 Facebook, London: $17k/₽1.3M 2022 Facebook, London: $13.5k/₽1M 2023 Facebook, London: $23.7k/₽1.8M 2024 Facebook, London: $34.8k/₽2.7M Смотри также: Сколько я зарабатывал в Amazon?

Какой был мой изначальный оффер в Facebook в 2020 году: Я пришел сначала на позицию Software Engineer (E5), что соответствует Senior Software Engineer. В Meta все разработчики имеют тайтл Software Engineer и уровни скрыты. От джуна до Principal и Distinguished, у всех тайтл Software Engineer и ты не всегда знаешь с какого уровня человеком ты говоришь. Оффер в 2020 году: 1) Base Salary - £101k/$134k 2) Bonus - 15% (£101k*0.15 = £15.15k/$20k) 3) RSU - $310k на 4 года. $77.5k в год. Плюс релокационный пакет, из которого ~£10k я получил налом. Компания сама оплатила квартиру на 2 месяца в Лондоне, наняла риелтора для поиска постоянной квартиры, помогла оформить визу и еще дала £10k налом. Итого на первый год, офер был: £101k*1.15 + £58k + £10k = £184k/$244k. С учетом инфляции на сегодняшний день это: £235k/$310k/24 миллиона рублей. За 4 год, я заработал уже в более чем в 2 раза больше (за 2024 год - £575/$760k/59 миллионов рублей)

Комментарии в коде

Don't comment bad code - rewrite it. Brian W. Kernighan and P. J. Plaugher

Эта цитата из начала главы 4: Comments из книги Clean Code (Robert C.Martin) Я согласен с большинством положений этой главы. Основной посыл — комментарии в коде следует писать только в случае крайней необходимости. Если вам приходится комментировать код, это стоит рассматривать как провал, так как в большинстве случаев причина появления комментариев — плохой, нечитаемый код. Более того комментарии быстро начинают расходится с кодом, который они описывают и могут вводить в заблуждение. Значит ли это, что комментарии в коде писать не надо вообще? Нет. Комментарии в некоторый случаях полезны: 1) Хорошее описание public API. Если вы разрабатываете библиотеку, которая используется другими командами внутри вашей компании или вне ее. Если это Java - можно писать Javadocs.Но описание API должно быть хорошим и полезным. Писать комментарии в стиле капитан очевидность смысле не имеет. Часто приходилось видеть Javadocs:

/**
 * Processes user order.
 *
 * @param userId the user id
 * @param products the products
 * @param applyDiscount the apply discount
 * @param sendEmail the send email
 */
public void processUserOrder(long userId, List<Product> products,
                             boolean applyDiscount, boolean sendEmail) {
    // ...
}

``` В таком Javadocs смысла не очень много. 2) Описание причин, почему так сделано. Если код выглядит плохо и очень хочется его переписать, но вы уже пытались и по каким-то причинам были вынуждены остановиться на воркэраунде, имеет смысл в комментарии объяснить, почему сделано именно так, а не иначе. 3) Предостережения. Похоже на предыдущий вариант, но если вы знаете, что изменения в этом коде в ту или иную сторону или его использование в определенном контексте приведет к очень плохим последствиям - стоит написать комментарий. 4) Пояснения, которые сложно выразить в коде. Иногда код невозможно сделать более читаемым из-за особенностей языка программирования, и он всё равно остаётся не очень удобным для восприятия. В таких случаях можно оставить информационный комментарий. 5) TODO. Имеет смысл оставлять такие комментарии о том, планируете изменить, дописать, улучшить в будущем. 6) Копирайты, если это требует ваша компания. Иногда компании по дефолту заставляют в каждый файл добавлять комментарий вверху или внизу с копирайтом, лицензией и т.д. В большинстве других случаев комментарии бесполезны или даже вредны: они перегружают мозг бессмысленной информацией при чтении кода, могут вводить в заблуждение и требуют дополнительных усилий разработчика для поддержки в актуальном состоянии. Например: 1) Комментарии в стиле капитан очевидность.

//Increment i
i++;

/** The name */
private String name;

2) Комментарии, которые можно убрать переименовав функцию, переменную или аргумент.

// timeout in milliseconds
long TIMEOUT = 5000;

Лучше:

long TIMEOUT_IN_MILLISECONDS = 5000;

//Extract user name from the input string
public String parse(String str) {
...

Лучше:

public String extractUserName(String commandLineParameters) {
...

3) Комментарии, когда можно вынесли логику в отдельную функцию.

// Проверяем, можно ли показать пользователю промо-баннер
if (user != null
        && user.isLoggedIn()
        && !user.isPremium()
        && featureFlags.isPromoBannerEnabled()) {

    showPromoBanner(user);
}

Лучше:

if (shouldShowPromoBanner(user)) {
    showPromoBanner(user);
}

private boolean shouldShowPromoBanner(User user) {
    return user != null
            && user.isLoggedIn()
            && !user.isPremium()
            && featureFlags.isPromoBannerEnabled();
}

4) Закомментированный старый код. Просто удаляйте код. Сейчас уже давно существует система контроля версий, которая хранит всю историю. 5) Комментарии (Javadocs) для не публичного API. Писать Javadocs ради самого факта их наличия не нужно. Не стоит писать комментарии для API, которое никем, кроме вас и вашей команды, не используется.

Предотвращают ли тесты баги в проде? Краткий ответ: нет. Даже со 100% покрытием кода тестами мы не можем гарантировать, что багов в проде не будет. Тесты лишь фиксируют текущее понимание разработчиком того, как код должен и может работать. Если это понимание не верно, то тесты не предотвратят баги. Более того, источником багов часто становятся различные конфигурационные изменения (конфигурация сети, базы, изменение бизнес правил и настроек), изменения в API зависимостей, которые вы используете, очень редкие race conditions и т.д. Если тесты не предотвращают все баги, то и нет смысла их вообще писать? Тесты писать смысл есть, в том числе и для предотвращения багов. Польза тестов: 1) Проверяют, что код работает так, как ты ожидаешь (хоть это ожидание может быть и не верным). Позволяет убедиться, что написанный код как-то работает и предотвращает кучу глупых багов. 2) Документирует код. Тесты - это лучшая документация к коду, которую можно придумать. Она актуальна. Т.к. если код изменился, то тесты перестанут работать. Так же разработчику проще понять как передать параметры, как вызвать этот код, как распарсить результат на примерах, чем прочитав сотни слов об этом. В Amazon часто приходилось интегрироваться с другими компонентами, и проще всего это было сделать — посмотреть интеграционные/e2e тесты, скопировать код теста к себе и поменять вызов и парсинг результата под свои нужды. 3) Можно спокойно делать рефакторинг кода. Если у вас хорошее покрытие тестами, то если при рефакторинге у вас начинают падать тесты, значит вы что-то сломали, или вам надо поправить сигнатуры вызовов в тестах. Вы можете с большой уверенностью гарантировать, что вы ничего своим рефакторингом не сломали. Если у вас нет хорошего покрытия тестами, то делать рефакторинг опасно. 4) Предотвращает регрессию. Вы делаете новое изменение в коде, добавляете тест и он работает. Но при этом этот код может поламать другой функционал и без хорошего покрытия вы об этом не узнаете. 5) Проверка, насколько удобен ваш код для клиента. Во время написания теста можно понять насколько просто или сложно ваш код использовать. Если тест писать сложно, то и использовать ваш код будет не просто. Хоть тесты и хорошее покрытие не предотвращают все баги в проде, но они имеют много другой пользы. В Amazon, в нашей орге покрытие тестами было 95%-97%. Тем не менее баги и аутедже случались. Но чаще они были связанны с конфигурациями, версиями API, неправильным пониманием бизнес логики или очень редкими стечениями многих факторов, которые трудно воспроизвести в тесте. Еще одно наблюдение из моего 18 летнего опыта, на количество багов в проде больше влияет не процент покрытия тестами, а качество разработчиков. В Мета покрытие тестами сильно меньше, но число багов очень маленькое.

Предыдущие части: 1) Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 1. 2) Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 2.

Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 3. AI Bubble Появляется все больше свидетельств того, что AI создает финансовый пузырь. При этом это не значит, что LLM и текущие генеративные модели не работают или бесполезны. Даже в текущем виде они полезны. Люди перестают искать информацию напрямую в поисковиках, в ней копаться и находить ответы. Сейчас эту функцию на себя берут LLM. Т.е. ChatGPT является прямым конкурентом поиску Google. Поэтому для Google стать лидером в AI является вопросом выживания. И на данный момент похоже на то, что Google начинает эту гонку выигрывать. Релиз Gemini 3 превзошел все ожидания и сместил ChatGPT с лидерских позиций. Более того, у Google есть давно и хорошо работающая монетизация через рекламу. Чего нельзя сказать про Open AI. У них пока все также нет нормальной монетизации, а подход с платными подписками пока работает в убыток. Несмотря на полезность LLM в качестве замены/эволюции поиска - объемы инвестиций непропорциональны. Инвестиции измеряются триллионами долларов. Как будто LLM не сегодня-завтра заменит всех людей, решит все проблемы энергетики, найдет лекарство от рака и людям можно будет не работать и получать базовый доход. Но пока это не звучит реалистично. Более того, все очень похоже на ситуацию с пузырем доткомов. Тогда кидали большие деньги во все компании, у которых появлялся сайт .com. При этом никакой работающей бизнес модели не было. Сейчас достаточно добавить AI в название своей компании и можно получить астрономические инвестиции. Сейчас люди получают 2 миллиарда долларов инвестиции без бизнес модели, просто имея слоган и 1-страничный сайт. Крупные игроки инвестируют сотни миллиардов долларов в строительство датацентров. При этом, стоимость видео карт для этих датацентров составляет существенную часть. Недавно Майкл Бьюри (это прототип главного героя фильма Игра на понижение, который заработал 700 миллионов для своих клиентов и 100 миллионов долларов для себя лично на кризисе 2008) зашортил Nvidia. Он посмотрел финансовые документы крупных компаний, и показал, что они завышают время использования видеокарт для своих будущих датацентров. Если раньше они закладывали, что видеокарты нужно менять раз в 3-4 года, то сейчас 6-7 лет. Это делается для искусственного занижения будущей стоимости работы этих датацентров. Варианты и число спекуляций для роста цен на акции продолжает расти: круговые сделки, массовые сокращения для перенаправления в AI, найм разрабов за сотни миллионов и миллиарды долларов. Даже сам Сэм Альтман, Сундар Пичаи, Марк Цукерберг, Безос и другие говорят про AI Bubble. Риски в ближайшие годы Перенаправление ресурсов в AI и возможный коллапс AI пузыря может привести к новым большим волнам массовых сокращений. Более того, за последние 5 лет IT индустрия создала много новых программистов. Сначала из-за роста использования онлайн ресурсов в ковид, а теперь для работы над AI. Кроме того, одной из коренных причин массовых сокращений в 2022-2023 годах стало отсутствие новых точек роста. Предыдущие проблемы масштабирования уже решены (поиск, соц сети, реклама, мессенджеры, видео контент). А новые не создали большое число новых рабочих мест (блокчейн, IoT, AR/VR). Все это создает предпосылки для очень конкурентного рынка программистов. Когда на рынке труда будет переизбыток программистов и недостаток вакансий. Кроме того, рост производительности программистов на 5%-20% из-за AI и ожидание, что AI скоро всех заменит может еще сильнее усугубить ситуацию для программистов в краткосроке, особенно для Junior программистов. Возможные позитивные сценарии для программистов в среднесрочной перспективе AI не сможет заменить программистов в долгосрочной перспективе, а лишь повысит их производительность + откроются новые точки роста, возможности для бизнеса или другие продукты, где полезен AI. Тогда может появиться большое число небольших и средних компаний, которые могут делать успешный продукты малыми командами. Или даже solo программистов, которые смогут делать существенные продукты.

Вышло новое интервью с Ильей Суцкевером Это сооснователь Open AI, ученик Джефри Хинтона(крестный отец Deep Learning, лауреат Нобелевской премии 2024 года по физике, благодаря нему появился метод обратного распространения ошибки в нейросетях). Сейчас он ушел из Open AI и делает свой стартап. https://youtu.be/aR20FWCCjAs

Агентность и замена джунов Не смотря на появление MCP и аналогов, AI все еще не хватает агентности. Ты не можешь сформулировать задачу для AI в 5 предложений и ожидать сделанную задачу на уровне мидла/синьера с таким же уровнем самостоятельности. AI все еще требует кучу бебиситинга и хендхолдинга. Это джун в лучшем случае. Но заменить джунов в долгосроке не получится. Джун это просто стадия роста программиста. Придется заменять всех (как минимум до Senior включительно). Иначе откуда брать Senior в долгосроке, если уволить всех джунов? Более того, AI не обучается на работе. Когда новый сотрудник приходит (даже Senior) ему требуется время для разгона (6 месяцев). Но он при этом обучается всем особенностям компании, отдела и команды. Ему не надо будет объяснять одни и теже вещи много раз. Он получает и кеширует контекст. Для AI каждый запрос как с чистого листа. Как будто он никогда не решал задачи для вашей команды или компании до этого. Прогресс или его отсутствие в развитии AI Под AI я имею ввиду генеративные модели. ML используется и приносит тонну пользы и триллионы долларов в год уже давно. Я говорю про текущий хайм генеративных моделей. Прорыв случился в 2017 году с созданием трансформеров: Attention Is All You Need. Open AI смогла обучить LLM на данных со всего интернета, что и привело к созданию ChatGPT и текущему хайпу. С тех пор прогресс не существенный. Появился встроенный поиск (RAG), Chain-of-Thoughts (что просто вариант промт инжиниринга), обучение модели дополнилось тысячами ручных лейблеров при помощи Reinforcement learning from human feedback. Качественные данные для обучения заканчиваются, новых архитектур нет, и все изменения инкрементальные. Прогресс замедлился и экспоненциальных скачков не предвидится. Есть идеи про World Models (одним из вариантов занимается Ян Лекун), но это пока на уровне исследований. Продолжение следует.

Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 1. Прогнозы Прошло практически 3 года с момента релиза ChatGPT в ноября 2022 года. С тех пор не утихают разговоры про замену программистов (и не только) при помощи AI в ближайшем будущем. В этом году CEO Anthropic (Claude) делал прогноз, что до конца лета AI заменит 90% программистов, а до конца года уже всех. Марк Цукерберг в начале года делал прогноз, что до конца 2025 AI будет на уровне мидла в Мета. Пока не похоже, что эти прогнозы сбываются. Сэм Альтман откладывал релиз ChatGPT 5.0, т.к. он уже 3 года всех кормит наступлением AGI и все ждали, что пятая версия будет уже этим AGI. Прогресс с предыдущего поколения моделей есть, но не существенный. Нет качественного изменения. Продуктивность и исследования Есть исследования, которые показывают, что буст продуктивности есть, но только на определенных типах задач: 1) Популярные языки 2) Маленькие репозитории 3) Простые задачи Что подходит для демо, прототипирования, пет-проектов, маленьких компаний на ранних стадиях. Тут буст продуктивности может быть очень существенный. Более того, число изменений кода может расти вплоть до 40%, но 20% из них приходится переделывать. При этом средний буст продуктивности лежит в диапазоне 5%-10%. Исследования: 1) Повышает ли AI производительность программистов? 2) Еще одно исследование улучшения продуктивности программистов при помощи AI Массовые сокращения Массовые сокращения в IT не связанны с заменой программистов. В 2022 и 2023 - оверхайринг в ковид и наступление постковида, спрос на IT-продукты перестал расти экспоненциально как в ковид. в 2024, 2025 - хайп вокруг AI, страх компаний проиграть в AI гонке и стать новым Yahoo или Kodak. Поэтому все крупные игроки перенаправляются ресурсы в разработку AI. Тул для личной продуктивности и проблемы При этом AI по большей части остается ассистентом и тулом для личной продуктивности. Его внедрения в продукты компаний не приносит денег, а только убытки. Есть исследования, что только 5% компаний внедрила AI в свои продукты, при этом 40% компаний пытались. Существенно больше компаний внедрило AI в качестве ассистентов для своих сотрудников с сомнительным ростом продуктивности и затратами на эти тулы. На данный момент это остается следующей ступенью развития google+stackoverflow+github+автокомплитеры, которые, как по мне принесли не меньший буст продуктовности в свое время. Просто это было растянуто на много лет. Все эти демо - сгенерируй змейку или тетрис впечатляют, но такой же код можно найти в пет-проектах на гитхабе. Это займет сильно больше времени, но результат будет тот же. Кроме того, после первоначальной генерации, очень сложно модифицировать код под свои нужды. Аналогичной проблемой страдают всяческие генераторы видео и музыки. Они не позволяют точечно редактировать и добиваться того, что вам нужно. Кто пытался генерировать мемы при помощи последних моделей вроде veo 3, sora 2, nano banana и т.д. это вопрос удачи. Вы генерируете что-то в надежде, что будет то, что вы хотите. Если не получилось, он не редактирует немного - он геренит заново. Поэтому по факту это не тул, а игра в лотерею. Ты генерируешь десятки и сотни вариантов и из них выбираешь. Аналогично с кодом, вайб кодинг не работает. Первоначальная генерация быстрая, но разобраться в коде, кастомизировать, устранить баги из-за галлюцинаций - все это требует времени и усилий.

Какая у вас статистика прохождения System Design и алгосов? На данный момент у меня такая: 1) Собеседования по алгоритмам - 56% раундов пройдено успешно за всю карьеру 2) Собеседования по алгоритмам в FAANG - 78% раундов пройдено успешно 3) System Design - 100% успешно пройденых раундов Статистику по алгосам я подпортил за 2011-2015 годы, когда ничего про подготовку не знал и не готовился. За эти годы у меня только 20% успешных прохождений.