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

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

Розвиток IT-індустрії не лише спонукає вкладати якомога більше у навчання спеціалістів. Бум галузі призводить і до появи хитрих схем заробітку, коли деякі компанії «продають» Junior-фахівців за ціною Middle, а то й Senior-розробників. Принаймні пробують це робити.

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

Ось що ми дізналися...

💰 Як зібрати команду «сеньойрів»

«Пройшов буткемп — і згодом я потрапив у компанію на позицію Trainee Back-end Developer. Після онбордингу запитав РМ’ку, чи можна відверто сказати на дзвінку клієнтові, що я початківець, аби він терпеливо до мене ставився. На це мені відповіли: „Не варто, клієнту тебе презентують як досвідченішого“. У компанію я йшов як Back-end Developer, а фактично робив і front, i back. На ці обставини зовсім не скаржуся. Це була школа виживання, яку я пройшов — і тепер маю багато досвіду» (Junior Strong Full Stack Developer).

«У свою першу компанію я прийшов на позицію Magento-розробника з досвідом роботи 4–5 місяців. Команда із сеньйора (досвід до року), мідла (досвід 6–7 місяців) і джуна (мене) мала зробити доволі кастомний магазин на Magento. Зараз дивуюся, що ми якось здали його клієнтові (хоча в процесі примудрялися додавати багато фіч, як-от подвоєння кількості товарів у кошику після перезавантаження будь-якої сторінки).

Строк у місяць був завалений втричі, гроші замовник виплатив лише частково, магазин через деякий час, як ми помітили, переписали наново. Взагалі тоді, у 2013-му, все це не здавалося ані нам, ані власнику нашої студії чимось дивним. Замовник пообіцяв 5000 євро, значить, можемо братися до справи :) Нам це було в кайф, бо все ж ми розуміли, що хоч і відповідальні за долю проєкту, але на рівні знань та ЗП — зелені джуни. Я б це назвав позитивним стресом з погляду впливу на себе. Зрештою, це був той період, коли кожен робочий день додає відчутний відсоток технічного досвіду. А ще, вже зараз, назвав би це великим соромом перед замовником» (Magento Developer).

«Коли я був Strong Junior, то перші 4–5 місяців мені давали адекватні завдання. А через пів року перевели на проєкт, де я був єдиним розробником і від мене вимагали рівня Senior. Працював у такому режимі майже рік. Компанія казала, що це не проєкт такий складний, а я такий слабкий. Тепер це викликає посмішку, а тоді було важко. Овертаймив регулярно, й атмосфера через керівництво була негативна. Радий, що потім змінив компанію» (Strong Middle).

«Мене, Junior Front-end Developer’а з піврічним досвідом роботи, компанія „продала“ іншій компанії як Senior. Натомість ця інша компанія представила мене замовнику зі США як „Super Senior з 5+ роками досвіду“. Звісно, замовник за декілька днів зрозумів, що його обманули. Мене звільнили, ще й звинуватили в тому, що я погано працюю, та намагалися „кинути“ на останню зарплату» (Senior Front-end Developer).

«Компанія поставила на проєкт, де, як виявилося згодом, мене презентували замовнику як Senior-розробника зі значним досвідом у доменній галузі. Тут я працював лише кілька тижнів як Strong Junior Developer. До цього був Trainee у невеличкій фірмі. Світчер. Не знаючи подібних підводних каменів аутстаф-індустрії та боячись втратити джерело доходу, я не звільнився одразу, хоча тепер розумію, що в таких випадках це єдине правильне рішення: на кону насамперед власна репутація.


Звідси здобув для себе урок № 1 — детально розпитувати про умови проєкту на етапі співбесіди й обговорювати речі, які для вас не є прийнятними. Під час роботи мене переслідує постійне відчуття провини, оскільки я є частиною обману. Хоча, з одного боку, я вляпався у відверте лайно, з іншого — отримую досвід роботи в крутій команді з дійсно цікавим продуктом, про що раніше і мріяв. Зараз хочу завершити основну частину праці, звільнитися і знайти роботу, де обов’язки відповідатимуть навичкам» (Strong Junior Developer).

«На той момент я пропрацював у компанії орієнтовно три місяці як Junior Manual QA, сумарний досвід — близько пів року. Повідомили, що є складний проєкт, куди вже якийсь час не можуть знайти Middle+ фахівця, і це міг би бути шанс проявити себе. Наскільки розумію, це був непоганий спосіб зекономити на спеціалісті та рекрутингу. Натомість я чув дуже багато історій про те, як важко пробитися в IT, і сам до цього шукав роботу майже пів року. Я був упевнений, що не існує таких речей, у яких не можна розібратися, маючи час. Тож, не довго думаючи, погодився на авантюру.

Все вийшло супер, я досить швидко наздогнав потрібний рівень експертизи, хоч це і коштувало мені декількох тяжких вечорів і суперечок з монітором. Надалі це позитивно позначилося як на рівні оплати, так і на моєму самосприйнятті та амбіціях» (Middle Python Developer).

😵 Схема з видавання джунів за сеньйорів не завжди вдається

«Коли був джуном, мене намагалися „продати“ на позицію сеньйора з 5-річним досвідом. Так і просили казати на технічній співбесіді з замовником (хоча фактично досвіду не мав узагалі). Соромно було брехати. Однак колеги сказали, що у замовника просто завищені очікування до цієї позиції, а я цілком можу впоратися. Ту співбесіду я не пройшов 😊 Взагалі там була цікава схема. На проєкті вже працював досвідчений розробник, але компанія хотіла його висмикнути й поставити на інший проєкт лідом. Мене не взяли, та іншого джуна таки поставили — схема спрацювала» (Senior Salesforce Developer).

«Вже майже рік працюю в українській аутстаф-компанії на позиції React-розробника. Це моя перша робота в ІТ, тому я ще вважаю себе джуном, а от моя компанія намагається „продати“ мене як мідла з 4-річним досвідом, додавши в резюме потрібні їм цифри й технології, з якими мені ще не доводилося працювати. Я пройшов не один десяток співбесід з потенційними замовниками. Більшість з них — успішно, але з не відомих мені причин на проєктжодного разу ще не потрапив.

Мого колегу-джуна навіть подали на сеньйора з 6-річним досвідом. Він пройшов кілька співбесід, проте його теж не взяли.

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

Які я висновки можу зробити для себе? Ніколи більше не працювати в ноунейм-компаніях, а тим паче в аутстафі» (Junior React Developer).

🤘Бізнес-аналітики не лишаються осторонь

«Працював у компанії два місяці, а на роботу мене взяли після проходження доволі посередніх курсів з бізнес-аналізу, без особливої практики.

Коли ще був стажером BA, навіть не джуном, мене поставили вести BA-частину розробки мобільного застосунку (проєкт стосувався громадського транспорту одного з міст України). Досвідченого BA, який мав би змогу допомогти, на жаль, не було. Через місяць страждань попросився на інший, легший проєкт, бо розумів, що „обсираюсь“ і можу завалити свою частину роботи. Після цього отримав легший проєкт з наставником, на якому виріс майже до Middle» (Middle BA).

«Працювала в компанії пів року, з них три місяці — інтернатура. Я ще навіть була Trainee, коли мене поставили на найбільшу діскавері в історії компанії. Пояснили, що BA, якого мали взяти на цей проєкт, відхилив офер, тому ставлять мене, але, звісно, будуть допомагати, бо розуміють, що це не мій рівень. Спойлери: не допомогли, потім ще сказали, що продуктивність у мене погана» (Business Analyst).

🚑 Через невідповідну роботу з’являються проблеми зі здоров’ям

«У мене так вийшло на першій роботі, де комерційного досвіду було нуль. Коли я прийшов, мені видали старий проєкт, написаний на PHP, і сказали, що бізнес-аналітики мають новий план, отже, все потрібно переробити, зберігаючи ідею, але виконати нормальну реалізацію на Python. Потрібно було робити все це, використовуючи Elasticsearch, з яким я стикнувся вперше. У компанії були свої програмісти на PHP і Java, ще декілька працювали на JS. З Docker мені допомогли. Коли було бодай щось готово, допомогли написати GitLab CI/CD. У мене було шалене зростання в навичках у перший рік. Однак зараз просто не розумію, як це все взагалі вийшло.

Початок був суперскладним: я не раз хотів піти, грозились мене звільнити, часто працював у вихідні й затримувався до 21-ї. І це все було за зарплату, нижче медіани для джуна Python. Тому досвіду набрався нормально і по всіх фронтах, але повторювати таке не хочу. Я почав „жестить“ як з собою, так і з іншими людьми — рідні змусили походити до психолога.

Місяць тому вирішив рухатися далі. Зараз проходжу співбесіди на нові цікаві вакансії» (Python Developer).

«Я пропрацював близько шести місяців, коли поставили на новий проєкт. Не знав, чи подужаю його, бо мені бракувало досвіду в розробці на React (була лише загальна теоретична база) і знання JS, HTML, CSS. Та починати з чогось було потрібно.

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

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

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

Кепський, але досвід. Все одно я вдячний своїй першій компанії за здобуті знання, знайомство з хорошими людьми та вкладання у мене ресурсів для мого зростання. Принаймні тепер я не ставитиму своїй роботі такий високий пріоритет у житті. Баланс — це важливо» (Junior React Developer).

🤑 «Продають» не лише Junior, а й Trainee

«Перша компанія, в якій я був Trainee QA, працювала таким чином: вони знаходили проєкт на Upwork для працівника рівня Middle чи Senior, але сам проєкт перекидали на Trainee. Так було і в моєму випадку. Знав, що проєкт не відповідає моєму рівню, та було все одно, бо я ж попав в айтішку — значить, треба триматися» (Junior QA).

«Коли я почала працювати на позиції Trainee, мій колега вирішив піти у відпустку на два тижні. Отож усі проєкти залишилися на мені одній — людині, яка щойно закінчила курси. Я отримала купу роботи, до якої немає письмової документації, та PM’ів, які постійно запитували, коли буде готово і чому я пишу багрепорт, якщо треба було тестувати взагалі не те. Дуже складно було розібратися в нюансах та критеріях роботи тієї чи іншої фічі, бо все відрізнялося від проєкту до проєкту (а їх було близько п’яти). Спроби розпитати девелоперів закінчувалися словами: „Читай документацію“ або „А що тут незрозуміло? Ти ж QA — розбирайся“. Було важко, іноді з’являлися симптоми паніки й думки штибу „це не для мене“ або „я занадто тупа для цієї роботи“.

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

«Я прийшов у компанію на позицію Trainee Front-end Developer і через два тижні долучився до команди, яка переписувала повністю проєкт v1 на v2 з нереальною кількістю нових технологій. Це були дуже важкі, але цікаві часи. Завдання були десь на рівні Strong Junior/Middle. Компанія нічого не пояснювала — просто так проходив мій онбординг» (Middle Software Engineer).

«Мене, Trainee Front-end розробника, „продали“ як Strong Middle на проєкт, де „на вчора“ треба було фіксити баги та додавати новий функціонал. У мене взагалі ще не було продакшн-досвіду, в компанію прийшла після курсів. Потрібно було писати застосунок на AngularJS (1.4, якщо розумієте) і за допомогою Cobertura та Xcode переводити на iPad. Зі мною працювали ще двоє джунів, і ми разом під моїм логіном щось кодили :) Із замовником ми спілкувалися щодня. Це було жахливо, я постійно працювала понаднормово (без оплати, звісно) і хотіла звільнитися. Проте, на щастя, проєкт цей був тимчасовий і тривав лише місяць» (Senior Front-end Developer).

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

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

Схожі статті




25 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Вот же классика из ранних лет ИТшечки
www.bruceblinn.com/parable.html

Если для выполнения сениорских задач достаточно джуна, значит задачи не сениорские.

Если для выполнения сениорских задач достаточно джуна, значит задачи не сениорские.

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

Т.е. впринципе, если у вас зарпата 5к, то вас с легкостью можно заменить 5-ю джунами по 900 дол, сэономив 0.5к, сохранив качество и выиграв в скорости?

Т.е. впринципе, если у вас зарпата 5к, то вас с легкостью можно заменить 5-ю джунами по 900 дол, сэономив 0.5к, сохранив качество и выиграв в скорости?
Сеньйор/мідл/джун — це про якість (сюди ж швидкість) виконання задачі.

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

Мені колись PM дав завдання по проекту на Symfony (який я до того взагалі не бачила і не знала). І каже «Я сказав замовнику що ти знаєш Symfony, і сказав що ми за 2 тижні зробим, ну я в тебе вірю — ти розберешся» :D це були незабутні два тижні

ой... як знайомо... також сімфа та ще й команда фронтів тоді вперше працювала з ember.js.
це був чудовий досвід)

а ще я пригадав такі ж завдання з joomla та prestashop. не такі глобальні, але дуже драйвові.
"Дімон, я в тебе вірю"©

В мене також була подібна історія, я гадаю вона досить трешова для цієї статті. Колись мене, стронг джуна з 1 роком досвіду десь на той момент, намагались продати замовнику як архітектора з 10(!!!) роками досвіда. На той момент мені було 22 роки. Найбільш цікаво, як саме компанія намагалась це зробити:
1. Мене попросили не голитися хоча б тиждень;
2. Я поставив спеціальний софт, який знижує якість веб-камери на рівні ОС, щоб мене було погано видно;
3. Мені сказали вдіти коричневі окуляри для роботи за компʼютером :)))
Обличчя технічних спеціалістів з боку замовника в момент, коли вони мене вперше побачили незабутні.
Звісно, я не пройшов далі. Але теперь маю цікаву історію.

це дуже смішно)) натомість вони певно подумали що це якийсь неголений бомж ноулайфер прийшов на інтерв’ю)

ноулайфер

Т.е. минимум в одном пункте с реальным архитектом таки угадали?

Можливо. Але я гадаю, що вони все ж таки зрозуміли, що їх намагаються надурити )

Цікаво, це у веб-девелоперів такий трешак якось особливо поширений, чи їх просто дуже багато?

Це типовий аутстаф де зі сторони замовника починаючий. Коли люди не знають толком, що треба буде зробити починають вимагати собі команди з трьома тімлідами, двома солюшн архітекторами і усіма сініорами. Потім починають таскати їх із собою годинами по мітингах куди затаскують із собою усіх кого можливо і маринувати meeting driven development-том. Є така книга Демарко Deadline там є глава чому так стається і що з цим робити. Ну, а зі сторони аутстафу усе просто — головне настафити позакривавши позиції, треба вам сініорів — намалюймо вам сініорів з 23 річних хлопців та дівчат, коли розберетесь що до чого вам прилетить погодинний рейт вже. Але якось пам’ятаю був прокол, коли заставили джуніорів видалити із підписів в емейлі тайтли які мають бути за корпоративним стандартом, бо клієнт вже почав розуміти, що до чого. Колись в 15 му було, як мало не усі з юніта нахитали п’ятами за кордон. В мене уся команда із джунів поголовно. Замовник покликала до себе в Лондон, дочекалась поки менеджер десь собі відійде по справах, підійшла і спитала на пряму — скільки в тебе в команді джунів? Довелось завуальовано сказати що усі, нас підсилили тоді двома сініорами і той проект вдалося виконати в строки. Нажаль замовник зарамдаунив команду по закінчені проекту іньшої роботи не надав. І кого виставили на мороз/бенчь аутсурсери — правильно сініорів і виставили.

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

Так от чому в попередній компанії і я (Lead), і молодь (Junior) писалися як «Software Engineer» :-)

Щось згадалося з минулого тут на ДОУ. Коли мене після тріумфальних співбесід після онсайт-тренінгу (звісно, через мої власні баги здебільшого) поперли з мого першого проєкту в айтішечці, але лишили на бенчі вінницького Арісенту, сіньйором. Але то був 2009 рік і риночок був трохи не в тій формі.
Отже, я мав солідну як на ті часи англійську (Intermediate), солідний, як на 22-річного сіньйора, досвід в десктопі і з залізом у Делфі (3.5 роки), непогану базу і нуль комерційного досвіду в C# та практично взагалі нуль досвіду в веб-програмуванні.
При цьому мене таскали по співбесідах, де я мав говорити про 2 роки досвіду в ASP.NET.
Згадалося, бо років вісім тому якийсь анонім, який мене за цим бачив, якось тут сипанув сарказмом, типу, бачив як ти тут по співбесідах ходив, а зараз вимахуєшся тут...

Непросто продатися туди, куди ти не тулишся, особливо якщо ринок такий, що в замовника є час і натхнення перебирати.

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

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

Різна заточеність. Я з таким торік (ще в аутсорсі нашому) зіткнувся сам як інтерв’ювер, у якості проєктного фідбеку.
ПМ була присутня на моїй співбесіді з чуваком, який з солюшн-архітекта хотів назад в інженери. З висоти свого досвіду я розумів, що свіжої «моторики» роботи руками він не має, тому не грузив його різними «булшит тестами», а радше питався його думку про різні аспекти на кожному кроці нашої матриці. На мою думку, там був цілком незалежний інженер, спроможний швидко зорієнтуватися в задачі і підтягнути, що йому треба.
А от ПМ, яка це бачила, вирішила, що я занадто м’який і занадто хороші оцінки, потрібна повторна перевірка. Деталей я не знаю, але він після тих їхніх рухів відмовився від офера. Мені донесли фідбек, я врахував типу «довіряй, але перевіряй», але досі вважаю, що вона таки втратила, а не усунула ризик.

Можливо, найпростіше пояснити це дихотомією engineer vs developer. Одного беруть на ширше і поверховіше описану задачу, яку він поступово розв’язує, тоді як інший це відносно вужчий фахівець (Java Back End, до прикладу), який «висаджується» на окреслену проблемну ділянку і робить все швидше і краще, але в обмеженій екосистемі і чіткіших вимогах.

P.S. А ще бувають сіньйори по вислузі, і «там». То окрема історія, а я про нормальних людей тут.

було б добре зазначити назви компаній.

Щоб отримати колекцію судових позовів від «У нас найкращі фахівці, бо ми використовуємо методики FAANG, ви все обманюєте, видаліть!»?

Часто буває і зворотнє: спілкуєшся з клієнтом і коли він затверджує вакансію то хоче сініора навіть на відверто Джун позиції з задачами накшталт: ’нажимання ось цієї кнопочки’

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

Ну, тут как в шахматах.
Чтоб перейти на уровень выше — надо играть с более опытным соперником (проектом).
Другое дело — когда от начинающих разработчиков требуют не закодировать какой-то описанный бизнес-процесс, а самостоятельно выполнить формализацию для последующей разработки — вот тут-то и может все вылезти боком.

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