Досвід роботи в Uplab
Я працюю протягом
⸻
Командна атмосфера та внутрішні процеси
Командна атмосфера в Uplab професійна й водночас комфортна. Регулярні командні зустрічі допомагають усім залишатися в контексті та рухатися в одному напрямку (All Hands, Project Demos, ретроспективи, Tech Talks).
Проведення Tech Talks дозволяє виносити цікаві технічні питання на обговорення та є потужним інструментом для обміну досвідом і також для професійного розвитку.
Також у компанії проводяться регулярні performance reviews, які допомагають зрозуміти, над чим саме варто працювати для подальшого професійного зростання та перегляду компенсації.
Відкрите та конструктивне спілкування з колегами допомагає своєчасно працювати над зонами росту та краще усвідомлювати власні сильні сторони.
⸻
Співпраця з клієнтами
Однією з найбільших цінностей для мене в Uplab є підхід до співпраці з клієнтами. Компанія орієнтована на довгострокові партнерства, де важливими є прозора комунікація, взаємна довіра та спільна відповідальність за результат.
Клієнти, з якими я працював, відкриті до обговорення ідей, альтернативних технічних рішень та пропозицій від команди. Розробники залучені не лише до виконання задач, а й до формування бачення продукту та планування його подальшого розвитку. Також варто відзначити активну роботу компанії з сучасними технологіями, зокрема AI-інтеграціями.
⸻
Інженерна культура та якість розробки
В Uplab є чіткі вимоги до якості коду та технічних рішень. Підтримуються сучасні підходи та best practices, а тестування є невід’ємною частиною процесу — від unit до integration та end-to-end.
Code review тут сприймається як інструмент розвитку та обміну досвідом, а не як формальна перевірка.
⸻
Комунікація та робочий баланс
Завжди є можливість напряму прокомунікувати з керівництвом за потреби, а також простір для обговорення нових ідей та ініціатив.
У компанії гнучкий графік роботи, є можливість взяти time-off, day-off або відпустку за потреби (звісно, без зловживань), що позитивно впливає на баланс між роботою та особистим життям.
Мій досвід роботи з компанією Uplab розпочався з bootcamp, після якого я успішно презентував фінальний проєкт і отримав офер.
Вже 6 років працюю в компанії, і за цей час можу поділитися тим, що в для мене дійсно є цінним
Співпраця з клієнтами:
— співпраця з клієнтами зазвичай будується на багаторічних відносинах, прозорій комунікації та взаємній довірі
— клієнти, з якими я працював, відкриті до обговорення нових ідей та альтернативних підходів
— у проєктах команда має можливість впливати на планування подальшого розвитку продукту, а не лише виконувати окремі задачі
— комунікація з клієнтами конструктивна, без тиску
— дедлайни ставляться реалістичні
— на проєктах активно використовуються актуальні технології; наразі значна частина задач пов’язана з AI-інтеграціями
Практики розробки:
— є вимоги до якості коду, технічних рішень, використовують актуальні підходи та best practices у розробці
— використовуються різні рівні тестування: unit, integration та end-to-end
— активно застосовуються code reviews і pair programming
— технічний борг ефективно керується, а не просто відкладається
— підтримується актуальна документація проєкту
— є менторинг і регулярні 1:1 з менеджером, де можна обговорити прогрес, цілі та отримати фідбек
Робота в команді:
— атмосфера, у команді, професійна і водночас дружня
— проводяться регулярні командні міти, для синхронізації та планування
— проводяться регулярні ретроспективи, які допомагають покращувати процеси
— складні проблеми зазвичай вирішуються спільно, з фокусом на результат
— до помилок ставляться спокійно та конструктивно
— мікроменеджмент відсутній — є довіра і фокус на результат
— ідеї та ініціативи справді заохочуються і не залишаються без уваги
Взаємодія з CEO:
— задає напрям, без контролю кожного кроку
— заохочує навчання та зростання
— до помилок ставиться спокійно, підтримуюче, без тиску
— рішення і зміни комунікуються відкрито
— створено простір для обговорення нових ідей
— комунікація з будується на відкритості, довірі та прозорості
Робочі процеси:
— гнучкий графік і можливість брати time-off для вирішення термінових особистих питань — без бюроктарії
— підтримується work-life balance
— регулярно проводяться all-hands, project demos та tech talks
— проводяться performance reviews з фокусом на зворотний зв’язок
— разом з менеджером формується PDP
:axolotl :axolotl :axolotl
Згоду на публікацію коду тестового завдання надаю. Проте мушу зазначити, що ви дуже майстерно викрутили ситуацію на свою користь, залишивши лише нейтральну частину історії повідомлень. Для справедливості скажу, що я продовжив відстоювати свою думку вже не стосовно вашого ТЗ (так, я мав врахувати деталі і без їхнього зазначення в ТЗ), а стосовно того, що, знаючи, яка складна ситуація на ринку праці створилася, ви ще встигаєте використовувати в діловій розмові недоречні жарти, як в другому реченні цитати, цитую: «Мабуть треба було дійсно додати вимогу, що код повинен чистовим та без багів, з однорідною архітектурою, повинен відповідати мінімальним вимогам по security. Можливо, і код потрібно було зразу написати, всі стейти задизайнити, перелічити усі едж кейси та рішення до них». Перепрошую, але висновки робіть самі. Можливо комусь таке ставлення прийдеться до вподоби.
Мені прикро, що вас мій коментар чимось образив та й я не знав про вашу складну ситуацію з пошуком роботи. Метою цитати, яку ви використали було показати, що можна безкінечно деталізувати задачу і вкінці кінців всеодно будуть незадоволені — тому і використав таку форму навівши приклад як можна деталізацію довести до абсурду. Вам ж вона також здалася абсурдною, але чомусь ще й образливою — ні в якому разі не мав на меті вас принижувати чи ображати, лише показати, що потрібна межа в деталізації і її виставляємо ми самостійно при складанні наших тестових задач
Написав відгук щодо ТЗ для тестового. Отримав відповідь типу «Може вам іще код написати в ТЗ?». Це був CEO Ігор Бармак, який хамовито і зверхньо ставиться до кандидатів. Не раджу цю компанію до розгляду в якості місця роботи.
Добрий день.
Мені прикро, що наша дискусія переходить в публічний простір, проте я не можу залишати ваш відгук без контексту ситуації.
Чи надаєте ви згоду на публікацію коду вашого тестового завдання для анонімного опитування серед спеціалістів з інших компаній щодо доповненості змісту тестового завдання та об’єктивності нашого відгуку?
Для контексту хотів би зазначити наступну інформацію:
— Ми даємо відгук усім кандидатам, які надсилають нам тестове завдання для того, щоб вони могли покращити свої скіли та зрозуміти на що звертають увагу роботодавці при прийомі на роботу.
— Ви подавалися на позицію Junior (не Trainee) React Native Developer, на яку ми отримали більше 290 заявок. Завданням тестового завдання було знайти людину, яка може швидко розібратися в новій для неї технології (GraphQL) та якісно реалізувати фунціональність автентифікації.
— В свою чергу на наш відгук ви відповіли, що йшли суто по ТЗ, а в них не було вказано тих зауважень, які я зазначив у своєму рев’ю. В цьому повідомлення ви виставили претензію щодо коректності ТЗ, на що я вам відповів, що ми його складали з урахуванням наших потреб та не вважаємо за потрібне вказувати настільки специфічні деталі (ознайомитися з відгуком можна нижче). Далі я детально прокоментував кожен пункт мого відгуку в максимально нейтральній формі, та все ж ви продовжили відстоювати свою думку на що я відповів, що повинна бути завжди межа в деталізації і для прикладу привів, що можна в ТЗ додавати вже готовий код, але всеодно знайдеться можливість зробити зауваження, що ТЗ недостатньо деталізоване.
— В тім ви погодилися, що ваш код виглядав як чернетка тому що ви розпочали писати тестове завдання на
— Також, я міг і не давати вам відгук, тому що ви надіслали його після дедлайну, але хотів допомогти зрозуміти як покращити ваше рішення та мати приклад для портфоліо, коли будете подаватися у інші компанії
З текстом тестового завдання можна ознайомитися тут:
— gist.github.com/...73b0dde339aae3a93d727b747
Відгук щодо тестового завдання:
Добрий день!Ми перевірили тестове завдання.
З наявних проблем:
— Пароль в відкритому вигляді без маскування
— Трошки костильна реалізація refresh token логіки. Якщо би додаток починав розростатися, то підтримувати таку логіку було би дуже і дуже важко. Приклад хорошої реалізації через Apollo.Link тут: community.apollographql.com/...ia-apollo-in-react/1440/5
— Багато хаків з таймаутами — це дуже поганий патерн
— На формах немає валідації
— Дуже громіздкий код Home screen
— Не однорідна архітектура — деякі мутації та квері винесені в окремий файл, деякі залишилися в основних файлахЗ плюсів:
— Добре описані типи до навігації
— Загалом зі сторони користувача користуватися, немає нічого лишнього, все лаконічно
— User-friendly переклад помилки про неправильні дані входуНа жаль, цього разу ми змушені вам відмовити в заявці на нашу вакансію. Ми обрали іншого кандидата
Дякую, бажаю удачі!
Адміністрація вебсайту dou.ua не гарантує і не підтверджує точність і достовірність будь-яких матеріалів, в тому числі відгуків і коментарів, які розповсюджуються не від імені Адміністрації, а від окремих користувачів. Адміністрація не несе відповідальності за відповідність таких матеріалів вимогам законодавства. Думки користувачів можуть не співпадати з думками Адміністрації.
Адміністрація не здійснює модерацію таких матеріалів, крім як у випадках, прямо передбачених Правилами користування вебсайтом (https://dou.ua/legal/). Адміністрація не уповноважена вирішувати спори, які виникають між користувачами чи з третіми особами, чи бути стороною такого спору. У випадку порушення Ваших прав звертайтесь безпосередньо до автора відповідної інформації чи органу, компетентному вирішувати спори/встановлювати факти подібного роду.
4 відгуки
RSS