Почніть вводити, щоб шукати по статтях, вакансіях, компаніях, проєктах, ресурсах, пакетах, подіях і користувачах.
Від редакції: Фелікс Різеберг - engineering-менеджер в Anthropic, де керував розробкою Claude.ai, Cowork і десктопного Claude Code, а також співмейнтейнер Electron; раніше працював у Notion, Stripe, Slack і Microsoft. Нижче - його текст про те, як змінюється найм і що це означає для тих, хто тільки починає.
Цього місяця я поховав класичну технічну співбесіду з кодуванням. Як менеджер, що наймає людей в Anthropic, я перестав давати її кандидатам. Вона добре відслужила: вміння швидко сформулювати проблему й знайти елегантне рішення було слабким, але корисним показником того, наскільки успішним ви будете в моїх командах. Невеликі задачі на реальному коді справді говорили про кандидата щось важливе.
Тепер це не так. Давати вам маленьку задачку на React має не більше сенсу, ніж екзаменувати людей з асемблера: Claude тепер краще впорається і з тим, і з іншим. Наші найрезультативніші інженери досягають успіху незалежно від того, як добре вони проходять такі тести.
Технічна співбесіда з кодуванням, попри свою повсюдність, ніколи не була популярною. Підозрюю, що досвідчені інженери все одно гостро відреагують на її зникнення - хоча б через те, що воно каже про еволюцію наших ролей. Вже написано чимало про те, яким викликом AI став для junior-розробників, особливо для тих, хто намагається знайти роботу. Тепер, коли я трохи подивився, як новачки працюють з AI, мій погляд оптимістичніший: вплив людини дедалі менше обмежений тим, скільки років знань про фреймворки й бібліотеки вона накопичила.
Я бачу, як порівняно нові інженери пролітають повз людей, які, мабуть, краще пишуть код і працюють значно довше. Голод сильніший за стаж.
Ця стаття - найкраща моя порада junior-інженерам, хоча «junior» тут не зовсім те слово. Насправді вона для інженерів без соціального капіталу, статусу чи влади.
Спершу знайте і свою перевагу, і свою ваду.
Свіжий погляд, навіть наївний, давно вважають силою. Коли я прийшов у Stripe, засновник Патрік Коллісон просив нас, новачків, уважно придивлятися до всього, що здається нам дивним. Він робив ставку на те, що новенькі помітять тертя й можливості, які старожили давно перестали бачити.
У 1991 році Джеймс Марч писав, що організації залежать від «постійного припливу наївних і необізнаних». Коли Орсона Веллса спитали, звідки в нього впевненість пробувати кадри, яких ніхто не пробував, він відповів: «Невігластво, чисте невігластво - знаєте, немає впевненості, яка б із ним зрівнялася. Лише коли ти щось знаєш про професію, ти, мені здається, стаєш боязким чи обережним».
Коли я влаштовувався в Notion, на одній зі співбесід треба було спроєктувати архітектуру офлайн-режиму. Я був приголомшений, коли почув, що вони вважали це співбесідою «з підступом», бо офлайн-режим вважався неможливим. Модель даних була надто складною, щоб легко синхронізувати цілий робочий простір Notion, а завантаження окремих сторінок було тим користувацьким досвідом, якого CEO Айвен Чжао ніколи б не дозволив. Про складність моделі даних виявилося правдою, а от про опір засновника - ні. Усі вважали це настільки загальновідомим, що ніхто не перевіряв. А я, необізнаний новачок, просто не знав, що питати не варто.
Читаючи такі історії, легко побачити в них людей, які ухвалюють погані рішення. Я не можу навіть передати, як важко помітити такі помилки, коли їх робиш ти сам. Невдовзі після приходу в Notion я хотів поставити командам великі телевізори з живими дашбордами. Я вперся в організаційні стіни, зазнав невдачі, і мені було не настільки важливо, щоб розпочинати цілу війну.
Через рік до нас прийшов Цзі Пей з тією самою ідеєю. Я пирхнув і сказав йому не морочитися: я вже пробував. А він уже спитав. Телевізори з'явилися наступного дня. Десь протягом того року старожилом став я.
У всієї цієї сили необізнаності лише одна проблема: нікого не цікавить, що ви думаєте. У більшості технологічних компаній є шари середнього менеджменту, які перекладають великі бізнес-цілі на виконання. Структурно компанії часто побудовані навколо ідеї, що кілька людей дають зелене світло окремим ідеям або блокують їх. У світі, де виконання дороге, зазвичай доводиться вигризати собі певний соціальний статус, перш ніж уся організація «поставить» на вашу ідею. Оргструктури зазвичай змінюються з льодовиковою швидкістю, тож навіть компанії, які вірять в AI, часто чекають від junior-інженерів просто швидшого виконання задач, а не амбітної гонитви за бізнес-цілями.
Що ж, добра новина: виконання більше не дороге.
(1) Обирайте бізнес-цінність, а не беклог. У 2011 році, задовго до кодування з AI, Патрік Маккензі писав: «інженерів наймають створювати бізнес-цінність, а не програмувати щось». Чіпляйтеся, радив він, до тих частин компанії, які заробляють гроші. Почніть звідси: зрозумійте, чого насправді намагається досягти ваша компанія (або, у великій компанії, ваша група чи відділ). Потім знайдіть правильну висоту: розуміння того, які цілі має менеджер вашого менеджера, часто є корисним орієнтиром.
(2) Візьміть радикальну ідею. Придумайте кілька ідей, які в разі успіху різко підвищать шанси вашої організації досягти цих цілей. Будьте амбітними!
(3) Збудуйте її за вихідні. Я бачив, як невеликі групи й інженери-одинаки пролітали повз звичний процес - написання документів з вимогами до продукту (PRD), збирання погоджень, вибивання часу дизайнерів чи продакт-менеджерів, - просто збудувавши робочий прототип.
(4) Зосередьтеся на одній добрій ідеї. З мого досвіду, junior-інженери часто помиляються, запихаючи кілька ідей в один прототип і ховаючи три чудові ідеї серед двадцяти поганих. Якщо ваш прототип передбачає створення нової мови програмування, бекенду і ще якимось чином мобільних застосунків, успіху не буде. Сенс робочого прототипу - донести ідею так добре, щоб керівництво швидко зрозуміло і можливість, і те, що саме ви та людина, яка зможе її реалізувати.
(5) Спирайтеся на свій свіжий погляд. Якщо ви працюєте над чимось, що бачать користувачі, у вас унікально багато емпатії до них, а отже набагато краще відчуття того, як продукт для них працює чи не працює. Моїм колегам у Slack і Notion було важко по-справжньому відчути, як це - користуватися Slack чи Notion зовнішньому користувачеві.
Якщо ви працюєте над інфраструктурою чи інструментами, ваша перевага в тому, що ви так і не вивчили всіх причин, чому щось вважається «неможливим».
Я не думаю, що технічна співбесіда з кодуванням повернеться. Легко засумувати, згадавши, скільки примірників «Алгоритмів і структур даних» купили в надії відкрити собі шлях до хорошої роботи й кращого майбутнього, або подумавши, що смерть технічної співбесіди з кодуванням - ще одна віха на шляху розробки програмного забезпечення до нового рівня абстракції.
Водночас як давній ненависник підвищень за вислугу років я не можу не бути оптимістом. Я вже бачив чимало популярних застосунків і продуктів, створених саме так.
В Anthropic люди настільки звикли користуватися Claude Code як інтерфейсом командного рядка (CLI), що знадобилося двоє відносно нових інженерів (Ентоні Морріс та Еліс Чжао), щоб за одні вихідні зібрати робочий прототип. Перша публічна версія вийшла приблизно за вісім днів по тому. Вас не здивує, що добрий графічний інтерфейс для Claude Code - дуже популярний продукт.
Мабуть, я не єдиний менеджер, який намагається зрозуміти, як проводити співбесіди з людьми, що добре будують з AI. Я ще не зовсім до цього дійшов, але переглядаю резюме й портфоліо в пошуках невеликих прототипів, у яких видно смак, емпатію і принципове мислення. Якщо ви придумали щось краще, я б дуже хотів почути, як саме.
Розсилки Mailcoach перевантажували сервер, і Стан Даніелс переглянув налаштування Horizon: хто споживає черги, timeout і retry_after, перезапуск після розгортання, алерти очікування і кількість воркерів.
Кілька воркерів черги одночасно оновлюють той самий OAuth-токен, і провайдер з ротацією refresh-токенів відповідає invalid_grant або взагалі відкликає підключення. Переказ статті Куанга Данга про те, як це розпізнати в логах і виправити через Cache::lock, повторне читання та compare-and-swap.
Розробник буде створювати, підтримувати та моніторити PHP-інтеграції, які збирають ігрові дані з лобі онлайн-казино, аналізувати HTML/DOM-структури та адаптувати скрипти до змін на сайтах. Також потрібні аналіз якості даних через SQL, робота з внутрішніми панелями та взаємодія з бізнес- і операційними командами. Вимоги: базові або середні навички PHP, розуміння HTML, DOM, CSS-селекторів і XPath, знання MySQL, cron і Linux, досвід роботи з AI-інструментами та аналітичне мислення.
Full Stack розробник розвиватиме та підтримуватиме власний аналітичний продукт для перевірки контрагентів і оцінки ризиків, працюючи зі складною бізнес-логікою та великими обсягами даних. Основний стек: PHP 8.x, Laravel або Symfony, MySQL, React; також потрібні проєктування API, оптимізація SQL-запитів, Docker, CI/CD. Вимоги: комерційний досвід від 3 років, досвід підтримки legacy-коду, англійська B1+ для читання документації.
Senior PHP-розробник відповідатиме за розроблення, розвиток і підтримку серверної частини вебзастосунків, проєктування нового функціоналу, рефакторинг, code review та усунення помилок. Ключовий стек: нативний PHP, Symfony, MySQL, PostgreSQL, REST API, RabbitMQ, Redis, AWS. Вимоги: досвід розробки на рівні Senior, глибоке знання ООП і патернів проєктування, оптимізовані SQL-запити, інтеграція зі сторонніми сервісами та досвід роботи з Git.
