Uber у середу показала прототип автомобіля, який планує використовувати для збирання реальних даних про дорожній рух для зростаючого переліку партнерів у сфері автономного транспорту, зокрема Avride, Waymo та WeRide.

Йдеться не про якийсь радикально новий дизайн. Це Hyundai Ioniq 5, оснащений великою кількістю датчиків на даху та з боків, про що компанія вперше розповіла TechCrunch ще в січні. Автомобіль, усіяний сенсорами, може й не виглядати проривним, однак для Uber він означає кілька важливих віх.

Це перший автомобіль, який Uber зібрала сама (за участі партнера) після продажу свого підрозділу з розробки безпілотників компанії Aurora у 2020 році. Він також демонструє прогрес нового підрозділу Uber AV Labs, запущеного на початку цього року. Його завдання — використовувати оснащені сенсорами автомобілі Uber для збору та подальшого обміну даними з більш ніж 30 партнерами з розробки технологій автономного водіння.

Uber заявила в середу, що планує вивести на дороги 500 таких доопрацьованих електромобілів Hyundai по всьому світу вже цього року. Цей парк зможе збирати «2 мільйони миль на місяць високоточних даних» для роботаксі. Компанія очікує, що 50 таких автомобілів будуть працювати вже до літа.

Ioniq обладнали 14 камерами, вісьмома твердотільними лідарними сенсорами та дев’ятьма радарами у партнерстві з Roush Performance, яка відповідає за переобладнання машин. Усі ці дані проходитимуть через обчислювальну платформу для автономних авто Nvidia Dual Drive Thor. Uber дає зрозуміти, що відкрита до змін цього набору сенсорів і надалі оновлюватиме його відповідно до потреб своїх партнерів.

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

У компанії вже є певний запас даних. Uber повідомила TechCrunch, що зібрала інформацію з тисяч автомобілів з камерами, спрямованими назовні, у десятках міст, які експлуатують її партнери з автопарків. Uber також збирала дані зі сотень автомобілів Lucid Air, що використовувалися партнерами компанії у США та Європі протягом останніх двох років.

Підрозділ AV Labs аналізує ці два масиви даних і готується збирати ще більше з допомогою модифікованих Hyundai Ioniq 5, які також працюватимуть у парках партнерів Uber.

Джерело

TechCrunch

Якщо ви фанат Росомахи, то добре знаєте: коли він з’являється, без кривавих сцен не обходиться. І якщо ви бачили цього тижня трейлер майбутньої гри Insomniac для PS5, то зрозуміли, чому вона отримала рейтинг M для дорослих. «Усі виглядають як мішки з варенням, – написав один із користувачів Reddit. – У них немає органів чи кісток. Вони просто наповнені варенням». На щастя для людей зі слабкими нервами (і, можливо, для продажів гри), у проєкті передбачені налаштування доступності, які дозволять пом’якшити насильство.

Студії Sony останніми роками роблять великий акцент на доступності, і Marvel’s Wolverine, схоже, не стане винятком. Серед параметрів, які можна змінювати, – динамічна кров, відрубування кінцівок та видимі пошкодження тіла самого Логана. Кожен із цих елементів можна зменшити або повністю вимкнути. Навіть фіксовані жорстокі сцени у кат-сценах, наприклад крупний план, де Росомаха прошиває чиєсь обличчя кігтем, можна заблюрити.

Режисер гри Майк Дейлі в розмові з Eurogamer сказав, що опції керування рівнем кривавості були очевидним рішенням. «У нас є класна система фізично коректної крові, яка вилітає й розбризкується всюди, – пояснює він. – Вона потрапляє на персонажів, розбавляється у воді та робить усі ці круті речі. Вимкнути це – найлегше, що можна зробити».

Якщо ви пропустили, ось той самий кривавий семихвилинний трейлер зі State of Play у вівторок:

Джерело

Engadget

Xbox оголосила наступну добірку ігор, які з’являться у підписці Game Pass на початку червня. Одним із головних релізів стане Persona 5 Royal — версія 2020 року, що додала третій семестр сюжету та кілька інших доповнень до оригінальної культової JRPG 2016 року. Якщо ви давно не поверталися до цієї стильної історії, саме час зануритися в ще одне проходження. Гра поповнить каталог Xbox Game Pass 9 червня.

Серед інді-новинок — Herdling, медитативна гра, у якій ви ведете зграю дивних, але милих створінь угору на гору. Вона вийшла торік і вже доступна в Game Pass Premium, а з 4 червня з’явиться також у Game Pass Ultimate та PC Game Pass.

Ще одна новинка, що привертає увагу, — Solarpunk, яка буде доступна в Game Pass у день релізу 8 червня. Це футуристична survival-crafting гра, де ви будуєте не лише будівлі, а й енергомережу на основі сонячної та вітрової енергії на системі летючих островів. Також цікавим виглядає Beastro, що поєднує елементи deckbuilder та кулінарної гри. Вона теж з’явиться в каталозі Game Pass у день виходу — 11 червня.

Джерело

Engadget

Netflix оголосив, що замовив новий анімаційний серіал Dealies від Джо Беннетта, співтворця Scavengers Reign і Common Side Effects, та Теда Тревелстеда, актора озвучування у Scavengers Reign і колишнього супервайзинг-продюсера на The Great North.

Dealies розповість про співробітників великого мережевого магазину з такою самою назвою. Для порівняння, Scavengers Reign стежив за командою, яка зазнала аварійної посадки на небезпечній інопланетній планеті, а Common Side Effects присвячений змові із замовчування потенційного «чудо-препарату», здатного подовжувати життя. На тлі цих сюжетів ситком про робоче місце в Dealies може видатися не надто інтригуючим. Але є підстави вважати, що за простим описом ховається щось цікавіше.

І Беннетт, і Тревелстед виступають виконавчими продюсерами та шоураннерами Dealies. За анімацію відповідає студія Green Street Pictures, яка працювала і над попередніми проєктами Беннетта. Судячи з ключового арт-матеріалу, який Netflix показав разом з анонсом, та заставки до серіалу, опублікованої Green Street Pictures на YouTube, Dealies має помітні стилістичні спільні риси з Common Side Effects. Дизайн персонажів із великими виразними головами вже можна вважати «фірмовим стилем» Green Street, а сюрреалістичні, майже «папріка-подібні» образи в титрах нагадують найамбітніші моменти попереднього серіалу студії. Хочеться сподіватися, що подібність простежиться й у сюжеті: Common Side Effects формально є комедією, але в ньому несподівано багато справжньої емоційної драми.

Джерело

Engadget

Lovable та Google у середу оголосили про розширену багаторічну співпрацю. Lovable, швидкозростальний стокгольмський стартап у сфері «vibe‑coding», уже давно користується сервісами Google Cloud. За новою угодою його використання хмарної платформи істотно зросте.

Попри те, що компанії не розкривають фінансових деталей, джерело, обізнане з умовами, повідомило TechCrunch, що йдеться про п’ятикратне збільшення присутності Lovable в Google Cloud, включно з використанням AI. За словами цієї особи, у межах угоди Lovable отримає розширений доступ як до Claude від Anthropic — моделі ШІ, яку широко застосовують для задач програмування, — так і до власних моделей Gemini від Google.

Особливо цікавим є компонент співпраці з Anthropic. У квітні Google інвестувала в Anthropic 10 млрд доларів грошима та кредитами на обчислювальні ресурси, пообіцявши ще 30 млрд доларів за умови досягнення певних показників ефективності. Ця інвестиція відбулася за оцінки Anthropic у 350 млрд доларів — лише за місяць до того, як компанія залучила приголомшливі 65 млрд доларів за оцінки майже в 1 трлн доларів. Поточна угода має допомогти Anthropic досягти цих цілей, адже Lovable є одним із найшвидше зростаючих стартапів Європи. За даними Lovable, у лютому компанія подолала позначку в 400 млн доларів річних повторюваних доходів, додавши 100 млн доларів лише за один місяць і маючи всього 146 співробітників. Компанія стверджує, що понад половина компаній зі списку Fortune 500 у тій чи іншій формі використовують її продукт.

Угода також глибше інтегрує Lovable в інші складові екосистеми Google. Новий агент Lovable буде доступний через корпоративний маркетплейс агентів Google Cloud — Gemini Enterprise Agent Gallery. Про таку співпрацю компанії вперше натякнули на великій хмарній конференції Google у США в квітні. А для захисту коду, який пишуть і люди, і агенти, Lovable інтегрується з Wiz — найбільшим придбанням Google в історії вартістю 32 млрд доларів, угода щодо якого була офіційно закрита в березні, через рік після анонсу. Інтеграція дозволить Wiz виявляти та усувати проблеми безпеки в режимі реального часу.

Завдяки продажу агентів Lovable через маркетплейс Google, хмарний гігант обіцяє спростити для корпоративних клієнтів закупівлі та білінг, що має полегшити Lovable залучення нових замовників серед великих підприємств.

Джерело

TechCrunch

На ринку q-commerce, зосередженому на швидкості доставки, індійський стартап FirstClub переконав інвесторів, що ставка на якість може стати новою можливістю. Це допомогло компанії подвоїти свою оцінку лише за дев’ять місяців після попереднього раунду фінансування.

Стартап із Бангалуру залучив $55 млн у раунді серії B під співлідерством Peak XV Partners і Sofina. Після інвестиції компанію оцінили у $255 млн — проти $120 млн у вересні 2025 року. У раунді також взяли участь чинні інвестори Accel, RTP Global та Paramark Ventures. Загалом FirstClub залучив уже $86 млн.

У міру того як покупки продуктів дедалі активніше переходять в онлайн, індійський ринок швидкої комерції стрімко зростає: з приблизно $6,2 млрд у 2025 фінансовому році до прогнозних $11–12 млрд у 2026-му, згідно зі звітом ICICI Securities. Лідери ринку популяризували онлайн-замовлення продуктів завдяки дедалі швидшій доставці. Водночас FirstClub робить ставку на те, що дедалі більше споживачів віддаватимуть перевагу якості та ретельному добору асортименту, а не максимально швидкому отриманню замовлення.

Заснований у 2024 році колишнім топменеджером Flipkart Айяппаном R, FirstClub розвиває курований онлайн-сервіс доставки продуктів, який пропонує близько 4000 найменувань — приблизно третину асортименту багатьох конкурентів у q-commerce. Стартап стверджує, що проводить якісний відбір свіжої продукції, лабораторні тести окремих основних товарів та співпрацює з брендами над ексклюзивними позиціями, позиціонуючи себе як надійний продуктовий сервіс, а не просто службу швидкої доставки.

«Людям не потрібен дуже великий вибір, їм потрібен правильно відібраний асортимент стабільної якості, щоразу», — сказав Айяппан в інтерв’ю.

За даними FirstClub, понад 60% клієнтської бази становлять домогосподарства, якими керують жінки. На відміну від багатьох сервісів швидкої доставки, де продажі домінують базові овочі на кшталт цибулі, помідорів і картоплі, серед хітів продажу FirstClub — авокадо, хурма та яблука сорту Modi. Це відображає попит на преміальні й ретельно відібрані продукти.

Стратегія, схоже, знаходить відгук серед перших користувачів. FirstClub повідомляє, що перетнув позначку в 1 млн замовлень і залучив 170 000 домогосподарств протягом року після запуску в Бангалуру.

Стартап наразі працює з річним валовим обсягом продажів (сума всіх товарів, реалізованих через платформу) близько $50 млн. У середньому клієнти оформлюють понад чотири замовлення на місяць і витрачають близько ₹1 200 (приблизно $13) за одне, розповів Айяппан TechCrunch.

FirstClub планує використати новий капітал для виходу за межі Бангалуру, де зараз працює 21 магазин, та для посилення присутності в Хайдарабаді, де сервіс нещодавно запустився з трьома локаціями. Компанія, у якій безпосередньо працює близько 220 співробітників, також має намір розширити асортимент за рахунок категорій товарів для дому та кухні, подарунків та інших повсякденних речей для домогосподарств.

Директор Peak XV GV Равішанкар зазначив, що в Індії формується більша група заможних, орієнтованих на здоров’я споживачів, готових платити за вищу якість, що створює простір для спеціалізованих продуктових платформ поряд із масовими сервісами q-commerce.

«Буде певна група споживачів, яка тяжітиме до платформи кращої якості з надійними продуктами», — сказав Равішанкар в коментарі TechCrunch. — «У міру того як індійці багатіють і стають більш поінформованими, все більше людей робитимуть саме такий вибір».

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

Джерело

TechCrunch

Benchmark Capital, легендарний венчурний фонд Кремнієвої долини, відомий ранніми інвестиціями в eBay, Snap, Uber та Twitter, порушує одну зі своїх ключових традицій: обмежувати розмір фондів приблизно $425 млн і вкладатися лише в молоді стартапи. Після більш ніж двох десятиліть, протягом яких розмір фондів не перевищував цієї суми, компанія залучила зобов’язання на $2 млрд у два нові фонди, включно з $1,25 млрд у фонд для інвестицій на пізніших стадіях, повідомляє The Wall Street Journal.

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

Водночас відносно невеликі фонди Benchmark, ймовірно, заважали компанії вкладатися в капіталомісткі AI‑стартапи, особливо розробників foundation‑моделей, раунди яких часто сягають сотень мільйонів доларів. У результаті фонд не інвестував в Anthropic, OpenAI чи інші капіталомісткі AI‑лабораторії, такі як Periodic Labs, Reflection AI або Recursive Superintelligence.

Новий ранньостадійний фонд Benchmark обсягом $750 млн дасть фірмі більше гнучкості для виписування більших чеків в умовах, коли оцінки стартапів на ранніх стадіях різко зросли. Хоча традиційно Benchmark заходив у компанії на раундах Series A, останнім часом фірма дала собі більше свободи інвестувати і на інших ранніх стадіях розвитку.

За останні місяці Benchmark інвестував у два стартапи на стадії Series B: Gumloop, платформу, що дає підприємствам змогу створювати AI‑агентів без програмування, та Monaco, «AI‑нативну» платформу для продажів і CRM.

Генеральний партнер Benchmark Еверетт Рендл раніше говорив TechCrunch, що фонд прагне будувати «суттєві й глибокі стосунки з підприємцями, і це може статися доволі рано в життєвому циклі компанії — на етапі seed, Series A чи Series B».

Фонд уперше серйозно спробував себе в пізніх стадіях, коли залучив $225 млн у спеціальний інвестиційний інструмент (SPV), щоб взяти участь у перед‑IPO‑раунді обсягом $1 млрд для Cerebras, як раніше повідомляв TechCrunch. Benchmark вперше очолив раунд Series A цього виробника чипів ще у 2016 році. IPO Cerebras відбулося минулого місяця і принесло Benchmark $3,25 млрд за ціною розміщення.

Саме цей великий вихід підштовхнув фірму до створення окремого growth‑фонду. Новий інструмент зробить п’ять‑шість великих інвестицій як у вже наявні портфельні компанії, так і в нові стартапи, розповіла особа, знайома зі стратегією Benchmark.

Два нові фонди — не єдині зміни в Benchmark. За останні два роки компанія суттєво оновила склад своїх генеральних партнерів.

У 2024 році Майлз Грімшоу залишив фонд і повернувся до Thrive Capital. Торік Сара Тавел — перша й поки єдина жінка‑генеральний партнер Benchmark — перейшла в менш залучену роль venture‑партнерки, а Віктор Лазарте пішов, щоб запустити власний венчурний фонд.

Щоб підсилити команду, Benchmark, який традиційно працює з чотирма‑шестома генеральними партнерами, запросив двох відомих інвесторів: згаданого Рендла, якого переманили з Kleiner Perkins, та Джека Альтмана, брата CEO OpenAI Сема Альтмана. Ці кроки свідчать, що навіть Benchmark, який довго визначався своєю стійкістю до зростання, тепер вважає еру AI такою, що потребує іншої гри — більше капіталу, більше стадій і нової крові за партнерським столом.

Джерело

TechCrunch

Спеціальний випуск подкасту УТ‑2 у форматі «МВД», записаний спільно з DOu, зібрав трьох добре відомих в українській тех‑спільноті інженерів і менеджерів: Юрка Федоренка, Євгена Ковалевського та Сашу Соловйова. Вони говорили про те, як змінюється найм розробників, що робити зі співбесідами в епоху LLM і як будувати команди без штучного роздування штатів.

Ця розмова оголює одразу кілька болючих точок українського ринку: фетиш конкретного стеку, перебільшені вимоги до embedded‑досвіду в мілтеку, нерозуміння ролі поведінкових інтерв’ю та хаотичний «ріст заради росту». І водночас показує, що навіть McDonald’s і Superhuman можуть бути корисними орієнтирами для українських продуктів і сервісних компаній.

Коли «5 років з конкретним фреймворком» стає пасткою

Одна з головних претензій до українського ринку найму — одержимість конкретним стеком і роками досвіду саме з ним. В описах вакансій це виглядає знайомо: «3+ років з React», «5+ років з Nest.js», «обов’язковий досвід з таким‑то фреймворком».

На перший погляд, це виглядає прагматично: компанія хоче мінімізувати ризики й отримати людину, яка «одразу поїде». Насправді ж така практика різко звужує пул кандидатів і гальмує розвиток як ринку, так і самих компаній.

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

По‑друге, така логіка підштовхує до консервації стеку. Коли HR і менеджери звикають мислити категоріями «N років з X», будь‑яка спроба перейти на новий фреймворк або мову перетворюється на кадрову кризу: ринку ще немає, а вимоги вже є. У результаті компанії або застрягають на застарілих технологіях, або змушені переплачувати за обмежену кількість «правильних» кандидатів.

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

У підсумку ринок отримує парадокс: вакансії «з досвідом саме в нашому стеку» висять місяцями, а сильні інженери, які могли б закрити ці задачі, навіть не потрапляють у воронку, бо не відповідають формальним вимогам.

Embedded як «священна корова» мілтеку: штучний дефіцит своїми руками

Найяскравіше ця проблема проявляється в мілтек‑компаніях. Саша Соловйов звертає увагу, що там часто вимагають попередній досвід саме в embedded‑розробці. Формулювання на кшталт «обов’язковий досвід embedded» стали де‑факто стандартом для вакансій, пов’язаних із дронами, бортовими системами, сенсорами.

Проблема в тому, що embedded‑розробників на ринку об’єктивно мало. Це історично вузька ніша, яка до повномасштабної війни не була масовим напрямком в Україні. Коли десятки нових мілтек‑компаній одночасно починають шукати людей з однаковим бекграундом, дефіцит стає неминучим. Але значною мірою він штучний.

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

Якщо людина вже має глибокий досвід у C/C++, системному програмуванні, роботі з мережами чи перформансом, перехід в embedded для неї — це радше адаптація до контексту, ніж повноцінне «навчання з нуля». Вимога «2–3 роки embedded» у такому разі перетворюється на бар’єр, який не має реального технічного сенсу, але суттєво ускладнює найм.

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

Це не означає, що специфіку embedded можна ігнорувати. Але замість того, щоб робити з неї фільтр «допуску до професії», логічніше будувати процеси онбордингу: внутрішні гайди, менторство, невеликі стартові задачі, які дозволяють швидко набрати критичну масу знань.

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

Поведінкові інтерв’ю проти епохи LLM: що ще можна міряти

На тлі стрімкого розвитку LLM і «підказувалок у вусі» логічно звучить теза, що класичні технічні співбесіди втрачають сенс. Якщо кандидат може під час інтерв’ю отримувати допомогу від моделей, а в реальній роботі й так користуватиметься ними щодня, що взагалі перевіряти?

Одна з відповідей — змістити фокус з «уміння писати код тут і зараз» на те, як людина мислить і поводиться в реальних ситуаціях. Саме тут на перший план виходять поведінкові інтерв’ю.

Учасники обговорення підкреслюють: поведінкові питання й розбір конкретних прикладів з минулого досвіду залишаються корисними навіть у світі, де LLM можуть згенерувати будь‑який фрагмент коду. Причина проста: вони міряють не знання синтаксису, а реальні патерни поведінки.

Класичний підхід — формат STAR (Situation, Task, Action, Result). Кандидата просять описати конкретну ситуацію: що сталося, яке завдання стояло, які дії він зробив і до якого результату це призвело.

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

Це не панацея: у глобальному наймі, де компанії працюють з людьми з десятків країн, частина попередніх роботодавців може вже не існувати, а контакти — загубитися. Але там, де референси доступні, зв’язка «поведінкове інтерв’ю + точковий референс‑чек» дає значно більше інформації, ніж абстрактне «ну він норм, працював добре».

Показовий приклад — Superhuman. Євген Ковалевський згадує їхні детальні референс‑форми з великою кількістю конкретних запитань. Це не формальність на кшталт «оцініть кандидата за шкалою від 1 до 5», а структурований інструмент збору зворотного зв’язку.

Форма може починатися з простого радіобатона, але далі обов’язково йде відкрите питання: «Чому ви так вважаєте?», «Опишіть, як саме це проявлялося», «Які сильні сторони ви виділили б?». Такий підхід змушує референта згадувати конкретні ситуації, а не давати загальні оцінки.

Так, це забирає час. Хтось, як у випадку зі швейцарською компанією, може відмовитися заповнювати півторагодинну анкету й запропонувати натомість п’ятихвилинну розмову телефоном. Але суть не в форматі, а в рівні конкретики. Чим точніші питання — тим менше простору для розмитих відповідей.

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

McDonald’s як еталон системності: що може запозичити ІТ

Згадка McDonald’s у контексті інтерв’ю може звучати як жарт, але насправді це один із найяскравіших прикладів того, як масовий найм може бути системним.

У McDonald’s поведінкові індикатори вимірюють за допомогою стандартизованих процедур на співбесідах. Для кожної ролі визначені ключові компетенції — від роботи в команді до стресостійкості — і під них підібрані конкретні питання та сценарії. Інтерв’юери проходять навчання, щоб однаково інтерпретувати відповіді кандидатів.

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

Для ІТ‑компаній, які часто наймають «по відчуттю» або покладаються на харизму техлідера, такий підхід може бути корисним орієнтиром. Стандартизовані поведінкові індикатори не означають бюрократію, якщо вони прив’язані до реальних задач.

Наприклад, для продуктової ролі можна чітко визначити, що означає «уміння працювати з невизначеністю»: скільки разів людина запускала фічі без повного набору даних, як документувала ризики, як комунікувала з командою. Для інженера — як він поводиться, коли прод падає вночі: чи бере участь у розборі, чи ініціює постмортеми, чи пропонує зміни в процесах.

McDonald’s показує, що навіть при масовому наймі можна міряти поведінку не інтуїтивно, а через стандартизовані процедури. Для українських ІТ‑компаній, особливо тих, що планують масштабування, це сигнал: без чітко описаних поведінкових очікувань ріст штату неминуче перетвориться на хаос.

Ріст з 20 до 40 за пів року: чому це майже завжди погана ідея

Ще одна важлива тема — темпи росту команд. На ринку досі живе уявлення, що швидке збільшення штату — ознака успіху. Компанія, яка за пів року виросла з 20 до 40 людей, часто подає це як досягнення.

Учасники дискусії дивляться на це значно скептичніше. На їхню думку, ріст компанії з 20 до 40 людей за пів року зазвичай є поганою або штучною метою, якщо ціль — якісний результат, а не роздування штату.

Аргументи тут радше операційні, ніж ідеологічні. По‑перше, онбординг. Навіть якщо припустити, що всі нові люди сильні, команда фізично не встигає їх якісно інтегрувати: пояснити контекст, процеси, технічні рішення, неформальні правила. У результаті частина новачків місяцями працює «в тумані», приймаючи рішення, які суперечать одна одній.

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

По‑третє, мотивація. Якщо ріст продиктований не реальними бізнес‑потребами, а бажанням «виглядати більшими» або отримати бонус за розширення штату, це швидко відчувається всередині. Люди бачать, що задачі розмиваються, пріоритети змінюються щотижня, а нові колеги з’являються швидше, ніж зникають старі проблеми.

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

Ці люди отримують мандат запускати під себе невеликі команди — по двоє‑троє інженерів на старті. Такий підхід дає кілька переваг.

По‑перше, кожен новий напрямок має власного «власника», який відповідає за результат, а не просто за кількість закритих вакансій.

По‑друге, маленькі команди легше онбордити й синхронізувати з рештою організації.

По‑третє, якщо якийсь напрямок не «злетить», компанія втрачає не 20 людей, а кілька, і може відносно безболісно перерозподілити їх на інші задачі.

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

Від стеку до поведінки: як може виглядати здоровий найм

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

По‑перше, відмова від фетишу конкретного стеку. Замість «3+ років з X» — фокус на базових інженерних навичках, здатності вчитися й адаптуватися. Для embedded і мілтеку це означає готовність брати сильних системних інженерів і вкладатися в їхнє входження, а не чекати міфічних «готових» кандидатів.

По‑друге, зміщення акценту з технічних «олімпіад» на judgment і поведінку. Формати на кшталт «покажи, який з двох фрагментів коду кращий і чому» дозволяють міряти здатність оцінювати рішення, а не лише писати їх з нуля. Поведінкові інтерв’ю й структуровані референс‑чеки — міряти, як людина діє в реальних ситуаціях.

По‑третє, системність у масштабуванні. Замість гордих кейсів «ми виросли з 20 до 40 за пів року» — чесна відповідь на питання «навіщо нам ще 20 людей і хто ними керуватиме». Якщо відповідь зводиться до «так прийнято на ринку» або «так легше вибити бюджет», це сигнал, що ріст штату може стати проблемою, а не досягненням.

Ця модель не є революційною. Багато з її елементів давно використовують глобальні компанії — від McDonald’s до Superhuman. Але для українського ринку, який одночасно переживає війну, релокацію й трансформацію ІТ‑сектора, вона може стати способом уникнути найгірших пасток: штучного дефіциту кадрів, токсичного овернайму й ілюзії, що «правильний стек» вирішує все.

Висновок: найм як стратегічна інженерна задача

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

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

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

У світі, де LLM можуть допомогти написати будь‑яку функцію, саме ці якості стають головною конкурентною перевагою — як для інженерів, так і для компаній.

Джерело

Співбесіди в минулому? Rust vs Zig. Blue Origin наздоганяє SpaceX? Дата-центри в космосі. mvd #1 — УТ‑2

Подкаст УТ-2 у спеціальному випуску «МВД», записаному спільно з DOu, зібрав трьох добре відомих в українській техтусовці інженерів і менеджерів: Юрка Федоренка, Євгена Ковалевського та Сашу Соловйова. На тлі буму LLM-інструментів і втоми від класичних «алгоритмічних» співбесід вони обговорюють, що саме сьогодні варто міряти в кандидатах і як це робити без ілюзій та самообману.

У центрі розмови — поняття judgment: здатність інженера оцінювати якість рішень, коду й компромісів, а не просто вміти швидко писати функції під таймер. Паралельно учасники переосмислюють роль алгоритмів, фундаментальних знань і поведінкових інтерв’ю в епоху, коли будь-яку «задачку з літкоду» можна розв’язати з підказкою великої мовної моделі.

Judgment як новий головний скіл: від «умію писати код» до «умію обирати правильний код»

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

Учасники дискусії прямо називають judgment одним із ключових сучасних скілів інженера. Йдеться не про «інтуїцію» в абстрактному сенсі, а про здатність:

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

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

Саме це, на думку співрозмовників, і є тим, що реально відрізняє сильного інженера від посереднього. І саме це майже не міряють класичні співбесіди, які зводять оцінку до «написав код — не написав», «пройшли тести — не пройшли».

Звідси й радикальні пропозиції: замість того, щоб змушувати кандидата під тиском часу реалізовувати алгоритм, варто прямо тестувати judgment — здатність оцінювати вже написаний код і аргументувати свій вибір.

Два шматки коду замість однієї задачі: як напряму міряти інженерний judgment

Один із запропонованих форматів інтерв’ю звучить майже провокаційно просто: показати кандидату два варіанти коду, які реалізують одну й ту саму функцію, і попросити обрати кращий та пояснити, чому саме.

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

По-перше, він змушує кандидата читати й аналізувати чужий код, а не лише писати свій. У реальній роботі це базова активність: рев’ю пул-реквестів, розбір легасі, інтеграція з чужими модулями. Людина, яка не вміє швидко зрозуміти чужий код і побачити в ньому проблеми, буде слабким ланцюгом у будь-якій команді.

По-друге, завдання на вибір «кращого» варіанту неминуче виводить розмову на критерії якості. Кандидат мусить проговорити, що для нього важливо: читабельність, простота, продуктивність, безпека, передбачуваність поведінки, тестованість. Саме в цих поясненнях і проявляється judgment.

По-третє, такий формат добре масштабується під різні рівні. Для джунів це може бути порівняння двох простих функцій з очевидними smell’ами. Для сеньйорів — аналіз двох архітектурних підходів чи різних реалізацій складнішого модуля. В обох випадках інтерв’юер бачить не лише «чи знає людина синтаксис», а й те, як вона мислить про код як про систему.

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

Алгоритми як індикатор глибини, а не як самоціль

Окрема лінія розмови — ставлення до алгоритмів. З одного боку, учасники визнають: люди, які добре розуміють алгоритми, зазвичай краще працюють і глибше розуміють інші аспекти інженерії. Це не випадковість.

Алгоритмічне мислення вчить:

бачити структуру задачі,
оцінювати складність рішень,
розуміти, де вузькі місця,
мислити в категоріях ресурсів — часу, пам’яті, мережі.

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

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

Через це питання на кшталт «реалізуй quicksort на дошці» мають, на думку співрозмовників, дуже обмежену користь. Вони слабо корелюють із тим, що людина робитиме щодня, і часто відсікають сильних практиків, які давно не тренувалися в «олімпіадному» форматі, але чудово тягнуть продакшен.

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

LLM проти літкоду: коли алгоритмічні співбесіди втрачають сенс

Ще один фактор, який змушує переглядати цінність класичних задачок, — поява й масове поширення LLM-інструментів. Учасники прямо говорять: сьогодні «читити» на алгоритмічних співбесідах стало набагато простіше.

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

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

На цьому тлі пропозиція змістити фокус із «написати алгоритм» на «оцінити рішення» виглядає не лише сучаснішою, а й більш чесною. LLM чудово справляються з генерацією коду, але значно гірше — з розумінням контексту конкретної команди, бізнесу, обмежень продакшену. Саме judgment, а не швидкість набору, стає тим, що важко автоматизувати.

Це не означає, що алгоритми треба повністю викинути з процесу відбору. Але їхня роль змінюється: замість того, щоб перевіряти, чи пам’ятає кандидат конкретну реалізацію, варто дивитися, як він міркує про складність, компроміси, граничні випадки — у поєднанні з реалістичними задачами й кодом.

Переказ, твір і поведінкові інтерв’ю: чому вміння формулювати важливе не менше за вміння кодити

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

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

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

У технічних командах ця здатність критична з кількох причин.

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

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

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

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

Усе це напряму пов’язано з поведінковими інтерв’ю. Учасники наголошують: навіть в епоху LLM поведінковий блок залишається одним із найстійкіших інструментів оцінки. Якщо кандидат описує реальні ситуації зі свого минулого досвіду, пояснює, як діяв, що пішло не так, що змінив би — це важко сфабрикувати «на льоту» за допомогою моделі. А ще легше перевірити референсами, якщо ставити конкретні запитання.

Показовий приклад — детальні референс-форми в Superhuman, де від реферера вимагають не загального «норм/не норм», а конкретики: що саме людина робила добре, як це проявлялося, які були слабкі сторони. Такий підхід різко підвищує якість сигналу й дозволяє краще зрозуміти, як кандидат поводиться в реальних ситуаціях, а не лише в умовах інтерв’ю.

Фундамент проти ритуалів: що залишиться важливим у співбесідах завтра

Якщо звести дискусію до кількох висновків, картина виглядає так.

По-перше, класичні алгоритмічні задачі на кшталт quicksort як головний інструмент відбору відживають своє. Вони погано відображають реальну роботу, легко піддаються «чітерству» через LLM і часто перетворюються на ритуал заради ритуалу.

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

По-третє, на перший план виходить оцінка judgment: здатності читати й оцінювати код, обирати між альтернативами, аргументувати свій вибір. Формати на кшталт «два варіанти коду — обери кращий і поясни» дають прямий доступ до цього скіла й краще відображають те, що інженер робитиме щодня.

По-четверте, вміння формулювати й переказувати інформацію, працювати з вимогами, чітко описувати проблеми й рішення стає не менш важливим, ніж уміння писати код. Це критично і для командної роботи, і для взаємодії з замовниками, і для ефективного використання LLM-інструментів.

По-п’яте, поведінкові інтерв’ю та якісні референси залишаються одним із найнадійніших способів зрозуміти, як людина поводиться в реальних ситуаціях. На відміну від алгоритмічних задач, їх складніше автоматизувати й підмінити підказками.

Усе це не означає, що завтра технічні співбесіди зникнуть. Але їхній фокус уже зміщується: від перевірки пам’яті й «олімпіадних» навичок — до оцінки judgment, комунікації та здатності працювати з реальними, а не штучними задачами. І ті компанії, які першими адаптують свої процеси під цю реальність, матимуть відчутну перевагу на ринку, де сильних інженерів менше, ніж вакансій, а LLM давно навчилися писати код не гірше за середнього кандидата.

Джерело

Співбесіди в минулому? Rust vs Zig. Blue Origin наздоганяє SpaceX? Дата-центри в космосі. mvd #1 — УТ-2

У спеціальному випуску подкасту УТ-2 у форматі «МВД», записаному спільно з DOu, інженери та лідери команд Юрко Федоренко, Євген Ковалевський та Саша Соловйов обговорюють, як змінюється підхід до технічних співбесід. На тлі поширення AI‑асистентів, зростання віддаленої роботи та втоми ринку від класичного «літкоду» вони пропонують радикальніший сценарій: замінити більшість технічних інтерв’ю оплачуваними тестовими днями або тижнями реальної роботи в команді.

Це не просто ще одна мода у HR. Йдеться про спробу переосмислити саму логіку відбору інженерів: від абстрактних задач на дошці до вимірюваної продуктивності в реальному середовищі.

Кінець епохи літкоду: чому класичні технічні співбесіди втрачають сенс

Класична модель технічної співбесіди — задачі на алгоритми, структури даних, іноді системний дизайн — десятиліттями була стандартом у великих технологічних компаніях. Але сьогодні її корисність дедалі частіше ставлять під сумнів.

По‑перше, ринок змінився технологічно. Доступність LLM‑асистентів, готових бібліотек і стандартних реалізацій алгоритмів робить знання на рівні «напиши quicksort з нуля» дедалі менш релевантним до щоденної роботи. Учасники дискусії прямо визнають: у реальних проєктах розробники майже ніколи не пишуть такі алгоритми самостійно, вони беруть готові реалізації з бібліотек, стандартних бібліотек мов або фреймворків.

По‑друге, з’являється розрив між тим, що міряє співбесіда, і тим, що справді потрібно в роботі. Питання на кшталт «реалізуй quicksort» або «розв’яжи нетривіальну задачу з масивами» мають обмежену кореляцію з реальними задачами продуктового інженера, який працює з легасі‑кодом, інтеграціями, бізнес‑логікою, комунікацією з замовниками та командою.

По‑третє, зростає роль judgment — здатності оцінювати якість рішень, коду, компромісів. Саме тому Ковалевський пропонує замість класичного кодінтерв’ю формат, де кандидату показують два варіанти коду з однаковою функціональністю й просять обрати кращий та пояснити, чому. Це вже не про механічне відтворення алгоритму, а про інженерне мислення.

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

На цьому тлі ідея радикальної заміни технічних співбесід тестовими періодами реальної роботи виглядає не просто провокацією, а логічною відповіддю на зміну контексту.

Реальна робота як інтерв’ю: як мають виглядати тестові дні та тижні

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

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

як кандидат взаємодіє з командою, чи вміє ставити запитання, домовлятися, уточнювати вимоги;

як він працює з існуючим кодом, інфраструктурою, інструментами;

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

З іншого боку, кандидат отримує шанс побачити реальну культуру, процеси, стиль комунікації, а не лише polished‑версію компанії з презентації рекрутера. Це важливо в умовах, коли помилка з вибором місця роботи може коштувати місяців часу й нервів.

Євген Ковалевський прямо говорить, що кодінтерв’ю з літкодом і системним дизайном можна й варто замінювати офлайн‑форматами та тестовими днями. На його думку, саме там найкраще проявляється реальна продуктивність кандидата. В онлайні, вважає він, доцільно залишати лише те, що складно або дорого перенести в офлайн: перевірку досвіду, поведінкову частину, базову валідацію адекватності очікувань.

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

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

Оплачувані тестові дні: як уникнути безкоштовної праці й зробити процес чесним

Одна з ключових етичних і практичних проблем тестових завдань — ризик перетворення кандидата на безкоштовну робочу силу. Коли компанія дає складне завдання, яке можна використати в продакшені, але не платить за нього, це викликає закономірне роздратування й недовіру.

Тому в обговоренні наголошується: тестові дні мають бути оплачуваними. Це не лише питання справедливості, а й інструмент підвищення залученості кандидата. Людина, яка отримує оплату за свій час, сприймає тестовий період як повноцінну співпрацю, а не як «іспит без гарантій».

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

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

Попри очевидні переваги, учасники визнають, що в Україні тестові дні або тижні як елемент воронки найму поки що дуже непоширені. Ринок досі тяжіє до класичної моделі: резюме, одна‑дві технічні співбесіди, можливо, невелике тестове завдання — і рішення. Причини можуть бути різні: інерція процесів, небажання компаній платити за відбір, страх «загальмувати» масштабування. Але саме тому дискусія про альтернативи виглядає своєчасною.

Український ринок і вузький стек: чому тестові тижні особливо потрібні тут

На українському ринку найму, за спостереженнями учасників, домінує підхід «наймаємо під конкретний стек і роки досвіду з певним фреймворком». Це означає, що вакансії часто формулюються як «N років з React», «M років з конкретним embedded‑стеком» тощо. Такий підхід спрощує фільтрацію резюме, але має серйозні побічні ефекти.

По‑перше, він штучно звужує пул кандидатів. Саша Соловйов наводить приклад мілтек‑компаній, які шукають розробників з попереднім досвідом в embedded. На ринку таких спеціалістів об’єктивно мало, і вимога «обов’язково embedded‑бекграунд» перетворюється на самосаботаж. При цьому, на думку учасників, хороший інженер може розібратися зі специфікою embedded за тиждень або навіть за два дні, якщо має сильну базу й мотивацію.

По‑друге, фокус на роках досвіду з конкретним інструментом погано вимірює реальну здатність вчитись і адаптуватися. Людина, яка п’ять років працювала з одним фреймворком у вузькому контексті, може виявитися менш гнучкою, ніж інженер з ширшим технічним кругозором, але без «правильних» років у резюме.

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

Показовою є й дискусія про темпи росту команд. Учасники скептично ставляться до сценаріїв, коли компанія зростає з 20 до 40 людей за пів року. На їхню думку, такі цілі часто штучні й продиктовані бажанням «роздути» штат, а не реальними потребами продукту. Якщо ж мета — якісний результат, а не цифри в презентації для інвесторів, то швидке нарощування кількості інженерів рідко буває виправданим.

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

Алгоритми, LLM і поведінкові інтерв’ю: що лишається в онлайн‑частині воронки

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

В онлайні, на їхню думку, логічно залишити:

перевірку досвіду — через обговорення попередніх проєктів, ролей, відповідальності;

поведінкову частину інтерв’ю — з використанням структурованих підходів на кшталт STAR, коли кандидата просять описати конкретні ситуації, дії та результати;

базову валідацію технічного рівня без глибокого занурення в алгоритмічні задачі, які легко делегуються LLM.

Цікаво, що поведінкові інтерв’ю розглядаються як відносно стійкі до впливу LLM. Щоб вигадати правдоподібні історії про минулий досвід, потрібно завантажити в модель багато контексту про реальні компанії, ролі, конфлікти, що робить такий обман складним і ризикованим. До того ж, ці історії можна перевірити через референси.

Саме референси теж зазнають переосмислення. Ковалевський наводить приклад Superhuman, де референс‑форми містять велику кількість конкретних запитань: не просто «як вам ця людина», а «що саме вона робила краще за інших», «які сильні сторони проявлялись у таких‑то ситуаціях», «опишіть конкретні приклади». Це контрастує з типовою практикою, коли рекрутер телефонує й ставить загальне запитання «ну як він/вона взагалі?», отримуючи настільки ж загальну відповідь.

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

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

Висновок: тестові дні як наступний логічний крок еволюції найму

Дискусія в подкасті УТ-2 показує, що ринок технічного найму стоїть на порозі суттєвих змін. Класична модель з літкодом, системним дизайном на дошці й абстрактними тестовими завданнями дедалі гірше відповідає реаліям, де:

алгоритми рідко пишуть з нуля;

LLM знімають частину «механічної» роботи;

ключовими стають judgment, здатність швидко входити в нові домени й ефективно працювати в команді.

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

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

Джерело

Подкаст УТ-2, спеціальний випуск «МВД» спільно з DOu: https://www.youtube.com/watch?v=3oh4k_NFV5Y

Штучний інтелект уже автоматизує частину роботи білих комірців і стрімко проникає в бізнес‑процеси. Та попри вражаючі цифри на кшталт сотень мільйонів користувачів ChatGPT, темпи реальних змін у компаніях будуть значно повільнішими, ніж очікує публіка. На це звертають увагу учасники подкасту Lenny’s Podcast, розбираючи, як ШІ вписується в історичну логіку технологічних революцій.

200 років автоматизації: що в цьому нового

За останні два століття кожна велика технологія проходила схожий цикл:

• спершу вона автоматизує частину існуючих завдань і «з’їдає» певну кількість робочих місць;
• потім на основі цієї ж технології виникають нові ролі, професії та цілі індустрії.

Парова машина, електрифікація, комп’ютери, інтернет — усі вони спершу загрожували зайнятості, але в підсумку створювали нові типи робіт. Питання сьогодні: чи є ШІ якісно іншим, здатним зламати цю історичну модель?

Один з аргументів «за особливість» ШІ — швидкість розповсюдження. На відміну від промислових революцій минулого, не потрібно чекати, поки підприємства закуплять дороге обладнання. Достатньо підключення до інтернету, і програмний сервіс миттєво масштабується.

Масове прийняття ≠ миттєва трансформація

Показовий приклад — ChatGPT, який зумів вийти на сотні мільйонів щотижневих користувачів, спираючись на вже існуючу аудиторію інтернету. Це справді швидше, ніж розповсюдження персональних комп’ютерів чи смартфонів.

Але масове користування не означає, що економіка так само швидко перебудовується:

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

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

Гальмо №1: корпоративні цикли впровадження

Ключовий фактор, який стримує темпи впливу ШІ на економіку, — це корпоративні цикли ухвалення рішень. У великих компаніях:

• продаж складних рішень триває довше, ніж цикл залучення венчурного фінансування стартапом;
• інтеграція нового продукту в існуючу ІТ‑інфраструктуру розтягується на роки;
• у критичних секторах (аерокосміка, охорона здоров’я тощо) вимоги до надійності та сертифікації ще жорсткіші.

Ніхто не буде «виривати» умовний SAP чи іншу базову ERP‑систему лише тому, що з’явився модний ШІ‑продукт. Навіть якщо технологія обіцяє значну економію, шлях від пілотного проєкту до повної заміни ядра корпоративної системи може займати 3, 5 чи 10 років.

У результаті:

• трансформація відбувається не одномоментно, а поетапно;
• різні галузі рухаються з різною швидкістю;
• хвиля автоматизації розтягується в часі, а не накриває ринок за один‑два роки.

Як саме буде змінюватися робота

Навіть якщо фундаментальні системи не змінюються миттєво, ШІ поступово переформатовує робочі ролі. Це відбувається у кілька кроків:

1. Точкова автоматизація
   Окремі завдання — складання текстів, аналіз документів, підготовка звітів — перекладаються на моделі ШІ як «асистента».

2. Перебудова процесів
   Коли з’являється впевненість у стабільності інструментів, компанії починають змінювати самі процеси: хто що робить, які етапи можна прибрати, де потрібна людина, а де достатньо моделі.

3. Переосмислення ролей
   Частина функцій зникає, але виникають нові: від налаштування й контролю ШІ‑систем до проєктування процесів, які максимально використовують їхні можливості.

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

Джерело

AI won’t move as fast as you think — Lenny’s Podcast

Келсі Гайтовер — один із найвідоміших голосів у світі Kubernetes та сучасної інфраструктури. Він закінчив школу у 1999‑му, кинув коледж через два тижні, самостійно підготувався до сертифікації A+ за книжкою за 35 доларів, починав як інсталятор DSL‑модемів, а згодом став Distinguished Engineer у Google — одним із найвищих технічних рангів компанії. У 43 роки він пішов з Google і фактично з великої тех‑індустрії, зробивши те, на що мало хто наважується: добровільно завершив кар’єру на самому верху.

Його історія — не лише про «нетиповий шлях у тех», а й про те, як людина без класичної освіти вчиться оцінювати власну ринкову вартість, відмовляється від надзвичайно вигідної пропозиції від CEO Microsoft і зрештою вирішує, що час сповільнитися й переосмислити життя поза роботою.

Від A+ до Distinguished Engineer: як нетиповий шлях доходить до вершини

Щоб зрозуміти масштаб контрасту, варто повернутися до відправної точки. У 1999 році Гайтовер закінчує школу. Замість того, щоб іти традиційним шляхом — чотири роки університету, стажування, перша «джуніорська» роль, — він обирає інший маршрут.

У Джорджії діє програма HOPE: з оцінками «B» і вище можна безкоштовно навчатися в будь‑якому державному виші, включно з престижними Georgia Tech чи Georgia State. Гайтовер пробує: вступає до місцевого університету, але вже за два тижні розуміє, що темп навчання не відповідає тому, що відбувається у світі. На телебаченні — черги за новими версіями Windows, перехід від dial‑up до високошвидкісного інтернету, ейфорія дотком‑ери. У вакансіях — Sun, IBM, системне адміністрування, але без зрозумілого мосту, як туди потрапити.

Він виходить із цієї дилеми через сертифікацію. У книжковому магазині знаходить гайд до CompTIA A+ — офіційного іспиту для технічної підтримки. Книжка коштує 35 доларів, коледж не потрібен, сертифікат фігурує в реальних вакансіях. Гайтовер купує її, вивчає «від обкладинки до обкладинки», тренується на тестах з CD, повертається до розділів, де помиляється, і зрештою складає іспит у тестовому центрі за десять хвилин замість відведеної години.

Це перший важливий переломний момент: він бачить, що індустрія визнає результат самостійного навчання. A+ відкриває йому двері на ярмарок вакансій, де шукають підрядників для масового переходу з dial‑up на DSL. Так він отримує свою першу «офіційну» технічну роботу — інсталює модеми, тягне кабелі, налаштовує підключення.

Далі буде довгий шлях — від малого бізнесу до великих дата‑центрів, від скриптів до хмарної інфраструктури. Але ключовий факт залишається: Гайтовер так і не повертається до класичної вищої освіти. Він самонавчанням, практикою і репутацією в спільноті доходить до рівня Distinguished Engineer у Google — позиції, яку зазвичай пов’язують із PhD, десятиліттями досвіду в корпораціях і бездоганним «резюме з обкладинки».

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

Лист від Сатьї Наделли і «доданий нуль»: як зовнішня пропозиція змінює уявлення про цінність

Кульмінаційний епізод цієї історії починається з електронного листа. У розпал кар’єри, вже як один із найвпливовіших людей у Kubernetes‑спільноті, Гайтовер отримує повідомлення від Сатьї Наделли, CEO Microsoft. Це не типовий рекрутинговий пінг від HR, а персональний контакт з першої особи компанії, яка активно бореться за позиції в хмарі та відкритому коді.

У листі — PDF із пропозицією. Гайтовер відкриває документ і бачить, що «до рівняння додали нуль». Формулювання промовисте: мова не про невелике підвищення, а про кардинально інший порядок цифр. Він прямо визнає, що навіть не знав, що такі рівні компенсації взагалі доступні для людей з його бекграундом — випускника школи 1999 року, який обрав A+ замість диплому.

У тех‑індустрії давно не секрет, що топові індивідуальні контриб’ютори й керівники можуть отримувати компенсаційні пакети з багатьма нулями. Але для конкретної людини момент, коли це перестає бути абстрактною «історією з Хабра» і стає особистою пропозицією, часто змінює сприйняття себе. Гайтовер опиняється саме в такій точці: його нетипова траєкторія раптом отримує підтвердження в найпрямішій формі — грошима й увагою CEO компанії масштабу Microsoft.

Важливо, що він сприймає цю пропозицію серйозно. Це не жест для підняття ставок у переговорах, не «подивитися, що там пропонують». Він реально розглядає перехід до Microsoft як наступний крок кар’єри. Це ще один сигнал: навіть на рівні Distinguished Engineer у Google зовнішні можливості залишаються реальними, а не символічними.

Найбільше підвищення в кар’єрі: як зовнішній офер перезапускає внутрішні очікування

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

Сам факт, що CEO іншої технологічної корпорації готовий платити суттєво більше, ніж ти отримуєш зараз, стає потужним аргументом у будь‑якій розмові про компенсацію. Для Гайтовера ця пропозиція стає тригером для найбільшого підвищення в його кар’єрі. Він прямо говорить про те, що саме цей офер «додав нуль до рівняння» і дозволив йому побачити, де насправді проходить ринкова планка для його рівня впливу.

Це важливий урок для всієї індустрії. У великих компаніях компенсаційні сітки, грейди й внутрішні політики часто створюють інерцію: навіть дуже сильні інженери роками рухаються невеликими кроками, не ставлячи під сумнів базову рамку. Зовнішній офер, особливо з іншої «великої п’ятірки», може радикально змінити цю рамку — не лише для конкретної людини, а й для її менеджерів і HR.

У випадку Гайтовера це не історія про шантаж чи агресивні торги. Це радше про прозорість ринку: якщо одна з найбільших компаній світу оцінює твою роботу в певну суму, важко переконливо пояснити, чому інша компанія того ж масштабу має платити суттєво менше. У результаті він залишається в Google, але з компенсацією, яка відповідає новому розумінню його цінності.

Для інженерів, які мріють про Staff/Principal/Distinguished‑рівні, цей епізод показовий. Навіть на найвищих щаблях кар’єрної драбини зовнішні пропозиції залишаються не лише інструментом переходу, а й способом «калібрувати» власну позицію на ринку. Іноді найважливіше, що дає офер, — це не нова робота, а нова точка відліку.

Чому гроші — не все: відмова від Microsoft і вибір на користь місії та автономії

Попри «доданий нуль» у PDF, Гайтовер не переходить до Microsoft. Це рішення виглядає парадоксальним, якщо дивитися на нього лише через призму компенсації. Але воно логічне, якщо врахувати інші фактори, які він ставить вище за гроші.

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

По‑друге, це автономія. Рівень Distinguished Engineer у Google — це не просто високий грейд. Це можливість впливати на технічний напрямок компанії, будувати мости між командами, формувати бачення. Зовнішній офер, навіть дуже щедрий, не гарантує такої ж свободи дій із першого дня. Для людини, яка звикла не лише писати код, а й формувати дискурс індустрії, це може бути критичним.

По‑третє, це спосіб життя. До цього моменту Гайтовер уже багато років жив у режимі постійного прискорення: від перших підробітків у McDonald’s у 14 років до глобальних конференцій, відкритого коду й ролі публічного лідера. Перехід до нової корпорації часто означає ще один виток інтенсивності — нові очікування, нові політичні конфігурації, нові зобов’язання. На певному етапі кар’єри питання «чи хочу я ще більше навантаження?» стає не менш важливим, ніж «скільки мені заплатять?».

Відмова від пропозиції, яка об’єктивно виглядає «мрією» для багатьох інженерів, показує, що для Гайтовера гроші — лише один із параметрів рівняння. Він уже довів собі й індустрії, що може досягти найвищих рівнів компенсації без диплома. Далі на перший план виходять інші критерії: сенс роботи, вплив, баланс життя.

«Потрібно сповільнитися»: чому він пішов із Google і з індустрії у 43 роки

Коли хтось залишає Google на рівні Distinguished Engineer у 43 роки, це завжди викликає запитання: чому? У типовій кар’єрній логіці це вік, коли багато хто лише наближається до Staff/Principal‑рівнів, а не завершує шлях. Але для Гайтовера цей крок виглядає закономірним продовженням попередніх рішень.

Його кар’єра з самого початку розвивалася в режимі «форсажу». У 14 років він уже працює в McDonald’s, у 15 — асистент‑менеджер із ключами від магазину, відповідальний за закриття зміни й звітність перед корпорацією. У старшій школі він паралельно займається спортом, бере участь у технічних гуртках, змагається на рівні штату в AutoCAD, вчиться програмувати на TI‑BASIC на графічному калькуляторі.

Після школи він кидає коледж, працює у фастфуді, доставляє піцу, самостійно готується до A+, входить у тех через DSL‑інсталяції. Далі — роки підприємництва, сервісний бізнес, потім великі дата‑центри, автоматизація, хмари, Kubernetes, публічні виступи, open source, внутрішній вплив у Google. Це десятиліття постійного зростання, де кожен наступний крок вимагає ще більше енергії, ще більше відповідальності, ще більше публічності.

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

Рішення піти з Google і фактично з великої тех‑індустрії у 43 роки — це спосіб зафіксувати цю зміну пріоритетів. Він робить це не після вигоряння, не після скорочення, не через втрату актуальності, а на піку: з високим грейдом, сильною репутацією, фінансовою подушкою й можливістю обирати, чим займатися далі.

Для індустрії, де «успіх» часто вимірюється безперервним рухом угору — від Senior до Staff, від Staff до Principal, від Principal до VP, — такий крок виглядає майже контркультурним. Але саме в цьому його сила: він показує, що вершина кар’єрної драбини може бути не трампліном до ще більшої гонитви, а точкою, де можна зупинитися й свідомо вийти з гри.

Нетиповий шлях як право вийти з гри на власних умовах

Якщо скласти всі фрагменти історії Гайтовера — від A+ до листа від Сатьї Наделли, від найбільшого підвищення в кар’єрі до добровільного виходу з індустрії, — вимальовується важливий висновок: нетиповий шлях у тех може не лише привести до елітних ролей, а й дати людині право вийти з гри на власних умовах.

Його стартові умови були далекими від класичного «успішного» сценарію: фастфуд, відсутність університетського диплому, відсутність менторів із індустрії, які могли б показати дорогу. Він сам знаходить A+, сам готується, сам входить у тех через контрактну роботу. Далі — роки самостійного навчання, експериментів, помилок і поступового нарощування репутації.

Те, що в підсумку він стає Distinguished Engineer у Google, отримує персональний офер від CEO Microsoft із «доданим нулем» і може дозволити собі відмовитися від нього, — це не лише історія про талант і працю. Це історія про те, як індустрія, що декларує «меритократію», іноді справді винагороджує навички й вплив, а не лише дипломи й правильні логотипи в резюме.

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

Для інженерів, які сьогодні думають про довгострокову траєкторію — чи то шлях до Staff/Distinguished, чи перехід в незалежний консалтинг, чи навіть тихе планування виходу з індустрії, — ця історія дає кілька практичних орієнтирів. Зовнішні офери можуть і повинні використовуватися як інструмент для чесної оцінки своєї вартості. Гроші — важливі, але не єдині. А вершина кар’єри може бути не лише черговим щаблем, а й точкою, де можна сказати: «цього достатньо».

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

Висновок

Історія Келсі Гайтовера — це не чергова байка про «хлопця без диплому, який став зіркою». Це детальний кейс про те, як людина з нетиповим бекграундом навчається оцінювати свою цінність, використовує зовнішні пропозиції для перегляду внутрішніх очікувань, відмовляється від надзвичайно вигідних оферів, коли вони не відповідають її пріоритетам, і зрештою свідомо виходить з індустрії на піку.

Для тех‑спільноти це сигнал: кар’єрна траєкторія не зобов’язана бути нескінченним зростанням. Вона може мати чітко окреслену вершину, після якої починається інший етап життя — не менш осмислений, але вже поза рамками корпоративних грейдів і компенсаційних пакетів.

Джерело

Подкаст The Pragmatic Engineer — «Kubernetes and retiring at the top with Kelsey Hightower»

Келсі Гайтовер — один із найвпливовіших голосів у світі Kubernetes, самоук, який став Distinguished Engineer у Google і пішов з індустрії на піку кар’єри у 43 роки. Але до того, як опинитися в центрі «контейнерних воєн» і становлення Kubernetes, він встиг пройти шлях від малого підприємця до інженера, який працює з інфраструктурою масштабу сотень тисяч серверів. Саме цей досвід — у дата-центрах Google та в автоматизованому хостингу на базі Rackspace — багато в чому пояснює, чому Kubernetes виглядав для нього не як революція, а як логічний наступний крок. І чому, на його думку, вирішальним фактором прориву Kubernetes став Docker.

Від малого бізнесу до гіпермасштабу: навіщо міняти автономію на дата-центри Google

До Google Гайтовер кілька років працював підприємцем: встановлював DSL, будував мережі й інфраструктуру для малих бізнесів, відкривав власний комп’ютерний магазин. Це давало автономію, але й накладало жорстку стелю на масштаб: кожен новий клієнт означав новий набір ручної роботи.

Перехід у Google як техніка дата-центру став свідомим обміном цієї автономії на доступ до гіпермасштабної інфраструктури. Йшлося вже не про десятки чи сотні машин, а про об’єкти, де працювали порядки сотень тисяч серверів. Для людини, яка щойно ще самостійно збирала ПК у маленькому магазині, це був інший всесвіт.

У таких дата-центрах кожна операція — від заміни планки пам’яті до діагностики материнської плати — множиться на величезні обсяги. Будь-яка неефективність або помилка масштабуються разом із залізом. Саме тут формується мислення, яке згодом стане природним підґрунтям для Kubernetes: усе, що можна автоматизувати, потрібно автоматизувати; усе, що можна стандартизувати, має бути стандартизованим.

Метріки проти інтуїції: як Google перетворив ремонт серверів на інженерну дисципліну

Робота техніка в дата-центрі Google середини 2000‑х була далекою від образу «людини з викруткою». Це була роль, жорстко прив’язана до метрик. Кожного співробітника оцінювали за двома ключовими параметрами: обсяг виконаних ремонтів і точність цих ремонтів.

Обсяг означав, скільки машин технік встигав відремонтувати за певний період. Але цього було недостатньо. Важливішою була точність, яку вимірювали за тим, як часто «відремонтовані» сервери поверталися в ремонт протягом 30–60 днів. Якщо машина поверталася, це означало, що початкова діагностика була хибною, а проблема — не усунена.

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

На цьому тлі показники Гайтовера виділялися. Він тримав точність на рівні високих 90% і при цьому ремонтував приблизно втричі більше машин, ніж багато колег. Це не було результатом «героїзму» чи понаднормової роботи — ключем стала системна оптимізація процесу.

Shell-скрипти, світлодіоди й народження культури автоматизації

Щоб одночасно зберігати швидкість і точність, Гайтовер почав робити те, що згодом стане його фірмовим підходом: писати інструменти для власної роботи. У дата-центрі це означало shell-скрипти, які дозволяли діагностувати кілька апаратних компонентів одразу, а не перевіряти їх по одному вручну.

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

Паралельно інші інженери Google будували власні інструменти, які підсилювали ефективність операторів. Один із показових прикладів — робота Тіма Гокіна, який створив діагностичний інструмент, що використовував світлодіоди на материнській платі для індикації потенційно несправних слотів DIMM. Замість того, щоб гадати, яка саме планка пам’яті викликає проблеми, технік міг просто подивитися на підказку «в залізі».

Ці два підходи — shell-скрипти Гайтовера та апаратні підказки Гокіна — ілюструють одну й ту саму ідею: внутрішні інструменти, навіть якщо вони виглядають дрібними, радикально підсилюють операторів на передовій. Вони перетворюють масову, рутинну роботу на керований, вимірюваний процес.

Це також формує певний тип мислення про інфраструктуру: не як про набір унікальних серверів, а як про флот, яким потрібно керувати через стандартизовані інтерфейси й автоматизовані процедури. Саме це мислення пізніше ляже в основу Kubernetes.

Від дата-центрів до автоматизованого хостингу: досвід Rackspace/ServerBeach

Після Google Гайтовер переходить у спін-оф Rackspace — компанію, відому під брендами ServerBeach або Peer 1, — щоб працювати над автоматизованим веб-хостингом. Якщо дата-центри Google дали йому досвід роботи з гіпермасштабом, то тут він занурився в іншу сторону інфраструктури: як зробити так, щоб клієнт міг отримати сервер або середовище для свого застосунку максимально швидко й з мінімальною участю людей.

Автоматизований хостинг середини 2000‑х — це попередник того, що сьогодні називається «cloud-native». Йшлося про те, щоб перетворити розгортання серверів і застосунків із ручної, тікетної операції на самообслуговування через API та панелі керування. Скрипти, шаблони конфігурацій, стандартизовані образи — усе це ставало частиною повсякденної роботи.

Для Гайтовера це був логічний розвиток ідей, які він уже застосовував у дата-центрах Google: якщо можна описати процедуру, її можна автоматизувати; якщо можна стандартизувати середовище, можна масштабувати послугу без лінійного зростання штату.

Цей досвід — поєднання гіпермасштабної експлуатації в Google і автоматизованого хостингу в Rackspace/ServerBeach — створив унікальну перспективу на інфраструктуру. Коли згодом на сцену вийшли контейнери, а за ними Kubernetes, для нього це було не стільки новою парадигмою, скільки кульмінацією давно назрілих тенденцій.

Docker як вирішальний фактор: чому Kubernetes «вистрілив» саме тоді

Коли сьогодні говорять про успіх Kubernetes, часто згадують його гнучкість, розширюваність або підтримку з боку великих хмарних провайдерів. Гайтовер пропонує більш приземлену, але показову відповідь: номер один серед факторів успіху Kubernetes — це Docker.

До Docker розмови про розгортання застосунків неминуче впиралися в мови програмування та рантайми. Команди сперечалися про Java проти Python, Ruby проти чогось іншого, а інфраструктурники змушені були враховувати специфіку кожного стеку: версії JVM, системні бібліотеки, залежності, конфігурації веб-серверів.

Docker радикально спростив цю картину. Він запропонував стандартизований контейнерний формат, у якому застосунок постачався разом зі своїми залежностями. Замість того, щоб обговорювати, як саме розгортати Java чи Python, інфраструктура могла говорити про одне: як розкладати Docker-контейнери по кластерах.

Це змінило стартові умови для Kubernetes. Коли система з’явилася, їй не потрібно було переконувати розробників переписувати застосунки або переходити на новий формат пакування. Вона могла просто взяти те, що вже існувало: Docker-образи, які команди й так будували для локальної розробки або CI/CD.

Фактично Kubernetes отримав «заправлений бак» ще до старту. Замість того, щоб вигадувати власний формат контейнерів або вимагати спеціальної підготовки застосунків, він зосередився на тому, що вмів найкраще: плануванні, масштабуванні, відмовостійкості. Docker зняв із Kubernetes найболючіший шар — стандартизацію пакування застосунків — і дозволив йому відразу зайнятися оркестрацією.

Це добре видно в тому, як Гайтовер формулює ключову зміну: замість дискусій «Java проти Python проти Ruby» розмова звузилася до «як розкладати Docker-контейнери». Ця редукція складності — класичний рецепт для прориву технології. Коли інфраструктура отримує єдиний, передбачуваний артефакт (контейнер), навколо нього можна будувати потужні, але загальні інструменти.

Від внутрішніх інструментів до глобального стандарту

Якщо подивитися на шлях Гайтовера — від shell-скриптів у дата-центрі Google до проповідування Kubernetes на конференціях — простежується чітка лінія: внутрішні інструменти, створені для вирішення локальних проблем, поступово перетворюються на загальні платформи.

У дата-центрі скрипти й апаратні індикатори допомагали одному техніку ремонтувати більше серверів із меншою кількістю помилок. У Rackspace/ServerBeach автоматизація хостингу дозволяла обслуговувати більше клієнтів без пропорційного зростання операційних витрат. Docker стандартизував контейнер як одиницю пакування застосунку. Kubernetes, у свою чергу, стандартизував спосіб, яким ці контейнери розгортаються, масштабуються й оновлюються.

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

Docker зробив можливим останній крок, надавши уніфікований «контейнер» для всіх цих декларацій. Без нього Kubernetes довелося б одночасно вирішувати дві задачі: стандартизувати пакування застосунків і стандартизувати їх оркестрацію. Завдяки Docker він міг зосередитися на другій.

Висновок: чому історія про дата-центри важлива для розуміння Kubernetes

Історія Келсі Гайтовера — це не лише сюжет про самоука, який став Distinguished Engineer у Google. Це також історія про те, як досвід роботи з реальною, масовою інфраструктурою формує погляд на технології, які згодом стають стандартом індустрії.

Робота в дата-центрах Google навчила його мислити в категоріях метрик, автоматизації й флотів серверів, а не окремих машин. Досвід у Rackspace/ServerBeach загострив розуміння того, як автоматизація перетворює хостинг на сервіс, що масштабується. Коли на цю базу наклалися Docker і Kubernetes, для нього це було не стільки «новою модою», скільки природним продовженням давно знайомих ідей.

Твердження про те, що номер один серед факторів успіху Kubernetes — це Docker, виглядає переконливо саме в цьому контексті. Docker зняв один із головних бар’єрів — різноманіття рантаймів і середовищ — і дозволив Kubernetes сфокусуватися на тому, що він робить найкраще: керувати контейнерами в масштабі. А шлях від shell-скриптів у дата-центрі до глобальної оркестраційної платформи показує, як локальні інженерні рішення, спрямовані на підвищення ефективності, з часом можуть змінити всю індустрію.

Джерело

Повний випуск подкасту The Pragmatic Engineer з Келсі Гайтовером:
https://www.youtube.com/watch?v=UlXpOGIpITM

Келсі Гайтовер сьогодні відомий як один із найвпливовіших інженерів у світі інфраструктури та Kubernetes, колишній Distinguished Engineer у Google, який вийшов на пенсію з індустрії у 43 роки. Але його шлях починався зовсім не з хмарних дата-центрів. Після школи він не пішов у класичний університетський трек, а взяв у руки дриль, PCI‑карти й інструкції до Windows 98 — і почав заробляти на встановленні DSL‑модемів та побудові офісних мереж для малого бізнесу. Згодом він відкрив власну компанію Digital Gateways, невеликий комп’ютерний магазин під Атлантою, допомагав музичним студіям переходити на Pro Tools і паралельно керував кар’єрою стендап‑коміка зі школи.

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

DSL як трамплін: коли перша технічна робота — це чужі офіси й Windows 98

Поворотним моментом для Гайтоворта стала не чергова зміна в піцерії, а тонка книжка за 35 доларів. Після закінчення школи у 1999 році він швидко розчарувався в темпі навчання в коледжі й натрапив у книгарні на посібник до сертифікації CompTIA A+. Самостійно вивчивши матеріал і склавши іспит у тестовому центрі під наглядом камери, він отримав сертифікат, який відкрив двері на ярмарок вакансій для технічних підрядників.

Саме там з’явилася перша «офіційна» технічна робота: встановлення DSL‑модемів як підрядник, що замінював у клієнтів старий dial‑up на високошвидкісний доступ. Це був кінець 90‑х — початок 2000‑х, коли AOL ще не зник, але попит на швидший інтернет уже стрімко зростав. Для телеком‑компаній це був масштабний перехід інфраструктури, а для таких інсталяторів, як Гайтовер, — щоденний контакт із реальними користувачами й їхніми хаотичними ІТ‑середовищами.

Робота не обмежувалася тим, щоб прикрутити модем до стіни. У багатьох клієнтів просто не було мережевих інтерфейсів, здатних працювати з DSL, тож він регулярно встановлював PCI‑мережеві карти в настільні ПК, відкриваючи корпуси, перевіряючи слоти, налаштовуючи драйвери. Далі йшло налаштування Windows 98: конфігурація TCP/IP, введення параметрів провайдера, тестування з’єднання, перевірка пошти й браузера.

Фактично він став живим мостом між телеком‑інфраструктурою й кінцевими машинами користувачів. Для провайдера важливо було «підняти лінію», але для бізнесу — щоб інтернет працював на конкретному комп’ютері, з конкретним софтом і принтерами. Саме на цьому стику Гайтовер отримав унікальний досвід: він бачив, як мережа поводиться не в лабораторії, а в реальних офісах, де старі ПК, дивні конфігурації й людський фактор зіштовхувалися з новими технологіями.

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

Народження Digital Gateways: коли чек не виписують на фізособу

Працюючи інсталятором DSL, Гайтовер швидко помітив закономірність: як тільки інтернет у клієнта запрацює, з’являється наступне питання — як підключити до нього всі комп’ютери в офісі. На той час типовий малий бізнес мав кілька ПК, іноді старий файловий сервер, принтер у кутку й жодного уявлення про мережеву топологію. Провайдер відповідав лише за лінію до модему, а далі починався «сіра зона», де потрібен був хтось, хто розуміє і кабелі, і операційні системи.

Гайтовер почав заповнювати цю нішу. Він купував і встановлював недорогі Linksys‑роутери, налаштовував локальні мережі, роздавав DSL‑з’єднання на всі машини в офісі, конфігурував спільний доступ до файлів і принтерів. По суті, він став мережевим інженером «на виклик» для малого бізнесу, який не міг дозволити собі штатного ІТ‑фахівця.

Саме в одному з таких офісів сталася сцена, яка визначила його подальшу підприємницьку траєкторію. Клієнт був задоволений роботою й був готовий заплатити, але відмовився виписувати чек на фізичну особу. Потрібна була назва компанії. І тоді, буквально на місці, Гайтовер вигадав «Digital Gateways» — ім’я, яке звучало достатньо «по‑бізнесовому», щоб пройти бухгалтерію.

Цей імпровізований бренд він згодом формалізував як малий бізнес приблизно у 19 років. Digital Gateways стала парасолькою для всіх його ІТ‑послуг: від налаштування мереж до ремонту ПК і консультацій. Важливим було не лише те, що він умів робити технічно, а й те, що він почав мислити як підприємець: оформлювати рахунки, будувати відносини з клієнтами, розуміти, як виглядає послуга очима людини, яка за неї платить.

Цей перехід від «людини з інструментами» до власника сервісного бізнесу показав йому, що в ІТ‑сервісах цінність створюється на перетині довіри, компетенції та здатності говорити мовою бізнесу. Але водночас він почав бачити й обмеження такого підходу.

Магазин, студії, виїзди: як один підприємець тягнув на собі весь стек

На межі 2000–2001 років Гайтовер зробив наступний крок — відкрив невеликий комп’ютерний магазин неподалік Атланти. Формально це був роздрібний бізнес: клієнти могли зайти, замовити або купити комп’ютер, отримати консультацію. Насправді ж магазин став для нього базою операцій для виїзних сервісів.

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

Особливим напрямком стали музичні студії. На початку 2000‑х багато з них ще працювали на аналоговому обладнанні: стрічкові рекордери, мікшерні пульти, фізичні ефекти. Перехід на цифрові робочі станції був неминучим, і Гайтовер опинився серед тих, хто допомагав зробити цей стрибок. Він налаштовував студіям Pro Tools, будував робочі процеси на базі Mac‑комп’ютерів, інтегрував новий софт із наявною апаратурою.

Це була вже не просто «комп’ютерна допомога», а спеціалізована інфраструктура для креативної індустрії. Потрібно було розуміти не лише технічні параметри, а й те, як працює студійний процес: де важлива затримка сигналу, як організувати зберігання великих аудіофайлів, як забезпечити стабільність системи під час запису.

Паралельно з усім цим Гайтовер займався ще одним бізнесом, який на перший погляд не мав нічого спільного з ІТ: він керував кар’єрою стендап‑коміка зі школи. Організація виступів, турів, логістика, домовленості з майданчиками — усе це вимагало іншого набору навичок, але за суттю було тим самим підприємництвом: знайти клієнта, створити для нього цінність, домовитися про оплату.

У сумі це означало, що один 20‑річний підприємець одночасно:

піднімав DSL‑лінії й будував офісні мережі;

збирав і продавав кастомні ПК;

налаштовував цифрові студії на Pro Tools і Mac;

керував артистом і організовував тури.

Цей період дав йому унікальну панораму малого бізнесу: від ресторану до студії, від офісу до концертного майданчика. І водночас — чітке відчуття меж власних можливостей.

Невидима стеля сервісного бізнесу: чому години не масштабується, як код

Після кількох років такого життя Гайтовер дійшов висновку, який пізніше сильно вплинув на його кар’єрні рішення: невеликий ІТ‑сервісний бізнес має вбудовану стелю зростання. На відміну від програмного продукту, який можна продати тисячам користувачів без лінійного збільшення витрат, сервіс прив’язаний до часу конкретних людей.

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

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

Це не означає, що сервісний бізнес — поганий. Навпаки, саме він дав Гайтоверу стартовий капітал досвіду, контактів і розуміння ринку. Але він також чітко показав межі: скільки годин на тиждень можна фізично працювати, скільки клієнтів реально обслуговувати без падіння якості, як важко делегувати роботу, коли клієнти звикли «до конкретної людини».

Цей досвід сформував у нього пізнішу перевагу до «більш важелевих» форматів роботи — там, де один зусилля може створювати цінність для великої кількості людей: у софтверних продуктах, відкритому коді, масштабованих платформах. Коли він згодом перейшов у великі інфраструктурні компанії, а потім у Google, це розуміння стало важливою частиною його підходу до кар’єри: шукати ролі, де вплив не обмежується кількома клієнтами чи одним містом.

Чому досвід «людини з дрилем» досі важливий для інженерів

Історія ранніх років Гайтоворта — це не просто ностальгія за епохою DSL і Windows 98. Вона показує, як глибоко практичний досвід малого сервісного бізнесу може вплинути на те, як інженер мислить про технології, продукти й власну кар’єру.

По‑перше, робота інсталятором і мережевим «швидкою допомогою» навчила його дивитися на технології очима користувача. Коли ти стоїш у задушливому офісі й намагаєшся пояснити бухгалтеру, чому інтернет «не працює», неважливо, наскільки елегантна твоя конфігурація. Важливо, чи може людина відправити звіт. Це приземлене розуміння цінності технологій згодом стало однією з причин, чому його підхід до інфраструктури й Kubernetes завжди був орієнтований на людей, а не на «технологію заради технології».

По‑друге, досвід побудови Digital Gateways і комп’ютерного магазину дав йому чітке відчуття економіки сервісів. Він на власній шкірі відчув, як виглядає «нескінченний робочий день», коли кожен новий клієнт — це ще один вечір без вихідних. Це зробило його особливо чутливим до питань масштабу й важеля: де кожна година роботи може приносити все більшу віддачу, а не просто заповнювати календар.

По‑третє, робота зі студіями й управління коміком показали, що технології завжди вплетені в ширший контекст — творчий, бізнесовий, культурний. Перехід студій на Pro Tools був не лише про встановлення софту, а й про зміну способу роботи музикантів. Організація турів — не лише про логістику, а й про розуміння аудиторії. Це навчило його бачити технологічні рішення як частину більших систем, де успіх визначається не лише технічною досконалістю.

Нарешті, ці роки дали йому впевненість, що формальна освіта — не єдиний шлях у технології. Сертифікація A+, самостійне навчання, робота з реальними клієнтами — усе це стало фундаментом, на якому він збудував кар’єру, що зрештою привела його до рівня Distinguished Engineer у Google і дозволила вийти з індустрії на власних умовах.

Висновок: уроки Digital Gateways для епохи хмар і AI

Сьогодні, коли інженери обговорюють Kubernetes, хмарні платформи й генеративний AI, історія про те, як хтось колись встановлював DSL‑модеми й Linksys‑роутери, може здаватися далеким минулим. Але в ній є кілька принципів, які залишаються актуальними.

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

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

По‑третє, підприємницький «хастл» на ранньому етапі кар’єри може стати не менш важливим, ніж робота у великій компанії. Імпровізована назва Digital Gateways, маленький магазин біля Атланти, студії на Pro Tools і тури стендап‑коміка — усе це не просто епізоди біографії, а практичні уроки про цінність, масштаб і людей, які згодом визначили, як Келсі Гайтовер мислить про технології й кар’єру.

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

Джерело

Повна розмова: Kubernetes and retiring at the top with Kelsey Hightower

Келсі Гайтовер — одне з найвідоміших імен у світі Kubernetes та сучасної інфраструктури. Він став Distinguished Engineer у Google, отримував персональні офери від CEO Microsoft Сатьї Наделли, а потім пішов з індустрії у 43 роки на піку кар’єри. Але його шлях у технології починався зовсім не з елітного університету чи стажування у великій компанії. Це історія про підлітка з ключами від «Макдональдса», калькулятор TI‑86, дешевий підручник за 35 доларів і сертифікацію A+, яка відчинила двері в ІТ.

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

Макдональдс як перша «школа менеджменту»

Перші зароблені гроші Келсі — не за код, не за налаштування мережі й навіть не за ремонт комп’ютерів. У підлітковому віці він пішов працювати до «Макдональдса» — просто тому, що ресторан був у пішій доступності від дому, а йому щойно виповнилося 14, і він міг отримати офіційний дозвіл на роботу.

Це була типова історія для американського підлітка: заповнити анкету, пройти співбесіду того ж дня, почути стандартне «коли можете почати?» і буквально «зараз» вийти на зміну в новій формі. Але дуже швидко ця, на перший погляд, «низькокваліфікована» робота перетворилася для нього на інтенсивний курс з управління людьми й відповідальності.

До 15 років Гайтовер уже був асистентом менеджера зі справжніми ключами від закладу. Уночі та на вихідних дорослі менеджери залишали йому керування рестораном. Підліток відповідав за все: від роботи кухні й кас до закриття зміни, підрахунку готівки, заповнення великих звітних таблиць і відправлення їх факсом у головний офіс.

Цей досвід дав йому дві важливі речі, які пізніше виявилися критичними в технологічній кар’єрі. По‑перше, розуміння, що будь-яка система — навіть фастфуд-ресторан — це складний, але добре відлагоджений механізм із очікуваннями клієнтів, чіткими процесами й вимогами до ефективності. По‑друге, ранній досвід управління людьми, включно з дорослими колегами, коли ти ще сам підліток.

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

TI‑86 і AutoCAD: як калькулятор і 3D‑моделювання дали впевненість у технічних здібностях

Шлях до програмування для Гайтовера почався не з комп’ютера, а з переїзду. Переїхавши з Каліфорнії до Атланти, він пропустив кілька місяців навчання й мусив добирати предмети, щоб вчасно закінчити школу. Спорт — біг, футбол, баскетбол — уже займав значну частину його життя, але додаткові предмети були неминучими.

Одним із таких напрямів стала участь у технологічній студентській асоціації, де поєднувалися навчальні курси й позакласні активності. Там він уперше серйозно зіткнувся з комп’ютерними технологіями — зокрема з AutoCAD. І хоча спочатку «комп’ютерний клуб» здавався чимось «не для крутих хлопців», інтерес швидко переміг стереотипи.

AutoCAD виявився для нього несподівано захопливим. Завдання були максимально практичними: отримати специфікацію, спроєктувати об’єкт, вкластися в час і видати результат. Гайтовер дійшов до змагань на рівні штату, де учасники мали виконати завдання прямо на місці. Для нього це був перший рік участі, але він одразу потрапив у фінал.

Парадоксально, але на цих змаганнях він посів друге місце, навіть не завершивши процес до кінця. Він не зміг надрукувати свій проєкт — обов’язковий крок, щоб судді могли оцінити роботу. Попри це, сам дизайн виявився настільки сильним, що йому все одно віддали «срібло». Це стало важливим сигналом: навіть у неідеальних умовах, навіть із технічними збоями навколо, він здатен показувати результат, який визнають на високому рівні.

Ще один ключовий момент стався в тій же навчальній атмосфері, але вже з іншим інструментом — графічним калькулятором TI‑86. Один із однокласників показав йому, що це не просто пристрій для побудови графіків, а повноцінна платформа для програмування на TI‑BASIC. Для підлітка, який не знав жодного професійного програміста, це відкриття було майже магічним.

Класичне завдання того часу — написати гру «Змійка». Учні брали код із журналу, переносили його в калькулятор, запускали й отримували працюючу гру. Потім починали експериментувати: змінювати параметри, додавати дрібні модифікації, дивитися, як це впливає на поведінку програми. Це був перший досвід, коли Гайтовер побачив прямий зв’язок між написаним кодом і поведінкою машини.

Саме тут заклалася ключова для нього ідея: складні технічні навички можна опанувати самостійно, якщо є доступ до інструментів і достатньо наполегливості. TI‑BASIC на калькуляторі й AutoCAD на шкільних комп’ютерах стали для нього доказом, що технічний світ не закритий клуб, а простір, у який можна зайти через практику й експерименти.

Коледж на паузі: чому безкоштовна освіта виявилася надто повільною

До закінчення школи в 1999 році Гайтовер мав цілком традиційний, «правильний» маршрут: у штаті Джорджія діє програма HOPE, яка дозволяє випускникам із середнім балом «B» і вище безкоштовно навчатися в будь-якому державному університеті. До цього переліку входять і сильні технічні виші на кшталт Georgia Tech і Georgia State.

Він вступив до одного з університетів поблизу, скориставшись цією можливістю. Формально все виглядало ідеально: безкоштовна освіта, престижні заклади, чітка траєкторія до «нормальної» кар’єри. Але реальність виявилася іншою. Уже за два тижні навчання він зрозумів, що темп занять не відповідає тому, як швидко він хоче рухатися.

Кінець 90‑х — це час, коли технологічний світ кипів. У телевізійних новинах показували черги за новими версіями Windows, інтернет переходив від dial‑up до високошвидкісних з’єднань, AOL втрачав монополію, а слово «онлайн» ставало частиною повсякденності. У медіа активно циркулювали історії про людей, які будували кар’єру в технологіях без дипломів: від Білла Гейтса до інших підприємців, для яких навички були важливішими за формальну освіту.

На цьому тлі лекції в університеті здавалися Гайтоверу надто повільними й відірваними від того, що відбувається на ринку. Він не бачив поруч людей, які вже працюють програмістами чи системними адміністраторами, не мав менторів із галузі. Коли він відкривав вакансії, то бачив там стек технологій — Sun Microsystems, IBM mainframe та інші корпоративні системи, — до яких просто не знав, як дістатися.

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

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

Сертифікація A+ за $35: як один підручник замінив роки навчання

Поворотним моментом стала випадкова зустріч у книжковому магазині. Переглядаючи полиці, Гайтовер натрапив на гайд із підготовки до сертифікації CompTIA A+. На той момент він уже бачив у вакансіях вимогу «A+ certified» для початкових ролей у техпідтримці й сервісних службах. І раптом з’ясувалося, що для цього не потрібен університетський диплом — лише скласти іспит.

Ключові параметри виглядали максимально привабливо: офіційний сертифікаційний іспит, визнаний ринком, і підручник вартістю всього 35 доларів. Для молодої людини, яка працює в сервісі й не має доступу до дорогих курсів чи приватних університетів, це був майже ідеальний варіант: низька вартість входу, чіткий зв’язок із ринком праці та зрозумілий критерій успіху — скласти іспит.

Гайтовер купив книгу й підійшов до неї так само, як колись до AutoCAD чи TI‑BASIC: системно й самостійно. Він прочитав її від обкладинки до обкладинки кілька разів. Матеріал охоплював базові, але фундаментальні речі: як влаштовані материнські плати, як працює пам’ять, які є типи накопичувачів, як поводиться операційна система, які типові проблеми виникають у користувачів.

У комплекті був CD із тренувальними тестами. Це створювало те, що Гайтовер особливо цінував: швидкий цикл зворотного зв’язку. Він запускав тест, відповідав на запитання, отримував результат, повертався до розділів, де помилявся, і знову проходив тест. Легка рандомізація запитань не дозволяла просто зазубрити відповіді — доводилося розуміти матеріал.

Коли настав час офіційного іспиту, він прийшов до сертифікаційного центру, сів у невелику кімнату під камерою спостереження й почав відповідати на запитання. На іспит відводили близько години-півтори, але йому вистачило приблизно десяти хвилин. Після завершення тесту система через dial‑up-з’єднання відправила результати, і він отримав підтвердження: іспит складено, він A+ certified.

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

Цей досвід сформував його подальший підхід до навчання: шукати низьковартісні, високоефективні інструменти, які дають конкретний результат, а не абстрактний статус. A+ став першим із таких інструментів, але далеко не останнім.

Один сертифікат — один ярмарок вакансій — перша робота в ІТ

Найважливіше в історії з A+ — те, як швидко сертифікація почала працювати як реальний пропуск у галузь. Невдовзі після складання іспиту Гайтовер дізнався про ярмарок вакансій, де шукали підрядників для масштабного проєкту: заміни dial‑up‑підключень на DSL у домогосподарствах і бізнесах.

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

Цей перехід показовий із кількох причин. По‑перше, він демонструє, як один формальний маркер компетенції — сертифікат — може різко змінити траєкторію кар’єри. Без нього Гайтовер залишався б у сфері сервісу, де досвід важко конвертувати в технічні ролі. З ним він отримав доступ до проєкту, який уже знаходився в технологічному ланцюжку: встановлення DSL‑модемів, робота з мережевим обладнанням, взаємодія з клієнтами, які переходять на новий тип підключення.

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

По‑третє, цей крок закріпив у ньому переконання, що кар’єра в технологіях може будуватися як послідовність практичних рішень, а не як один великий стрибок. Спочатку — TI‑BASIC на калькуляторі, потім AutoCAD на змаганнях, далі — A+ за 35 доларів, і вже після цього — перша робота, де технічні навички оплачуються як технічні, а не як частина загальної «працьовитості» в сервісі.

Саме з цього моменту починається його формальна історія в ІТ, яка згодом приведе до ролі Distinguished Engineer у Google, пропозицій від Microsoft і впливу на розвиток Kubernetes. Але фундамент цієї історії — не в гучних брендах, а в рішенні підлітка інвестувати в дешевий підручник і довести собі, що він здатен вчитися самостійно й конкурувати на технічному рівні.

Нетиповий маршрут як сигнал для індустрії

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

По‑перше, формальна освіта не завжди встигає за темпом змін у технологіях. У 1999 році Гайтовер бачив, як швидко розвивається інтернет і програмне забезпечення, і не знаходив цього темпу в аудиторіях. Схожа ситуація спостерігається й нині, коли нові інструменти, від контейнерів до генеративного ШІ, з’являються й еволюціонують швидше, ніж оновлюються навчальні програми.

По‑друге, доступні за ціною, але визнані ринком сертифікації можуть стати реальним соціальним ліфтом. A+ за 35 доларів став для Гайтовера тим, чим для когось сьогодні можуть бути онлайн‑курси з чітким зв’язком до ринку праці чи професійні сертифікати від великих вендорів. Важливо не лише те, що вони дають знання, а й те, що вони відкривають двері в конкретні процеси найму.

По‑третє, ранній досвід відповідальності й управління людьми, навіть поза ІТ, може виявитися не менш важливим, ніж технічні навички. Робота асистентом менеджера в «Макдональдсі» навчила Гайтовера працювати з тиском, очікуваннями клієнтів і дорослими колегами. Ці навички згодом стали критичними в ролях, де потрібно не лише писати код, а й будувати команди, впливати на спільноти та просувати нові технологічні підходи.

І нарешті, його шлях показує, що «нетиповий» маршрут може стати не винятком, а одним із повноцінних сценаріїв входу в індустрію. Випускник школи 1999 року, який обирає A+ замість диплома, самостійно вивчає техніку за дешевою книгою, програмує калькулятор і змагається в AutoCAD, у підсумку доходить до рівня, де CEO Microsoft додає «ще один нуль» у PDF‑офері. Цей контраст не романтизує відмову від освіти, але показує, що для частини талановитих людей гнучкі, самостійні траєкторії можуть бути ефективнішими за стандартні.

Висновок: уроки з історії про A+, TI‑86 і ключі від ресторану

Сьогодні, коли Келсі Гайтовер уже завершив кар’єру в індустрії на рівні Distinguished Engineer, легко побачити лише фінальний результат: Kubernetes, Google, великі сцени, вплив на інфраструктуру. Але його ранній шлях нагадує, що за цими титулами стоять дуже конкретні рішення й практики.

Підліток, якому довірили ключі від «Макдональдса», навчився відповідальності раніше, ніж дехто отримує першу сесію в університеті. Учень, який писав «Змійку» на TI‑86 і проєктував об’єкти в AutoCAD, зрозумів, що може самостійно опановувати технічні інструменти. Студент, який покинув безкоштовний університет через надто повільний темп, показав, що готовий іти проти інерції заради реальної швидкості розвитку. І молодий працівник, який вклав 35 доларів у підручник з A+, довів собі, що один сертифікат може стати квитком у нову професію.

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

Для інженерів, які сьогодні думають про власну траєкторію — чи то шлях до Staff/Principal‑рівня, чи перехід в іншу сферу, чи вихід з індустрії, — історія Гайтовера нагадує: нетиповий маршрут може бути не слабкістю, а джерелом сили, якщо за ним стоїть системна робота, самостійне навчання й готовність брати на себе відповідальність задовго до того, як це буде прописано в посадовій інструкції.

Джерело

Повний випуск подкасту The Pragmatic Engineer з Келсі Гайтовером:
https://www.youtube.com/watch?v=UlXpOGIpITM