🤝 Как нанимают в Cursor, Cognition и Replit – и почему там больше нет LeetCode. Попался на глаза разбор от Business Insider про найм в топовых AI coding стартапах – и это прямо любопытная иллюстрация того, как рынок труда для инженеров переворачивается вслед за самим продуктом. К тому же еще и статья без paywall. 1/ Семь раундов и LeetCode – в прошлом: ▪️Cursor и Kilo (портфель General Catalyst) заменили классические циклы собеседований на многодневные unpaid work trials и недельные буткемпы. ▪️Cursor настолько известен своими pilot-трайлами, что это стало частью репутации компании в Кремниевой долине. ▪️Логика в следующем – в мире, где AI пишет код, важнее посмотреть, как кандидат реально работает, а не как он решает абстрактные задачки на доске. 2/ Охота идет не через джоб-борды: ▪️CEO Cursor Майкл Труэлл лично сканирует X и GitHub в поисках неприметных на первый взгляд инженеров, бывших фаундеров и людей из tech стартапов типа Notion и Figma. ▪️В Replit есть отдельный Slack-канал Talent Spot, куда сотрудники скидывают людей, с которыми познакомились на конференции или в Linkedin – даже если знакомство поверхностное. ▪️CEO Base44 Маор Шломо охотится за теми, кто просто выкладывает свои проекты в опенсорс. 3/ Самое неочевидное – новый вопрос на техническом интервью: ▪️В Rocket (портфель Accel) первый вопрос кандидату – сколько токенов ты тратишь в неделю на работе и в личных проектах. ▪️Логика COO компании жесткая: не жжешь токены в бешеных объемах – значит, недостаточно экспериментируешь и не угонишься за скоростью команды. ▪️Заодно спрашивают, можно ли звонить кандидату в 3 ночи, если что-то сломалось – ищут не просто скилл, а "founder mode" даже у рядовых сотрудников. 🔹Тут момент только в том, что tokenmaxxing уже не особо в тренде, так что неясно, сейчас в моменте ответ по токенам должен быть "много" или "мало" – хотя скорее ответ должен быть "адекватно". 4/ AI на интервью не запрещают, а требуют: ▪️В Cognition кандидатам прямо говорят использовать AI-инструменты при выполнении тестового задания – иначе это как "просить ребенка сдать математику без калькулятора". ▪️В Base44 просят кандидата построить продукт вместе с интервьюером прямо на созвоне, за час. Друзья, а вы такое замечаете? Может быть, вы сами стали нанимать как-то по-другому? Если есть, что сказать – делитесь в комментариях. 👉 Ссылка на статью: https://www.businessinsider.com/recruiting-practices-ai-vibe-coding-startups-cognition-cursor-replit-interview-2026-7 @proVenture #ai #howtovc

Архитектурные практики Прошло чуть больше полугода, как я перестал писать код руками, за редкими исключениями. Но несмотря на это, я просматриваю его глазами. Где-то внимательнее, где то по диагонали, в зависимости от степени влияния на структуру кода и логику. И каждый раз спрашиваю себя, а какими принципами я руководствуюсь? Пишу этот пост, чтобы порефлексировать с одной стороны и заложить на будущее темы, которые буду разбирать. ИИ это хорошо для кодинга, но инженерия никуда не девается. Все происходит над подсознательном уровне, я работаю в давно знакомом мне проекте и хотя бы примерно понимаю что и где происходит, задачи которые я делаю тоже понятны, все таки и в разработке давно и сам проект не гугл. Но он достаточно большой и сложный, чтобы можно было просто забить на архитектуру и делать как придется. Наверное главное, за чем я слежу и что прорабатываю глубоко это онтология проекта: сущности, свяжи между ними и границы ответственности. Причем речь не идет о том, чтобы попытаться полностью повторить реальный мир, наоборот, идет попытка создать систему, с одной стороны, простой, с другой нужно учесть все необходимые требования от нормализации до поддержки историчности при изменениях (там где это надо). Связь m2m сложнее o2m, это будет проявляться и в запросах и в коде. Можно ли не усложнять? А если мы работаем с иерархией сущностей, надо ли делать одну таблицу с полями сразу для всего, но чтобы каждый тип использовал свое подмножество или нам надо создавать разные таблицы? А как потом их объединять? Денормализация или внешний поиск? И обязательно инварианты. Какие состояния в системе вообще допустимы? Что не должно происходить никогда? Какие связи обязательны, какие опциональны. Здесь мы имеем дело и со смыслами и с технической имплементацией на уровне хранилища и, в моем случае, ORM. Можно ли в этом случае довериться ии? Обсуждать, спрашивать совет и просить рассказать плюсы и минусы разных вариантов это прямо хорошо, но принимать решение точно надо самому, потому что слишком дорого потом придется платить за неудачно принятые решения. А они точно будут. Примерно такая же история с api. Если внешние ручки спроектированы плохо, потом мы обалдеем тащить это легаси через года и пространство. Между первым (моделями) и вторым (api) собственно и лежит большая часть кода в типовых веб-приложениях. Да ее пишет ИИ, но на базе заложенной архитектуры. Причем она достаточно стандартна. У нас есть слой сервисов, где выполняются бизнес-операции и проверяются инварианты. Рядом находится слой авторизации и события. К этому примыкает инфраструктурный слой с асинхронными джобами, очередями, мидлварами и тому подобным. Я отдельно выношу обработчики http, dto и валидациями данных запроса и ответа. Все это вообще не надо писать самостоятельно, сейчас, когда легко доступен design-first, лучше пользоваться генераторами типа openapi-generator, которые создают все автоматом на базе openapi. Все что остается, это вписать в нужные места вызовы своих сервисов и правильно сформировать ответ. Даже если обходиться без генерации, ии отлично справится опираясь на существующий код, если он написан нормально. Отдельный большой блок связан с микросервисной архитектурой, но я пишу про нее редко, потому что живу в монолите (хотя и с кучей сервисов, асинхронных джоб и обвязок вокруг). Оставляю эту тему другим блогерам 🙂 Ну и фронтенд, с ним ситуация явно проще, особенно если использовать готовые библиотеки компонентов и сгенерированные sdk для api (если у нас есть openapi). Да, во фронте есть свои заморочки связанные с безопасностью, отсутствием коннекта, локальным стейтом, ошибками, идемпотентностью и другими интересными темами. И конечно без понимания базы, сделать что-то серьезное будет сложно. Все? Нет конечно, самое интересное начинается когда надо думать об обратной совместимости, следить за транзакционными границами, идемпотентностью и конкурентностью. И тесты, которые ии по дефолту пишет плохо. Вот это все не будет происходить само по себе и хорошо бы знать, как оно устроено под капотом. Что еще упустил?

Как Ford признал, что сам себя переиграл В 1964 году Ford выпустил бестселлер - Mustang - машину, которую придумала команда под руководством молодого управленца по имени Ли Якокка. Он пришёл в компанию инженером, но быстро понял, что его сила в понимании потребностей клиентов, и перешёл в продажи и маркетинг. Именно вера в интуицию и опыт команды, а не только в инженерные расчёты, принесла Ford рекорд тех времён - более 400 тыс. проданных авто за первый год, лучший результат компании со времён Model A. Свой успех Ли Якокка описал в книге "Карьера менеджера", кстати, рекомендую. Но спустя 60 лет Ford забыл про человеческую интуицию и чутье и решил поиграть во всеобщую игру под названием "ИИ заменит рабочих" и заодно и издержки, и с 2024 года сократил 20 тыс. рабочих мест. К чему это привело? Брак, с которым Ford борется уже много лет, не уменьшился - в 2025 году компания официально отзывала бракованные партии 152 раза - это самый высокий показатель в США. А вот обучать ИИ стало просто некому, т.к. под сокращение попали те самые грамотные инженеры с интуицией, которые лучше любого ИИ чуйкой понимали где искать причину. Примерно как Якокка ставил свою карьеру на кон, настаивая именно на такой форме Мустанга, а не той, которую хотел Генри Форд младший. Сочетание вернувшихся "gray beards" опытных инженеров, задача которых теперь была обучить ИИ, автоматизации "умными" камерами и перепрошивка систем контроля на основе реального производственного опыта, которого не было в исходных данных без людей, дало результат - уже в этом 2026 году Ford впервые с 2010 года занял первое место среди массовых брендов в рейтинге качества J.D. Power. В общем, Ford - ещё один пример компании, показывающий, что технология усиливает мастерство, а не заменяет его. Алгоритм может обработать данные, но не может обработать опыт, которого в этих данных никогда не было. Да и смысл соревноваться с ИИ там, где решает человеческая интуиция, если можно встроить человека в процесс и получить от технологии максимум? Пусть Ford ещё поработает. Да и нравится мне Ford Mustang, нет в нем ничего лишнего, ИИ уж точно 😉 Согласны? Что скажете? #истории ®️ Фанат сервиса| MAX| Клуб| Обо мне Личный путь лидера - В моменте

Как устроен двигатель внутреннего сгорания Чтобы объяснить двигатель внутреннего сгорания с нуля, автор начинает с пушки. Порох воспламеняется, газ мгновенно расширяется, ядро вылетает из ствола, надёжно и управляемо, но совершенно бесполезно для вращения вала. Ядро толкнёт кривошип один раз и улетит навсегда. Весь фокус в том, чтобы ядро не улетало. Заменяем его поршнем с отверстием, крепим шатун, запираем в цилиндре, и снаряд, который раньше исчезал за горизонтом, теперь возвращается наверх, готовый к следующему взрыву. Дальше та же логика достраивается до реального четырёхцилиндрового мотора, где коленчатый вал под давлением взрывов почти не касается металла, а плавает на тончайшей плёнке масла. Проследим, как одноразовый выстрел превращается в бесконечный цикл.

В большинстве своем при поиске latency метрик мы находим общую latency = написал текст/сказал текст и получил аудио обратно. Однако за этим стоит не только большая доля инженерии, но и модули модели. Метрики, которые мы здесь рассмотрим: • FTL - first packet latency • TPP - first packet decode • DEC - mean packet decode • FPL - first packet latency • RTFx - audio_duration / processing time - общий throughput пайплайна Чаще всего работаем с пайплайном: текст -> LM based TTS - - - > audio codebook tokens - - - -> Codebook based Vocoder FTL - это путь от текста к первому audio codebook token. Это может быть как и один токен, который генерит большая модель, так и sequence токенов, которые генерит какой-то depth transformer, а может быть вообще multi-token generation от главной модели. Так или иначе на выходе только дискретный токен / латентный вектор. На эту метрику влияют кроме всех прочих приколюх модели и параметры интеренса. Например, сколько буковок вообще нужно ждать, чтобы начать генерить. Или сколько буковок передавать как lookahead, чтобы аудиотокены получались лучше. TPP - это путь только вокодера. Получили аудио токены - получили первый audio patch. У этого пути может быть отдельный cuda stream. Здесь также главную роль играют "accumulation" параметры. Например, сколько токенов нужно подсобрать чтобы сделать один pass вокодера? —— Но также именно здесь есть важный дизайнхук, который всегда люди делают по-разному. Как декодировать последовательность, чтобы не было странных звуков между патчами😒 Многие это делают декодируя всю предыдущую последовательность. Кто-то собирает n прошлых секунд и отправляет именно их. Кто-то использует kv cache, что часто идентично. Каждый из них влияет на latency. Именно это design choices отражаются на DEC метрики, так как один пасс через vocoder может потом линейно вырости и будет казаться, что вокодер вместо 50ms почему-то стал тратить 200ms, а все потому что мы передали ему весь предыдущий контекст. —— Все метрики выше влияют на FPL, как раз то, что большинство юзеров называют latency. Или вот эта задержка между тем как вы что-то сказали и бот ответил вам в ответ (здесь мы считали только TTS часть). Большинство компаний стремятся к тому, чтобы это значение latency было меньшее 100ms 😌 В борьбе за этим что только можно и нельзя использовать. При этом важно и смотреть на общий RTF, так как многие (в том числе и я) могут занижать FPL с помощью более маленького контекста, lookeahead'a и тд, а потом уже кормить модель нормальным контекстом🙂. Ну и конечно мы оставляем за большими скобками хитрые вещи по типу filler words или заготовленные фразы, чтобы не казалось что модель долго думает.

А с каким latency говорите вы? Я иногда с 300ms, а иногда с -100ms (ну знаете когда собеседник уже слишком тянет и ты все уже понял)

Как специфика строения атома водорода может повлиять на его функциональные свойства? Вот вам очень интересный пример из серии "почему нельзя остановиться просто на изучении структуры" и как я пришёл в итоге к теоретической физике. Энергетики обычно облицовывают ёмкости для хранения водорода под давлением специальными полимерными составами. И часто пара металл-чистый водород становится для специалистов кошмаром. И нет, ёмкости и резервуары не корродируют. Всё куда круче - если полимера не будет, то емкость просто... Развалится 😆 Выше показан излом, образовавшийся естественным путём. Виной всему строение атома водорода. Когда атом водорода входит в металл (а при постоянном контакте это происходит хотя бы из-за диффузии), он обычно отдает свой единственный электрон в зону проводимости материала. Большинство элементов сохраняют внутреннее электронное облако, создающее стерические препятствия, из-за которых электроны сильно отталкиваются друг от друга при слишком близком сближении. У протона водорода, не имеющего внутренней оболочки, такого электронного облака нет. Поскольку у него нет внутреннего электронного облака, которое могло бы оказывать сопротивление кристаллической решетке, он легко перемещается в межатомных пространствах. Способность водорода избегать столкновений не ограничивается только физическими факторами. Поскольку водород невероятно мал, на его поведение сильно влияет квантовая механика. Длина волны де Бройля протона достаточно велика, чтобы он мог квантово туннелировать сквозь физические энергетические барьеры между междоузлиями. Вместо того чтобы использовать тепловую энергию для преодоления барьера от одного пустого пространства в кристаллической решетке к другому, атом водорода может просто обойти эту преграду. Это позволяет водороду быстро диффундировать через твердые материалы даже при чрезвычайно низких температурах, где более тяжелые атомы прочно зафиксированы. Свободно перемещаясь по стальной решетке, эти протоны сталкиваются с микроскопическими дефектами, границами зерен или крошечными пустотами. Когда два протона водорода встречаются в одной из таких пустот, они забирают электроны и образуют связь, формируя газообразный водород. Это уже не полезно, так как вызывает колоссальные внутренние напряжения. Но помимо этого всё это ещё и реагировать химически начинает с образованием продуктов реакции. Это огромное внутреннее давление разрывает окружающий металл, вызывая катастрофическое разрушение структуры, известное как водородное охрупчивание. Металл разрушается изнутри наружу. И это под микроскопом выглядит так, как показано на картинке. Вот вам сразу три фактора в одно связке. и Два из них выходят за рамки механики. Чат канала теперь тут

Боинг MAX Катастрофа Боинг MAX — хороший пример аварии, вызванной нарушением баланса между прибылью и поддержкой. Чтобы разобраться в этом случае, необходимо немного углубиться в историю. В 90х годах прошлого века были тяжелые времена для авиастроителей. Падение спроса в гражданской авиации, сокращение военных заказов. В 1995 году сократили более 70 тыс. рабочих. В 1997 Боинг купил компанию МакДоннелл-Дуглас. В объединенной компании ведущую роль начали играть менеджеры из МакДоннелл-Дугласа — они были более понятным для аналитиков с Уолл Стрит. В компаниях начали вводить различные программы сокращения затрат, увольнения опытных сотрудников (с самыми большими зарплатами) и так далее. Потихоньку инженерная школа Боинга проиграла в культурной войне финансовой школе МакДоннелла. В 2004 Боинг запускает разработку нового самолета 787 Дримлайнер. Однако, из-за проблем с проектированием (что не удивительно), поставки начались только в 2011 году. Airbus же в 2010 выпустила среднемагистральный А320, более экономичный. А320 составил основную конкуренцию 737 и DC9 МакДонелл-Дугласа Боинг в ответ хочет выпустить новый самолет, еще более экономичный чем Airbus, и хочет выпустить максимально быстро. Чтобы сократить время разработки и сертификации, новый самолет запускают как обновление 737. Для экономии делают двигатели большего размера. Разместить их под крыльями уже не получалось, поэтому их вынесли вперед и выше. Это изменило аэродинамическую модель самолета — он все время задирал нос вверх. Это было видно даже на испытаниях моделей самолета в аэродинамической трубе. Чтобы избавиться от этого недостатка, разработали MCAS: система улучшения характеристик маневрирования. Сообщать об этой системе пилотами и компаниям не стали? так как это потребовало бы дополнительного обучения пилотов и сертификации в FAA — мы же помним, нам надо быстрее. Сама система MCAS написала не очень хорошо — по команде от одного датчика система начинала опускать нос вниз. И продолжала это делать каждые 5 секунд с маниакальным упорством. Чтобы добить всех, главный технический пилот Boeing написал, что обучение работе с MCAS на симуляторе не требуется. После первой катастрофы с Lion Air Боинг предпочел обвинить в аварии пилотов индонезийской компании, обновлений в системе не было. Только после второй аварии Боинг MAX поставили на прикол до исправления ситуации. Отвечая на вопрос The Washington Post о том, почему компания не остановила полеты MAX, когда она впервые узнала о софте, убившем 189 человек, президент компании Дейв Калхун сказал: «Я не жалею об этом решении. И я не думаю, что мы ошиблись в то время и в том месте». #ЧФ #системная_модель #управленческая_дилемма