max.sh

Когда-то давно, во времена учебы в ШАДе, нам читали интенсив по основам архитектуры GPU и разработки на CUDA. Обещали рассказать, как устроены видеокарты и почему они эффективны для машинного обучения. Я тогда дальше model.to('cuda:0') в этом вопросе ничего не знал, поэтому с интересом записался.

Лекции читали разработчики из Nvidia. Да, это было такое время, когда у компании был Московский офис и они периодически нанимали DL-инженеров, а иногда и стажеров (марафон технических раундов и глубоких вопросов на понимание, чтобы побороться за 2 стажерские позиции).

Курс, по моему мнению, получился ужасным. Материал стремительно усложнялся без какой-либо оглядки на аудиторию и тот факт, что ко второй лекции половина слушателей уже отвалилась. Я потерял суть происходящего уже минуте на 20-30 первой лекции, в момент когда термины вида SM, warp schedulers, cuda cores заполняли каждый слайд, а повествование превратилось во внутренний митап для инженеров Nvidia.

Худо-бедно интенсив я закрыл, решая задачи методом проб и ошибок. От курса в голове не осталось почти ничего. Разве что боязнь копаться в деталях работы с GPU.

Позже, уже в 2022-2023 году, модели перестали влазить в память одной ГПУ и нужно было учиться паралелить, оценивать эффективность инфраструктуры в поисках ответа на вопрос: а почему все так медленно? are we compute bound or communication bound? Снова я столкнулся с GPU акселераторами лицом к лицу. Документации от Nvidia было не очень много, так что неподготовленному читателю входить было не просто. Но дело двигалось тем же путем проб и ошибок и общением с коллегами по работе.

А хороших гайдов на понимание все еще не было. Мне кажется их и сейчас не очень много. ( Как и специалистов в этой области. Performance Engineer крайне актуальная роль в области DL на ближайшие годы)

Недавно наткнулся на "книгу" от ребят из DeepMind, они проделали невероятную методологическую работу. И выпустили онлайн-учебник How to Scale Your Model. Центральный предмет книги о том, как учить трансформеры на больших кластерах, арифметику моделей (откуда набегает так много гигабайтов памяти, чтобы сделать один forward pass) и что такое TPU/GPU. К каждой главе идет еще набор квизов, чтобы посчитать что-нибудь руками.

Крайне Рекомендую!

https://jax-ml.github.io/scaling-book/

Edit: в комментариях накидали еще полезных материалов!

На ютубе разлетелось видео, в котором стример разбирает якобы слитый собес в Антропик, секция кодинг, на позицию Senior AI engineering, Inference team.

Смотреть тут
Пост на блайнде

Слить такое в сеть мог только сам кандидат. Учитывая, что интервью он прошел, объективно, плохо (для человека с позиционированием себя как 10+ лет опыта разработки на c++ очень плохо), зачем такое выкладывать не очень понятно. Только для пиара. Но его оригинал я не нашел, кстати.

Так что воспринимать контент стоит в любом случае осторожно, с долей скептицизма.

В комментариях к видео (и посту здесь в тг!) пишут, что действительно такой раунд и формат, и задача имеют место быть.

Задача кажется не очень сложная. Конвертировать стак трейс в вектор событий. Что-то на уровне между литкодом и повседневным программированием. Разобраться (не так как кандидат) и решить за час точно можно.

В конце интервью замечательный диалог:

кандидат: How do you compromise speed for safety?

интервьюер: We never compromise on safety.

Сильно.

Бодро влетаем в новый год. Сегодня про Claude Code Skills.

Пару месяцев назад Антропики добавили концепцию Agent Skills

Skills, если по-простому, это папки с SKILLS.md и любыми вспомогательными файлами/скриптами, которые агент может по необходимости подтягивать в контекст и использовать как «встроенный опыт».

Преимуществ несколько:

1) переиспользуемый контекст. Вы, как пользователь Claude Code, можете создать свои кастомные скиллы и переиспользовать в проекте / внутри организации

2) более эффективное использование контекстного окна LLM. Содержимое навыка будет загружено в контекст модели только если она решит, что уместно использовать скилл, а не будет таскать всю инфу о нем постоянно.

3) открытая экосистема, которая будет расширяться за счет опен соурса и самих Антропиков.

Экосистема действительно разрастается. Вот, например, всеми любимый Hugging Face опубликовали серию своих SKILLS, написанных вручную, чтобы обучить агента файн-тюнить модели (SFT, GRPO, DPO). По итогу это набор гайдлайнов о том, какой инстанс брать для файн-тюна в зависимости от размера модели, как провалидировать, что данные в правильном формате, и так далее.

Ссылка.

А еще, энтузиасты собрали интересный проект – Skills Marketplace. Соскрапили 44K skills с github и прикрутили поисковик. Может быть полезно, если что-то ищете специфичное под фреймворк.

Я на практике пока что успел поиграть с несколькими официальными скиллами от самих Антропиков. Например, с гайдлайнами для дизайна фронтендов.

Из интересного, это то что подключение скилла консистенто запускает у Claude Code режим планирования, в котором он у меня распрашивает, какой веб-стэк я хочу использовать. Без подключенного скилла же, регулярно улетает в поделки на plain HTML/CSS/JS.

Интересно, видно что будет расти и дальше. Пользуемся. 👍

А в финальном посте года немного рефлексии по итогам полугода работы в стартапе.

О скорости перемен

Полгода назад ушел из биг теха ловить счастье делать pre-PMF стартап (про первый месяц писал тут). Компания без продукта, но с большим раундом (фаундер уже продал юникорна) в эпоху AI трансформаций == постоянный пивот в новое направление.

Начинали с фреймворка про Spec Driven Development, а сейчас делаем платформу, на которой можно измерять перформанс coding-агентов с разных сторон: насколько хорошо они справляются с задачами в репозитории, умеют ли писать идиоматически приемлемый код (рассказывал о бенчмарке тут). Плюс разные фишки вокруг этого: автогенерация документации, сравнение с другими агентами, context engineering.

После биг теха было сложно привыкнуть к тому, что каждые месяц-два могут выбрасываться не просто идеи и прототипы (там то мы следовали принципу Disagree and Commit 😑), а целое видение компании. И что нужно регулярно погружаться в ресерч совсем новых тем.

Слоган года, который я постоянно слышал от фаундеров стартапов: Побеждают те, у кого хватает ресурсов, чтобы сделать еще один пивот.

Про агентов и программирование

Эволюция профессии происходит стремительно. Это невозможно отрицать.

Еще в начале лета я был плотно вовлечен в написание кода: задаешь направление, а умные IDE помогают. Автокомплитят или реализуют логику на уровне файла. Но почти всегда с правками, потому что что-то не совсем то.

Точка перелома случилась примерно с Sonnet 4.5, когда я закоммитил 500+ строк кода.
В проект, который вижу чуть ли не в первый раз и понимаю в основном на уровне бизнес-логики.
Нужно было срочно сделать конкретную фичу.
Запускаешь и работает как надо.
И выглядит адекватно.
Так оно и было смерджено.

А дальше понеслось. Код руками я почти перестал писать. Все время уходит на оркестрацию агентов, продумывание идей, эксперименты с новыми фичами (типа skills у Claude Code), ведение тг-канала. Короче, агентам аутсорсишь исполнение, а сам занимаешься самым интересным – размышлением.

Имхо: без human in the loop на дистанции все равно получается разваливающийся нейрослоп. Но это временно.

Еще одна мысль, на которой себя поймал. Да, прорывы в кодогенерации привели к массовым сокращениям, заменив многие роли (например, чистых фронтендеров). Но при этом тот же прогресс создал и огромное количество новых возможностей: кучу стартапов (включая тот, где работаю и я), позиции вроде Agents Developer, AI Engineer и т.д.

В заключение

Следующий год, думаю, будет еще более интересным и насыщенным: больше открытий, релизов новых моделей, роста адопшена и безумных сделок по покупке компаний.

В таком мире особенно важно не прекращать учиться, качать новые скиллы и заботиться о здоровье (особенно ментальном!).

Спасибо, что читаете!

С Новым годом! 🥂🎄🍪

Год подходит к концу, поэтому самое время подводить итоги.

В этом посте разбираю одну из центральных тем блога в этом году: собеседования на ML/Research роли.

⚫️В первой половине года я много собеседовал и понял, что хочется делиться тем, что может помочь соискателям. Так появились эти тексты. Они разные по формату и теме, все субъективные и основаны на личном опыте. А теплые сообщения в личку о пользе текстов только мотивируют стараться ✨

Типы вопросов на собеседованиях про Трансформеры
Подборка ресурсов для изучения RL в контексте LLM
Лонгрид ML Breadth Interview Deep Dive

Как готовиться к Coding Interview
Как готовиться к ML Design Interview
Как готовиться к ML Depth Interview

Рисерч стажировки в биг техе. Часть 1. Как попасть на собеседование
Рисерч стажировки в биг техе. Часть 2. Структура Интервью

⚫️Потом я оказался по другую сторону и начал собеседоваться сам. Собесы – это во многом рандом, поэтому любая информация помогает хоть немного увеличить шансы в этой лотерее. А реальные отзывы других людей так тем более. Я начал собирать истории подписчиков канала и делиться ими здесь. В итоге получилась солидная коллекция интервью-историй за 2025 год.

Все отзывы можно найти по тегу #интервью. А здесь оставлю ссылки на истории в зарубежные компании:

🌐Research Engineer в Google DeepMind
🍏Senior ML Engineer в Apple Music
💻Performance Engineer в Nvidia, Munich
💻OpenAI, Solutions Architect, Generative AI Deployment, London
Ⓜ️ Senior ML Engineer в Meta
🖥 Research Fellowship в Anthropic
🛒Applied Scientist, Amazon
🎧 Senior DL Engineer в Spotify, Personalization, London

Senior ML Engineer в Waymo, Perception Team, California
Solutions Architect в ByteDance, Дубай.
VP of AI ML в J.P. Morgan Chase, London
AI Engineer в Mistral.AI

🔥 Буду рад если поддержите пост репостами или поделитесь с друзьями. И забирайте себе в коллекцию, если готовитесь к новому приключению в следующем году!

Паровые двигатели изобрели в 1700 году. С тех пор их эффективность неизменно росла.

Самый популярный вид транспорта того времени – лошади. И что интересно: первые 120 лет прогресса паровых двигателей никак не повлияли на численность лошадей в США.

А затем произошло резкое изменение. В период примерно с 1930 по 1950 годы около 90% лошадей в Штатах исчезло. К началу нулевых количество лошадей на семейство стало близким к нулю.

Прогресс паровых двигателей был плавным. Но скачок в их эффективности, и как следствие, полный отказ от лошадей оказался стремительным.

К чему вообще здесь лошади? Думаю, параллель с развитием AI-технологий и автоматизацией разных отраслей, включая разработку, углядеть нетрудно.

Один из ресёрчеров из фаундинг-команды Anthropic, Andy Jones, как раз пишет об этом у себя в блоге:
https://andyljones.com/posts/horses.html

Он подкрепляет историческую аналогию личным опытом. В 2024 году, ещё до выхода Claude Sonnet 3.5, значительная часть его работы заключалась в онбординге новых сотрудников и ответах на их вопросы, порядка 4000 вопросов в месяц.
К декабрю их доля заметно сократилась. А ещё через шесть месяцев 80% этой рутины было автоматизировано. В итоге появилась система, которая в сотни раз дешевле человека и легко масштабируется.

На такой ноте заметка заканчивается.

Но в жизни Andy Jones большой AI-евангелист. Коллега по работе училась вместе с ним в Эдинбургском университете, так что была редкая возможность познакомиться ближе. В жизни он с юмором сочетает мысли о невероятной скорости прогресса и неизбежной автоматизации профессий с абсолютной глупостью моделей в некоторых вещах. Одни технологии и профессии уйдут, но придут новые.

Прогресс может быть плавным. Но трансформация стремительной.

Открыл для себя в этом году Баку. Поездкой очень доволен.

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

По моим впечатлениям город интересно балансирует между высокими стеклянными (и довольно однообразными) бизнес застройками в духе любого мегаполиса (Лондон, Дубай, с поправкой на масштаб) и вниманием к истории, природе и винтажу. Старый город и нагорный парк как отдельные шедевры.

И конечно еда! Было очень вкусно. Я обожаю всякую выпечку и пирожки, поэтому каждый день пробовал новые кутабы (азербайджанское ноу-хау, очень тонкие пирожки с начинкой на выбор), хачапури, лаваши.

В общем, и истории много, и красивых мест, и вкусная еда.

💻OpenAI, Solutions Architect, Generative AI Deployment, London. Отзыв на Интервью.

Сегодня в историях про собесы уникальное пополнение. Рассказа про OpenAI.

Буду рад видеть свежие от читателей, гугл форма тут.
Все отзывы по тегу #интервью


➡ Ник автора в тг - N/A
➡ Название компании, можете указать ссылку или коротко описать что за место - OpenAI
➡Расскажите про свой бэкграунд - Senior MLE at Microsoft (customer solutions), 7 лет SWE, 7 лет ML/DS. Так или иначе с кастомерами. В целом хотелось меньше кастомеров и больше глубоких сложных задач.

➡ Как подались на вакансию - Написал сам рекрутер в LinkedIn (позиции тогда публично не было - была похожая в US)

➡ Субъективно Сложность процесса по 10 бальной шкале - 5
➡Когда начали процесс - октябрь 2025
➡Когда закончили процесс - декабрь 2025


➡Позиция, на которую собеседовались - Solutions Architect, Strategics (Post Sales) (https://openai.com/careers/solutions-architect-generative-ai-deployment-london-uk/).

Дизайнить и деливерить LLM-based солюшны в EMEA, общаться со стейкхолдерами на стороне кастомера, с сейлзами, продукт-тимой и рисёрчерами.

До 3 дней в неделю могли быть из офиса клиента (по словам рекрутера), скорее 1-2 дня по словам Hiring Manager (и что компенсация тревела щедрая)

➡Грейд (если известно) - N/A
➡Локация вакансии - London, UK

🔥 Расскажите про этапы собеседований

1) Созвон с рекрутером

2) Screening с менеджером (30 мин) - опыт, технологии, ожидания от позиции

3) Техническое задание на кодинг (домашнее на 5 business days) - выслали сразу после менеджера, а у меня отпуск на 2 недели был на следующий день, предложила заменить задачу по возвращении - сказали норм, когда вернусь.

Сделать рабочий солюшн, диаграмму, документацию, next steps.
Тут я начала на 2 недели позже, дня 3 бизнесовых потратила, кодила 1.5 вечера, потом они неделю проверяли.

4) 4 интервью пачкой (в 1 день должны были, но одно перенеслось):

- Partnering with Sales (30 мин) - рассказать про разные конфликтные ситуации, когда продали что-то, а тебе делать, другие behavioural аспекты

- Deep Dive with Manager (30 мин) - опыт, cultural fit, про миссию, про мои цели

- Case (Being a Solutions Architect) (45 мин) - прошли по задаче от нечёткого определения задачи (LLM-based солюшн) через мои вопросы и их уточнения до имплементации, evaluation, это было парное интервью - второй интервьюер учился-шедоуил.

- Coffee Chat with peer (тут мне обещали, что я буду задавать вопросы, но чувак - очень классный! - кажется, что-то перепутал и распрашивал меня всякое техническое, на мои осталось 5 минут).

Отказ и фидбек дали через ещё неделю.

⏺ Что понравилось:

Все, с кем разговаривала - приятные, профессиональные интервьюеры, быстрые ответы на вопросы от них и координатора, минимальный стресс, фидбек-сессия с HR


⏺Что не понравилось:

Несоответсвие Coffee Chat объявленному наполнению, я думала я перепутала (и на стрессе где-то тупила явно), но потом извинились, сказали, интервьюер увлёкся вот и.

Довольно много времени заняло (у меня очень мало опыта в интервью, впрочем - третье в жизни, может, это норма)

Кредиты на тех. задание начислить не смогли ("что-то сломалось"), просили купить самой и зареимбёрсить - напомнила об этом после отказа, тут же выслали ссылку, ещё через 5 дней заревьюили и выслали.

➡ Итоги собеседования, например оффер или отказ, или что-то другое:
Отказ. Без детального фидбека, но с созвоном с HR. Посчитали, что ответы по case study для общения с бизнес-кастомерами должны быть почётче, а технический опыт отличный.
Думаю, что я не выказывала сильного энтузиазма работать с кучей заказчиков, да и напрямую спрашивала про транзишны внутри компании и возможность исходно работать над более сложными задачами, чтобы туда двигаться.
Обещали стукнуться, если будут такие позиции и просили меня им тоже писать, если увижу что-то (подписаться на алёрты нет опции).

➡ Информация про Total Compensation: 190k £ Base + Equities


@max_dot_sh

📱 канал AI Engineer

В посте выше я ссылался на доклад с AIE митапа. Так вот, у них есть болшой YT канал с очень годным контентом от передовых лаб и AI стартапов.

Канал тут.

Выступления все в среднем по 20 минут и крайне прикладные. Тут вы никогда не увидите формул, глубоких деталей методов или какие-то строгие специфичные eval-ы. Но можно зацепить много идей, посмотреть что делают в индустрии, набраться ключевых слов и ссылок и потом пойти копать дальше.

Большой дисклеймер: Да, крутого контента много, но еще больше бесполезного маркетингового мусора, которое слово в слово дублирует какой-нибудь релиз. Благо, видео короткие, можно быстро отсеять.

Мне, например, очень понравились доклады про разный RL, многие совсем свежие:

1. OpenAI про Agent RL, во второй части доклада рассказывают про пилоты с реальными кастомерами
2. Про эффективный RL, где боттленеки обучения, где простаивают GPU
3. про обучение своих агентов с помощью RL, вот тут вообще кайфовый case study от сбора данных до reward-hacking-ов

Happy Learning!

—
кстати, митапы проходят не только в SF, но и в других локациях. В этом году состоялся первый в Париже и несколько прошло в Лондоне. Здесь все скромнее по масштабу, но все равно очень интересно. Запланировал выступить в следующем году на таком.

#образование

Послушал очень плотное по контенту и интересное для размышлений выступление с недавнего AI Engineer митапа от Dexter Horthy (фаундер YC стартапа, много выступает с докладами про Context Engineering для кодинг агентов)

Смотреть тут

⚫️Одна мысль про так называемую "dumb zone". Контекстное окно агента (Claude Code, Codex, ...) стоит держать заполненным только до определенного размера. В докладе автор эмперически говорит о 40%. Как только контекстное окно переваливает через этот рубеж, агент быстро начинает тупеть.

Учитывая MCP инструменты, кастомные правила, всякие манифесты типа CLAUDE.md и входы/выходы размышлений агентов, окно заполняется очень быстро.

Один способ побороть это, делегировать выполнение кусков задачи другим агентам (так называемые sub agents). Они будут выполнять задачу от главного агента, в своей копии контекстного окна, никак не засоряя основное, по итогу работы вернув в главное контекстное окно сжатое эффективное представление.

Другой подход – это agent skills, который активно продвигают Антропики.

⚫️Автор продвигает подход RPI (Research Planing Implementation) суть которого в том, что агент должен решать задачу (особенно если она сложная и подразумевает работу в уже существующей кодовой базе) в несколько этапов. Каждый этап может выполняться отдельным агентом или серией агентов. Исходя из названия подхода, в целом понятно, что должен делать каждый агент: делать поиск по кодовой базе в поисках актуального контекста, суммаризировать все это в план действий, а затем уже переходить к написанию кода через план.

Предлагается еще ввести Human Review на каждой из стадий. Потому что процесс принятия решений пока еще нельзя полностью аутсорсить агентам. Ревью так или иначе нужно. Автор подкрепляет свою ветку красивыми диаграммами вида: Одна плохая строчка в CLAUDE.md -> десятки тысяч плохого кода; Плохой рисерч агента –> потенциально сотни строк плохого кода; Плохой план исполнения -> потенциально десятки строк плохого кода.

⚫️Ну и напоследок, из-за того, что сломать агента на масштабе больших рефакторингов и кодовых изменений крайне просто, у инженеров разной сеньорности со временем формируется полярное отношение к AI агентам. Пока VP of Eng ломают голову, как его внедрять на уровне организаций и плавно переходят к ненависти AI технологий (неоднократно слышал такой фидбэк лично от разных матерых разрабов), более джуновые инженеры, оперирующие на уровне фичей, обожают все новые технологии, потому что это бустит продуктивность.

Solutions Architect в ByteDance, Дубай. Отзыв на Интервью.

Новая история про собеседования, самое то для пятницы.
Буду рад видеть свежие от читателей, гугл форма тут.
Все отзывы по тегу #интервью

спойлер: тотал комп в оффере отличный, дочитайте до конца

➡ Ник автора в тг - N/A
➡ Название компании, можете указать ссылку или коротко описать что за место - ByteDance
➡Расскажите про свой бэкграунд - 7YOE, Engineering & Solution Architecture (стартапы), никаких FAANG'ов в резюме. Своя компания Engineering & Technical Consulting & Solution Architecture (6 years), AI Content generation & workflows (1 year) + продажа различного софта онлайн.

➡ Как подались на вакансию - Рекрутер на LinkedIn сам написал (его потом уволили, хех)

➡ Субъективно Сложность процесса по 10 бальной шкале - 7
➡Когда начали процесс - Август 2025
➡Когда закончили процесс - Ноябрь 2025


➡Позиция, на которую собеседовались - Solutions Architect, Enterprise AI, MaaS (models as a service)
➡Грейд (если известно) - N/A, 2-2 или 3-1 скорее всего (от автора канала: в комментариях описали разбивку грейдов)
➡Локация вакансии - Дубай

🔥 Расскажите про этапы собеседований

0 - HR Screening,
1 - Solution Architecture Technical Chat (AI Content generation),
2 - Solution Architecture Technical Interview (Experience assessment and use cases),
3 - Panel interview with Sales and General Manger (Experience assessment and use cases),
4 - Technical Presentation for Sales team and Hiring manager,
5 - Offer and follow-up conversations on expectations (my initiative).

⏺ Что понравилось:
Понравилось, что не было тупых вопросов (типа как Amazon leadership задротство, бррр). Все интервьюверы задавали хорошие глубокие вопросы про GTM. Ожидания проговаривались.
ByteDance - масштабная контора - у них свой большой cloud и свои топ модели (видео, аудио и т.п.) - много клиентов, нужно строить AI солюшны, Models as a service продвигать. В 2026 собираются порвать многих акул рынка.

⏺Что не понравилось:
Был Лондон, а стал Дубай, но решил процесс довести до конца. После раундов часто долго не было фидбека. Оффер высылали неделю.

➡ Итоги собеседования, например оффер или отказ, или что-то другое: Получил оффер. В итоге отказался. Увы, тайминг не подходящий. Нужно быть в ЮК

➡ Информация про Total Compensation: OTE: 260k GBP / year, 180k - base (tax free cash, т.к. Дубай), 5-6 зарплат - бонус (каждый квартал), 10k GBP - стоки (да, смешно). В Дубайских тугриках OTE: ~1.2-1.3M AED (20k GBP в месяц кэшом на руки). Офис 4/1.

@max_dot_sh

Выпустили первый инженерный лонг рид, активно участвовал в создании и всех экспериментах.

Почитать полный текст можно тут.

✍️Пообсуждать, покритиковать или предложить идей в комментариях или в лс – буду очень рад)

На самом деле релизнули его еще несколько недель назад, но только сейчас доехали красивые картинки.

Основная мысль такая. С рассветом агентов и улучшением LLM-ов для кодинга, проблема галлюцинаций или того, что LLM-ка чего то не знает становится менее центральной. Все потому что у агента есть много инструментов найти недостающее знание: 1) посмотреть в исходный код (если работаете с какой-то библиотекой, то агент может просто найти, где она установлена и прочитать код оттуда) 2) поискать в браузере 3) интерактивно повзаимодействовать с библиотекой и в fix-loop парадигме научиться пользоваться библиотекой.

Реальной практической проблемой становится вопрос того, насколько агент эффективно пользуется этой самой библиотекой. Пользуется ли агент ей так, как задумывали авторы? Или вместо использования готового API начинает городить сложные конструкции. Которые формально могут решать задачу. Функционально все будет ок. Функциональная корректность кода – это безумно важно и актуально, никто не отменяет eval-ы про юнит-тесты. Но в реальных приложениях, в продуктовом коде, который пишут разрабы в огромных развитых экосистемах, помимо функциональной корректности нужна еще какая-то валидация на его качество.

Игрушечный пример (модели уровня Opus 4.5 или Sonnet 4.5 справляются, а маленькие могут облажаться). Допустим, вы просите агента реализовать self-attention механимз в PyTorch. Он идёт и вручную пишет функцию со всеми умножениями q, k, v матриц, в духе собеседований. А вот «умный» агент знает, что начиная с версии 2.x в торче существует F.scaled_dot_product_attention, который делает всё в одну строку.

Такой пример подсвечивает проблемы с идиоматичным использованием фреймворков. Вот в блоге и оценивали масштаб такого эффекта.

* Собрали 270 разных опенсоурсных реп разных лет, от очень старых до новых.
* Нагенерировали на основе исходного кода репозиториев разных coding exercises – задач, в которых агенту нужно было реализовать некоторую логику используя конкретную библиотеку
* Дали разным агентам (cursor, claude code) решать эти задачи
* Оценивали решения с помощью рубрик отдельным агентом-валидатором. Штрафовали за ситуации, когда решение не использовало какой-то метод или паттерн, который ожидался

Посмотрели на результаты в разных разрезах.

Один результат, что лучше модель – лучше качество. Картинка 1 про перформанс разных моделей Антропика.

Другой интересный разрез – это перформанс в зависимости от даты релиза библиотеки. Агенты довольно плохо перформят на старых репах и на супер новых, Картинка 2. По популярности репозитория точно такой же тренд – чем больше форков, тем выше скор. Оно и понятно: такие репы являются основой для трейн данных любой LLM-ки.

Отдельно в блоге еще затронули пункт про то, а как это можно улучшить. Мы предлагаем способ в виде Спек – таких сжатых документов, оптимизированных под то, что они пойдут в контекстное окно модели, чтобы на ходу обучить ее работе с репой. Спеки содержат примеры как работать с API репы, какие best practices и основные детали. Короче по задумке как context7, но построено на других принципах.

Все coding challenges и рубрики для оценки выложили, в блоке есть ссылка.

Applied Scientist L5 в🛒Amazon. Отзыв на Интервью.

Пополняем копилку свежей историей. Буду рад видеть новые от читателей, гугл форма тут.
Другие по тегу #интервью

➡ Ник автора в тг - N/A
➡ Название компании, можете указать ссылку или коротко описать что за место - Amazon
➡Расскажите про свой бэкграунд - в этом году закончила ICL, PhD степень, машинный перевод, ищу работу. До этого только летние стажировки и подработки между учебой. IBM, Intel, McKinsey.

➡ Как подались на вакансию - сама через вакансию в Linkedin

➡ Субъективно Сложность процесса по 10 бальной шкале - 7
➡Когда начали процесс - сентябрь 25
➡Когда закончили процесс - октябрь 25


➡Позиция, на которую собеседовались - Applied Scientist, AGI команда
➡Грейд (если известно) - L5
➡Локация вакансии - Лондон / Кэмбридж

🔥 Расскажите про этапы собеседований

Virtual Screening

Раунд 1. Сначала дали leetcode style задачу на поиск элементов в матрице. Дословно как здесь: https://leetcode.com/problems/search-a-2d-matrix/description/. Линейное решение пришло быстро, а с бинарным поиском всё получилось не идеально в плане реализации. Интервьюер, кажется, был больше заинтересован в том, что я правильно проговариваю логику, чем в самом коде и краевых случаях. Ушло минут 35-40. Далее обсуждали LP-вопрос про мой опыт работы в исследовательской команде. У меня был сильный кейс, потому что я немного поработала и в индустрии, и в академии, и использовала этот опыт как пример на интервью. Похоже, это впечатлило.

Раунд 2. На этом раунде всё было наоборот: сначала минут 25-30 обсуждали LP-принципы, затем были разнообразные вопросы по классическим понятиям машинного обучения: gradient descent и его виды, свёртки, случайные величины, закон больших чисел. Не везде у меня были хорошие ответы, интервьюер просто шёл дальше, выглядело больше как викторина. Видимо, набрала достаточно галочек, чтобы позвали на он-сайт.


Virtual On-site

Раунд 1. Behavioral Interview с нанимающим менеджером.

Раунд 2. Bar Raiser Interview. Раунд похож на скриниг. В этот раз фокус на оценку качества моделей, A/B тесты. Как бы я проектировала вывод в продакшн новой болталки, какие оффлайн и онлайн метрики использовала. Было очень круто поговорить с Principal Scientist-ом.

Раунд 3. Лит код. Первая задача на дизайн структуры, написать функции для обхода графа. Потом применить их для конкретной задачи. Дали модификацию вот такой задачи: https://leetcode.com/problems/number-of-islands/description/.

Раунд 4. ML Дизайн. Самая сложная для меня секция, потому что такого опыта у меня никогда не было. Интервьюеры дали задачу приближенную к их работе: дизайн Text-To-Speech системы для озвучивания аудио книг. А именно построить решение для multi voice narration. Покрыли такие пункты: какие данные собирать, как делать разметку, как оценивать систему, которая генерирует сразу несколько голосов, какие есть модели. Я никогда не работала над TTS, поэтому было сложно в целом рассуждать про архитектурные подходы, а уж тем более как в одной модели смешать многоголосый синтез. Интервьюеры были очень поддерживающими, и помогали вести диалог в тех частях, где я буксовала. В итоге раунд, который мне казался самым страшным превратился в комфортную беседу. Блеснуть, конечно не вышло, из-за специфики задачи, но в одной части разговора речь зашла про языки за пределами английского и удалось применить опыт с машинным переводом, что кажется очень зашло.


➡ Итоги собеседования, например оффер или отказ, или что-то другое: В течение недели после собеседования поставили звонок с рекрутером. Сказали, что до уровня L5 не дотягиваю и дали конструктивный фидбэк, что улучшить. При этом не хотят делать reject, и готовы нанять на грейд L4 (это скорее джун), либо взять на стажировку на 4-6 месяцев по итогам которой могут дать полноценный оффер на L5. Проблема только в том, что вакансий сейчас нет 🤷‍♀️, но могут появиться в Q1 2026. Посмотрим, возможно к тому моменту будет уже не актуально.

➡ Информация про Total Compensation: N/A

@max_dot_sh