Archives

Все, що ви хотіли знати про роутери та Wi-Fi. Частина І. Обладнання

На вашу думку, без чого сьогодні складно уявити життя та ефективну роботу? Смартфони? Соцмережі? Додатки? Так, але це все не має сенсу без домашнього інтернету та Wi-Fi!

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

Поїхали!

Розділ І. Обладнання

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

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

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

Проте є інший шлях існує! Окрім роутерів, які можна придбати у магазинах, є ще керовані роутери – це роутери, які телеком-оператор надає своїм абонентам. В Україні це рідке явище, проте в інших країнах це популярне рішення.

Чим такі роутери відрізняються від тих, що можна купити у магазині?

  • Роутери від оператора є інтегральною частиною мережі провайдера. Це означає, що провайдер має до них віддалений доступ, відповідає за сервіс, налаштування та заміну. Як правило сам роутер є частиною пакету послуг і надається безкоштовно або за невелику абонентську плату.
  • Автоматичне налаштування. Інженер, який встановлює роутер, вводить певний код або сканує QR код, і всі подальші налаштування, разом з оновленням програмного забезпечення, відбуваються автоматично.
  • Вони мають опцію автоматичного оновлення програмного забезпечення.
  • Розширений функціонал. Оператор має доступ до функцій, які користувач через веб-інтерфейс просто не бачить.
  • Тісна інтеграція між провідним та мобільним інтернетом. Є багато моделей, які мають мобільний резервний канал: 3G, 4G, 5G. Є моделі, які розраховані виключно на мобільне використання. Мобільні оператори намагаються використати це як перевагу для покращення якості та стабільності сервісу.
  • Мають інтегровані рішення з безпеки та батьківського контролю.

    Підтримка інших послуг оператора як то IPTV, відео на вимогу чи елементи розумного будинку.

Виклики

Звісно, що є ряд труднощів та викликів. Втім, будь-які виклики розробники програмного забезпечення намагаються перетворити на нові сервіси.

Основними викликами на сьогодні є:

  • Кількість даних, які передаються, збільшується вдвічі кожного року, а плата за послуги росте набагато повільніше.
  • Більшість користувачів оцінюють якість послуг оператора виключно за якістю Wi-Fi.
  • Часто один оператор використовує десятки моделей пристроїв від різних виробників. Тож, коли в нього виникає потреба внести якусь зміну, йому потрібно замовляти цю зміну кожного з виробників, а пізніше провести тестування кожної моделі. Саме тому оператори намагаються зменшити модельний ряд пристроїв, які вони підтримують та уніфікувати його.
  • У період глобальних обмежень багато користувачів перейшли на віддалений режим роботи з дому. Суттєво зросли очікування щодо якості домашнього інтернету та підтримки бізнес функцій таких як, наприклад VPN.
Тренди

Сьогодні на ринку існують такі тренди:

  • Перехід на уніфіковане програмне забезпечення. Це полегшить впровадження нових моделей та перенесення сервісів з однієї моделі на іншу, а також зменшить витрати на розробку. Тут найдалі просунулися проєкти з відкритим кодом RDK-B та OpenWrt/prpl (про це докладніше ми поговоримо в наступній публікації).
  • Mesh-мережі для Wi-Fi. Це інтелектуальні системи, що складаються з роутера та ретрансляторів, які разом централізовано керують Wi-Fi мережею.
  • Хмарні рішення. Існує багато моделей, які керуються виключно з хмарного інтерфейсу. Клієнт може налаштувати свою мережу, переглянути статистику, рахунки, тарифні плани прямо на сайті оператора.
  • Домашня автоматизація. Тут бракує єдиного стандарту, проте є хороші напрацювання у сфері безпеки, а також інтеграція зі штучним інтелектом. Це дозволяє впроваджувати домашню автоматизацію, використовуючи наявну інфраструктуру.
  • Гігабіт. Провідні оператори вже сьогодні пропонують гігабітні пакети. Через деякий час це стане стандартом де-факто. В розробці є моделі, які підтримують 2.5 Гб, очікуємо появу 10 Гб в недалекому майбутньому.

Стисло – це все про сучасний стан речей у темі роутерів та обладнання. У наступній колонці ми поговоримо про OpenWrt. Не перемикайтесь!

Бажаєте більше?

До вашої уваги – ще більше технічних статей плюс професійні спільноти GlobalLogic, що діють у Facebook:

Приєднуйтесь!

Мікросервісна архітектура для початківців. Частина ІІ

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

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

Міжсервісна комунікація
Стратегія

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

Основні стратегії комунікацій

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

Це:

  • Блокуючий та синхронний
  • Блокуючий та асинхронний
  • Неблокуючий та синхронний
  • Неблокуючий та асинхронний

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

API

В рамках вибору комунікаційної стратегії, REST/HTTP та GraphQL – це базові протоколи, які зазвичай використовуються для надання високорівневих API для web. В будь-якому випадку дизайн високорівневих API вимагає чіткого розуміння best practice щодо API Management.

Для новачків важливим є розуміння концепцій API Gateway та версіонування API. Розуміння паттерну API-Led Connectivity – це відправна точка для глибокого занурення в організацію низькорівневих API та підсистем.

Відмовостійкість

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

Тут варто подумати про:

  • Timeout – щоб гарантувати час відповіді
  • Retry – для автоматизації повторних спроб у випадку деградації мережі
  • Circuit Breaker – для контролю у випадку виникнення каскадних помилок
  • Deadline – для контролю довгих запитів, що залежать від багатьох сервісів
  • Rate Limiter – для контролю навантаження згідно з SLA (Service Layer Agreement)
Консистентність даних

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

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

Натомість мікросервіси використовують подієво-орієнтований підхід доступний для імплементації у двох моделях: оркестрація та/або хореографія.

Транзакції

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

Коли ви купуєте чашку кави, у цьому процесі, транзакції з базою даних не беруть участь. Ви платите гроші і чекаєте в черзі, поки не отримаєте повідомлення про те, що ваша кава готова. Якщо щось піде не так, ви просите компенсацію і або отримуєте вашу каву або повертаєте гроші. Іншими словами, це архітектура, керована подіями (Event-Driven Architecture).

Події

Існує дві логічні сутності: події та повідомлення. Вони відрізняються логічно так же, як шина подій (event bus) від черги повідомлень (message queue). Треба розрізняти логічну різницю між цими термінами.

Повідомлення (message) є частиною систем, заснованих на брокерах повідомлень (message broker), де повідомлення відправляється в чергу/топік, враховуючи, що отримувач (consumer) отримає його та щось зробить. Ця модель називається “fire and forget”.

Події дещо відрізняються від повідомлень. Повідомлення може бути чим завгодно (число, текст, JSON тощо). Події, своєю чергою, є логічно закінченою контекстною інформацією і повинні мати чітко визначену структуру (наприклад, JSON). Події також можна зберігати в системі до конкретного часу для повторного використання (event replay) або аудиту.

Шини подій зазвичай відповідають за зберігання/стрімінг/обробку подій, саме цим вони відрізняються від брокерів повідомлень. Наприклад, Kafka проти RabbitMQ.

Паттерни

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

Наприклад:

  • Event Sourcing – для збереження стану програми в серії подій
  • CQRS – щоб скористатися перевагами розділенням моделей читання та запису
  • SAGA – для забезпечення глобальної консистентності даних використовуючи послідовність локальних транзакцій
  • Event Streaming – для застосування принципів обробки потоків до подій
Інфраструктура

Мікросервісна архітектура може стати дуже складною, тому керування інфраструктурою та застосування DevOps best practices є важливими на всіх етапах розробки.

Розробка масштабованого (scalable) та високодоступного (high-available) мікросервісного рішення може потребувати багато зусиль. В тому числі складно підтримувати систему де є сотні мікросервісів.

Event-driven domain-based decoupling

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

У будь-якому випадку (багатодоменний або ні), в мікросервісній архітектурі вам доведеться мати справу з такими темами, як:

  • Code Repositories — mono-repo проти multi-repo
  • Deployment Strategies — включаючи топологію оточення (dev, qa, uat, prod) та deployment стратегії (blue-green, canary, тощо).
  • Автоматизація – включаючи оркестрацію кластера, Service Mesh, CI/CD.
  • Загальні проблеми (Common Concerns) – контейнеризація, оркестрація, конфігурація, безпека, моніторинг, логування, трейсінг, кешування, комунікації тощо.
  • Тестування – e2e, інтеграційне, contract-driven тощо.
Висновок

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

  • best practices рефакторінгу монолітів до мікросервісів
  • платформ обробки даних (Data Platform, Data Lake)
  • різні event-driven архітектури

Тож не соромтесь, задавайте питання, співпрацюйте та підтримуйте зв’язок! Де та як?  До вашої уваги – професійні спільноти GlobalLogic, що діють у Facebook:

Приєднуйтесь!

Scrum Guide 2020: що нового?

Минуло досить багато часу з моменту останнього оновлення в Scrum Guide (а ось тут – українська версія).  І ось воно! Нова версія, яка з’явилася у листопаді 2020 року, принесла цікаві зміни. На мій погляд, ці нововведення вносять більше гнучкості в процес. У цій колонці пропоную покроковий огляд оновлень.

Ще менш наказовий

З роками посібник зі Scrum почав ставати дедалі жорсткішим, тобто вказував, ЩО робити і ЯК. Версія 2020 року має на меті повернути Scrum до попередньої гнучкости шляхом вилучення або пом’якшення наказового тону. Наприклад, було видалено щоденні запитання Scrum, пом’якшено настанови щодо атрибутів PBI в product backlog, пом’якшено настанови щодо елементів з ретроспективи у backlog спринту, скорочено розділ стосовно скасування спринту, тощо.

Що це означає?

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

  • Використання щоденних запитань Scrum не є обов’язкове. Важливо, щоб люди чули одне одного, ділилися думками та звертались за допомогою, якщо це потрібно. Є багато шляхів побудувати бесіду в команді, і ми не повинні обмежуватися питаннями “Що я зробив”, “Що я буду робити” та “Які в мене перешкоди”.
  • Якщо ми говоримо про Product Backlog Items (PBI), то це завжди гарна ідея мати достатній рівень деталізації, естімейтів, важливості для бізнесу тощо. Однак важливо, щоб це відповідало потребам бізнесу та сферам діяльності. Як результат, PBI можуть містити згадані атрибути, але не бути обмеженими ними. Пом’якшення атрибутів PBI – це розширення гнучкості та уникнення заклику до жорстких порядків.
  • Ретро-елементи зараз є більш абстрактні. Автори повідомляють нам лише те, над якими ключовими аспектами слід працювати під час ретроспективної зустрічі. Існують десятки інструментів, які дозволяють нам обрати найкращий підхід до ретроспективи, роблячи цю церемонію найефективнішою для команди. Загалом це призводить до зменшення рекомендацій щодо того, хто що повинен робити, і більшого зосередження на результатах.
  • Скорочення інших частин у Scrum Guide надає більшої прозорості та не перевантажує опис процесу з очевидними наслідками, якщо сталася якась дія, наприклад “Скасування спринту”.
Єдина Команда фокусується на Єдиній Меті

Метою було усунення концепції “команди в команді”, яка призводить до поведінки “проксі” або “ми й вони” між Власником Продукту та Командою Розробників. Зараз є лише одна Scrum Команда, яка зосереджена на єдиній меті, з трьома різними рівнями відповідальності: Власник Продукту, Scrum Master та Розробники.

Що це означає?

У попередній версії не було виокремлено жодної підгрупи і лише розробників винесли в підгрупу, і нарешті цей підхід додано на рівень всієї команди Scrum. Найперша ліквідація поведінки “ми й вони” відбулася у 2011 році, коли вилучили посилання на концепт курей та свиней. І зараз це логічне продовження скасування поділу Product Owner та Dev Team (Власник Продукту та Команди розробників). Розмір команди зараз відноситься до Scrum Team, а не лише до розробників. Окрім того, версія 2020 року радить, але не обмежує наявність до 10 людей у ​​Scrum Team, пояснюючи чому маленькі команди працюють краще.

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

Впровадження Цілі Продукту

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

Що це означає?

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

“Ціль продукту” описує його майбутній стан. Дуже важливо дотримуватися визначеної мети, щоб постійно перевіряти, чи команда Scrum розробляє продукт який очікується. Також Scrum команда може обрати неправильний шлях і приректи продукт на провал, якщо не буде звірятися з кінцевими цілями.

Місце для Цілей спринту, Визначення Готової Роботи та Цілей Продукту

Попередні посібники зі Scrum описували Ціль спринту та Визначення Виконаної Роботи (Definition of Done), не даючи їм справжньої ідентичності. Вони були не зовсім артефактами, але були дещо пов’язані з артефактами. Завдяки тому, що було додано Ціль Продукту, версія 2020 надає більше ясності. Кожен із трьох артефактів тепер містить „зобов’язання” щодо них: для product backlog ‐ Ціль Продукту, для backlog спринту ‐ Ціль спринту, а для Інкременту – Визначення Виконаної Роботи. Вони існують для забезпечення прозорості та зосередженості на прогресі кожного артефакту. 

Що це означає?

Зобов’язання – це готовність наполегливо та енергійно працювати та віддавати час на роботу чи діяльність. Створення артефакту повинно диктуватися бажанням досягти конкретних цілей. І завдяки “зобов’язанню” ми можемо провести одну лінію від Product Backlog Item до бажаного стану нашого продукту.

Самокерування та Самоорганізація

Попередні посібники зі Scrum називали Команди Розробників (Dev Team) самоорганізованими, вони могли обирати хто і як виконує роботу. Версія посібника зі Scrum 2020 року з фокусуванням на Scrum Команді підкреслює, що саме ціла Scrum Команда здатна до самоврядування, та може обирати хто, як і над чим буде працювати.

Що це означає?

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

Три речі до Планування Спринту

На додаток до “Що” та “Як” у Плануванні спринту, посібник зі Scrum 2020 акцентує на третій речі “Чому”, посилаючись на Ціль спринту.

Що це означає?

Ідея проста. Під час планування спринту Product Owner пропонує, як товар може збільшити свою цінність у поточному спринті. Потім вся команда Scrum співпрацює для визначення цілі спринту, яка відповідає питанню чому цей спринт цінний для зацікавлених сторін.

Порядок планування спринту: Чому -> Що -> Як

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

Висновки

Загальне спрощення мови для ширшої аудиторії. У посібнику зі Scrum 2020, акцент зроблено на усуненні зайвих та складних тверджень, а також на усуненні специфіки роботи в ІТ (наприклад: тестування, система, дизайн, вимоги, тощо). Зараз посібник зі Scrum складається з менш ніж 13 сторінок (в оригіналі).

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

Бажаєте дізнатись про Scrum більше? Пропонуємо переглянути цикл статей про Ролі у Scrum від Андрія Кульшана, Business Analyst, Product Owner, Consultant, GlobalLogic та Олександри Скібіної, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic!

  1. Ролі у SCRUM: Епізод І. Сходження Product Owner’а
  2. Ролі у SCRUM: Епізод II. Повернення Scrum Master’а

Гарного читання!

Exit-інтерв’ю. Що потрібно знати HR менеджеру

Одним з етапів процесу завершення співпраці є проведення exit-інтерв’ю. Для того, щоб цей HR інструмент був ефективним та сприяв впровадженню позитивних змін в компанії, важливо знати, як правильно проводити exit – інтерв’ю, які є особливості та нюанси та що робити далі, щоб зібрані дані перетворювались в конкретні результати. Щоб отримати відповіді на всі ці питання – читайте нижче!

Що таке exit – інтерв’ю?

Одним з фінальних кроків в employee journey (шлях співробітника від початку співпраці до її завершення) є проведення exit –  інтерв’ю. Exit – інтерв’ю – це зустріч, яку проводить HR менеджер зі спеціалістом, який прийняв рішення припинити співпрацю з компанією.

Цілі exit – інтерв’ю та чому важливо їх проводити?

Exit – інтерв’ю мають кілька цілей:

  • Можливість отримати чесний фідбек від фахівця і зрозуміти справжню причину розриву співпраці. Офіційна причина часто може відрізнятися від справжніх мотивів. Побудувавши правильно розмову й ставлячи правильні питання (нижче обговоримо їх список), HR менеджер може отримати правдиву й чесну відповідь, що саме змусило людини прийняти рішення піти.
  • Виявити, що можна поліпшити в процесах компанії, де є вузькі місця, що змушують людей приймати рішення про припинення співпраці й зменшити кількість подібних ситуацій в майбутньому.
  • Exit – інтерв’ю дає не тільки можливість проаналізувати, де компанія може поліпшити свої процеси, а й отримати рекомендації та зібрати цінні ідеї від спеціаліста, як це можна виправити.
  • Знизити емоційне напруження в настрої спеціаліста й створити фундамент для можливої співпраці в майбутньому.
  • Іноді рішення може бути спонтанним і емоційним, тому exit – інтерв’ю може дати можливість змінити намір людини. Якщо ж рішення все-таки остаточне, то в ході інтерв’ю варто обговорити перспективи подальшої співпраці – запрошення в alumni спільноту, можливість повернутися в компанію. У разі ж негативного настрою, exit-інтерв’ю дозволяє вирівняти емоційне напруження і розійтись, не спалюючи мости.
  • Отримати фідбек про ефективність безпосереднього менеджера. Цей фідбек дозволяє компаніям зміцнювати і заохочувати менеджерів, орієнтованих на розвиток і виявляти тих, чия поведінка не відповідає культурі компанії.
  • Узгодити фінальні зобов’язання обох сторін. З боку компанії – це можуть бути гарантії належних компенсацій, надання рекомендацій, для спеціаліста – дотримання договору конфіденційності, положень про інтелектуальну власність і т.д.
  • Вивчення пропозицій (пакета компенсацій, бонусів, тощо) інших компаній. Ця додаткова інформація дозволяє проаналізувати, наскільки компанія є конкурентна стосовно інших гравців на ринку.
  • Отримати рекомендації в пошуку заміни. Якщо людина припиняє співпрацю з компанією в позитивному настрої, то, цілком ймовірно, що він також буде готовий порекомендувати когось зі знайомих або друзів на вакантну позицію.
Хто проводить інтерв’ю?

Як уже згадувалося, exit – інтерв’ю проводяться, як правило, HR менеджерами.

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

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

Як проводити?

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

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

Що важливо не забути запитати на exit – інтерв’ю?

Наведемо кільки можливих питань для exit – інтерв’ю:

  • Чому ви йдете з компанії?
  • Що спонукало шукати пропозиції в інших компаніях?
  • Чого не вистачило в нашій компанії?
  • Що нам варто поліпшити?
  • Чи є у вас якісь ідеї / пропозиції, як можна це покращити?
  • Як складалися відносини з безпосереднім керівником / колегами?
  • Чи було чітке розуміння, як можна розвиватися всередині компанії?
  • Якби ви могли залишитися, що б змінили в процесах?
  • Що могло б спонукати вас повернутися в компанію?
  • Що також тримати в фокусі?
Підготовка

Як і до будь-якого виду інтерв’ю, до exit-інтерв’ю варто готуватися – вивчити профайл людини, зібрати попередню інформацію від безпосереднього керівника і колег, розуміти контекст припинення співпраці.

  • Атмосфера та етика. Перш за все, завдання інтерв’юера створити комфортну атмосферу для спілкування. Активне слухання, увага, чесність та відкритість допоможуть сформувати позитивний хід інтерв’ю. Не треба намагатись переконати або спростувати аргументи співрозмовника.
  • Слухайте, ставте питання і знову слухайте. Якщо під час інтерв’ю потрібно робити позначки, важливо попередити людини для чого і що ви збираєтеся записувати.
  • Конфіденційність. Exit – інтерв’ю повинно бути строго конфіденційним й співрозмовник повинен бути впевнений в цьому.
  • Спеціаліст має право відмовитися від участі, але якщо exit – інтерв’ю відбулося, подякуйте людини за час, співпрацю й готовність надати фідбек.
  • Крім самого exit – інтерв’ю, можливе використання також анкетування та збору додаткової інформації за допомогою анкети зворотного зв’язку. Формат таких опитувань не завжди однаковий – від автоматизованих анонімних питань через спеціальні програми (наприклад, Glint) до стандартних Google – форм.
А що робити далі? Як використовувати дані exit-інтерв’ю?

Роботу з результатами можна розділити на два напрямки:

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

  • Збір інформації для поліпшення процесів компанії в цілому – ґрунтуючись на даних з анкет exit-інтерв’ю та інформації, отриманої в ході самих зустрічей, HR команда може ініціювати перегляд і коригування тих чи інших процесів. Аналіз таких даних важливо проводити з певною регулярністю (раз на місяць, квартал і т.д.) для того, щоб вчасно реагувати на наявні проблеми в компанії.

Як зробити інтерв’ю ще ефективнішим?

10 порад і підказок, як можна поліпшити практику проведення exit-інтерв’ю. Усе, що проговорили вище у вигляді списку порад, аби ви могли легко перевірити себе перед інтерв’ю.

  1. Чесно проговорити мету зустрічі й чому важливий ця бесіда.
  2. Конфіденційність.
  3. Проговорити про цінність зустрічі для фахівця – залишити позитивний настрій на майбутнє, приєднатися в alumni спільноту або навіть можливість поновити співпрацю.
  4. Важливо систематизувати, обробити й використати отримані дані. Перетворюючи отриману інформацію в цифри, HR менеджери можуть ефективно аргументувати необхідність впровадження змін в процесах компанії й розмовляти з менеджментом на “мові цифр”.
  5. Помилкою буде вважати, що HR знає справжню причину припинення відносин з компанією.
  6. В ході інтерв’ю не намагайтеся запевнити, що виправите проблему і прийміть якісь заходи. Натомість – запитайте фахівця, яке його пропозицію, як можна поліпшити наявну проблему.
  7. Для великих компанії з представництвами в різних локаціях для стандартизації збору даних краще використовувати єдину анкету для exit-інтерв’ю для всіх локацій.
  8. Додатковим інструментом, який можна використовувати для збору даних від спеціалістів – анкети зворотного зв’язку для тих, хто повторно почав співпрацювати з компанією. Це дасть можливість отримати фідбек, що в компанії стало краще/гірше з моменту розриву співпраці, а що можна поміняти/поліпшити зараз.
  9. В ході інтерв’ю, особливо в конфліктних і складних ситуаціях, завжди зберігайте етичний підхід спілкування.
  10. Дійте позитивно, дайте спеціалісту зрозуміти, що ви відкриті для співпраці в майбутньому.

Головне – пам’ятати, що успіх роботи будь-якого інструменту залежить від вмілого та правильного його використання. Сподіваюсь, стаття допомогла розібратись з основними аспектами та нюансами при провадженні практики exit – інтерв’ю.

Бажаємо вам змістовних та продуктивних інтерв’ю!

Хочете дізнатись більше про інтерв’ю? Тоді пропонуємо вам переглянути такі статті:

    1. Як успішно пройти інтерв’ю з клієнтом? Поради менеджера

Автор: Олександра Cкібіна, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic Ukraine

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

  1. Always put your best foot forward, або Як Trainee пройти перше в житті інтерв’ю — 10 порад

Автор: Катерина Сич, Associate Recruiter, Consultant, GlobalLogic Kharkiv

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

GlobalLogic Game Community за 10 днів. Як ми це зробили

Традиційно GlobalLogic багато уваги приділяє взаємодії з аудиторією, а саме – ком’юніті. Наприклад, професійні спільноти, які ми створили у Facebook минулого року:

Крім того, що це майданчик для цікавого, корисного та комфортного спілкування професіоналів різного рівня, це ще й джерело авторського контенту, яким ми з задоволенням ділимось з нашими читачами. Наприклад, стаття-гайд CI/CD для JS розробників. Чи поради з технічного інтерв’ю з Java-інженерами.

З чого все почалось

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

Як будь-яка магічна історія, ця бере свій початок напередодні новорічних свят. В одного із консультантів GlobalLogic Lviv Сергія Горошка, Test Engineer, Quality Assurance, Consultant, виникла ідея створити спільноту, яка об’єднає усіх любителів комп’ютерних ігор.

Пандемія внесла свої корективи у повсякденне життя людей. Насамперед нема змоги зустрітись великою спільнотою офлайн. То що робити? Треба знайти майданчик для онлайн спілкування! Навколо ідеї об’єднались представники менеджменту, команди маркетингу та People Team. Всього за 10 днів було створено GL Game Community та проведено першу гру напередодні Нового Року.

Слово ініціатору та ідеологу цієї справи, Сергію Горошко, Test Engineer, Quality Assurance, Consultant:

  • Ідея говорила сама за себе ще за часів першої гри в L4D, під час якої я знайшов однодумців. Ми почали спілкуватися, грати, потім дружити. Community – хороший спосіб знайти новий інтерес чи поділитися досвідом, можливо чогось навчитися. Спільнота насправді може більше, тому що її будують люди! – Сергій Горошко, ініціатор та лід GL Game Community у Львові.
Чому вдалось зібрати людей так швидко?

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

Сьогодні GlobalLogic Game Community – спільнота, яка налічує близько 200 учасників та функціонує на платформі Discord. Спільнота побудована з п’яти основних розділів:

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

На цей час спільнота продовжує ділитися цікавими ідеями та планує зібрати більше охочих за інтересами.Також було додано можливість local events де кожний охочий може зібрати свій захід власноруч.

Чому ми навчились завдяки GlobalLogic Game Community?

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

Бажаємо  успіхів у побудові!

Мікросервісна архітектура для початківців. Частина І

Автор: Орхан Гасімов, Technology Director, GlobalLogic

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

Що таке мікросервіс?

Мікросервіс – це найпростіша одиниця, сервіс, який приймає вхідні запити для здійснення дії. Це може бути бекенд сервіс, який доступний цілодобово та без вихідних, або функція, яка викликається, коли відбувається подія. Простими словами, функція або набір функцій, доступних через певний API через мережу. Отже, це бекенд служба, розгорнута на сервері. У якомусь сенсі це монолітний додаток. Однак він не несе в собі всю функціональність системи, а лише меншу частинку логіки. На відміну від моноліту, отриманий додаток побудований як набір відносно невеликих незалежних служб, що називаються «мікросервісами», які комунікують через комп’ютерну мережу. Можна сказати, мікросервіси – це ті самі логічні модулі монолітного додатка, які розподілені через комп’ютерну мережу, замість того, щоб працювати в рамках одного процесу (пристрою).

Типова довідкова архітектура мікросервісного веб-додатку

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

Front-End — Client Application, Static Content
Back-End — API Gateway, Experience Microservices, Domain Microservices
Data & Integration — Data Stores, Integration Interfaces / Connectors

Розглянемо кожен ярус і опишемо, за що він відповідає.

Логічні яруси

  • Клієнтська програма

У випадку веб-програми, клієнтом, як правило, є веб-браузер. Дехто вважає, що клієнт – це UI, але це не так. Браузер – це клієнт, який завантажує статичний контент із віддаленого сервера і рендерить UI всередині себе. І він же є клієнтом, що обробляє фізичні HTTP запити ща надходять до сервера. Важливо розрізняти клієнт та контент. Особливо, якщо ви розробляєте micro-app frontend.

Клієнт (веб-браузер) взаємодіє з Backend, щоб рендерити UI та викликати API.

  • Статичний контент

Найкраща практика – розділити відповідальність шляхом роз’єднання логічних компонентів, щоб жоден компонент не відповідав за все. З цієї причини рекомендується подавати статичний контент через окремий серверний компонент. Це дозволяє відокремлювати статичний контент від API. Кілька важливих принципів, на які потрібно звернути увагу, – це server-side rendering, кешування та контроль доступів.

  • API Gateway

API Gateway – це центральні двері для всіх публічних API. Це єдина точка входу для так званих Experience APIs, доступних для клієнтських програм, і є важливою складовою найкращих практик управління API (API Management). По суті, він передає запити реальним бекенд сервісам та здатен приймати рішення. Частіше за все, API Gateway відповідає за такий функціонал, як:

  • Request handling
  • Upstream (або downstream) data transfer (або transformation)
  • Access control
  • Security policies
  • Throttling
  • Rate limiting
  • Analytics
  • Caching
  • Experience мікросервіси

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

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

Уявіть набір мікросервісів, які надають API вищого рівня, орієнтовані на клієнтський досвід, повторно використовуючи низкорівневі гранулярні API, доступні в системі. Наприклад, різні продукти, що постачаються для веб- і мобільних клієнтів (Experience), можуть використовувати різний набір experience API, представлених незалежними мікросервісами за API шлюзом (API gateway).

Ці мікросервіси утворюють experience ярус, який логічно відокремлений від інших ярусів. Він може бути керований та налаштований (масштабований, налаштований, захищений тощо) незалежно. Зверніться до архітектурних паттернів API-Led Connectivity та Backend For Frontend, щоб глибоко заглибитися у зв’язані концепції.

  • Доменні мікросервіси

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

Таким чином experience сервіси сфокусовані на користувачі та продукті, в той час, коли доменні мікросервіси відповідають за дані та ресурси, що знаходяться під їх управлінням. Тож, доменні мікросервіси постачають гранулярні API нижчого рівня, які дають можливість створювати різни experience сервіси, повторно використовуючи доступну доменну логіку.

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

  • Бази даних

Best practice полягає в тому, що база даних повинна належати лише одному мікросервісу. Жодні інші сервіси не повинні мати можливості безпосереднього доступу до бази даних, лише через API сервіса-власника. Це дозволяє кожному сервісу керувати консистентністю та структурою бази даних, якою він володіє. Також це дозволяє обирати найбільш відповідну базу даних для конкретних цілей без будь-якої залежності від вимог системи в цілому. Наприклад, один сервіс може використовувати нормалізовану базу даних SQL, тоді як інший може отримати вигоду з бази даних NoSQL. Однак один мікросервіс може керувати кількома базами даних.

Сервіс може мати безпосередній доступ до бази даних, лише якщо він є власником. В іншому випадку він повинен використовувати API мікросервіса-власника і ніколи не мати безпосередній доступ до бази даних інших сервісів.

Спільне використання бази даних може потенційно призвести до анти-паттерна Distributed Monolith. Якщо вам потрібно надати загальний доступ до даних, зверніться до таких концепцій централізованих сховищ, як :

  • DWH (Data Warehouse), 
  • DFS (Distributed File System) 
  • Data Lake. 

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

  • Інтеграційні інтерфейси та конектори

Окрім внутрішніх джерел даних, програмі може знадобитися доступ до інших підсистем та сторонніх API. Корисна практика – розділяти інтеграційний ярус, запровадивши окремі сервіси-конектори.

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

Читайте другу частину статті за посиланням.

Технічне інтерв’ю з Java: запитання, лайфхаки та ключі до успіху

Автор: Дмитро Мрачковський, Consultant, Engineering, GlobalLogic 

У цій колонці хочемо поділитись власним досвідом у проведенні технічного інтерв’ю зокрема з технології Java.

Перш за все, визначимось з питанням, для чого ми проводимо інтерв’ю? Аби зрозуміти технічний рівень кандидата та оцінити його Soft Skills. Це може бути не так важливо для Trainee чи Junior спеціалістів, але надважливо для Senior, Lead чи менеджерів. Ще одна ціль інтерв’ю – перевірити чи підходить людина команді ментально.

Формат інтерв’ю

Які бувають формати інтерв’ю? Часто поділяють на структуроване та неструктуроване.

Структуроване інтерв’ю – це стандартний список запитань, які ви задаєте співрозмовнику, отримання відповідей та формування свого фідбеку.

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

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

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

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

Структура інтерв’ю

Поговоримо про стандартні секції в інтерв’ю:

  • Привітання та невеликий small talk. Оскільки інтерв’ю для кандидатів це майже завжди стрес, вашою задачею є цей стрес мінімізувати та допомогти вашому співрозмовнику налаштуватись та розслабитись.
  • Інформація про проєкт. Оптимальний час для цього до 5 хвилин. Мета – допомогти кандидату зрозуміти чим проєкт займається, та з чим він гіпотетично матиме справу. Не вдавайтесь в найдрібніші деталі, адже вам потрібно залишити час для технічної частини інтерв’ю.
  • Soft Skill розмова. Це можливість розпитати кандидата про його попередній досвід роботи та спостерігати за тим, як людина спілкується. У цій частині ви також можете перевірити рівень володіння англійської.
  • Технічна частина інтерв’ю (про це далі)
  • Питання від кандидата. Залиште час в кінці бесіди, аби кандидат мав нагоду поставити ті запитання, які його цікавлять чи турбують.
Технічне інтерв’ю

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

OOP

Перша тема, це – OOP. Зазвичай запитуємо про основні принципи та агрегацію композиції, тобто головні поняття з ООР. Ці питання рекомендуємо ставити всім, проте будьте готові, що ви отримаєте різні відповіді.

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

Приклад цікавого запитання – запитання про поліморфізм. Іноді буває, що кандидат розуміє що це, вміє ним користуватися та, можливо, навіть застосовує поліморфізм на практиці, проте не може доступно пояснити та розказати про його плюси, а це досить тривожний дзвіночок, особливо якщо інтерв’ю з Senior-спеціалистом.

Особливості Java Core/ Java 8-11

Запитання по Java 8 та пізніші версії можна теж ставити всім, а особливо техлідам та архітекторам.

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

Collections

Ще одне з обов’язкових запитань для всіх незалежно від рівня та мов програмування, якими кандидат пише, це – колекції, тобто структури даних. Можна розпочати з питання про список та множину (List, Set), fifo/lifo та про асоціативний масив.

Наприклад, пропонуємо кандидатам основні структури даних (в java це list, set, queue, set) та очікуємо, що вони знатимуть ці структури даних та зможуть пояснити чим вони відрізняються.

Хороше запитання: чим відрізняється список від кількості?

Популярна відповідь – кількість не дозволяє дублікатів, а список дозволяє. Насправді це далеко не ключова відмінність списку від множини. Основне це те, що елементи у списку зберігаються в тому порядку, в якому ви їх додаєте. Саме цими властивостями можна пояснити методи, які ви потім спостерігаєте у структурах даних. В список можна по індексу додати елемент, а в set – не можна, тому що set не гарантує порядку, і поняття індексу там немає сенсу. Ось в цьому полягає основна особливість.

Ще один приклад – HashMap. Чому це питання цікаве?

Практично всі розпочинають з кошиків (buckets), відповідаючи, що коли ми по hash-коду отримуємо bucket, то виникають певні нестикуванняколізії. Це стандартна відповідь. Мені ж тут цікаво запитати де ж ті самі buckets зберігаються. Кандидати, зазвичай, відповідають, що вони зберігаються в масиві. Далі запитую наступне: у нас є hash-код, і як же нам у масивах цих кошиків визначити індекс buckets, в які ми ці елементи додамо?

Тут є дві варіанти:

  • Люди знають як це зробити – і можна далі розпитувати. До прикладу, можна запитати як саме це робиться, для чого, та чому розмір масиву у HashMap завжди рівний. Мета цих питань, звісно, не завалити кандидата, а зрозуміти глибину його знань.
  • Люди не знають як зробити, але якимось чином знаходять рішення.
    Проте завдання не просто знайти buckets. Особливість HashMap – це амортизована константа доступу до елементу по ключу. Питання в тому, як добитися цієї константи складності пошуку елементу, і це найголовніша перевага HashMap перед будь-якою іншою імплементацією мапи. Тут важливо те, що ми не очікуємо правильної відповіді, важливо подумати та дослідити з кандидатом як можна за константний час визначити індекс в масиві. Чудовий момент, аби зрозуміти стиль мислення кандидата та побачити як він приходить до певного рішення.
Concurrency

Питання з Concurrency до Middle-спеціалістів ставляться рідко, бо люди на цих позиціях впевнено себе почувають у цій темі. Розпитувати у них деталі є беззмістовним. А от у Senior та Lead – краще запитати. Знання Concurrency для Senior є обов’язковим.

Серед популярних питань – про синхронізацію та що означає volatile. Всі ці запитання дають вам можливість зрозуміти наскільки добре люди розбираються у суті речей.

Data Stores

Далі, важливо з кандидатом поговорити про бази даних. Знову ж таки, це запитання для спеціалістів всіх рівнів, проте з молодими фахівцями варто подискутувати лише про базові речі, типу SQL. Middle, Senior та Tech Lead фахівців радимо запитати про теорему (обов’язково), чим відрізняються реляційні бази даних від не реляційних, коли та які саме застосовувати. Про SQL теж можна запитувати, але при необхідності.

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

JVMGC

Про JVMGC у Middle рекомендуємо запитувати на рівні загальних знань, а от для Senior та Tech Lead варто поставити більш конкретні питання. Проте, якщо у вас не вимогливий до перфомансу додаток, ці питання не є ключовими.

Ще один дуже важлива навичка, особливо для Senior та Team Lead, це – troubleshooting.

Troubleshooting

Це вміння зрозуміти в чому проблема, під’єднатися до неї моніторинг-інструментом (наприклад, Java Mission Control), зібрати дані та успішно розв’язати проблему на продакшені.

Framework

По Framework варто запитувати те, що використовується на проєкті. Можна також розпитати про те, на який фреймворк хотів би інженер перейти. Важливо запитати для чого придумали Spring, яку проблему він вирішує, на якому шаблоні він побудований, тощо. Гарний приклад питання на Spring – життєвий цикл bin в контейнері.

Сподіваюсь, що ці поради допоможуть вам зробити інтерв’ю цікавими та результативними.

Бажаєте дізнатись більше про інтерв’ю? Тоді вам будуть цікавими такі статті:

  1. Як пройти інтерв’ю з клієнтом від Олександри Скібіної, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic.
  2. Як побудувати спілкування з кандидатом найкращим чином та презентувати свій проєкт та команду найліпшим шляхом від Андрія Кульшана, Business Analyst, Product Owner, Consultant, GlobalLogic
  3. Як підготуватись до інтерв’ю, якщо ви у пошуках того самого проєкту мрії від Катерини Сич, Associate Recruiter, Consultant, GlobalLogic.

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

Курс “Communicate like a PRO: навички професійної комунікації” від GlobalLogic Education

Автор: Анастасія Васьків, University Program Coordinator, GlobalLogic

Пріоритетним напрямком роботи для компанії GlobalLogic є співпраця з молодими спеціалістами, які починають свій шлях в ІТ сфері. Багато часу та ресурсів компанія вже інвестує для розвитку молодого покоління технічних спеціалістів – ми активно проводимо технічні тренінги, курси, хакатони та семінари. Курс «Communicate like a PRO: навички професійної комунікації», про який піде мова нижче, як раз один з них.

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

В процесі безперервної комунікації зі студентами ми помічали те, що теоретична база, ґрунтовні технічні знання у студентів є, проте їм дуже часто бракує так званих soft skills, а саме навичок самопрезентації, бізнес-комунікації, досвіду в плануванні та інше. З іншого боку – в компанії є велика кількість досвідчених спеціалістів та професіоналів, які завжди готові ділитись своїми знаннями з початківцями.

Саме тому, команда GlobalLogic Education (спільно з платформою професійного розвитку Happy Monday) вирішила створити онлайн курс «Communicate like a PRO: навички професійної комунікації», який дозволить молодим спеціалістам глибше зануритись в тему бізнес-комунікації.

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

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

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

  • Чи даний курс є платний?
    Даний курс є абсолютно безкоштовним та всі лекції ми виклали у вільному доступі на сайті GlobalLogic, а також на YouTube каналі GlobalLogic Ukraine.
  • Чи можу я отримати сертифікат по завершенні курсу?
    На цей час функціонал генерації сертифікатів в процесі розробки, але, звісно, ми плануємо ввести його та надавати учасникам сертифікати від компанії.
  • Що мені робити з інформацією, яку я здобув/здобула на курсі?
    В даному питанні одними з можливих варіантів є:
    Почати застосовувати лайфхаки з курсу та практичні рекомендації в реальному житті. Відстежуйте, наскільки ця інформація впливає на вашу роботу в команді, на реалізацію нових проєктів та на успішність в пошуку роботи.
    Додати в своє резюме інформацію про те, що ви успішно пройшли закінчили курс. Ці дані точно будуть цікаві роботодавцю, а особливо компанії GlobalLogic.
  • Чи можу я подивитись записи лекцій пізніше, оскільки зараз сесія і часу на додаткову освіту бракує?
    Так, звичайно. Лекції є в наявності у відкритому доступі на сайті компанії та на корпоративному YouTube каналі і ви можете з легкістю переглянути їх саме тоді, коли вам зручно. Також, ви можете переглядати лекції частинами, що теж особливо зручно.
  • Чи планує компанія створювати онлайн курси на схожу тематику?
    В наших планах є створення низки онлайн курсів для студентів та початківців – як і на теми soft skills, так і в напрямку профорієнтації. Якщо у вас є конкретні пропозиції та ідеї, будь ласка, дайте нам знати за допомогою цієї форми.

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

Спілкуйтесь з профі, спілкуйтесь, як профі!

Все, що ви хотіли знати про GL BaseCamp, але не знали, як спитати

Авторка: Світлана Охович-Шаповал, University Program Coordinator, GlobalLogic

Для інженерів, що лише розпочинають свій шлях, та entry level фахівців GL BaseCamp — це чудова нагода підтягнути практичні знання та розпочати ІТ-кар’єру. Команда Університетської програми GlobalLogic зібрала ТОП-6 питань від потенційних учасників та учасниць наших курсів та описала особливості відбору, деталі навчального процесу та старту професійного шляху.

Аби не бути голослівними, ми вирішили запитати у наших колег, як їм допомогли ініціативи GlobalLogic вступити на професійний шлях й набратися впевненості у власних скіллах. Тож годі гаяти час, поїхали!

Яка мета GL BaseСamp?

Навчальні програми курсів GL BaseCamp — це ініціатива, яка з одного боку дозволяє entry level фахівцям отримати актуальні практичні знання та навички, а з іншого – допомагає команді відшукати таланти.

За усю історію GL BaseСamp відбулося більше 20 курсів за різними напрямками та спеціальностями. Програма кожного курсу адаптується та оновлюється щоразу перед стартом.

Олег Андрус

Associate Software Engineer, Engineering, GlobalLogic

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

Як пройти відбір на курс?

Конкурс в середньому це 5-6 людей на одне місце. Навчальні групи включають від 15 до 30 людей. Відбір студентів та студенток програми відбувається протягом 2- 4 тижнів. Критеріями відбору завжди є результати вступного тесту, мотивація, рівень англійської.

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

Вступне онлайн завдання отримують усі, хто зареєструвався. Різні GL BaseСamp мають свої вступні тести. Наприклад, для С/С++ чи Linux Kernel BaseCamp треба відповісти на питання з мови програмування С, а також орієнтуватися у роботі з Git і Bash. Задачі мають варіанти відповідей або відкрите поле для вашого коду. Щоб долучитися до QA Automation BaseCamp, ми просимо виконати вступне завдання на базі будь-якої релевантної мови програмування.

Віталій Андрушевич

Junior Software Engineer, Engineering, GlobalLogic

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

На щастя, мої старання у вивченні нового не були марними, адже сьогодні я в одній команді з професіоналами GlobalLogic. Потрапив сюди після курсів GL ProCamp. Вони дали мені можливість перейти на новий експертний рівень та опанувати нові навички, які потрібні для комплексного та складного інжинірингу.

Як побудовано навчання на курсі?

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

У разі потреби, активні студенти онлайн курсів отримують на час навчання додаткове обладнання. Наприклад, якщо до програми курсу входить опанування роботи з GL Embedded Starter Kit чи іншими апаратними пристроями.

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

Навантаження у курсів може бути різне в залежності від запиту стейкхолдерів курсу і вимог до майбутніх інженерів. Наприклад, у СС++ BaseCamp зазвичай дуже насичена програма, заняття проходять 4 рази на тиждень, а практичні завдання студенти виконують разом з досвідченими менторами. Програма QA Automation включає перший інтенсивний місяць, коли заняття проводяться тричі на тиждень, а далі — двічі.

Заняття на усіх програмах тривають 2,5-3 місяці. Ментори та викладачі курсу відстежують успішність, а наприкінці складають рейтинг студентів.

Що відбувається наприкінці курсу?

Після завершення лекцій та практичних робіт навчальна група отримує свої результати або відбувається презентація індивідуальних підсумкових проєктів. Зокрема, розробка власного pet-проєкту входить до програми Linux Kernel BaseCamp та може бути обрана за бажанням у СС++ BaseCamp.

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

Іменні сертифікати отримують усі, хто успішно пройшов курс.

Андрій Дубик

Software Engineer, Engineering, GlobalLogic

ВНЗ мені дав хорошу теоретичну базу, яка стала в пригоді під час моїх інтерв’ю у різних компаніях. Проте, часто не вистачало саме практичних навичок, особливо у світлі браку менторів або людини, яка може пояснити деякі речі на власному досвіді, показати це з практичної сторони.

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

Чи достатньо знань, отриманих на BaseCamp, щоб отримати першу роботу?

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

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

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

Я ще навчаюсь, чи зможу я поєднувати навчання в університеті та Trainee програму?

Ми пишаємося консультантами, які здобувають або уже мають вищу освіту. Серед наших консультантів в Україні близько 13% студентство. Це нелегке завдання, але необхідна підтримка з нашого боку завжди є.

Віднедавна у компанії існує два види програми для трейні для ІТ фахівців: перший — це фултайм взаємодія протягом трьох місяців, а другий триває до пів року і проходить у форматі part-time.

Орест Онищенко,

Trainee Software Engineer, Engineering, GlobalLogic

Я проходив різні ІТ курси. Зараз я вже 3 місяці як доєднався до компанії GlobalLogic у статусі Trainee. Тут маю ментора, який вводить мене в курс справ, допомагає засвоїти теоретичні знання та показує як застосовувати ці знання на практиці. Попри те, що я Trainee, я вже залучений до реального комерційного медіапроєкту. Саме підтримка з боку компанії дає мені сили та бажання рухатись вперед!

Успіхів та до зустрічі на GL BaseCamp!

Що почитати: дайджест кращих блогів за 2020 рік

Якщо кінець року – кращий час, аби підбивати підсумки, то початок нового – кращий час аби згадати найкраще!

Тож зустрічайте добірку блогів з рубрики BlogSpot за 2020 рік: актуальні теми, цікаві думки, поради та гайди від експертів. Приємного читання!

Як перестати хвилюватись та не перетворити навчання на прокрастинацію

Автор: Тетяна Хряпіна, Director, CEE Learning & Development Head, GlobalLogic Ukraine

Про що: Як вчитися ефективно, без прокрастинації та з задоволенням? Чим відрізняється мікро-навчання від макро? Що робити, аби вивчене не забувалось на наступний день? На ці та інші відповіді знайдете відповіді у цій колонці.

Тонкощі CV або Як скласти та кому надіслати, щоб отримати пропозицію мрії про співпрацю

Автор: Анна Туліна, Talent Acquisition Specialist, GlobalLogic 

Тема створення резюме актуальна завжди. Опис підводних каменів на цьому шляху та навички грамотної презентації власних досягнень часто прирівнюється до скрижалей мудрості або мапи скарбів. Проте, не все так складно, як здається на перший погляд. Як скласти CV? Що треба пам’ятати та як вірно розставити акценти, аби отримати пропозицію мрії про співпрацю? Відповіді – у детальній статті від експерта!

Soft and Hard Skills: Що важливіше? Розповідь одного рекрутера

Автор: Олена Лісовська, Recruitment specialist, Consultant, GlobalLogic Ukraine

Що важливіше: Hard чи Soft? А особливо, якщо мова йде про скілли? У чому полягає їх розділення? А що про це думають рекрутери? Питань багато, тож саме час розставити усі крапки над і. Саме це ми й спробували зробити у спеціальній статті.

Як успішно пройти інтерв’ю з клієнтом? Поради менеджера

Автор: Олександра Cкібіна, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic Ukraine

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

Always put your best foot forward, або Як Trainee пройти перше в житті інтерв’ю — 10 порад

Автор: Катерина Сич, Associate Recruiter, Consultant, GlobalLogic Kharkiv

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

Декомпозуй це: розкладаємо великі та складні задачі на компоненти

Автори:  Андрій Сидор, Senior Consultant, Quality Assurance, GlobalLogic Ukraine, Андріан Яблонський, Senior Consultant, Engineering, GlobalLogic Ukraine

Будь-яка велика задача складається з маленьких. Її можна розкласти на компоненти – це називається декомпозиція. Як декомпозувати складні задачі? Які техніки є ефективні? Про це та більше – розказали у цій колонці.

Python: чому вивчати та з чого почати?

Автор: Віктор Мойсеєнко, Team Lead, Python speaker and trainer, conducted over 25 group training courses, Consultant, GlogbalLogic Ukraine

Звісно, не міг цей дайджест обійтись без технічних статей! Чому Python такий популярний сьогодні? У яких сферах він використовується? А найголовніше – з чого почати вивчення цієї мови? На ці та інші важливі питання відповіли у великій оглядовій статті про Python!

Автоматизоване мобільне тестування: перші кроки

Автор: Антон Пелянський, Test Engineer, Quality Assurance, Consultant, GlobalLogic Ukraine

Перед кожним QA з часом може постати питання – чи можна зробити тест ефективнішим, швидшим та надійнішим? Можна! За допомогою автоматизації. З чого почати, які підводні камені тут існують та які методі є найбільш ефективними – розібрали у спеціальній колонці.

Інтерв’ю як історія: шлях героя для Agile проєкту

Автор: Андрій Кульшан, Business Analyst, Product Owner, Consultant, GlobalLogic Kharkiv

Продовжуємо тему інтерв’ю. А що робити, коли питання ставлять не вам, а ви? Як побудувати спілкування з кандидатом найкращим чином та презентувати свій проєкт та команду найліпшим шляхом? Практичні поради для менеджера проєкту щодо проведення інтерв’ю – прямо за лінком!

Кар’єра для студента: на проєкт без комерційного досвіду

Автор: Юлія Марсо, Recruitment specialist, Consultant, GlobalLogic Ukraine

З чого почати свої кар’єрний шлях? На що звернути увагу вчорашньому студенту? Які курси прийдуть на допомогу та як подолати фільтр “відсутність комерційного досвіду”? Що криється за назвами GL BaseCamp та GL ProCamp? Читайте за посиланням!

Бажаєте бути в курсі появи нових Блогів та оновлень? Слідкуйте за нами у соціальних мережах: Facebook, LinkedIn, Instagram та Телеграм-каналі.

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

  • URL copied!