Здравствуйте, Undying, Вы писали: U>Какая задача такой и ответ. В условии хоть указываете, что решение должно быть максимально оптимизировано?
Задача нормальная, ответ идиотский.
Налицо незнание структур данных, не оптимальный и сложный код.
Оверхед в использовании памяти.
Магические числа в коде.
О ссылках я вообще молчу.
Код уровня джуниора максимум.
Здравствуйте, -n1l-, Вы писали:
U>>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. N>Нет, это просто задача.
Тогда получается, что алгоритмические задачи на практике не встречаются, т.к. все они уже давным-давно решены в стандартных библиотеках. И знание алгоритмов не нужно тем более.
Здравствуйте, Ikemefula, Вы писали:
I>Односвязный список это ни разу не экзотика, это основы структур данных. Не бывает человека, который хорошо понимает структуры данных и не знает что такое связный список.
Я, например, прекрасно понимаю структуры данных. При этом если бы на форуме не тусовался об односвязном списке не знал бы ничего. Понимать и знать термины это вообще разные вещи.
Здравствуйте, -n1l-, Вы писали:
N>Словарь и хештаблица принципиально разные вещи. Это раз.
А в чем разница? В шарпе вообще только словарь есть. Предлагаешь на собеседовании заворачивать всех шарпистов не знающих чем словарь отличается от хэштаблицы?
Здравствуйте, Undying, Вы писали:
I>>"в реализации хэш таблиц где списки используются" это хороший вопрос на собеседовании. А если это такая форма удивления-несогласия, то за такое не худо бы надавать по шее и вытолкать за дверь.
U>Идиотский вопрос, совершенно бесполезный для практики. Полезное знание это формирование хэша объекта для его использования в хэштаблице.
Значит ты плохо представляешь, что такое хеш-таблицы.
I>>Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
U>Ты издеваешься? Код пишется для того, чтобы он а) работал б) легко модифицировался при необходимости. Если код сложнее в отладке, значит, его тяжелее заставить работать и сложнее модифицировать. Т.е. по определению такой код является более сложным и соответственно худшим при прочих равных.
Если код пишется легче, то и заработает он раньше и модифицировать его будет проще и отлаживать его будет меньше.
Сложность отладки сильно слабо корелирует со сложностью написания и модификации.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ikemefula, Вы писали:
U>>>А зачем вы ищете специалистов по алгоритмам, а не специалистов по решению алгоритмических задач? I>>А в чем разница ? Я чтото не понимаю твоей терминологии.
U>Для того, чтобы найти специалиста по алгоритмам на собеседовании нужно спрашивать сколько алгоритмов человек вызубрил.
Это чушь. Специалист по алгоритмам в первую очередь умеет анализировать алгоритмы. Если человек чего то зазубрил, это никогда не сделает его специалистом ни в одной области.
>Для того, чтобы найти специалиста по решению алгоритмических задач на собеседовании нужно спрашивать какие алгоритмические задачи человек решил в своей профессиональной деятельности.
И здесь тоже самое — в первую очередь надо уметь анализировать алгоритмы. Если ты умеешь
U>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей?
Скажи пожалуйста а кто определил специалиста по алгоритмам как зубрилу ?
Я как раз и говорю, что зазубривать наизусть алгоритмы не нужно.
А вот владение соответсвующей математикой это уже серьезная заявка.
Здравствуйте, gandjustas, Вы писали:
G>>>Любая задача на собеседовании, которая: G>>>1) Не имеет отношения к потенциальной работе G>>>2) Требует знания конкретных алгоритмов G>>>3) Требует решения на бумажке
G>>>Фактически является головоломкой, которая нужна только для удовлетворения самолюбия собеседующего.
I>>Подставляем в формулу твою задачку по шарепоинту на 7 строчек и согласно п.3. получаем результат — "головоломка, которая нужна только для удовлетворения самолюбия собеседующего"
I>>
G>Все 3 надо, а не одно из них. G>В нашем случае только 3 и есть, 1 и 2 нет.
Ну значит с реверсом списка все в порядке — это не требует знания конкретного алгоритма, более того, задача выбрана предельно простой что бы чел придумал алгоритм если не сталкивался.
Отношение к потенциальной работе вполне конкретное
1. демонстрация понимание ссылок-указателей
2. понимание списковых структур данных
3. умение закодировать придуманое решение
Здравствуйте, gandjustas, Вы писали:
I>>Если надо писать пару раз в неделю, что 100% это есть в гугле.
G>Когда знаешь что гуглить, да. Но мы специально подобрали задачу, чтобы в одном месте не гуглилась. Надо именно понимать чтобы такое написать.
Практически все как с реверсом списка, только он сам по себе избитая задача и гуглится. Пудозреваю, если другие конторы начнут задавать такие же задачи, как у тебя, решений будет валом в интернете.
G>Ели человек не понимает этих вещей, то нам не подходит.
Правильно,и с реверсом тоже самое — нет решения, не подходит.
G>Причем это не абстрактные знания, которые никогда могут не пригодиться. Эти знания пригождаются почти каждый день.
Это типовые задачи. Все что ты прверишь — умение решать типовые задачи. Это умение ни о чем.
I>>Задача близка и задачу надо решь пару раз в неделю это вещи мягко говоря разные. G>Почему?
Потому, что это типовая задача. С такими нет никаких проблем разобраться, если есть некоторая база в программировании. Проблема с другими задачами, которые только похожи на типовые или вовсе уникальные.
I>>Код он большей частью весь уникальный. Типовые задачи смысла давать решать, проще задать несколько вопросов. G>Не-а. Статистика говорит что по большей части люди пишут код, который на 80% повторят уже написанный ими же.
Не повторяет, а всего лишь похож. Ты слишком вольно трактуешь статистику. Если у тебя люди на 80% повторяют код писаный ими же самими, то это значит, что ты набрал не разработчиков, а копипастеров.
G>Это кстати проблема, потому что человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ.
Правильно ! Потому надо и проверять такое умение, как раз на уникальных задачах, которые только похожи на типовые.
G>А ты сколько раз рукопашную сортировку видел в реальном проекте? И зачем она там была?
Всего не перечислишь. Например нужна гарантия, что сортировка никогда не отработает за n^2. Как ты понимаешь, быстрая сортировка здесь неприменима, а вот фокус, в стандартных алгоритмах нужна именно она.
Есть оптимизации основаные на свойствах конкретных данных и их количестве. Используя эти оптимизации можно получить время линейное или близкое к этому.
I>>Тогда странно, почему отсев только 30% G>Это одним вопросом. А мы много вопросов задаем.
И это странно. Хорошая задача сделает отсев гораздо лучше.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ikemefula, Вы писали:
I>>Односвязный список это ни разу не экзотика, это основы структур данных. Не бывает человека, который хорошо понимает структуры данных и не знает что такое связный список.
U>Я, например, прекрасно понимаю структуры данных.
Понимание структур данных это в первую очередь умение их анализировать и, далее, умение модифицировать и строить новые.
Умение анализировать структуры данных приенимо вообще ко всем структурам данных. Примерно как умение читать применимо ко всем книгам на родном языке, а не к той конкретной, котору ты прочел самой первой.
Соответсвенно все такие вещи прокачиваются на базовых вещах, вроде списков. В алгоритмах эти базовые вещи в основном сортировки. Если у тебя нет специального образования, ну например, ты не заканчивал факультет прикланой математики, то эти умения ты мог прокачат на других вещах.
При этом крайне странно заявлять, что экзотика требует каких то специальных знаний-умений. Если есть знания-умения, то они, как и чтение, применимы даже вещам навроде ревеса строки, списка, дерева и чего угодно.
Если этого у тебя нет, то, извини, ты не понимаешь ни структур данных ни алгоритмов.
Здравствуйте, Undying, Вы писали:
НС>>Этим гугль не поможет, они и рабочий код будут писать по принципу "фигли тут думать, трясти надо".
U>Какая задача такой и ответ. В условии хоть указываете, что решение должно быть максимально оптимизировано?
У инженера большей частью все задачи с неполным условием.
Есть общая проблема — большее количество кода гарантровано создаёт большее количество проблем.
Такое условие никто никогда в техническое задание не вводит, а оно есть.
Еще одна общая проблема — код больше читают, чем пишут. И этого условия в ТЗ не будет, а оно есть.
Еще одна проблема — ожидается, что он понимает, в какой области работает.
Скажем энтерпрайз это как в сказке про Федота стрельца из сборника Афанасьева — "поди туда, незнамо куда, да принеси то, незнамо что"
Итого — инженер обязан уметь решать задачи с неполным условием, даже если они выглядят как то иначе и учитывать общие проблемы присущие коду вообще
1. уточнять задание, уточнять результат и тд
2. размер желательно поменьше, ибо короткая программа при равных свойствах лучше длинной
3. код желательно иметь предельно понятным, ибо понятная программа при равны свойствах лучше запутаной
Поэтому если человек пишет на собеседовании решение по принципу "фигли тут думать, трясти надо", то он нахрен никому не упал, он вообще не инженер
Здравствуйте, Undying, Вы писали:
U>Тогда получается, что алгоритмические задачи на практике не встречаются, т.к. все они уже давным-давно решены в стандартных библиотеках. И знание алгоритмов не нужно тем более.
Встречаются, очень редко, но встречаются.
Сейчас там самый мейнстрим — это bigdata.
Здравствуйте, Undying, Вы писали:
U>И где тут отсутствие ресайзов и списки в их классическом понимании?
А почему списки должны быть в классческм понимании ?
U>Идея цепочки ссылок, да, используется и в хэштаблицах, и в тех задачах, которые Stanislav V. Zudin приводил. Но список в его классической реализации на практике никому не нужен, ибо зело тормозит. На практике для хранения цепочки ссылок используют массивы и ресайзят их при необходимости.
Практика она разная. В некоторых случаях я бы предпочел иметь цепочку в виде связного списка,что бы не иметь проблем связанных с ресайзом массива.
Здравствуйте, Undying, Вы писали:
U>Тогда получается, что алгоритмические задачи на практике не встречаются, т.к. все они уже давным-давно решены в стандартных библиотеках. И знание алгоритмов не нужно тем более.
Встречаются, просто люди большей частью решают их по методу "трясти надо".
Здравствуйте, Undying, Вы писали: U>А в чем разница? В шарпе вообще только словарь есть. Предлагаешь на собеседовании заворачивать всех шарпистов не знающих чем словарь отличается от хэштаблицы?
Отличие хештаблицы от словаря — это наличие|отсутствие коллизий соответсвтенно.
Вообще хештаблица в шарпе как бы есть, но технически это тоже словарь.
Здравствуйте, Ikemefula, Вы писали:
I>Скажи пожалуйста а кто определил специалиста по алгоритмам как зубрилу ?
Ты на собеседовании спрашиваешь знание алгоритмов, а не опыт по решению реальных алгоритмических задач. Если человек знает алгоритмы, но не применяет их на практике, то он зубрила по определению.
Здравствуйте, Ikemefula, Вы писали:
I>Если код пишется легче, то и заработает он раньше и модифицировать его будет проще и отлаживать его будет меньше.
Ты только что прямо заявил, что рекурсия сложнее в отладке.
Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
Т.е., продолжая твою мысль, рекурсия заработает позже и будет сложнее в модифицировании. Мой опыт это прекрасно подтверждает. Твой опыт, судя по твоему первому утверждению, тоже.
