JS живет по своим правилам

В Мета на перфоманс ревью будут оценивать AI-driven impact

Со следующего года в PSC(перфоманс ревью в Мета) будет введена новая ось: AI-driven impact. На текущий момент, перфоманс оценивается по 4 осям: Project Impact, Engineering Excellence, Direction, People.
До этого, Мета уже запустила эксперимент, по использыванию AI на собеседовании: Начиная с 30 сентября Мета запускает пилот по использованию AI во время интервью

Уровень абсурда нарастает.

Простой вопрос с собеседования по Java

Что не так с кодом:

static int value = 1;
static final Object obj = new Object();

// поток 1
....
synchronized (obj) {
value++;
}
....

// поток 2
.....
int x = value;
....

Ответ.
Переменная не volatile, но ее изменение происходит в synchronized-блоке. Это гарантирует атомарность и видимость изменения только по отношению к потокам, которые читают в synchronized-блоке на том же мониторе (Смотри Вопрос с собеседования: что такое Java Memory Model и happens-before и Atomicity and Visibility). В соответствии с Java Memory Model, факт выхода из synchronized (obj) создаёт happens-before только по отношению к другим участкам кода, которые тоже синхронизируются на том же мониторе (obj). Поэтому для обеспечения видимости и атомарности нужно чтение поместить также в synchronized-блок на том же мониторе:

static int value = 1;
static final Object obj = new Object();

// поток 1
synchronized (obj) {
    value++;
}

// поток 2
int x;
synchronized (obj) {
    x = value;
}

В качестве альтернативы можно использовать AtomicInteger:

static final AtomicInteger value = new AtomicInteger(1);

// поток 1
value.incrementAndGet();

// поток 2
int x = value.get();

Добавление volatile в переменную обеспечит только видимость, но не атомарность операции. В данном случае у нас пишет только один поток и переменная 32-битная - поэтому эта проблема может быть не столь критичной, мы не прочитаем какое-то кривое значение, оно просто может быть не самым актуальным, если мы будем читать во время инкремента. Но если у нас будут писать уже несколько потоков, то это будет реальной проблемой, могут быть утеряны некоторые изменения. Поэтому фиксить эту проблему просто добавлением volatile - не лучшее решение.

Смотри также:
1) Разобрал 32 вопроса и задачи по Java и Многопоточность
2) Вопрос с собеседования: что такое Java Memory Model и happens-before
3) Atomicity and Visibility

Задача с собеседования в Google

Задача. Дан массив целых чисел. Значения могут быть только 0, 1 и 2. Нужно отсортировать на месте (без доп. памяти). Использовать библиотечные функции сортировки нельзя.

Например,

Input: nums = [2,0,2,1,1,0]
Output: [0,0,1,1,2,2]

Input: nums = [2,0,1]
Output: [0,1,2]

Ссылка на leetcode: https://leetcode.com/problems/sort-colors

Решение.

Решение разобрал тут: Задача с собеседования в Google: Sort Colors

Код решения:

public void sortColors(int[] nums) {
    int left = 0;
    int right = nums.length - 1;
    int current = 0;
    while (current <= right) {
        if (nums[current] == 0) {
            swap(nums, left, current);
            left++;
            current++;
        } else if (nums[current] == 1) {
            current++;
        } else {
            swap(nums, current, right);
            right--;
        }
    }
}

private void swap(int nums[], int i, int j) {
    int tmp = nums[i];
    nums[i] = nums[j];
    nums[j] = tmp;
}

В тему недавнего outage Cloudflare

Какая у вас статистика прохождения System Design и алгосов?

На данный момент у меня такая:
1) Собеседования по алгоритмам - 56% раундов пройдено успешно за всю карьеру
2) Собеседования по алгоритмам в FAANG - 78% раундов пройдено успешно
3) System Design - 100% успешно пройденых раундов

Статистику по алгосам я подпортил за 2011-2015 годы, когда ничего про подготовку не знал и не готовился. За эти годы у меня только 20% успешных прохождений.

Что там по замене программистов при помощи 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 и т.д. это вопрос удачи. Вы генерируете что-то в надежде, что будет то, что вы хотите. Если не получилось, он не редактирует немного - он геренит заново. Поэтому по факту это не тул, а игра в лотерею. Ты генерируешь десятки и сотни вариантов и из них выбираешь. Аналогично с кодом, вайб кодинг не работает. Первоначальная генерация быстрая, но разобраться в коде, кастомизировать, устранить баги из-за галлюцинаций - все это требует времени и усилий.

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

Агентность и замена джунов
Не смотря на появление 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 (одним из вариантов занимается Ян Лекун), но это пока на уровне исследований.

Продолжение следует.

Вышло новое интервью с Ильей Суцкевером

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

https://youtu.be/aR20FWCCjAs

Что там по замене программистов при помощи 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 программистов, которые смогут делать существенные продукты.

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

Предотвращают ли тесты баги в проде?

Краткий ответ: нет.

Даже со 100% покрытием кода тестами мы не можем гарантировать, что багов в проде не будет. Тесты лишь фиксируют текущее понимание разработчиком того, как код должен и может работать. Если это понимание не верно, то тесты не предотвратят баги. Более того, источником багов часто становятся различные конфигурационные изменения (конфигурация сети, базы, изменение бизнес правил и настроек), изменения в API зависимостей, которые вы используете, очень редкие race conditions и т.д.

Если тесты не предотвращают все баги, то и нет смысла их вообще писать?

Тесты писать смысл есть, в том числе и для предотвращения багов.

Польза тестов:

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

Хоть тесты и хорошее покрытие не предотвращают все баги в проде, они имеют много другой пользы. В Amazon, в нашей организации покрытие тестами было 95-97%. Тем не менее, баги и аутэджи случались. Но чаще они были связаны с конфигурациями, версиями API, неправильным пониманием бизнес-логики или очень редкими стечениями многих факторов, которые трудно воспроизвести в тесте.

Ещё одно наблюдение из моего 18-летнего опыта: на количество багов в проде больше влияет не процент покрытия тестами, а качество разработчиков. В Meta покрытие тестами сильно меньше, но число багов очень маленькое.

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

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

Эта цитата из начала главы 4: Comments из книги Clean Code (Robert C.Martin)

Я согласен с большинством положений этой главы.
Основной посыл — комментарии в коде следует писать только в случае крайней необходимости. Если вам приходится комментировать код, это стоит рассматривать как провал, так как в большинстве случаев причина появления комментариев — плохой, нечитаемый код.
Более того комментарии быстро начинают расходится с кодом, который они описывают и могут вводить в заблуждение.

Значит ли это, что комментарии в коде писать не надо вообще?

Нет. Комментарии в некоторый случаях полезны:

1) Хорошее описание public API. Если вы разрабатываете библиотеку, которая используется другими командами внутри вашей компании или вне ее. Или API/Endpoint, которое вызывают другие команды. Если это 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, которое никем, кроме вас и вашей команды, не используется.

В какую из FAANG-компаний самое сложное Coding-interview?

Краткий ответ: Google.

Несмотря на то, что в Google на решение задач дают больше времени — нередко это одна задача на 45 минут или задача + follow-up — сами задачи, как правило, сложнее, чем в других компаниях. Google любит спрашивать динамическое программирование и задачи на графы. Кроме того, это часто уровень LeetCode Hard.
Остальные этапы собеседования в Google не самые сложные по сравнению с другими FAANG-компаниями. Поведенческое собеседование (на googliness) проще, чем во многих других компаниях (в том же Amazon, например). А System Design примерно на том же уровне, что и в Meta.
В Meta на coding-интервью всегда дают по две задачи, и у вас есть по 20 минут на каждую. Но большинство задач уровня Medium, а динамическое программирование, как правило, не спрашивают. Более того, субъективно, вариативность задач ниже, поэтому, выучив наизусть первые 30 самых частых задач, с большой вероятностью вы получите на собеседовании хотя бы половину именно из этого списка.

Начиная с февраля 2026 сотрудники Инстаграмма должны ходить в офис 5 дней в неделю

На данный момент RTO(return-to-office) policy обязует ходить в офис 3 дня в неделю. Это приводит к так называемому Coffee Badging, когда люди приходят в офис на несколько часов для галочки.
Начиная с февраля сотрудники в США, которые работают над Instagram, должны будут ходить в офис 5 дней в неделю.

Amazon вернул 5-дневную рабочую неделю еще в январе 2025 года.

Вышло интервью в соавтором статьи Attention Is All You Need

Интервью с Ильей Полосухиным.
Он является соавтором статьи Attention Is All You Need, в которой описана архитектура трансформера(по сути - создание LLM). OpenAI, используя эту архитектуру, обучила её на данных всего интернета, что привело к созданию ChatGPT.

Сам Илья, сейчас занимается другими вещами. Он переключился на блокчейн.

Его линкелин: Illia Polosukhin

Само интервью: https://youtu.be/k17HfILvMnA

Таймкод про историю изобретения трансформера — 1:28:00

Чего мне больше всего не хватает, спустя 5 лет жизни в Лондоне?

Недавно исполнилось ровно 5 лет с тех пор, как я переехал в Лондон.

Чего мне больше всего не хватает в Лондоне, по сравнению с жизнью в Москве?
Это березки? Водка? Доставка за 10 минут? - Нет.

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


Смотри также:
1) Бытовые особенности жизни в Лондоне. Часть 1.
2) Бытовые особенности жизни в Лондоне. Часть 2.
3) Бытовые особенности жизни в Лондоне. Часть 3.

Laurent Simons получил PhD по квантовой физике в возрасте 15 лет

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

Это вам не жаловаться на незнание того, как работает хеш-таблица и как инвертировать дерево.

Новость

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

Представьте, вы просыпаетесь от звонка в дверь, а там Цукерберг с супом.

Подкаст: https://www.youtube.com/watch?v=ZeyHBM2Y5_4

Мета сокращает расходы на метаверс на 30%.

Последует ли очередная волна сокращений?

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

Если искали, что бы послушать в выходные, не ищите дальше

Официальный саундтрек чемпионата мира по Microsoft Excel: https://youtu.be/xJL573PGYak