Відповідаю на питання №2

Головне

• Чи потрібен команді окремий QA-інженер? У WebbyLab тестувальники є завжди, бо для бізнесу так дешевше; у його команді в Google Cloud немає жодного ручного тестувальника чи автоматизатора — але ручне тестування все одно відбувається, просто розподілено: (1) розробник тестує свою фічу, (2) продакт-менеджер її проклацує, (3) інженер організовує 30–40-хвилинний "bug bash" — дзвінок, на якому вся команда полює на баги в новій фічі, (4) dogfooding усередині Google, (5) beta-запуски для trusted testers. Оскільки монорепо Google тримає одну версію кожної бібліотеки, «хтось оновлює Angular для всього Google, і це не ти» — тож автоматичні тести — твоя єдина гарантія, і писати їх — відповідальність розробника.
• TDD: він не TDD-пурист. Для нього це має сенс при виправленні багів (написати падаючий тест, потім фікс — цикл red/green, який Kent Beck насправді й мав на увазі; він рекомендує серію дискусій "TDD is Dead" із Kent Beck, Martin Fowler і DHH). У проєктуванні TDD змушує фокусуватися на занадто вузьких аспектах; натомість він накидає приклади використання API/абстракції, багаторазово їх переписує, поки не проступить скелет, потім реалізує модулі й пише тести після коду. Він цитує A Philosophy of Software Design (прочитану кількома місяцями раніше), де є «рівно та сама цитата» про те, як TDD відводить увагу вбік — див. проєктування ПЗ.
• Mockist чи classicist? Classicist: він не любить моки й проєктує так, щоб можна було підставити альтернативну реалізацію.
• Його особистий бенчмарк для LLM — одна стандартна задача: бінарний пошук у файлі без читання всього файлу в пам'ять. Результати: останні версії ChatGPT і Gemini 2 розв'язують чисто (Gemini 1.5 одного разу розв'язав, потім регресував); Grok (той, що в Twitter) провалюється — все одно читає весь файл; локальні дистиляти DeepSeek R1 до 70B параметрів провалюються навіть із reasoning, а повний онлайновий ~700B DeepSeek розв'язує, але «думає» довго.
• Щоденні інструменти: найчастіше Gemini (включно з Gemini Deep Research для збирання матеріалу з вебу в звіти), потім ChatGPT o3-mini-high. Автодоповненням у стилі Copilot майже не користується — хоча в GitHub Copilot тепер є безкоштовний тариф «і працює нормально» — бо внутрішнє автодоповнення Google, натреноване на власній кодовій базі Google, доповнює в стилі коду Google і значно краще. Для приватного коду він ганяє локальні моделі через Ollama, щоб нічого не покидало його машину.
• Його головні застосування LLM: брейншторм проблеми, вигадування назв змінних, вивчення нової технології та прототипування. У ChatGPT він тримає «проєкт» із постійним системним промптом (React + Material UI + TypeScript, компоненти експортуються як звичайні функції, не стрілочні), щоб не пояснювати свої конвенції щоразу.
• У Google AI-інструменти вбудовані в стандартне середовище розробки та інтегровані всюди, включно з code review; вставляти код Google у зовнішній ChatGPT він не може. Він також працював поруч із командою Vertex AI (його команда формувала входи/виходи; інша команда відповідала за тестування AI — регресійні перевірки, фреймворки, багато dogfooding). Він хвалить Vertex AI як найбільш end-to-end ML-платформу з відомих йому (тренування, fine-tuning, деплой, доступ через API) і зазначає, що Cloud Run (його команда) додав підтримку GPU — "serverless 2.0" для inference-навантажень. Ще він інтегрував і тестував Claude 3.5 Sonnet для дисертаційної роботи (витягування структурованих даних) — «працює пристойно», як і чимало локальних моделей; у нього є цілий порівняльний звіт, який він, можливо, опублікує.
• Підготовка до співбесід у Google: LeetCode він ніколи не гриндив — приблизно два-три тижні, по парі годин щоранку, плюс кілька днів на перечитування книжок з алгоритмів. Жодна задача на співбесідах не збіглася з тим, що він тренував; важило вміння аналізувати задачу вголос, помічати крайні випадки, тестувати в голові й визнавати, що рішення не оптимальне. Фактор удачі реальний: у 2014-му він провалився на четвертій співбесіді (це був період Майдану — того ранку він був на площі), і Google спокійно дозволяє спробувати через рік.
• Ключова навичка інженера — не мова програмування, а вміння доставити те, що працює й розв'язує проблеми користувачів. Його порада початківцям: не просто вчіть мову — зробіть маленький pet-проєкт від початку до кінця: фронтенд, бекенд, база даних, Docker, орендуйте хмару, купіть домен, налаштуйте DNS і пошту (глибоке вивчення фундаменту).
• Що вищий рівень, то більше задачі — про невизначеність, рішення й розуміння потреб, і менше про написання коду: іноді він відвантажує один комміт за два місяці, іноді 20–30 на місяць.
• Вигорання: по-справжньому він ніколи не вигорав — втома була, і панічні атаки під час побудови бізнесу, — але після відпочинку завжди знову хочеться кодити. Здоров'я зараз головний пріоритет: зважився — 103 кг, планує відновити спортивну звичку.
• Умови Google щодо інтелектуальної власності суворі («все жорстко»): жодних побічних комерційних проєктів, навіть open-source питання йдуть через погодження; у WebbyLab він залишається співвласником, але бере участь лише в стратегічному плануванні.
• Грейди в Google суттєво відрізняються від звичної драбини junior/middle/senior — це питання він відклав на окреме майбутнє відео.
• Складні алгоритми вручну імплементуєш рідко, але треба розуміти структури даних, їхні властивості та складність за часом/пам'яттю. Історія з практики: для проєкту «Excel на JavaScript» йому довелося переписати топологічне сортування ітеративно з власним стеком, бо ліміт JS ~10 000 стекових фреймів вибухав на ланцюжках залежностей у таблицях довших за 10 тисяч клітинок. Повнотекстовий пошук він теж імплементував сам. На code review він регулярно помічає «це O(n²), це кубічне» просто читаючи код.
• Порада щодо книжок: проста книжка з алгоритмів, що виглядає доступною, — і є правильним стартом; йому сподобалася Grokking Algorithms; не треба перевантажувати себе, коли проста книжка дає ефект. AlgoExpert йому теж допоміг.
• Reverse engineering трапляється на практиці: реалізуючи функції Excel у JS, вони постійно промацували реальну поведінку, бо документація не збігалася з дійсністю.
• Йому весь час хочеться вивчити Elixir/Clojure, але всі pet-проєкти він пише на Node.js + TypeScript: швидкий сучасний рантайм з чудовим JIT (його JS Excel обганяв чистий CPython у 5–10 разів на обчисленнях), типізація за потреби, а якщо pet-проєкт виросте в продукт — найняти Elixir-розробників реально проблема. З погляду ринку JavaScript+TypeScript сьогодні раціональний вибір. Проєкти він обирає питанням «чи хотів би я, щоб це існувало?» — приклади: mytalks.net (платформа для спікерів у дусі Behance) і запланований інструмент контрастного автофокуса для його камери Blackmagic через її API керування фокусом.
• Go проти Rust для вебу: він обрав би Go (там є GC), але не фанат — регулярно читаючи Go в Google, він вважає, що мові бракує виразності й інструментів абстракції, і в ній забагато boilerplate (абстракції). Для складного застосунку він радше взяв би TypeScript або C#.
• Патерни проєктування — не сакральне знання: у Mail.ua його команда реалізувала понад 10 із 24 патернів GoF «практично за книжкою» до того, як прочитала книжку, бо це просто найлогічніші рішення. Приймаючи архітектурний патерн, стежте, де він перестає працювати, і розширюйте його (наприклад, додавши власну концепцію контролера на фронтенді).
• Історія state management у React з перших рук: він викотив React 0.4 у продакшн через два місяці після релізу; далі доповідь Facebook про Flux (без реалізації) → стори Fluxxor → його команда обгорнула PubSubJS, щоб імітувати Flux → доповідь Dan Abramov про Redux → Redux-boilerplate → метапрограмні бібліотеки-обгортки. Сьогодні його pet-проєкти взагалі без Redux: просто React плюс власна бібліотека доступу до API. Єдиної «правильної» архітектури немає — свідомо вирішуйте, як розділяєте рендеринг і стан.
• ООП на фронтенді: у його роботі в Google його вдосталь — компоненти й сервіси Angular це класи й абстракції наскрізь.
• Він не рекомендує MacBook за замовчуванням: його власний стрімінговий ноутбук — Asus Zenbook (1.6 кг, OLED 120 Hz, ~50 GB RAM, RTX 4070, 2 TB SSD) — об'єднання його старого важкого Eurocom і ThinkPad Carbon X1 в одній машині. На Mac з M1 різниця 16 проти 32 GB у тестах була практично непомітною завдяки швидкому SSD-свопу, але йому потрібно 32+ GB, бо він постійно ганяє кілька VM.
• Чому Docker з'їдає пам'ять Mac: на Linux Docker — просто ізольований процес; на macOS це ціла Linux VM з попередньо виділеною пам'яттю.
• Рекомендований подкаст про менеджмент: Manager Tools — «я виріс як менеджер завдяки цьому подкасту».
• Про Україну: контракт зобов'язує переїхати до Варшави після завершення воєнного стану (сім'я вже там), але майбутнє своїх дітей він бачить в Україні — «тут дуже багато можливостей». WebbyLab спершу віддавав 100% прибутку на армію, потім створив волонтерський фонд; він просить глядачів проголосувати за нього/WebbyLab у премії DOU.