Здравствуйте, Undying, Вы писали:
U>Где бы вы и сколько бы не учились, ответов на большинство возникающих вопросов у вас не будет. Т.к. вопросов возникает очень много и самых разных. Так почему вы такое значение придаете именно сортировке, которая составит малюсенькую долю возникающих вопросов? А не умению решать возникающие задачи с неизвестным ответом?
Сортировка хорошо детектит разрабов вроде "у нас всё в базу упирается", "шо тут думать, трясти надо", "такое нигде не пишут"
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У нас нет пользователей как таковых, пользователи — прикладные программисты, существенно ниже уровнем.
Т.е. вы занимаетесь преимущественно технологической работой (написанием кода, который упрощает решение задач другим программистам)? Так бы сразу и сказал. Если вы ищете технологов, то согласен это нормальная задача для собеседования. Тем не менее то, что вы ждете оптимального решения лучше проговаривать явно, т.к. технологи тоже телепатией не владеют.
НС>Знаешь, меня вот пугают все время преждевременными оптимизациями, но на практике я таких вижу только на форуме. Чтобы что то не делать, человека уговаривать долго не надо.
Признаю твою правоту. Я думал вы так специалистов-кодеров отбираете, а учитывая, что они вам не нужны, то это хорошая задача для первичного отбора.
Здравствуйте, Ikemefula, Вы писали:
U>>Инженер может и использовать теоретический метод и создать/дополнить теорию. Это Vzhyk считает, что теоретический метод это нечто данное инженерам свыше и доработке не подлежащее. I>Не Вжик, а именно ты.
Когда это я сказал? Цитату в студию.
I>На счет теории ты не продемонстрировал ничего особенного. Все что ты показал это удачный метод тыка.
Я метод решения задачи вообще не показывал. Так что домыслы насчет тыка это твоя телепатия, а телепат из тебя хреновый.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот только там очень много математики. Преобразование Адамара там, не? Или настоящие практики это все не используют?
И куда это преобразование Адамара в бинд топлива совать? Предлагаешь с начала значения с датчика сжать что ли? Это сильный ход.
Здравствуйте, Ikemefula, Вы писали:
I>Сортировка хорошо детектит разрабов вроде "у нас всё в базу упирается", "шо тут думать, трясти надо", "такое нигде не пишут"
Может ты и прав. Так-то согласен таких тоже как-то фильтровать надо.
Здравствуйте, Undying, Вы писали:
U>И куда это преобразование Адамара в бинд топлива совать?
Его не надо совать в топливо, это теория. На основании этого преобразования считается матрица ВЧ фильтра или любой другой потребной функции, которую нужно наложить на сигнал.
Здравствуйте, Undying, Вы писали:
U>Т.е. вы занимаетесь преимущественно технологической работой
У тебя какое то странное понимание терминов. Нет, технологической работой занимаются отдельные люди, в чью задачу входит настройка технологических моментов программирования — VCS, CI и т.п.
U>(написанием кода, который упрощает решение задач другим программистам)? Так бы сразу и сказал.
А никто и не спрашивал.
U> Если вы ищете технологов
Нет, мы не ищем технологов, мы ищем программистов.
U>то согласен это нормальная задача для собеседования
Не вижу принципиальных отличий на таком мелком уровне.
U>Тем не менее то, что вы ждете оптимального решения лучше проговаривать явно
Мы не ждем какого то супероптимального решения, мы ждем хороший приличный код. И это не очевидно только имбецилам, которые все равно не нужны.
U>Признаю твою правоту. Я думал вы так специалистов-кодеров отбираете
Мне кажется с самого начала было понятно, что речь не идет об найме обезьянок для шаблонного кода.
Здравствуйте, Undying, Вы писали:
U>Инженер может и использовать теоретический метод и создать/дополнить теорию. Это Vzhyk считает, что теоретический метод это нечто данное инженерам свыше и доработке не подлежащее.
Где ты такое вычитал? Может хватит придумывать призраков и бороться с ними.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>После заявления о том, что про односвязный список он услышал только здесь, тебя еще что то удивляет? Просто делай выводы.
Да, делаю, точно убедите.
Здравствуйте, Ikemefula, Вы писали:
U>>То что очевидно, что проблему можно решить. I>Её и в другом случае можно решить
Возможно. Но в другом случае это уже было бы неочевидно.
I>Правильно и здесь помогают базовые знания. Чем шире база, тем быстрее поиск решения. В уме гораздо быстрее решаются уникальные задачи, быстрее чем гугл результаты выдает.
Если умеешь и стремишься решать задачи, то базовые знания быстро появляются, даже в изначально незнакомой области.
I>Специалист по алгоритмам обязан уметь анализировать алгоритм и быть в курсе свойств метода. Скажем, не надо нигде гуглить если ты видишь алгоритм "разделяй и властвуй". Совершенно не важно, сортировка это или бпф, у него вполне определенная сложность.
I>Теоретически можно и нагуглить, но есть люди, которые могут решать такие задачи в уме.
Спрашивая подобные вещи ты на собеседование отберешь не тех кто умеет, а тех кто помнит.
I>Их и надо брать, если тебе важны именно алгоритмы, а не кодинг для Шарепоинта.
Не вижу принципиальной разницы между отбором по знанию алгоритмов и отбором по знанию Шарепоинта. И то и другое это отбор по знаниям, а не по способностям.
I>И вот представь, приходит кандидат и в курсе сложности быстрой сортировки, а сложность метода "разделяй и властвуй" не знает. Это значит, что он просто зазубрил алгоритмы и будет гуглить. Для сложной проблемы каждая секунда решения в уме будем помножена на минуты и часы гугления.
Эти какие задачи у вас программисты решают за секунды? Отдел фантастики в другой ветке. Мало-мальски сложная задача, как правило, обдумывается несколько дней (хоть обычно и параллельно с какой-нибудь рутиной). Соответственно пара часов гугления по нетривиальной задаче не стоит вообще ничего.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Его не надо совать в топливо, это теория. На основании этого преобразования считается матрица ВЧ фильтра или любой другой потребной функции, которую нужно наложить на сигнал.
Старый алгоритм так и работал, т.е. первоначально накладывал фильтр на сигнал. В результате терялась(загрублялась) информация о точности данных — уровень топлива фильтр возвращает, а дисперсию уже нет, о времени начала/конца события — реальная точка начала заправки/слива замусорена последующим поднятием/снижением уровня топлива, о уровне топлива на начало/конец события — по той же причине. Там, конечно, и алгоритм верхнего уровня был выбран принципиально неудачно, но и при наилучшем алгоритме из изначально загрубленного сигнала много не выжмешь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У тебя какое то странное понимание терминов. Нет, технологической работой занимаются отдельные люди, в чью задачу входит настройка технологических моментов программирования — VCS, CI и т.п.
Программистскую спесь поубавь. В любой производственной деятельности работники делятся на конструкторов (люди, которые видят задачу целиком и умеют разбить ее на более простые части), технологов (люди, которые видят типовые задачи и умеют сделать их решение тривиальным) и рабочих (тех кто собственно воплощает продукт в реальность). И только программисты считают себя уникальными и гордо называют себя программистами, а не какими-то там инженерами, технологами, или упаси господь рабочими. Хотя на самом деле программирование это такая же производственная деятельность и работа программистов точно также разделяется на конструкторскую, инженерную и рабочую. Разница только в том, что т.к. программисты отказываются это признавать, то в их проектах зачастую процветает кустарщина и бардак.
Так что вы занимаетесь именно технологической деятельностью. И это вовсе не ругательство, а весьма полезная деятельность.
НС>Мне кажется с самого начала было понятно, что речь не идет об найме обезьянок для шаблонного кода.
Здравствуйте, Undying, Вы писали:
I>>Правильно и здесь помогают базовые знания. Чем шире база, тем быстрее поиск решения. В уме гораздо быстрее решаются уникальные задачи, быстрее чем гугл результаты выдает.
U>Если умеешь и стремишься решать задачи, то базовые знания быстро появляются, даже в изначально незнакомой области.
Все правильно, только время надо как то учитывать. Если ты хочешь решать сложные задачи скажем в области цифровой обработки сигналов так же быстро и качественно, как и человек, который там варится 10 лет, то теб надо будет потратить сравнимое время.
I>>Теоретически можно и нагуглить, но есть люди, которые могут решать такие задачи в уме. U>Спрашивая подобные вещи ты на собеседование отберешь не тех кто умеет, а тех кто помнит.
Я большей частью даю задачи, усные и письменные и они подобраты так, что бы их нужно было решать. Шансы, что ктото их будет знать заранее, стремятся к нулю.
U>Не вижу принципиальной разницы между отбором по знанию алгоритмов и отбором по знанию Шарепоинта. И то и другое это отбор по знаниям, а не по способностям.
Способности большей частью трансформируются в прочные знания. По другому не бывает. Умение решать задачи показывает именно способности.
U>Эти какие задачи у вас программисты решают за секунды?
Разные.
>Отдел фантастики в другой ветке. Мало-мальски сложная задача, как правило, обдумывается несколько дней (хоть обычно и параллельно с какой-нибудь рутиной). Соответственно пара часов гугления по нетривиальной задаче не стоит вообще ничего.
А я где то сказал, что любые задачи решаются за секунды ? Если тебе на каждый чих гуглить надо, то я боюсь сложные задачи потребуют годы на решение.
Здравствуйте, Undying, Вы писали:
I>>Сортировка хорошо детектит разрабов вроде "у нас всё в базу упирается", "шо тут думать, трясти надо", "такое нигде не пишут"
U>Может ты и прав. Так-то согласен таких тоже как-то фильтровать надо.
Сортировка просто удачный пример, хотя и заезженый.
Здравствуйте, Undying, Вы писали:
I>>Похоже, ты близок к Нобелевской премии и это не шутка.
U>Нобелевка нынче награда политическая, а не научная и тем более не инженерная. Так что не переживай мне она точно не грозит.
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, -n1l-, Вы писали:
N>>А все почему? Потому, что есть типа идиома какая-то или закон, звучит так — "Нельзя писать велосипед!!!". V>Это правильная идиома. Нельзя писать велосипед, пока не доказано, что имеющиеся стандартные решения не удовлетворяют требованиям задачи.
N>>Любая задача сводится к тому, что она уже написана и надо просто погуглить и скопипастить код. V>Действительно уже много задач написано и в 90% процентах случаев программистской работы можно скопипастить. Но есть 10% (или сколько там процентов), где такое не пройдет.
N>>То, что этот код может быть неправильным, неподходящим для задачи или просто переусложненным игнорируется полностью. N>>Отсюда имеем плачевный результат, забери у такого "спеца" его платформу или интернет и он не способен решить ни одной проблемы. V>Если у вас все задачи на конторе попадают исключительно в 10% R&D — что невозможно.
Почему не возможно? Очень даже возможно.
А с первым высказыванием я согласен.
Здравствуйте, gandjustas, Вы писали:
G>Про ref не спрашиваем. Он слишком редко в дикой природе встречается.
У кого как, но тогда разбор ссылочных и значимых типов будет неполным.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех. G>>Ну ты как-бы сам шифруешься вечно. Уже было с десяток тем, где ты всегда уходил в "особенности", про которые никому не сказал. G>>Видимо не очень особенные эти особенности.
I>Ты хочешь что бы я выложил 10мб спецификаций ?
Нет, ты просто по русски напиши.
I>>>Предложи решение которое даст O(n) без дополнительной памяти. G>>Зачем? I>Для того, что бы сошлись концы с концами.
А почему так не сходятся? Память нинче дешевая. 4гб стоят дешевле моего дня работы. Причем сильно дешевле.
G>>>>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки. I>>>Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил. G>>Это я говорю. В серверной разработке абсолютно нет смысла заниматься оптимизацией алгоритмов, которые работают быстрее нескольких часов. I>Представляю — рендеринг картинки вместо пол-секунды займет пол-часа. Похоже это про тебя: "у нас всё в базу упирается"
Ты её можешь заранее отрендерить, а потом показывать? Может не всю, а по слоям. Сама идея слоев пришла из ГИСов, где рендерить все на лету нереально. Поэтому картинка режется на слои и рендеринг каздого оптимизируется с целью делать как можно меньше работы. Заметь — не делать как можно быстрее, а делать как можно меньше.
I>>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>>Чувак, 90% компаний этим не занимается. I>Ага, вне шарепоинта жизни нет.
Есть, и вообще SharePoint — малнькая среда. На всю Россию сотня крупных проектов. Во всем мире порядка на два больше.
Но даже это больше, чем САПРов.
