company_banner

Что вас на самом деле ждёт на курсе про алгоритмы в Яндекс.Практикуме

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

    А если речь идёт про курс, посвящённый алгоритмам, всё усложняется: ведь алгоритмы сами по себе — это не то, чем вы будете заниматься на работе. Это скорее добавочный уровень знаний, помогающий вам понимать программирование. Если совсем упрощать.



    Первая версия нашего курса про алгоритмы вышла не самой удачной и вызывала у некоторых студентов большие вопросы. Обратную связь мы иногда получали довольно эмоциональную, но часто справедливую. Та версия курса, которая предлагается студентам сейчас, — это издание дополненное и исправленное, с учётом всей критики за последний квартал. Что самое важное, в создании курса нам активно помогают выпускники, прошедшие его первую версию и набившие шишек самостоятельно. Спасибо всем участникам коммьюнити и авторам, которые контрибьютили в эту тему.

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

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

    Акела промахнулся


    Да, мы неправильно определили на старте целевую аудиторию нашего курса. Свою роль сыграло окружение и тот факт, что создатели курса много времени проводили в алгоритмической среде, где вращались такие же любители алгоритмов и сильные программисты. Уже отсюда пошло остальное: мнения продактов, тексты авторов курса, составление учебной программы и прочее.

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

    Знаете, это как в описании старого доброго DigitalOcean, “designed for developers”. Когда разработчики пошли и сделали решение для других разработчиков. Это крутой подход, потому что люди в теме делают что-то хорошее для таких же людей в теме. Зная все болевые точки, высказанные (и невысказанные) хотелки и нужные фичи.

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

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

    В общем, надо было что-то менять. И мы фактически поменяли весь курс.

    Работа над ошибками: для кого же этот курс


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

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

    Зачем людям вообще алгоритмы


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

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

    Именно из-за этого про алгоритмы так часто спрашивают на собеседованиях.

    Плюс множество историй успеха, когда кто-то подучил алгоритмы и стал крутым кодером в Facebook, например. Опять же, заметим: очень вряд ли этот человек на работе пишет классические алгоритмы.

    Вторая причина отчасти вытекает из первой. Это когда люди сталкиваются с синдромом самозванца и приходят учиться алгоритмам, чтобы повысить свой уровень.

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

    Как мы сейчас учим людей на курсе


    Итак, это базовый курс про алгоритмы и структуры данных. Мы начинаем с бесплатной части, так называемого «нулевого спринта», на котором предлагаем абитуриенту решить несколько задач, чтобы определить уровень подготовки. Если он справляется, значит, поймёт сам курс; если нет, то нужно подтянуть навыки программирования.


    Справа в столбике — 5 задач из бесплатной части курса


    Для каждой задачи описаны условие и формат входных и выходных данных, а чтобы проще было разобраться, есть пара примеров для иллюстрации

    Далее во вступительной части мы рассказываем, что такое алгоритмы вообще и зачем они нужны. Показываем, как решаются задачи по программированию, чем одни решения отличаются от других — ведь правильных решений больше одного. Они могут отличаться по времени исполнения, по потреблению ресурсов (особенно памяти). И именно от выбора студента будет зависеть, как быстро сможет работать его решение, насколько оно будет экономично.

    В целом теперь курс рассчитан на тех, кто вообще не знает ничего про алгоритмы, в нём нет суперсложных задач. Мы рассказываем, как в памяти устроены такие структуры, как массив, список, очередь. Здесь же объясняем про базовые алгоритмы — бинарный поиск и сортировки; разбираем рекурсию и различные рекурсивные алгоритмы.

    Затем подбираемся к более сложным штукам, говорим о хэш-таблицах и деревьях. После этого идут графы.

    Под конец курса оставлено самое сложное — алгоритмы на строках и динамическое программирование.

    От теории к практике


    Процесс устроен так. Сначала на платформе Практикума студент изучает теоретические материалы, а затем попадает на платформу Яндекс.Контест, где мы публикуем задачи. Там студент решает задачи именно по той теме, которую изучал в теоретической части.

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

    Сам курс — это восемь спринтов, в каждом из которых в среднем по 15 задач. Задачи при этом поделены на два вида, обычные и финальные. Для решения обычной задачи студенту просто надо написать код, послать его в Контест и получить в ответ ОК. В этом случае нужно именно одобрение от системы, и не столь важно, как именно написан сам код, — оценивается лишь его работоспособность, скорость и адекватные аппетиты в плане памяти.

    С финальными задачами всё немного сложнее. Кроме одобрения от Яндекс.Контеста нужно отправить своё решение живому человеку, код-ревьюеру из нашей команды. Их у нас несколько, потому что код студенты пишут на разных языках (Python, C++, Java, Go, NodeJS). Сами примеры задач мы по этой причине пишем на псевдокоде.

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

    Яндекс.Контест


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


    Интерфейс Яндекс.Контеста

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

    И тут начинается холивар, причём всеобъемлющий. Мнения разделяются как среди студентов, так и среди авторов курса.
    Система не скажет вам, что именно в коде не так, если он не работает. Вы просто получите в ответ «Код не работает», но не будете знать, почему.
    Некоторых студентов это дико бесит. Ну представьте: вы продолжаете закидывать систему кодом, а она вам просто: «Неправильно», «Опять неправильно». Как в школе, когда сдаёте реферат на 10 листов, а вам говорят: у тебя там одна ошибка, ищи. Поэтому возникает вполне резонный вопрос: как на обучающих курсах код-то отлаживать, если система не говорит, где косяк?

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

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

    Конечно, у наставников есть доступ к тест-кейсам, и по запросу они могут открыть его для студента. Это вечная дилемма насчёт тех неудобств, которые помогают развиваться.

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

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

    Ещё одна полезная функция Контеста — это статистика. Мы можем посмотреть, за какую задачу студенты вообще не брались, а за какую брались многие, но почти никто не решил. Это помогает постоянно улучшать курс. Если за задачу не брались вообще, то есть просмотрели её условие и даже не попытались решить, значит, проблема в условии. Оно непонятно написано, и надо его переделать.

    Человеческий фактор


    Как всегда, многое зависит от людей. Если с Контестом человек сработается, как и с любым другим инструментом (типа браузера или любимой клавиатуры), то с ревьюерами и наставниками ситуация может быть иной. Кому-то из студентов просто не понравится наставник, а кто-то будет уверен, что предыдущий наставник объяснял всё хуже, чем новый.

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

    Самостоятельное обучение


    Мы живём в прекрасное время, когда книги, учебные пособия, курсы и прочее максимально доступны. Можно сходить на Курсеру и выбрать себе навык по душе, а то и целую специальность. Можно наблюдать за любимыми проектами на гитхабе и уже одним этим потихоньку прокачиваться.

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

    Сами задачи по большей части у нас примерно такие же, какие вы можете встретить в сети, в книгах, в примерах. И это хорошо — это привычные и максимально приближенные к реальности задачи.

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

    В этом и смысл нашего курса, заточенного теперь под джуниоров.

    Кому курс точно не подойдёт


    • Тому, кто вообще не умеет программировать, и хочет научиться программированию сразу через алгоритмы. Базовый навык программирования тут необходим. Иначе вы просто не поймёте, что тут вообще происходит.
    • Тому, кто железно уверен, что отлично справится с обучением самостоятельно по книгам и иным ресурсам.
    • Тому, кто хочет алгоритмической жести. Мы сталкивались с обратной связью, когда человек был уверен, что курс по алгоритмам от Яндекса — это максимальный хардкор по алгоритмам вообще просто потому, что от Яндекса. Нет, тут всё не так. Мы любим алгоритмы, но сам курс у нас базовый. Только задачи уровня Easy и Medium. Без Hard. Возможно, у нас будут продвинутые курсы по алгоритмам, но точно отдельно от этого базового курса.
    • Тому, кто не готов уделять хотя бы 10 часов в неделю на изучение теоретического материала и непростые домашние задания.


    Что дальше


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

    У нас есть бесплатная вводная часть. Если сомневаетесь, нужен ли вам вообще курс по алгоритмам и осилите ли вы его, можно пройти её: и осмотритесь, и свой уровень знаний оцените.

    В общем, курс существенно обновился. И мы стараемся делать его ещё лучше.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Стоит ли открывать тест-кейсы?

    • 67,5%Да, люди должны знать, где ошибка77
    • 29,8%Нет, так они ничему не научатся34
    • 2,6%Свой вариант, напишу в комментарии3
    Яндекс.Практикум
    Помогаем людям расти

    Комментарии 42

      +14

      Ваш подход вызывает аналогию с обучением плаванию.
      Кинули пока не умеющего плавать человека посреди километрового пролива и сказали «плыви». Мол когда придёт время в реальности плыть вы столкнётесь с тем же окружением и теми же проблемами. Отсюда вытекает вполне логичный вопрос: а нафига нужно такое обучение?
      Так вот, обучение так не работает. Вы не даёте человеку возможность учится думать, хотя цели у вас именно такие. Потому что для новичка сам процесс поиска ошибки при известных входных данных — это уже обучение. А когда вы в самом начале пути начинаете топить, то все силы и стремления тратятся на преодоление бессмысленного стресса.
      Аргументы ваших сотрудников которые топят за то чтобы не показывать входные данные напоминают дедовщину, мол мы в своё время были в таких условиях, теперь и вы терпите.
      Я правильно понимаю, что вы хотели сгладить негатив после недавней критической статьи? Мне кажется что наиболее эффективно было бы сделать работу над ошибками и публично об этом рассказать, а не просто в очередной раз, другими словами рассказывать про проект.

        +8
        Мне кажется что наиболее эффективно было бы сделать работу над ошибками и публично об этом рассказать

        Ээээм, но у чуваков же в публичном посте

          +3
          Кинули пока не умеющего плавать человека посреди километрового пролива и сказали «плыви». Мол когда придёт время в реальности плыть вы столкнётесь с тем же окружением и теми же проблемами. Отсюда вытекает вполне логичный вопрос: а нафига нужно такое обучение?

          Если я правильно поняла, то ваш комментарий относится к закрытым тестам. Тут не могу согласиться с вашей аналогией про жесткое обучение плаванию. Открытие тестовых кейсов — не единственный способ помочь студентам. Мы подробно рассказываем, что делать, если код не работает, какие подходы стоит попробовать.

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

          Я правильно понимаю, что вы хотели сгладить негатив после недавней критической статьи? Мне кажется что наиболее эффективно было бы сделать работу над ошибками и публично об этом рассказать, а не просто в очередной раз, другими словами рассказывать про проект.


          Что касается работы над ошибками – именно о ней мы и рассказали. В недавней критической статье был описан случай из сентября 2020 — ошибки того времени мы уже исправили, и об этом рассказываем в посте.
            +7
            А на тот мегапост был подробный ответ? Просто человек подсветил очень много моментов, не только и не столько проблемы конкретного курса, а системные вещи. Неэтичное ревью, хамство менеджера, неотлаженную систему автопроверки, странный возврат денег, очень много чего. Тут мне кажется проблема не только в программе курса.
              +7
              Да, мы подробно ответили на мегапост в комментариях.
                +1

                Да, действительно, я не возвращался к перечитыванию комментариев. Спасибо за проделанную работу. Хотя я бы на вашем месте сослался на комментарий или исходную статью с критикой, мол поступали негативные отзывы которые подтолкнули нас к решительным действиям.
                Я субъективно считаю, что сложившаяся ситуация достаточно типична для многих крупных продуктовых компаний. Очень хорошо, когда кто-то вмешивается и радикально подходит к решению вопроса. Но нередки ситуации, когда на конечных пользователей забивают болт и продолжают тупо грести деньги. И будучи рядовым разработчиком у меня не было ни инструментов ни желания чтобы переть против руководства, которое считало что +- пару недовольных клиентов всегда будут.


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

                  +2
                  >Так вот, не обязательно сразу раскрывать непосредственно данные, а в индивидуальном порядке намекнуть, мол у вас нет проверки на отрицательные числа. И только через некоторое время, если уж совсем никак, открыть входные данные.

                  Так и происходит. Наставник смотрит на тест, на код и пытается навести на мысль о том, что могло пойти не так. Иногда может задать наводящий вопрос. Иногда может прокомментировать ошибку в коде программы, когда проблема не связана с основным алгоритмам, а касается каких-то частностей. В редких случаях может выдать тест. Ещё бывает, что наставник придумывает сходный тестовый пример и обсуждает со студентом, как программа будет работать на нём. Всё зависит от конкретной задачи и конкретной ошибки.
                    0

                    Тогда всё хорошо и в упомянутой выше критической статье просто наврали :)

              +5
              Опыт взаимодействия с Яндекс.Практикумом на другом курсе показывает что нет, вы вряд ли провели работу над ошибками. В курсе «аналитик данных» у вас другие проблемы, но обращение через чат с сообщением о проблемах с пед дизайном просто игнорируются. Вы не меняете задания, не исправляете проблемные места.

              Это вообще феерически, когда ответ верный, получен он не той функцией, что ожидал автор задачи, поэтому задача валится с неинформативной ошибкой, а саппорт через чат в ответ на критику просто даёт «правильный ответ». Или когда у вас полуфабрикат кода на 50 строк, где в случайных местах «недописаны строки» (и не везде по комментариям в коде понятно, что там что-то надо дописать", а в описании задачи вообще написано «постройте гистограмму», ничего про дописки нет.

              Отдельная боль — то что разные уроки сделаны разными людьми. Поверьте, это очень бросается в глаза. Подходы очень разные были у людей. Где-то кода минимум, где-то простыни, где-то надо делать функцию, а где-то выводить в STDOUT.

              И в том после, МНЕ КАЖЕТСЯ, основная претензия была именно к отношению со стороны компании, а не к технической реализации. И публикуя пост какие вы молодцы, вы лишь подтверждаете точку зрения автора предыдущей статьи.

              P.S. не подумайте, что мне не нравится Яндекс.Практикум. На фоне той дичи, что сейчас на рынке творится, у вас один из лучших продуктов. И при его объёме очень сложно сохранить планку, это я прекрасно понимаю. Вы делаете важное и нужное дело.
                0
                Здравствуйте! Меня зовут Алексей Макаров, я менеджер программы «Аналитик данных».

                По поводу вариативности принимаемых решений в тренажере, мы постоянно пытаемся улучшать качество проверок. Действительно, на старте программы в большинстве задач были жёсткие критерии проверки, которые предполагали строгое соответствие авторскому решению. Сейчас мы изменяем наши проверки на парсинг AST (Abstract Syntax Tree), это позволяет нам сделать проверку более гибкой, а также лучше понимать где ошибается студент, чтобы выдавать более точную подсказку. В большинстве курсов проверки уже модернизированы.

                Уроки действительно пишутся разными авторами. Это позволяет нам подбирать для конкретной темы эксперта, который наиболее полно раскроет её, учитывая свой профессиональный опыт. Сильный разброс по стилическому оформлению появляется где-то начиная с курса «Анализ бизнес-показателей». Это связано с тем, что с увеличением сложности курса всё меньше шаблонных вариантов решения задачи. Например, не существует единого подхода к оценке результатов A/B-тестирования с помощью Python.

                Про отношение компании к студентам:
                Помимо команды, которая занимается разработкой и поддержанием программы, есть те, кто сопровождает студентов, то есть помогает и заботится. Кураторы, наставники и преподаватели отвечают на вопросы по теории или практике, разбираются с ошибками или сложностями в тренажере и дают мощную поддержку всем, кому она необходима. Команда сопровождения собирает и передаёт обратную связь и ускоряет решение любых спорных ситуаций студентов полной программы. Однако у нас есть партнёрства с университетами, где нет необходимости в наших преподавателях и кураторах, от чего может сложиться не совсем корректное мнение про отношение со стороны компании и команды школы. Поправьте, если мы ошиблись, но вы учились/учитесь на подобной программе. Если у вас есть недовольства или вопросы к устройству курса — свяжитесь с нами через службу поддержки Практикума, мы стараемся помочь каждому, кто к нам обращается.
                  +2
                  Уже точно не вспомню темы, но мне показалось, что стиль очень сильно отличается где-то в районе «Предобработка данных» или даже «Введение в профессию Аналитик Данных» и заметна именно в переходе от одной темы к другой.

                  P.S. У меня не недовольство, я же выше написал, на мой взгляд это проблемы, которые у практикума есть, но в целом продукт очень крутой. Я его нескольким людям рекомендовал вполне искренне (хотя и предупредил о ряде проблем). И мне к счастью, помощь не нужна была за исключением нескольких досадных ситуаций (например как-то раз решал пункт задачи «через один», а грейдер мне всё твердил, что я не то вывожу, ну так сам дурак, всё верно). Мне бы хватило и форума с однокурсниками как на курсере, чтобы не нагружать вендора, но, у счастью, у меня есть бэкграунд. ;-)
            +14
            Самая главная ошибка таких курсов и их главная беда в том, что столкнувшись с реальной задачей реального мира такой курсист будет подгонять задачи реальные под те, с которыми знаком.
            И это очень распространенная ошибка.
            Вот типичный случай " возьмем пространство признаков и тогда каждая выборка будет представлять собой вектор" — и далее линал полным ходом. Но вот на простой вопрос — с чего это вдруг это пространство этих признаков обладает метрикой, сложением и прочими свойствами? Ответа нет — на курсах это нигде не преподают, ни на каких. А вот по линалу нахвататься формул можно достаточно просто.
              +13
              Стоит ли открывать тест-кейсы?

              Реально какая-то двойственная штука.

              А не думали как-то дополнять задачи? Допустим, юзер загрузил свое решение, система говорит ему «Обломись», и тут у юзера выбор.

              1. Пойти и реверсить свой код, чтобы самому понять, что там и где не так.
              2. Нажать кнопку «Показать, где накосячил», но при этом система тебе на зачтёт эту задачу, а даст вместо нее новую, по той же теме. И вот она уже учитывается.

              То есть когда ты понимаешь, где ты архитектурно косячишь и на что обращать внимание при создании кода, а не просто «Ошибка на строке 10 — исправь, будет ОК».

              Или такое тоже будет слишком жёстко и завалит студентов задачами?
                +6
                Идея хорошая, спасибо!

                Сходу видно несколько сложностей в реализации:
                1) Платформа не умеет предлагать новую задачу в ответ на неудачную попытку, и вообще гибкости не так много: либо открыть все тесты, либо все закрыть.
                2) Нужно решить сколько таких попыток давать человеку и сделать соответствующее кол-во задач на каждую тему. Это уже попроще, чем первый пункт, но всё равно требует времени.

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

                В любом случае спасибо за идею, любые такие предложения заставляют лишний раз подумать и может быть в итоге придумать что-то классное.
                  +3

                  Кейсы можно снабдить "подсказками". Например для случая, когда выбрана 32-х битная переменная, в которой не помещается весь диапазон заданных значений, кейс, который именно это проверяет, может выдавать намек, которого должно быть достаточно без раскрытия подробностей.

                    +1
                    Да, это здравая мысль, про подсказки думаем.
                +7
                Для каждой задачи описаны условие и формат входных и выходных данных

                Зачем это нужно? Литкод прекрасно обходится без этого, не заставляя заниматься вводом/выводом.


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

                Это болтология. В реальной жизни баг (почти) всегда можно воспроизвести на известных входных данных. Опять же, литкод прекрасно показывает тест, на котором случился TLE или для которого дан неверный ответ. Но у вас свой, особенный, путь, да.


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

                  +2
                  Есть немало причин и за ручной ввод/вывод, и за ввод/вывод посредством передачи данных в функцию. В любом случае, это точно не главная сложность в решении большей части задач (кроме задач, где именно ввод-вывод является лимитирующим фактором; да, такое тоже бывает).

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

                  По-моему все-таки "У вас в коде ошибка" — это не особенно похоже на реальность. В реальности мы знаем хоть что-то об ошибке — как она проявляется, в чем она заключается, при каких условиях, почему ее надо исправлять.
                  Не бывает же так, что начальник просто приходит и говорит "поправь код" и уходит.


                  И чего плохого в том, что люди будут просто подгонять код так, чтобы он проходил тесты? Если тест можно пройти с помощью подгона, то он плохо написан, недостаточно подробен или недостаточно въедлив.
                  Так же, как в TDD — мы пишем ровно столько кода, сколько необходимо для прохождения тестов :)

                    +5

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


                    И сидит потом студент над алгоритмом, ищет ошибку, которой в нем нет. А на самом деле входные данные — символы, а не числа или типа того.
                    В реальности это сразу было бы в отладчике видно, а тут только угадывать, что там авторы имели в виду под "на вход подаются числа", условно говоря.


                    Ну или писать в поддержку и тратить дорогостоящее время ваших специалистов.

                      0
                      Самый важный аргумент против открытия тестов — это то, что, придумывая тесткейсы самостоятельно, студент со временем научится писать код чище, заранее угадывать, где могут быть проблемы. Это банально бережет ресурсы программиста. Ну и если мы говорим о том, что в реальной жизни тест известен, потому что TDD — кто-то же должен был эти тесты изначально написать. Значит надо уметь тесты придумывать, причем всесторонние, охватывающие разные случаи, связанные с задачей.
                        +2

                        Но у вас же все-таки курс по алгоритмам, а не по юнит-тестированию?


                        Я в первую очередь говорю, что в реальной жизни проблемы себя так не проявляют, есть хоть какой-то симптом, хоть какой-то способ понять, в чем дело. Закрытый тест-кейс — это буквально "пойди туда, не знаю куда, найди то, не знаю что".


                        В реальности я не буду сидеть и просто медитировать над кодом, пытаясь понять, что не так, по крайней мере не в первую очередь! Я буду вставлять отладочную печать, читать логи, запускать анализаторы, выполнять код по шагам, буду изолировать проблемное место.


                        Тем не менее, и мои и ваши аргументы явно основаны на личных предпочтениях. Было бы здорово, если бы мы могли их как-то более весомо подкрепить.
                        Не попадались ли вам какие-нибудь исследования на эту тему? Можно ли ввести какие-то объективные метрики? Хотя бы, не знаю, сравнить несколько групп с закрытыми и с открытыми тестами.


                        Еще, кстати, момент — а вы студентам-то в самом курсе объясняете, почему тесты закрыты?

                          0
                          В реальности я не буду сидеть и просто медитировать над кодом, пытаясь понять, что не так, по крайней мере не в первую очередь! Я буду вставлять отладочную печать, читать логи, запускать анализаторы, выполнять код по шагам, буду изолировать проблемное место.


                          Остается только повторить Ваш вопрос: это курс по алгоритмам?
                            +1

                            Вы считаете, что алгоритмы можно понять только с помощью медитации над кодом, а не с помощью отладки?

                              +3
                              Есть баги которые только задумчивым взлядом на код и логами поймать можно.

                              Баг может проявлять себя только через несколько часов работы с потоком данных в пару сотен мегабит.
                              Или стрелять раз в месяц ночью.
                              Или быть в дебрях фьючер библиотеки и проявляться при хитрых условиях недоступности чего-либо внешнего что до этого было доступным.
                              Да и обычную гонку в непростом коде дебаггером не поймать.
                              А уж во всяких микросервисах которые имеют привычку стартовать и стопится не моментально и иногда оставлять следы своей прерванной работы столько красоты бывает.

                              Это все реальные случаи из моей практики.

                              Навык ловить баг без отдладчика полезный. Не для джунов, конечно. Им рано.
                                0

                                Соглашусь.

                            +4
                            Но у вас же все-таки курс по алгоритмам, а не по юнит-тестированию?


                            Тестирование на наш взгляд — важная часть обучения алгоритмам.
                            Если не умеешь реализовывать алгоритм так, чтобы код работал — значит не научился алгоритмам (в нашем понимании).
                            Чтобы писать рабочий код, надо уметь его тестировать, видеть разные кейсы.

                            Так что не вижу больших проблем в том, чтобы тренировать навык тестирования в курсе по алгоритмам. В конце концов, студенты приходят к нам за навыком, а не за «лёгкими» галочками напротив задач.

                            И да, конечно мы рассказываем им почему тесты закрыты и подробно объясняем что нужно делать, если не получается побороть тест.
                              +3
                              И да, конечно мы рассказываем им почему тесты закрыты и подробно объясняем что нужно делать, если не получается побороть тест.

                              Это хорошо!


                              Тестирование на наш взгляд — важная часть обучения алгоритмам.
                              Если не умеешь реализовывать алгоритм так, чтобы код работал — значит не научился алгоритмам (в нашем понимании).
                              Чтобы писать рабочий код, надо уметь его тестировать, видеть разные кейсы.

                              Тем не менее я не вижу в этом прямой корреляции с закрытыми тестами.
                              С вашего позволения, я повторю свои аргументы все в одном месте.


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

                              Минутка субъективизма

                              Лично я проходил несколько курсов (в т.ч. 3 или 4 по алгоритмам так или иначе) — тесты везде были открыты. В одном даже вместе с заданием выдавалась пачка тестовых кейсов, которые можно было запускать локально.
                              На мой субъективный взгляд — это были лучшие курсы с лучшими преподавателями, которые я в жизни видел. Подогнать код под ответ было невозможно, потому что реальные тесты содержали гигантские входные данные, это было проще сделать правильно, чем подогнать!


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


                              Соответственно весь мой опыт восстает против закрытых тестов, но опираться только на свой опыт — неправильно. Вероятно опыт ваших сотрудников говорит об обратном.
                              Поэтому было бы здорово как-то объективно сравнить результаты.

                                +2
                                Очень основательный ответ, приятно читать!

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

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

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

                                Закрытые тесты означают, что ваши наставники тратят больше времени на общение со обучающимися, разъясняя вещи, которые можно было бы просто увидеть в результатах тестов (т.е. буквально выполняют работу машин). Время ваших сотрудников, которое оплачивает ваша компания!

                                Нам кажется что сценарий
                                «Тест упал -> иду к наставнику -> наставник задаёт вопрос о логике моего алгоритма/советует вспомнить про краевые случаи -> я отвечаю на вопросы или следую советам наставника, сама додумываюсь до проблемы в коде»

                                лучше, чем сценарий

                                «Тест упал -> я взяла тесткейс, нашла в коде баг, поправила, отправила в систему опять»

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

                                Закрытые тесты скорее всего приводят к большей фрустрации учащихся и к большему уровню недовольства курсом в целом. Понятно, что ваша цель — научить людей алгоритмам, но как знать, сколько из них бросают это дело, потому что «аргх ничего непонятно опять ошибка!»?

                                За этим мы следим, стараемся помогать тем, кому сложно. Человек никогда не уходит от нас незаметно, так что все такие случаи известны и посчитаны

                                Закрытые тесты не похожи ни на реальное программирование, ни на реальное самостоятельное написание тестов. Неясно, действительно ли они помогают научиться тестировать код, по крайней мере курсы или книги по юнит-тестированию вроде бы такое не практикуют массово?

                                Мы считаем, что да, помогают, это консенсус многих преподавателей и программистов, с которыми мы обсуждали курс.
                                Наверное, чтобы доказать это или опровергнуть раз и навсегда, нужен эксперимент. Подумаем, как его устроить, чтобы не напугать студентов :)

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

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

                                Вероятно, открывать тесты по желанию учащегося было бы разумным компромисом (типа, нажать на кнопочку и согласиться с предупреждением). По факту вы ведь сейчас так и делаете! Только с привлечением живого человека, которому, опять же, нужно оплачивать его время, который не может ответить всем сразу, который мог бы отвечать на более интересные вопросы. А учащийся должен ждать этого ответа какое-то (полагаю, не очень малое) время, что тоже усиливает фрустрацию.

                                Мы думаем в сторону того, чтобы дать подсмотреть «по кнопке» несколько тестов. Большинство тестов всё равно довольно объемные и их открытие вряд ли сильно поможет.

                                Спасибо, что участвуете в обсуждении и предлагаете варианты, нам это важно.
                                  +2
                                  Очень основательный ответ, приятно читать!

                                  В свою очередь рад, что вы вообще идете на обсуждение :)


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

                                  Верно, но очень уж обидно тратить целый день на идиотскую ошибку в парсинге, когда вообще непонятно, в чем же ошибка заключается!
                                  Я вот представляю, что я студент-новичок — и реально не знаю даже, с чего начинать-то? В какую сторону думать? Каждую строчку перебирать?


                                  Нам кажется что сценарий
                                  «Тест упал -> иду к наставнику -> наставник задаёт вопрос о логике моего алгоритма/советует вспомнить про краевые случаи -> я отвечаю на вопросы или следую советам наставника, сама додумываюсь до проблемы в коде»

                                  лучше, чем сценарий

                                  «Тест упал -> я взяла тесткейс, нашла в коде баг, поправила, отправила в систему опять»

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

                                  Вот не факт, не факт. В первом варианте у человека буквально нет выбора, кроме как обращаться за помощью к наставнику. Поможет ли это думать — сильно зависит от человека, далеко не всем приятно сразу "признавать поражение" и просить чужой помощи. Не воспитает ли это рефлекс "чуть что сломалось — беги к старшему"?


                                  В случае открытого теста думать, скорее всего, то же придется — если ошибка в алгоритме и если она не глупая опечатка, то придется придумывать, что с ней делать.
                                  Можно так же возразить, что при этом у студента не будет ощущения, что ему помогали, нет, он всё сам!


                                  За этим мы следим, стараемся помогать тем, кому сложно. Человек никогда не уходит от нас незаметно, так что все такие случаи известны и посчитаны

                                  Это само по себе очень хорошо, но не лучше ли предотвратить страдания, а не "заглаживать вину" постфактум?


                                  Мы считаем, что да, помогают, это консенсус многих преподавателей и программистов, с которыми мы обсуждали курс.
                                  Наверное, чтобы доказать это или опровергнуть раз и навсегда, нужен эксперимент. Подумаем, как его устроить, чтобы не напугать студентов :)

                                  Как видите, здесь в комментариях довольно много людей с противоположным мнением :) Возможно, что ваш консенсус — это следствие confirmation bias и каких-то других групповых когнитивных искажений типа пузыря фильтров? Или еще каких-то умных слов, которыми я пытаюсь сказать, что люди с одинаковым мнением стремяться общаться только друг с другом и соглашаться друг с другом, тем самым укрепляясь в своем мнении.


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

                                  Отлично :) Надеюсь, что если устроите, то опубликуете результаты!


                                  Мы думаем в сторону того, чтобы дать подсмотреть «по кнопке» несколько тестов. Большинство тестов всё равно довольно объемные и их открытие вряд ли сильно поможет.

                                  Если тесты объемные, то странно, что вы боялись "подгона под ответ"…
                                  Вообще же даже объемные можно предлагать скачать как файл, например, чтобы студент мог локально потестить, было бы желание.


                                  Спасибо, что участвуете в обсуждении и предлагаете варианты, нам это важно.

                                  Пожалуйста :)

                            +1

                            Но получается, что тут смешивается 2 вектора: научить алгоритмам и научить тестированию, отладке, дебагу кода. Надо и то и то, но это разные курсы могут быть. Тестирование вообще является отдельным направлением зачастую.

                              +2
                              Тестирование или/и доказательство корректности алгоритма является неотъемлемой частью решения алгоритмической задачи.
                              Всё-таки, в алгоритмических задачах тестирование «на минималках»: тут нет ни внешних сервисов, ни некорректных данных, ни многих других проблема реальной разработки.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            +2

                            Всё равно приятно, когда компании не подают в суд за клевету (не подали же вроде?), а идут на диалог и что-то меняют.

                            +3

                            Я бы точно не стал покупать у вас этот практикум, зная, что тесты скрыты. Одно дело когда ты студент, готовишься к ICMP, у тебя горят глаза, и тебе важно прокачать "чуйку". И совсем другое дело, когда времени в обрез, дедлайны, учишь языки, отвозишь ребёнка в школу и назад и т.д… В этом случае ты покупаешь подписку на литкод не для того, чтобы "прокачать чуйку", а чтобы быстро закрыть наиболее ключевые дырки и пойти проходить собес в FAANG. И вот спрашивается на кой чёрт мне эти ваши многочасовые выискивания того, что я, оказывается, забыл обработать какой-то хитрый кейс с переполнением, с -1, или сочетанием более редких факторов. Это ведь всё ещё и за деньги. В общем noway.


                            То что эти "хитрые кейсы" многочасовые я знаю доподлинно. В бытность студентом я мнооого времени потратил, пытаясь понять, какой же такой кейс я не покрыл. Думаю КПД этого времени было в р-не 5-10%. Всё равно спустя 10 лет я нахожу баги совсем не тем способом, которым пытался найти их тогда.


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

                              +3
                              Вы поняли, что наш курс не для вас, и это круто.
                              Он действительно подходит не всем, к нам стоит идти за навыком (или чуйкой, как вы говорите).
                              +6

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

                                +5
                                Да, это разумное предложение, видим, что многим этого не хватает, обязательно это обдумаем. Спасибо!
                                0
                                Я сам проходил множество курсов и делал свои. В вопросе открывать или скрывать тесты есть «Соломоново решение». Все типовые тесты должны быть публичны. Все скрытые тесты должны быть аналогичны публичным (но значения должны отличаться, чтобы не было подгона под точные значения из публичных тестов).
                                Отдельные задачи «на смекалку» могут иметь нетиповые скрытые тесты, но надо сразу готовиться, что учащихся будет «бомбить» и в задаче эта «подстава» должна быть как-то обоснована.

                                Иногда тест нельзя сделать публичным потому, что он просто «не влезет» (например, проверка на какие-то свойства очень больших чисел, там важно эффективно использовать память и время, но они и на экран могут не влезть). Надо в таком случае дать возможность или «скачать» тестовые данные, либо объяснить как их сконструировать самостоятельно.
                                  +3
                                  Спасибо, что делитесь опытом!
                                  Да, видимо нам стоит как-то в эту сторону двигаться, учиться показывать часть тестов.
                                    +1
                                    А это очень крутая идея: публичные «лёгкие» тесты, и скрытые «тяжёлые» на то же самое, но с другим набором данных, чтобы было не подогнать. И публичные прямо в виде готовом к импорту публиковать :)

                                    P.S. А вы не думали для Тренажёра и Контеста написать плагины для популярных IDEшек, как например один ресурс по обучению Java сделал с IntelliIDEJ — то есть решаются задачи с сайта, но в IDE.
                                  0
                                  Как интересно!!! А вот ODS просто, тупо выложили курс по DS на Хабре и чет даже денег ни с кого не спросили. А вместо тестирующей системы у них были обычные гугл-формы :) И дело даже не в качестве курсов, а в самом мотиве людей — кто-то хочет внести свой вклад в развитие сообщества (общества), а кто-то хочет срубить бабла. Разница примерно такая же как между филантропией и мизантропией :) Именно это и бесит людей.

                                  Слабо, просто, в стиле ODS замутить и выложить какой-нибудь бесплатный курс на Хабр? С точно такой же проверяющей системой в гугл… яндекс-формах :)

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое