Як у GitLab зрівняли зарплати бекенду та фронтеду та навіщо збірник правил на 13 тисяч сторінок. Інтерв’ю зі Staff Front-end Engineer про роботу в Gitlab та вихід на IPO
Компанія GitLab з українським корінням, яку заснував Дмитро Запорожець, у жовтні вийшла на IPO. При цьому у «внутрішній кухні» GitLab немало цікавого. Компанія працює повністю віддалено з дня свого заснування в 2014 році (сам сервіс з’явився
Ми розпитали Staff Front-end Engineer у GitLab Наталію Теплухіну, як це все працює на практиці, від чого залежать зарплати та опціони, а також про те, чим займається спеціаліст на посаді Staff.
Про рекордно швидке влаштування в GitLab і кар’єрне зростання
— Як відбувся ваш старт на GitLab?
Це було у 2018 році. Я працювала тоді в польській аутсорсинговій компанії, теж віддалено. І виступала інколи на Vue-конференціях як спікерка. Під час конференції в Лондоні, у вересні
Філіпа Ласерда, одна із сеньйор-розробниць у GitLab, тоді спитала: «Чому б тобі не податися до нас?». На що я відповіла: «У вас п’ять стадій інтерв’ю, ви, як Google, я просто не пройду. Немає сенсу подаватись».
Через кілька місяців вона знову почала мене переконувати спробувати, казала: «Пройдеш, просто надішли резюме». В якийсь момент я вирішила, що втрачати нічого, і подалась. Як я знаю, на сьогодні мій процес найму був одним із найшвидших. Минуло сім днів від written assessment — щось на зразок тестового завдання — до оферу. Натомість класичний процес найму в компанії триває від трьох тижнів до двох місяців.
— Які у вас були обов’язки на посаді Senior Engineer у GitLab і які зараз на посаді Staff Engineer?
Нічого особливого, як і в будь-яких компаніях, Senior — це посада, на якій працюєш більш-менш самостійно, контактуючи з бекендом, UX, продакт-менеджером, усіма іншими. Тоді я працювала в команді Create. Ми відповідали за issues, merge requests, коментарі в них тощо.
У GitLab людину підвищують після того, як вона робить щось на наступному рівні. Тобто з огляду на виконану роботу. Як сеньйор я робила те, що має робити Staff Engineer. І це було ще більш цікаво, бо посади Front-end Staff Engineer до цього компанії не існувало.
— У них не було цієї посади, чому вирішили її ввести? Спеціально під вас, виходить?
Ця посада була для бекенд-інженерів, database-інженерів тощо. Зокрема, лінійка Senior Engineer → Staff Engineer → Distinguished Engineer. І на всіх цих позиціях уже були люди. Натомість для фронтенду її не існувало, наш кар’єрний шлях як Individual Contributor закінчувався на сеньйорі — далі можна було йти тільки шляхом менеджера.
Я порушила це питання 2019 року на GitLab Contribute — офлайн-корпоративі, на який збирається вся команда. Мені відповіли, що у нас не настільки складний фронт, щоб стафи існували як клас. Це було правдою п’ять років тому, але за цей час фронтенд значно ускладнився.
За деякий час і після дискусій серед менеджменту вони погодились відкрити стаф-позиції для фронтенд-інженерів. Загалом було декілька людей, які готові були йти на цю позицію. Тобто це була не тільки я.
— Чим займається Staff Engineer у GitLab?
Що вимагають від стафа взагалі? Так, люди часто не знають, хто це. Найсмішніше було, коли питали, чи це пов’язано з HR...
Треба розповісти трохи про структуру, щоб розуміти, як у нас зростають після сеньйор-позиції. Ви можете вибрати шлях менеджера, піти в Engineering Management і дійти до віцепрезидента. Ця робота не потребує кодингу, це не типовий тімлід, який пише код і перевіряє, як ви виконуєте завдання. Це людина, яка саме менеджить команду.
Однак вас може не цікавити робота з людьми, адже не кожен хоче мати 10 мітингів на тиждень віч-на-віч і розбиратися з конфліктами в команді. Тому інший шлях — розвиватися як техлід. Це шлях Staff Engineer. Але тут теж не вийде просто кодити. Ваші обов’язки — пробувати щось нове, будувати proof of concept, стежити за якістю коду, визначати, що треба покращити, зокрема на архітектурному рівні.
Ми стараємось не робити з людей bottlenecks. Ідея не в тому, що ви стаєте незамінним спеціалістом, який розбирається в усьому, а коли йде у відпустку, то все зупиняється. Ні. Ідея Staff Engineer у тому, щоб піднімати команду на свій рівень, навчатись, стежити за якістю кодової бази, постійно удосконалювати її.
Ми почали працювати з GraphQL на фронті, і я ініціювала дискусію про стейт-менеджмент. Нам потрібно було визначитись, чи ми залишаємось на Vuex, чи будемо використовувати можливості Apollo Client. Зупинилися на останньому, і мені довелось писати внутрішню документацію з його використання, тому що мало хто розумів, як працює стейт-менеджмент в Apollo Client cache (для деякої частини команди це й досі магія).
Моє завдання було, власне, розібратися в цьому, навчити команду. У нас нетиповий стек для Apollo — Vue, а не React, тому ми змушені були дещо аналізувати самі, писати мануали. Так, наприклад, було з юніт-тестами Vue-компонентів з Apollo-запитами. Я й досі, коли гуглю, бачу серед перших результатів частину документації VueApollo, яку сама писала, та дві свої статті на цю тему.
— У технічному плані над чим ви зараз працюєте, які проблеми вирішуєте?
Тепер я в іншій команді, вона називається Plan. Основне завдання — розробка архітектури так званого work item. Це динамічна структура, яка буде базою для issue, merge requests, epics тощо.
Це складна задача як для бекенду, який змушений повністю ініціалізувати структуру даних з нуля, так і для фронтенду. Це те, з чим я буду працювати в найближчі пів року.
І, звичайно, крім задач, специфічних для моєї команди, це загальнофронтендні питання: апгрейд Apollo з другої версії на третю, рефакторинг старих shared-компонентів для покращення можливості їх повторного використання тощо.
Про особливості віддаленої роботи для компанії з 1000+ співробітників
— Відомо, що GitLab — це повністю віддалена команда з початку свого існування, з 2014 року. Зараз там працює понад 1400 співробітників у 65 країнах. Скажіть, як влаштовані робочі процеси, управління, взаємодія між фахівцями, які складнощі в цьому?
Чудове запитання! У нас на цю тему написано цілий хендбук. Я вважаю, що хоча б переглянути його корисно для всіх компаній, які працюють віддалено. Він є у відкритому доступі, і практично будь-яку інформацію про компанію (включно з бонусами для співробітників) можна знайти саме там.
— Можливо, є цікаві кейси?
Насамперед те, що вражає людей, які спілкуються з гітлаберами: як у робочі години можна бути на конференції чи відповідати в телеграм-чаті щодо Vue? Просто в нас немає такого поняття, як робочий час,
Узагалі, якщо треба взяти перерву чи відпустку, людина просто інформує про це. Не запитує, а саме повідомляє. У нас є, так би мовити, правило «Don’t ask, must tell». «У мене дей-оф, мене не чіпати». У нас намагаються якомога менше спиратися на синхронну комунікацію і використовувати асинхронну.
До речі, у мене є один обов’язковий мітинг на тиждень — це 1:1 з моїм менеджером. Решта — опціональні, можу долучатися або ігнорувати. Бо якщо я в Австралії, а зустріч о 17:00 за київським часом, то це просто неможливо. Щоб усі знали, що обговорювали на мітингах, їх записують.
До того ж у нас є так звана адженда для будь-якого зібрання. Є гуглдок, в якому перераховуєте все, що збираєтеся сказати, коротко, тезово. Це зручна техніка, якою інші чомусь рідко користуються.
Інколи, коли проводиш зідзвон не з гітлаберами, жодної програми немає, ми просто дві години говоримо, і ніхто навіть не запам’ятовує про що. Це дуже незвично після GitLab.
Узагалі, асинхронна комунікація дуже важлива. Насамперед це issue comments. GitLab спирається на те, що ми використовуємо власні продукти. Якщо хочете влаштувати технічну дискусію щодо виконання того чи іншого завдання, відкриваєте issue і просто в коментарях спілкуєтеся.
— Наскільки це зручно?
Передусім у вас буде завжди збережена дискусія. Не так, що Джон сказав щось, але я не пам’ятаю що. Ні. Розмова записана. По-друге, прилітатимуть сповіщення на імейл, бо ви підписані на issues. По-третє, ви використовуєте власний продукт. Якщо знаходите будь-який недолік, це легко виправити.
Які мінуси? Кажуть, що людина працює повільніше, що час від часу доводиться чекати 24 години, поки колега у Новій Зеландії відпише. На рев’ю відводиться 48 годин. Так, це правда. Однак сьогодні ми на тій стадії, коли вже не поспішаємо. В нас немає такого, що ось це треба заделіверити цього тижня, до релізу.
Мій менеджер колись сказав правильну річ: ми не біжимо спринт, ми біжимо марафон. Тому більш повільний темп нормальний для GitLab, і, якщо врахувати завдання, які виконали за місяць, а не за день чи два, я не бачу великої різниці з компаніями, які працюють в офісі та спілкуються щодня.
Мінуси стали очевидні під час локдауну, тому що навіть на віддаленій роботі всім потрібен соціальний час. До пандемії в нас були гранти на подорожі. Ти міг полетіти в Німеччину зустрітися з колегами, і GitLab повністю покривав вартість перельоту з розрахунку $150 за одного колегу, якого ти зустрів. Тобто зустрів 10 осіб, отримав $1500 на переліт. Можна було за $1500 злітати в Австралію.
Тоді люди часто літали. Були коворкінги, які теж оплачувала компанія, а ще раз на 9 місяців проводили GitLab Contribute — корпоративний івент, на якому збиралася вся компанія. Це було класно. З настанням пандемії, як і в усіх компаніях, стало трішки боляче, бо я, наприклад, деяких колег, з якими працюю щодня, не бачила вже два роки.
Про зарплати в GitLab: від чого вони залежать і як нараховуються
— У вас немає робочих годин, але за якими критеріями тоді розраховують зарплату? Вона залежить від виконаних завдань чи є ставка?
У нас звичайна ставка. Залежно від того, як ви працюєте, раз на рік буде рев’ю, під час якого визначають, на якому з трьох рівнів перебуваєте. Центральний — performing, тобто виконуєте обов’язки на свою ставку. Якщо робите більше, ніж від вас очікують, то це exceeding — перевищення показників.
Ще є нижчий рівень, developing, у нього рідко хтось потрапляє. Він означає, що наразі людина на трохи нижчому від очікуваного рівні. Це не значить, що її звільнять або знизять зарплату. Можливо, фахівця щойно підвищили й він просто не «тягне» свій новий рівень. Тоді менеджер каже: «Окей, ти недовиконуєш тут і тут, виправмо це».
— Наскільки реально виконувати необхідний на ставку обсяг?
Більш ніж реально. Раніше в нас був показник — 10 merge requests на місяць. Наразі від нього відмовились. Тепер у нас більше спираються на якість, ніж на кількість. Те, що ти не спричинив складних інцидентів чи регресій, так званих S1 (severity 1 issue — коли ви щось критично зламали), — це важливіше, ніж 10 merge requests.
У нас немає жорстких кількісних показників. За виконанням задач, які ставить продакт-менеджер, стежать менеджери команд. Тобто нам треба розв’язати певні завдання за наступний квартал. Якщо команда недовиконує, менеджер розбирається, чому так сталося. Якщо ви не зробили щось, але на це були причини, наприклад задача виявилась складнішою, ніж здавалася спочатку, щось недоврахували, то це не розцінюють як underperformance — це нормальна річ.
Раніше наш калькулятор зарплат був відкритий для всіх. Тепер тільки для співробітників компанії. Будь-який фахівець GitLab може подивитися оплату на певній посаді: наскільки вона відрізняється залежно від регіону, перформансу та грейду.
— Чи залежить зарплата від регіону? Якщо, наприклад, ви в Києві живете — отримуєте одну зарплату, в Амстердамі — іншу? Чи великі перепади?
GitLab відкрито заявляє про цю свою політику, і компанію за це неодноразово згадували на DOU. Я читала ці треди про GitLab, який «недоплачує бідним українським співробітникам». Було досить смішно, враховуючи, що моя зарплата в Києві була вищою за третій квартиль статистики DOU щодо сеньйорів.
— Тобто в Амстердам ви переїхали серед іншого й через це?
Думаю, моя відповідь запустить серію типових DOU-коментарів на тему, чого мені не сиділось у Києві з такою високою зарплатою :) Якщо враховувати чисту купівельну спроможність у Києві та Амстердамі, то в Києві вона набагато вища. Набагато. А різниця між київською та амстердамською зарплатнею в абсолютних цифрах не настільки відчутна.
А якщо ще враховувати 5% податку в Україні та приблизно 36% тут (це прогресивна ставка, тому не можна сказати конкретну суму), тож у Києві моя купівельна спроможність була набагато вища.
Коли я переїжджала, то Україна на зарплатній шкалі була нижче, ніж Нідерланди. Нині ж вони більш наближені до рівних, у GitLab взяли курс на вирівнювання зарплат щодо європейських країн. Тому ні, переїзд до Нідерландів був точно не через гроші.
— Чи можете назвати п’ять країн з найбільшими зарплатами?
Можу — США, але не скрізь. В Америці теж виплачують залежно від штату. Найвища зарплата — коефіцієнт 1, від якого вираховуються всі інші коефіцієнти. Це Сан-Франциско, Каліфорнія.
Для Амстердама коефіцієнт становить 0,68, а загалом для Нідерландів — 0,6. На жаль, ці показники не можна афішувати поза GitLab, тому що є компанія, яка надає нам дані до калькулятора (суто статистику за зарплатами у різних країнах/регіонах), і вона проти, щоб показники були у відкритому доступі. Це можна зрозуміти, адже вона цю статистику продає.
Для України location factor — 0,45. Не настільки велика різниця, якщо порівнювати з Нідерландами.
— А найнижчі показники в яких країнах?
Наскільки я знаю, менше ніж 0,45, як в Україні, немає. Річ у тім, що раніше показник для України був нижчим, просто тепер його вирівняли під 0,45 для всіх. Порівняймо Україну та Угорщину. В Угорщині жити буде дорожче, а показник 0,45 все одно.
Натомість в Індії взагалі казка, показник 0,45, а вартість життя набагато нижча. Технічно можна сказати, що Україна внизу, але, якщо ви будете порівнювати з країнами типу Нідерландів або Німеччини, то виявиться, що в Україні жити вигідніше.
Наталія Теплухіна під час виступу на JS Fwdays 2019 у Києві
Про втілення на практиці правил і цінностей GitLab
— У GitLab є збірник правил роботи на 13 тисяч сторінок. Чи справді всі користуються цими правилами й наскільки це ефективно?
Реально всі користуються цими правилами. І для мене це було дивно. Коли я приєдналась до GitLab, як типовому східному європейцю, мені весь час здавалося, що це документ, яким ніхто не послуговується, його опублікували просто для піару. По-друге, я не могла зрозуміти, де пастка, не може ж бути все так гарно, як описано в хендбуці.
Насправді цих правил дотримуються. Скажімо, якщо виникає будь-який незрозумілий момент, то зазвичай ми звертаємося до хендбуку. Причому він не статичний, весь час змінюється. Один із кроків нашого онбордингу інженера — почитати збірник і зробити свій перший merge request, щось змінити, виправити або запропонувати нове.
Усі важливі зміни обов’язково анонсують у Slack компанії. Не може бути так, що ми різко змінюємо якийсь із власних принципів і ніхто про це не знає. Це транслюють, щоб усі зрозуміли, і переважно ще й обговорюють. Важливі зміни — це завжди merge request, у якому є дискусія, навіщо вони.
Водночас якщо ми не погоджуємось, то це абсолютно нормально. Коли у нас були зміни в опціонах, розпалилася дискусія на 300 коментарів. Час від часу це GitLab шкодить. Наприклад, коли компанія зупинила найм Sеnior Reliability Engineer у Росії, то хтось сторонній прочитав відкриту дискусію і пішов постити на Habr матеріал: «GitLab тепер не наймає росіян», і це було смішно і сумно водночас. Як завжди, ніхто нічого не з’ясовує, а відразу публікує.
— Одна з головних цінностей GitLab — Collaboration, співпраця. Як це втілюється на практиці?
Це справді один з показників, який на річному рев’ю враховують одним із перших. І це наразі важливіше за результати. Не так важливо, скільки ви самостійно заделіверили, як те, скільки працювали з командою. Ми ж ремоут-компанія, і якщо перестанемо зважати на співпрацю, то далеко не заїдемо.
Як це втілюється? У нас є дві стадії рев’ю будь-якого технічного merge request. Це означає, що ваш код буде перевіряти щонайменше дві людини. Часто навіть не з вашої команди, і вони будуть залишати коментарі. Це один із принципів співпраці.
По-друге, у нас цінують knowledge sharing, дають бонуси та підвищують за це. Якщо ви знаєте щось, чого ваша команда не знає (йдеться не лише про формально вашу команду, а й про весь фронтенд, наприклад) і можете цим поділитися, то це схвалюватиме і команда, і менеджмент, і це буде найбільш помітно.
Тобто ви намагаєтесь підняти команду на свій рівень. Це те саме, що я говорила для Staff Engineer — це один з основних принципів, на яких GitLab тримається. Тому в нас сильна фронтенд-команда, і вона швидко зростає. Я помічаю, що люди, яких підвищили до мідлів з інтернів, швидко виростають до сеньйорів. Якщо не лінуються. Бо навчити вас хочуть усі, в нас так заведено.
Ось банальний приклад, як це працює, на рівні того ж код-рев’ю. У багатьох компаніях код-рев’ю зводиться до «це погано, це переписати». В нас, якщо я пишу «на мою думку, це не дуже гарна практика», варто додати пояснення на два-три абзаци чому. Бо якщо людина припустилася помилки, то це означає, що вона не розуміє причин. У нас намагаються навчити, а не просто виправити поточні моменти. Це теж співпраця.
— Як у вас вимірюють продуктивність розробника? У GitLab є таке правило, як «We want each team member to be a manager of one who doesn’t need daily check-ins to achieve their goals». Як цього досягають?
Дуже просто. В нас кожен самостійно шукає собі задачі. Звичайно, є певний набір на місяць, квартал тощо. Вони у відкритому доступі. Ви берете й починаєте розбиратися. Менеджер не має ходити за вами, бо ви, як фронтендер, кажете: «Ой, у мене не вистачає частинки API, напевно, треба пінганути бекенд». Ні, так не працює. Ви самі пінгуєте бекенд, пишете, чого бракує. І такий рівень — це норма. Мене дратує, коли час від часу в нашому телеграм-каналі люди пишуть: «Якщо в команді всі відповідають за все, то це означає, що у вас хаос». Ні, в нас не хаос, а відповідальність.
Ми очікуємо від кожного розробника, що він не буде сидіти й чекати, поки замість нього хтось розбереться. Якщо ви вступаєте в дискусію з продакт-менеджером, то наприкінці зазвичай і ви, і продакт вивчите щось нове. Зокрема, ви дізнаєтесь, як колега бачить розвиток продукту. Своєю чергою, він бачить, що у вас є певні технічні обмеження.
Цей рівень обговорень дуже важливий. Те саме з дизайнерами, UX-розробниками, бекендом і фронтендом. Якщо працюєте над чимось складним, важливим, комплексним, то від вас очікують, що на найбільш ранній стадії ви будете пінгувати колег. І це буде колективне рішення. Це, до речі, теж одна з наших цінностей — Transparency (прозорість). Важливо, щоб усі були в курсі.
— Щодо інших цінностей компанії. Зокрема, Transparency, Iteration, Diversity, Inclusion & Belonging. Як вони на практиці працюють? Можливо, є конкретні історії?
Щодо першого та головного Transparency. Насамперед ми open source, і мені це подобається, адже будь-хто може подивитись, який код я пишу щодня. Час від часу він хороший або ж поганий, але у нас абсолютно відкритий source code. Тут часто виникає запитання, за що вам платити? «Чому я мушу купувати продукт, якщо я можу взяти ваш відкритий код і скомпілювати його сам, зробити свій маленький GitLab». Так і задумано, якщо ви можете і хочете це робити, будь ласка.
Крім того, в нас більша частина дискусій відкрита, тобто якщо ви хочете подивитись issue, не тільки щодо програмного продукту, а й маркетингу, HR-тем, то більша частина їх буде відкрита для світу. Закрите тільки те, що може зашкодити компанії при публічному обговоренні — фінансові показники тощо. З тієї ж причини ми не обговорюємо IPO. Це зрозуміло. Будь-які питання щодо ІРО я не можу коментувати.
Якщо говоримо про технічні команди, то ми завжди в курсі, що робиться і на якому рівні. Якщо працюєте в GitLab, у вас повністю відкрита вся фінансова інформація, бо ми всі є співвласниками, у нас є опціони. І тому щомісяця я отримую повний фінансовий звіт про те, як компанія працює, скільки в нас доходу, скільки витрат... Його отримують всі інвестори компанії. Ті, що не працюють у GitLab, теж.
Щодо Transparency, то мені дуже сподобалось, наскільки відкритість може далеко зайти...
— Пригадаєте конкретний приклад?
Так, наприклад, раніше в нас була нерівність в оплаті бекенду і фронтенду. Приблизно на 21% більше отримував бекенд. Для розуміння: наш бекенд — це Ruby on Rails і трішки Go. Фронтенд — JavaScript (з фреймворком Vue.js). На моє запитання, чому така різниця, відповіли: у Сан-Франциско приблизно такі рейти, фронтенд отримує там на 21% менше.
Я вважала це неправильним, бо фронтенд у нас складний і стає все складнішим. І якось прийшла на CTO Office hours (СТО відповідає на наші питання, можна обговорювати будь-що) і запитала: «Еріку, ти справді вважаєш, що складність роботи фронтенду і бекенду в GitLab відрізняється аж настільки?». Це, до речі, з принципу прозорості, тобто я можу прийти і сказати таке СТО компанії на 1000+ людей. Хоча було страшнувато.
СТО відповів: «Ні, я не вважаю, що наш фронтенд настільки відрізняється. Я думаю, що складність у нас приблизно та сама». Я спитала: «Окей, розумію, але у нас є така різниця в оплаті праці, чи можна подивитися базу даних, з якої ми беремо цей показник (повинна ж бути база даних, ми ж від чогось відштовхуємось!)? Я дивилася відкриті джерела, і там не така велика різниця — приблизно у 3%, залежно від джерела, бекенд або фронтенд отримує більше чи менше. Тобто приблизно нарівні».
На що він сказав: «Я не можу відкрити тобі джерело наших HR, але ми можемо з ними зідзвонитися, попросити їх зробити вибірку і подивитися, чому така різниця». Причина була в тому, що в нас фронтенд рахувався як Web Development. Не Software Engineer в JavaScript, а Web Developer. Тобто приблизно, як люди, які займаються сайтиками на WordPress.
Тоді СТО погодився, що це не про наш фронт, що ми працюємо на іншому рівні. І після довгих обговорень —
— Чудовий кейс щодо підвищення зарплати...
Завжди будуть люди в компанії, які ставитимуть питання і не погоджуватимуться з тим, як усе нині працює. Їх можна або звільнити, якщо менеджмент незадоволений питаннями, або ж прислухатися до них. Не слухати, а саме прислухатися. І завжди можна відповісти аргументовано, мовляв, ні, ми не будемо цього робити. Це мені імпонує в компанії, бо коли тобі відмовляють у чомусь, то завжди пояснюють чому.
Водночас можна не погодитись і знову надати аргументи. Одне з наших правил — disagree, commit and disagree. Тобто ти не погоджуєшся, але продовжуєш виконувати свою роботу, згідно з хендбуком і своєю оплатою. При цьому можеш далі продовжувати не погоджуватись і сперечатися. Це одна з важливих речей, яка мені дуже подобається.
Щоправда, за останній рік, на мою думку, рівень прозорості у компанії знизився. Наприклад, калькулятор, який закрився. І все одно я ніде не бачила таку аутсорс-компанію, яка б працювала так прозоро.
Про специфіку менеджменту в GitLab
— Назвіть особливості менеджменту й організації процесів у GitLab, крім ремоуту. Що можете цікавого згадати?
У менеджменті є те, що називається serving management. Менеджер команди не керує вами як юнітом. Він не буде казати, що робити, чи навмисне пришвидшувати. Наші менеджери — це радше психотерапевти, і це дуже приємно. Вони стежать за тим, у якому емоційному, моральному стані перебуває фахівець, як він працює, за конфліктами в команді.
Це був несподіваний момент для мене в перший рік у GitLab. Бо менеджер читав мій Twitter. Не для того, щоб сказати, що я пишу щось не те про компанію, а для того, щоб помітити моє незначне вигоряння. Він зауважив: «Ти, здається, трішки втомилась, маєш багато комітів і в GitLab, і у Vue, візьми кілька дей-офів, а може, й відпустку».
Узагалі, про «візьми відпустку» — це часта тема, яку можна почути від менеджера, якщо активно працюєте. Наприклад, якщо кажете: «У члена родини день народження, можна взяти один вихідний?». То менеджер відповість: «Може, два?». Над таким у нас не заморочуються, і менеджери дуже уважні. І це справді як психотерапія.
Також у нас не тиснуть на розробників, кожен достатньо самостійний і відповідальний для того, щоб працювати без наглядача. І це одна з тих тем, які трапляються і на DOU, і в інших обговореннях. Я неодноразово помічала, що більшість потребує наглядача, а інакше ніхто не буде нічого робити.
І всі запитують: у вас же ремоут-команда, ніхто над тобою не стоїть? Насправді це все вирішують на моменті відбору. Ці самі софт-скіли на інтерв’ю. В нас намагаються наймати тих людей, які будуть працювати самостійно, якщо їм цікаво.
Якщо не цікаво, це вже проблеми компанії. У нас радше намагаються вберегти фахівців від вигоряння, бо вони працюють у нас більше, ніж звичайно. Водночас вас ніхто не змушує, але з того, що я бачу, люди в GitLab радше перепрацьовують, ніж недопрацьовують.
— На чому зараз сконцентрована робота в GitLab?
Наразі триває глобальна зміна цінностей з кількості нових фіч на якість. Це була основна фішка GitLab — більше й більше цікавих нових фіч. Тепер уже не так важливо заделіверити щось нове, як підвищити якість і швидкість роботи, зменшити кількість інцидентів та регресій. До речі, цікаво це обговорювати після того, що нещодавно сталося з Facebook.
Усі, мабуть, пам’ятають, як у GitLab понад п’ять років тому був інцидент, коли програміст дропнув базу. Це була одна з причин, чому я сюди прийшла. Я знала про цей кейс, як вони з ним впорались, як почали стрімити те, як відновлювали бази тощо.
Під час влаштування в компанію я запитала тих, хто мені порадив йти сюди, чи цей фахівець ще працює. Так, він досі тут. Мало того, після цього випадку його підвищили, бо GitLab вивчив багато нового щодо безпеки саме завдяки цьому.
Коли приходите в GitLab, у вас є обов’язок — зробити п’ять coffee calls. Це дзвінки на довільні теми з різними людьми, з різних департаментів GitLab. Перша людина, якій я зателефонувала — був той самий розробник, який колись дропнув базу.
Мені було страшенно цікаво послухати, як це було. Це специфічна історія, і те, що він працює досі, означає, що компанія не ставиться до людей як до ресурсу, який легко звільнити чи замінити.
— Якось ви казали, що найважче для вас не код, а люди. Розкажіть про конкретні випадки, чому так вважаєте, які у вас головні підходи для розв’язання схожих проблем?
Проблема синхронної комунікації. Частково тому, що у нас немає жорсткої вертикалі керування. Наприклад, я не можу прийти та сказати: «Ти пишеш код отак». Як я уже розповідала, ви маєте все пояснювати. І у людей бувають різні погляди на одну й ту саму ситуацію, особливо якщо вони не з однієї команди.
Одним із яскравих прикладів є те, як я перейшла в теперішню команду Plan. Тут будували складну фічу, переводили її на GraphQL, і мене залучили як експертку (я на той час ще була в іншій команді). І запитали про стейт-менеджмент. На що я відповіла: «Ви використовуєте GraphQL, найкраще буде взяти Apollo Client cache». Натомість лідер розробки сказав: «Я не знаю Apollo і буду користуватися тим, що знаю краще, тож ми будуватимемо навколо цього фічу».
Я подумала: а що я технічно можу зробити? Я взагалі працювала в іншій команді. Моє завдання рекомендувати та поінформувати.
За три місяці мене перевели в цю команду, і тоді це стало вже моєю проблемою. Складним моментом було те, що людина справді не знала Apollo Client. Моя стратегія була не конфліктувати, не сперечатися про те, що вони вже використовували у будуванні фічі, а робити сторонні маленькі задачі з Apollo. І залучати колегу, щоб він поступово його вивчав. А я робила рев’ю і пояснювала.
За чотири місяці співпраці в такому форматі розробник сказав, що тепер знає Apollo client, що я мала слушність і що взяти замість нього Vuex для стейт-менеджменту було помилкою. Це непросто, особливо якщо працюєш на довгострокову перспективу. Складно не командувати, не намагатися все сконцентрувати у своїх руках.
Після роботи в аутсорсі думаєш: «Краще я зроблю це сам і буду впевнений у результаті». Але якщо ви сам, то виконуєте лише певну частинку роботи. Щоб вашу роботу можна було масштабувати, потрібна команда. Якщо ви здатні цю команду навчити, то будете набагато ціннішими, ніж людина, яка просто знає, як це виконати. Але делегувати відповідальність складно.
Про співробітників і специфіку найму в GitLab
— Із понад 1400 людей, які працюють у GitLab, який відсоток технічних спеціалістів?
Більш ніж половина. Найбільше з них бекенд-інженерів, фронтенд-команда маленька.
— Скільки спеціалістів з України?
Порахуймо. Перше і найважливіше — в Україні живе Дмитро Запорожець, який є засновником компанії. З технічних спеціалістів значна кількість у Харкові, тому що Дмитро там, і команда Ruby-розробників формувалась у Харкові. Кілька спеціалістів у Києві, а ще є у Львові та Дніпрі. Весь список команди у відкритому доступі. 11 фахівців загалом з України.
— У яких країнах найбільше співробітників?
Досить багато їх у США. З Європи найбільше людей у Нідерландах. Сюди все частіше переїжджають. Річ у тім, що в GitLab є локальна entity, не офіс, але юридична особа, і компанія пропонує допомогу під час релокації в Нідерланди. Попри те, що ви можете працювати віддалено, повнісю підтримує з візою, переїздом. Тому тут багато фахівців. І з США теж переїжджають у Нідерланди.
— Чи берете ви участь у наймі розробників для GitLab?
Так, я інтерв’юер. Якщо ви проходите технічне інтерв’ю в GitLab, то можете потрапити на мене.
— Яка специфіка і що найголовніше в цьому?
На відміну від більшості інтерв’ю, в нас основний фокус не на хард-скілах, a на софт-скілах. GitLab м’яко ставиться до того, що ви знаєте з фаху. Тобто, якщо є не всі потрібні технічні знання, це не критично.
Наше технічне інтерв’ю максимально наближене до повсякденної роботи. Ви не будете писати алгоритми, у вас не буде whiteboard interview. Лише merge request. Матимете одну добу, щоб його вивчити, зробити рев’ю. І на інтерв’ю ми будемо обговорювати коментарі, які ви залишили до merge request, що б ви зробили по-іншому. Якщо маєте пропозиції змін, можна імплементувати це зараз на реальному коді.
Код абсолютно реальний, це один із невеличких застосунків, які в нас є в GitLab. На ньому є помилки на різних рівнях. За тим, як ви будете робити рев’ю merge request, визначать ваш рівень. Якщо ви знайшли помилки більш простенькі й не торкнулися архітектурних, найімовірніше, вам запропонують посаду Middle.
Якщо ви розбирались більш архітектурно, сказали, як плануєте рефакторити цей застосунок — найімовірніше запропонують Senior. Але це знов-таки не основний фокус. Головний акцент буде на тому, наскільки ви впишетесь у команду. Для віддаленої команди важливо, щоб ви «Don’t be an asshole».
Будьте нормальними. А це велика проблема, зокрема для українських розробників. Я знаю як мінімум один випадок, коли розробника з надзвичайно високим рівнем технічних навичок не взяли в GitLab саме через брак софт-скілів.
— Він не хотів чи не вмів комунікувати?
Річ у тім, що ще на скринінг-інтерв’ю виникли певні проблеми з усвідомленням своєї позиції в команді, бо співпраця в нас на першому плані. Були певні труднощі з нетерпимістю тощо. Це, до речі, стосується і diversity & inclusion.
— Чи є в GitLab квоти з найму співробітників?
Мені подобається, що у нас немає поняття квот для найму. Я не вважаю, що квоти змінять хоч щось на краще. Мало того, в нас є заохочення. Якщо я порекомендую розробника в GitLab і його наймуть, мені дадуть реферал-бонус, як це зазвичай трапляється в IT-компаніях. У нас це умовно $1000. Якщо я найму людину з країни, яка, відповідно до фактора локації, нижча за 0,5 (Україна, наприклад), то отримаю $1500 бонусу. Бо для компанії це вигідно. А якщо я при цьому рекомендую будь-кого з недостатньо представленої групи (underrepresented group) — $2000.
Це залежить від відділу, куди я рекомендувала людину. Наприклад, якщо я рекомендую кого-небудь у HR-відділ, і це жінка, вона не є underrepresented, тому що цей відділ у нас представлений обома статями, більш-менш рівномірно.
Натомість якщо я рекомендую жінку у фронтенд або ще краще бекенд-розробку, то це буде вважатись недостатньо представленою групою, бо їх тут менше як 10%.
Однак це не означає, що якщо я рекомендую жінку, то її відразу наймуть. У дівчат процес нічим не відрізняється від того, що у хлопців. Але якщо наймуть жінку, то мій бонус буде більшим. Тому я як співробітниця GitLab заохочена більше рекомендувати людей, які можуть пройти інтерв’ю. Бо GitLab отримає кваліфікованих розробників, але разом із тим команда стає більш diverse, і це, з мого досвіду, краще для команди.
— Тобто ви зацікавлені не тільки в поточній розробці, а й у тому, щоб запросити якомога більше дівчат на бекенд у GitLab?
Як на мене, це на краще і для розробника, і для команди. Бо я бачила команди, в яких дівчат немає взагалі, і в них більше конфліктів.
— Чи багато ви з України запросили працівників?
Офіційно в мене два реферали, яких найняли з України.
Про опціони в GitLab та ІРО
— Розкажіть про опціони. Як влаштована система опціонів у GitLab? У всіх співробітників різна кількість, від чого вона залежить? І скільки опціонів кожен може отримати?
Кількість опціонів залежала від посади. Одна кількість була для Middle, інша для Senior, для менеджера. Ми починали отримувати опціони при наймі: 25% після першого року роботи й далі протягом трьох років ще 75% (певну частку видають помісячно). Ще були так звані options grants, які видавали після річного performance review, залежно від того, як людина працює.
Бонус сильно залежав від перформансу. Це різна сума для всіх співробітників компанії. Ще є категорія «key talent», що отримувала максимальну кількість опціонів як грант.
Загалом має діяти така сама практика в майбутньому. Будуть видавати гранти, можливо, не опціонами, а RSU — Restricted stock units для того, щоб ви отримали свою частку в компанії ще й акціями.
— Ця схема більш класична для західних компаній. Про SalesForce, наприклад, відомо, що спочатку там отримують 25% за перший рік роботи, потім 50% на другий рік, ще 75% — після третього року. І тільки за чотири роки дають 100% призначеного пакету опціонів + відсотки, які наросли за цей період. До того ж працівник купує акції за тією ціною, яка була на першому році, коли він прийшов у компанію. Схожа схема й у GitLab?
Так, те, що вам закладали при наймі, повністю видавали за чотири роки. У кожного співробітника є система, де можна подивитися, яка була вартість першого гранту, яка вартість усіх інших, скільки «завестили» тощо.
— Компанія GitLab оголосила про ІРО. Знаю, що ви не можете про це говорити, але скільки може заробити, наприклад, Senior-розробник компанії?
Узагалі не можу нічого сказати, все залежить, як тепер буде після ІРО і хто і як збирається продавати акції. Це може бути абсолютно різна сума, залежно від того, коли ви збираєтесь продавати та чи збираєтесь продавати взагалі.
— Як у компанії сприйняли новину про вихід GitLab на IPO, залучення понад $800 млн від продажу акцій і зростання капіталізації стартапу до $15 млрд? Якось відзначали цю подію у вашій команді та ви особисто?
GitLab провів публічний стрім розміщення на Nasdaq. У команді святкували, звичайно. Це можна було побачити на численних фото в Twitter. Особисто я нейтрально сприйняла цю новину.
Про роботу з Vue.js
— Уже досить давно ви залучені в core team Vue.js. Якось говорили в інтерв’ю, що це нудний процес, який узагалі грошей не приносить, та ще й багато критики навалюється. Яка мотивація далі цим займатися? І що зараз робите в проєкті?
Це приблизно те саме, що ділитися знаннями в GitLab. Я пишу документацію для фреймворку і знаю, що практично всі, хто вчить Vue 3, будуть користуватися тим, що я написала. Приємно усвідомлювати, що люди можуть вивчити щось із того, що ти створив.
Я дивлюсь на це як на умовний «борг»: у мене непогана робота, я отримую гроші, і хочеться якось віддячити тим людям, які свого часу рекомендували мене в GitLab чи навчили програмувати. І я віддячую тим, що вчу наступну хвилю розробників, яка навчить ще когось.
Тому я й пишу документацію фреймворку, і мені приємно знати, що її вважають легкою для засвоювання.
— Ви щодня цим займаєтесь?
Зараз менше. Документація для третьої версії вже дописана, вона оновлюється не так інтенсивно. Наприклад, коли ми готували документацію до «трійки» перед релізом (перед вереснем 2020 року), то це могло зайти й 20 годин на тиждень, бо треба було закінчити. Сьогодні це п’ять годин на тиждень, іноді менше.
— Чи стежите за новими технологіями у фронтенді? Наскільки глибоко занурюєтесь у них?
Стежу. Я думаю, що будь-який фронтенд-інженер, який працює на велику компанію і на більш-менш нормальній позиці, буде це робити. Адже ми, як Аліса в Задзеркаллі: щоб залишатись на місці, треба бігти, а щоб просунутися вперед, треба бігти ще швидше. Тому обов’язково всім цікавимось.
Наскільки глибоко? Я, наприклад, не буду стежити за всіма новинками у всіх фреймворках. Не скажу, що нового буде в останній версії React, бо не працюю з ним. А те, що стосується Vue-світу, буду читати. Цікавитимуся такими рішеннями, як react-query, тому що це може змінити й мою роботу. Досить глибоко, але не так широко. Загалом не охоплюватиму всю сферу сучасного фронтенду.
Наталія Теплухіна на GraphQL Summit 2019 у Сан-Франциско
Про участь у конференціях і розвиток soft skills
— Що вам дає участь у різних конференціях? Наскільки зараз їх багато і в якому форматі через локдауни?
Це можливість поділитися своїми знаннями та вивчити щось нове. Можливо, часом не навчити, а надихнути. 30 хвилин доповіді для того, щоб навчити, — це дуже мало. А ось 30 хвилин для того, щоб надихнути щось вивчати, — достатньо.
Будь-яка конференція — це спілкування з багатьма людьми, і до чого воно приведе, ніколи не знаєш. Наприклад, можна влаштуватися в GitLab. Або один із класних українських спікерів піде у GitLab, бо послухав вас на конференції. До речі, Ілля Климов — один із тих, кого я переконала приєднатись до нашої команди.
Або можна почерпнути щось нове з доповідей або в кулуарах. Це нетворкінг і навчання — два в одному. І тому онлайн-конференції викликають сум. По суті, для спікера участь зводиться до запису відео та умовного спілкування в чатах.
Приємно бачити, що деякі офлайн-конференції відновлюються. Днями була конференція в Єревані (Вірменія). Там зібралося троє гітлаберів-спікерів. Рада була всіх побачити та поспілкуватися.
— Можливо, порадите, як розвивати soft skills саме розробникам, адже їм усе одно потрібно комунікувати?
Я знаю, що є багато книг про це, але переважно вони для менеджерів. Якщо можете, читайте, особливо видання для технічних менеджерів. Наприклад, «Як пасти котів» Дж. Генка Рейнвотера. Ці рекомендації можете використати, навіть якщо ви звичайний розробник.
Щодо інженерів, які хочуть писати код і більше нічого, — ви ж все одно робите рев’ю. Спробуйте хвалити, і це особливо важливо для українських розробників. Почніть із того, що добре. Я думаю, в усіх українців є негативний досвід, який тягнеться ще зі школи. Коли виконуєш будь-яку задачу, і вчитель із червоною ручкою підкреслює те, що погано.
Сподіваюся, що щось змінилось, але з того, що я пам’ятаю, то ніхто ніколи не казав, що у вас добре. «В тебе чудовий твір, який написаний просто казково, ці порівняння, метафори такі влучні, ти пропустив дві коми, а решта — супер». Ні, такого не говорили. Усе, що ви чули, це мінус бал за орфографію, ще мінус бал за пунктуацію. І це прошивається в нас на базовому рівні.
Коли рев’ю проводять українські розробники, у яких немає досвіду співпраці із західними компаніями, — це жах. Спробуйте бути більш людяними в цьому. Це було в тредах на DOU. Щось про те, що в американських компаніях фейкова ввічливість. Знаєте, я, як розробниця, виберу фейкову ввічливість проти абсолютно правдивої грубості. Мені байдуже, адже я бачу цю людину вперше і востаннє, так само як у merge request: я бачу цього фахівця раз на рік. І мені краще, щоб там була вдавана посмішка, ніж відкрите хамство. Для наших розробників це типово.
І для мене теж, не скажу, що в мене всі рев’ю у єдинорогах і райдугах. Я так само вчилася з позиції «це і це погано». Ще одна проблема — сприйняття критики. Це коли читаєш коментарі й відразу думаєш: «Ні, ти не правий, бо критикуєш те, що я роблю».
У нас сильні розробники, з гарним тайм-менеджментом, навичками планування. Фактично всі українці, яких ми наймали, мали високий технічний рівень. Ще б трохи прибрати токсичність, то взагалі було б ідеально.
Про плани на майбутнє
— Які у вас плани на майбутнє, чого хотіли б ще досягти в кар’єрі?
Тепер у мене буде спокійний період, можливо, з невеликим кар’єрним зростанням усередині GitLab. Планую підкорити наступний щабель, який називається Principal Engineer. Принципалів ще немає ніде в GitLab, це новий проміжний рівень між Senior і Distinguished. У GitLab, думаю, це буде об’єднана позиція.
— Які обов’язки вона передбачає?
По-перше, треба мати знання і бекенду, і фронтенду. По-друге, керувати проєктами середнього й великого розміру, в тому числі з нуля. Зараз працюємо над таким у команді. Цікаво буде подивитись, як це впливатиме на департамент, який є великою одиницею в GitLab.
Пояснюю. У нас є команди, які з’єднуються в stage, своєю чергою, stage з’єднується в subdepartment, а потім уже в department. От як Principal ти повинен впливати на департамент. Зараз частина моєї роботи впливає на весь фронтенд, а не лише на департамент. Просто тепер треба буде додати ще бекенд.
— Це те, що стосується GitLab. Можливо, ви плануєте власний бізнес відкрити?
Ні, я бачила, як живуть стартапи, і знаю, що це буде робота 24/7. Мене влаштовує позиція найманого працівника в компанії, можливо, на трошки вищому рівні, ніж у GitLab. Можливо, в якийсь момент я перейду в менеджмент. Буду більше працювати з людьми. Наразі цього не хочу, але й не заперечую проти цього. Піти по вертикалі менеджменту і подивитись, що з цього вийде, бо в GitLab я навчилася не лише фронтенду (його я знала і до того), а й того, як керувати командами, вибудовувати процес, спілкуватися.
Щодо процесів, то це окрема тема. Коли бачиш компанії, які тільки починають, з
