Как стать автором
Обновить

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

Если вы даете задание вида "сделать N и M", а потом начинаете смотреть на качество кода — вы сами себе злобные буратины, что тут можно сказать.
Потому что "жадным" способом практически любое задание можно делать если не бесконечно, то по крайней мере очень долго, и если у меня будут хоть малейшие подозрения, что контора хочет от меня выполнения тестового задания по принципу "всё включено" — то я его просто сразу не буду делать, т.к. это заведомо выйдет за количество времени, которое я в принципе готов потратить на тестовое задание.
Если тестовое задание сформулировано как "сделать вот такое", то и проверяться должно ровно это — сделано ли. Проверяете качество кода — пишите об этом в условия в явном виде.

Можно и без оверинжиниринга сделать нормально, там где надо вынести в сервисы, там где не надо не плодить лишних модулей, хорошо продумать структуру и назвать модули/перменные/директивы, а вот если бы мне прислали раздутый пример на миллион модулей в простом задании - наоборот забраковал бы.

Например когда давал простое тестовое джунам на пару часов максимум, я не ждал от них кода как в статье, а ждал хотя-бы использования async pipe вместо .subscribe(value => this.value = value); но джуны как раз раздували структуру на миллион модулей вместо такой простой вещи как async pipe)

Это да. Но из списка замечаний в статье у меня не сложилось впечатления, что автор смотрел на "сделать нормально" в рамках задания. А скорее на "сделать нормально" в разрезе "представим, что вот нам надо такой сайт под ключ". Что будет крайне сильно раздувать реально затраченное на задание время.

Так я и не говорил, что автор прав)

Мне недавно прислали на ревью результат такой. Можно написать программу на node за 40 строк, но написано два репозитория с фронтом и беком, 60 dependencies и где то 3к строк кода.

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

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

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

Качество кода — это именно то, что можно и нужно подразумевать как включенное по умолчанию.

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


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


Нет порядка в privite/public свойствах

и у него может быть (субъективно) очень обоснованное мнение о том, почему это важно. Но важно ли это для проекта и конторы в целом?

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

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

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

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

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

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


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


PS: Я, если что, вовсе не имел в виду, что список критериев для оценки надо включать в задание as is. Я говорил о том, что в условиях задания должно быть явно указано, что качество кода оцениваться будет (или нет).

Мог бы - лайкнул бы )

Честно говоря вообще не понял аргументацию автора.

Главный аргумент насколько я понял "что разработчик потащит огромный пласт своих "готовых/проверенных" решений, которые в свою очередь могут слишком усложнить проект, который не будет завершен ".
Эм, если разработчик не может удержаться от того что бы тащить готовые блоки и из-за этого в итоге не может в разумных срок закончить (sic!) задание, то какой он вообще сеньёр? В моём понимании старший разработчик это разработчик, одним из ключевых качеств которого является умение выбирать инструменты и архитектуру адекватно задаче (а это кстати вытекает из главного качества сеньёра (ИМХО) - работать самостоятельно).

Фразу про "не делаю для РФ" не понял. Какая разница РФ/не РФ?

Что вы такое курите что бы в отзыве про код писать:

нет вау эффекта

Забавно, если если с такой формулировкой могут развернуть на код ревью)

Я так понимаю, этому человеку все равно кого собеседовать - разработчиков или проституток, фразы примерно одни ).

Ожидать вау эффекта от тестового на "3-6 часов" это интересно какого уровня специалиста надо искать, да

Он есть. У автора от самого себя.

Где же он есть то? Если автор сам писал это задание несколько недель.

но иногда он таки бывает же. его и ждем...

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

Ввести критерии приемки для результата. Да ладно ?! А что мешает их сразу указывать? Для middle и выше должно быть на уровне рефлекса проверить наличие «Definition of Done»\ «Acceptance Criteria» для Task. А тут создают Задание без этих критериев и удивляются результату:
но шанс, что он его выполнит или выполнит его так, как вы бы этого хотели минимален.

Практически шаблонный ответ «Мы ожидали другого». Чего «другого»? ХЗ.
Он не зависит от того спросил ты или нет «как сделать? 'правильно' со всеми 'наворотами в зоопарке' или 'концепта' достаточно ?» После пары тройки таких ответов, я зарекся делать даже за деньги.
Качество кода — это именно то, что можно и нужно подразумевать как включенное по умолчанию.

Качество кода регламентируется требованиями к разработке решения и его архитектуре и декларируется хотя бы на уровне «Code style» документа, регламентируя правила именования классов-переменных-интерфейсов-аргументов-...\скобочки\отступы\табы\порядок private-public\инициализации переменных и прочее и проверяется инструментально в первую очередь. Какой шанс, что у кандидата стиль будет совпадать с принятым для проекта на 100%? не большой
Посмотреть какой у человека базовый уровень качества по умолчанию и насколько он приемлем. Потому что если он неприемлемо низок, то потом ежедневно вытягивать его из-под палки

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

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

Хотя конечно то о чем вы говорите - совершенно верно.

Но проверить это линтером невозможно.

для Visual Studio 201x писал валидаторы кода для C#. Пришлось под собственные правила клиента дописывать, поскольку стандартных не хватало.

Наглядное пример того, что составители тестовых заданий "на пару часов", сами никогда не пытались из сделать за отведенное время.

Тот кто говорит, что это проще чем отнять конфетку у младенца, никогда не пробовал отнять конфетку у младенца ;) (с)

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

Конечно не знают. Откуда бы такое знание иметь?

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

В моем опыте собеседующего было слишком много кандидатов, которые д'Артаньяны в теоретической части (лидил команду в 10 человек, настроил CI/CD, всё модульное и идеально протестированное). А стоит такому дать простую задачку написать два UI компонента и продумать их API, чтобы гибко и тестируемо, и он моментально скисает.

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

все-равно иногда появляется разработчик, который 50/50 и непонятно что с ним делать

50/50 - прям как в том анекдоте про дракона и блондинку? А если серьезно - если после часового собеседования у вас непонятно, что с ним делать - то проблема именно в собеседующем. Попробуйте проанализировать ваш подход к собеседованию и сделайте работу над ошибками.

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

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

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

Я имел в виду как раз наоборот: представьте, что нужно принять на работу человека, который впоследствии будет проводить собеседования. Так вместо того, чтобы его самого собеседовать, выдать ему несколько тестовых заданий кандидатов, которых он прособеседует. И потом у кандидатов спросить - насколько качественно их проинтервьюировали, спросили-ли всё, что должны были спросить, насколько верно оценили их слабы и сильные стороны и т.п.
То есть, провести собеседование, но оценить не кандидата, а интервьюера.

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

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

Тестовое задание для собеседующего это собственно собеседования :) Если те кого он рекомендует потом хорошо работают, значит справляется :)
Так тут и было понятно по статье дальше: автор попытался выполнить своё тестовое задание, а в итоге «пара недель по 2-3 часа перед сном», и то задание не выполнено в нужном ключе, что говорит о не совсем адекватном соответствии его, как ревьювера, и того, кто выполняет тз…
Лично у меня, после прочтения, сложилось впечатление, что автор «начал за здравие, а закончил за упокой»…

Мне особенно понравилось "Нет работы с таймзонами" для задания на "3-6 часов".

Такое, чувство, что автор очень сильно хотел до-кхм-кхм-аться до кандидата.

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

Вероятно нам дали очень урезаннье описание тз, в статье вообще про 4 формочки, я подумал, что просто текст сохранить и редактировать. Что-то вроде Heroes App из офф туториала.

Хочу тут еще заметить, что 3 и 6 часов - это таки разница в два раза. Что вполне может отделять мидла от сеньора. А может и ввести в заблуждение, если мидл что-то подобное недавно делал и только пыль стряхнул с того решения и причесал чутка.

А я не понимаю всей этой неприязни к небольшим тестовым заданиям. Конечно это должен быть не первый этап. И ещё большее непонимание у меня вызывает претензии по поводу того что будут проверять качество кода. Это нормально. Как уже отметили выше, код нужно по умолчанию писать нормально, а для тестового задания тем более.
Если тестовое задание — чистое зло, то как нужно нанимать программистов(речь в первую очередь про Junior и middle уровень)?

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


А я не понимаю всей этой неприязни к небольшим тестовым заданиям.

В статье выше не про "небольшие" задания, а про 3-6 часов с последующим фидбэком "нет вау-эффекта" (или, из "существенных недостатков" — "нет ленивой загрузки" и "в 480px верстка не алё").

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

Какие "подобные"? Fizzbuzz? Если человек "в условиях стресса" не может написать 10 строк кода, то что с ним потом делать, если он пойдет в магазин, а ему там нагрубят? Неделю не сможет код писать?

А что вы хотите увидеть по реализации fizzbuzz? Какие критерии? Мне кажется самые наивные решения вообще не показательны в плане качества кода. А что то такое займёт уже не 10 минут.
Какие критерии?

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

Мне лично проще на собеседовании покодить 10-15 минут в какой-нибудь онлайн-IDE, нежели тратить 3 часа (а скорее всего и все 6) личного времени на написание некоей ненужной ерунды. Три часа можно потратить более продуктивно и приятно.

Жизнь коротка.

Всё правильно говорите. Только один нюанс — тестовое задание нужно не вам, а работодателю. И нравится оно вам не должно.
Что можно узнать за 10-15 минут в онлайн IDE на задачах по типу fizzbuzz? Исключим прям неординарные случаи. Допустим это собеседование на мидл. Думаю можно узнать знаком ли человек хоть немного с синтаксисом языка. Алгоритмы какие то наверно можно проверить. Можно даже какие то каверзные вопросы позадавать на знание нюансов. Всё? А ищут то кого? Наверняка ведь в 99% случаев работа будет связана не с написанием алгоритмов на brainfuck, а с использованием уже готовых библиотек и методологий. Кроме того хочется чтобы человек умел пользоваться инструментами типичными для позиции(тот же webpack или docker).
Наверняка ведь в 99% случаев работа будет связана не с написанием алгоритмов на brainfuck, а с использованием уже готовых библиотек и методологий.

Чтоб применять готовые библиотеки и методологии — способность писать код всё еще нужна. Не была бы нужна — вас бы уже не брали на работу, вместо вас бы работала нейросеточка.


Кроме того хочется чтобы человек умел пользоваться инструментами типичными для позиции(тот же webpack или docker).

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

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

Лирическое отступление: да я вообще не понимаю, чего они там проверяют на интервью. У меня 13 лет опыта веб-разработки, и у меня спрашивают, знаю ли я что такое скрам/аджайл и что такое замыкание. Нет, знаете ли, я последние 20 лет жил в лесу и не знаю, что такое скрам! И всю мою карьеру мне как-то удавалось скрывать непонимание того, как работают замыкания в JS, но вот вы меня наконец разоблачили!

Если собеседование на миддла, то можно похвастаться гитхабом. А уж если его нет, ну вот тогда только тестовое, да.

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

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

Про понимание основных механик — согласен, я не зря упомянул про альтернативные инструменты. Если человек про них знает, значит, задумывался, зачем это всё и нельзя ли как-то получше. Но в тестовом задании это не выявишь, потому что времени всего 3 часа и ты возьмёшь просто готовый конфиг:)

по-моему в большинстве случаев видно понимает ли человек конфиг или какой то готовый взял и даже лишнее не поудалял

Согласен — при вышеобговоренных условиях:)

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

Только один нюанс — тестовое задание нужно не вам, а работодателю. И нравится оно вам не должно.

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

Мне трудно говорить про свой опыт, так как я думаю я просто высоко оплачиваемый junior

Забавно что в подписи у Вас стоит Senior Front-end Developer

Иногда люди проговаривают на правду )

Я же обычно пишу ревью на тестовые задания

И однажды делая ревью на тестовое задание кандидата, я написал вот такой фидбек

Я запутался. Так вы фидбек пишете или ревью? Или ивалюэйшн? Или может быть асессмент? Этот момент нужно прояснить.

Согласен, браза, крайне импотантли андестендить, что ты райтишь - фидбек или ревью. Абсолютли.

Не понятно кого можно найти, читая всю эту писанину.

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

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

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

Ну, а если речь про архитектуру фронта, то ему до фонаря все эти ваши операторы, которые вы тут смакуете.

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

Ну вот ещё и удивляются что разработчики хороводы водят по собесам 1-2 раза в месяц в пассивном поиске, по вакансиям залетающим от HR. То тестовые по 6 часов, то анаграммы решать и строку со скобками, то гитхаб должен быть заполнен проектами. Даже чисто логически не должно быть у каждого разработчика своего проекта на Гите, не нужно миру столько софта. Получается, что идеальный кандидат это вчерашний школьник, запиливший никому ненужный Todo лист на MERN стеке, заучивший типовые задачки и не обременённый хобби и друзьями, чтоб 6 часов тратить на недо-airbnb тестовые.

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

На настройку окружения ушло около часа, осталось еще 3.

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

Но в новом проекте этого нет, и что делать с этим не понятно. Я решил перетаскивать по мере необходимости.

И второй не заметили - невозможность просто использовать решения из других проектов без перетаскивания.

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

Для сравнения, это приложение было реализовано за 2 часа: notes.hyoo.ru

Если вы реально 2 часа писали приложение, только чтобы ответить этим комментарием, то снимаю шляпу, моё уважение

Уважать меня не за что - приложение написано пару лет назад.

Еще раз прочитав я подумал, что это можно сделать за пару часов (или дней).

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

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


То есть начали одну задачу, обозначили сроки, нарушили, сделали другое. А что с изначальной задачей? Как решили?

Статья про то как потратить 3 месяца (если судить по github) на тестовое задание вместо 3-6 часов.

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

Если человек не использует Redux - это не минус, по мне так плюс. В Ангуляре нативно его нет и он там там нахрен не нужен, использует только тот кто по реакту скучает. ИМХО.

А если есть возможность не использовать ChangeDetection - это вообще прекрасно. Ангуляр сам прекрасно это делает, если объекты правильно строить и использовать.

Знаете. Пока я читал статью, и мне пришла мысль о том, как отвечать на предложение сделать тестовое задание.
— Его выполнение должно занимать несколько часов (опционально как договоритесь, но я больше чем на 4 не подпишусь).
— Все критерии приёмки прописаны в ТЗ.
— После его выполнения вы мне дадите ссылку на репозиторий, где лежит выполненое вашим сотрудником тестовое, которое отвечает всем требованиям. И по коммитам видно, что оно было выполнено за указанное время.
Некотрое время назад делал тестовое задание, в задании написано «Не надо доводить до идеала и тратить неделю, главное чтоб функционалу соответствовало», я спустя неделю за пару часов сделал, функционалу соответсвтует, может быть с чистотой кода не все в порядке, но я подумал, что если буду править это, то пройдет еще несколько недель. В итоге зарубили за плохую архитектуру, в качестве примера хорошего задания привели репу, в которой человек больше недели делал несколько коммитов в день. Оно конечно выполнено лучше моего, но когда в задании пишут одно, а по факту проверяют другое… Сразу бы писали, на что смотрят, глядишь и выделил бы время.

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

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