Май 01

Як я шукав роботу в NLP за кордоном

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

Спочатку трохи про мене. Працюю у сфері IT близько 14 років: 10 років в Україні, а з 2017-го — у Вроцлаві, Польща. Тому більшість моїх висловлень стосуватиметься польського ринку праці. Щодо досвіду, то це був переважно аутсорс. Аутсорс загартовував мене як універсального розробника. Попри широке коло технічних навичок та умінь, я все ж хотів зосередитися тільки в одному домені — NLP (Natural Language Processing). Цікаві вакансії я знаходив у продуктових компаніях. Ще рік тому я чомусь вважав, що існує невидиме скло, через яке я не можу пройти співбесіди у них.

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

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

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

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

Ілюстрація Аліни Самолюк

Пошуки

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

Попри моє бажання працювати за напрямом NLP, я розумів, що сам процес може бути ускладнений, а саме такими питаннями:

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

Після того як я сформулював це для себе, почав поступово вибудовувати стратегію щодо пошуку та працевлаштування.

Наразі є багато сервісів, за допомогою яких можна з’ясувати, чим живе індустрія, які платформи, застосунки є корисними, які напрями розробки популярні. Передусім мені сподобалось аналізувати NLP через дані із сайтів LinkedIn, NLP Archives, IBM Research NLP Research Blog — The Stanford NLP Group. Найбільшу кількість статей, дописів я побачив на LinkedIn. Прості публікації, інформативні, є велика кількість груп, де можна поставити запитання колегам на різні теми. Після аналізу я був приємно здивований тим, що можна почати працювати, навіть не маючи освіти чи досвіду розробки NLP-застосунків.

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

Резюме. Підготовка

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

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

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

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

Підготовка до співбесіди

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

Перше, над чим я замислився під час пошуку роботи в продуктових компаніях, — твій досвід часто не має значення. Так, він має бути, щоб було про що говорити. Але помітив одну особливість. Коли я почав гортати та передивлятися вакансії, пов’язані з NLP, зауважив, що в багатьох випадках достатньо університетської освіти. Це стосується інтерв’ю, наприклад System Design і Application Architecture, які можна побачити лише у продуктових компаніях.

В аутсорс-компаніях такого типу співбесіди я майже не бачив. На рівні сеньйора майже вся технічна розмова проходила у стилі Application Architecture. У продуктових компаніях ці типи виділені в окремі етапи. Найскладнішим для мене був System Design. Цей етап більш схожий на творчу екзаменаційну роботу, ніж на повноцінну кваліфікаційну співбесіду.

Після упорядкування інформації, знайденої в інтернеті, я поділив весь процес на етапи: розмова з HR про компанію, System Design, Application Design, відгук від компанії, мій відгук про співбесіди, обговорення оферу (якщо такий є). Для полегшення роботи створив файл, у якому для кожного кроку додав тези, про що добре запитати, та матеріали для підготовки. Найскладнішими були SD/AD. Тут я можу порадити прочитати такі книги:

Щодо запитань, які я ставлю будь-якій компанії, то перелік їх типовий. Наприклад, які методології використовують на проєктах, яка основна мова спілкування/документації, чи є річні бонуси до зарплати, чи компанія надає доступ до O’Reilly Books, чи допомагає під час релокації. Моє улюблене запитання — як компанія може прокоментувати несхвальні відгуки на Glassdoor. Саме вміння розмовляти на такі теми, бажання надати об’єктивні відгуки для мене є важливим чинником, чи пристану я на пропозицію роботи.

Співбесіди

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

розмова з HR;
перший технічний відсів (алгоритмічні тести або технічна співбесіда);
AD/SD-розмови (Architecture Design/Software Design);
поведінкова співбесіда;
пропозиція або відмова.

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

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

А ось на AD/SD-інтерв’ю я почувався напружено та інколи припускався простих помилок. Було багато різних співбесід, де просили закодити бекенд або створити дизайн API. Я зауважив, що різні компанії по-різному давали відгуки, навіть було таке, що інтерв’юерам не подобалися назви методів або, наприклад, «ви не сказали, що існують RFC».

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

Під час схожих інтерв’ю мені подобається використовувати модель STAR. Тобто свою відповідь укладати за таким планом:

S — Situation. Описати, з чим я зіткнувся, яке було середовище та в яких умовах працював. Тут часом розповідаю, які мав ресурси та скільки часу дали на виконання завдання.
T — Task. Описати завдання, яке отримав. Звертаю увагу на те, як я отримав його: чи це було моє рішення (знайдена мною хиба у проєкті), чи від керівника проєкту або бізнесу.
A — Action. Кілька речень щодо дій, які допомогли мені розв’язати завдання, які були перепони та в чому знадобилася допомога.
R — Result. Якого результату було досягнуто?

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

Офер: на що звернути увагу

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

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

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

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

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

Як залишити стару роботу та передати справи

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

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

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

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

Підготовка до роботи в новій фірмі

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

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

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

Отже, коли я запитав про це в новій компанії, мені порадили ознайомитися з книгою Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. Це ґрунтовна праця, я почав її читати і був вражений тим, що сфера NLP — це не тільки алгоритми опрацювання текстів, а й дизайн і розробка систем, які зберігають величезні масиви даних. Зі свого досвіду скажу, що така література допомагає серед іншого упорядкувати вже отримані знання.

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