Мій шлях від джуніора до Frontend Architect у 47 років

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Вітаю! Мене звати Валерій Сідельников, мені 47 років, і зараз я працюю Frontend Architect у міжнародній компанії, яка є лідером в аналізі ефективності цифрової реклами. Але ще 6 років тому я був джуніор фронтенд-розробником, який нічого не знав про сучасну ІТ-індустрію і мав бекграунд спеціаліста з 1С, як і багато хто мого віку.

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

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

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

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

Незадовго до цього я пройшов індивідуальний курс з C# для одного проєкта на роботі й заново відчув, що таке вчитися чомусь новому, як у студентські роки. У процесі навчання несподівано прийшло розуміння: як же мені не вистачало сучасного ІТ весь цей час! І це суттєво вплинуло на моє рішення щось змінити в житті.

На щастя, у мене був знайомий, до якого можна було звернутися за порадою. І вона виявилася дуже несподіваною, але, як я зараз розумію, ідеальною. Це був мій розподільний капелюх в ІТ — Грифіндор! Насправді ж порада була — функціональне програмування. Ну, якщо простіше — JavaScript. Адже його можна використати й у веброзробці, і в блокчейні. Чесно кажучи — тоді мені було загалом байдуже, але зараз я безмежно вдячний цьому вибору. І ви скоро зрозумієте, чому.

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

Як швидко вивчити JavaScript? Немає нічого простішого — прочитай Learn JavaScript тричі. Мені ця мова дуже сподобалась, особливо після суворого C#, а його типізована версія взагалі була написана тими ж людьми. Раз вже мова зайшла про JavaScript, варто було ще вивчити React — найперспективнішу технологію того часу у веброзробці. Ви здивуєтесь, але на все це знадобилося всього два місяці інтенсивного навчання.

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

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

Джуніор-розробник

Я потрапив у команду, яка працювала з найновішими та найкрутішими технологіями того часу: GraphQL, BFF, Redux-Saga, React, Ant Design. У мене був чудовий тімлід — ми подружилися і разом ходили на каву. ІТ зсередини виявилося зовсім не таким, як мені здавалося весь цей час зовні — воно перевершило всі мої очікування.

Було й таке, що лякало — я не розумів 50% лексики навіть рідною мовою. Усі ці естімейти, бізнес-скорочення та англіцизми, які переробили на свій лад... Я просто записував їх у блокнот і читав потім у Вікіпедії. А я ж, здавалось би, був з ІТ... Одним словом, найбільшим челенджем для мене стали не технології, а розуміння екосистеми та сленгу.

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

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

Strong мідл

Через пів року роботи я вже почувався впевнено: взяв собі ще одного джуніора як ментор, виконував складні самостійні завдання. У мене нарешті була крута команда — на посиденьках я розважав їх веселими історіями з минулого життя, а у них навчався сучасним реаліям ІТ.

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

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

Тут я взяв ініціативу на себе і почав проводити власні фронтенд-дейлі, намагаючись роздати цікаві завдання сеньйорам і розгрібати баги разом із джунами. Чому мені це було легко? Просто у мене було троє синів, і мені було 43 роки. Якось усі з цим погодилися — бо лідерство мало хто любить, а ось робити цікаве завжди хочеться.

Ах так, ще один нюанс — проєкт був фікс-прайс. Простими словами це означало: «зроби якнайшвидше або помри». Я добре пам’ятаю 20-годинний робочий день, коли разом із нами сидів один із CEO і писав код авторизації на бекенді, а зранку нас чекало демо перед замовником.

Senior

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

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

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

Спочатку я був другим пілотом, слухаючи, як досвідчені фронтенд-хижаки перевіряють кандидатів. І тут знову в хід пішов мій блокнот — я старанно записував питання та відповіді. Це був неймовірний досвід: кожна співбесіда — вибух мозку, справжній іспит, після якого хотілося трохи поплакати як кандидатам, так і мені. У мене були відмінні наставники, і незабаром мені запропонували стати першим пілотом.

І понеслося — я провів близько 30 інтерв’ю за рік. Це тримало в шаленому тонусі, особливо з огляду на те, що потрібно було ще й керувати власним проєктом...

Після чого я благополучно вигорів.

Техлід

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

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

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

Я тоді занурився в кодинг по максимуму, перелопатив сотні тисяч рядків коду, багато чого переробив. Але це тривало недовго — через пів року я очолив проєкт як тімлід.

Відпочили — і вистачить.

Архітектор

16-17 травня, Київ. Квитки тут!👇

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

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

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

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

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

І в результаті я офіційно став архітектором.

Що ж далі

Як і все хороше, мій чудовий проєкт закінчився. У клієнта почалися фінансові труднощі, деякі ініціативи закрили. Ми встигли випустити класний продукт на нових технологіях, і команда поступово розійшлася. Я досі за ними сумую.

Водночас усе це співпало з моїм переїздом до США через війну. Це був абсолютно новий рівень випробувань, адже пошук роботи в США відрізняється від українського ринку. Було страшно. Я навіть взявся за LeetCode.

І тут настав моторошний інсайт: мозок заіржавів, і рішення цих завдань практично обнулило мою самооцінку. Я спочатку не міг впоратися навіть із найпростішими задачами, але поступово втягнувся і за місяць вирішив близько 50 штук. Все здавалося сірим. Давалися взнаки стрес від імміграції. Але допомогло одне просте рішення — я почав оновлювати резюме.

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

Після оновлення профілю в LinkedIn вже за тиждень мені написав HR з великої американської компанії. Як я дізнався пізніше, вони шукали архітектора з моїм стеком уже понад пів року.

Після 7 раундів інтерв’ю (переважно з топменеджментом) я отримав офер. І сьогодні продовжую найкраще з того, чим займався в попередній компанії — але вже з абсолютно іншими перспективами.

До речі, LeetCode мені так і не знадобився... Але деякі алгоритми я тепер використовую в роботі.

Чи є життя після архітектора

Цікаве питання. Колись я не бачив нічого далі сеньйора, потім — далі архітектора.

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

Ми всі інженери, які будують продукти. Але важливо будувати так, щоб розробникам було легко, а користувачам — приємно. Будувати платформи, а не застарілі через рік застосунки. Думати масштабно і давати волю креативу.

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

Тож ніколи не пізно почати.

Деякі думки та ретроспектива

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

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

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

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

Вчіться у лідерів свого напряму. Завжди є «токсичний сеньйор», який знає все, але з ним ніхто не спілкується. А ви спробуйте. Знайдіть підхід, поговоріть, спробуйте зрозуміти. Живе спілкування не замінять статті, а особливо спостереження за тим, як людина вирішує проблеми в реальному житті.

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

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

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

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

Намагайтеся зберігати work-life баланс. Чесно? Це те, що мені давалося найгірше. Нові виклики затягують, дедлайни, мітинги, овертайми — і до життя справа майже не доходить. Тут важлива реальна дисципліна, хороші звички (пропоную почитати Atomic Habits).

Будьте креативними. Креатив є не тільки в мистецтві. В ІТ він на кожному кроці. Ми придумуємо нові рішення, створюємо унікальні продукти та змінюємо світ. Звучить пафосно? Самому трохи ніяково. Але це чиста правда.

👍ПодобаєтьсяСподобалось36
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ви молодці, моя повага.
тим часом я у 37 років і вже 3 річний джун(

дякую за статтю, цікава.

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

дякую

Дякую за цікаві запитання!

1️⃣ Скільки разів змінювали роботу?
Я не з тих, хто часто змінює роботу заради змін. По суті, я переходив між проектами всередині однієї компанії, а пізніше вона стала частиною Intellias, і я був у групі, яка допомагала вирівнювати процеси між компаніями. Уже після переїзду в США отримав запрошення в нову компанію. Тому якщо рахувати «зміни роботи» — то 2,5 рази. А якщо говорити про проєкти — то я завжди шукав такі, які давали можливість прокачати як софт-, так і хард-скіли відповідно до поточних пріоритетів.

2️⃣ Чим моя позиція відрізняється від Senior?
Ключова різниця — точка огляду та зона відповідальності. Я дивлюся на весь фронтенд у масштабах компанії, налаштовую глобальні процеси та ухвалюю архітектурні рішення, які впливають на всі команди. Наприклад:

Як організувати крос-командну взаємодію?
Які технології вибрати, щоб вони були зручними для всіх (концепція Paved Road)?
Як ефективно організувати обмін знаннями та найкращими практиками між лидами та сеньйорами?
Як вибудувати композицію команд, щоб швидкість і якість розробки були оптимальними?
Як трансформувати набір фронтенд-застосунків у повноцінну платформу?
Як забезпечити глобальний контроль якості коду на рівні всіх команд?
Головна відмінність — масштабність задач. Вони виходять за межі одного додатку або навіть групи додатків.

3️⃣ Як Senior може вирости до архітектора?
Кілька ключових напрямків, у яких можна розвиватися:

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

Дякую за відповідь.

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

Дякую за питання! Якщо чесно, я просто дуже уважний слухач. На певному етапі кар’єри ти починаєш слухати не просто розумних людей, а тих, хто реально рухає індустрію — CTO, директорів з інновацій, творців мов і фреймворків. Наприклад, мій перший наставник з програмування (я був в універі тоді) написав свій SQL на Prolog, і це, м’яко кажучи, сформувало моє бачення архітектури. Другий важливий момент — це постійний аналіз існуючих систем, навіть легасі. Це як археологія: копаєш, знаходиш стародавні артефакти, робиш висновки — що працює, а що треба було спалити ще на етапі задуму. Взагалі, як Шекспір і його предшественники придумали всі класичні сюжети, так і патерни архітектури вже були винайдені мислителями минулого століття. Залишається тільки правильно їх використовувати та не винаходити велосипед з квадратними колесами. Ну і, якщо вже говорити про сучасні інструменти розвитку, зараз важливо вміти правильно використовувати AI-асистентів, навіть для особистісного зростання, не побоюся цього слова — спробуйте це неімовірний досвід.

Що там «архітектити» на фронті?
Це швидше техлід чи стафф позиція.

Я вже три роки part of Architecture Panel поряд із бекенд-архітекторами та VP архітектури, і, знаєте що? Фронтенд теж має архітектуру. Просто вона складніша, бо ще й красивою має бути! 😄

Дякую за статтю і вітаю із успіхом. Декілька питань:
1. А можете більше розказати про вашу роль?
2. Чим архітектура фронтенту відрізняється від бекенду, принципи шарування, solid, організації модулів і т.п. не діють на фронті?
3. Що саме у фронтенді на вашу є таким складним?

Дякую вам за коментар! Ваші запитання наштовхнули мене на думку, що варто написати кілька статей на Medium — принаймні, частина тем у мене вже в планах.

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

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

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

Дякую за цікаві запитання! Можливо, я детальніше розкрию ці теми в наступних статтях.

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

Лол, яка філософська тема)

переїздом до США через війну

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

Автор додає до фрази слова «кинув, звалив, переплив, піднирнув». Ігор, ображений на життя, бусифікацію і закриті кордони, задоволено продовжує читати.

Так) я теж запамʼятав ці овертайми з перервою на каву на березі моря😁

Той самий момент, коли ми отримали неймовірний досвід у cowboy-driven development! 😆

Молодець, Валера!

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

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

Ну і куди ж без нашої улюбленої рубрики «Історії від Валери»

Дуже дякую і тобі Валера, і тобі Міша за такий прекрасний час в якому ми усі разом робили класні речі!

Дякую тобі! Це була неймовірна атмосфера і справді фантастична команда. Такі моменти запам’ятовуються назавжди! 😊

Так) я теж запамʼятав ці овертайми з перервою на каву на березі моря

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

P.S. Для деяких коментаторів хто пише як так можна було за півроку вже почати менторити. Відповідь проста — це можливо. Чесно кажучи я навіть зараз здивований що у Валерія на той час було близько півроку досвіду у фронтенді, бо він мав відповіді на всі мої запитання)

Дуже приємно зустріти тебе тут! Ти був неймовірно здібним і швидко розвивався—працюючи з тобою, я сам краще зрозумів деякі концепції фронтенду. 😊

Міша наша бусінка)

архітект за 6 років?
нагадало мем — як стати С++ розробником за 21 день
в випадку автора: достатньo було попрацювати ~20 років розробником в іншому стеку, і тоді це реально :)

Звичайно, 20 років досвіду в іншому стеку — це важливий фактор, але головне було змінити підхід і почати швидко зростати. Я отримав увесь можливий досвід у 1С за 3 роки, а потім надовго застяг на місці.
Перехід від сеньйора до архітектора — це великий крок, так само як від архітектора до VP. Але головне тут — не боятися змін. Страхи тільки стримують розвиток, а справжній прогрес починається, коли виходиш із зони комфорту.

Буває таке . Особисто зустрічав ’з інтерна до архітекта ’ за 5-6р. Але це скоріше виключення з правил -вдале поєднання: знань ,проекту та мабуть ментора. (Ще б додав би відсутність соціальних зобов’язань )

Ну так це на галері. На наших галерах тобі дадуть будь-яку личку, аби тільки гроші не просив. В нормальній технологічній компанії з позиції «фронтенд архітект» можуть тільки посміятись, а щоб дорости до повноцінного архітекта, то це 10+ років досвіду + різні регалії з попередніх місць.

Так в нього досвід 10+ є, хоч і не релевантний.

В нормальній технологічній компанії з позиції «фронтенд архітект» можуть тільки посміятись

З цим не згоден, саме у таких компаніях стафф інженер, принципал, сіньор архітект, принципал qa архітект це реальні посади.

Бо якщо компанія платить високу ЗП, то з цими тайтлами легше пояснити «а чого ми на інженерів тратим 300к якщо на ринку є по 150к».

В мене на продукті зараз стафф інженер це сіньор 5+ років) над ним ще кілька тайтлів є. І це не ліди чи архітекти.
Зате дивишся середню ЗП для стафф інженера під 200-400к, тоді і якомусь ремоут з східної європи не шкода дати 100к.

стафф інженер, принципал, сіньор архітект, принципал qa архітект це реальні посади

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

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

Падажіте, я правильно прочитав? Ви були джуном, половину термінів навіть не розуміли, і вже через шість місяців ви вже мідл і ментор для іншого джуна?

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

Так, 6 місяців — це небагато для глибокої практики, але варто враховувати, що я постійно приймав виклики, мав досвід створення складних систем на 1С і безпосередньо спілкувався з продуктовими власниками. До того ж, через обмежений час у мене була висока мотивація швидко освоїти нові підходи та застосовувати їх на практиці.
Мої перші два проекти — Enterprise React-застосунок із GraphQL та TypeScript, а другий — MVP-платформа на основі мікросервісів NodeJS з AI. Це значно прискорило процес навчання.

Якщо ви уважно читали, то в автора до того було 19 в айті. Всі сміються над 1С, але 19 років це 19 років. Я б сказав так. За 6 місяців сеньор (в 1С) став мідлом і ментором (в JS). Відчуваєте, як по іншому звучить?
P.S. І як на мене 6 років то навіть багато, хоча в 47 ти можешь вчитися швидко. Дуже швидко. Але то прострілили коліно (сім’я, діти, старі батьки, ремонти, іпотеки)

Я працював розробником 1С і будував корпоративні системи 19 років, також створював десктопні застосунки. Але я не використовував сучасні підходи, тож коли почав працювати у веб-розробці, я був готовий до швидких змін і зміг швидко адаптуватися.

Дякую, тепер розумію, питань немає.

так, але є нюанс.. (20 років досвіду )

О так! Кардинальна зміна, але без цього було б нецікаво. Дякую! 😊

Насправді ж порада була — функціональне програмування. Ну, якщо простіше — JavaScript.

жесть.

Якщо чесно, то порада стосувалася смарт-контрактів в IBM Blockchain, і основною мовою для цього був саме JavaScript. Але розумію, чому це могло викликати плутанину.

Круто. Теж заскочив во фронтенд в 40+.

Значить, не я один вирішив змінити курс після 40 😃 Які враження ?

Було трохи ризиковано , міняти напрям. Але вийшло майже без просідання по зп так як часи були трохи інші. Але з проектами не дуже склалося — не вдалося отримати швидко релевантний досвід . Після декілька змін контор Зараз в компанії із топ 10. Але думаю це було робити років 5-7 тому

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