Карго-культ в IT-освіті: як менторство перетворилося на техпідтримку

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

ІТ-фахівці, які проводять технічні співбесіди, часто кажуть одне й те саме: джуни після курсів приходять з гарними резюме, але не вміють мислити як інженери. Вони непогано знають термінологію, мають поширені теоретичні знання. А коли потрібно вирішити задачу, впадають у ступор. Притому майже в кожному резюме присутня фраза: «навчався з ментором».

Як так сталося? Чому менторінг, який нещодавно був знаком якості освіти, тепер нічого не означає?

Привіт. Мене звати Сергій Немчинський. Я розробник з досвідом понад 20 років, досвідчений техлід, засновник власної компанії та керівник навчального центру FoxmindEd. Про менторінг в ІТ я знаю все або майже все (читати з ноткою іронії). Сьогодні пропоную обговорити, як змінився ІТ-менторінг за останні роки, і що з цим робити.

Клієнтоорієнтованість, що призводить до інфляції менторства

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

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

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

Як наслідок, те, що вони продають, це не менторинг. А що тоді? Звичайна техпідтримка!

Пояснюю детальніше.

Анатомія підміни: як виглядає фейковий менторинг

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

Патерн № 1. «Ментор у кишені» (чат-підтримка 24/7)

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

Начебто це і непогано, але є проблема. Так формується навчена безпорадність. У роботі розробника ніхто не відповідає через п’ять хвилин, якщо щось не виходить. Це виглядає інакше: є завдання, є документація, є дедлайн. Усе. І якщо щось не вийшло з першої спроби, нікого це не хвилює, у компанії немає нянечки з носовичком 24/7.

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

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

Патерн № 2. «Колективний розум» (групові менторські дзвінки)

Ще одна популярна модель — коли один ментор спочатку проводить вебінар за обраною темою, сесію запитань і відповідей, а потім робить груповий розбір завдання на десятки людей.

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

По-перше, у великій групі ментор не може приділити достатньо уваги кожному студенту. Це зручно для тих, хто ходить на курс аби просто «відсидіти». Часто це ті, кому навчання оплатили батьки. Вони звикли так робити у школі або навіть у виші й гадають, що й тут прокотить. Але ж потім ці «відсидільці» прийдуть влаштовуватися на роботу, а в резюме буде згадано навчання з ментором!

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

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

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

Патерн № 3. «ШІ-ментор» і автоперевірка

О, ми згадали про ШІ. Як же без нього. Останній тренд в ІТ-менторингу — автоматична перевірка студентських завдань або «ШІ-наставник». Це продається дуже красиво. Тут і найсучасніші технології, і миттєвий фідбек, і майже необмежена масштабованість. Для бізнесу це ідеальна модель: система може перевіряти тисячі рішень без участі живого спеціаліста.

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

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

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

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

Патерн № 4. «Карусель» (різні ментори)

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

Виникає своєрідна «карусель менторів»: сьогодні один викладач, завтра інший, потім третій. Особистого контакту немає. Така перевірка виглядає досить формально, майже як автоперевірка або використання ШІ.

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

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

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

Профіль справжнього ментора

Є популярний міф: ментор повинен бути хорошим педагогом. Насправді головна вимога інша — ментор має бути сильним розробником.

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

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

Тому проста перевірка перед вибором курсу виглядає так: подивіться LinkedIn ментора. Цю ідею ми жваво обговорювали в коментарях до попередньої статті: що ти знаєш і вмієш сам і чому можеш навчити інших?

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

Методологія «no pain — no gain»

Є проста, але непопулярна правда. Справжнє навчання завжди проходить через дискомфорт.

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

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

Є три складові ефективного менторингу в програмуванні.

1. Мінімум теорії

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

2. Code Review як основний механізм

Справжнє навчання відбувається під час написання коду і після цього. Ви робите завдання → надсилаєте pull request → отримуєте коментарі. Іноді багато. Іноді болісно. Але саме в цей момент і «ростуть» ваші інженерні м’язи.

3. Критерій Done

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

4. Виділений ментор

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

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

Справжній менторинг — це процес, у якому студент постійно стикається з помилками, отримує чесний фідбек і вчиться мислити як інженер. Саме через цей дискомфорт і формується професійна навичка. Без нього навчання може бути приємним, але навряд ефективним.

Замість висновку. Чек-лист: як не купити ілюзію менторства

Перед тим як оплачувати будь-які IT-курси з ментором, варто поставити кілька простих питань. Це не щось складне або формальне, а просто спосіб зрозуміти, як насправді побудоване навчання.

1. Чи є у ментора LinkedIn?
І головне, чи працює він зараз розробником, а не просто викладає.

2. Як перевіряють домашні завдання?
Це просто тести, відповіді в чаті, чи нормальний code review у Git?

3. Що буде, якщо я застрягну?
Мені просто скинуть готове рішення чи допоможуть розібратися і самому дійти до відповіді?

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

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.