Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Ну значит с реверсом списка все в порядке — это не требует знания конкретного алгоритма, более того, задача выбрана предельно простой что бы чел придумал алгоритм если не сталкивался. G>>Разворот списка на месте требует именно определенного алгоритма
I>Тогда любой код это "определенный алгоритм".
Нет. Определенный алгоритм, означает что нужно в определенном порядке написать операторы, чтобы получить верный результат.
Разворот списка на месте только одним образом можно сделать.
Мы такого никогда не требуем. Требуем чтобы работало. Хоть как-нибудь, дальше уже вопросы задаим.
В этом и суть проверки умений писать код, а не решать головоломки.
I>Этот алгоритм настолько тривиален, что не придумать его просто невозможно.
За 10 минут на собеседовании, при рисовании на бумажке? Ты слишком хорошего мнения о способностях программистов.
Человек должен быть специально натренирован решать такие задачи или он просто нагуглил.
Увы обе характеристики нерелевантны для тех, кого мы ищем.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, gandjustas, Вы писали: G>>Разница между ссылочными и размерными типами — особенность платформы, которую стоит знать. Особенные проблемы получаются у тех, кто раньше на C++ писал. G>>А разворот списка для нас бесполезен. Да и для всех остальных тоже. N>Интересно, как ваши кандидаты, не зная что такое ссылка, растолковывают вам отличие передачи ссылочного типа с|без ключевого слова ref.
Про ref не спрашиваем. Он слишком редко в дикой природе встречается.
Здравствуйте, gandjustas, Вы писали:
G>Нет. Определенный алгоритм, означает что нужно в определенном порядке написать операторы, чтобы получить верный результат. G>Разворот списка на месте только одним образом можно сделать.
Минимальные требования — умение придумать решение и его закодить. Всё.
I>>Этот алгоритм настолько тривиален, что не придумать его просто невозможно. G>За 10 минут на собеседовании, при рисовании на бумажке? Ты слишком хорошего мнения о способностях программистов.
Ну мы же не ищем специалистов по написанию типовых задач для шарепоинта.
G>Человек должен быть специально натренирован решать такие задачи или он просто нагуглил.
Именно так — "умение придумать решение и его закодить". Типовые задачи никогда не создают большого количетсва проблем и потому их не надо спрашивать на собеседовании.
Здравствуйте, Undying, Вы писали:
I>>Профайлер скажет тебе "сортировка слишком долгая операция". Если у тебя есть познания в алгоритмах, то ты скорее всего усомнишься в этом, если нет — тупо согласишься с профайлером. U>Насколько я понял проблема была не в том, что сортировка всегда работала медленно, а в том что она работала медленно иногда.
И что ?
I>>Гуглением найдешь что сортировка это в лучшем случае O(n*log(n)), а про конкретный случай тебе гугл ничего не скажет. U>Даже статья в Википедии говорит, что нормальное время O(n*log(n)), а худшее — О(n2). Уже этого в купе с замерами времени достаточно, чтобы определиться в каком направлении копать.
Задним числом, когда я все тебе разжевал — конечно всего этого достаточно.
Это было задолго до появления этой статьи в Википедии.
I>>Если буквально, то я не знаю наизусть ни одного алгоритма сортировки и никогда не знал. U>А сколько названий методов сортировки с их нормальными и худшими случаями ты знал до того как сам столкнулся с проблемой порожденной сортировкой?
Я знал основные подходы в сортировках, а конкретных алгоритмов только пузырёк и быструю.
Здравствуйте, Ikemefula, Вы писали:
U>>Насколько я понял проблема была не в том, что сортировка всегда работала медленно, а в том что она работала медленно иногда. I>И что ?
То что очевидно, что проблему можно решить.
I>Задним числом, когда я все тебе разжевал — конечно всего этого достаточно.
Что ты разжевал? Что тормоза в некоторых случаях сортировки объясняются плохим случаем данных? Это даже Википедия знает.
I>Это было задолго до появления этой статьи в Википедии.
Все течет, все меняется. Лет двадцать назад ценность конкретных знаний была сильно больше, сейчас упала. Зато умение решать задачи с неизвестным ответом всегда в цене.
I>Я знал основные подходы в сортировках, а конкретных алгоритмов только пузырёк и быструю.
Так что ты хочешь услышать на собеседовании на вопрос о сортировках?
Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
Здравствуйте, gandjustas, Вы писали:
НС>>В данном случае — понимание что такое ссылка и умение удерживать несложные ссылочные конструкции в голове. G>Зачем?
Затем что это напрямую влияет на качество и эффективность программиста.
G>Пуст лучше компьютер удерживает, у него памяти много и она не дырявая, как в програиистов.
Компьютер еще дизайн софта самостоятельно делать не научился. Так что пока только головой.
НС>>В месте программирования. Не все ж какой нибудь 1С подпиливают, некторые и посложнее задачки решают. G>Ну вот, ты уже сам пришел к выводу, что это не всем надо.
Конечно не всем. Это надо программистам. Ну так мы и собеседуем не вообще, а для конкретных вакансий.
НС>>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен. G>Практика показывает обратное.
Здравствуйте, Undying, Вы писали:
U>Т.е. условия задачи определяется Делом.
Кто такой Дел и почему он у нас определяет условие задачи?
НС>>В таком разрезе человек, которому надо даже для такой примитивной задачи явно указывать на то, что кривой код писать не надо, нам не нужен. U>А что в приведенном тобой коде особо кривого?
А ты не видишь? Впрочем, если ты про односвязные списки только здесь услышал, то охотно верю что не видишь.
U> На автопилоте я бы весьма вероятно написал бы примерно такой же код
А нам вот не нужно писать код на автопилоте в принципе, лучше вообще ничего не писать, чем потом этот автопилотный код вылавливать и переписывать. А если человек даже на собеседовании пишет код без включения моска, то чего от него можно ожидать в продакшене?
U>И в продакшене меня бы подобный код вполне устроил
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Т.е. условия задачи определяется Делом. НС>Кто такой Дел и почему он у нас определяет условие задачи?
Если тебе не понятно, что такое дело, значит, у вас и в работе условия задачи определяются не ее нужностью пользователям, а чьими-то тараканами. Искренне вам сочувствую.
НС>А ты не видишь? Впрочем, если ты про односвязные списки только здесь услышал, то охотно верю что не видишь.
Что кривого-то? Прямо ответить-то никак, только юлить можешь? Ну лишние копирование памяти. Ой ужас какой — на целую микросекунду код отработает медленнее в задаче, которая выполняется сотню миллисекунд.
В стандартные хелперы, да, подобный код убирать плохо. А по месту, если очевидно, что на производительность он не повлияет, что в подобном коде плохого-то?
НС>А нам вот не нужно писать код на автопилоте в принципе, лучше вообще ничего не писать, чем потом этот автопилотный код вылавливать и переписывать. А если человек даже на собеседовании пишет код без включения моска, то чего от него можно ожидать в продакшене?
Как раз меня бы очень насторожило, если бы на собеседовании человек бросился писать оптимальным код. Так как весьма вероятно, что в реальной работе он будет делать тоже самое. И вместо того, чтобы, понимая что данное место не является критичным, свести задачу к известной и решить пусть неоптимально, но быстро и надежно, будет долго и упорно фигачить оптимальный вариант.
Здравствуйте, Vzhyk, Вы писали:
I>>Профайлер скажет тебе "сортировка слишком долгая операция". Если у тебя есть познания в алгоритмах, то ты скорее всего усомнишься в этом, если нет — тупо согласишься с профайлером. V>Это если глуп (таких очень мало) или опыт пол-года(это студенты еще).
Не понял идею.
I>>Если буквально, то я не знаю наизусть ни одного алгоритма сортировки и никогда не знал. V>А "пузырек"? Его и самому придумать можно, если в школе не проходили.
Я его каждый раз и придумаваю заново, если спрашивают
Здравствуйте, Undying, Вы писали:
I>>Почему инженер не может использовать теоретический метод ? Или подразумевается, что теоретический метод доступен только марсианам и богам ? I>>Поясни, а то непонятно.
U>Критерием истины является практика. Соответственно невозможно создать теорию не пользуясь эмпирическим методом. Умозрительно можно максимум сформулировать гипотезу.
Не пользуюясь теоретическим методом, тоже невозможно создать теорию.
Здравствуйте, Undying, Вы писали:
U>>>Насколько я понял проблема была не в том, что сортировка всегда работала медленно, а в том что она работала медленно иногда. I>>И что ?
U>То что очевидно, что проблему можно решить.
Её и в другом случае можно решить
I>>Задним числом, когда я все тебе разжевал — конечно всего этого достаточно.
U>Что ты разжевал? Что тормоза в некоторых случаях сортировки объясняются плохим случаем данных? Это даже Википедия знает.
Я выложил все что нужно и теперь тебе все очевидно
U>Все течет, все меняется. Лет двадцать назад ценность конкретных знаний была сильно больше, сейчас упала. Зато умение решать задачи с неизвестным ответом всегда в цене.
Правильно и здесь помогают базовые знания. Чем шире база, тем быстрее поиск решения. В уме гораздо быстрее решаются уникальные задачи, быстрее чем гугл результаты выдает.
I>>Я знал основные подходы в сортировках, а конкретных алгоритмов только пузырёк и быструю. U>Так что ты хочешь услышать на собеседовании на вопрос о сортировках? U>
U> Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
Специалист по алгоритмам обязан уметь анализировать алгоритм и быть в курсе свойств метода. Скажем, не надо нигде гуглить если ты видишь алгоритм "разделяй и властвуй". Совершенно не важно, сортировка это или бпф, у него вполне определенная сложность.
Теоретически можно и нагуглить, но есть люди, которые могут решать такие задачи в уме. Их и надо брать, если тебе важны именно алгоритмы, а не кодинг для Шарепоинта.
И вот представь, приходит кандидат и в курсе сложности быстрой сортировки, а сложность метода "разделяй и властвуй" не знает. Это значит, что он просто зазубрил алгоритмы и будет гуглить. Для сложной проблемы каждая секунда решения в уме будем помножена на минуты и часы гугления.
Здравствуйте, Ikemefula, Вы писали:
I>Почему инженер не может использовать теоретический метод ? Или подразумевается, что теоретический метод доступен только марсианам и богам ?
Инженер может и использовать теоретический метод и создать/дополнить теорию. Это Vzhyk считает, что теоретический метод это нечто данное инженерам свыше и доработке не подлежащее.
I>Не пользуюясь теоретическим методом, тоже невозможно создать теорию.
Разумеется. Поэтому и нужно уметь использовать и теорию, и эмпирику.
Здравствуйте, Undying, Вы писали:
U>Если тебе не понятно, что такое дело, значит, у вас и в работе условия задачи определяются не ее нужностью пользователям
У нас нет пользователей как таковых, пользователи — прикладные программисты, существенно ниже уровнем.
U>Что кривого-то?
Код жрет лишнюю память, больше размером, его сложнее читать и сложнее рефакторить. И совершенно непонятно, есть ли у него хоть один плюс по сравнению с нормальным вариантом.
U> Прямо ответить-то никак, только юлить можешь? Ну лишние копирование памяти. Ой ужас какой — на целую микросекунду код отработает медленнее в задаче, которая выполняется сотню миллисекунд.
Это задача на собеседовании. Только полный имбецил не понимает, что такие задачи дают с целью выяснить наличие определенных умений. Постоянное утягивание обсуждений в сторону прямой практической полезности этой задачи показывают узость мышления
U>В стандартные хелперы, да, подобный код убирать плохо. А по месту, если очевидно, что на производительность он не повлияет, что в подобном коде плохого-то?
Скажи лучше, что в нем хорошего?
U>Как раз меня бы очень насторожило, если бы на собеседовании человек бросился писать оптимальным код.
Тебя бы насторожило что на собеседовании человек написал бы код с использованием моска? Однако.
U> Так как весьма вероятно, что в реальной работе он будет делать тоже самое.
Знаешь, меня вот пугают все время преждевременными оптимизациями, но на практике я таких вижу только на форуме. Чтобы что то не делать, человека уговаривать долго не надо.
Ну а если тебя этот факт так беспокоит, это легко выясняется небольшой устной задачкой на проектирование прямо по ходу собеседования. Но это уже совсем потом, обсуждаемая же задачка это просто входной фильтр. У нас до каких либо бесед человеку просто дают простенький тест на основы шарпа с вариантами ответов и эту задачку. И когда человек, который требует зарплату сильно выше рынка, в тесте с трудом отвечает на половину вопросов, и пишет просто нерабочий код, то и разговаривать с ним уже не имеет никакого смысла.
Здравствуйте, gandjustas, Вы писали:
G>Задача не алгоритмическая.
А задача разворота списка что, алгоритмическая? Т.е. переворот списка по принципу ханойской башни это алгоритм, который надо придумать? Жесть.
I>>Правильно,и с реверсом тоже самое — нет решения, не подходит. G>Не правильно, разворот списка не имеет отношения к реальной программе.
А строку ты часто в реальных программах разворачиваешь?
Здравствуйте, Vzhyk, Вы писали:
V>Блин, с каждым днем, я все больше и больше в шоке от кывта, точнее от современных программистов. Обычно я всегда тут нахожу, что ответить, но сейчас я ступоре, у меня просто нет слов.
После заявления о том, что про односвязный список он услышал только здесь, тебя еще что то удивляет? Просто делай выводы.
Здравствуйте, Undying, Вы писали:
U>А теория ЦОС по твоему откуда появилась? Ее бог что ли написал или марсиане? Ее писали такие же люди как я и ты, но в отличие от тебя не боявшиеся сами находить решения, а не пользоваться готовыми.
Вот только там очень много математики. Преобразование Адамара там, не? Или настоящие практики это все не используют?
U> Если бы все мыслили так как ты люди до сих пор бы с деревьев не слезли.
Да вот непонятно только кто на деревьях сидит, кто математикой пользуется или кто исключительно методом научного тыка палкой.
Здравствуйте, gandjustas, Вы писали:
G>>>Не правильно, разворот списка не имеет отношения к реальной программе. I>>Объясняю еще раз — кроме ссыдлк-указателей и тд, в каждой программе всегда и везде будет уникальный код, который пишется практически каждый день. G>И что?
Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам.
Умение писать такой код это умение обучаться, умение решать проблемы.
I>>Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче. G>Нужны способности писать этот уникальный код, а не пытаться всё свести к развороту списка.
И ты проверяешь способности писать уникальный код с помощью типовой задачи. Я правильно тебя понял ?
G>>>Или по итеративному вычислению квадратного корня? I>>Фильтруют, не переживай. G>Не видел.
Мало видел.
I>>Оставшиеся 20% задач как раз и создают бОльшую часть проблем. Если кандидат начнет сводить их к типовым, получится хаос. G>Нет. Как раз проблемы возникают в совершенно типовом коде. То есть плотность ошибок примерно одинаковая, но типового кода тупо больше.
Наверное это особенности Шарепоинта или тех людей которых ты нанял, раз в типовом коде плотность ошибок такая же как и в остальном коде.
I>>Естественно, ты же и асп-нетчиков брал точно так же — по типовым задачам. А если человек умеет решать нестандартные задачи, то как правило ему разбираться будет легко. G>Нет, как раз их брали по-другому.
Конечно по другому — давали типовые задачи для асп-нета.
I>>Ты похоже начал сам с собой спорить: "человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ" G>Да. Просто человек заранее не понял что задача нетиповая. Если бы заранее понял, то её проще к типовой свести, чем решать как есть.
Если задача сводится к типовой, это просто типовая задача.
I>>Смысл в том, что типовые задачи создают меньше всего проблем в силу того, что они отработаны чуть не до автоматизма. А остальные задачи создают бОльшую часть проблем. G>Нет, типовые задачи создают столько же проблем. Плотность ошибок одинаковая. Так как типовых задач больше, то и ошибок в них больше.
Это чушь. Типовые пишутся даже пьяным без ошибок.
G>С чего ты взял? Как раз большая часть любых задач решается именно комбинированием существующих кусочков. G>Реализация алгоритма, который не разлагается на другие, требуется крайне редко.
Разлагается на другие и типовая задача это две большие разницы.
I>>В среднем раз в год, и кое какие даже сам писал. G>Зачем?
Смотри рядом, там пример конкретный.
G>>>Выделенное кстати зачем? Value какой? I>>Требования, естественно, на время отклика. Правда это было в проекте которым я не занимался. G>Время отклика кого\чего?
Системы. Можешь посмотреть пример рядом для Undying.
I>> Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n) G>Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника.
Ты прав с точностью до наоборот.
G>Например при загрузке программы построить дерево. При небольших изменениях в него даже вставлять можно за log(n).
Есть мир вне Шарепоинта.
I>>Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех. G>Ну ты как-бы сам шифруешься вечно. Уже было с десяток тем, где ты всегда уходил в "особенности", про которые никому не сказал. G>Видимо не очень особенные эти особенности.
I>>Предложи решение которое даст O(n) без дополнительной памяти. G>Зачем?
G>>>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки. I>>Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил. G>Это я говорю. В серверной разработке абсолютно нет смысла заниматься оптимизацией алгоритмов, которые работают быстрее нескольких часов.
I>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>Чувак, 90% компаний этим не занимается.
Здравствуйте, Undying, Вы писали:
I>>Почему инженер не может использовать теоретический метод ? Или подразумевается, что теоретический метод доступен только марсианам и богам ?
U>Инженер может и использовать теоретический метод и создать/дополнить теорию. Это Vzhyk считает, что теоретический метод это нечто данное инженерам свыше и доработке не подлежащее.
Не Вжик, а именно ты.
I>>Не пользуюясь теоретическим методом, тоже невозможно создать теорию.
U>Разумеется. Поэтому и нужно уметь использовать и теорию, и эмпирику.
На счет теории ты не продемонстрировал ничего особенного. Все что ты показал это удачный метод тыка.
Здравствуйте, gandjustas, Вы писали:
I>>Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех. G>Ну ты как-бы сам шифруешься вечно. Уже было с десяток тем, где ты всегда уходил в "особенности", про которые никому не сказал. G>Видимо не очень особенные эти особенности.
Ты хочешь что бы я выложил 10мб спецификаций ?
I>>Предложи решение которое даст O(n) без дополнительной памяти. G>Зачем?
Для того, что бы сошлись концы с концами.
G>>>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки. I>>Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил. G>Это я говорю. В серверной разработке абсолютно нет смысла заниматься оптимизацией алгоритмов, которые работают быстрее нескольких часов.
Представляю — рендеринг картинки вместо пол-секунды займет пол-часа. Похоже это про тебя: "у нас всё в базу упирается"
I>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>Чувак, 90% компаний этим не занимается.
Здравствуйте, Undying, Вы писали:
V>> Здесь всего-лишь нужен ЦОС, немного ТВиМС и основ матана.
U>На самом деле в данной задаче и от всего перечисленного толку немного. Классическая ЦОС заточена под часто снимаемые сигнала. А когда данные идут раз в десять секунд работает это все кое как.
Похоже, ты близок к Нобелевской премии и это не шутка.
Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n) 