---
title: "Голод сильніший за стаж: поради junior-інженерам від менеджера Anthropic"
url: https://laravelukraine.com/blog/golod-silnisii-za-staz-poradi-junior-inzeneram-vid-menedzera-anthropic
date: 2026-11-14
source: https://felixrieseberg.com/hunger-beats-tenure-advice-for-junior-engineers/
---

# Голод сильніший за стаж: поради junior-інженерам від менеджера Anthropic

*Від редакції: Фелікс Різеберг - engineering-менеджер в Anthropic, де керував розробкою Claude.ai, Cowork і десктопного Claude Code, а також співмейнтейнер Electron; раніше працював у Notion, Stripe, Slack і Microsoft. Нижче - його текст про те, як змінюється найм і що це означає для тих, хто тільки починає.*

Цього місяця я поховав класичну технічну співбесіду з кодуванням. Як менеджер, що наймає людей в Anthropic, я перестав давати її кандидатам. Вона добре відслужила: вміння швидко сформулювати проблему й знайти елегантне рішення було слабким, але корисним показником того, наскільки успішним ви будете в моїх командах. Невеликі задачі на реальному коді справді говорили про кандидата щось важливе.

Тепер це не так. Давати вам маленьку задачку на React має не більше сенсу, ніж екзаменувати людей з асемблера: Claude тепер краще впорається і з тим, і з іншим. Наші найрезультативніші інженери досягають успіху незалежно від того, як добре вони проходять такі тести.

Технічна співбесіда з кодуванням, попри свою повсюдність, ніколи не була популярною. Підозрюю, що досвідчені інженери все одно гостро відреагують на її зникнення - хоча б через те, що воно каже про еволюцію наших ролей. Вже написано чимало про те, яким викликом AI став для junior-розробників, особливо для тих, хто намагається знайти роботу. Тепер, коли я трохи подивився, як новачки працюють з AI, мій погляд оптимістичніший: вплив людини дедалі менше обмежений тим, скільки років знань про фреймворки й бібліотеки вона накопичила.

Я бачу, як порівняно нові інженери пролітають повз людей, які, мабуть, краще пишуть код і працюють значно довше. Голод сильніший за стаж.

Ця стаття - найкраща моя порада junior-інженерам, хоча «junior» тут не зовсім те слово. Насправді вона для інженерів без соціального капіталу, статусу чи влади.

### Усе бачиш, а голосу немає

Спершу знайте і свою перевагу, і свою ваду.

Свіжий погляд, навіть наївний, давно вважають силою. Коли я прийшов у Stripe, засновник Патрік Коллісон просив нас, новачків, уважно придивлятися до всього, що здається нам дивним. Він робив ставку на те, що новенькі помітять тертя й можливості, які старожили давно перестали бачити.

У 1991 році Джеймс Марч [писав](https://doi.org/10.1287/orsc.2.1.71), що організації залежать від «постійного припливу наївних і необізнаних». Коли Орсона Веллса спитали, звідки в нього впевненість пробувати кадри, яких ніхто не пробував, він [відповів](https://www.themarginalian.org/2012/04/30/orson-welles-on-ignorance-1960/): «Невігластво, чисте невігластво - знаєте, немає впевненості, яка б із ним зрівнялася. Лише коли ти щось знаєш про професію, ти, мені здається, стаєш боязким чи обережним».

Коли я влаштовувався в Notion, на одній зі співбесід треба було спроєктувати архітектуру офлайн-режиму. Я був приголомшений, коли почув, що вони вважали це співбесідою «з підступом», бо офлайн-режим вважався неможливим. Модель даних була надто складною, щоб легко синхронізувати цілий робочий простір Notion, а завантаження окремих сторінок було тим користувацьким досвідом, якого CEO Айвен Чжао ніколи б не дозволив. Про складність моделі даних виявилося правдою, а от про опір засновника - ні. Усі вважали це настільки загальновідомим, що ніхто не перевіряв. А я, необізнаний новачок, просто не знав, що питати не варто.

Читаючи такі історії, легко побачити в них людей, які ухвалюють погані рішення. Я не можу навіть передати, як важко помітити такі помилки, коли їх робиш ти сам. Невдовзі після приходу в Notion я хотів поставити командам великі телевізори з живими дашбордами. Я вперся в організаційні стіни, зазнав невдачі, і мені було не настільки важливо, щоб розпочинати цілу війну.

Через рік до нас прийшов [Цзі Пей](https://www.linkedin.com/in/ji-pei) з тією самою ідеєю. Я пирхнув і сказав йому не морочитися: я вже пробував. А він уже спитав. Телевізори з'явилися наступного дня. Десь протягом того року старожилом став я.

У всієї цієї сили необізнаності лише одна проблема: нікого не цікавить, що ви думаєте. У більшості технологічних компаній є шари середнього менеджменту, які перекладають великі бізнес-цілі на виконання. Структурно компанії часто побудовані навколо ідеї, що кілька людей дають зелене світло окремим ідеям або блокують їх. У світі, де виконання дороге, зазвичай доводиться вигризати собі певний соціальний статус, перш ніж уся організація «поставить» на вашу ідею. Оргструктури зазвичай змінюються з льодовиковою швидкістю, тож навіть компанії, які вірять в AI, часто чекають від junior-інженерів просто швидшого виконання задач, а не амбітної гонитви за бізнес-цілями.

Що ж, добра новина: виконання більше не дороге.

### Що робити

**(1) Обирайте бізнес-цінність, а не беклог.** У 2011 році, задовго до кодування з AI, Патрік Маккензі [писав](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/): [«інженерів наймають створювати бізнес-цінність, а не програмувати щось»](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/). Чіпляйтеся, радив він, до тих частин компанії, які заробляють гроші. Почніть звідси: зрозумійте, чого насправді намагається досягти ваша компанія (або, у великій компанії, ваша група чи відділ). Потім знайдіть правильну висоту: розуміння того, які цілі має менеджер вашого менеджера, часто є корисним орієнтиром.

**(2) Візьміть радикальну ідею.** Придумайте кілька ідей, які в разі успіху різко підвищать шанси вашої організації досягти цих цілей. Будьте амбітними!

**(3) Збудуйте її за вихідні.** Я бачив, як невеликі групи й інженери-одинаки пролітали повз звичний процес - написання документів з вимогами до продукту (PRD), збирання погоджень, вибивання часу дизайнерів чи продакт-менеджерів, - просто збудувавши робочий прототип.

**(4) Зосередьтеся на одній добрій ідеї.** З мого досвіду, junior-інженери часто помиляються, запихаючи кілька ідей в один прототип і ховаючи три чудові ідеї серед двадцяти поганих. Якщо ваш прототип передбачає створення нової мови програмування, бекенду і ще якимось чином мобільних застосунків, успіху не буде. Сенс робочого прототипу - донести ідею так добре, щоб керівництво швидко зрозуміло і можливість, і те, що саме ви та людина, яка зможе її реалізувати.

**(5) Спирайтеся на свій свіжий погляд.** Якщо ви працюєте над чимось, що бачать користувачі, у вас унікально багато емпатії до них, а отже набагато краще відчуття того, як продукт для них працює чи не працює. Моїм колегам у Slack і Notion було важко по-справжньому відчути, як це - користуватися Slack чи Notion зовнішньому користувачеві.

Якщо ви працюєте над інфраструктурою чи інструментами, ваша перевага в тому, що ви так і не вивчили всіх причин, чому щось вважається «неможливим».

### Майбутнє світле

Я не думаю, що технічна співбесіда з кодуванням повернеться. Легко засумувати, згадавши, скільки примірників «Алгоритмів і структур даних» купили в надії відкрити собі шлях до хорошої роботи й кращого майбутнього, або подумавши, що смерть технічної співбесіди з кодуванням - ще одна віха на шляху розробки програмного забезпечення до нового рівня абстракції.

Водночас як давній ненависник підвищень за вислугу років я не можу не бути оптимістом. Я вже бачив чимало популярних застосунків і продуктів, створених саме так.

В Anthropic люди настільки звикли користуватися Claude Code як інтерфейсом командного рядка (CLI), що знадобилося двоє відносно нових інженерів ([Ентоні Морріс](https://x.com/amorriscode) та [Еліс Чжао](https://x.com/alicelovescake1)), щоб за одні вихідні зібрати робочий прототип. Перша публічна версія вийшла приблизно за вісім днів по тому. Вас не здивує, що добрий графічний інтерфейс для Claude Code - дуже популярний продукт.

Мабуть, я не єдиний менеджер, який намагається зрозуміти, як проводити співбесіди з людьми, що добре будують з AI. Я ще не зовсім до цього дійшов, але переглядаю резюме й портфоліо в пошуках невеликих прототипів, у яких видно смак, емпатію і принципове мислення. Якщо ви придумали щось краще, я б дуже хотів почути, як саме.
