Здравствуйте, Undying, Вы писали:
U>И переворот дерева это извращение какое-то, а не практически востребованная операция.
Почему извращение? Такое может быть, к примеру, полезно при анализе зависимостей — переворот дерева сформирует обратные зависимости.
U>Производительность работника в первую очередь снижает решение простых задач сложными методами. Например, применением рекурсии там где можно обойтись циклами.
Давно рекурсия сложнее цикла стала? По мне так в большинстве случаев все наоборот, рекурсивное решение проще, а развертыванием его в цикл пусть компиляторы занимаются.
U> И по хорошему именно умение работника решать задачи просто надо проверять на собеседовании.
Это невозможно ввиду крайне ограниченного времени собеседования. И уж тем более невозможно его использовать в качестве входного фильтра. Умение решать реальные задачи проверяется на испытательном сроке.
Здравствуйте, gandjustas, Вы писали:
G>И? Все равно он может с помощью гугла написать код на нужном языке за полдня.
Да не напишет он и с помощью гугла. Больше половины на обсуждаемую задачку не задумываясь пишут примерно такой код (и это еще самый приличный вариант, чаще идея похожая, да еще и нормально не реализована):
var head = ...;
var current = head;
var list = new List<Item>();
while (current != null)
{
list.Add(current);
current = current.Next;
}
list.Reverse();
for (int i = 0; i < list.Count - 1; i++)
list[i].Next = list[i + 1];
list[list.Count - 1].Next = null;
Этим гугль не поможет, они и рабочий код будут писать по принципу "фигли тут думать, трясти надо".
Здравствуйте, Undying, Вы писали:
U>Дерево это другая структура данных. И переворот дерева это извращение какое-то, а не практически востребованная операция. А в реализации хэш таблиц где списки используются?
"в реализации хэш таблиц где списки используются" это хороший вопрос на собеседовании. А если это такая форма удивления-несогласия, то за такое не худо бы надавать по шее и вытолкать за дверь.
U>Не понял. Зачем для того, чтобы понимать, что многократное сложение при последующем делении может привести к переполнению, знать что "умножение в двоичной системе счисления считается через цикл и сдвиг"? Первое со вторым вообще не связано.
Если есть задачи оптимизации производительности, то на таких небольших кусочках можно много чего соптимизировать.
U>Производительность работника в первую очередь снижает решение простых задач сложными методами. Например, применением рекурсии там где можно обойтись циклами. И по хорошему именно умение работника решать задачи просто надо проверять на собеседовании. Вы же пытаетесь проверять обратное — умеет ли работник видеть в мухе слона.
Здесь проверяется умение решать простую задачу простым методом, + задача для неподготовленого достаточно новая, нужно немного приложить мозг.
Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
Скажем решения задач навроде реверса списка и похожих рекурсивным методом дают в среднем меньше количетсво ошибок относительно решения с циклом.
Здравствуйте, gandjustas, Вы писали:
G>Любая задача на собеседовании, которая: G>1) Не имеет отношения к потенциальной работе G>2) Требует знания конкретных алгоритмов G>3) Требует решения на бумажке
G>Фактически является головоломкой, которая нужна только для удовлетворения самолюбия собеседующего.
Подставляем в формулу твою задачку по шарепоинту на 7 строчек и согласно п.3. получаем результат — "головоломка, которая нужна только для удовлетворения самолюбия собеседующего"
Здравствуйте, Undying, Вы писали:
N>>Переворот списка — это вообще не сложно. Тут нет ни мух ни слонов. N>>Есть основы, которые нужно знать.
U>Зачем знать? Придумать самому при необходимости, да, это полезный навык. Знание экзотики бесполезный.
Есть одна проблема — нет никакой гарантии, что из постановки задачи будет однозначно очевиден способ её решения.
Даже люди занимающиеся математикой крайне плохо решают такие прикладные задачи, если их область не прикладная математика.
Переворот списка это просто громкие слова. Реально здесь нужно уметь обходить список. А вот задач, похожих на обход списка есть везде выше крыши.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Опаньки ! Практически аналог реверса для SharePoint — программиста. G>>Да, но разница только в том, что это реально используется в работе. Я же говорил что подобный код минимум пару раз в неделю писать приходится. G>>В отличие от разрворотов списка.
I>Если надо писать пару раз в неделю, что 100% это есть в гугле.
Когда знаешь что гуглить, да. Но мы специально подобрали задачу, чтобы в одном месте не гуглилась. Надо именно понимать чтобы такое написать.
Ели человек не понимает этих вещей, то нам не подходит.
Причем это не абстрактные знания, которые никогда могут не пригодиться. Эти знания пригождаются почти каждый день.
I>>>Ты похоже делаешь выводы по своему частному случаю. G>>Причем тут частый случай? Основной криетрий полезности той или иной задачи — насколько она близка к той работе, которую нужно делать. I>Задача близка и задачу надо решь пару раз в неделю это вещи мягко говоря разные.
Почему?
G>>Развороты списка в реальном приложении не пишет никто. I>Код он большей частью весь уникальный. Типовые задачи смысла давать решать, проще задать несколько вопросов.
Не-а. Статистика говорит что по большей части люди пишут код, который на 80% повторят уже написанный ими же.
Это кстати проблема, потому что человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ.
G>>Рукопашную сортировку видел один раз, и что потому что программист был не в курсе что такое comparer. I>Так что, обсуждать 'широту' твоего опыта ?
А ты сколько раз рукопашную сортировку видел в реальном проекте? И зачем она там была?
G>>Поэтому спрашивают все это на собеседовании чтобы потешить самолюбие собеседующего, не более того. I>Вероятно это у тебя такая цель.
Я такие вопросы не задаю
I>>>Баззворд SharePoint в вакансии сам по себе фильтрует неплохо и на собеседования новички практически не приходят. G>>А вот ценник притягивает тех, кто полкнижки только успел прочитать. I>Тогда странно, почему отсев только 30%
Это одним вопросом. А мы много вопросов задаем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Так именно знание платформы и нужно НС>Базовые навыки важнее.
Какие именно? Почему важнее?
G>>, а не абстрактное умение "оперировать ссылками" НС>Оно не абстрактное, оно очень практичное.
В каком месте?
G>>Вообще не очень понимаю зачем нужно это абстрактное знание\умение. НС>Код писать.
Ко писать можно и не очень умея разворачивать списки, не находишь?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Любая задача на собеседовании, которая: G>>1) Не имеет отношения к потенциальной работе G>>2) Требует знания конкретных алгоритмов G>>3) Требует решения на бумажке
G>>Фактически является головоломкой, которая нужна только для удовлетворения самолюбия собеседующего.
I>Подставляем в формулу твою задачку по шарепоинту на 7 строчек и согласно п.3. получаем результат — "головоломка, которая нужна только для удовлетворения самолюбия собеседующего"
I>
Все 3 надо, а не одно из них.
В нашем случае только 3 и есть, 1 и 2 нет.
Здравствуйте, gandjustas, Вы писали:
НС>>Базовые навыки важнее. G>Какие именно?
В данном случае — понимание что такое ссылка и умение удерживать несложные ссылочные конструкции в голове.
G> Почему важнее?
Потому что этому научить намного сложнее.
НС>>Оно не абстрактное, оно очень практичное. G>В каком месте?
В месте программирования. Не все ж какой нибудь 1С подпиливают, некторые и посложнее задачки решают.
G>>>Вообще не очень понимаю зачем нужно это абстрактное знание\умение. НС>>Код писать. G>Ко писать можно и не очень умея разворачивать списки, не находишь?
Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен.
Здравствуйте, Undying, Вы писали:
U>Он при любой реализации хэш таблицы не динамический и его нужно ресайзить при переполнении.
Он при любой реализации языка не динамический.
Его всегда нужно ресайзить, а вот список не нужно.
Размер списка ограничивает только доступная оперативная память.
Здравствуйте, -n1l-, Вы писали:
U>>Он при любой реализации хэш таблицы не динамический и его нужно ресайзить при переполнении. N>Он при любой реализации языка не динамический.
Реализация словаря на шарпе:
private int[] buckets;
private Dictionary<TKey, TValue>.Entry[] entries;
private void Resize()
{
int prime = HashHelpers.GetPrime(this.count * 2);
int[] numArray = new int[prime];
for (int index = 0; index < numArray.Length; ++index)
numArray[index] = -1;
Dictionary<TKey, TValue>.Entry[] entryArray = new Dictionary<TKey, TValue>.Entry[prime];
Array.Copy((Array) this.entries, 0, (Array) entryArray, 0, this.count);
for (int index1 = 0; index1 < this.count; ++index1)
{
int index2 = entryArray[index1].hashCode % prime;
entryArray[index1].next = numArray[index2];
numArray[index2] = index1;
}
this.buckets = numArray;
this.entries = entryArray;
}
И где тут отсутствие ресайзов и списки в их классическом понимании?
Идея цепочки ссылок, да, используется и в хэштаблицах, и в тех задачах, которые Stanislav V. Zudin приводил. Но список в его классической реализации на практике никому не нужен, ибо зело тормозит. На практике для хранения цепочки ссылок используют массивы и ресайзят их при необходимости.
Здравствуйте, Ikemefula, Вы писали:
U>>А зачем вы ищете специалистов по алгоритмам, а не специалистов по решению алгоритмических задач? I>А в чем разница ? Я чтото не понимаю твоей терминологии.
Для того, чтобы найти специалиста по алгоритмам на собеседовании нужно спрашивать сколько алгоритмов человек вызубрил. Для того, чтобы найти специалиста по решению алгоритмических задач на собеседовании нужно спрашивать какие алгоритмические задачи человек решил в своей профессиональной деятельности.
Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей?
Здравствуйте, gandjustas, Вы писали:
G>>>Мы используем разворот строки на C#. Причем любой. НС>>Там нет ссылок. G>Нет, они и не нужны.
Где нет ссылок? В C# нет ссылок?
G>Задаем вопрос про value и reference типы в .NET.
Эпично, спрашивать про ссылочные типы и при этом не интересоваться разворотом списка. Это просто эпично.
Здравствуйте, Ikemefula, Вы писали:
I>"в реализации хэш таблиц где списки используются" это хороший вопрос на собеседовании. А если это такая форма удивления-несогласия, то за такое не худо бы надавать по шее и вытолкать за дверь.
Идиотский вопрос, совершенно бесполезный для практики. Полезное знание это формирование хэша объекта для его использования в хэштаблице.
I>Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
Ты издеваешься? Код пишется для того, чтобы он а) работал б) легко модифицировался при необходимости. Если код сложнее в отладке, значит, его тяжелее заставить работать и сложнее модифицировать. Т.е. по определению такой код является более сложным и соответственно худшим при прочих равных.
Здравствуйте, Undying, Вы писали:
U>Для того, чтобы найти специалиста по алгоритмам на собеседовании нужно спрашивать сколько алгоритмов человек вызубрил. Для того, чтобы найти специалиста по решению алгоритмических задач на собеседовании нужно спрашивать какие алгоритмические задачи человек решил в своей профессиональной деятельности.
Нет, вот "зубрилки" и "люди понимающие структуры данных и алгоритмы" — понятия разные.
U>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая.
Нет, это просто задача. U>И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей?
Только по таким знаниям сложно сказать.
Но вот если нужно строго последовательно обрабатывать данные, то очередь или стек очень пригодятся.
Мы уже победили, просто это еще не так заметно...
