Media is too big
VIEW IN TELEGRAM
Gemini 3 Pro доступна в Gemini CLI.
С сегодняшним релизом Gemini 3, тут же релизнули и интеграцию в гугловсокго кодинг агента.
Модель доступна подписчикам Google AI Ultra или тем, кто пользуется через платный API: Gemini API/ Vertex API . Все остальные, включая бесплатных юзеров, могут пока встать в waitlist
В посте с анонсом обращают внимание на такие фичи:
– улучшенные способности в генерации красивых UI-интерфейсов. Старая модель безумно страдала в этом аспекте.
- генерация 3D сцен.Прикрепленное видео из поста с анонсом, довольно впечатляюще
– генерация сложных терминальных команд
– генерация аккуратной документации (Гугл на днях тут еще запустил и Code Wiki, сервис для автоматической документации проектов)
– улучшенный ризонинг, требующий работы одновременно с несколькими файлами (старая модель тоже страдала с этим), помощь в дебаге и способность мониторить логи запущенных сервисов, чтобы диагностировать проблемы
Стал ли агент действительно интереснее и полезнее и насколько крутая модель скоро увидим. По тем скудным кодинг бенчмаркам что представлены (terminal bench, SWE Bench, livecodebench) модель не на голову выше других гигантов.
С сегодняшним релизом Gemini 3, тут же релизнули и интеграцию в гугловсокго кодинг агента.
Модель доступна подписчикам Google AI Ultra или тем, кто пользуется через платный API: Gemini API/ Vertex API . Все остальные, включая бесплатных юзеров, могут пока встать в waitlist
В посте с анонсом обращают внимание на такие фичи:
– улучшенные способности в генерации красивых UI-интерфейсов. Старая модель безумно страдала в этом аспекте.
- генерация 3D сцен.Прикрепленное видео из поста с анонсом, довольно впечатляюще
– генерация сложных терминальных команд
– генерация аккуратной документации (Гугл на днях тут еще запустил и Code Wiki, сервис для автоматической документации проектов)
– улучшенный ризонинг, требующий работы одновременно с несколькими файлами (старая модель тоже страдала с этим), помощь в дебаге и способность мониторить логи запущенных сервисов, чтобы диагностировать проблемы
Стал ли агент действительно интереснее и полезнее и насколько крутая модель скоро увидим. По тем скудным кодинг бенчмаркам что представлены (terminal bench, SWE Bench, livecodebench) модель не на голову выше других гигантов.
🔥12⚡6👍4👎1👏1👌1🆒1
Мб пригодится начинающим стартаперам:
http://yandex.ru/aistartup
Критерии участия:
В ногу с трендами ждут проекты про AI
http://yandex.ru/aistartup
Критерии участия:
Вы совершеннолетний студент, аспирант, исследователь или предприниматель
Команда от двух человек, и участники готовы уделять проекту 10–15 часов в неделю
Хотите валидировать свои гипотезы и открыты к обратной связи
У вас технологический проект с подтверждёнными гипотезами или прототипом, TRL 3+
В ногу с трендами ждут проекты про AI
Yandex AI Startup Lab — пространство, где идеи превращаются в реальные продукты
Приходите с технологическими идеями, дорабатывайте их с поддержкой Яндекса и попробуйте получить 3 000 000 рублей на дальнейшее развитие
❤14🔥6👍4⚡1
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
Пополняем копилку свежей историей. Буду рад видеть новые от читателей, гугл форма тут.
Другие по тегу #интервью
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, поэтому было сложно в целом рассуждать про архитектурные подходы, а уж тем более как в одной модели смешать многоголосый синтез. Интервьюеры были очень поддерживающими, и помогали вести диалог в тех частях, где я буксовала. В итоге раунд, который мне казался самым страшным превратился в комфортную беседу. Блеснуть, конечно не вышло, из-за специфики задачи, но в одной части разговора речь зашла про языки за пределами английского и удалось применить опыт с машинным переводом, что кажется очень зашло.
@max_dot_sh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤39🔥13🙏8👏3⚡1🆒1
Выпустили первый инженерный лонг рид, активно участвовал в создании и всех экспериментах.
Почитать полный текст можно тут.
✍️ Пообсуждать, покритиковать или предложить идей в комментариях или в лс – буду очень рад)
На самом деле релизнули его еще несколько недель назад, но только сейчас доехали красивые картинки.
Основная мысль такая. С рассветом агентов и улучшением LLM-ов для кодинга, проблема галлюцинаций или того, что LLM-ка чего то не знает становится менее центральной. Все потому что у агента есть много инструментов найти недостающее знание: 1) посмотреть в исходный код (если работаете с какой-то библиотекой, то агент может просто найти, где она установлена и прочитать код оттуда) 2) поискать в браузере 3) интерактивно повзаимодействовать с библиотекой и в fix-loop парадигме научиться пользоваться библиотекой.
Реальной практической проблемой становится вопрос того, насколько агент эффективно пользуется этой самой библиотекой. Пользуется ли агент ей так, как задумывали авторы? Или вместо использования готового API начинает городить сложные конструкции. Которые формально могут решать задачу. Функционально все будет ок. Функциональная корректность кода – это безумно важно и актуально, никто не отменяет eval-ы про юнит-тесты. Но в реальных приложениях, в продуктовом коде, который пишут разрабы в огромных развитых экосистемах, помимо функциональной корректности нужна еще какая-то валидация на его качество.
Игрушечный пример (модели уровня Opus 4.5 или Sonnet 4.5 справляются, а маленькие могут облажаться). Допустим, вы просите агента реализовать self-attention механимз в PyTorch. Он идёт и вручную пишет функцию со всеми умножениями q, k, v матриц, в духе собеседований. А вот «умный» агент знает, что начиная с версии 2.x в торче существует
Такой пример подсвечивает проблемы с идиоматичным использованием фреймворков. Вот в блоге и оценивали масштаб такого эффекта.
* Собрали 270 разных опенсоурсных реп разных лет, от очень старых до новых.
* Нагенерировали на основе исходного кода репозиториев разных coding exercises – задач, в которых агенту нужно было реализовать некоторую логику используя конкретную библиотеку
* Дали разным агентам (cursor, claude code) решать эти задачи
* Оценивали решения с помощью рубрик отдельным агентом-валидатором. Штрафовали за ситуации, когда решение не использовало какой-то метод или паттерн, который ожидался
Посмотрели на результаты в разных разрезах.
Один результат, что лучше модель – лучше качество. Картинка 1 про перформанс разных моделей Антропика.
Другой интересный разрез – это перформанс в зависимости от даты релиза библиотеки. Агенты довольно плохо перформят на старых репах и на супер новых, Картинка 2. По популярности репозитория точно такой же тренд – чем больше форков, тем выше скор. Оно и понятно: такие репы являются основой для трейн данных любой LLM-ки.
Отдельно в блоге еще затронули пункт про то, а как это можно улучшить. Мы предлагаем способ в виде Спек – таких сжатых документов, оптимизированных под то, что они пойдут в контекстное окно модели, чтобы на ходу обучить ее работе с репой. Спеки содержат примеры как работать с API репы, какие best practices и основные детали. Короче по задумке как context7, но построено на других принципах.
Все coding challenges и рубрики для оценки выложили, в блоке есть ссылка.
Почитать полный текст можно тут.
На самом деле релизнули его еще несколько недель назад, но только сейчас доехали красивые картинки.
Основная мысль такая. С рассветом агентов и улучшением 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 и рубрики для оценки выложили, в блоке есть ссылка.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5❤17🔥13👍6🤓2🆒1
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
Новая история про собеседования, самое то для пятницы.
Буду рад видеть свежие от читателей, гугл форма тут.
Все отзывы по тегу #интервью
спойлер: тотал комп в оффере отличный, дочитайте до конца
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 собираются порвать многих акул рынка.
Был Лондон, а стал Дубай, но решил процесс довести до конца. После раундов часто долго не было фидбека. Оффер высылали неделю.
@max_dot_sh
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥22🤯11❤4👍3🆒1
Послушал очень плотное по контенту и интересное для размышлений выступление с недавнего 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 технологий (неоднократно слышал такой фидбэк лично от разных матерых разрабов), более джуновые инженеры, оперирующие на уровне фичей, обожают все новые технологии, потому что это бустит продуктивность.
Смотреть тут
Учитывая MCP инструменты, кастомные правила, всякие манифесты типа CLAUDE.md и входы/выходы размышлений агентов, окно заполняется очень быстро.
Один способ побороть это, делегировать выполнение кусков задачи другим агентам (так называемые sub agents). Они будут выполнять задачу от главного агента, в своей копии контекстного окна, никак не засоряя основное, по итогу работы вернув в главное контекстное окно сжатое эффективное представление.
Другой подход – это agent skills, который активно продвигают Антропики.
Предлагается еще ввести Human Review на каждой из стадий. Потому что процесс принятия решений пока еще нельзя полностью аутсорсить агентам. Ревью так или иначе нужно. Автор подкрепляет свою ветку красивыми диаграммами вида: Одна плохая строчка в CLAUDE.md -> десятки тысяч плохого кода; Плохой рисерч агента –> потенциально сотни строк плохого кода; Плохой план исполнения -> потенциально десятки строк плохого кода.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍12❤7🆒1
В посте выше я ссылался на доклад с AIE митапа. Так вот, у них есть болшой YT канал с очень годным контентом от передовых лаб и AI стартапов.
Канал тут.
Выступления все в среднем по 20 минут и крайне прикладные. Тут вы никогда не увидите формул, глубоких деталей методов или какие-то строгие специфичные eval-ы. Но можно зацепить много идей, посмотреть что делают в индустрии, набраться ключевых слов и ссылок и потом пойти копать дальше.
Большой дисклеймер: Да, крутого контента много, но еще больше бесполезного маркетингового мусора, которое слово в слово дублирует какой-нибудь релиз. Благо, видео короткие, можно быстро отсеять.
Мне, например, очень понравились доклады про разный RL, многие совсем свежие:
1. OpenAI про Agent RL, во второй части доклада рассказывают про пилоты с реальными кастомерами
2. Про эффективный RL, где боттленеки обучения, где простаивают GPU
3. про обучение своих агентов с помощью RL, вот тут вообще кайфовый case study от сбора данных до reward-hacking-ов
Happy Learning!
—
кстати, митапы проходят не только в SF, но и в других локациях. В этом году состоялся первый в Париже и несколько прошло в Лондоне. Здесь все скромнее по масштабу, но все равно очень интересно. Запланировал выступить в следующем году на таком.
#образование
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Agent Reinforcement Fine Tuning – Will Hang & Cathy Zhou, OpenAI
Deep dive into OpenAI's approach to reinforcement fine-tuning for code models.
https://x.com/willhang_
https://x.com/cathyzhou
AIE is coming to London and SF! see dates and sign up to be notified of sponsorships, CFPs, and tickets: https://ai.engineer
…
https://x.com/willhang_
https://x.com/cathyzhou
AIE is coming to London and SF! see dates and sign up to be notified of sponsorships, CFPs, and tickets: https://ai.engineer
…
4🔥13👍7❤5⚡2😍1🆒1
Сегодня в историях про собесы уникальное пополнение. Рассказа про OpenAI.
Буду рад видеть свежие от читателей, гугл форма тут.
Все отзывы по тегу #интервью
Дизайнить и деливерить LLM-based солюшны в EMEA, общаться со стейкхолдерами на стороне кастомера, с сейлзами, продукт-тимой и рисёрчерами.
До 3 дней в неделю могли быть из офиса клиента (по словам рекрутера), скорее 1-2 дня по словам Hiring Manager (и что компенсация тревела щедрая)
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 для общения с бизнес-кастомерами должны быть почётче, а технический опыт отличный.
Думаю, что я не выказывала сильного энтузиазма работать с кучей заказчиков, да и напрямую спрашивала про транзишны внутри компании и возможность исходно работать над более сложными задачами, чтобы туда двигаться.
Обещали стукнуться, если будут такие позиции и просили меня им тоже писать, если увижу что-то (подписаться на алёрты нет опции).
@max_dot_sh
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍14❤6⚡2👻1
Открыл для себя в этом году Баку. Поездкой очень доволен.
Декабрь не самый сезон для тура сюда, постоянные ветра и в целом серое небо. Но это не помешало получить кучу удовольствия от города.
По моим впечатлениям город интересно балансирует между высокими стеклянными (и довольно однообразными) бизнес застройками в духе любого мегаполиса (Лондон, Дубай, с поправкой на масштаб) и вниманием к истории, природе и винтажу. Старый город и нагорный парк как отдельные шедевры.
И конечно еда! Было очень вкусно. Я обожаю всякую выпечку и пирожки, поэтому каждый день пробовал новые кутабы (азербайджанское ноу-хау, очень тонкие пирожки с начинкой на выбор), хачапури, лаваши.
В общем, и истории много, и красивых мест, и вкусная еда.
Декабрь не самый сезон для тура сюда, постоянные ветра и в целом серое небо. Но это не помешало получить кучу удовольствия от города.
По моим впечатлениям город интересно балансирует между высокими стеклянными (и довольно однообразными) бизнес застройками в духе любого мегаполиса (Лондон, Дубай, с поправкой на масштаб) и вниманием к истории, природе и винтажу. Старый город и нагорный парк как отдельные шедевры.
И конечно еда! Было очень вкусно. Я обожаю всякую выпечку и пирожки, поэтому каждый день пробовал новые кутабы (азербайджанское ноу-хау, очень тонкие пирожки с начинкой на выбор), хачапури, лаваши.
В общем, и истории много, и красивых мест, и вкусная еда.
❤32👍7🔥5🤩2🆒1
Паровые двигатели изобрели в 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-евангелист. Коллега по работе училась вместе с ним в Эдинбургском университете, так что была редкая возможность познакомиться ближе. В жизни он с юмором сочетает мысли о невероятной скорости прогресса и неизбежной автоматизации профессий с абсолютной глупостью моделей в некоторых вещах. Одни технологии и профессии уйдут, но придут новые.
Прогресс может быть плавным. Но трансформация стремительной.
Самый популярный вид транспорта того времени – лошади. И что интересно: первые 120 лет прогресса паровых двигателей никак не повлияли на численность лошадей в США.
А затем произошло резкое изменение. В период примерно с 1930 по 1950 годы около 90% лошадей в Штатах исчезло. К началу нулевых количество лошадей на семейство стало близким к нулю.
Прогресс паровых двигателей был плавным. Но скачок в их эффективности, и как следствие, полный отказ от лошадей оказался стремительным.
К чему вообще здесь лошади? Думаю, параллель с развитием AI-технологий и автоматизацией разных отраслей, включая разработку, углядеть нетрудно.
Один из ресёрчеров из фаундинг-команды Anthropic, Andy Jones, как раз пишет об этом у себя в блоге:
https://andyljones.com/posts/horses.html
Он подкрепляет историческую аналогию личным опытом. В 2024 году, ещё до выхода Claude Sonnet 3.5, значительная часть его работы заключалась в онбординге новых сотрудников и ответах на их вопросы, порядка 4000 вопросов в месяц.
К декабрю их доля заметно сократилась. А ещё через шесть месяцев 80% этой рутины было автоматизировано. В итоге появилась система, которая в сотни раз дешевле человека и легко масштабируется.
На такой ноте заметка заканчивается.
Но в жизни Andy Jones большой AI-евангелист. Коллега по работе училась вместе с ним в Эдинбургском университете, так что была редкая возможность познакомиться ближе. В жизни он с юмором сочетает мысли о невероятной скорости прогресса и неизбежной автоматизации профессий с абсолютной глупостью моделей в некоторых вещах. Одни технологии и профессии уйдут, но придут новые.
Прогресс может быть плавным. Но трансформация стремительной.
Andyljones
Horses
AI progress is steady. Human equivalence is sudden.
🔥16👍7🤔4😁1
Год подходит к концу, поэтому самое время подводить итоги.
В этом посте разбираю одну из центральных тем блога в этом году: собеседования на 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
🔥 Буду рад если поддержите пост репостами или поделитесь с друзьями. И забирайте себе в коллекцию, если готовитесь к новому приключению в следующем году!
В этом посте разбираю одну из центральных тем блога в этом году: собеседования на ML/Research роли.
Типы вопросов на собеседованиях про Трансформеры
Подборка ресурсов для изучения RL в контексте LLM
Лонгрид ML Breadth Interview Deep Dive
Как готовиться к Coding Interview
Как готовиться к ML Design Interview
Как готовиться к ML Depth Interview
Рисерч стажировки в биг техе. Часть 1. Как попасть на собеседование
Рисерч стажировки в биг техе. Часть 2. Структура Интервью
Все отзывы можно найти по тегу #интервью. А здесь оставлю ссылки на истории в зарубежные компании:
🍏Senior ML Engineer в Apple Music
Senior ML Engineer в Waymo, Perception Team, California
Solutions Architect в ByteDance, Дубай.
VP of AI ML в J.P. Morgan Chase, London
AI Engineer в Mistral.AI
Please open Telegram to view this post
VIEW IN TELEGRAM
13👍48❤16🎄9🔥5⚡4🆒1