Статья Феликса Ризеберга, нанимающего менеджера в Anthropic:
В этом месяце я окончательно похоронил традиционное кодинг интервью по программированию. Как нанимающий менеджер в Anthropic, я перестал просить кандидатов проходить их. У этого формата была хорошая жизнь: способность быстро определять задачи и находить элегантные решения была слабым, но всё же полезным индикатором того, насколько успешным человек окажется в моих командах. Небольшие задачи по программированию, основанные на реальном коде, позволяли нам получать значимую информацию о кандидатах.
Теперь это больше не так. Давать вам маленькую задачу на React имеет не больше смысла, чем устраивать экзамен по ассемблеру; Claude теперь лучше справляется и с тем, и с другим. Наши самые результативные разработчики успешны независимо от того, насколько хорошо они проходят такие тесты.
Несмотря на повсеместное распространение, coding interview никогда не были особенно любимы. Я подозреваю, что у опытных инженеров исчезновение этого формата всё равно вызовет сильную реакцию — хотя бы потому, что это говорит об эволюции нашей профессии. Уже написано немало о том, насколько ИИ усложняет жизнь начинающим разработчикам, особенно тем, кто пытается найти работу. Но теперь, когда я некоторое время наблюдаю за тем, как начинающие специалисты работают с ИИ, у меня появился более оптимистичный взгляд: влияние на результат всё меньше ограничивается тем, сколько лет знаний о фреймворках и библиотеках вы накопили.
Я вижу, как сравнительно новые инженеры обгоняют людей, которые, вероятно, программируют лучше и работают в профессии гораздо дольше. Голод важнее стажа.
Этот пост — мой лучший совет начинающим инженерам, хотя слово «начинающим» здесь не совсем верное. На самом деле он для инженеров, у которых пока нет социального капитала, статуса или власти.
Есть видение, но нет голоса
Прежде всего поймите и своё преимущество, и свой недостаток.
Свежий взгляд, даже наивный, давно считается очень ценным. Когда я пришёл в Stripe, основатель Патрик Коллисон настоятельно просил новичков внимательно замечать всё, что кажется им странным. Его ставка была на то, что новые сотрудники увидят трения и возможности, которые старожилы давно перестали замечать.
В 1991 году Джеймс Марч писал, что организации зависят от «поддержания притока наивных и невежественных». Когда Орсона Уэллса спросили, откуда у него взялась уверенность пробовать такие приемы съемки, к которым до него никто не прибегал, он ответил: «Невежество, чистейшее невежество — поверьте, ничто не дает такой уверенности. Мне кажется, именно тогда, когда начинаешь хоть что-то понимать в профессии, становишься робким или излишне осторожным».
Когда я пришёл в Notion, одно из собеседований было посвящено проектированию архитектуры офлайн-режима. Я был удивлён, когда узнал, что там считали это «интервью с подвохом», поскольку офлайн-режим считался невозможным. Модель данных была слишком сложной, чтобы легко синхронизировать целое рабочее пространство Notion, а скачивание отдельных страниц якобы никогда бы не одобрил генеральный директор Иван Чжао. Сложность модели данных действительно оказалась реальной; сопротивление основателя — нет. Люди настолько считали это общеизвестным фактом, что никто даже не проверял. Я, невежественный новичок, просто не знал, что «так нельзя», и поэтому задал вопрос.
Легко читать такие истории и видеть, как другие принимают плохие решения. Но я не могу преувеличить, насколько трудно замечать эти ошибки, когда их совершаешь ты сам. Вскоре после прихода в Notion я захотел установить в командах большие телевизоры с живыми дашбордами. Я упёрся в организационные стены, не добился своего и не был достаточно мотивирован, чтобы начинать из-за этого большую борьбу.
Год спустя Цзи Пэй пришёл в компанию с той же идеей. Я усмехнулся и сказал ему не тратить время: я уже пробовал. А он уже успел спросить. На следующий день телевизоры появились. Где-то за тот год я сам успел стать старожилом.
Единственная проблема всей этой силы невежества в том, что никому не интересно, что вы думаете. В большинстве технологических компаний существует несколько уровней среднего менеджмента, которые переводят крупные бизнес-цели в конкретное исполнение. Структурно компании часто устроены так, что несколько людей одобряют или блокируют отдельные идеи. В мире, где реализация стоит дорого, обычно нужно долго накапливать социальный статус, прежде чем вся организация будет готова «поставить» на вашу идею. Организационные структуры меняются с ледниковой скоростью, поэтому даже компании, которые верят в ИИ, часто ожидают от junior сотрудников просто более быстрого выполнения поставленных задач, а не амбициозной работы напрямую на бизнес-цели.
Что ж, хорошая новость: реализация больше не стоит дорого.
Что делать
(1) Выберите бизнес-эффект, а не беклог. Ещё до эпохи ИИ-кодинга, в 2011 году, Патрик Маккензи писал: «инженеров нанимают, чтобы создавать бизнес-ценность, а не чтобы программировать». Он советовал держаться ближе к тем частям компании, которые зарабатывают деньги. Начните с этого: поймите, чего ваша компания на самом деле пытается добиться — или, если компания большая, чего пытается добиться ваша группа или отдел. Затем выберите правильный уровень абстракции: понимание целей руководителя вашего менеджера часто даёт хороший ориентир.
(2) Выберите радикальную идею. Придумайте несколько идей, которые в случае успеха резко повысили бы шансы вашей организации добиться этих целей. Будьте амбициозны.
(3) Соберите это за выходные. Я видел, как небольшие группы и отдельные инженеры обходили обычный процесс написания PRD, получения поддержки и выбивания времени дизайнеров или продакт-менеджеров, просто создавая рабочий прототип.
(4) Сосредоточьтесь на одной хорошей идее. По моему опыту, начинающие люди часто совершают ошибку, запихивая в один прототип сразу множество идей, пряча три отличных идеи среди двадцати плохих. Если ваш прототип требует создания нового языка программирования, бэкенда и каким-то образом ещё и мобильных приложений, скорее всего, ничего не получится. Смысл рабочего прототипа в том, чтобы настолько хорошо донести одну идею, чтобы руководство быстро поняло и саму возможность, и то, что именно вы способны её развить.
(5) Используйте свежий взгляд. Если вы работаете над чем-то пользовательским, у вас есть необычно высокий уровень эмпатии к пользователю и поэтому гораздо лучшее понимание того, как продукт реально работает или не работает для него. Моим коллегам в Slack и Notion было трудно по-настоящему вспомнить, каково пользоваться Slack или Notion в качестве внешнего пользователя.
Если вы работаете над инфраструктурой или инструментами, ваше преимущество в том, что вы ещё не успели выучить все причины, почему что-то считается «невозможным».
Будущее выглядит светлым
Я не думаю, что кодинг интервью вернутся. Легко поддаться сентиментальности, если вспомнить, сколько экземпляров «Алгоритмов и структур данных» было куплено в надежде получить хорошую работу и лучшее будущее — или увидеть в смерти таких собеседований ещё один рубеж, после которого software engineering поднялся на новый уровень абстракции.
При этом, как человек, который давно ненавидит продвижение в зависимости от стажа, я не могу не быть оптимистом. Я уже видел достаточно популярных приложений и продуктов, созданных именно таким способом.
В Anthropic люди настолько привыкли использовать Claude Code как интерфейс командной строки, что потребовались два сравнительно новых инженера — Энтони Моррис и Элис Чжао — чтобы за одни выходные собрать рабочий прототип. Первая публичная версия вышла примерно через восемь дней. Вас, вероятно, не удивит, что хороший графический интерфейс для Claude Code оказался очень популярным продуктом.
Я, вероятно, не единственный менеджер, который сейчас пытается понять, как проводить собеседования с людьми, которые хорошо умеют строить продукты с ИИ. Я сам пока до конца не разобрался, но уже просматриваю резюме и портфолио в поиске небольших прототипов, в которых видны вкус, эмпатия и принципиальное мышление. Если вы придумали способ лучше, мне было бы интересно о нём узнать.