LinkedIn, Twitter, Google і знову Twitter: український розробник — про те, як будував кар’єру в США
Розробник Володимир Жаб’юк уже 17 років у професії. У його послужному списку понад 10 компаній, серед яких Twitter, Google, LinkedIn. Стаття вийде у двох частинах. У першій розповімо про кар’єру Володимира в Україні та США, що йому не сподобалося у Google і чому він вирішив повернутися у Twitter. Також розробник проаналізував свій досвід роботи в стартапі та докладно описав особливості співбесід у великих американських компаніях.
Освіта та кар’єра в Україні
Я народився в Івано-Франківську, де навчався в гімназії № 1 у класі з поглибленим вивченням математики, фізики, англійської мови. Школа була така, що ми сиділи на уроках до четвертої дня. В десятому класі у мене з’явився комп’ютер, тоді ж я почав цікавитися програмуванням, щось робити саме вдома, а не в школі. Пробував розібратися з Delphi та С++, хотів подивитись, наскільки важко отримати візуальний результат. Наприклад, зробити гру чи щось таке. Для мене це було трохи схоже на магію. І найпростіші речі мені вдавалися.
Після школи я вирішив вступати до Могилянки на інформатику. Мені сподобалося там навчатися. Цікава атмосфера, незвичайні люди. Стосовно знань, я сказав би, що нам дали достатню основу з програмування, алгоритмів, математики й навіть гуманітарних предметів. Самі викладачі зауважували, що вони вчать нас, як навчатися, як здобувати знання. І мені здається зрозумілим, що в університеті не буде всього, що потрібно для практичної діяльності. Але здобутих знань мені вистачило, щоб знайти роботу. З третього курсу я вже почав працювати.
Отже, коли мені було 20 років, я знайшов першу роботу. Компанія розміщувалася в Інституті ім. Патона, її зараз вже нема. Вона розробляла програмне забезпечення для проєктування трубопроводів російського «Газпрому». Використовували Delphi та Oracle. Мені дали тестове завдання. І я був єдиним з кандидатів, хто його виконав. Потім вони довго сміялися з того, як я його зробив: я не мав уявлення, як робити UI-компоненти.
Графічний інтерфейс був створений дуже неправильно, я порушив базові принципи UI-дизайну. Наприклад, були немодальні вікна, кожен клік на кнопки відкривав нове вікно. Але оскільки я був єдиним, хто взагалі впорався, мене взяли. Там я більше працював з UI, тобто робив графічні інтерфейси. Також у мене було завдання створити графічну бібліотеку на Java. Чесно кажучи, не знаю, навіщо їм це було потрібно, але ось так. Я працював там місяців п’ять і паралельно вчився. Це був мій перший реальний досвід програмування не в класі.
Потім я звільнився, бо вирішив, що не хочу працювати в літні канікули. Наступна моя робота була в іноземній компанії, писав більше на Java. Тоді я вже отримав перший досвід проходження співбесід за процедурою, якої дотримуються в більшості компаній України. Я фактично працював фултайм, але зі зміщеним графіком, бо роботу треба було поєднувати з навчанням на четвертому курсі. До закінчення університету, тобто наступні три роки, так і було: я вчився і працював.
Взагалі я змінював багато робіт. На кожній з них перебував плюс-мінус рік. Чому так? Коли я тільки приходив у нову компанію, у мене було багато мотивації: я хотів усе вивчити, показати себе, зробити щось корисне, розвинути продукт. А за рік ця мотивація трохи зменшувалася, бо робота ставала стабільнішою, ставало менше викликів, розвитку. Тоді щось усередині починало мене підмовляти: «Ти вже так не вчишся, десь можна більше...».
На той час, до речі, цікавим було зростання моїх зарплат — зовсім нелінійне. На першій роботі я отримував 400 доларів, на наступній —
Дуже багато мені дав Ciklum. Я працював у команді, де було 18 людей, всі надзвичайно розумні, вони багато чого могли навчити: як робити проєкти, як їх тестувати, як планувати, як виконати щось у найпростіший спосіб, яку літературу читати.
Перша моя робота на позиції Team Lead була в Reuters. Я займався їхньою платформою на платній підписці. У нас була команда з чотирьох фахівців, а ще було дві сусідні, що займалися СМS-системою та пошуком. Ми регулярно їздили у Нью-Йорк. І це теж був важливий досвід, бо я вперше побував за кордоном.
Також мені дуже сподобалося працювати в GlobalLogic. Там я став Scrum-майстром. Команда була дуже велика: 23 розробники й два тімліди. По суті як такого Project-менеджера чи просто менеджера не було. Другий Team Lead з’явився пізніше за мене, тому я довго виконував роль Scrum-майстра і частково менеджера. Крім того, на мені була комунікація із замовниками, планування спринтів, ретроспективи, тобто багато координації та вирішування питань з командою, планування роботи. Це було не просто, але цікаво. Такий досвід допоміг мені значно розширити свої навички.
Переїзд до США
Із 2008 року я почав шукати варіанти, як виїхати за кордон. Подавав резюме, але тоді це не надто виходило. У
Насправді цей період був цікавий і непростий, бо відбулося відразу багато змін. Я адаптувався і до сімейного життя, і до нових умов. В Україні я заробляв достатньо та ніколи не переживав за гроші. Коли я виїхав у США, стало складніше: заробітна плата збільшилася, але й витрати значно зросли. Ще була мовна адаптація. В Україні моєї англійської вистачало для роботи із замовниками, але спілкування у щоденному житті — це трішки інше. До того ж я ніколи не працював і не мешкав в інших країнах. Потрібно було розбиратися з питаннями житла, медичної страховки, купівлі машини, меблів... Щодня я мав щось вирішувати. А ще нове оточення, нові друзі... Перші
На першій роботі я пропрацював 11 місяців. Мені взагалі дуже сподобалося в EPAM. Вони багато мені допомагали з переїздом, акліматизацією, підтримували мене в роботі із замовником, щоб не було жодних проблем з комунікацією, консультували щодо медичних послуг тощо. Робота була дуже цікава, я лідив команду, яка здебільшого розташовувалася в Києві, а ще допомагав набирати onsite-команду із Business Intelligence в Expedia та в сусідні EPAM-команди, що працювали на Expedia.
Чому я вирішив шукати нову роботу? По-перше, я приїхав за HB-1 візою і було невідомо, наскільки швидко компанія зробить мені грін-карту. По-друге, я бачив різницю в оплаті між моєю позицією контрактора через EPAM на Expedia і тим, що я міг заробити в інших компаніях. Ця різниця була велика. І, по-третє, мотивація: я хотів працювати над чимось складнішим, нетривіальним, над проєктами, що використовують мільйони людей... І щоб реалізувати таку мету, потрібно було шукати нову роботу. Тому я почав проходити співбесіди.
З дружиною
Особливості співбесід у США
Перша моя співбесіда була в Amazon. Я нібито нормально пройшов її, але мене не взяли. Потім у мене були інтерв’ю ще в кількох компаніях, у тому числі в Google. Туди я теж не пройшов, можна сказати, що навіть пролетів. Я, напевно, провалив три співбесіди з п’ятьох. Чому? Пропонував занадто складні рішення і не встигав їх повністю закінчити, не слухав усіх порад інтерв’юера та банально розгубився.
Я відразу відчув різницю з інтерв’ю в Україні. До переїзду я пройшов, напевне, понад 50 співбесід, а провів ще більше. Я готувався до співбесід, мав досвід, як їх проходити, але він виявився нерелевантним у Сполучених Штатах.
Яка основна різниця? З того, що я пам’ятаю, в Україні на співбесідах питають не загальні, а специфічні речі. Якщо це, наприклад, інтерв’ю із Java-технологій, то тобі можуть ставити питання щодо Spring Scope, особливостей custom serialization/deserialization спрингу, про рівні ізоляції в реляційних базах даних чи чогось такого дуже специфічного. Питання більш технічні: про фреймворки, конкретні мови програмування. Тобто робиться установка на те, щоб людина вже не дуже багато вчилася на цій посаді, а прийшла і зразу могла працювати.
У Штатах великі компанії проводять значно довші співбесіди, ніж в Україні, та багатоетапні. Здебільшого є одна чи дві телефонні співбесіди. Одна з них з менеджером чи рекрутером, коли вони перевіряють, чи людина зацікавлена, чи є в неї є необхідний досвід. І після цього може бути ще одне чи два телефонних інтерв’ю — вже технічних, коли дають просту задачу, наприклад, змерчити два відсортовані інтервали.
Потім буде вже onsite-інтерв’ю —
Потім технічні зустрічі. Це може бути три співбесіди з написання коду — з такими ж питаннями, як і на телефонній співбесіді, але трошки важчими. Часто спочатку інтерв’юер дає високорівневе завдання, тому потрібно ставити уточнювальні запитання. Цього й очікують, що людина буде уточнювати всі деталі, вимоги. Потім кандидат починає писати код на дошці чи комп’ютері та водночас розказувати, що робить і чому так, а не інакше. Якщо вже код написаний, видно, що він працює, можуть дати написати на нього юніт-тести, попросити оцінити часову складність алгоритму, можливо, спитати ще щось про алгоритми. А далі будуть ускладнювати задачу. Найкращі питання — ті, де є
Також можуть бути
Це я нині сам проводжу по дві співбесіди на тиждень, тобто загалом це приблизно
Взагалі мені дуже подобався LinkedIn, я читав їхній блог, дивився їхні open-source проєкти, мене туди тягнуло. Співбесіду я пройшов дуже добре. Хоча був один небезпечний момент. Вони запитали мене, з чим я люблю працювати: Front-end чи Back-end, і чи можу я працювати Full Stack. І я сказав, що не люблю працювати Full Stack і загалом з Front-end, що мені більше подобається Back-end. І для них це було як red flag — показник того, що я не дуже хочу змінюватися чи пробувати нове. А в більшості їхніх команд треба було б якраз робити i бекенд, і щось ближче до фронтенду.
Але мені пощастило. Була команда, яка займалася open-source, і їм потрібна була людина з досвідом на бекенді. І, до речі, open-source досвід у мене теж був. Тож так вийшло, що я потрапив у команду, яка займалася не конкретно продуктом LinkedIn (хоча робила структуру даних і для них), а open-source проєктами, які компанія публікувала, щоб користувачі зі всього світу могли ними послуговуватися.
У LinkedIn я працював на Java, NoSQL, Spring, Lucene. Мій проєкт називався SenseiDB, він був подібний до Elasticsearch і Solr. Це наполовину база даних, наполовину search engine: система, яка дає змогу індексувати документи, щоб потім можна було у real-time фільтрувати й агрегувати дані. Схоже на реляційну базу даних, але різниця у тому, що ми можемо робити також full-text search, зберігати набагато більше даних (мільйони, сотні мільйонів документів) і повертати їх набагато швидше. Вся робота в real-time, із затримкою менше як кілька сотень мілісекунд. Всередині LinkedIn ми робили цю систему для Homepage. Ще були
Я працював якраз над індексацією, над новими фічами. Майже всі учасники моєї команди (ще п’ять осіб, крім мене) були вихідцями з Китаю. Ми досить продуктивно працювали, запрошували інші компанії, робили їм презентації, а ще рекламували себе всередині LinkedIn, щоб більше внутрішніх команд почали нас використовувати.
Спочатку я працював над цим, а потім у нас з’явився дуже цікавий юзкейс. Нам потрібно було індексувати вже не сотні мільйонів чи мільярди документів, а сотні мільярдів. І зробити пошук за ними в real-time. Зараз є Presto, Druid, які можуть виконувати ці функції. А тоді потрібно було повністю перебудувати наші індекси. Це було надзвичайно складно зробити в технічному плані: потрібно було створювати дуже компактні індекси, сканувати сотні мільйонів документів у секунду на одній машині, водночас пошук за ними мав бути швидким.
Це ми вже робили для частини LinkedIn, яка відповідає за Revenue — Ads impression. Наприклад, якщо користувач побачив рекламу, ми вносимо новий запис у наші бази даних. Кожен запис охоплює дані про користувача і рекламу. Потім система може відповідати на питання на кшталт «Скільки користувачів у Нью-Йорку, яким понад 30 років і які мають досвід у готельному бізнесі, бачили цю рекламу за місяць?».
Там я пропрацював два з половиною роки. LinkedIn зробили мені грін-карту. Запустили процес через три місяці після того, як мене найняли. Це зайняло 11 місяців, бо я заплатив за premium processing. Після грін-карти рівно за 5 років я отримав громадянство Сполучених Штатів.
Насправді в LinkedIn було дуже круто. Вплинуло й те, що я потрапив у компанію якраз після IPO, тому там було багато енергійних, талановитих людей, постійні хакатони, цікаві ініціативи... Взагалі кожна компанія проходить один і той самий шлях: спочатку кілька раундів фінансування, а якщо фінансові показники вже виходять на певний рівень, вона може виходити на біржу або її можуть купити. Обидва варіанти непогані. У першому випадку перед IPO компанія повинна починати якісь нові напрями, показувати експоненційне зростання для інвесторів.
Тому в Кремнієвій долині є певні тенденції, що за рік-два перед IPO в компанію приходять люди, які можуть дуже швидко і класно реалізувати багато ідей. По суті, це такі «мисливці за IPO», які виводять організацію на новий рівень, за що отримують великі гроші, бо компанія при IPO щедро дає акції. Хоча, звісно ж, IPO — це також лотерея. Але може бути таке, що акції зростуть у декілька разів. Потім ці «мисливці» ідуть в іншу компанію, яка готується до виходу на ринок. Я прийшов після IPO, але і в мене вартість акцій зросла більше ніж удвічі.
У LinkedIn я завів багато друзів. Деякі зв’язки підтримую і сьогодні, хоча минуло вже 9 років.
Отримали громадянство :)
Перехід у Twitter
Наш Director of Engineering в LinkedIn перейшов у Twitter, який на той час був при IPO і мав вийти на біржу за кілька років. І відразу за ним через певні непорозуміння з Leadership компанії туди пішов і мій менеджер, який був засновником SenseiDB і напряму Search databases в LinkedIn. Наша дружня команда розпалася.
За деякий час я запитав у свого менеджера, як йому в Twitter, чи все подобається. Він розказав, що там зовсім інша інженерна культура, тобто масштаб і технічні проблеми складніші, ніж у LinkedIn, а, наприклад, внутрішні тули, які вони будують, їхні бази даних, системи Observability чи для A/B testing — дуже круті. Та й взагалі, десятки тисяч твітів на секунду, мільярди користувачів, сотні мільйонів активних користувачів — будувати інфраструктуру для цього — це надзвичайно круто. Я загорівся. До того ж більша частина нашої команди вже перейшла в Twitter.
Я не потрапив до свого менеджера. Але мене скерували в групу проєктів, які належали колишньому Director of Engineering у LinkedIn. У Twitter він став віцепрезидентом. До речі, він сам з України, але ми спілкувалися лише англійською. Я почав будувати інфраструктуру для recommendations, наприклад, user recommendations (who to follow) чи сповіщень, які ми можемо робити. У моїй новій команді не було нікого з колишніх колег по LinkedIn — вони пішли далі працювати в команду Search.
У Twitter я працював на Scala, NoSQL, Summingbird, Scalding, Finagle. У команді нас було до 16 осіб, і тільки я та ще один спеціаліст не мали PhD. Усі займалися алгоритмами із рекомендацій: рекомендувати користувачів, твіти тощо. Те, що я приніс у команду, — швидкість розробки. Я міг надзвичайно швидко створити інфраструктуру, щоб ми провели якийсь експеримент.
Мені було кайфово від того, що можна придумати ідею і за тиждень-два запустити її та побачити, як на цю зміну реагують сотні мільйонів людей. Це те, що мені подобалося в Twitter. А ще імпонувала інженерна культура і рівень моїх колег. На той час туди прийшло багато людей з Google та інших компаній — був надзвичайно високий рівень Machine Learning, загалом tech stack (Monitoring systems, A/B testing, RPC frameworks), застосування алгоритмів, наприклад, random walks on graph, detecting user communities тощо. Я тоді дуже багато розвивався, вчився.
За три з половиною роки були різні проєкти. Крім першої системи, я працював над такою, що рекомендувала твіти у real-time. Наприклад, якщо користувач когось фоловить, нехай 200 людей, і троє з них лайкнули один і той самий твіт чи статтю, ми надсилали йому сповіщення. Завдання визначити це в реальному часі, коли у нас є мільярд користувачів, є дуже нетривіальним. Проєкт мав назву MagicRecs. Ми його почали, і він досі існує. Ним займаються
Як це визначається? Ми проводимо A/B-експерименти. Беремо 1% користувачів і показуємо їм старий функціонал (control group), а іншому 1% показуємо нову версію (treatment bucket). І порівнюючи статистичні показники (скільки твітів написали, лайкнули, скільки часу вони провели на платформі тощо) між двома групами, отримуємо кількісні показники користі нового функціоналу.
Також Twitter купив стартап, який створив дуже красивий мобільний застосунок на Android для показу тематичних новин. І ми хотіли запустити щось схоже: знайти важливий контент, твіти, статті, які в нас є, згрупувати їх, з’ясувати, які з них можуть бути цікаві для конкретного користувача (relevance), і показати як Daily Digest. Компанія хотіла, щоб цим займалася команда зі стартапу. Вони всі працювали на Android, а я був одним розробником на Back-end, допомагав їм з інфраструктурою.
Потім нас стало двоє на Back-end, і ми за пів року запустили цей проєкт. Він прожив три роки, був успішним, але потім, як це часто трапляється у великих компаніях, з’явився новий продукт, який робив те саме (Twitter Moments). Коли я повернувся назад у Twitter два роки тому, мій проєкт якраз повністю закрили. Було іще декілька проєктів, коли ми робили інтеграцію з іншими компаніями. Але я, здається, не маю права про це розказувати.
Загалом у середньому люди змінюють проєкт кожні
Святкуємо день народження колеги в Twitter. Image Source
Досвід роботи в стартапі
Мені подобалося у Twitter, але у якийсь момент у компанії почалася криза: акції стали падати, багато людей пішло... До того ж я вже працював досить довго на одному місці (три з половиною роки) і менше вчився. Тому подумав, що варто спробувати перейти до стартапу типу Unicorn, який може швидко вийти на ринок. Я хотів мати змогу показати свої знання, зробити impact, щоб компанія була успішною.
Так я прийшов у Zenefits. Вони робили для компаній HR-системи, в яких можна було платити зарплати, надавати медичну страховку тощо. Це такий єдиноріг, який за два роки з часу заснування пройшов через інкубатор — їхній valuation зріс до 4,5 мільярда. Там був великий штат розробників. Я багато чого навчився в Zenefits, багато спілкувався із засновниками, дізнався, як вони так швидко зросли... Я працював на Python, Django, MySQL, Ember.js. Але рівень технічної складності, мови програмування — усе це не було мені дуже цікавим.
Так, я розвивався надзвичайно швидко, мені це імпонувало, але задачі, які я виконував, не відповідали моєму досвіду. Я насправді не знаю, чому мене поставили працювати з тим, про що я не мав жодного уявлення: CSS, HTML тощо. Але основна проблема була в тому, що компанія в якийсь момент перестала зростати. Взагалі, для стартапів існують сотні причин, чому вони можуть не стати успішними. Zenefits стикнулися із трьома.
Перша проблема — спочатку вони орієнтувалися на маленькі компактні компанії (до 20 людей) і послуги для них. І вийшло так, що швидко ринок вичерпався, а для більших компаній він уже був зайнятий.
Друга проблема полягала в тому, що Zenefits будували все надзвичайно швидко без урахування якості. Взагалі не звертали уваги на технічний борг, а старалися запустити все за кілька днів. Вони самі казали, що будують ракету в той момент, коли вона летить. Тобто робили Fake it till you make it — вдавай, поки не вдасться.
І все почало валитися. Код був настільки нечитабельний і непідтримуваний, що більшу частину часу ми витрачали на те, щоб це підтримувати, виправляти якісь маленькі проблеми з користувачами, які вони репортили.
При цьому UI був такий, ніби все працює автоматично. Але багато спеціалістів робили вручну те, що ще не було автоматизовано. Немало розробників працювали ночами. Іноді компанія вибирала найпродуктивніших фахівців (я не скажу, що це була найкраща якість, але було найшвидше) і давала завдання створити новий продукт за кілька тижнів. Наприклад, одного разу винайняли великий готельний номер, посадили туди розробників на два тижні, які мали підготувати основу для нової Payroll-системи в Сполучених Штатах.
Щоб ви розуміли обсяг проблеми, зазвичай компаніям потрібно кілька років, щоб створити таку систему, яка б змогла правильно нараховувати зарплату в 90% випадків. Оподаткування в США надзвичайно складне і відрізняється в кожному з 50 штатів. Розробники щось написали, компанія оголосила, що має новий продукт. Але всі, хто був ознайомлений з цією «системою», мали великі підстави для хвилювання. Коли з’явилися перші клієнти, розробники працювали ночами, щоб вручну проганяти розрахунки та записувати їх у базу даних.
Третя проблема — через те, що Zenefits хотіли дуже швидко все робити, вони неправильно проходили певні процедури у США. Вони надавали медичне страхування для компаній, а для цього всі агенти мали пройти певну сертифікацію. І Zenefits обійшли це. Вони зробили певні тули, щоб цю сертифікацію можна було пройти не за кілька днів, а за пів години чи годину. І цим уже зацікавилося ФБР, бо це порушення законів у багатьох штатах. Відразу мав звільнитися засновник компанії, прийшов інший CEO, потім і він звільнився...
Отже, я працював у Zenefits чотири місяці, поки в компанії не почалися великі проблеми. Мені не подобалася атмосфера і те, чим я займався. І коли я пройшов співбесіду в Google, то вирішив, що пора йти.
У Google я прийшов як Team Lead. Тут я працював на Java, Spanner, F1, Boq, Mendel, але майже всі технології використовувалися тільки всередині компанії. Я потрапив у команду Shopping Express. Це щось схоже на Amazon, по суті система доставки. Тобто на цьому сайті можна купувати різні продукти, наприклад, з таких великих мереж роздрібної торгівлі, як Costco чи Sears, а потім Google Shopping Express доставляв їх по основних містах Сполучених Штатів. Це був такий собі стартап усередині Google.
Я прийшов у команду аналітиків. У нас було багато offline data pipelines, баз даних, тулів, щоб компанія могла звітувати: скільки грошей заробили, скільки продали товарів тощо. Це було потрібно для ритейлерів, Google Executives та й власне самого Google Shopping Express, щоб оптимізовувати бізнес.
Але мені було нецікаво у технічному плані, тому після року роботи я поміняв команду. На новому місці ми розробляли інфраструктуру, щоб зберігати YouTube-коментарі, повідомлення Google Hangouts, пости Google+ та багато іншого. Як Team Lead я багато дізнався про cross team collaboration, планування, взаємодію з бізнес-аналітиками, Product-менеджерами, про те, як вести перемовини, визначати, що ми хочемо від інших команд чи що команди хочуть від нас... Плюс я пройшов чимало тренінгів. Узагалі Google корисний тим, що тут, якщо є бажання, можна отримати сильний розвиток. Я цим користувався.
Google дбають про психологічну безпеку людей. Вони провели не одне дослідження про те, які команди успішні, які ні, що потрібно для того, аби люди та команди функціонували добре, щоб їм було комфортно і вони швидко працювали. Тому компанія промоутила mindfulness (практику усвідомленості), і я якраз пішов на тренінг, де вчили медитації та сповільнення... Це було дуже цінно.
Але все це були речі, не пов’язані з технічною роботою. А у технічному плані я не розвивався. У компанії багато розробників, сильних, розумних, але робиться все дуже доскіпливо, процеси повільні. Ще є велика внутрішня конкуренція: щоб потрапити на певний проєкт, треба подавати заявку. Часто на одне місце їх дуже багато або взагалі позиції не виставляють, а просто запрошують по знайомству людей з інших команд.
Через усе це мій внесок був невеликим (багато людей — мало роботи). Я переживав, що насправді не приношу користі. Тобто є я чи мене немає — різниці не буде. Я працював, щось робив, писав якісь дизайн-документи, невеликі фічі, але я не відчував, що всі знання, які в мене є, і весь досвід потрібні.
Я не працюю у команді чи компанії лише за гроші, я хочу отримувати новий досвід, задоволення від спілкування з іншими людьми, від навчання. Насправді є багато видів мотивації, але один з них — це те, що я можу приносити користь і міняти щось для компанії, робити іmpact. Ця частина дуже важлива для мене. У Google і на першому, на другому проєкті я цього не відчував, і це мене сильно демотивувало, я не був щасливим. Життя достатньо коротке, тому я зважився на зміни.
Знову в Twitter
Мені написав хороший друг із Twitter, мій менеджер, людина, якою я захоплююсь. Ми зустрілися, і він запропонував, щоб я повернувся в Twitter. Без співбесіди чи чогось такого. Мій менеджер на той момент вже став Senior-директором і відповідав за дуже велику частину роботи. Він мене переконав повернутися. Це було два роки тому.
Я потрапив у проєкт, пов’язаний з минулою діяльністю, але інший — Twitter Trends, який відповідає за речі, про які користувачі найбільше говорять, різноманітні хештеги, важливі події... Ми показуємо їх окремо на Homepage та Twitter Explore. Колись це була велика система, якою займалися 15 спеціалістів. Але коли я прийшов туди, там була лише одна людина, яка підтримувала Twitter Trends. Тож проєкт не приносив багато користі. Мене попросили: «Попрацюй тут, бо нам потрібно оживити систему, знову зробити її успішною». Закривати не хотіли та навіть не могли, бо це фундаментальна частина компанії.
Мені дуже сподобалося це завдання, бо це було складно і давало великий impact. Ми надзвичайно багато змінили, зробили систему успішною, завдяки їй приходить багато мільйонів користувачів. Twitter почав знову вкладати багато зусиль в неї. Мені дуже приємно, що недавно навіть Трамп написав про Twitter Trends.
I через кілька місяців ще:
Отже, спочатку я працював над трендами, був Team Lead. Потім перейшов на інший проєкт — Twitter Explore. В команді було 20 фахівців, до ковіду я був там Tech Lead. А ось зараз я став просто розробником знову на Trends. Чому так? Коли велика команда, менеджери трохи дистанціюються, через що суттєву частину роботи, яку має виконувати менеджер, починає робити Tech Lead.
На мені було і написання коду, і співпраця з іншими командами, стеження за безліччю речей. А я не люблю розпорошуватися, люблю йти глибоко. Я відчував, що не є успішним у цьому та вигораю. До того ж з ковідом комунікація стала ще важчою. Тож я перейшов у тренди і став Individual Contributor, щоб працювати з тим, що мені справді подобається і що мене драйвить.
Я займаюся алгоритмами, Event detection. Тобто знаходжу, що цікавого відбувається в Twitter, що можна показати користувачам. Наприклад, якщо є новина про Андрія Медведєва й люди цікавляться тенісом, це можна запропонувати. Ми показуємо найкращі твіти чи статті користувачам, надсилаємо сповіщення про це і все таке.
Зараз компанія оголосила, що можна не повертатись на роботу в офіс, тобто дозволено працювати з дому на постійній основі. Мені, з одного боку, це подобається, бо в мене діти, я можу більше часу проводити з ними. І я зберігаю півтори години, які витрачав раніше на дорогу до офісу. Але з іншого — мені бракує живого спілкування з колегами, коли можна поговорити, щось побрейнстормити, дізнатися щось нове, просто пообідати з командою та обговорити цікаві речі, не пов’язані з роботою. Наразі в мене є набагато більше часу, і я справді став набагато продуктивнішим на карантині, але є речі, за якими я сумую. Тому надалі я б краще два дні працював з офісу, а три — з дому.
Чим відрізняються Twitter, Google, LinkedIn? Які є в компаніях робочі нюанси, де цінують командну співпрацю, де привабливіші умови та простіше отримати підвищення? Про все це і багато іншого Володимир розповість у другій частині статті, а також дасть корисні поради про підготовку до співбесід і торги на стадії оферу.
