Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

«Я побачив, що IT-індустрія в Україні змінюється». Андрій Дегтярьов, VP of Engineering компанії Ciklum, — про те, чому перейшов з Google в Ciklum та як працює тепер

Ми продовжуємо спілкуватися з людьми, які формують українську ІТ-індустрію. Публікуємо розмову з VP of Engineering компанії Ciklum Андрієм Дегтярьовим.

Андрій понад п’ять років працював у Google. Там його кар’єра була успішною та попри це він повернувся в Україну і влаштувався в компанію Ciklum. Андрій Дегтярьов розповів DOU про те, як змінюється Ciklum, як побудовані в ній процеси. А також про свій кар’єрний шлях, досвід у Google, про нові тренди в технологіях і тест-драйв сімейного життя під час карантину.

👉🏼Інтерв’ю краще слухати на нашому YouTube-каналі.

«Аутстафінговий бізнес відходить у минуле». Про різницю між аутсорс- та аутстаф-компаніями

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

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

На ІТ-ринку Ciklum вже 20 років, компанія виросла тут. Спочатку це була аутстафінгова модель, але тепер ми переходимо до product engineering services — послуг з розробки продукту. Якщо поєднати найкращі фічі аутстафінгової та аутсорсингової моделей в одній системі, вийде product engineering services. Ми працюємо над кількома продуктами у кількох доменах. За всю історію Ciklum більше ніж 1200 компаній мали змогу скористатись нашими послугами. Тепер у нас понад 200 активних проєктів.

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

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

В Ciklum ми вже не займаємось класичним аутстафом. Клієнтам, з якими працюємо давно, наприклад 9 чи 10 років, розповідаємо про свої нові пропозиції. Тобто ми органічно й у своєму темпі розширюємо бізнес-можливості та послуги, які надаємо.

«У нас є проєкти, в яких клієнтом компанії Ciklum є сам Ciklum». Про те, як працює компанія

У компанії матрична структура. Є інжиніринг, де ми розвиваємо технічну експертизу в різних напрямах. Це організовано в центри компетенцій, які, своєю чергою, діляться на юніти. Кожен юніт фокусується на специфічній технології чи фреймворку. Зазвичай це певна мова програмування, але не обов’язково. Наприклад, у нас є юніт, у який входять Java і .NET. Є відділ, куди належать JS з усіма фреймворками та Mobile.

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

Крім цього, звичайно, у нас є фінансовий відділ і HR-відділ.

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

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

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

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

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

У нас є проєкти, в яких клієнтом компанії Ciklum є сам Ciklum. Ми вкладаємось у власну трансформацію, у розвиток своєї інфраструктури, екосистеми. Серед таких проєктів розробка внутрішнього HR-тулінгу чи технологічний радар.

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

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

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

«Один з наших ключових КРІ — офер за 24 години після технічного інтерв’ю». Про новий процес найму

Нещодавно ми повністю переглянули наш процес найму, зробили висновки та втілили деякі зміни. Це допомогло нам зростати на 200 людей на місяць. Один з наших ключових КРІ — офер за 24 години після технічного інтерв’ю.

Як відбувається процес найму? Кандидат надсилає нам резюме. З ним зв’язується рекрутинговий департамент. Фахівець розповідає про свої побажання, а рекрутер — про компанію, підходи, про те, як може розвиватися кар’єра далі. Після цього кандидат і рекрутер ухвалюють рішення про подальшу співпрацю.

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

В Google вживають іншу назву посади — є просто Senior Software Engineer. За потреби фахівець може опанувати будь-яку мову чи технологію

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

Крім того, у Ciklum є багато шляхів, як розвивати кар’єру. Назву три основні. Перший — це інжиніринг. Фахівець може підсилювати свою технічну експертизу, зрости до рівня Solution Architect, експерта. Другий шлях — менеджмент. Якщо спеціаліст заряджається від роботи з людьми, може пробуватися в цьому напрямі, керувати роботою фахівців. І третій шлях — консалтинг. Актуально, якщо співробітник радо бере участь в пресейлах, спілкується з клієнтами. Звісно, з часом можна передумати та змінити напрям розвитку.

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

В Україні так історично склалося, що у нас є Senior .NET-інженер, Senior JS-інженер. Але немає позиції Senior Software Engineer Generalist, інженера загального профілю. Таке більше спостерігаємо на Заході. В тому ж Google вживають іншу назву посади — є просто Senior Software Engineer. Це означає, що за потреби фахівець може опанувати будь-яку мову чи технологію. Людина думає про продукт, про те, яку проблему треба вирішити, а вже потім підбирає оптимальні засоби для цього.

«Я керував лондонськими командами, які робили Android Studio». Про роботу в Google

У 2015 році я подав заявку на сайті Google, і за три дні мені відповіли. З цього усе почалося. Далі я пройшов кілька етапів співбесід. Процес найму тоді тривав не 24 години, а трохи довше. Загалом весь процес і оформлення віз зайняв пів року. В Google я почав працювати на позиції Software Engineer Manager команди Android Developer Tools. Фактично, я керував лондонськими командами, які робили Android Studio.

В Google було чотири локації, де займалися Android Studio: Ма́унтін-В’ю, Сіетл, Ренн (місто у Франції) та Лондон. За мою каденцію ми збільшили команду з 8 до 25 людей. Лондон став ключовою локацією у цій сфері, тому що команда почала брати участь у стратегічному плануванні, працювати над впливовими речами. Ми тісно взаємодіяли з іншими офісами Google. Щороку в мене було 4–6 поїздок у Штати. Зі Штатів у Велику Британію теж приїжджали фахівці, ми проводили саміти.

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

В Android Studio є специфіка: розробляти софт для інших девелоперів — не те саме, що розробляти софт для кінцевих користувачів. Тут є певне відокремлення від програми, бо, як правило, ті люди, які пишуть інструменти, самі не користуються ними. Щоб розв’язати цю проблему, ми працювали з DevRel-спеціалістами. Влаштовували навіть так, щоб розробники Android Studio і DevRel-спеціалісти сиділи якомога ближче одні до одних, адже DevRel (Developer Relations) — це знання потреб розробників з перших рук.

Крім цього, ми формували власне бачення того, яким має бути Android Studio. Проводили хакатони, де треба було написати Android-застосунок на власний смак. На цих івентах розробники мали змогу втілити власні ідеї, розробки. Були прикольні знахідки, презентації, пітчинги. Це був другий спосіб знайти помилки та виправити їх у самій Android Studio.

І третій канал, який допомагав заповнювати прогалини, — організація Android Developer Summit. Зазвичай ці саміти проводили в Штатах, але така зустріч була і в Лондоні. На саміти приїжджали ключові розробники від різних топових компаній, які використовують Android Studio (скажімо, із Spotify). Ми збирали від них відгуки, побажання, щось презентували. Тобто формували своє продуктове бачення, виходячи з потреб ком’юніті розробників.

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

Код я пишу досі. Писав його навіть у той час, коли в Google зростала команда. На посаді Engineer Manager, коли керуєш командою, треба розуміти, що є технічні задачі, які не можна делегувати. Лише ти маєш їх виконати. Єдине — роботу треба планувати так, щоб задачі не блокували команду, коли м’яч на твоїй половині. Серед таких задач може бути покращення білд-системи, CI/CD пайплайн: завдання, які поліпшують роботу команди, але для них ні в кого не знаходиться часу. Я брав з беклогу таски і виконував їх.

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

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

Щодо Kotlin і Swift, то я вважаю, що це технології, які виконували запит часу. Історично так склалося, що в Android-світі на першому місці була Java, а в iOS — Objective C. Згодом для швидкості розробки виникла потреба в більш лаконічних мовах, які не тягнуть за собою всю спадщину тридцятирічної давності. У 2018 році Kotlin став вибором номер один у світі Android.

Якщо говорити про тренди, то, думаю, варто звернути увагу на low-code та no-code рішення. З певного погляду це суперечливі інструменти, але вони закривають свої задачі. Вони то з’являються, то зникають з радарів і поки що ми не знаємо, як вони будуть розвиватися. Свого часу щось подібне відбувалося з Machine Learning. ML був евристичний, потім статистичний. Тепер ми бачимо, якими шаленими темпами він змінився і зріс за останні п’ять років. Тобто те, що здається трохи дивним, за п’ять років може стати стандартом індустрії.

Схожа історія відбулася з планшетом. Здається, перший планшет розробила IBM у 90-х чи навіть раніше. Та популярними вони стали пізніше, коли з’явився iPad.

«Мітинги заради мітингів — погана практика». Про планування роботи

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

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

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

Насправді «неробство» — дуже важливий процес

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

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

«Працювати лише заради грошей — неефективна стратегія». Про гроші

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

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

Навіть люди, які мають мільярдні статки та фінансову свободу, працюють

Свої акції в Google я і продавав, і зберігав. Я не продавав їх відразу, коли вони ставали доступними. В Google, як і в багатьох інших компаніях, практикують вестинг (схему видачі акцій, коли пакет цінних паперів видають поступово, залежно від часу, який людина відпрацювала у компанії — ред.). Цей механізм допомагає компанії утримувати співробітників. Він справді працює.

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

У мене вже нема потреби працювати, щоб підтримувати своє існування. Але для мене важливе динамічне зростання. Загалом працювати лише заради грошей — неефективна стратегія, є у вас чотири мільйони чи немає. Для мене робота — це щось більше, ніж фінансова незалежність. Це самореалізація і все те, що є в піраміді Маслоу. Навіть люди, які мають мільярдні статки та фінансову свободу, працюють. У них є бажання впливати на щось. Інакше виникає стагнація. Люди почуваються щасливими по-справжньому лише тоді, коли вони до чогось рухаються.

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

«Якщо ви думаєте про зміну компанії, поміркуйте, куди ви біжите: від чогось чи до чогось». Про те, чому вирішив перейти з Google в Ciklum

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

Згодом у Google в мене виникло бажання побачити й інші сторони компанії, і я перейшов з Android Studio в Google Search. Там я збагнув, що в цих частинах компанії різне, а що — однакове. Та в певний момент дійшов висновку, що хочу повернутися в Україну, працювати в product engineering service-компанії.

Думаю, що переходити з однієї компанії в іншу тому, що «усе набридло» і буде +$500 — таке собі рішення. Якщо ви думаєте про зміну компанії, поміркуйте, куди ви біжите: від чогось чи до чогось. Це стосується й релокації в іншу країну. Деякі люди переїжджають просто так, аби переїхати. Усе решта для них не має значення. Цей підхід я вважаю не дуже зрілим і ефективним. Та якщо у вас є певна ідея, ви розумієте, чого хочете (нехай навіть без конкретних деталей реалізації), то ви біжите вже до чогось. Це конструктивно.

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

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

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

А ще я побачив, що IT-індустрія в Україні змінюється, відходить від класичного аутстафу. Мені хотілося допомогти компанії пройти етап такої трансформації. Відповідний досвід, навички, зацікавленість у мене були. Крім того, Ciklum — британо-українська компанія. У нас великий ринок у Великій Британії, багато клієнтів там, є офіс, співробітники. Я працював в Україні та Британії, в аутсорсі і в продуктовій компанії. Тому я побачив, що в роботі Ciklum магічно поєдналося усе, в чому я маю досвід. Для мене це був ідеальний момент, ідеальне місце, щоб реалізувати свої ідеї.

Під час карантину 2020 року сталася цікава історія.

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

Наступне побачення ми запланували в Києві. Ми зустрілись, я освідчився. Дівчина погодилась вийти за мене заміж. Та за кілька днів почався карантин і наш рейс на літак скасували. Вийшло так, що у нас відразу почався тест-драйв сімейного життя. Судячи з усього, він пройшов вдало.

Карантин ми провели в Києві. На певний час поїхали в Дніпро, моє рідне місто. Тоді мені було дуже приємно перевідкривати для себе країну. Я не був у Дніпрі цілих п’ять років і з’ясував, що те Дніпро, яке було у моїй голові, і місто, яке я побачив у 2020-му, — зовсім різні. Можливо, цей ефект перевідкриття України також справив на мене сильне враження, і я задумався про перспективу повернення.

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

Можливо, мені пощастило, бо навчався я за спеціальністю, яка подобалась. Здобув технічну освіту в Дніпровському національному університеті імені Олеся Гончара на факультеті прикладної математики, спеціальність «Інформатика». Програмувати почав у 12 років, ще задовго до університету. Я був самоучкою, але універ допоміг мені в плані соціалізації, прокачування навичок. Там я навчився дотримуватися дедлайнів, працювати й досягати результатів. У мене були підвищені стипендії, іменна стипендія Верховної Ради. Це був корисний досвід: я докладав зусилля й отримував результати.

Думаю, на мій кар’єрний шлях суттєво вплинув перехід від однієї мови програмування до кількох. Спочатку я писав лише на С++, а потім вирішив вивчити Python, і далі пішло-поїхало. Також я світчився між доменами. Спочатку я працював над пошуковими системами. Потім перейшов у Investment banking. Згодом — в Mobile, Google Android. Тепер я фокусуюсь на багатьох галузях і багатьох доменах.

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

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


Підписуйтесь на наш YouTube, щоб не пропускати нові випуски.

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному3
LinkedIn

Схожі статті




25 коментарів

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

МИЛОРД, РАБЫ БЕГУТ С НАШЕЙ ГАЛЕРЫ!

Почему в статье написано, что он вернулся в Украину, а в профиле доу и на линкедине — город Лондон?

Классно. В отличии от ряда других интервью, здесь изложен интересный опыт, а не простыня. По своему опыту в СТО офисе этой компании, могу предположить, что автора ждёт интересный опыт и ему есть что привнести в эту компанию

Пан Дегтярьов був старшим менеджером інженерів в Гуглі, один серед сотень, а став віце президентом, одним серед десятків. Як кажуть на одному відомому в вузьких кругах ресурсі: ТЦ або ГТФО.

Пан Дегтярьов був старшим менеджером інженерів в Гуглі, один серед сотень

Скорее одним среди тысяч

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

Vesting — это сам процесс превращения RSU в SU. Пошагово и постепенно называется TBRSU — time-based RSU.

Time-Based RSU means a RSU which is subject to time-based vesting conditions as set forth in the RSU Grant Agreement.

Будьте добры, подскажите ресурс, или книгу или курс, которому можно доверять. Цель: разобраться для себя с всеми этими rsu, stock opts, vesting

Я бы начал с инвестопедии: www.investopedia.com/...​restricted-stock-unit.asp — там более человеческим языком написано обо всём, обычно книги пишутся профессионалами для профессионалов и тяжело воспринимаются.

«Багата інфраструктура» того, від чого хочеться втекти. От я і йду з чудового аустстафінгу в продукт...

Из всего текста больше всего понравилось слово «продуктолог».

Коротко о процессах)

На одном проекте заказчику продавали в три дорога самые дешевые МакБукиПро 13″ якобы от сертифицированного поставщика.
В итоге вся команда сидела на слабых ноутах)

Первое впечатление что Юра берет интервью сам у себя)

Вік багато що ставить на свої місця :)

Тяжело читать — много слов на «менеджерском».

Люди читають в 10-20 разів швидше ніж дивляться відео. Нема сенсу витрачати 15-30 хвилин на відео, якщо можна пропарсити коментарі за 5 хвилин.

зато видео можно прослушать в машине или на пробежке и на скорости 1,5х

А заодно услышать интонацию, понять насколько человек уверен в своих словах, услышать по его речи скрывает ли он что-то и узнать больше подробностей, ведь, очевидно в статью не попадают все мельчайшие подробности разговора ;)

Вобщем, смотрите видео и ещё подписывайтесь на ютуб 🌚

Підписатись на коментарі