Що я шукаю в сеньйор-інженерах у 2026 (після 250+ наймів)

За останнє десятиліття я найняв чимало інженерів. Агентство в Тель-Авіві, фінтех і комплаєнс у Швейцарії, дев-шопи, що масштабували команди з 50 до 250 людей, а тепер JobCannon і група MIR. Чесний рахунок — десь за 250 наймів, зроблених або напряму затверджених мною, плюс, мабуть, удвічі більше співбесід.

У першій половині цієї кар’єри я помилявся майже в усьому. Сигнали, яким я тоді довіряв — дипломи, бренд компаній, красномовні відповіді на співбесіді, швидкий LeetCode — не передбачали майже нічого про те, чи випустить людина хороший софт у наших умовах.

Далі — набагато менший набір сигналів, яким я довіряю зараз, у 2026.

Сигнал 1: вони випустили щось завершене і можуть говорити про компроміси

Не «долучився до», не «був частиною команди, яка». Випустив. Відповідав за це. Від специфікації до живих користувачів.

Кожну співбесіду з сеньйором я відкриваю проханням провести мене крізь проєкт, який вони випустили від і до. Перші десять хвилин — вони розповідають історію. Наступні п’ятнадцять — я питаю, чому вони зробили саме такий вибір. «Чому ця база даних, а не інша? Чому ця auth-бібліотека? Чому ти не написав тести для цієї частини?»

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

Сигнал 2: вони пишуть код при мені й озвучують хід думки

Я не роблю leetcode. Мені байдуже, чи вміє людина балансувати бінарне дерево на дошці. Формат співбесіди, який я веду: ось маленька, майже реальна задача з нашої предметної області. Сорок хвилин пишемо код разом. Ти за кермом, я спостерігаю й ставлю питання.

На що я дивлюся:

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

Сигнал 3: вони можуть не погоджуватися зі мною без захисної реакції

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

«Так, можна й так» — провал (згодливість, не заперечить, коли це буде важливо)
«Хм, але...» з реальним аргументом — пройшов
«Це неправильно, тому що X, ось що я зробив би замість цього» — пройшов з відзнакою
«Це жахлива ідея» (без пояснення) — провал (грубість ≠ правота)

Команда, яку я будую, має вміти сказати мені, засновнику, що я неправий. Кілька разів на тиждень. Без вагань.

Сигнал 4: у них є стосунки з власними інструментами

Покажи свій редактор. Покажи термінал. Розкажи, як дебажиш. Розкажи, що останнє в стеку тебе бісило.

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

Сигнал 5: вони можуть написати зрозумілий абзац англійською про технічну річ

Сеньйорська інженерія — це щонайменше 30% письма. Не коду — письма. Дизайн-документи, RFC, ADR, пост-мортеми, описи PR, треди в Slack з поясненням, чому фіча затримується.

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

Сигнал 6: вони пройшли через реальний вогонь і пам’ятають, що горіло

Аутейдж. Втрата даних. Невдала міграція. Скомпрометований акаунт. Помилкове списання в тисяч користувачів.

Інженери, які пройшли через справжню продакшн-кризу — і були достатньо близько, щоб відчути відповідальність — розвивають інтуїцію, яку неможливо отримати інакше. Після цього вони пишуть код інакше. Будують observability, навіть коли їх ніхто не просить.

Що мене більше не хвилює

Університет. Корисний як слабкий сигнал хіба що на найвищому рівні. В решті випадків — нуль прогностичної цінності.
Брендові компанії. Великий техбізнес випускає і чудових інженерів, і повних туристів.
Роки досвіду. Після п’яти крива вирівнюється. Після десяти — це вже шум.
Конкретний фреймворк. Якщо ти випустив хороший софт двома мовами, у третій станеш продуктивним за два тижні.
Швидкість розв’язання LeetCode medium. Марна для продуктової роботи.

Що мене хвилює тепер більше, ніж раніше

Толерантність до невизначеності. Реальна продуктова робота — це наполовину недоокреслені специфікації й пріоритети, що постійно змінюються.
Самостійність у віддаленій роботі. Асинхронна дисципліна тепер — окрема навичка.
Комфорт з AI-інструментами. У 2026 продуктивні інженери — ті, хто осмислено вбудував GPT-5, Claude, Cursor чи подібне у свій робочий процес.
Спокій під тиском. Код писати у спокійний вівторок може будь-хто.

Процес співбесіди, який я веду зараз

1. 20-хвилинний вступний дзвінок. Історія останнього проєкту. Фічі проти рішень.

2. 60-хвилинна сесія парного кодингу. Реальна предметна область, реальна клавіатура.

3. 30-хвилинна розмова «розкажи про важкий момент».

4. Один пробний тиждень, оплачений за повною ставкою, на реальному тікеті. Без варіантів.

Оце і все. Жодних домашніх завдань (це образливо і легко обійти). Жодних панельних співбесід (співвідношення сигнал/шум занадто низьке). Жодного чисто технічного скринінгу від HR.

Головний принцип наостанок

Найм — найважливіше, що робить засновник, а більшість засновників ставляться до нього як до рутини. Ціна невдалого найму сеньйора — шість місяців і десь від $100K до $500K. Ціна додаткового пробного тижня з трьома кандидатами — кілька тисяч доларів і тиждень терпіння. Сповільнися. Дивись, як вони пишуть код. Слухай, як вони розповідають історії.

Уперше опубліковано на mktrl.dev/blog.