Без дополнительных подробностей тут неясно, где засада.
В самом общем случае скажу, что инженер-программист и математик-алгоритмист — это две разных специализации, ну примерно как врач-стоматолог и врач-кардиолог (хотя и у того, и у другого в дипломе написано "лечебное дело"). Ты же не пойдешь с больным зубом к кардиологу, правда?
Мне приходилось сталкиваться и с инженерами, и с алгоритмистами. Вот инжене(г)р действительно может затупить на алгоритме, написать со сложностью N^2 вместо N*log N, но зато организует код проекта с четким разбиением на подсистемы с формализованными интерфейсами, код будет простой и ясный, так что даже junior сможет его поддерживать и развивать. Наоборот, алгоритмист может придумать эффективный алгоритм, зато на его код смотреть без слез невозможно — "а что такого, у меня же все работает!", и этот код в дальнейшем отправляется прямиком в Корзину.
Нет?
Так что наверное надо начинать с того, какие скиллы более важны.....
Здравствуйте, Gattaka, Вы писали:
G>Так вот два четких кластера. Зеленые новички — легко. Зубры N*N. Да, бывают в этой статистике вбросы, но я бы сказал так. G>Что скажите?
Скажу, что у разных компаний разные цели. Если цель — пилить стандартный код, то твои "зубры" самый раз. А вот если выпустить продукт. который сильно лучше конкурентов — тут зубры с проблемами в алгоритмике не факт что помогут.
Это многослоечка такая. Когда у человека проблемы технологического плана типа мусорного кода, то на их фоне все остальное меркнет. А вот когда с кодом все более менее хорошо (а в нормальных условиях любой разработчик, если он не полный дебил, достигает этого лет за 5 промышленного опыта), вот тогда на первый план начинают вылазить другие вещи — скорость решения задач, умение решать те задачи, ответ на которые не гуглится, понимание приоритетов. Тут уже, увы, дажеко не каждый способен осилить.
А дальше все еще интереснее — инициативность, интуиция, умение общаться с остальной командой, лидерские качества, вобщем всякие soft skills и иже с ними. Здесь вообще хорошо если один из 20 дорастает, остальные и в 50 лет остаются задротами.
Здравствуйте, Gattaka, Вы писали:
G>Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
Значит тебе нечего делать в яндексе. Это не значит что ты "не тянешь", просто им нужны специалисты другого профиля, вот и все.
Здравствуйте, Gattaka, Вы писали:
G>Так вот два четких кластера. Зеленые новички — легко. Зубры N*N. Да, бывают в этой статистике вбросы, но я бы сказал так. G>Что скажите?
В Яндексе зелень отбирают, чтобы работали не за деньги, а за то, что им там позволили работать
простота — сама по себе ценна
не всегда можно себе её позволить, увы
я когда добавляю в код сложный алгоритм чувствую себя довольной свиньей
процесс приятен, но работодатель за это поплатится, когда надо будет это править
Здравствуйте, Gattaka, Вы писали:
G>Так вот два четких кластера. Зеленые новички — легко. Зубры N*N. Да, бывают в этой статистике вбросы, но я бы сказал так. G>Что скажите?
Со мной недавно подобный же случай был. Я решил не выделываться, оделся для интервью во всё коричневое, чтобы выглядеть какашкой зубром и перечитал "Растрескивание собеседования по написанию кода". А там чётко сказано: "Сначала выдайте примитивное решение, а затем его оптимизируйте". Оттарабанил я, значит, на бумажке N*N и говорю: "А вот теперь я его превращу в конфетку". А мне отвечают: "А вот теперь ваше время истекло". И правда, полчаса как-то незаметно пролетело, хотя я писал свой код без пауз. В общем, вызвали конвоира и проводили меня с вещами на выход.
А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил. Так вот теперь я эту задачу сам на собеседованиях спрашиваю. И результат меня удивил, так что я решил с вами поделиться и обсудить. Дело в том, что люди которые буквально только из универа и не знают что такое GC, что такое план запроса, что такое deadlock, не знают что в C# есть свойства (! тут я со стула чуть не упал, т.к. парень с опытом работы на C#). Так вот этот парень решает эту задачу. Но матерые зубры, которые и особенности Oracle и основные проблемы работы с TSQL и паттерны, и DI и CI и Kubernetess — просто красавец, что не спросишь реально знает, грамотно отвечает и Service Discovery и что лучше, что хуже. Видно что работал с технологиями. Даешь задачу — N*N. Зато просто, говорит он... Ну прям как я
Так вот два четких кластера. Зеленые новички — легко. Зубры N*N. Да, бывают в этой статистике вбросы, но я бы сказал так.
Что скажите?
Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
Здравствуйте, smeeld, Вы писали:
S>Тут есть какой-то психологический эффект. Не иначе. Когда у тебя за плечами годы в разработке систем без преувеличения высокой сложности, годы ковыряния в таких же, разработанных другими, с целью их дальнейшего развития или взлома, сотни тысяч строк кода на самых разных ЯП, и прочее всё такое, то те задачки, которые на собеседованиях предлагают, у тебя просто нет ни малейшего желания решать. Мозг отазывается уделять этим задачкам хоть каплю внимания где-то на уровне подсознания. Ты знаешь где-то на том же уровне, что здесь не нужно париться и что здесь нужно форсить решение с как можно меньшими временными и энергетическими затратами.
Здравствуйте, Gattaka, Вы писали:
G>Сейчас ход конем будет. Сядь чтобы не упасть. Менеджеры совсем не нужны, это лишнее звено, паразиты и не более.
Нужны и еще как. Без менеджеров административные проблемы размазываются по разработчикам. И что самое поганое, никто эти проблемы решать не будет, т.к. эти проблемы становятся проблемами разработчиков, а чтобы решать их у них полномочиев не хватает.
Здравствуйте, Gattaka, Вы писали:
G>Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
У меня есть другое объяснение. Специализация-с!
Ты работаешь с конкретными технологиями, фреймворками, а с алгоритмическими задачами в последний раз сталкивался, в лучшем случае, в школе.
А в Яндексе хотят именно алгоритмиста, а вопросы по фреймворкам решаются с полпинка на SO.
И то, и другое это опыт. Я вот напрягаться не буду и забью болт, если с меня спросят что-то экзотическое из жизни СУБД (хотя найдется что рассказать), а для тебя это шибко важное.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, vsb, Вы писали:
vsb>Хз, может в твоём мире гугл другой. Все эти особенности оракл как раз таки на первой строчке гугла и выдаются, а вот алгоритмы фиг ты найдёшь на какой строчке,
Те алгоритмы, которые спрашивают, они либо тоже на первой строчке, либо в реальной жизни не встречаются и не применяются.
За исключением прикладных алгоритмов, конечно, но они специфичны для предметной области.
Здравствуйте, IID, Вы писали:
НС>>И что там n^4 было очень непросто увидеть, код сложный. Мне часа два с профайлером понадобилось, чтобы проблему выловить. IID>Кастую landerhigh в тред, чтобы он тебе объяснил, что отладчики (и профайлеры) не нужны.
Отладчики и правда не нужны, должны храниться в сейфе под тремя замками и разработчикам выдаваться только с письменного разрешения технического директора компании.
А вот на профайлеры лично я никогда бочку не катил.
P.S. Все же интересно, почему мое имеющее объективные основания негативное отношение к порочной практике использования отладчика программистами в процессе разработки вызывает такое веселье у почтенной публики?
Здравствуйте, Gattaka, Вы писали:
G>Пока я помню провал кинопоиска, помню как в яндекс.музыке баг при проигрывании это 20% от общего числа, тут была ссылка на конкурс и в нем нельзя было зарегестрироваться по причине бага.
Ну так это все — стандартные задачи, без особого челленджа.
G>Та самая банальщина и занудство о которой вы так принибрижительно отзываетесь.
Почему пренебрежительно? Просто указываю на очевидные вещи, которые ты почему то не видишь. И, кстати, подобные проблемы, как правило, говорят о проблемах не с разработчиками, а с менеджментом. Баги есть всегда. Только одни менеджеры делают из этого выводы и налаживают процесс так, чтобы совсем уж глупые ошибки не вылезали на проде, а если уж вылезли то быстро фиксились, а другие надеются на правильных разработчиков, не делающих ошибок.
НС>>А дальше все еще интереснее — инициативность, интуиция, умение общаться с остальной командой, лидерские качества, вобщем всякие soft skills и иже с ними. Здесь вообще хорошо если один из 20 дорастает, остальные и в 50 лет остаются задротами. G>Поразительно! Но из всего перечислено не названо самое главное качество программиста. Как с его кодом работают другие программисты.
Ах, не назвал ключевое для тебя слово, кошмар.
Плохая читабельность кода это и есть одна из проблем технологического плана, о которых шла речь.
G> Это самое главное.
Это самое главное у начинающего разработчика.
G>Малозначительно насколько быстро чувак пишет код.
Это если у тебя сроки и бюджеты бесконечные и никакого давления со стороны клиентов и руководства нет.
G> Важнее как с этим кодом работают его коллеги. Если они вникают по 2 два дня в одну функцию — гоните его.
У меня таких вообще нет. И потому что код пишут те, кто детскими болячками не болеет, и потому что код читают те, кто умеет хорошо читать даже мутный код (как ты не контролируй код, но от легаси никто не застрахован).
G> Оценивайте работу команды в целом. А не одного конкретного карьеростроителя. Это типичная ошибка менеджмента у нас по крайней мере. Очень распространено.
Оценивать работу моей команды в целом — задача топов. А моя задача сделать так, чтобы каждый член команды работал максимально эффективно, поэтому я таки оцениваю каждого. И я очень хорошо вижу и слышу, что и где тормозит разработку. И уж поверь, фиговый код далеко не на первом плане. Куда больше, к примеру, проблем создает плохая технологическая культура соседних команд, с которыми приходится взаимодействовать — невнятные релизные циклы, плохое тестирование, медленная реакция на проблему и т.п. А это, как ты понимаешь, косяк менеджеров, а не разработчиков, и никаким знанием "DI и CI и Kubernetess " ее не решить.
Сейчас ход конем будет. Сядь чтобы не упасть. Менеджеры совсем не нужны, это лишнее звено, паразиты и не более. Проблемы других команд... опять довод, который негативно характерезует ваши процессы. Есть АПИ, есть абстракция, есть грамотное разделение на подсистемы или как сейчас модно микросервисы. Другие команды тебя совсем никак не трогают. Если ты замечаешь их присутсвие, а тем более релизы — у вас проблемы с кухней. Быть может вы просто скопировали свои процессы из Яндекс. Это была ошибка.
Здравствуйте, Gattaka, Вы писали:
G>Я утверждаю следующую вещь. Что самое важное, самое нужное в профессии программиста это знание важности качества кода и его читабельности для других программистов. Методы на 1000 строк, разрозненное именование переменных, использование глобальных переменных, отсутствие единого guideline. Это все на первом месте и должно спрашиваться в первую очередь везде.
Осталась только одна проблема — придумать способ как это проверить в рамках 45 мин интервью так, чтобы отсеять тех кто умеет рассуждать на эту тему от тех кто умеет это делать на практике.
Вы действительно считаете что Google, Facebook, Amazon, Bloomberg, Yandex и множество других компаний спрашивают задачки на алгоритмы только потому что не осведомлены о важности того что вы выше перечислили?
Они просто исходят из простого принципа — задачки позволяют хоть как-то формализовать критерии отбора и провести грань между брать/не брать.
Здравствуйте, The Passenger, Вы писали:
TP>это ладно — я вот тест в одну финансовую компанию проходил — там процентов на 80 были задачи на вращение треугольников — типа — TP>поверните направо налево — теперь ответьте как он лежит
Это aptitude тест был скорее всего. Тест IQ для программистов. Там ешё задачки клёвые на логику. Его обычно самым первым дают, сразу после первоначального скрининга. Очень эффективен. На нём 2/3 кандидатов сразу срезаются (зависит от того как планку выставить). Если бы можно было оставить только один тест я бы его оставил.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И что там n^4 было очень непросто увидеть, код сложный. Мне часа два с профайлером понадобилось, чтобы проблему выловить.
Кастую landerhigh в тред, чтобы он тебе объяснил, что отладчики (и профайлеры) не нужны.
Здравствуйте, ned, Вы писали:
ned>Тут всё просто. Троечнику не дадут "разворачивать треугольники". Многие выпускники приходят с honours degree. Я вижу только конечный результат отбора и мне он нравится.
Т.е. вы приглашаете вращать треугольники только обладателей honors degree, и из них 2/3 отсекаете? Ну это и есть то, что называется сиплюсплюсникам в Сиднее либо копейки, либо польку-бабочку танцевать на кастинге, пока интервьювер зевает и ковыряет в носу не знает уже, до чего до..аться.
Здравствуйте, landerhigh, Вы писали:
L>Иными словами, вас устраивают выпускники, которые не умеют делать ровным счетом нихрена. В таком случае вообще непонятно, зачем заморачиваться собеседованием — подбрасывание монетки или помещение левой стопки резюме в корзину ("нам не нужны неудачники") дадут тот же результат.
Во-первых, от выпускников ожидается скорее способность к обучению, чем умение давать результат прямо сейчас. Всегда проще научить, чем переучить. Если же политика конторы подразумевает immediate impact, то и критерии отбора другие должны быть. Во-вторых, с монеткой тяжело метрики составить и критерии формализовать, а отдел кадров требует некоторой наукообразности отбора кандидатов. В-третьих, наблюдаю, что люди, вырастающие в квалифицированных программистов, как правило, с треугольниками справляются на ура. На своём примере смею утверждать, что обратное тоже верно: гномиков не перевариваю, но и по сравнению с гугловскими молодцами тот ещё джамшут-кумар. Благо, на работе платят не за код, а за продукт. Но это классическое разредление на инженерные и программерские конторы (корпоративное обслуживание не видел, как там не знаю). Просто надо найти тот тип, который подходит конкретно тебе. А по деньгам... Деньги, вообще, тлен и дело случайное. Один знакомый пять лет назад с нвидией подписался и грант акциями получил... Уважаемый человек теперь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Видишь ли
Вижу и знаю только одно-качественный программер не проходит собеседований. Вот от слова совсем. Его просто зовут на работу. Он, возможно, соглашается. Коль скоро тут упомянут Тео, то в пример могу привести опенбздишников, многие из которых трудоустроены в гугле. И ни один из них не проходил никаких собеседований и не решал задачек. А HR если и видел, то только при оформлении трудоустройства. Можете спросить их об этом сами, подтвердят. Каждого из чуваков просто звали в гугель поработать. Точно так же и в РФ, если он разраб, и толковый, то о нём знают, и просто зазывают на работу. Он не прохоит собеседований, он просто звонит и говорит что иду к вам работать (если текущий работодатель перестаёт устраивать). Это та реальность, которую вижу. Если у кого-то не так, то он или зелёный студень, или с ним что-то не так и он нифига не профи. А с зелёными студнями, по опыту работы с ними тимлида проекта в котором сейчас принимаю участие, с ними нужно быть осторожными. Он запросто может иметь диплом Московского физтеха на отлично, влёт решать задачки для собеседований, но реально на месяцы зависать на сравнительно простых боевых задачах. Ну не заточиили его мозг думать так, как нужно думать, чтоб решать реальные боевые задачи в современном IT. Это проходит куча времени (годы) пока он перестаривает своё мышление, если у него на это хватит трудолюбия (у многих только гонор и нет никакого трудолюбия), и только тогда он становится дееспособным. Если е становится-идёт в госкорпорации с своим дипломом наперевес тупо занимать каку-то должность плевать в потолок до пенсии. Это всё факты из наблюдаемой реальности.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>S>, и оно придёт, вместе с известностью в достаточно узком кругу IT-шного мира. Кстати, разработка софта-это та самая сфера, где и "непризнанные гении" могут добиться признания, если достоин. НС>Чтобы добиться признания надо хотя бы рассказать, что ты такого сделал. Многие на это не способны.
Анекдот студенческих времен
- Что такое экзамен?
— Это разговор двух умных людей.
— А если один из них дурак?
— Тогда другой отправится на переэкзаменовку.
Бесполезно рассказывать о своем опыте разработки сетевых устройств человеку, для которого сетевое программирование ограничивается сакральным знанием о том, как открыть сокет, вычитанным за 15 минут до собеседования из википедии, а протоколов, кроме TCP, не существует.
Здравствуйте, landerhigh, Вы писали:
L>Иными словами, вас устраивают выпускники, которые не умеют делать ровным счетом нихрена. В таком случае вообще непонятно, зачем заморачиваться собеседованием
Если выбрать лучших и потратить несколько месяцев на обучение (в том числе и на рабочих проектах), то через год половина из них будет не хуже сеньора с много-много лет опыта воротящего нос от тестов.
Повторюсь: мне не важно как отбирают людей я вижу конечный результат – коллег умных, быстросоображающих, легкообучаемых и с минимальным количеством тараканов в голове.
И да, я когда-то прошёл этот тест "с треугольниками". Это был фан. Всегда любил кроссворды с шарадами
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Ага. И потом сидят такие суперпрактики и чинят. Вот только чинят они не сложность, а демонстрируют чудеса битовыжимания. Константу починят, а О(n дохрена) осталась как была. E>А вот как с минимальными изменениями исходного алгоритма починить сложность — какого то черта с этой простейшей практической задачей не могут справиться большинство любителей преждевременной оптимизации. У большинства оптимальные решения конкретных задач тупо зазубрены в лучшем случае. Сделать конфетку по сложности с минимальной модификацией исходного кода какого то черта могут единицы. Все полностью переписать чтоб ускорить за черти какое время при неизменных условиях — здесь много ума не надо. На практике зачастую для ускорения в тысячи раз достаточно точечных локальных изменений, которые очень быстро как делаются, так и находятся. При условии нормальной декомпозиции это вообще не задача.
О, даааа!!! Декомпозиция это нашефсё...
Разделили на уровни, на одном уровне всё линейно, и на другом уровне тоже всё линейно. А в сумме получаем квадратичную сложность. Это мы уже проходили.
Вроде бы тут собрались не студенты, а старые саксаулы аксакалы.
Увы, джентльмены, начинать с намеренной пессимизации не прокатывает.
Обычно, если делается тупо в лоб, то это решение так и остается навеки в коде и выдрать его можно только с большим трудом. Студентов на уроках ООП учат про абстракцию данных, полиморфизм... как мы чудесным образом меняем алгоритмы и структуры данных не надо переделывать (или наоборот, кромсаем структуры данных и алгоритмы неизменны).
Хрентамбыл! Структуры данных это первоочередной момент, определяющий эффективность алгоритма. Нельзя состряпать по-быстренькому структуры данных, реализовать на нем наивный алгоритм, а потом лихо, если потребуется, переписать алгоритм. Переписывать приходится всё, включая интерфейсы.
Я не топикстартер, я уже 20+ лет занимаюсь не технологиями, а именно алгоритмами. Нету готовых библиотек, всё приходится делать либо с нуля, либо адаптировать что-то, описанное в статьях. Тут любое упрощение архитектуры на начальном этапе впоследствии выливается в переписывание всего кода.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, The Passenger, Вы писали:
TP>Здравствуйте, ksandro, Вы писали:
K>>Догадываюсь, что это за компания...
TP>Они, к стати, сейчас на хакерранк тесты перешли — это я еще могу понять ... хотя там тоже пару раз фэйлился, но в другие конторы
Да, на хакерранк перешли уже давно. Но со слов собеседующих там тоже все так гладко. Было несколько случаев когда, после прекрасных результатов на хакерранке на собеседование приходил чувак, вообще плохо представляющий, что такое программирование. Ну еще помню что мне показывали одну задачку по плюсам на которую хакерранк считал явно неправильный ответ правильным.
K>>В свое время в школе на уроках черчения я обнаружил у себя талант к подобным задачам. Но, так как я терпеть не мог черчение, то считал этот талант абсолютно бесполезным. Никогда бы не догадался, что бесполезное умение поворачивать в уме треугольники в будущем так сильно повлияет на мою жизнь
TP>Работаешь там? TP>Думаю еще раз попробовать осенью
Работал в одной из этих Амстердамских финансовых конторок, но я довольно быстро осознал, что Голландия — это не мое, прожил там полтора года и вернулся в Россию.
Вообще, там работается хорошо, но есть свои ньюансы. Несмотря на очень неплохие, даже по голландским меркам, условия, текучка кадров довольно большая.
K>>До сих пор не могу понять, зачем давать программистам такие тесты, это блин даже не IQ тест и не задачи про гномиков... Он никак не проверяет абстрактное логическое мышление, которое нужно программисту. Ну, я еще могу понять если бы надо было программировать терхмерную графику, но к финансам это вообще не имеет никакого отношения (трейдеры кстати совсем другой тест проходят).
TP>на самом деле, я так полагаю, это тест на возможность представления и просчета алгоритма по шагам в голове ... но мне, если надо, я рисую.
Ну, не знаю, у меня было ощущение, что мне просто повезло, никих навыков, нужных именно программисту в этом тесте не проверялось. Знаю очень крутых разработчиков (в разы круче меня), которые с треском проваливали этот тест.
TP>... но всеравно — они както умудряются описать задачи, вроде и по английски, но после одного прочтения нифига не понятно
Ну это да, я в свое время так несколько собеседований завалил, пока читал задачу по английски, и пытался понять, что ж там надо сделать время заканчивалось
План определяет, как именно SQL сервер будет вычислять ответ на запрос. В каком порядке читать из каких таблиц, какими индексами пользоваться, т.е. как именно сервер собирается обращаться к своим B-Trees на диске.
Хз, может в твоём мире гугл другой. Все эти особенности оракл как раз таки на первой строчке гугла и выдаются, а вот алгоритмы фиг ты найдёшь на какой строчке, только прорешивать тысячи олимпиадных задачек, чтобы они в подкорку запали. Другой вопрос, что в работе оно мне лично ни разу не пригождалось за 10 лет, но я и не в яндексе работаю.
Здравствуйте, Gattaka, Вы писали:
G> Что самое важное, самое нужное в профессии программиста это знание важности качества кода и его читабельности для других программистов.
В любой крупной организации (да и не обязательно крупной) есть свои старослужащие, которые лучше тебя знают сколько у кода должно быть отступов, как он должен выглядеть, чтобы им было проще его читать и вот это все.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Gattaka, Вы писали:
G>>Так вот два четких кластера. Зеленые новички — легко. Зубры N*N. Да, бывают в этой статистике вбросы, но я бы сказал так. G>>Что скажите?
НС>Скажу, что у разных компаний разные цели. Если цель — пилить стандартный код, то твои "зубры" самый раз. А вот если выпустить продукт. который сильно лучше конкурентов — тут зубры с проблемами в алгоритмике не факт что помогут.
Пока я помню провал кинопоиска, помню как в яндекс.музыке баг при проигрывании это 20% от общего числа, тут была ссылка на конкурс и в нем нельзя было зарегестрироваться по причине бага. Продукты пока низкокачественные и для хорошей идеи нужна не только быстрая реализация, но хорошо рабочая оболочка. Та самая банальщина и занудство о которой вы так принибрижительно отзываетесь.
НС>Это многослоечка такая. Когда у человека проблемы технологического плана типа мусорного кода, то на их фоне все остальное меркнет. А вот когда с кодом все более менее хорошо (а в нормальных условиях любой разработчик, если он не полный дебил, достигает этого лет за 5 промышленного опыта), вот тогда на первый план начинают вылазить другие вещи — скорость решения задач, умение решать те задачи, ответ на которые не гуглится, понимание приоритетов. Тут уже, увы, дажеко не каждый способен осилить. НС>А дальше все еще интереснее — инициативность, интуиция, умение общаться с остальной командой, лидерские качества, вобщем всякие soft skills и иже с ними. Здесь вообще хорошо если один из 20 дорастает, остальные и в 50 лет остаются задротами.
Поразительно! Но из всего перечислено не названо самое главное качество программиста. Как с его кодом работают другие программисты. Это самое главное. Вы знаете, что тактика современных боевых действий это ранить как можно больше противников. Потому что раненый парализует армию. Его нужно доставить в госпиталь, его нужно эвакуировать с поля боя.
Малозначительно насколько быстро чувак пишет код. Важнее как с этим кодом работают его коллеги. Если они вникают по 2 два дня в одну функцию — гоните его. Оценивайте работу команды в целом. А не одного конкретного карьеростроителя. Это типичная ошибка менеджмента у нас по крайней мере. Очень распространено.
Это почему же? Этот поступок показывает, что ГГ(ТС) имеет навык обучения и владеет техникой "бенчмаркинг".
Он увидел лучшую практику и внедрил её в своей компании. В чём глупость?
Z> Надеюсь ты владелец компании куда собеседуешь людей, иначе
Роль в компании никак не влияет на соответствие методики найма (кому/чему) стратегии компании. Если он как сотрудник видит, что такой приём хорош для стратегии его компании, то почему его не перенять? Для этого не обязательно быть директором. Права/полномочия у сотрудника все есть.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Gattaka, Вы писали:
G>>Так вот теперь я эту задачу сам на собеседованиях спрашиваю.
MD>Так а сама задача какая?
не говорит — видимо опозоритья боится
что нибудь типа списка развернуть
Здравствуйте, zubr, Вы писали:
Z>Поправьте меня, но мне казалось что смотрят не только на способность решить задачу, но также и на фактор того как человек думает и как решает. Z>Способен ли довести до лучшего решения порой не так важно, сколько важно — умение задавать вопросы и уточнять условие задачи, потому что порой условие специально оставляют немного не точным.
Да. И это тоже можно формализовать. К примеру, даётся задача на дизайн системы и 10 минут подумать. +1 поинт – если задал вопрос по условиям задачи. +5 – если нарисовал решение и сумел внятно объяснить. +10 – если решил правильно (обычно несколько верных вариантов/направлений). Затем задача усложняется. +10 – если успешно адаптировал систему и ничего не сломал. +5 – если решил быстро. И так далее.
Z>Причем второй интервьювер не знает задачу заранее, это может показать как вообще человек умеет работать в команде (может слышали о таком опыте — поделитесь!).
Здравствуйте, ned, Вы писали:
L>>Ты, наверное, хотел сказать, "крутят пальцем у виска и уходят", да? ned>У меня такой статистики нету Но это тоже хорошо. "Не очень-то и хотелось" значит.
Это хорошо ровно до тех пор, пока вы можете довольствоваться теми, кому "очень-то хочется".
Впрочем, хозяин — барин
Здравствуйте, ned, Вы писали:
ned>Тут всё просто. Троечнику не дадут "разворачивать треугольники". Многие выпускники приходят с honours degree. Я вижу только конечный результат отбора и мне он нравится.
Иными словами, вас устраивают выпускники, которые не умеют делать ровным счетом нихрена. В таком случае вообще непонятно, зачем заморачиваться собеседованием — подбрасывание монетки или помещение левой стопки резюме в корзину ("нам не нужны неудачники") дадут тот же результат.
Здравствуйте, landerhigh, Вы писали:
L>На минутку — речь идет об Австралии.
Не, я более обше. Австралия, прямо скажем, не трендсеттер в области best hiring practices в IT, поэтому нужно думать немножко down under: не смотреть, что было бы логично делать исходя из местных реалий, а прикидывать как натянуть условного майкрософтовского гномика на пробегающего мимо кенгуру. L>Соответственно, в Австралии выпускник универа по определению умеет и хочет учиться.
Нашёл чем удивить. Они везде сейчас такие. Далее нужно как-то ранжировать и отобрать тех, кто умеет и хочет более лучше. Задачки с хакерранка — не самый проигрышный вариант, как мне видится. С точки зрения меня как нанимаюшего менеджера, остальной команды, вышестоящего начальства, отдела кадров, да и самого кандидата, наверное. Особенно, если оборот людей большой и нанимаются не прямо вот под конкретный горящий проект, а чтобы человек хороший был в обойме на случай ядерной войны.
Здравствуйте, El Camino Real, Вы писали:
L>>Соответственно, в Австралии выпускник универа по определению умеет и хочет учиться. ECR>Нашёл чем удивить. Они везде сейчас такие. Далее нужно как-то ранжировать и отобрать тех, кто умеет и хочет более лучше.
Ранжировать? С добрым утром
Те, кто умеет и хочет более лучше, к моменту выпуска уже либо в гугле-фейсбуке или хеджфонде каком, либо свой стартап пилят.
Среди остальных, что треугольники поворачивай, что монетку кидай — результат будет один. Возможно, с монеткой даже получше выйдет.
Здравствуйте, alzt, Вы писали:
A>Просто, чтобы что-то получалось, этим надо заниматься. В разработке очень редко приходится решать какие-то серьёзные алгоритмические задачки. Достаточно писать алгоритм со сложность N * log N вместо квадрата. Поэтому такой навык не развивается у большинства и знания постепенно забываются. Исключение это преподы и интервьюэры.
На самом деле во многих случаях достаточно квадрата, если квадрат работает нормально на расчетных данных. Вот мне на практике несколько раз требовалось писать топологическую сортировку. Я ее всегда писал с квадратичной сложностью. За 5 минут — применяю метод обхода каждой ноды и дергаю у всего этого size, и это натравливаю на стандартный sort — все. Весьма понятный и очевидный код получается, хоть и потенциально медленный. Ибо пофиг, это совсем не критичное место и N не превышает 100 в самом худшем случае. Если же это окажется вдруг проблемным местом, я сначала возьму простой трюк мемоизации, причем универсальной, над одним методом, в результате на практических задачах уже это будет N log N практически. Если N log N тоже маловато окажется и проблема в асимптотике — ну применю какой нидь bucket sort, в результате будет уже N (на практике кстати необходимости пока ни разу не было). Причем потрачу весьма мало времени. А реальный эффективный алгоритм, но более сложный, я буду использовать только тогда, когда окажется что вот такие быстрые оптимизации недостаточно эффективны, а память желательно поэкономить.
Ибо все просто — чем более оптимизированный код, тем он всегда сложнее читается, тем сложнее там что то менять. И без крайней необходимости лучше код не запутывать. Какого хрена мне оптимизировать пусть даже секунду на топологической сортировке, если то, ради чего эта сортировка выполняется, гоняется вообще несколько часов потом на кластере стандартной коммерческой дорогой и крайне оптимизированной решалкой. Что, закон Амдала отменили чтоль ?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну вот ты и продемонстрировал наглядно, зачем нужны задачки. Потому что O(N) алгоритмы абсолютно тривиальны, да и их писать обычно не нужно.
Если копнуть глубже, есть улучшения как например
A space-efficient algorithm for finding strongly connected components David J.Pearce
Но когда чел городит O(n*n) на ровном месте (а скорее там O(n*n*log n) и не пытается разобраться, как оптимально, это плохо.
E>>Ибо все просто — чем более оптимизированный код, тем он всегда сложнее читается
Декомпозиция для чего? Так то можно и всё приложение одной портянкой из спагетти сделать.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, alzt, Вы писали:
A>>Там же алгоритм имеет O(N). E>На многих задачах реально на практике пофиг — N это или N*N. Даже экспонента может сойти, никто и не заметит при N = 10, когда известно что N что N никогда больше не будет. А если заметят и вдруг окажется узким местом — ловится все на раз, и чинится.
Ага. И потом сидят такие суперпрактики и чинят. Вот только чинят они не сложность, а демонстрируют чудеса битовыжимания. Константу починят, а О(n дохрена) осталась как была.
Здравствуйте, ned, Вы писали:
E>>А если заметят и вдруг окажется узким местом — ловится все на раз, и чинится. ned>А ракета уже упала. Чинить поздно.
Ага. И упала она потому, что какой-то умник заменил O(N^2) на O(N), чем похерил тайминги. Или, что еще более вероятно, устроил локальный расстрел памяти. Или все вместе.
Чтобы ракеты не падали, нужно не на алгоритмы этосамое вприсядку. Нужно тестировать. Тестировать все и во всех возможных вариантах.
А за использование отладчика выгонять с волчьим билетом.
Здравствуйте, landerhigh, Вы писали:
L>Ага. И упала она потому, что какой-то умник заменил O(N^2) на O(N), чем похерил тайминги. Или, что еще более вероятно, устроил локальный расстрел памяти. Или все вместе.
Поэтому нужно сразу писать O(N). А так да, "рефакторинг без причины – признак дурачины".
L>Чтобы ракеты не падали, нужно не на алгоритмы этосамое вприсядку. Нужно тестировать. Тестировать все и во всех возможных вариантах.
Там проблема в том что и софт и железо разрабатываются одновременно. Годами.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, uncommon, Вы писали:
U>>Я так понял, ты менеджер?
НС>А еще у меня 20 лет опыта разработчика. Так что все равно у меня длиннее.
К сожалению это мало о чем говорит. Есть такие ребята которым не повезло и они 20 лет работали с менеджерами и знать не знали и представить себе не могли что может быть иначе. В итоге такие ребята становятся менеджерами и окончательно запирают перспективы своего развития. Ведь если ты менеджер, то не имеешь уже шанса понять как работают без менеджеров. Стал таки драконом.
Здравствуйте, SergASh, Вы писали:
SAS>А задачу-то можно озвучить?
Ну я слышал краткий вариант в таком виде.
Гномы отмечали день рождения Белоснежки и немного перебрали сладкого сиропа. За долгие годы в коллективе набрались взаимные претензии у каждого к каждому, но они существа добрые и любой третий не позволит двоим подраться. Всем гномам надо перебраться по мостику через ущелье, но мост ограничен по номинальной нагрузке по проекту, не более N гномов за раз, но, как нам известно, мосты проектируются с допусками в X процентов сверху нагрузки. X неизвестен из-за того, что Железный Дровосек уехал на курорт на профилактику и не осматривал техническое состояние моста. За время его отсутствия злобные Марраны угрожали Страшиле Мудрому и для устрашения сожгли одну шину на мосту, образовалась дырка круглой формы. В эту дырку проросло дерево. Страшила не поддался на провокации, Марраны через несколько лет сожгли вторую покрышку. Гномам нужно преодолеть дырку и перебраться на другую сторону, пока не наступила ночь и злобный людоед не сожрал иж. Они надели разноцветные колпаки, взяли квадратную крышку от люка и пошли на другую сторону. Обошли дерево вглубину и краем глаза заметили какой-то сундук высоко в густых ветвях. Время поджимало и крышка тяжелая. После обхода дерева они прошли дальше, дошли до дырки от сгоревшей шины, положили крышку. Поскольку они любопытные, они развернулись нерекурсивно и пошли назад. После разворота кто-то зацепился за длинную одежду товариша и им пришлось определять место цикла и отцеплять друг дружку чтобы снова получить нормальную связность. Подощли к дереву и начали обходить его в ширину, нашли сундук с золотыми монетами. Поделили клад так, что каждому в каждый его карман положили по монетке. У всех разное число карманов, но известно что их не более 16 и не менее 12 у каждого из гномов. Всем дали по монетке разных номиналов, так чтобы ни у одного в отдельности не было двух монет одного номинала. В итоге у каждого оказалась равная сумма. Они развернулись в этот раз уже рекурсивно и продолжили путь. По достижению другого края они нашли кучку блинов разного размера на одном блюде, прикрепленном цепью к камню. Рядом находялось еще два пустых блюда, одно тоже с цепью, другое свободное. Они при помощи лопаток перенесли блины на блюдо, которое не прикреплено к камню и продолжили путь. Зашли в замок к Кощею и за сумму в K денег выкупили у него прекрасную принцессу Элли, собрав деньги L различными способами из своих карманов. После этого нажрались булочек с маком, которые добрые Жевуны раздавали рядом с полем и нетвердой походкой горланя песни дошли до города, где устроили пир и накормили всех блинами.
Вопрос: во сколько обойдется Страшиле Мудрому ремонт дороги, моста с путепроводом нектара, восстановление макового поля и поиски загулявшего Дровосека. Нужно ли брать кредит у подземных королей или лучше распродать земли вокруг города? Какова зависимость затрат по времени и по ресурсам от числа гномов?
Бонусные вопросы.
Насколько изменится время, если вместо летающих обезьян материалы для ремонта будут доставлены на автомобиле Винтика и Шпунтика?
Перечислите плюсы и минусы привлечения разных исполнителей для ремонта: гномов, деревянных солдат, жителей города, сельских жителей.
Как Страшиле Мудрому избежать обвинений в растрате бюджета и покрывательстве промахов Железного Дровосека?
Стоит ли Храброму Льву принимать участие в тендере на охрану строительных работ и как ему победить в заявке против саблезубых тигров?
Какие организационные выводы должны последовать из происшествия для уменьшения возможности повторения? Стоит ли вводить запрет на угощение медовым сиропом после двух часов дня или ограничиться выговором Белоснежке? Провести ли референдум о легалайзе или скосить маковое поле и посадить ромашки?
Каким образом вести контроль работ и раздачу задач: водопадом, канбаном, скрамом или прочим аджайлом?
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, Эйнсток Файр, Вы писали:
G>> нет мотивации решать и даже напрягаться из-за нудной фигни...
ЭФ>RussianFellow подобный зубр. Ему лень напрягаться из-за всякой фигни, если можно просто спросить на rsdn.
ЭФ>Ведь реально у него много опыта и широкий кругозор.
Нет, опыт должен быть релевантным. Т.е. при разработке enterprise приложений есть определенные паттерны. Буквально это штук 40 книг достаточно прочитать. Так вот у RussianFellow опыт другой. Ну вот давайте спросим его без гугла он тестирует состояние или поведение в своих проектах? RussianFellow вы здесь?
Здравствуйте, Gattaka, Вы писали:
G>Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
Просто, чтобы что-то получалось, этим надо заниматься. В разработке очень редко приходится решать какие-то серьёзные алгоритмические задачки. Достаточно писать алгоритм со сложность N * log N вместо квадрата. Поэтому такой навык не развивается у большинства и знания постепенно забываются. Исключение это преподы и интервьюэры.
Здравствуйте, Vlad_SP, Вы писали:
V_S>ну примерно как врач-стоматолог и врач-кардиолог (хотя и у того, и у другого в дипломе написано "лечебное дело").
А вот и нет, у всех врачей написано "лечебное дело", а у стоматолога — "стоматология"
V_S>Наоборот, алгоритмист может придумать эффективный алгоритм, зато на его код смотреть без слез невозможно — "а что такого, у меня же все работает!", и этот код в дальнейшем отправляется прямиком в Корзину.
Подтверждаю. Был случай — математик(весьма продвинутый) писал код, причем архитектура с виду правильная, но слишком сложно и все тормозило жутко.
Очень удивился, что я смог разобраться и найти узкое место тк он сам несколько месяцев над этим бился.
Ну, "архитектура с виду правильная, но слишком сложно и все тормозило жутко" — это еще полбеды. А то и вообще не беда.
Беда — это код математика с функциями по полторы-две тысячи строк, юзающими к тому же кучу глобальных переменных с очень информативными именами типа i, ii, iii, k, kk, kkk.... "ну а что, работает же!"
Здравствуйте, Gattaka, Вы писали:
G>А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил.
Тут есть какой-то психологический эффект. Не иначе. Когда у тебя за плечами годы в разработке систем без преувеличения высокой сложности, годы ковыряния в таких же, разработанных другими, с целью их дальнейшего развития или взлома, сотни тысяч строк кода на самых разных ЯП, и прочее всё такое, то те задачки, которые на собеседованиях предлагают, у тебя просто нет ни малейшего желания решать. Мозг отазывается уделять этим задачкам хоть каплю внимания где-то на уровне подсознания. Ты знаешь где-то на том же уровне, что здесь не нужно париться и что здесь нужно форсить решение с как можно меньшими временными и энергетическими затратами.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Беда — это код математика с функциями по полторы-две тысячи строк, юзающими к тому же кучу глобальных переменных с очень информативными именами типа i, ii, iii, k, kk, kkk.... "ну а что, работает же!"
Не, я обычно использую аргументацию "ну, перепиши!". Даже могу поспособствовать выделению бюджета. Но программисты всё равно взвывают.
Здравствуйте, koenig, Вы писали:
K>как так? уж на что я веб-макака, и то переодически сталкиваюсь. на графах легко напороться на сильно больше, чем n^2, например
Ну а что требуется-то? Максимум обойти все элементы ациклического графа, или найти путь от одной вершины до другой. Поиск и разрыв циклов в графе может потребуется раз в 5 лет, и то с ходу сложно придумать зачем.
Здравствуйте, copypaste, Вы писали:
C>Здравствуйте, Gattaka, Вы писали:
G>>Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни... C>Значит тебе нечего делать в яндексе. Это не значит что ты "не тянешь", просто им нужны специалисты другого профиля, вот и все.
А вот это то я и оспариваю. Я утверждаю следующую вещь. Что самое важное, самое нужное в профессии программиста это знание важности качества кода и его читабельности для других программистов. Методы на 1000 строк, разрозненное именование переменных, использование глобальных переменных, отсутствие единого guideline. Это все на первом месте и должно спрашиваться в первую очередь везде. Это важнее алгоритмов в любой софтверной компании. Понимание этой вещи приходит с опытом работы. Сразу после университета самым важным предполагаются бывшими студентами алгоритмы.
И я имею право так говорить, потому что на одной из прошлых работ у меня были крайне впечатляющие достижения по улучшению работы системы за счет выбора нестандартного (не описанного у Кнута) алгоритма и структуры данных к нему.
Надеюсь свою мысль донес.
Здравствуйте, koenig, Вы писали:
A>>Просто, чтобы что-то получалось, этим надо заниматься. В разработке очень редко приходится решать какие-то серьёзные алгоритмические задачки. K>как так? уж на что я веб-макака, и то переодически сталкиваюсь. на графах легко напороться на сильно больше, чем n^2, например
Лично чинил n^4 на сложном графе. Сериализация UI форм была. Пока формы были сравнительно небольшие, а компы у клиентов хорошие — все было прекрасно. А потом появилась формочка на 2М XML и совсем уж неприличное клиентское железо, и оно повылазило по полной.
Причем накосячил очень неплохой в целом разработчик, просто молодой еще на тот момент. И что там n^4 было очень непросто увидеть, код сложный. Мне часа два с профайлером понадобилось, чтобы проблему выловить.
Здравствуйте, Gattaka, Вы писали:
G>Сейчас ход конем будет. Сядь чтобы не упасть. Менеджеры совсем не нужны, это лишнее звено, паразиты и не более.
Менеджеры нужны всегда, когда в команде больше одного человека.
G> Проблемы других команд... опять довод, который негативно характерезует ваши процессы. Есть АПИ, есть абстракция, есть грамотное разделение на подсистемы или как сейчас модно микросервисы. Другие команды тебя совсем никак не трогают.
Да хоть обделись. Если у тебя очередная версия вдруг меняет поведение в чем то, то очень даже трогает.
G> Если ты замечаешь их присутсвие, а тем более релизы — у вас проблемы с кухней.
Я и написал про то что имеют место проблемы. Ты чего сказать то хотел?
Здравствуйте, Gattaka, Вы писали:
G>А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил. Так вот теперь я эту задачу сам на собеседованиях спрашиваю.
Надеюсь ты владелец компании куда собеседуешь людей, иначе твой поступок выглядит достаточно глупым.
Здравствуйте, Gattaka, Вы писали:
G>А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил. Так вот теперь я эту задачу сам на собеседованиях спрашиваю.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, Gattaka, Вы писали:
G>>А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил. Так вот теперь я эту задачу сам на собеседованиях спрашиваю. Тё>OMG яндекс нанес тебе душевную травму.
Здравствуйте, Gattaka, Вы писали:
G>Я объясняю это следующим образом на своем примере. Для меня попросту не интересно решать такую нудную комбинаторику, ее легко нагуглить. А вот реальные проблемы как организовать код — гораздо важнее и тут уже не нагуглишь, тут нужен только опыт. Именно поэтому нет мотивации решать и даже напрягаться из-за нудной фигни...
это ладно — я вот тест в одну финансовую компанию проходил — там процентов на 80 были задачи на вращение треугольников — типа —
поверните направо налево — теперь ответьте как он лежит
TP>это ладно — я вот тест в одну финансовую компанию проходил — там процентов на 80 были задачи на вращение треугольников — типа — TP>поверните направо налево — теперь ответьте как он лежит
TP>вот я до сих пор в недоумении
TP>отнесся несерьезно и не прошел.
Это все меня удивляет.
Здравствуйте, lintik, Вы писали:
L>Они просто исходят из простого принципа — задачки позволяют хоть как-то формализовать критерии отбора и провести грань между брать/не брать.
Совершенно верно. Не так важно что спрашивать. Намного важнее иметь возможность эффективно сравнить кандидатов по каким-то хорошо определённым критериям.
Здравствуйте, ned, Вы писали:
ned>Это aptitude тест был скорее всего. Тест IQ для программистов. Там ешё задачки клёвые на логику. Его обычно самым первым дают, сразу после первоначального скрининга. Очень эффективен. На нём 2/3 кандидатов сразу срезаются (зависит от того как планку выставить). Если бы можно было оставить только один тест я бы его оставил.
А есть корелляция между "тестом на iq" и успеваемостью? Например, чел почти круглый отличник, но при этом попадает слева от колокола. И обратная ситуация, распиздяй- троечник (например, не знает про банальный big-O), а тесты на треугольнички выбивает справа от колокола.
Здравствуйте, ned, Вы писали:
ned>Здравствуйте, lintik, Вы писали:
L>>Они просто исходят из простого принципа — задачки позволяют хоть как-то формализовать критерии отбора и провести грань между брать/не брать.
ned>Совершенно верно. Не так важно что спрашивать. Намного важнее иметь возможность эффективно сравнить кандидатов по каким-то хорошо определённым критериям.
Поправьте меня, но мне казалось что смотрят не только на способность решить задачу, но также и на фактор того как человек думает и как решает.
Способен ли довести до лучшего решения порой не так важно, сколько важно — умение задавать вопросы и уточнять условие задачи, потому что порой условие специально оставляют немного не точным.
А дальше смотрим как человек решает задачу, хотя мне казалось что самое веселое было бы — иметь двух человек (один дает задачу, а со вторым ты её решаешь).
Причем второй интервьювер не знает задачу заранее, это может показать как вообще человек умеет работать в команде (может слышали о таком опыте — поделитесь!).
Здравствуйте, Тёмчик, Вы писали:
Тё>А есть корелляция между "тестом на iq" и успеваемостью? Например, чел почти круглый отличник, но при этом попадает слева от колокола. И обратная ситуация, распиздяй- троечник (например, не знает про банальный big-O), а тесты на треугольнички выбивает справа от колокола.
Ты именно про успеваемость или про успешность (функциональность) на рабочем месте? Вот хороший пример это интерны и выпускники. Их отбирают на основе IQ-подообных тестов фактически. Опыта работы у них нет. Знание предметной области нулевое. Из сотни кандидатов остаётся десяток, после испытательного срока ещё на несколько человек меньше. Но в итоге оставшиеся через пару лет выходят на уровень сеньоров с 10+ опытом. И работать с ними легко – всё схватывают на лету и думают быстро.
Здравствуйте, ned, Вы писали:
ned>Это aptitude тест был скорее всего. Тест IQ для программистов. Там ешё задачки клёвые на логику. Его обычно самым первым дают, сразу после первоначального скрининга. Очень эффективен. На нём 2/3 кандидатов сразу срезаются (зависит от того как планку выставить). Если бы можно было оставить только один тест я бы его оставил.
мне чисто для себя — как часто вы вращаете треугольники на работе?
а то я, как дурак, все время на собеседованиях спрашивал, то что по работе нужно
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Очень похоже на отмазку.
Да как угодно. Если ты приходишь с людьми поговорить об интересном, а они тебе какую-то чухню под нос пихают, то меньше всего заботит что эти люди о тебе подумают. Всё-таки стоит как-то разделять матёрого чела и зелёного студня. Предложите Тео порешать какую-либо задачку, он пошлёт даже не задумываясь над ней и прав будет. Это какой-то компании Я. нужны спецы, спецы же и без этой компании без проблем обойдутся.
Здравствуйте, ned, Вы писали:
ned>Ты именно про успеваемость или про успешность (функциональность) на рабочем месте? Вот хороший пример это интерны и выпускники. Их отбирают на основе IQ-подообных тестов фактически. Опыта работы у них нет. Знание предметной области нулевое. Из сотни кандидатов остаётся десяток,
Например, один кандидат- троечник, всё списывал и с трудом закрывал хвосты. Но Эти кретинские тесты на кручение треугольников выбивает лучше, чем 90%. И другой кандидат, отличник, у которого троечник списывал. Но который слаб в кручении треугольников (заметь- не в развороте гномиков!). Его срежут этим первым тестом. Теперь внимание: кто решит поставленную задачу- тот кто сам всё решал и другим помогал в юни, или троечник, который всё у всех списывал?
Здравствуйте, Тёмчик, Вы писали:
Тё>Теперь внимание: кто решит поставленную задачу- тот кто сам всё решал и другим помогал в юни, или троечник, который всё у всех списывал?
Тут всё просто. Троечнику не дадут "разворачивать треугольники". Многие выпускники приходят с honours degree. Я вижу только конечный результат отбора и мне он нравится.
Хотя отличников и отличниц не умеющих написать и пары строчек осмысленного кода по окончании технического вуза видел в РФ. Тестеры из них получались неплохие
Здравствуйте, ned, Вы писали:
ned>Здравствуйте, landerhigh, Вы писали:
ned>Повторюсь: мне не важно как отбирают людей я вижу конечный результат – коллег умных, быстросоображающих, легкообучаемых и с минимальным количеством тараканов в голове.
Выше среднего народу ушло или помогли уйти за последние несколько лет, после такого отбора. А за остальными бегают с секундомером, чтобы норму выдавали, а также были духовно мотивированы. В чем смысл прохождения такого отбора, чтобы потом попасть в потогонку?
Здравствуйте, mmu, Вы писали:
mmu>В чем смысл прохождения такого отбора, чтобы потом попасть в потогонку?
Деньги. Бабло побеждает зло как обычно.
Иначе никак если хочешь осилить 1.5 млн. домик (цена чуть выше медианной) в Сиднее к пенсии. Или в штаты ехать. Вот уже даже Тёмчик собирается.
Здравствуйте, ned, Вы писали:
ned>Иначе никак если хочешь осилить 1.5 млн. домик (цена чуть выше медианной) в Сиднее к пенсии. Или в штаты ехать. Вот уже даже Тёмчик собирается.
Если цель- дом к пенсии, то можно продать здесь юнит и купить в Голд-Косте дом недалеко от пляжа. Насчёт "Темчик собрался в штаты ехать", рано разводить спекуляции. Пока у меня нет планов на подачи, ибо я не один в вакууме. Но между "потогонка до пенсии в Сиднее" и "ненапряжная жизнь в Нью-Йорке" я бы выбрал второе. Суть в том, что сейчас у меня нет потогонок в Сиднее.
Здравствуйте, The Passenger, Вы писали:
TP>Здравствуйте, ned, Вы писали:
ned>>Это aptitude тест был скорее всего. Тест IQ для программистов. Там ешё задачки клёвые на логику. Его обычно самым первым дают, сразу после первоначального скрининга. Очень эффективен. На нём 2/3 кандидатов сразу срезаются (зависит от того как планку выставить). Если бы можно было оставить только один тест я бы его оставил.
TP>мне чисто для себя — как часто вы вращаете треугольники на работе?
TP>а то я, как дурак, все время на собеседованиях спрашивал, то что по работе нужно
Кстати, действительно, как дурак.
Здравствуйте, Тёмчик, Вы писали:
Тё>Если цель- дом к пенсии, то можно продать здесь юнит и купить в Голд-Косте дом недалеко от пляжа.
А можно продать дом, купить дом на ГК и ещё миллион кешем останется для комфортной жизни на пенсии.
Тё>Но между "потогонка до пенсии в Сиднее" и "ненапряжная жизнь в Нью-Йорке" я бы выбрал второе.
Здравствуйте, El Camino Real, Вы писали:
ECR>Во-первых, от выпускников ожидается скорее способность к обучению, чем умение давать результат прямо сейчас.
На минутку — речь идет об Австралии. Где ВО, во-первых, весьма платное, а во-вторых, не очень и в почете. Проще пойти в ПТУ на пару лет и к моменту, когда выпускников инженерных специальностей еще только начинают подпускать к переворачиванию треугольников, уже заколачивать шестизначный доход, "вкалывая" с семи до трех с перерывом на серф и пиво.
Соответственно, в Австралии выпускник универа по определению умеет и хочет учиться.
E>Вот мне на практике несколько раз требовалось писать топологическую сортировку. Я ее всегда писал с квадратичной сложностью. За 5 минут — применяю метод обхода каждой ноды и дергаю у всего этого size, и это натравливаю на стандартный sort — все.
я тупой, не вдупляю, объясни пожалуйста, причем тут size
и если ты их уже обошел(в глубину)-ты по дороге мог список сформировать, зачем еще что-то?
Здравствуйте, smeeld, Вы писали:
S>Да как угодно. Если ты приходишь с людьми поговорить об интересном, а они тебе какую-то чухню под нос пихают, то меньше всего заботит что эти люди о тебе подумают.
Видишь ли, задачки тебе HR дают, и перед ними бессмысленно хвост распускать и доказывать, что в главном то ты крут. Вместе с тем, никто по этим задачкам решения принимать и не будет, это просто некий входной барьер, который человек, умеющий думать, вполне способен преодолеть.
S> Всё-таки стоит как-то разделять матёрого чела и зелёного студня.
Стоит. Только вот "матерые челы" обычно по классическим собеседованиям и не ходят особо, и начиная с какого то уровня тебя вообще перестает волновать вся эта мутатень. А вот "зеленому студню" надо учится проходить такие барьеры, потому что таких целое море, и никто с каждым лично нянчится не будет. Если у кого то какие то личные проблемы с собеседованиями — невелика беда, там в очереди еще сотня таких же. Причем, что характерно, 95 из этой сотни считают себя почти гениями и суперценным приобретением для любой компании, и с реальной полезностью уровень ЧСВ коррелирует примерно никак.
Здравствуйте, koenig, Вы писали:
K>я тупой, не вдупляю, объясни пожалуйста, причем тут size K>и если ты их уже обошел(в глубину)-ты по дороге мог список сформировать, зачем еще что-то?
Затем, что топологическую сортировку можно обень быстро сделать как комбинацию уже готовых алгоритмов — обхода дерева и сортировки. Обход дерева он пишется один раз и он универсальный, я всегда на новой работе пишу утилитку универсального обхода дерева, очень полезно получается, практически всегда требуется. Соответственно наивное простое решение — обойти, взять количество обойденных, и по количеству отсортировать — все. А по дороге сформировать список — это уже дальнейшая оптимизация.
Здравствуйте, elmal, Вы писали:
E>На самом деле во многих случаях достаточно квадрата
Бессмысленное заявление.
E>Вот мне на практике несколько раз требовалось писать топологическую сортировку. Я ее всегда писал с квадратичной сложностью. За 5 минут — применяю метод обхода каждой ноды и дергаю у всего этого size, и это натравливаю на стандартный sort — все. Весьма понятный и очевидный код получается, хоть и потенциально медленный. Ибо пофиг, это совсем не критичное место и N не превышает 100 в самом худшем случае. Если же это окажется вдруг проблемным местом, я сначала возьму простой трюк мемоизации, причем универсальной, над одним методом, в результате на практических задачах уже это будет N log N практически. Если N log N тоже маловато окажется и проблема в асимптотике — ну применю какой нидь bucket sort, в результате будет уже N (на практике кстати необходимости пока ни разу не было). Причем потрачу весьма мало времени. А реальный эффективный алгоритм, но более сложный, я буду использовать только тогда, когда окажется что вот такие быстрые оптимизации недостаточно эффективны, а память желательно поэкономить.
Ну вот ты и продемонстрировал наглядно, зачем нужны задачки. Потому что O(N) алгоритмы абсолютно тривиальны, да и их писать обычно не нужно.
E>Ибо все просто — чем более оптимизированный код, тем он всегда сложнее читается
В случае пессимизации, как в твоем примере — обычно та же картина.
Здравствуйте, ned, Вы писали:
ned>А можно продать дом, купить дом на ГК и ещё миллион кешем останется для комфортной жизни на пенсии.
Провести жизнь на потогонке, чтобы к пенсии скопить миллион? И зачем на пенсии миллион?
ned>Ты же не доехал ещё до NY. А если там злые негры?
Я и не искал в NY.
K>>я тупой, не вдупляю, объясни пожалуйста, причем тут size K>>и если ты их уже обошел(в глубину)-ты по дороге мог список сформировать, зачем еще что-то? E>Затем, что топологическую сортировку можно обень быстро сделать как комбинацию уже готовых алгоритмов — обхода дерева и сортировки. Обход дерева он пишется один раз и он универсальный, я всегда на новой работе пишу утилитку универсального обхода дерева, очень полезно получается, практически всегда требуется. Соответственно наивное простое решение — обойти, взять количество обойденных, и по количеству отсортировать — все. А по дороге сформировать список — это уже дальнейшая оптимизация.
прости, но я продолжаю тупить
топологическая сортировка — она ж про зависимости? как в принципе зависимости отрезолвить посредством скалярного атрибута (хоть size, хоть еще какого)?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну вот ты и продемонстрировал наглядно, зачем нужны задачки. Потому что O(N) алгоритмы абсолютно тривиальны, да и их писать обычно не нужно.
Нужно сначала гуглить, потом искать в каком пакете где это лежит, подключать зависимости и т.д. У готового решения может быть не очень удобное API и т.д. На практике потратишь больше времени, чем на быстрое наивное решение. В твоем случае там 257 строк, нужно еще как то быть кверенным что там нет багов, наивное быстрое решение пишется в 1 строчку сходу и ошибиться там сложно.
Здравствуйте, koenig, Вы писали:
K>топологическая сортировка — она ж про зависимости? как в принципе зависимости отрезолвить посредством скалярного атрибута (хоть size, хоть еще какого)?
Тот элемент, который ни от кого не зависит — у него size по детям будет 0. У кого будет 1 зависимый — у него size по детям будет 1. И т.д. Кто зависит от всех — у того size будет максимальный. Потому прекрасно все сортируется стандартным алгоритмом сортировки через немного нестандартный компаратор. Более того, именно это решение преподают студентам кажется в Беркли в курсе алгоритмов как наивное, и далее показывают как его улучшить если нужно быстрее. Если что, такую наивную реализацию я не сам придумал, если б курс по алгоритмам в свое время не прослушал и кое что не запомнил, может быть и гуглил бы когда понадобилось . Также запомнил, что у алгоритма кроме вычислительной сложности есть еще такой немаловажный параметр, как понятность, и если обстоятельства позволяют — лучше использовать более понятный алгоритм. Если б самообразованием не занимался в свое время — может быть и фигачил всегда сверхоптимальные копипасты когда надо и когда не надо.
Здравствуйте, elmal, Вы писали:
НС>>Ну вот ты и продемонстрировал наглядно, зачем нужны задачки. Потому что O(N) алгоритмы абсолютно тривиальны, да и их писать обычно не нужно. E>Нужно сначала гуглить, потом искать в каком пакете где это лежит, подключать зависимости и т.д.
О да, отмазок много. А по факту — косячное, запутанное и тормозное решение в коде. ЧТД.
E> У готового решения может быть не очень удобное API
А у танцора — слишком большие яйца.
E>На практике потратишь больше времени, чем на быстрое наивное решение.
На практике ты уже показал отличную иллюстрацию моих слов.
E> В твоем случае там 257 строк
Там столько строк, потому что всякими удобствами, коммнентариями и улучшизмами обвешано, чтобы потом некоторые не рассказывали про неудобный API. Да еще плюсом там детектор циклов. Сам же алгоритм — 49 строк вместе с детектором.
E>, нужно еще как то быть кверенным что там нет багов, наивное быстрое решение пишется в 1 строчку сходу и ошибиться там сложно.
Вот ты продемонстрировал вторую проблему гномикоборцев. Даже если им пальцем показать на готовое правильное решение, они будут упираться до посинения и придумывать миллион безумных аргументов, но свое первое решение неверным не признают никогда.
Здравствуйте, Тёмчик, Вы писали:
Тё>Если копнуть глубже, есть улучшения как например Тё>A space-efficient algorithm for finding strongly connected components David J.Pearce
Ну, это уже второй вопрос. Тут хотя бы самый банальный алгоритм знать бы или хотя бы простейший поисковый запрос в гугле написать.
E>>>Ибо все просто — чем более оптимизированный код, тем он всегда сложнее читается Тё>Декомпозиция для чего? Так то можно и всё приложение одной портянкой из спагетти сделать.
Здравствуйте, El Camino Real, Вы писали:
V_S>>Беда — это код математика с функциями по полторы-две тысячи строк, юзающими к тому же кучу глобальных переменных с очень информативными именами типа i, ii, iii, k, kk, kkk.... "ну а что, работает же!" ECR>Не, я обычно использую аргументацию "ну, перепиши!". Даже могу поспособствовать выделению бюджета. Но программисты всё равно взвывают.
Контр-аргументация простая, как доска — а что будете делать, когда (не "если", а именно "когда") этот математик выйдет на пенсию, и "вдруг" окажется, что код математика не масштабируется. Или "вдруг" найдутся непредусмотренные граничные условия?
Здравствуйте, smeeld, Вы писали:
S>Вижу и знаю только одно-качественный программер не проходит собеседований.
Я об этом и написал. Но до этого еще надо дорасти. Причем не только профессионально. Непризнанные гении тут не прокатывают, нужны признанные. Но если у тебя неадекватный ЧСВ, признанным ты вряд ли станешь.
Здравствуйте, elmal, Вы писали:
E>На самом деле во многих случаях достаточно квадрата, если квадрат работает нормально на расчетных данных. Вот мне на практике несколько раз требовалось писать топологическую сортировку. Я ее всегда писал с квадратичной сложностью. За 5 минут — применяю метод обхода каждой ноды и дергаю у всего этого size, и это натравливаю на стандартный sort — все.
Что такое size?
Как-то в коде был квадрат, он работал минут 10 и это не было критично. Потом оказалось, что количество входных данных перевалило за миллион и квадрат справляться перестал. Пришлось переписывать. И было это не легко, т.к. код запутанный и делал какие-то совсем не очевидные вещи, которые желательно было сохранить. Не то, чтобы это очень надо было для задачи, но заказчики уже так привыкли. Если бы сразу писали без квадрата, было бы в разы проще.
E>Весьма понятный и очевидный код получается, хоть и потенциально медленный. Ибо пофиг, это совсем не критичное место и N не превышает 100 в самом худшем случае. Если же это окажется вдруг проблемным местом, я сначала возьму простой трюк мемоизации, причем универсальной, над одним методом, в результате на практических задачах уже это будет N log N практически.
Там же алгоритм имеет O(N).
E>Ибо все просто — чем более оптимизированный код, тем он всегда сложнее читается, тем сложнее там что то менять. И без крайней необходимости лучше код не запутывать.
Здесь вопрос организации кода. Пишется абстракция графа, и пишется топологическая сортировка. Всё. Для клиента это всё выглядит как вызвать функцию для графа. А внутри может быть хоть квадратичная сложность, хоть кубическая. Но опять же алгоритмы не такие уж и сложные, чтобы быстрый алгоритм был запутанный.
Сложности возникают, если путают логику программы с алгоритмами сортировки, когда вдруг они должны знать, что сортировка производится не для графа, а для графа фотографий или ещё чего.
E>Какого хрена мне оптимизировать пусть даже секунду на топологической сортировке, если то, ради чего эта сортировка выполняется, гоняется вообще несколько часов потом на кластере стандартной коммерческой дорогой и крайне оптимизированной решалкой. Что, закон Амдала отменили чтоль ?
Можно попытаться и распараллелить. Только читаемость вряд ли улучшится.
Здравствуйте, The Passenger, Вы писали:
TP>это ладно — я вот тест в одну финансовую компанию проходил — там процентов на 80 были задачи на вращение треугольников — типа — TP>поверните направо налево — теперь ответьте как он лежит
TP>вот я до сих пор в недоумении
TP>отнесся несерьезно и не прошел.
Догадываюсь, что это за компания...
В свое время в школе на уроках черчения я обнаружил у себя талант к подобным задачам. Но, так как я терпеть не мог черчение, то считал этот талант абсолютно бесполезным. Никогда бы не догадался, что бесполезное умение поворачивать в уме треугольники в будущем так сильно повлияет на мою жизнь
До сих пор не могу понять, зачем давать программистам такие тесты, это блин даже не IQ тест и не задачи про гномиков... Он никак не проверяет абстрактное логическое мышление, которое нужно программисту. Ну, я еще могу понять если бы надо было программировать терхмерную графику, но к финансам это вообще не имеет никакого отношения (трейдеры кстати совсем другой тест проходят).
Здравствуйте, ksandro, Вы писали:
K>До сих пор не могу понять, зачем давать программистам такие тесты, это блин даже не IQ тест и не задачи про гномиков... Он никак не проверяет абстрактное логическое мышление, которое нужно программисту. Ну, я еще могу понять если бы надо было программировать терхмерную графику, но к финансам это вообще не имеет никакого отношения (трейдеры кстати совсем другой тест проходят).
Да что вы все до треугольников докопались? Это всего лишь пара вопросов из 100. Большинство вопросов вполне релевантные: логические задачки (кто в каком доме живет), найти состояние конечного автомата после n шагов, несложные финансовые задачки. Из совсем нелепых помню только задачки на внимательность типа посчитать сколько раз встречается буква A в небольшом тексте.
Здравствуйте, alzt, Вы писали:
A>Там же алгоритм имеет O(N).
На многих задачах реально на практике пофиг — N это или N*N. Даже экспонента может сойти, никто и не заметит при N = 10, когда известно что N что N никогда больше не будет. А если заметят и вдруг окажется узким местом — ловится все на раз, и чинится. Не нужно всегда и во всем иметь минимальную вычислительную сложность. В первую очередь всегда нужно думать — нужно это или не нужно. И если наивный но понятный квадрат или хуже допустим — ничего страшного не случится. Вот предположим N — это количество стран. Пофиг как ты эти 252 страны будешь сортировать, за N*N или даже за N. Стран миллион не будет при жизни очень и очень многих поколений, если вообще когда будет. Более оптимальный алгоритм практически всегда гораздо более сложный, чем наивный. И не нужно без необходимости городить лишнюю сложность, чтобы уменьшить время отклика с секунды на 999 миллисекунд. Это один из базовых принципов в Computer Science вообще то.
A>Можно попытаться и распараллелить. Только читаемость вряд ли улучшится.
Уже все, что надо, и максиматьно оптимизировано и все распараллелено. Сама задача NP Complete, она даже в упрощенной форме относится к классическим. Соответственно получается базовое решение, дальше постепенно генетическими алгоритмами это все улучшается до тех пор, пока позволяет время, и далее выдается субоптимальное решение, и этого достаточно.
Здравствуйте, elmal, Вы писали:
E>А если заметят и вдруг окажется узким местом — ловится все на раз, и чинится.
А ракета уже упала. Чинить поздно.
E>Пофиг как ты эти 252 страны будешь сортировать, за N*N или даже за N. Стран миллион не будет при жизни очень и очень многих поколений, если вообще когда будет.
"640K ought to be enough for anybody".
А потом кто-то заменит список стран на индексы, например, и приехали. Или ещё один умник засунет сортировку в другой квадратичный алгоритм.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ага. И потом сидят такие суперпрактики и чинят. Вот только чинят они не сложность, а демонстрируют чудеса битовыжимания. Константу починят, а О(n дохрена) осталась как была.
А вот как с минимальными изменениями исходного алгоритма починить сложность — какого то черта с этой простейшей практической задачей не могут справиться большинство любителей преждевременной оптимизации. У большинства оптимальные решения конкретных задач тупо зазубрены в лучшем случае. Сделать конфетку по сложности с минимальной модификацией исходного кода какого то черта могут единицы. Все полностью переписать чтоб ускорить за черти какое время при неизменных условиях — здесь много ума не надо. На практике зачастую для ускорения в тысячи раз достаточно точечных локальных изменений, которые очень быстро как делаются, так и находятся. При условии нормальной декомпозиции это вообще не задача.
Здравствуйте, elmal, Вы писали:
E>А вот как с минимальными изменениями исходного алгоритма починить сложность
Подожди. Ты нам только что тут расписывал, как прекрасно все фиксится при необходимости.
E> — какого то черта с этой простейшей практической задачей не могут справиться большинство любителей преждевременной оптимизации.
А большинство любителей преждевременной пессимизации?
E> У большинства оптимальные решения конкретных задач тупо зазубрены в лучшем случае. Сделать конфетку по сложности с минимальной модификацией исходного кода какого то черта могут единицы. Все полностью переписать чтоб ускорить за черти какое время при неизменных условиях — здесь много ума не надо.
Это что, попытка сменить тему?
E> На практике
Опять на практике. На практике ты нам тут рассказывал про топосорт с n^2, который ты, при необходимости, обещал сложным алгоритмом и кучей времени превратить в n*log n. Вот это как раз практика и есть, а не то что ты рассказываешь.
E>зачастую для ускорения в тысячи раз достаточно точечных локальных изменений, которые очень быстро как делаются, так и находятся.
А если недостаточно? Бросаем проект? Или срочно бежим искать нормального разработчика?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Опять на практике. На практике ты нам тут рассказывал про топосорт с n^2, который ты, при необходимости, обещал сложным алгоритмом и кучей времени превратить в n*log n. Вот это как раз практика и есть, а не то что ты рассказываешь.
Каким к черту сложным алгоритмом? Он превращается в n*log n банальной универсальной мемоизацией вообще без усилий, поставить мемоизацию сразу мешает только банальная лень. На тысяче элементов ты хрен когда заметишь разницу между n и n*n, а уж между n и n log n тем более. Небольшие проблемы, когда квадрат уже полная фигня — это миллионы. А когда миллиард — вот тогда приходится очень сильно извращаться, и асимптоматика должна быть максимальной, и еще нужно о крайне многих вещах думать, например как максимально поместить данные в кеш процессора чтоб не потерять всю скорость, плюс как загрузить эффективно все ядра и многое другое.
НС>А если недостаточно? Бросаем проект? Или срочно бежим искать нормального разработчика?
А если недостаточно — тогда действительно пишем максимально оптимально конкретное место. Только снова на практике — это узкое место будет видно сразу же на этапе постановки задачи, ибо на этапе постановки задачи будет сразу понятно что данных там миллиард (да хоть и миллион даже, но будет сразу понятно, что сама эта задача является основной, а не второстепенной). Тогда сразу асимптоматика будет нужная, а уже над низкоуровневыми оптимизациями придется повозиться. Возможно несколько раз придется еще и переписывать алгоритм с изначально хорошей асимптоматикой, но на более сложный и запутанный, но лучше применимый к конкретной задаче.
Общий принцип. Чем проще у тебя изначальные алгоритмы — тем больший простор для всяких изменений кода при изменениях требований. Как только ты начинаешь оптимизировать — тем меньше у тебя простора для изменений. Приходится и данные перепаковывать определенным оптимальным образом, и зависимости ненужные делать чтоб избежать лишних проходов и т.д, там до черта приходится делать, в рехультате код очертененно теряет в универсальности, но работает быстро, зачастую на пределе возможностей железа. И уже в оптимизированный код вносить изменения получается полная жесть. Потому там, где это не нужно — не нужно излишне запутывать код. Нужно сначала найти проблемные места, и только затем их оптимизировать.
Я уж молчу о том, что на определенных N n*n бывает быстрее n log n. Ибо какого то черта в методе sort во многих либах при определенных n внутри оказывается пузырек.
Здравствуйте, ksandro, Вы писали:
K>Догадываюсь, что это за компания...
Они, к стати, сейчас на хакерранк тесты перешли — это я еще могу понять ... хотя там тоже пару раз фэйлился, но в другие конторы
фэйлился в основном на том что с английским было не очень хорошо — пока поймешь — время идет
потом долго бодался с консолью — как аргументы получить и распарсить — занимало большинство времени ... ну не работаю я давно с консолью
и в ожидании подвоха — пытался найти более элегантное решение чем в лоб, а потом понимал что в лоб и надо.
K>В свое время в школе на уроках черчения я обнаружил у себя талант к подобным задачам. Но, так как я терпеть не мог черчение, то считал этот талант абсолютно бесполезным. Никогда бы не догадался, что бесполезное умение поворачивать в уме треугольники в будущем так сильно повлияет на мою жизнь
Работаешь там?
Думаю еще раз попробовать осенью
K>До сих пор не могу понять, зачем давать программистам такие тесты, это блин даже не IQ тест и не задачи про гномиков... Он никак не проверяет абстрактное логическое мышление, которое нужно программисту. Ну, я еще могу понять если бы надо было программировать терхмерную графику, но к финансам это вообще не имеет никакого отношения (трейдеры кстати совсем другой тест проходят).
на самом деле, я так полагаю, это тест на возможность представления и просчета алгоритма по шагам в голове ... но мне, если надо, я рисую.
... но всеравно — они както умудряются описать задачи, вроде и по английски, но после одного прочтения нифига не понятно
Здравствуйте, ned, Вы писали:
L>>Ага. И упала она потому, что какой-то умник заменил O(N^2) на O(N), чем похерил тайминги. Или, что еще более вероятно, устроил локальный расстрел памяти. Или все вместе. ned>Поэтому нужно сразу писать O(N).
Ага. Сразу. Особенно в случаях, когда O(N^2) оказывается быстрее, чем O(N) и даже, какой кошмар, O(1)
L>>Чтобы ракеты не падали, нужно не на алгоритмы этосамое вприсядку. Нужно тестировать. Тестировать все и во всех возможных вариантах. ned>Там проблема в том что и софт и железо разрабатываются одновременно. Годами.
Не вижу проблемы. Для всего сложнее онлайн-бложека это совершенно нормальная ситуация.
Здравствуйте, ned, Вы писали:
ned>Здравствуйте, ksandro, Вы писали:
K>>До сих пор не могу понять, зачем давать программистам такие тесты, это блин даже не IQ тест и не задачи про гномиков... Он никак не проверяет абстрактное логическое мышление, которое нужно программисту. Ну, я еще могу понять если бы надо было программировать терхмерную графику, но к финансам это вообще не имеет никакого отношения (трейдеры кстати совсем другой тест проходят).
ned>Да что вы все до треугольников докопались? Это всего лишь пара вопросов из 100. Большинство вопросов вполне релевантные: логические задачки (кто в каком доме живет), найти состояние конечного автомата после n шагов, несложные финансовые задачки. Из совсем нелепых помню только задачки на внимательность типа посчитать сколько раз встречается буква A в небольшом тексте.
Ну, не знаю, в тесте, который делал я большинство задач было именно на пространственное мышлениление. Хотя и другие логические задачки тоже встречались...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я об этом и написал. Но до этого еще надо дорасти. Причем не только профессионально. Непризнанные гении тут не прокатывают, нужны признанные. Но если у тебя неадекватный ЧСВ, признанным ты вряд ли станешь.
Про "непризанных гениев" ничего не говорил. А про дорасти, то для этого достаточно увлечённо работать лет 10-20, и оно придёт, вместе с известностью в достаточно узком кругу IT-шного мира. Кстати, разработка софта-это та самая сфера, где и "непризнанные гении" могут добиться признания, если достоин.
Здравствуйте, ksandro, Вы писали:
K>Ну, не знаю, в тесте, который делал я большинство задач было именно на пространственное мышлениление. Хотя и другие логические задачки тоже встречались...
Он адаптивный, по-моему. Если валишься на определённом типе задач он даёт больше задач этого типа.
Хинт: берёшь листок бумаги, быстро рисуешь треугольники, крутишь на столе. Так же проходятся задания с переворотом/разрезанием листа "в голове"
Здравствуйте, Gattaka, Вы писали:
G>А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил. Так вот теперь я эту задачу сам на собеседованиях спрашиваю.
Здравствуйте, ksandro, Вы писали:
K>Да, на хакерранк перешли уже давно. Но со слов собеседующих там тоже все так гладко. Было несколько случаев когда, после прекрасных результатов на хакерранке на собеседование приходил чувак, вообще плохо представляющий, что такое программирование. Ну еще помню что мне показывали одну задачку по плюсам на которую хакерранк считал явно неправильный ответ правильным.
тут я смотрел — одна задачка из адвансед — решило чтото около сотни человек — первые человек 30 все по разным странам ... потом 50 человек подряд раджешев ... совпадение? — не думаю
я к тому — что человек может вполне и не сам решать
K>Работал в одной из этих Амстердамских финансовых конторок, но я довольно быстро осознал, что Голландия — это не мое, прожил там полтора года и вернулся в Россию. K>Вообще, там работается хорошо, но есть свои ньюансы. Несмотря на очень неплохие, даже по голландским меркам, условия, текучка кадров довольно большая.
догадываюсь что там — соковыжималка ... у нас работала пара человек оттуда — их просто всем отделом схлопнули
Здравствуйте, The Passenger, Вы писали:
K>>Работал в одной из этих Амстердамских финансовых конторок, но я довольно быстро осознал, что Голландия — это не мое, прожил там полтора года и вернулся в Россию. K>>Вообще, там работается хорошо, но есть свои ньюансы. Несмотря на очень неплохие, даже по голландским меркам, условия, текучка кадров довольно большая.
TP>догадываюсь что там — соковыжималка ...
Я бы не сказал что там прям соковыжималка. Работа вцелом спокойнее чем в России. Иногда можно расслабиться и фигней страдать, а иногда вдруг резко выясняется, что надо еще ко вчерашнему дню срочно какую-то очень важную фичу сделать. Но я так понимаю в Голландии в других организациях народ вообще обычно не сильно напрягается, там все очень спокойно и размеренно.
TP>у нас работала пара человек оттуда — их просто всем отделом схлопнули
я кстати работал не в этой фирме, я работал у их конкурентов, куда большая часть этого отдела потом перешла.
Здравствуйте, elmal, Вы писали:
НС>>Опять на практике. На практике ты нам тут рассказывал про топосорт с n^2, который ты, при необходимости, обещал сложным алгоритмом и кучей времени превратить в n*log n. Вот это как раз практика и есть, а не то что ты рассказываешь. E>Каким к черту сложным алгоритмом?
Видимо достаточно сложным, раз сразу его написать ты не осилил.
E> Он превращается в n*log n банальной универсальной мемоизацией вообще без усилий
Точно, еще и памяти подожрем на ровном месте. Ты опять сделал мне смешно.
E>А когда миллиард — вот тогда приходится очень сильно извращаться
А сильное извращение это наконец перейти к простенькому алгоритму с O(n)? Или не пяди врагу?
НС>>А если недостаточно? Бросаем проект? Или срочно бежим искать нормального разработчика? E>А если недостаточно — тогда действительно пишем максимально оптимально конкретное место.
Максимально оптимально это, на практике, выкинуть бредятину с мемоизацией и таки реализовать простенький алгоритм?
E>Общий принцип. Чем проще у тебя изначальные алгоритмы — тем больший простор для всяких изменений кода при изменениях требований.
Ты нам только что рассказывал, что смена алгоритма это архисложная задача, и лучше мемоизацию прикрутить.
E> Как только ты начинаешь оптимизировать — тем меньше у тебя простора для изменений. Приходится и данные перепаковывать определенным оптимальным образом, и зависимости ненужные делать чтоб избежать лишних проходов и т.д, там до черта приходится делать, в рехультате код очертененно теряет в универсальности, но работает быстро, зачастую на пределе возможностей железа. И уже в оптимизированный код вносить изменения получается полная жесть. Потому там, где это не нужно — не нужно излишне запутывать код. Нужно сначала найти проблемные места, и только затем их оптимизировать.
Давай перейдем от общих слов к конкретике. Вот сделал ты топосорт каким то мутным алгоритмом с сортировкой. Прикрутил поверх мемоизацию. А все равно мало. Теперь какие дальнейшие действия по ускорению?
E>Я уж молчу о том, что на определенных N n*n бывает быстрее n log n.
Давай, с замерами, свой алгоритм с алгоритмом Кана в студию.
Здравствуйте, smeeld, Вы писали:
S> А про дорасти, то для этого достаточно увлечённо работать лет 10-20
Недостаточно. Большинство местных обладателей раздутого ЧСВ только своим ЧСВ и известны. А опыт в 10-20 лет не есть нечто неординарное.
S>S>, и оно придёт, вместе с известностью в достаточно узком кругу IT-шного мира. Кстати, разработка софта-это та самая сфера, где и "непризнанные гении" могут добиться признания, если достоин.
Чтобы добиться признания надо хотя бы рассказать, что ты такого сделал. Многие на это не способны.
Здравствуйте, ksandro, Вы писали:
K>Я бы не сказал что там прям соковыжималка. Работа вцелом спокойнее чем в России. Иногда можно расслабиться и фигней страдать, а иногда вдруг резко выясняется, что надо еще ко вчерашнему дню срочно какую-то очень важную фичу сделать. Но я так понимаю в Голландии в других организациях народ вообще обычно не сильно напрягается, там все очень спокойно и размеренно.
Все так — если свои жопочасы ровно отсиживаешь и красиво танцуешь срам митинги — то можно вообще не работать
Хотя моя выборка нерелевантна, просто сужу по нескольким поменявшимся голландским начальникам внутри одной конторы.
Этой осенью точно сорвусь — если в эуропах не пристроюсь, то может и в Россию поеду.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Давай перейдем от общих слов к конкретике. Вот сделал ты топосорт каким то мутным алгоритмом с сортировкой. Прикрутил поверх мемоизацию. А все равно мало. Теперь какие дальнейшие действия по ускорению?
Вот если мало, тогда берется стандартная эффективная реализация, и только тогда тратится время на гугление, поиск хорошей реализации на гитхабе, возможно делается конверсия на свой язык программирование и т.д. Что тормозит будет видно даже без профилировщика, простым снятием дампа потоков в момент тормозов. И очень быстро пофиксится, хоть и больше на это потратится, чем на изначальное наивное решение.
Но не тогда, когда N=100 и никогда не будет даже 1000, это нужно строго в одном месте, и голова забита совсем другими проблемами чем реализацией топологической сортировкой, ее нужно сделать между делом ASAP и далее забыть. Ибо в одном случае это было нужно чтоб отдавать данные на фронтэнд, причем отдавать нужно один раз, и фронтэнду неудобно когда ему отдаются элементы не в том порядке. И если там будет 1000 элементов — там фронтэнд загнется совсем по другим причинам, причем самому пользователю столько данных никогда не понадобится отдавать. Во втором случае эта топологическая сортировка понадобилась при трансформации AST дерева. Которое тоже никогда сильно глубокое не будет, ибо если N будет большое, то человек, который этот AST пишет, боюсь с ума сойдет пытаясь понять что там написано. Через год, кстати, пришлось разок из за перфоманса лезть и оптимизировать, ибо падало по памяти. Топологическая сортировка с квадратичной скоростью даже близко не была проблемой. Оптимизировал, причем быстро. Теперь упало все на сторонней библиотеке, коммерческой, гонявшейся на кластере, ибо математик туда захреначил систему уравнений на миллионы переменых и миллионы уравнений соответственно, и солвер не справился. В результате потом математику один черт пришлось упрощать модель, и по существу оптимизацию лично я делал зря .
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Чтобы добиться признания надо хотя бы рассказать, что ты такого сделал. Многие на это не способны.
Были на проекте до моего прихода двое, обоим под 50, софт пишут с начала девяностых, никому не рассказывали что именно делали, так как софт пилили всегда закрытый, но о них в Мск знают все работодатели. Им однажды надоело, они просто перешли в другую компанию, просто приняли одно из предложений, коих ежегодно им поступало кучи со всех сторон. Не называю имён и компаний, но они в Мск известны. Тупо толковые чуваки, и это распространяется по сарафанному радио между работодателями. Так что всё-таки тупо качественно проработать с результатами лет десять-этого достаточно чтоб тебя зазывали на работу все работодатели без глупых собеседовании. В Америках то же самое. Причём, известность в Мск распространяется и там. в США, кстати, могут попытаться насильно затянуть, как Винника. Тут дело в том, что работать некому, серьёзно. Тысячи выпускников ежегодно, тысячи желающих работать в профессии, но дело делать некому. Мало реально способных на это. Об этом, кстати, в своих постах юзернейм langerhigh постоянно также намекает.
Здравствуйте, elmal, Вы писали:
НС>>Давай перейдем от общих слов к конкретике. Вот сделал ты топосорт каким то мутным алгоритмом с сортировкой. Прикрутил поверх мемоизацию. А все равно мало. Теперь какие дальнейшие действия по ускорению? E>Вот если мало, тогда берется стандартная эффективная реализация
E>, и только тогда тратится время на гугление, поиск хорошей реализации на гитхабе, возможно делается конверсия на свой язык программирование и т.д.
Здравствуйте, MasterZiv, Вы писали:
MZ>Здравствуйте, Gattaka, Вы писали:
G>>А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил. Так вот теперь я эту задачу сам на собеседованиях спрашиваю.
MZ>Задача то где?
Ну не. Вы ее здесь решите сейчас, а мне еще людей проверять.
Здравствуйте, landerhigh, Вы писали:
L>Бесполезно рассказывать о своем опыте разработки сетевых устройств человеку, для которого сетевое программирование ограничивается сакральным знанием о том, как открыть сокет, вычитанным за 15 минут до собеседования из википедии, а протоколов, кроме TCP, не существует.
Просто объяснить сложное сложно. Сложно объяснить сложное просто.
Здравствуйте, Gattaka, Вы писали:
G>А вот и не про Яндекс. Я тут уже рассказывал как мне задачку давали в Яндексе и я ее не решил. Так вот теперь я эту задачу сам на собеседованиях спрашиваю. И результат меня удивил, так что я решил с вами поделиться и обсудить. Дело в том, что люди которые буквально только из универа и не знают что такое GC, что такое план запроса
Здравствуйте, landerhigh, Вы писали:
L>Бесполезно рассказывать о своем опыте разработки сетевых устройств человеку, для которого сетевое программирование ограничивается сакральным знанием о том, как открыть сокет, вычитанным за 15 минут до собеседования из википедии, а протоколов, кроме TCP, не существует.
Сетевая часть пишется максимум за полдня с закрытыми глазами. Вот как разрулить толстый поток, дозапрашивать пакеты и не лочить, не выжрать память- нужно знание структур данных, алгоритмов, многопоточки, паттернов проектирования — т.е. ровно того, что на собеседовании у тебя пригорает.
Здравствуйте, Тёмчик, Вы писали:
L>>Бесполезно рассказывать о своем опыте разработки сетевых устройств человеку, для которого сетевое программирование ограничивается сакральным знанием о том, как открыть сокет, вычитанным за 15 минут до собеседования из википедии, а протоколов, кроме TCP, не существует.
Тё>Сетевая часть пишется максимум за полдня с закрытыми глазами. Вот как разрулить толстый поток, дозапрашивать пакеты и не лочить, не выжрать память- нужно знание структур данных, алгоритмов, многопоточки, паттернов проектирования — т.е. ровно того, что на собеседовании у тебя пригорает.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Увы, джентльмены, начинать с намеренной пессимизации не прокатывает.
Так не нужно пессимизировать намеренно. На том этапе, когда заказчик не знает чего хочет, когда идут постоянно требования — "а давайте добавим вот эту фичу", затем на следующей — "нет, вот эту фичу, которую мы добавляли, ради которой нам пришлось до хрена рефакторить — это мы випилим, она не нужна", затем — "эту фичу мы модифицируем", затем — "нет, тут мы ошиблись, вот тут связь не 1 к одному а много ко многим, а здесь не много ко многим а 1 ко многим", и в таком режиме продукт может жить годами. При этом с развитием может оказаться, что для клиента 1 идет 1 набор фич, для клиента 2 идет второй, для третьего идут фичи с модификациями, четвертый клиент хочет вообще конструктор фич, чтоб он сам мог добавлять свою специфику самостоятельно. Если в таком режиме все делать сверхоптимально, а не максимально гибко — в этом случае проект будет делаться 100 лет.
Здравствуйте, elmal, Вы писали:
E>Так не нужно пессимизировать намеренно. На том этапе, когда заказчик не знает чего хочет, когда идут постоянно требования — "а давайте добавим вот эту фичу", затем на следующей — "нет, вот эту фичу, которую мы добавляли, ради которой нам пришлось до хрена рефакторить — это мы випилим, она не нужна", затем — "эту фичу мы модифицируем", затем — "нет, тут мы ошиблись, вот тут связь не 1 к одному а много ко многим, а здесь не много ко многим а 1 ко многим", и в таком режиме продукт может жить годами. При этом с развитием может оказаться, что для клиента 1 идет 1 набор фич, для клиента 2 идет второй, для третьего идут фичи с модификациями, четвертый клиент хочет вообще конструктор фич, чтоб он сам мог добавлять свою специфику самостоятельно. Если в таком режиме все делать сверхоптимально, а не максимально гибко — в этом случае проект будет делаться 100 лет.
Ты или готовую прикрути, или свой контейнер напиши с топологической сортировкой и простыми понятными интерфейсами наружу, покрой юнит тестами. Надо заказчику сортировку- подцепил, не надо- выбросил. Может в будущем пригодится. Так нет, каждый раз по памяти фигачишь кривой велосипед с O(n*n*log n).
Update
А вообще, я тут подумал (правильного алгоритма не читал) ведь топологическая сортировка — это обход графа с удовлетворением зависимостей. Просто обходишь в глубину и помечаешь пройденные узлы, чтобы не было повторов (та самая мемоизация).
Здравствуйте, elmal, Вы писали:
SVZ>>Увы, джентльмены, начинать с намеренной пессимизации не прокатывает. E>Так не нужно пессимизировать намеренно. На том этапе, когда заказчик не знает чего хочет, когда идут постоянно требования — "а давайте добавим вот эту фичу", затем на следующей — "нет, вот эту фичу, которую мы добавляли, ради которой нам пришлось до хрена рефакторить — это мы випилим, она не нужна", затем — "эту фичу мы модифицируем", затем — "нет, тут мы ошиблись, вот тут связь не 1 к одному а много ко многим, а здесь не много ко многим а 1 ко многим", и в таком режиме продукт может жить годами. При этом с развитием может оказаться, что для клиента 1 идет 1 набор фич, для клиента 2 идет второй, для третьего идут фичи с модификациями, четвертый клиент хочет вообще конструктор фич, чтоб он сам мог добавлять свою специфику самостоятельно. Если в таком режиме все делать сверхоптимально, а не максимально гибко — в этом случае проект будет делаться 100 лет.
Гм, интересные шляпки носила буржуазия.
А в какой отрасли такие разброд и шатание? Веб сайты? Какие-то корпоративные системы?
В наших ебенях САПРах так не делают. Объем данных известен еще на берегу, цель тоже более-менее известна.
Нюансы выплывают немного в другом. Либо задача будет исследовательской, пока не сделаешь, не узнаешь, годится ли результат. Либо задача известна, но данные приходят из разных источников, и хотя они соответствуют спецификации, могут быть всякие косяки.
В обоих случаях нет смысла ляпать прототип на скорую руку, экономии не получишь. Да еще и рискуешь не дождаться результатов, если сляпано совсем без оптимизации.
Ну и есть такая вредная традиция, которую еще Хмелевская описала в своих мемуарах: "...нет ничего более постоянного, чем временное. Так времянка, построенная для ремонта усадьбы, простояла 200лет...". Так что приходится делать сразу добротно.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А в какой отрасли такие разброд и шатание? Веб сайты? Какие-то корпоративные системы?
В разработке корпоративных приложений вот такое сплошняком. Особенно весело когда работаешь не по готовому ТЗ, а пытаешься что то сделать такое, чтоб у тебя это купили, и бегаешь по потенциальным клиентам собирая требования и показывая прототипы. Да и когда заказчик известен — обычно тоже куча веселого. ПОка пишется, все, поменяется 10 представителей заказчика и 10 раз требования, причем оценка объема данных может отличаться в миллион раз от изначальной .
Здравствуйте, elmal, Вы писали:
SVZ>>А в какой отрасли такие разброд и шатание? Веб сайты? Какие-то корпоративные системы? E>В разработке корпоративных приложений вот такое сплошняком. Особенно весело когда работаешь не по готовому ТЗ, а пытаешься что то сделать такое, чтоб у тебя это купили, и бегаешь по потенциальным клиентам собирая требования и показывая прототипы. Да и когда заказчик известен — обычно тоже куча веселого. ПОка пишется, все, поменяется 10 представителей заказчика и 10 раз требования, причем оценка объема данных может отличаться в миллион раз от изначальной .
Понятно.
Не, у нас с этим попроще. От клиентов приходит фидбек и в целом понятно, что им надо. Плюс всякие выставки и конференции показывают, в каком направлении движется отрасль в целом.
Вот серьезная проблема это борьба с конкурентами. Честные методы, ессно, не работают. Надо работать через топ-менеджмент, а это знакомства + талант.
Вернее, не знакомства, отрасль небольшая, все всех знают, а именно вхожесть в кабинеты.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Gattaka, Вы писали:
НС>>А еще у меня 20 лет опыта разработчика. Так что все равно у меня длиннее. G>К сожалению это мало о чем говорит.
А что говорит много? Величина ЧСВ?
G> Есть такие ребята которым не повезло и они 20 лет работали с менеджерами и знать не знали и представить себе не могли что может быть иначе. В итоге такие ребята становятся менеджерами и окончательно запирают перспективы своего развития. Ведь если ты менеджер, то не имеешь уже шанса понять как работают без менеджеров. Стал таки драконом.
В отличие от тебя, я создал или довел до ума несколько успешных open source продуктов, которыми пользуются десятки тысяч человек. Так что у тебя все равно короче.
