Как преподавать IT в 2020 и не обосраться

Это пост не про менторство и не про воспитание джунов под крылом компании.

Это практические заметки о том, как преподавать IT и около-IT дисциплины в рамках учебного процесса (например в ВУЗе) так, чтобы что-то вложить в мозги подрастающего поколения, не порвать им (а так же их родителям, себе и деканату) мозг и жопу.

Здесь нет формальных и процессных советов. Скорее это про общий подход и очевидные косяки, которые нельзя допускать. А ещё много мата. Зато доходчиво и собьёт с тебя излишнюю спесь.

Disclamer

Преподавание - это не хер собачий, а очень ответственный процесс.
Для начала список неправильной мотивации для того чтобы преподавать. Серьёзно, если тебе хочется что-то из списка ниже, то просто не становись преподавателем и не возвращайся к этой идее пока дурь из головы не выветрится.

НЕ иди преподавать чтобы:

• потешить ЧСВ (сразу нет)
• заработать бабок
• вписать ачивку в резюме
• по приколу
• соблазнять студенток (строго индивидуально, но вообще не стоит)
• нанять толковых джунов за копейки (игра в короткую)
• попиарить свои разработки

Иди преподавать чтобы:

• получить опыт (в т.ч. руководства)
• закрепить свои знания по преподаваемой дисциплине
• чуть сократить количество фейспалмов во время собеседований
• обзавестись связями
• закинуть кадровые удочки (игра вдолгую)
• исследовать проблемы образования и кадрового рынка
• повысить visibility
• отточить ораторские навыки
• попиарить свой стек

Это не мануал как организовать коммерческие курсы (хотя основные принципы там те же) и не поучение старого пердуна как надо. Это рекомендации к действию, которые помогут тебе остаться в памяти студентов хорошим преподавателем, которого старшекуры будут вспоминать как "блин, а вот у нас был такоооой... вот он крут", когда ты покинешь свой пост (а ты его покинешь). В основном это мануал для тех, у кого в зоне досягаемости есть какой-никакой ВУЗ с кафедрами, деканатом, группами и техническим оснащением. Онлайн - это не ко мне, как организовывать консультационно-обучающий центр который клепает "вайтишников" за копейки - тоже (вообще не надо этим заниматься).

Trivia

Не будь мудаком. Мудака студенты вычленяют на раз - как следствие ты поимеешь проблемы с посещаемостью и рано или поздно твой курс превратится в нечто, по чему студенты просто будут сдавать заранее заготовленные задания и забывать как про страшный сон. Помни - если посещаемость низкая, то это не студенты разгильдяи, а ты что-то делаешь не так. Если падает посещаемость, то твой курс неудобен по времени/неактуален/имеет неадекватные требования/подача хромает и куча других причин. Вообще каждый раз когда ты имеешь какие-либо проблемы с успеваемостью или посещаемостью - первым делом задавай СЕБЕ классический вопрос: "А не мудак ли я?". Вот прям садись, выписывай на листочек все места, где ты можешь оказаться мудаком и долго думай. И только когда ты решительно не будешь понимать что ты делаешь не так - только тогда начинай копать в других направлениях. Если ты пришёл преподавать ради ЧСВ - то именно оно и будет мешать тебе найти правильные ответы в ходе отладки процесса (поэтому этот момент первый в списке противопоказаний).

Сегментируй аудиторию

Чётко выдели с кем хочешь и можешь работать. И не работай с теми, с кем не хочешь или не можешь. Аудиторию необходимо классифицировать перед началом работы. Если у тебя будет смешанная аудитория из разноуровневых людей - то попытка подстроиться под них под всех неизбежно похерит качество. Невозможно сделать курс по TypeScript, который будет одинаково полезен и для новичков, только вчера открывших Programming for Dummies, равно как и для 23-летних сениоров (хотя тут я может и погорячился) - все в итоге скажут что курс говно, а автор - мудак. У меня наиболее эффективно получалось преподавать для студентов 3 курса ФИТ НГУ. Там уже не надо тратить время на введение в основы и можно спокойно говорить о более интересных вещах. И даже если ты до начала занятий отсегментировал свою аудиторию и набрал тех, с кем можно продолжать - в процессе тебе всё равно придётся делить студентов на кучки и работать с ними по-разному (особенно если в твоей изначальной выборке > 50 человек). Но в целом задача сегментации в том, чтобы не обсуждать с выпускниками ВУЗа ключевое слово if и не говорить об особенностях архитектуры highload kubernetes-кластера со школьниками 9 класса.

Знай контекст

Если мы говорим об университете - надо настроить себя на категорически важный майндсет, который должен выступать для тебя императивом:

ТВОЙ ПРЕДМЕТ НАХЕР НИКОМУ НЕ УПАЛ. И ЭТО НОРМАЛЬНО.

Это - мантра, которую нужно повторять себе каждый раз, когда сомневаешься. Звучит контринтуитивно, но только через эту мысль у тебя получится сделать что-то действительно достойное. Помни - у студентов и помимо твоих выебонов до чёрта проблем, которые в основном создаются старыми пердунами, сидящими в профессорских креслах. А ещё им нужно время на участие в универской тусовке и нетворкинг, который для них будет полезнее чем тысячи часов задротства. Никому на хуй не всралось днями и ночами писать очередной компилятор или proxy-сервер потому что тебе, мудиле, кажется что "через это должны пройти все".

Далее. Если на твой курс попали студенты, которым оно не надо (такое иногда бывает в образовательном процессе) - не вставай в идиотскую позу "я обязан вас научить!" и "вы обязаны это знать!". Хуй они тебе на воротник обязаны. Первым делом идентифицируй всех, кому твои знания не нужны и отдели. Для начала предложи сделать с этим что-то административно. У меня например был спецкурс "по выбору" и я предлагал всем или поменять на другой если не интересно, или просто не ходить на занятия (ограничившись практическими заданиями), чтобы не портить атмосферу тем, кому действительно надо. Так же, сделай "короткий путь" для тех, кому нужен трояк, чтобы прохождение курса без порчи зачётки было максимально понятной и достижимой в условиях горящей жопы задачей. Если ты не позаботишься об этом заранее - то из тебя вынут все кишки на сессии. Сначала студенты, потом деканат, а если не повезёт - то родители. И ты всё равно с высокой долей верояности поставишь, но с совершенно неадекватными сути дела затратами нервов и времени.

Плюс к тому же учитывай актуальные тенденции. Если ты преподаёшь что-то, что имело место 10 лет назад, но никак не связано с нынешней реальностью (например компания послала тебя читать курс VBScript потому что у вас жирный американский заказчик, у которого половина системы на этой штуке и надо набрать обезьян) - то студенты это очень быстро раскусят и будут относится соответствующе. Позаботься о том, чтобы дать людям АКТУАЛЬНЫЕ знания, которые они смогут применить, например, на первом же собеседовании. Исключение составляют здесь классические дисциплины (матанализ, линейная алгебра, физика), но это отдельная песня и о них в данном мануале мы не говорим.

А ещё - не контролируй посещаемость. Это мудацкий рудимент, который должен умереть. Просто не надо.

Материал

Помни - в мире есть википедия, книги, видео-туториалы на ютубе, справочники, JavaDoc и MSDN. Если всё, что ты собираешься рассказать доступно в каком-то одном источнике (на одном канале, в одном учебнике, в одной серии статей) - настоятельно рекомендую оставить затею с преподаванием - и без тебя справятся. Просто не начинай. Для того, чтобы достичь успеха у тебя должна быть уникальная и эффективная подача, хороший опыт и/или уникальная, нигде не доступная информация. С последним сейчас туго, поэтому твоя роль сводится к тому, чтобы правильно структурировать и иллюстративно доносить. Так вот материал - это про то, как структурировать.

Технически

Стандарт в 2020: лекции доступные в виде раздаточного материала. Заставлять конспектировать - зашквар. Поэтому раздаточный материал ты должен подготовить заранее. Можно ограничиться планом (в теории), но я не видел ни одного человека, у которого бы это получилось. Лично для меня наиболее эффективная форма материала - слайды. Садишься и начинаешь излагать. Вот tip-ы по слайдам и презентациям:

• Не пиши блджд текст. НЕ ПИШИ СУКА ТЕКСТ НА СЛАЙДАХ. Максимум ограничься пятью (5) строчками.
• Слайды - это про скриншоты, схемы, диаграммы. Совсем хорошо - анимация.
• Лушче больше слайдов и меньше информации на каждом, чем наоборот
• У презентации обязан быть выдержан единый, удобный для просмотра стиль без выебонов и рюшечек (в MS Office есть неплохие встроенные шаблоны)
• Никакого Times New Roman. Это зашквар
• Загугли 10 мануалов как составлять слайды к конференциям и держи их в голове

Подготовка материала происходит ЗАРАНЕЕ, ПЕРЕД занятиями. В идеале - на каникулах, когда до начала курса остаётся месяц-другой. И это - адская работа. На хорошую лекцию уходит 8 часов времени, зато потом презентовать станет легче. Самый большой проёб - это готовить материал за день перед занятием. Это фу и некачественно. Я так делал, никому не рекомендую.

Подготовленный материал надо ревьюить перед каждой итерацией курса. В современном IT-мире всё то, что написано в твоих лекциях может превратиться в тыкву за неделю. Поэтому за месяц до начала курса открывай исходники презентаций и тщательно перепроверяй. Будет совсем хорошо если ты их допишешь, согласно реалиям.

В моём случае пришлось дописывать секцию про async/await в C# (когда вышла 4 версия). И обновлять скриншоты студии. Если бы я продолжил преподавать - пришлось бы писать про .NET Core, Rider и фишечки C#8. А ты что думал, всё будет легко и просто? Не, нихера. Это вот если ты какую-нибудь многопоточность преподаёшь или базы данных - там да, можно один раз написать и будет на века. Однако если речь о языках или фреймворках - то материал надо апдейтить РЕГУЛЯРНО. Хотя тебе, скорее всего, надоест.

Логически

Если ты просто накидаешь ссылок в текстовый документ, то зачем ты вообще нужен? Нужно проложить студенту путь для понимания. Любая дисциплина - это тёмный лес. Поэтому задача тебя как преподавателя - утоптать в нём тропинки, расставить указатели, взять за ручку и провести. Поэтому логическая компоновка очень важна. Вот tip-ы по логической компоновке:

Начинай с простого, но эффектного

Для того, чтобы человек въехал в тему и не потерял интерес - нужно дать ему что-то простое и эффектное. Что-то, что за мало усилий даст какой-то заметный глазу результат. Если для того, чтобы получить в консоли "It works!" нужно 2 часа настраивать кластер оракловых серверов, писать километры YAML-конфига, а потом надевать дождевик и нести кольцо всевластия бабушке через лес, полный русалок - то это решительно не то, с чего стоит начать.

Квантование

Да, я могу рассказать и показать студенту все плюшки C# за час. Только у него от этого разорвёт мозг, он удалит студию и будет пить антидепрессанты чтобы забыть. Поэтому ещё древние греки придумали делить подаваемый материал на модули, которые потом последовательно скармливаются студенту. Лучше много маленьких, но логически цельных модулей нежели один здоровый, обо всём на свете. Калибруй размер модуля так, чтобы всю суть можно было полностью раскрыть за 30 минут человеку, который это видит впервые в жизни.

Сложность

Естественным путём сложность информации будет возрастать к концу модуля. Позаботься о том, чтобы она не улетала в небеса РЕЗКО. Студент - существо умное и вполне себе может осознать штуки практически любой сложности, при условии что сложность возрастает плавно, а не разрывает ему дыню с порога. Калибруй производную сложности так, чтобы не было космических перегрузок, но в то же время чтобы не талдычить часами воду в ступе.

Как ты понимаешь, задавать вопрос аудитории "всё понятно?" - бессмысленно. Услышишь молчание в 9 из 10 случаев. Настоящий индикатор понимания - это когда студенты вовлекаются в дискуссию, задают вопросы, бьют друг другу морды. Если дискуссии и вопросов нет - значит что-то не так со скоростью роста сложности. Или всё действительно очевидно и говорить тут не о чем, или же всё настолько сложно что даже вопрос сформулировать нельзя. Как вариант ещё - между вами культурная стена, которую ты не потрудился разрушить.

Последовательность изложения

Переходы в рамках одного занятия должны быть последовательные и логичные. "Используйте X. Что, X вы ещё не изучали? Ваши проблемы" - это зашквар. Представь что ты проектируешь здоровенную систему, состоящую из кучи пакетов. Пакет X использует функциональность из пакетов Y и Z, а по сему не может быть собран раньше них. Вот примерно так же в голову студентов подгружаются знания. Каждый следующий кусочек ЗНАНИЯ должен быть постижим, используя все предыдущие.

Контрпример: в моём НГУ часто имела место ситуация а-ля "А вот чтобы решить эту задачу, нам надо составить систему дифференциальных уравнений. Что? У вас дифференциальные уравнения только в следующем семестре? Ну шоподелать, сами виноваты". Это называется нарушение связности материала. Фу таким быть.

Переходы между тейками в рамках модуля должны быть логичными и обоснованными. В духе "мы изучили печь, муку и яйца, если мы это совместим - можно получить кулич, сейчас я покажу как". Всё, сказанное после должно строем вытекать из всего, что сказано до . Если дальше течь некуда - всё, конец модуля. Объявляй перерыв 10 минут и переходи к другой теме.

Аналогии

Объясняй абстракции через конкретику. Это эффективно. Приводи аналогии и примеры из жизни. Человеческий мозг - это нейросеть, абстрактное мышление - это такой бонус, который требует существенных мысленных затрат и полагаться на него не стоит. Чтобы человеческий мозг наилучшим образом усвоил абстракцию - ему нужна конкретика. И чем эта конкретика проще и ближе к жизни - тем лучше.

Проиллюстрирую на примере: вот рассказываешь ты, скажем, про SOLID и SRP в частности. Всем нипанятна. Не беда - расскажи про одну большую аутсорс-компанию , у которой был такой-то проект , в котором было ажно вооот такенное место , которое сначала написали без соблюдения SRP, потом всё сломалось в самый ответственный момент, всем причастным раздали по роже и выгнали. Потом пришли нормальные пацаны и написали с соблюдением SRP, стало красиво и хорошо, работает по сей день, все пьют. Совсем хорошо если ты покажешь конкретный код с SRP и код без SRP.

Что примечательно: в предыдущем абзаце я вам рекурсивно объяснил абстракцию через конкретику. Надеюсь, стало понятнее. Черт, и видимо рекурсию тоже объяснил. Ну да ладно.

Мемы!

Мемы помогают анкорить материал: твои 5 строчек кода, иллюстрирующие отлов exception-а студенты не запомнят, а вот если рядом с ними будет подходящий по смыслу котик - отложится в голове.

Подача

А теперь отложи свои замечательные лекции в сторону. Я бы сказал, выкинь их к херам, но пока не надо.

Фишка в том, что если ты просто будешь зачитывать свои заготовленные слайды - ты на хер не нужен и тратишь своё и чужое время впустую. Привыкай что личные встречи как раз и существуют для того, чтобы решать то, что нельзя решить не встречаясь. Поэтому чтобы твои занятия имели больше смысла чем чтение лекций - тебе надо работать над подачей материала. Помни - твоя личность тоже анкорит знания. Если ты преподавал Python, то ещё долгое время студенты, сталкиваясь с Python-ом на работе будут вспоминать твою рожу, внешность, как ты говоришь и как ты объясняешь. Позаботься о том, чтобы эти воспоминания не были для них что вьетнамские флешбеки.

Поэтому: одеваемся нормально, но не напыщено. В идеале - так же как студенты. Посторонних звуков и запахов не издаём, с бодуна на занятия не ходим (стараемся). А главное - НЕ ПРОДАЛБЫВАЕМ ЗАНЯТИЯ. А ЕСЛИ ПРОДАЛБЫВАЕМ - ПРЕДУПРЕЖДАЕМ ЗАРАНЕЕ. Ничто не снижает доверие к преподавателю так, как неожиданный проёб занятия без предупреждения. При том происходит это на подсознательном уровне.

Далее, ломаем стену. Вставать на пьедестал "я тут охрененный специалист, а вы - щеглы которых понабрали по объявлению" - зашквар. Правильный посыл такой: ты - точно такой же человек, когда-то тоже был студентом, тебя прёт от темы, которую ты преподаёшь, но в то же время признаёшь право людей не переться от того же самого. Ты пришёл показать как это круто, как этим можно зарабатывать себе на жизнь, если хорошо знать. Тут есть тонкая грань в плане что не стоит переходить на совсем уж панибратство (это бесит, особенно если человек не хочет). Поэтому во время занятий - занятия. Все контакты по личным вопросам - во внеучебное время welcome. Пить со студентами - опционально.

Материал доносим чётко, уверенно и громко. Своими словами (можно подглядывать в записи/лекции). Нет ничего хуже чем мнущийся преподаватель, натужно подыскивающий что сказать (если такое случается - объявляем перерыв). Лекции могут быть открыты на фоне и они должны быть неким summary того, что ты хочешь сказать и/или иллюстрирующим материалом. Так что на них мы не смотрим. А смотрим строго на студентов, переводя взгляд с одного на другого.

Разумеется, меняем интонацию. Мы тут не покойника отпеваем, а пытаемся привлечь внимание аудитории к светлому, доброму, вечному. Если видим что аудитория теряет фокус - ей нужен отдых. Если до перерыва далеко, то сворачиваем объяснение материала и, например, травим байку из работы (только чтобы байка была смешная или поучительная). Байки заготавливаются заранее и используются для разряжения обстановки. Если всё сделано правильно, то аудитория будет в тонусе, а засыпать на твоих занятиях не будет. Однако помним, что перерывы байки не заменяют. Регламент предприсывает делать перерыв один раз в 45 минут и в целом неплохо бы ему следовать, но 5-10 минут туда-сюда допустимо.

Моя опыт показал, что очень хорошо для преподавания IT работает скринкаст. То есть транслируем на проектор экран и пишем код (это надо уметь делать быстро, но тут же нет никаких проблем - ведь ты senior, так?). Если что-то пишешь в скринкасте - увеличь шрифт чтобы всем было видно. Старайся писать так, чтобы код (или его целостная смысловая часть, на которой мы сейчас акцентируем) целиком умещался на экране. Если ты ничего не профакапил, то скринкаст работает как очень хороший анимированный слайд, вовлекая аудиторию в процесс написания, порождая дискуссии и вопросы. Поэтому лучше не показывать готовый код на картинке, а взять и напечатать его руками, запустить в дебаггере, сделать несколько step over чтобы было понятно как он исполняется. Ты ведь умеешь писать код, ведь так?

Задания

Без самостоятельной работы, увы, ничего в голове не откладывается. Поэтому нужны практические задания. Вот несколько моментов, которые надо про них понимать.

Первое и самое главное: НИКОГДА, МАТЬ ТВОЮ, НИКОГДА БЛДЖД НЕ ДАВАЙ ЗАДАНИЯ КОТОРЫЕ НЕ ДЕЛАЛ САМ. Не думай что ты тут самый крутой и можешь оценить и декомпозировать даже университетскую задачку в уме. "Ну я же даю что-то похожее?" - НЕТ БЛДЖД! НЕТ И ТОЧКА. ВСЕ даваемые студентам задачи, Я ПОВТОРЯЮ, ВСЕ должны быть прорешены преподавателем самостоятельно перед тем как быть опубликованными. Совсем хорошо если ты засечёшь время, за которое ты эту задачу сам сделал. Как же распорядится полученной информацией? Очень просто - вспомнить что студенты не в контексте, им надо курить мануалы и умножить время на 4. А потом вспомнить что ты у студентов не единственный мудак, который требует домашнюю работу - и умножить ещё на 2. И получишь примерно время, которое у студента уйдёт на то, что ты там выдумал. Если в сумме задача занимает больше недели времени full-time то или выкинь эту задачу на хер, или назови "курсовая" и измени подход к оценке.

Все условия заданий должны подразумевать КОНКРЕТНЫЙ результат. Если требуется написать программу - так и пиши "ТРЕБУЕТСЯ ПРИЛОЖЕНИЕ". А то у нас есть лошпеды, которые ограничиваются формулировкой "решить задачу о рюкзаке", а дальше вы, мол, прочтите мои мысли. Не будь как они - это зашквар.

Помимо конкретного результата, у всех заданий должны быть предельно чётко написанные условия, написанные понятным (а не птичьим) языком. Чтобы даже у обезьяны не возникало вопросов что от неё требуется. Если студент выкатывает тебе не то решение, которое ты хотел видеть и убедительно доказывает что в тексте задания написано так и написано - то ты мудак и задачу придётся принять (при условии работоспособности). Если не уверен что выразился ясно (хотя даже если уверен) - дай коллеге (а лучше двум) прочитать написанное. И если тот с первого раза не поймёт что требуется - ты уебан, иди переписывай. И да, эту работу надо делать ЗАРАНЕЕ, ДО НАЧАЛА КУРСА. А не дописывать на скорую руку на коленке прямо перед занятием. В целом же правило такое - чем более размыто написаны требования, тем более размыты должны быть критерии приёма задания. Иначе ты - мудак и тебя будут заслуженно обкладывать матами в кулуарах, а так же избегать работать в будущем. Студенты уже вошли в твоё положение в том плане что ты не можешь чётко написать условия - войди и ты в их положение при приёме задания.

Если у тебя есть требования к UI задания - не будь уродом - нарисуй мокап (используй Balsamiq/Axure/Figma). И бога ради не доябывайся чтобы кнопки стояли попиксельно если хочешь научить, а не заебать (их ещё менеджеры и заказчики заебут на работе с пикселедрочкой). Если у тебя есть требования к консольному приложению - покажи тегом <code> ожидаемый пример работы. И не забудь дать, БЛДЖД, ТЕСТОВЫЕ ДАННЫЕ. Или ты хочешь чтобы студенты занимались эникейством, генерируя и вбивая циферки в базу/текстовый файл?

Организационно

У меня хорошо сработали 9 разных задач с разными оценками за них и право выбора. Студент мог сделать 3-5 мелких задач, а мог взять одну большую, мог смешивать - как угодно. На самом деле я сделал иллюзию выбора и по трудозатратам любой выбранный путь был примерно одинаковый на аналогичную оценку. Единственное что у меня были задачи на "отлично" - для тех, кому предмет зашёл и кому хотелось челленджа. Но там уже индивидуальных подход во все поля - как при выполнении так и при оценке.

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

Контроль

Никаких автоматических средств проверки заданий! Если ты ставишь целью научить языку программирования, но при этом делаешь систему, которая автоматически запускает задачи студентов и сравнивает output с заранее заготовленным - ты не мастер преподавательской автоматизации, а убогий уебан, которому похуй на студентов и который не желает делать свою работу.

Весь код должен быть отсмотрен лично. Выдаваемый на экран результат (если он не очевидно неправильный) имеет опосредованное значение. Если ты преподаёшь, скажем, Java и смотришь чтобы программа выводила правильные данные и не заглядываешь в код, то ты - мудак. Потому что важно привить студентам нужные привычки с точки зрения кода, а не чтобы они сделали решение. А для этого надо смотреть код их реализации. При том просто просмотр кода тебе, очевидно, ничего не даст. Важно убедиться что студент понимает что в нём происходит. Для выявления этого факта прекрасно работают дополнительные задания или теоретические вопросы. Например - "а перепишите вот это место вот так вот, объясните происходящее", "сейчас программа выводит одну циферку, сделайте так чтобы было две", "почему вы использовали тут такой-то подход, что произойдёт если делать по-другому?".

Повторюсь, это конкретно про изучение языков программирования и фреймворков. Если же у тебя спецкурс по тренировке нейросетей - то тогда да, надо смотреть на результат а не на код. Короче, не будь мудаком. Проверяй усваиваемость того, что написано в названии твоего курса, а не всякое нелевантное говно.

Для выставления оценок должны быть чётко определённые формальные критерии. Допускается люфт в 5-10%, но не более. Загодя до начала курса ты должен точно знать за что ты готов поставить трояк, что в твоём понимании "хорошо" и что - отлично. И не менять эти стандарты на лету. И не подстраивать под конкретного человека.

Исключение из этого правила, пожалуй, одно: если студент уже подрабатывает на том стеке, которому ты обучаешь, то это обязано быть учтено. Вплоть до выставления оценки по предмету автоматом. Если у него есть пет-проект в гитхабе на твоём стеке - аналогично. Этот вариант даже лучше, ибо как ты можешь посмотреть код и поговорить предметно по узким местам. Практика показывает, что таких студентов немного и ты будешь большой молодец если поощришь их стремления индивидуальным подходом.

Технически

Если ты преподаёшь что-то, предполагающее написание кода, то это только github. Как вариант - bitbucket. Всё, no exceptions. Никаких своих самописных систем, куда надо загружать задание, оформленное определённым образом. Никаких отправок zip-архивов по почте. Код должен быть в репозитории. В популярном, которым пользуются все. Больше он нигде быть не может. Если речь о коде - то будет совсем отлично если ты научишь студентов мерджить, ребейзить, делать пулл-реквесты... Вот этой вот всей текучке. Ты будешь очень молодец, люди из индустрии скажут тебе спасибо.

Как бороться со списываниями

Через некоторое время ты заметишь что код некоторых задач подозрительно похож. И если твои задачи простые и реализоваться они могут строго одним способом, то тут списывание никак не спалишь. Однако же, если в задаче мало-мальски есть сложность и пространство для фантазии, то становится интереснее. Тут можно уже посмотреть на архитектуру (она всё равно у всех людей разная), дерево коммитов (хотя ненадёжно - многие пишут "в один коммит") и как-то что-то понять. Да, кстати, если ты дочитал до этого момента - то ты же понимаешь что требовать полного побуквенного соответствия решения твоему - это мудачество? Надеюсь что понимаешь, хорошо.

Я боролся со списыванием предельно простым способом: собирал всех списавших в кружок и давал им групповую задачу. Это хорошо работает, потому что мотивирует стороны не списывать и не давать кому-то свои решения (ибо в итоге проблемы будут у всех причастных). Работает отлично (при правильном установлении личностей причастных).

Ну и пойми, что через 2-4 года все практические задания придётся обновлять. Во-первых технологии поменяются, во-вторых студенческое сообщество очень хорошо обучается методом обратного распространения ошибки и эталонные решения очень быстро станут широко известны. Сгоревшие таким образом задачи заменяй новыми (надо иметь некий пул, да).

Устный экзамен

Можно, но я предпочитаю отталкиваться от кода и задач - в этом пути меньше пространства для манипуляций и принятие решения более прозрачно. Если тебе пришло в голову сделать устный экзамен - опять же не будь мудаком. Возьми вопросы, которые задают на реальных собеседованиях и гоняй по ним. Не надо выдумывать какую-то нерелевантную рынку хуиту из головы. Студенты будут проходить её по методологии "сдать и забыть". А вот если сдав экзамен у тебя они смогут пойти и найти себе работу - поздравляю, друк, ты работаешь как надо.

Пока всё. Придумаю ещё что-то - допишу.