Перші 2 місяці інтернатури пройшли в онлайн режимі. Підтримувати зв’язок нам допомагали два канали комунікації. В Slack інтерни могли звертатися за допомогою. Готових прийти на поміч інтернів було більше, ніж питань, тож зазвичай відповідь знаходили ще до того, як я встигав відреагувати на запитання. Також кожен день вcя група збирались в Zoom на спільний огляд результатів роботи. Кожен інтерн демонстрував роботу виконаного завдання та пояснював, як воно реалізоване в коді. В результаті інтерни навчалися на чужих помилках, могли бачити різні варіанти вирішення задачі та практикували свої здібності як доповідачі. Для спільного доступу до матеріалів сезону ми запустили сайт з лекціями та практичними завданнями. Частина лекції 19-го та 18-го сезонів вже доступна на сайті курсу інтернатури.
З кожним сезоном я частково змінюю практичні завдання для інтернів. Інтерни 19 сезону практикувалася працювати з масивами в Java, створюючи консольні хрестики-нолики. Потім ця гра стала основою для практики з ООП. Разом з завданням реалізувати зв’язний список вони показали, які ж проблеми вирішує інкапсуляція. Ця ж гра стали прикладом для мережевої взаємодії в Java. Далі REST API на Spring Boot, HTML/CSS, JavaScript та Angular. Тут все по класиці – тренувалися на todo list-ах. Таким чином за 2 місяці full time підготовки в онлайн форматі ми пройшли необхідний мінімум full stack розробника.
Після завершення ремонту в нашому офісі на Гоголя ми змогли перейти до другого етапу інтератури – командного проекту.
Хлопці взялися за розробку нового модуля нашої HR системи – назначенням контракторів на проекти. Досвід незвичайний тим, що з одного боку ми створювали новий мікро-сервіс, то ж це було схоже на розробку “з нуля”. А з іншого, в системі вже існують прийняті домовленості по організації коду. Для реалізації функціоналу необхідно відправляти запити на інші мікро-сервіси. А фронтент в нас – це один великий Single Page Application на Angular. Тож попрацювати з legacy інтернам теж випала нагода.
Чого не робить студент навчаючись в ВУЗі – так це не працює з вимогами та замовником. Типові курсові чи дипломні роботи зазвичай не потребують такої актиності. Але саме з цього і починається розробка продукту – аналізу того, які можливості необхідно реалізувати в системі і навіщо вони потрібні. Контактною особою (Product Owner в Scrum термінології) для інтернів став наш менеджер проектів Олександр Лукавий. На ньому інтерни випробовували свої вміння ставити чіткі та зрозумілі запитання.
Звикали робити це вчасно та фіксувати отримані деталі в системі управління задачами (ми використовували Jira). Одного разу інтерни зробили хибні висновки з прототипів у Figma і взялися за реалізацію, не перепитавши власника продукту. Як результат – зайвий непотрібний код, який потім видалили, та провалений спринт (ітерація, тиждень роботи в Scrum). Отримавши цей перший досвід в безпечних умовах, хлопцям буде простіше спілкуватися з замовниками на комерційних проектах.
Далі буде! 🙂
Post A Reply