Здравствуйте, Undying, Вы писали:
НС>>Этим гугль не поможет, они и рабочий код будут писать по принципу "фигли тут думать, трясти надо". U>Какая задача такой и ответ.
Задача — нормальная.
U> В условии хоть указываете, что решение должно быть максимально оптимизировано?
Что значит максимально оптимизировано? У того кода, что я написал — у него есть хоть в чем то преимущество перед нормальным решением?
Тут видишь ли какое дело — всегда ведь можно спросить, почему сделано так а не иначе. И если какой то код окажется менее оптимальным, но, к примеру, короче и проще, это можно обсудить. Но когда приводится вариант, который хуже по всем параметрам, то я не вижу ни одного оправдания такого.
Это один момент. А второй — мы не ищем людей, которые должны лопатить от забора до обеда по строгому ТЗ. У нас даже менее опытным программистам задачка дается в стиле "решить такую то проблему". Если проблема сложная, я еще могу накидать какой то предварительный дизайн и указать на принципиальные моменты, а если там нет каких то особых челленджей, то этим все и заканчивается, дальше надо применять активно свой моск. Единственное где тут можно сэкономить — составить список конкретных вопросов по функционалу и нефункциональным требованиям и отдать список аналитику.
В таком разрезе человек, которому надо даже для такой примитивной задачи явно указывать на то, что кривой код писать не надо, нам не нужен. Так что пускай он идет куда нибудь в другое место рассказывать про ужасные задачи на собеседовании, авось где нибудь на допиливание готовых платформ типа 1С или шерпоинта пригодится.
Но это все совсем совсем другой уровень, нежели решение примитивных задачек.
Здравствуйте, Undying, Вы писали:
U>Кстати, даже если у вас условия задачи определяются тараканами заказчика, то на выяснение этих тараканов у специально обученных людей уходят многие дни.
О, это отдельный скилл, тоже важный начиная с определенного уровня разработчика. Но тут уже от конкретной фирмы зависит. Как то довольно давно я был на собеседовании в одной известной конторе, мне задали вопрос в стиле "спроектируйте ка дизайн вот под такую задачку", видимо ожидая некий более менее стандартный ответ сразу. И когда я начал фиксировать нефункциональные требования (необходимость расширяемости, временные и бюджетные рамки, предполагаемое время жизни проекта и т.п.) это их поставило в тупик, потому что в эту сторону они даже не думали.
А весь этот флейм в основном раздувается некоторыми товарищами, которые пытаются придумать причину почему эти 9 значащих строк ну никак невозможно на собеседовании написать без гугла и спецподготовки.
Здравствуйте, Undying, Вы писали:
U>Я, например, прекрасно понимаю структуры данных. При этом если бы на форуме не тусовался об односвязном списке не знал бы ничего.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Если надо писать пару раз в неделю, что 100% это есть в гугле.
G>>Когда знаешь что гуглить, да. Но мы специально подобрали задачу, чтобы в одном месте не гуглилась. Надо именно понимать чтобы такое написать. I>Практически все как с реверсом списка, только он сам по себе избитая задача и гуглится.
Задача не алгоритмическая. Нужно знать 3 класса, 4 функции и понимать как они работают. Все эти функции обычно программисты пишут каждый день. В интернетах все есть.
Но вот люди невнимательно читают и часто не понимают почему пишут именно так.
I>Пудозреваю, если другие конторы начнут задавать такие же задачи, как у тебя, решений будет валом в интернете.
Не-а. На русском про SharePoint пишут человек пять. Один уехал, одн работает со мной, а еще двое были на собеседовании.
G>>Ели человек не понимает этих вещей, то нам не подходит. I>Правильно,и с реверсом тоже самое — нет решения, не подходит.
Не правильно, разворот списка не имеет отношения к реальной программе.
Почему например людей не фильтруют по незнанию преобразования числа в строку?
Или по итеративному вычислению квадратного корня?
G>>Причем это не абстрактные знания, которые никогда могут не пригодиться. Эти знания пригождаются почти каждый день. I>Это типовые задачи. Все что ты прверишь — умение решать типовые задачи. Это умение ни о чем.
Я же писал, что 80% задач на работе — типовые. Это у всех. Более того, люди сами стремятся так работать — сводить все к типовым задачам. Ибо так мозг меньше напрягается.
I>>>Задача близка и задачу надо решь пару раз в неделю это вещи мягко говоря разные. G>>Почему? I>Потому, что это типовая задача. С такими нет никаких проблем разобраться, если есть некоторая база в программировании.
Практика показывает что есть. Раньше брали asp.net программистов, в надежде что разберутся. Увы, разбираться сложно, а писать на asp.net легко. Только value added получался отрицательным.
I>Проблема с другими задачами, которые только похожи на типовые или вовсе уникальные.
Они обычно сводятся к типовым. Потому что так дешевле.
I>>>Код он большей частью весь уникальный. Типовые задачи смысла давать решать, проще задать несколько вопросов. G>>Не-а. Статистика говорит что по большей части люди пишут код, который на 80% повторят уже написанный ими же.
I>Не повторяет, а всего лишь похож. Ты слишком вольно трактуешь статистику. Если у тебя люди на 80% повторяют код писаный ими же самими, то это значит, что ты набрал не разработчиков, а копипастеров.
"всего лишь похож" это и есть типовые задачи. То есть на входе примерно одно и тоже, а выходе тоже примерно одинаковое, вариативность логики небольшая. С точки зрения бизнеса задачи могут быть сильно разные. С точки зрения решения — очень похожи друг на друга.
G>>Это кстати проблема, потому что человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ. I>Правильно ! Потому надо и проверять такое умение, как раз на уникальных задачах, которые только похожи на типовые.
Нет, это бессмысленно. Какой смысл решать уникальную задачу? Угадал — не угадал? Что это может сказать о человеке?
Суть программирования — комбинирование решения из готовых кусочков. Для комбинирования надо понимать как кусочки устроены и собственно навык комбинирования.
Этот навык очень далек от разворота списка. Хотя и разворот списка можно через комбинирование написать, но это уже сложнее.
G>>А ты сколько раз рукопашную сортировку видел в реальном проекте? И зачем она там была? I>Всего не перечислишь. Например нужна гарантия, что сортировка никогда не отработает за n^2. Как ты понимаешь, быстрая сортировка здесь неприменима, а вот фокус, в стандартных алгоритмах нужна именно она.
Я спросил сколько. 1-2-3-10-100 раз?
Выделенное кстати зачем? Value какой?
I>Есть оптимизации основаные на свойствах конкретных данных и их количестве. Используя эти оптимизации можно получить время линейное или близкое к этому.
А зачем это все? Вставляй в сбалансированное дерево при получении данных, далее за o(n) доставай упорядоченное.
Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки.
HFT и разработкой бд тут мало кто не занимается.
I>>>Тогда странно, почему отсев только 30% G>>Это одним вопросом. А мы много вопросов задаем.
I>И это странно. Хорошая задача сделает отсев гораздо лучше.
Нет. SharePoint слишком большой, чтобы одной задачей покрыть. А минимальный скиллсет требуется большой.
Здравствуйте, Ikemefula, Вы писали:
I>Ну значит с реверсом списка все в порядке — это не требует знания конкретного алгоритма, более того, задача выбрана предельно простой что бы чел придумал алгоритм если не сталкивался.
Разворот списка на месте требует именно определенного алгоритма
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>>>Мы используем разворот строки на C#. Причем любой. НС>>>Там нет ссылок. G>>Нет, они и не нужны. N>Где нет ссылок? В C# нет ссылок?
В задаче на разворот строки.
G>>Задаем вопрос про value и reference типы в .NET. N>Эпично, спрашивать про ссылочные типы и при этом не интересоваться разворотом списка. Это просто эпично.
Разница между ссылочными и размерными типами — особенность платформы, которую стоит знать. Особенные проблемы получаются у тех, кто раньше на C++ писал.
А разворот списка для нас бесполезен. Да и для всех остальных тоже.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
НС>>>Базовые навыки важнее. G>>Какие именно? НС>В данном случае — понимание что такое ссылка и умение удерживать несложные ссылочные конструкции в голове.
Зачем?
Пуст лучше компьютер удерживает, у него памяти много и она не дырявая, как в програиистов.
G>> Почему важнее? НС>Потому что этому научить намного сложнее.
Как раз легче. Но все равно не зачем.
НС>>>Оно не абстрактное, оно очень практичное. G>>В каком месте? НС>В месте программирования. Не все ж какой нибудь 1С подпиливают, некторые и посложнее задачки решают.
Ну вот, ты уже сам пришел к выводу, что это не всем надо.
G>>>>Вообще не очень понимаю зачем нужно это абстрактное знание\умение. НС>>>Код писать. G>>Ко писать можно и не очень умея разворачивать списки, не находишь? НС>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен.
Практика показывает обратное.
Здравствуйте, Undying, Вы писали:
U>Коллизия это когда хэш объекта попал в ячейку уже занятую другим объектом.
Коллизия — это явление при котором хеш-функция получает для двух разных объектов одинаковый хеш-код.
В словарь невозможно добавить два объекта с одинаковым хеш-кодом, а в хеш-таблицу возможно.
Здравствуйте, gandjustas, Вы писали: G>Разница между ссылочными и размерными типами — особенность платформы, которую стоит знать. Особенные проблемы получаются у тех, кто раньше на C++ писал. G>А разворот списка для нас бесполезен. Да и для всех остальных тоже.
Интересно, как ваши кандидаты, не зная что такое ссылка, растолковывают вам отличие передачи ссылочного типа с|без ключевого слова ref.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это один момент. А второй — мы не ищем людей, которые должны лопатить от забора до обеда по строгому ТЗ.
И мне не нужен.
НС>У нас даже менее опытным программистам задачка дается в стиле "решить такую то проблему".
Т.е. условия задачи определяется Делом. А не чьими-то тараканами в голове. Задачи на собеседовании не связаны с делом, их условия определяются чисто собеседователем. А пришедший на собеседование его в первый раз в жизни видит, и без понятия что от него хотят — чтобы он просто решил задачу, чтобы он сделал это быстро, чтобы он сделал это оптимально.
НС>В таком разрезе человек, которому надо даже для такой примитивной задачи явно указывать на то, что кривой код писать не надо, нам не нужен.
А что в приведенном тобой коде особо кривого? На автопилоте я бы весьма вероятно написал бы примерно такой же код, разве что без list.Reverse. И в продакшене меня бы подобный код вполне устроил, при условии что он не работает с большими объемами данных. Соответственно если бы человек на собеседовании написал бы подобный код, заметив при этом что код не оптимален по производительности, я бы посчитал что он хорошо справился с задачей.
Здравствуйте, Ikemefula, Вы писали:
I>У ней n*log(n) это среднее время работы, худший случай — n^2
Есть подозрение, что вероятность этого худшего случая на большой коллекции данных пренебрежимо мала.
I>Когда есть некоторые сведения о характере и количестве сортируемых данных, можно подобрать более подходящий алгоритм, часто даже O(n).
А конкретный пример и характера данных, и алгоритма можешь привести?
Здравствуйте, Vzhyk, Вы писали:
V> Здесь всего-лишь нужен ЦОС, немного ТВиМС и основ матана.
На самом деле в данной задаче и от всего перечисленного толку немного. Классическая ЦОС заточена под часто снимаемые сигнала. А когда данные идут раз в десять секунд работает это все кое как.
Это разговор ни о чем.
Вы никогда не переубедите ни меня, ни Ночного смотрящего, ни какого-либо другого грамотного специалиста в том, что переворот списка — это ненужная абракадабра.
Потому, что в этой задаче заложены многие основы современного программирования и это факт.
На работах со ссылками основаны все нынешние паттерны ООП.
Яркий пример — декоратор.
На тех же ссылках основаны все нынешние высокоуровневые яп, так как вы не работаете на прямую с данными, вы работаете с ссылками на них.
Это понимание делает возможным программирование с использованием языка, а не на языке.
В итоге вы становитесь независимым от конкретного яп и спокойно можете переключатся с одного на другой.
Но самая главная ирония в том, что вы и некоторые товарищи выше, просто демонстрируете зазубривание конкретного языка, платформы, фреймворка.
И после всего этого называете зубрилами других людей, которые много работали и трудились, что бы разбираться в сути.
Здравствуйте, -n1l-, Вы писали:
U>>Если у вас условия задачи определяются тараканами в голове заказчика, то я вам искренне сочувствую. N>Так это в итоге всегда так.
Если заказчиков много, то это всегда не так по совершенно объективным причинам.
Здравствуйте, gandjustas, Вы писали:
I>>Ну значит с реверсом списка все в порядке — это не требует знания конкретного алгоритма, более того, задача выбрана предельно простой что бы чел придумал алгоритм если не сталкивался. G>Разворот списка на месте требует именно определенного алгоритма
Тогда любой код это "определенный алгоритм".
Этот алгоритм настолько тривиален, что не придумать его просто невозможно.
Здравствуйте, Undying, Вы писали:
U>На самом деле в данной задаче и от всего перечисленного толку немного. Классическая ЦОС заточена под часто снимаемые сигнала. А когда данные идут раз в десять секунд работает это все кое как.
Блин, с каждым днем, я все больше и больше в шоке от кывта, точнее от современных программистов. Обычно я всегда тут нахожу, что ответить, но сейчас я ступоре, у меня просто нет слов.
Здравствуйте, gandjustas, Вы писали:
G>Задача не алгоритмическая. Нужно знать 3 класса, 4 функции и понимать как они работают. Все эти функции обычно программисты пишут каждый день. В интернетах все есть. G>Но вот люди невнимательно читают и часто не понимают почему пишут именно так.
То есть — не надо.
I>>Пудозреваю, если другие конторы начнут задавать такие же задачи, как у тебя, решений будет валом в интернете. G>Не-а. На русском про SharePoint пишут человек пять. Один уехал, одн работает со мной, а еще двое были на собеседовании.
А почему надо только русский язык учитывать ?
I>>Правильно,и с реверсом тоже самое — нет решения, не подходит. G>Не правильно, разворот списка не имеет отношения к реальной программе.
Объясняю еще раз — кроме ссыдлк-указателей и тд, в каждой программе всегда и везде будет уникальный код, который пишется практически каждый день.
Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче.
G>Почему например людей не фильтруют по незнанию преобразования числа в строку? G>Или по итеративному вычислению квадратного корня?
Фильтруют, не переживай.
I>>Это типовые задачи. Все что ты прверишь — умение решать типовые задачи. Это умение ни о чем. G>Я же писал, что 80% задач на работе — типовые. Это у всех. Более того, люди сами стремятся так работать — сводить все к типовым задачам. Ибо так мозг меньше напрягается.
Оставшиеся 20% задач как раз и создают бОльшую часть проблем. Если кандидат начнет сводить их к типовым, получится хаос.
I>>Потому, что это типовая задача. С такими нет никаких проблем разобраться, если есть некоторая база в программировании. G>Практика показывает что есть. Раньше брали asp.net программистов, в надежде что разберутся. Увы, разбираться сложно, а писать на asp.net легко. Только value added получался отрицательным.
Естественно, ты же и асп-нетчиков брал точно так же — по типовым задачам. А если человек умеет решать нестандартные задачи, то как правило ему разбираться будет легко.
I>>Проблема с другими задачами, которые только похожи на типовые или вовсе уникальные. G>Они обычно сводятся к типовым. Потому что так дешевле.
Ты похоже начал сам с собой спорить: "человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ"
Ты определись, таки дешевле или он не прав.
I>>Правильно ! Потому надо и проверять такое умение, как раз на уникальных задачах, которые только похожи на типовые. G>Нет, это бессмысленно. Какой смысл решать уникальную задачу? Угадал — не угадал? Что это может сказать о человеке?
Смысл в том, что типовые задачи создают меньше всего проблем в силу того, что они отработаны чуть не до автоматизма. А остальные задачи создают бОльшую часть проблем.
G>Суть программирования — комбинирование решения из готовых кусочков. Для комбинирования надо понимать как кусочки устроены и собственно навык комбинирования. G>Этот навык очень далек от разворота списка. Хотя и разворот списка можно через комбинирование написать, но это уже сложнее.
Одним комбинированием новую задачу не решить.
I>>Всего не перечислишь. Например нужна гарантия, что сортировка никогда не отработает за n^2. Как ты понимаешь, быстрая сортировка здесь неприменима, а вот фокус, в стандартных алгоритмах нужна именно она. G>Я спросил сколько. 1-2-3-10-100 раз?
В среднем раз в год, и кое какие даже сам писал.
G>Выделенное кстати зачем? Value какой?
Требования, естественно, на время отклика. Правда это было в проекте которым я не занимался.
I>>Есть оптимизации основаные на свойствах конкретных данных и их количестве. Используя эти оптимизации можно получить время линейное или близкое к этому. G>А зачем это все? Вставляй в сбалансированное дерево при получении данных, далее за o(n) доставай упорядоченное.
Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n)
Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех.
Предложи решение которое даст O(n) без дополнительной памяти.
G>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки.
Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил.
G>HFT и разработкой бд тут мало кто не занимается.
Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника.
Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n) 
