Про боль простого и понятного изложения сложного материала
У меня, к сожалению, пока нет возможности сказать "мои курсы для души, а не для знаний", потому что мы, увы, учим всякому там машинлернингу и сопутствующей математике и программированию (хотя одна идея развлекательного курса у меня уже есть, может хоть там вздохну спокойно :). В частности, столкнувшись с тем, что успешно пройдя собес по ML после обучения у нас, слушатель может зарубиться на алгоритмической секции, мы решили добавить немного контента про алгоритмы и структуры данных во введение.
Тут можно смело сказать: "Что за наивность, несколько лекций для алгосекции?". Но на самом деле пройти алгосекцию не на Software Engineer это все же не медаль на ACM взять, и что-то с этим сделать можно.
Как решил поступить я: в модуле с пререквизитами к ML рассказываем несколько базовых тем (бинпоиск, сортировки, несложные жадные алгоритмы, динамическое программирование в простых кейсах, простые структуры данных), объясняем, зачем вообще этот сыр-бор, и накидываем ссылок на задачки с литкода. Во всех случаях объясняем, где это используется в работе с данными и когда выстреливает. А дальше, пока слушатель изучает ML, ему ничто не мешает решать в неделю хотя бы по несколько задачек на литкоде. После этого есть надежда, что на джунском или миддловом собесе на DS уж односвязный список человек развернет или бинпоиск напишет, не налажав в граничных условиях.
Так вот, вычитывал и правил сегодня утром составленные LLMкой конспекты про уроку, где рассказывается про работу массива переменной длины (который list в питоне или vector в плюсах) и вижу опасное утверждение, что время добавления нового элемента в конец в среднем О(1). Чем опасное? Ой, в бытовом смысле ничего страшного в нем нет, тем более в целом это нормальное утверждение, особенно если вы не изучали алгоритмы серьезно. А вот если изучали, вы знаете, что есть время работы в среднем и время работы амортизационно, для работы в среднем надо обсуждать какой-то случайный вход, а амортизационно считается усреднением по большому количеству операций и часто оценивается с помощью всяких неочевидных для неподготовленного слушателя подходов вроде банковского метода или метода потенциалов.
Я естественно в холодном поту бегу проверять, что там было у преподавателя в лекции: сейчас научим слушателя путать "в среднем" и "амортизационно" и его завалят на собесе. А добавлять еще приличное количество нетривиального материала, чтобы четко и понятно объяснить новичку разницу прям совсем не хочется, тем более до модуля по теорверу. К счастью, оказывается, что в лекции действительно рассказано про амортизационную оценку, так она и называется, и в целом можно сильно не переживать, только аккуратненько поправить в конспекте.
Но сама проблема, как составляя понятный курс для слушателя, не посвятившего Computer Science лучшие годы жизни, не ввести его в заблуждение и не подставить так на собеседовании или в работе - очень реальная и с ней приходится работать постоянно. И, кстати, по этой причине LLMки хоть и ускоряют подготовку материалов для курсов (тех же конспектов, например), но требуют очень тщательной проверки преподавателями.
Таких тревожных моментов как я описал выше у меня при подготовке любого курса в MLinside, на Физтехе и в Вышке десятки. Так что всем, кто думает, что преподавание это очень классно, приятно и вдохновляюще, вынужден сказать, что это еще и про постоянный страх подвести своего слушателя и борьбу с этим страхом с помощью перепроверок и исправления ошибок.