Здравствуйте, Erop, Вы писали:

НС>>Ни в каком случае этот код не есть правильный.
E>Это очень сложный вопрос.

В данном случае это простой вопрос.

E>Вот, например, давай я задам тебе похожую, но другую задачу?

Зачем?

E>Есть твой список и надо его на месте отсортировать...

Это существенно сложнее. С таким на собеседовании уже 99% не справятся.

E>Я бы вот принял и правильное решение в духе, делаем массив ссылок, сортируем, потом делаем из него список, и в духе сортируем на месте сляиниями, например. А ты?..

А я не люблю доказательства по аналогии.

E>>>А разворот списка на месте -- неготовая к исключениям и непотокобезопасная преждевременная оптимизация таки...
НС>>Это не оптимизация, а при чем тут потокобезопасность вообще непонятно.
E>Ну, как бы вот представь, что на предыдущем собеседовании нормального кандидата завернули на том, что он пишет непотокобезопасно, например...

Зачем мне это представлять? Ты пытаешься довести до абсурда, но цель этого непонятна.

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Безопасным относительно чего? Сам по себе метод вполне безопасен, так как не использует внешнее состояние совсем.

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

НС>Какой такой задачи? О чем ты?
Твоей, про "перевернуть на месте"..


НС>Правильный ответ, он не только сильно лучше по процессору и памяти, он еще и самый простой.
По процессору он лучше раза в два примерно по памяти да, но не понятно дорого ли это.
Про "самый простой" не согласен.

Проведи два теста.
1) Посмотри насколько низкий уровень требуется что бы породить/понять "правильный" и "неправильный"
2) Давай нам надо мнемного модифицировать задание? Пусть перевернуть порядок следования надо не у всех элементов, а только у каждого второго, или не более, чем у первых 10... Какой из вариантов кода легче модифицировать?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ничего подобного я не жду. Я жду другого — умения работать со ссылками, я это уже миллион раз в топике написал. На эффективность мне, вобщем то, плевать. Единственная причина, почему пишут тот код, что я привел выше, это то что человек не может или не умеет с этими ссылками работать.

Как ты проверял это утверждение?

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

НС>Обоснуй.

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

Я уже предложил рассмотреть варианты модификации того и другог кода в будующем, ну если вдруг понадобится немного поменять поведение

E>>Кстати обе обсуждаемые версии простые и понятные, так, которая вам не нравится, даже понятнее, IMHO...

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

Здравствуйте, Ночной Смотрящий, Вы писали:

E>>Вот, например, давай я задам тебе похожую, но другую задачу?
НС>Зачем?

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

E>>Есть твой список и надо его на месте отсортировать...
НС>Это существенно сложнее. С таким на собеседовании уже 99% не справятся.

Ну вот ты справишься, например? Хотя бы неприятным тебе способом?..
если да, то таки тот способ проще и технологичнее и масштабируется, в отличии от твоего "правильного"...

E>>Я бы вот принял и правильное решение в духе, делаем массив ссылок, сортируем, потом делаем из него список, и в духе сортируем на месте сляиниями, например. А ты?..

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

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


НС>Зачем мне это представлять? Ты пытаешься довести до абсурда, но цель этого непонятна.

Я указал на два, на мой взгялд, неверных у тебя предположения.
1) Что код с промежуточным массивом однозначно хуже.
2) Что задавая соискателю вопросы надо скрывать от него чего мы от него ждём.

и пытаюсь их тебе обосновать.

Здравствуйте, Erop, Вы писали:


I>>Кто тебе такое сказал ?
E>Ну то решение, которое не нравится НС, если его сделать более или менее по уму, оно всего в два раза медленнее + одна-две аллокации под буфер массива, что на GC полная фигня, как бы...

Отвечу отдельным тредом, а то я устал уже.

Здравствуйте, Erop, Вы писали:

E>на другой хадаче ты сможешь рассуждать с чистого листа и тебе легче будет быть объективным...

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

E>>>Есть твой список и надо его на месте отсортировать...
НС>>Это существенно сложнее. С таким на собеседовании уже 99% не справятся.
E>Ну вот ты справишься, например?

Справлюсь. Дальше то что?

E> Хотя бы неприятным тебе способом?..

У меня нет неприятных способов.

E>если да, то таки тот способ проще и технологичнее и масштабируется, в отличии от твоего "правильного"...

Какой тот?

НС>>А я не люблю доказательства по аналогии.
E>При чём тут аналогии?

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

E>Я в целом не люблю вопросы-ловушки

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

E>Если бы ты сразу просил типа без доп. памяти

А с чего ты взял, что не просят? Я где то такое писал?

E>, и каждую ссылку менять можно тока один раз

Этого требования вообще нет.

E>1) Что код с промежуточным массивом однозначно хуже.

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

E>2) Что задавая соискателю вопросы надо скрывать от него чего мы от него ждём.

Опять ты со своими фантазиями споришь. Никто ничего не скрывает.

Здравствуйте, Erop, Вы писали:

E>Как ты проверял это утверждение?

По коду это хорошо видно.

E>>>Второе значительно дороже в разработке, а часто ещё и в поддержке...
НС>>Обоснуй.
E>Ну "думать" вообщедорого.

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

>Это всё непосредственно дороже в баксах в час, и в часах, часто, тоже.

Дороже, это когда куча наколбашенного кода плодит стадо багов, а отрефакторить все это гавно крайне тяжело.

E>Я уже предложил рассмотреть варианты модификации того и другог кода в будующем, ну если вдруг понадобится немного поменять поведение

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

E>>>Кстати обе обсуждаемые версии простые и понятные, так, которая вам не нравится, даже понятнее, IMHO...
НС>>Обоснуй.
E>Ну так ты сам считаешь, что уровень программиста для понимания нужен ниже, значит код проще...

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

Здравствуйте, Erop, Вы писали:

НС>>Безопасным относительно чего? Сам по себе метод вполне безопасен, так как не использует внешнее состояние совсем.
E>относительно многопоточного окружения. Пока ты там крутишь свой разобранный список из другого потока его могут попробовать почитать...

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

НС>>Правильный ответ, он не только сильно лучше по процессору и памяти, он еще и самый простой.
E>По процессору он лучше раза в два примерно по памяти да, но не понятно дорого ли это.
E> Про "самый простой" не согласен.

Ну приведи метрику, по которой он окажется сложнее.

E>1) Посмотри насколько низкий уровень требуется что бы породить/понять "правильный" и "неправильный"

А с какого это перепугу мы стали простоту кода мерять возможностью его написания безграмотным "программистом"? Нормальный LL парсер у тебя тоже сложнее, чем ручной разбор без какой либо методики, потому что первый человек с первого раза скорее всего написать не догадается? А код, который из сиквела выбирает лишние данные, потому что человек джойнами не умеет пользоваться, он тоже проще? А ручная десериализация XML, потому что человек никогда не слышал про XmlSerializer или Linq2Xml? А рукопашный контроль структуры XML, потому что моска не хватило со схемами разобраться? Или вон, как Шеридан, ниасил xslt и наворотил шаблонов на базе string.Format. С твоей логикой очень далеко можно зайти.

E>2) Давай нам надо мнемного модифицировать задание?

Нет, не давай. Доказательства по аналогии идут в сад, потому что таким способом можно доказать что угодно.

Здравствуйте, Vzhyk, Вы писали:

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

Предложи тогда более толковый способ, нежели задачи.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

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


E>> Хотя бы неприятным тебе способом?..
НС>У меня нет неприятных способов.

В смысле?
"приятным" я назвал сортировать тупо на месте, "неприятным" сортировать в массиве ссылок, а потом писать обратно в ноды.

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

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

НС>А с чего ты взял, что не просят? Я где то такое писал?
Если так и просят, то нормальная задача. А ты писал просто НЕПОНЯТНО, про то, что ни в коем случае нельзя упомянул кто-то другой.

А если просите без доп. памяти, то зачем народ сдаёт решение с массивом? От безисходности что ли?

НС>Да, он однозначно хуже. И другая задача в этом плане ничего не доказывает.
Ну вот такой простой параметр, как лёгкость модификации, как оценишь, без рассматривания что изменится в коде, если поменются немного условия?

НС>Опять ты со своими фантазиями споришь. Никто ничего не скрывает.
Если не скрываешь, то нормально.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>Это совсем совсем другой скилл, и его надо совсем другими задачками и вопросами проверять.
Я вот чего не понимаю, если у тебя в задании есть требование не использовать доп. память, то это полностью делает неверным ответ с массивом, так как это ответ на ДРУГОЙ вопрос.

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

НС>Нет, не значит. Иммутабельный код, к примеру, обычно проще и надежнее кода с инвариантами, но неумелые программисты, если у них нет нужного бекграунда, пишут именно инварианты. Еще один пример — парсеры правильно пишут только те, кто хотя бы немного знаком с темой, а остальные 99% без профильного образования пишут страшных каракатиц, мутных и падучих, при том что с другими задачками они худо-бедно справляются.

Но понять тоже проще тот, что с массивом, и, главное, его проще менять...

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

Здравствуйте, Ночной Смотрящий, Вы писали:

E>>2) Давай нам надо мнемного модифицировать задание?
НС>Нет, не давай. Доказательства по аналогии идут в сад, потому что таким способом можно доказать что угодно.

Это у тебя невроз такой, да? Аллергия на аналогии?

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

Здравствуйте, Erop, Вы писали:

НС>>Ты, кажется, не понял — такая задача подобрана специально, на другой задаче все по другому.
E>Это ты не понял, что кроме оценки кода, много там лишнего или мало, есть и другие метрики, например его технологичность и стандартность...

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

E>>> Хотя бы неприятным тебе способом?..
НС>>У меня нет неприятных способов.
E>В смысле?

Что тебе непонятно в простом предложении?

E>"приятным" я назвал сортировать тупо на месте, "неприятным" сортировать в массиве ссылок, а потом писать обратно в ноды.

Ты написал "неприятным тебе" способом, а что ты там у себя называешь мне лично все равно.

E>А демонстрация нифига не прямая

Придумай прямее.

E>, если ты прямо не просишь без лишней памяти...

То есть продолжаешь спорить со своими фантазиями?

E>А ты писал просто НЕПОНЯТНО

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

E>А если просите без доп. памяти, то зачем народ сдаёт решение с массивом? От безисходности что ли?

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

НС>>Да, он однозначно хуже. И другая задача в этом плане ничего не доказывает.
E>Ну вот такой простой параметр, как лёгкость модификации, как оценишь

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

Здравствуйте, Erop, Вы писали:

НС>>Дороже, это когда куча наколбашенного кода плодит стадо багов, а отрефакторить все это гавно крайне тяжело.
E>Ну и какие проблемы плодит код обращения списка через массив?

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

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

Можно цитату где я подобное делаю?

E>, а как просто "код, который хуже", так вот, по критерию "проще модифицировать" он, как раз, лучше, а не хуже...

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

НС>>Нет, не значит. Иммутабельный код, к примеру, обычно проще и надежнее кода с инвариантами, но неумелые программисты, если у них нет нужного бекграунда, пишут именно инварианты. Еще один пример — парсеры правильно пишут только те, кто хотя бы немного знаком с темой, а остальные 99% без профильного образования пишут страшных каракатиц, мутных и падучих, при том что с другими задачками они худо-бедно справляются.

E>Но понять тоже проще тот, что с массивом, и, главное, его проще менять...

Нет, не проще понять и не проще менять. Понишь каким образом я тебе описал, почему твои объекты-механизмы не самый удачный дизайн? Вот попробуй в таком же духе объяснить, почему неправильный вариант проще модифицировать. Там меньше зависимостей? Там выше связность кода? Там меньше контракты? Там меньше внутренних связей? Меньше функциональных точек? Меньше цикломатическая сложность? Назови хотя бы одну объективную метрику или принцип дизайна, под который подходит неправильный вариант, и не подходит правильный.

E>Либо он не понял твоего вопроса.

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

Здравствуйте, Erop, Вы писали:

E>Это у тебя невроз такой, да? Аллергия на аналогии?

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

E>Ты просил метрику простоты кода? Ну так вот, простой код просто модифицировать.

ДОКАЖИ.

E> Так что смотрим насколько просто модифицировать тот и другой код

А если надо не сортировку добавить, а просто изменить способ получения ссылки Next? В каком из вариантов больше изменений будет, а?

Здравствуйте, Ночной Смотрящий, Вы писали:

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

Демогогия -- это то, что ты тут пишешь.
Если в твоей задаче есть В УСЛОВИИ требование не использовать доп. память, то ответ с массивом НЕ ВЕРНЫЙ по ФОРМАЛЬНЫМ причинам.

НС>Ну да, и вместо того чтобы прямо спросить о том что ты не понял ты начал что то фантазировать и на основании этих фантазий спорить.

Я вообще никак не оценивал твои собеседования. Я оспариваю то, что код с массивом -- плохой. Он просто написан исходя из другой системы ценностей. Он не является решением твоей задачи и мне странно, что ты не упомянул это, когда приводил его...

НС>Да потому что не может по другому.
Тогда, конечно, это не ваши кандидаты.

НС>Никак. Это задача не на легкость модификации, она, как минимум, слишком маленькая для оценки этого. Ты же, надеюсь, еще помнишь, что здесь обсуждается именно конкретная задача, а не что то еще?

Я оспариваю твоё утверждение, что один код переупорядочивый односвязанный список хуже другого.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Я вот, честно, уже не знаю как с тобой разговаривать.
Не знаешь, ка кразговаривать? -- Не разговаривай

НС>Никаких проблем он не плодит, он вообще имеет довольно опосредованное отношение к коду реальному.
Ты сам там вот на пару сообщений выше написал, что типа код с массивами плохой, потому, что программировать так, типа шаблонно вообще плохо, так как потом это породит кучу проблем и тружно будет отрефакторить.
Я же ничего ен перепутал?
ну вот мне и инетерсно понять, какие проблемы может по твоему породить этот код и почему его трудно отрефакторить?


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

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

Здравствуйте, Erop, Вы писали:

E>Если в твоей задаче есть В УСЛОВИИ требование не использовать доп. память, то ответ с массивом НЕ ВЕРНЫЙ по ФОРМАЛЬНЫМ причинам.

Меня формальные причины не особо интересуют.

E>Я вообще никак не оценивал твои собеседования. Я оспариваю то, что код с массивом -- плохой.

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

E> Он просто написан исходя из другой системы ценностей. Он не является решением твоей задачи и мне странно, что ты не упомянул это, когда приводил его...

Я его и привел как пример неверного решения. С кем ты споришь?

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

НС>>Никак. Это задача не на легкость модификации, она, как минимум, слишком маленькая для оценки этого. Ты же, надеюсь, еще помнишь, что здесь обсуждается именно конкретная задача, а не что то еще?
E>Я оспариваю твоё утверждение, что один код переупорядочивый односвязанный список хуже другого.
E>

В контексте этой задачи он таки хуже.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нет. Просто единственный конструктивный способ продолжения разговора после применения подобных приемов. А ты ожидал, что я будут с твоими аналогиями спорить? Фик тебе.

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

НС>А если надо не сортировку добавить, а просто изменить способ получения ссылки Next? В каком из вариантов больше изменений будет, а?

Одинаково, вообще-то...
Зачем второй раз итерировать список, если есть верно упорядоченный массив?..

Здравствуйте, Erop, Вы писали:

НС>>Никаких проблем он не плодит, он вообще имеет довольно опосредованное отношение к коду реальному.
E>Ты сам там вот на пару сообщений выше написал, что типа код с массивами плохой, потому, что программировать так, типа шаблонно вообще плохо

Попробуй найти в моих сообщениях хотя бы одно использование слова "шаблонный". Может хватит уже придумывать за меня мои слова?

E>, так как потом это породит кучу проблем и тружно будет отрефакторить.
E>Я же ничего ен перепутал?

Да ничего, кроме того что я ничего подобного не писал.

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

Это так.

E>, они хороши с разных точек зрения просто.

Второй кусок плох с любой точки зрения. В контексте данной конкретной задачи.

E> Это вообще никак не свящано с тем, что ты как-то издеваешься или там ещё что делаешь с соискателями

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