«И вот еще три ссылки, где про это можно почитать подробнее. Если будут вопросы — обязательно задавай», - устало пробормотал я в трубку.  Закончился очередной звонок с разработчиком на испытательном сроке. Опять возникло ощущение, что это повторяется в сотый раз: вот уже несколько лет мы встречаем новых участников команды и почти всегда ведем их примерно по одному пути (за редким исключением). Я понимал, что у нас уже достаточно наработок, чтобы оформить их в некий курс.  Меня зовут Дмитрий Чернышов, я руководитель группы разработки системы «БАРС.Бюджет-Бухгалтерия».Сегодня я поделюсь своим опытом создания обучающего курса для разработчиков.  С критериями отбора все было одновременно и просто, и сложно. Стек команд – Python/Django – популярное сочетание. Версии не самые последние по номерам, но в актуальных ветках. Обвязка вокруг основного стека пусть и обширная, но в большинстве своем стандартная. Собственные библиотеки есть, но при базовом понимании принципов работы основного фреймворка – можно было достаточно быстро разобраться и с ними. СУБД – PostgreSQL.  Из обязательных критериев сразу был убран PostgreSQL – первичный поток задач явно не подразумевал погружения в БД дальше ORM, а остальное можно было получить уже в рамках «Интенсива» и последующей работы. Обязательное знание Django заменили на формулировку «Django либо иной Python-фреймворк/ORM» с пояснением, что в ряде случаев (например, человек пришел из другого стека и знает пока только Python) и этот критерий может не являться обязательным. От Python решили не отказываться, поскольку тогда отбор мог бы затянуться на продолжительное время. Было понятно, что хотелось видеть в части компетенций у разработчика, прошедшего «Интенсив». После некоторых обсуждений появился следующий перечень того, что нужно было разобрать в рамках обучения:   Теория Python. Django. PostgreSQL. ООП. Паттерны. Структуры данных. Алгоритмы Окружение. Практика Разворот проекта. Основные компоненты продуктов. Работа с задачами. Процессы и инструменты Основные ресурсы и процессы подразделения и компании. Основные процессы команд. Основные инструменты работы. По процессам и инструментам в результате получилось так: часть тем были распределены на первые дни, а оставшиеся – по другим дням и смежным темам. После составления «скелета» курса стало понятно, что он займет тридцать один день (в конечном итоге их будет тридцать два).    Кроме того, было сформировано расписание типового дня: 09:30 - 10:00 - Теория. Проверка тем предыдущего дня. 10:00 - 11:30 - Теория. Новая тема. 11:30 - 12:30 - Самостоятельный разбор дополнительных источников. 12:30 - 13:30 - Обед. 13:30 - 14:00 - Разбор задачи. 14:00 - 16:30 - Самостоятельная реализация задачи. 16:30 - 17:30 - Разбор решений. 17:30 - 18:30 - Самостоятельная доработка замечаний по задачам. Чтобы различные дни «Интенсива» выглядели согласовано, был выработан небольшой перечень рекомендаций для менторов: Начинайте любое занятие по теории с проверки при помощи контрольных вопросов. Они должны дать понимание, какой уровень знания темы у участников, как они могут пересекаться или отличаться с контрольными вопросами, которые будут заданы на следующий день.  Прорабатывайте каждую тему при подготовке материалов, учитывайте тот факт, что группа может быть хорошо подготовлена по конкретному вопросу. Поэтому рекомендуется заготовить как базовые пункты/примеры, так и расширенные. Подберите к каждой теоретической теме материалы для самостоятельной работы. Минимум один-два источника (книги, вопросники и т.д.). Проводите разбор задач (кроме первой) по схеме: Демонстрация: прочтение текста, уточнение вопросов. Определение времени, за которое каждый из участников должен решить ее. Проверка реализованных решений (выполнение реализации в отдельной ветке), разбор ошибок. Демонстрация верного решения, если ни у кого его не было в полном виде. Разбирайте с группой по одной задаче ежедневно. Но рекомендуется иметь в запасе один-два варианта для дополнительного изучения, а также подготовиться к ситуации, когда разбор задачи перейдет на следующий день. На собеседованиях мы сразу предупреждали, как и в каком формате предстоит работать. Далеко не все были готовы к этому: кто-то просто просматривал рынок на предмет чего-то более «удобного», кого-то пугал быстрый темп обучения или нехватка знаний.  Но у курса было главное преимущество – мы сразу давали оффер на работу, а не на стажировку. На мой взгляд, это добавляло уверенности, что компания настроена серьезно.  Наконец, завершилась встреча с последним кандидатом. Офферы выданы и приняты: участники отрабатывали положенные им две недели на своих прежних местах, мы – готовили занятия первых дней и дополняли программу. В итоге студентами «Интенсива» стали 6 человек.  За десять дней до начала мы собрали общий чат со всеми. Я решил еще раз напомнить про системные требования к машинам. И тут началось:  - А у меня ядра по количеству только виртуальные, ничего?  - Ничего. - А прямо со старта 200 ГБ понадобится?  - Нет, но в процессе могут понадобиться.  - У меня все есть, но на Mac. А есть жесткий меньше, но на Убунте. Что лучше? - Пока можно остаться на Убунте.  - А у меня винда!  - И у меня! (немая сцена).  На тот момент казалось «некритично» – просто придется сделать больше действий для достижения конечной цели.  «Оглядываясь назад, первый вывод, который был сделан – требования к железу и ОС следует делать конкретнее и именно те, с которыми вы готовы работать. И если вам кажется, что главное *nix-система, а там срастется – вероятнее всего не срастется и тем более не взлетит». Но все были на месте и готовы работать.  Теоретические занятия показали, что участники многого не знают, но ребята старались и работали как сплоченный коллектив: и на звонках, и в чатах. Было интересно наблюдать за тем, как они взаимодействуют друг с другом, пробуют разные варианты, ошибаются и начинают сначала. После практических задач стало понятно, что студенты не привыкли писать комментарии и документацию. Потребовалось время, чтобы синхронизироваться в этой части, а также «утрясти» процесс работы через  репозиторий и pull-request’ы. Выводы первой недели:  Чистая система и Docker по официальному мануалу, никак иначе.   Bash-скрипты уместны, только когда они запускаются под Linux, так как при запуске в macOS – появляются проблемы.    Команда хорошо умеет скрывать слабые стороны отдельных людей.    Кроме того, у участников были сложности в понимании инструментария и компонентов типового приложения. Также у некоторых начали копиться «долги», другим не хватало знаний по темам, которые будут в середине курса, для выполнения заданий по продуктам. Для решения этих проблем пришлось скорректировать программу, добавив один день без практики. В этот день мы еще раз прошлись по всем инструментам, разобрали проблемные вопросы и синхронизировали с менторами подходы к работе, а кто-то из участников в течение этого дня доделывал оставшиеся «хвосты».  Но несмотря на трудности, мы старались не отставать от программы и продолжали двигаться дальше. От базовых тем постепенно перешли к расширенным, началось погружение в СУБД и ООП, с которыми у обучающихся было меньше опыта, чем, например, с Python. Если говорить о продуктовых задачах, то их сложность тоже постепенно увеличивалась. Мы перешли к задачам, где требовалось большего взаимодействия с предметной областью, а работа не ограничивалась только кодированием. Хотелось, чтобы ребята научились лучше анализировать взаимосвязи компонентов, постарались понять суть бизнес-процессов продуктов (это важные навыки).  Спустя два месяца обучения в нашей команде осталось пять участников. Было решено не давать итоговое практическое задание, поскольку ребята уже показали себя: было понятно, какими скиллами обладает каждый из них. Поэтому критерием по практике стало отсутствие «хвостов» и успешное прохождение итоговой аттестации, которую в результате сдали четверо. Еще с одним участником мы попрощались, но постарались дать ему подробный фидбек.  P.S. Во время обучения к группе присоединились два сотрудника компании, которые работали в смежном стеке.  По итогу курса хочется дать несколько советов. Надеюсь, вам они будут полезны:   Будьте готовы к тому, что придется начинать с основ.    Убедитесь, что все обучающиеся понимают принцип работы инструментов, с которыми им придется взаимодействовать в рамках курса.    Оценивайте не командную работу, а отдельно взятого человека.   Для проверки необходимы автоматические тесты.    Старайтесь, чтобы для всех учебных заданий была одна среда, но не в ущерб удобству их выполнения.   Старайтесь оставлять в учебных заданиях «пасхалки», связанные с дополнительными материалами.    Показывайте продуктовые задачи только после всех базовых тем, иначе общая нагрузка может напугать.   Проверяйте, что все готово к записи встречи, так как потом времени переснимать материал может и не быть.    Ограничивайте время работы с участниками.    И главный вывод – не бойтесь действовать. Да, мы допускали ошибки, но все получилось. За это спасибо нашей невероятной команде!    В процессе подготовки было изучено большое количество информации. Вот несколько ресурсов, которыми пользовались чаще всего:   realpython.com – познавательные статьи, подробно рассказано про базовые инструменты.    medium.com – для общего развития.    refactoring.guru – примеры по паттернам и рефакторингу.    postgrespro.ru/education/courses – курсы по PostgreSQL. Обратите особое внимание на DEV1 и QPT.   habr.com – без любимого Хабра никуда :)    www.djangoproject.com – полезно и кратко про документацию. Много примеров, а также комьюнити.    Кроме этого, в список рекомендаций к курсу попали несколько книг: Python. К вершинам мастерства | Лучано Рамальо Чистый Python. Тонкости программирования для профи | Бейдер Дэн   Django by Example | Antonio Mele   Эффективная работа с унаследованным кодом | Майкл К. Физерс   Head First: Объектно-ориентированный анализ и проектирование | Маклафлин Бретт   Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих | Бхаргава Адитья   Ведущий разработчик