Здравствуйте, gandjustas, Вы писали:

I>>В сложных проектах часто встречаются структуры отличные от List. Например всевозможные оптимизации или сложные структуры навроде списковых, графовых, древовидных и тд. Здесь уметь всякие преобразования и обходы крайне необходимо.

G>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте?
G>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.

Правильно ! И дело в том, что во время работы нужно решать целую кучу всяких частных случаев, которые встречаются не чаще раза в жизни.
Нет необходимости писать код который пишут все, такой код в 99% уже написан.

Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "
А если обходить надо будет не список, а дерево, и, вдобавок, асинхронно, и, вдобавок, впихнуть дерево в N-представлений, что бы отразить самые разные аспекты ?
Я сильно сомневаюьс, что человек сможет обойти дерево, если не смог обойти список.
Обход дерева — xml, json, файловая система, реестр, урлы на сайте и тд и тд.

Собтсвенно в этой задаче нет ничего, что бы могло поставить хорошего кандидата в тупик.
Если решения нет, то однозначно кандидат не интересует, ибо
1. вообще не работал со списковыми структурами (может всю жизнь матрицы умножал)
2. малый опыт (вчера научился программировать)
3. умеет решать только стандартные задачи (вызубрил одну книгу и больше ничего не умеет)
4. не понимает указатели (WTF ???)

в этой задаче нужно уметь
1 сделать простейший обход
2 использовать указатели-ссылки

Если не понимает указатели-ссылки, то на каком основании он называется программистом ?

Вобщем, я не видел сильных девелоперов, которые не могли бы решить такое. Есть люди, которые отказываются решать подобные задачи. Есть люди которые волнуются во время собеседования.
Обычно несколько подсказок и достаточное количество времени помогает во втором случае.
А если человек отказывается решать такое — пусть идет работать к конкурентам, тут я ничего не могу поделать

Ну и надо понимать самое главное — у специалиста, скажем, по звуку нет смысла спрашивать такое, ибо есть вещи намного более важные.
У лида или архитекта так же незачем спрашивать такое, т.к. есть вещи более важные.

Здравствуйте, Ikemefula, Вы писали:

I>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "

Если человек не может что-то сделать СЕЙЧАС, это не значит, что он это не может сделать вообще. Более того — если даже он может обойти ваш @$#^ список, почему вы так уверены, что он так же легко разрулит, скажем, сбалансированное дерево?? Гарантии — никакой.

Ну и вообще по проблеме: отнеситесь к найму человека как.... к ВЫБОРУ ДЕВУШКИ! Это не делается за час. Это невозможно выяснить до булевого "хороший/плохой". Нельзя залезть в мозги и измерить. Это вообще глупость — ТЕСТИРОВАТЬ УМ! Даже всем известный "тест IQ" — и тот оказался лажей (тоже мне, удивили!), а что вы хотите от собеседования в режиме "мы ща тебя заспрашиваем до икоты, а ты нам выдай продакшн код!".
Человек должен проявить себя в естественной среде — среди коллег или уж дома. И без подгонялова "вот вам час" (даже если задача решается за минуту) — человек просто по сути своей — живое существо и не может резко стать спокойным, особенно если он — "начинающий" или "середнячок".
Я даже "тугодума" взял бы с большей уверенностью, потому что выскочки-всезнайки (типа вот этой обидчивой девочки, которая тут с листочком и карандашом перевернула список) абсолютно не пригодны там, где требуется скрупулёзность и выверенность идей. Тут всё непросто, это на 99% психология и только 1% — какие-то технические банальности.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>В сложных проектах часто встречаются структуры отличные от List. Например всевозможные оптимизации или сложные структуры навроде списковых, графовых, древовидных и тд. Здесь уметь всякие преобразования и обходы крайне необходимо.

G>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте?
G>>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.

I>Правильно ! И дело в том, что во время работы нужно решать целую кучу всяких частных случаев, которые встречаются не чаще раза в жизни.
I>Нет необходимости писать код который пишут все, такой код в 99% уже написан.
То есть ответ "ни разу"? Я не сомневался.

I>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "
Так и спрашивай про граф или дерево, в чем проблема? Если только это нужно для работы.

I>Я сильно сомневаюьс, что человек сможет обойти дерево, если не смог обойти список.
Обход списка и разворот а месте — разные операции. Кроме того мы не про абстрактные навыки говорим, а про код на бумажке.
99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.

I>Если не понимает указатели-ссылки, то на каком основании он называется программистом ?
Указатели далеко не везде есть. Более того, сейчас больше языков, где указателей нет.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, gandjustas, Вы писали:

G>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте?

НС>А ты лично можешь этот разворот написать?
Лично я могу, а что это меняет?

G>>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.

НС>И? К примеру, мне несколько раз приходилось топосорт писать, далеко не во всех платформах он стандартный имеется. В дотнете, к примеру, его нет. Только если дать задачку на топосорт, то уже требуется знание хоть и простенького, но уже не тривиального алгоритма, а вот это как раз уже значения особого не имеет — можнооткрыть педивикию и почитать.
Если у тебя в работе постоянно используется топосорт, то спрашивай на собеседовании, прямо проси написать код или, хотя бы, псевдокод. Если в работе не нужно, то зачем спашивать?
Я вот на собеседованиях спрашиваю как написать клиентский(jquery+ajax) и серверный(asp.net) код. Такое как минимум придется писать раз в неделю.
А вот разворот списков и топологические сортировки не спрашиваю, они не нужны.

НС>Или ты думаешь что человек, не справившийся с разворотом списка, топосорт при этом легко напишет? Опять же, а как проверять знание азов программирования? Твои варианты задачек на отсеивание полных нулей какие?
Мы используем разворот строки на C#. Причем любой. В зависимости от того что напишет — дополнительные вопросы.
Ведущим еще задачку — увеличение на 1 числа, хранящегося в массиве поциферно или превращение потока символов в поток слов IEnuerable<char> -> IEnumerable<string>. Вторая задача на практике полезнее.

Здравствуйте, Vzhyk, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте?
G>>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.
V>Да причем тут это? Есть большая толпа что хочет крутую зарплату. Ка прикажешь их отсеивать? По сути для работы пофиг кого брать.
Давайте задачу близкую к реальной работе.

Мы берем SharePoint программистов, просим написать SharePoint код. Буквально 7 строк, но куча тонкостей, 30% на нем и отсеивается.

Здравствуйте, herethere, Вы писали:

H>О! Хорошо сказал! Вот примерно так я чувствую себя при общении с апологетами "паттернов проектирования" — думаешь, "где ж вы все такие умные были, когда 20 лет назад писали Винду?!" — ведь тогда никто не жаловался "ты не используешь фабрику!", люди просто РЕШАЛИ ЗАДАЧИ. Сами. Без "банды четырёх".

В винде можно найти практически все паттерны, которые есть у "банды четырех" и целая куча других, не менее популярных.
Например фабрики можно найти в виде ClassFactory в COM, там же можно найти локатор в виде моникеров, chain of responsibility в xml/html dom, composite там же, command во всех библиотеках и тд и тд и тд.

>А сейчас каждый задрот мне тыкает ехидно: "Какие паттерны ты знаешь?" (это я работу недавно искал) А я им: "Понятия не имею! Я пишу при помощи мозгов." — посмеялись, разошлись. Так, наверное, до сих пор и ищут "специалистов по паттернам"!

Если человек мало чем интересуется, то как правило, он всякие паттерны вряд ли будет знать. Как он будет общаться с коллегами по цеху — не ясно. Как минимум, паттерны нужо знать, ибо почти во всех источниках используется этот язык паттернов. Вместо погружения в сотни тысяч строк кода можно описать достаточно адекватную модель задачи при помощи паттернов и это будет просто и понятно.

Здравствуйте, herethere, Вы писали:

H>Алгоритмы — это просто собранные в кучу решения каких-то задач. Их знание или незнание — всего лишь вопрос опыта и МИНУТЫ ГУГЛЕНИЯ.

Вряд ли в гугле ты найдешь нужную тебе модификацию алгоритма или структуру данных. Общие вещи — запросто, специализированые — уже вряд ли. И, скажем, что бы правильно модифицирвать алгоритм или структуру данных нужно чтото больше чем гугление, потому что кроме решения надо еще доказать что решение обладает нужными тебе свойствами.

H>Если я впервые решаю задачу, даденую на работе, я в офисе даже палец о палец не ударю, потому что тупо не могу думать в офисной помойке — я собираю материал, приношу домой и в тишине и спокойствии начинаю думать.

Периодически бывают авраалы, фиксить приходится быстро, за минуты после обнаружения проблемы. Если ты в офисе думать не можешь, значит авраалы придется разгребать твоим товарищам.

Ну и непонятно,как ты будешь работать в команде. Если ктото зависит от тебя, то он каждый раз должен ждать "до завтра", пока ты созреешь.

>Ну и что умного ты хочешь выяснить о человеке, когда он на нервах сидит в кабинете незнакомой организации и какое-то существо в свитере и с бородой задаёт с прищуром ему вопросы! Я и возраст-то вспоминаю секунд пять, что уж говорить про красно-чёрные деревья и ряды Фурье!

Если ты решил,что специалист по алгоритмам, структурам данных и ЦОС, то крайне странно, что тебя поставят в тупик такие вопросы.

Здравствуйте, gandjustas, Вы писали:

I>>Правильно ! И дело в том, что во время работы нужно решать целую кучу всяких частных случаев, которые встречаются не чаще раза в жизни.
I>>Нет необходимости писать код который пишут все, такой код в 99% уже написан.
G>То есть ответ "ни разу"? Я не сомневался.

Правильно, вещи которые люди пишут часто и по многу, на раз находятся в гугле.

I>>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "
G>Так и спрашивай про граф или дерево, в чем проблема? Если только это нужно для работы.

Задача на граф или дерево слишком сложная, что бы давать её на собеседовании. Если скажем для отбора есть один день, как скажем делают в некоторых организациях, то можно дать и граф и дерево вместе взятые.

I>>Я сильно сомневаюьс, что человек сможет обойти дерево, если не смог обойти список.
G>Обход списка и разворот а месте — разные операции. Кроме того мы не про абстрактные навыки говорим, а про код на бумажке.
G>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.

Это заблуждение.

I>>Если не понимает указатели-ссылки, то на каком основании он называется программистом ?
G>Указатели далеко не везде есть. Более того, сейчас больше языков, где указателей нет.

"указатели-ссылки" — нет указателей, значит есть ссылки. В приведеной задаче про реверс списка указатель ничем от ссылки не отличается, там не нужна адрсная арифметика и тд и тд.

Здравствуйте, herethere, Вы писали:

I>>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "

H>Если человек не может что-то сделать СЕЙЧАС, это не значит, что он это не может сделать вообще. Более того — если даже он может обойти ваш @$#^ список, почему вы так уверены, что он так же легко разрулит, скажем, сбалансированное дерево?? Гарантии — никакой.

Над таким задачами думать более 15-20 нет смысла Никому не нуже кандидат, который в тривиальный случай списка вникает часами.

Задача показывает, что кандидат знает и понимает списки, ссылки-указатели, умеет писать код, умеет делать обход.
Все, что ему не будет хватать в задаче про сбалансированое дерево, это просто конкретные знания собственн про эти деревья.

Вот эту часть можно и нужно проверить отдельно от списков. Код писать необязательно, но если требуется, можно задть вопрос типа: "где вы применяли красно-черное дерево и чем был обоснован выбор"

H>Ну и вообще по проблеме: отнеситесь к найму человека как.... к ВЫБОРУ ДЕВУШКИ! Это не делается за час.

Мне кажется, свю девушку тебе еще выбирать много лет а то десятилетий Для коммерческой организаци это слишком дорого, а надежность всё та же — вот найдешь ты девушку, а она уйдет от тебя к любовнику положе, побогаче. Вот как научишься разрешать такие проблемы, приходи, будешь советы давать

H>Человек должен проявить себя в естественной среде — среди коллег или уж дома. И без подгонялова "вот вам час" (даже если задача решается за минуту) — человек просто по сути своей — живое существо и не может резко стать спокойным, особенно если он — "начинающий" или "середнячок".

Умение взять в себя в руки очень важно. Умение работать в критической ситуации так же очень важно.

H>Я даже "тугодума" взял бы с большей уверенностью, потому что выскочки-всезнайки (типа вот этой обидчивой девочки, которая тут с листочком и карандашом перевернула список) абсолютно не пригодны там, где требуется скрупулёзность и выверенность идей.

Правильно, бери тугодумов, мне меньше фильтровать придется

Здравствуйте, gandjustas, Вы писали:

G>Мы берем SharePoint программистов, просим написать SharePoint код. Буквально 7 строк, но куча тонкостей, 30% на нем и отсеивается.

Вот интересно, неужели эти тонкости настолько важнее умения программировать как такового?
Сколько нужно, чтобы ввести в них человека, который немного ориентируется в ASP.NET, пару месяцев?
Может лучше брать просто программистов, а не "SharePoint программистов"?

Здравствуйте, Ikemefula, Вы писали:

H>>...люди просто РЕШАЛИ ЗАДАЧИ. Сами. Без "банды четырёх".

I>В винде можно найти практически все паттерны, которые есть у "банды четырех" и целая куча других, не менее популярных.

Вот именно — паттерны "получились сами", их применили, потому что они были нужны. Сейчас всё ровно наоборот — бегает куча "списиалистов", которые знают шаблоны и так и ждёшь от них "хелловорлд" на 20 экранов — "а ларчик просто открывался".


I>Если человек мало чем интересуется, то как правило, он всякие паттерны вряд ли будет знать.

А что в знании ваших паттернов такого важного?? Я же специально дал вначале пример винды — вы что, прочли и так ничего и не поняли? Тогда какой смысл "всем интересоваться" как любопытный дельфин?

I>Как он будет общаться с коллегами по цеху — не ясно.

Да как веками это делали — на родном языке. Только вот из моего опыта я даже и не вспомню, хоть раз была ли у меня потребность разжёвывать "а вот тут я при помощи паттерна "фасад"..." — как правило, нормальному программисту объясняешь всё "в квадратиках", остальное он легко допирает сам.

I> Как минимум, паттерны нужо знать, ибо почти во всех источниках используется этот язык паттернов.

гыг Ну если только читать книги со словом "паттерны" — да, без них никуда! А так, в нормальной литературе, я не встречаю этого шарлатанства. Наверное, потому что не все авторы заражены Паттернами Головного Мозга. Поверьте мне, ещё лет 5-10 и про ваши шаблоны никто и не вспомнит, это просто сейчас раскрутили базворд, да деньжат на лохах книгах подняли — типичная преходящая мода. А главное, мода-то ни на что! Всё равно, что назвать чесание уха "ирскрэтчем", а все, кто просто говорит "я почесал ухо" — еретик и не следует канонам старейшин.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "
G>>Так и спрашивай про граф или дерево, в чем проблема? Если только это нужно для работы.

I>Задача на граф или дерево слишком сложная, что бы давать её на собеседовании.
Да ну? А как тогда проверить что кандидат таки умеет работать с графами? Это ведь нужно в первую очередь.


I>>>Я сильно сомневаюьс, что человек сможет обойти дерево, если не смог обойти список.
G>>Обход списка и разворот а месте — разные операции. Кроме того мы не про абстрактные навыки говорим, а про код на бумажке.
G>>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.
I>Это заблуждение.
Что именно?

I>>>Если не понимает указатели-ссылки, то на каком основании он называется программистом ?
G>>Указатели далеко не везде есть. Более того, сейчас больше языков, где указателей нет.
I>"указатели-ссылки" — нет указателей, значит есть ссылки. В приведеной задаче про реверс списка указатель ничем от ссылки не отличается, там не нужна адрсная арифметика и тд и тд.
А что нужно понимать в ссылках? Что после a=b; Object.ReferenceEquals(a,b)==true?

А причем тут разворот списка? Тебя уже сильно в сторону унесло. А ты даже близко не подошел к обоснованию полезности этой задачи.

Здравствуйте, ins-omnia, Вы писали:

IO>Здравствуйте, gandjustas, Вы писали:

G>>Мы берем SharePoint программистов, просим написать SharePoint код. Буквально 7 строк, но куча тонкостей, 30% на нем и отсеивается.

IO>Вот интересно, неужели эти тонкости настолько важнее умения программировать как такового?
А что есть "умение программировать как таковое"?

Мы ведь смотрим на опыт человека. Опытный человек с большей вероятностью умеет программировать, чем неопытный.
Задачи на программирование и на проектирование даем с учетом конкретной технологии. Не нужен человек, который умеет MVC в разработке для SharePoint.


IO>Сколько нужно, чтобы ввести в них человека, который немного ориентируется в ASP.NET, пару месяцев?
Практика показывает что от года.

IO>Может лучше брать просто программистов, а не "SharePoint программистов"?
Нет, не лучше. Слишком многому надо научить до того как пользу принесет.

Здравствуйте, Ikemefula, Вы писали:

H>>Ну и вообще по проблеме: отнеситесь к найму человека как.... к ВЫБОРУ ДЕВУШКИ! Это не делается за час.

I>Для коммерческой организаци это слишком дорого, а надежность всё та же

Вот это я вам и повторяю — независимо от ваших глупых собеседований, всё равно вы не можете достоверно сказать, что наняли лучшего программиста. Зато рассуждений о списках — целая простыня! Тогда какой смысл во всех этих хитродуманных задачах? Отсеять ламеров? Так это вы должны уметь уже по CV и первым трём предложениям.

I>Вот как научишься разрешать такие проблемы, приходи, будешь советы давать

Если я научусь давать такие советы, ты без квартиры останешься оплачивая моё время.
Я же сказал — это СЛОЖНО, это психология (а я всего лишь прогер). Так что типичный отсев можно свести к отбору наиболее опытных (5+ лет разработки коммерческих систем) и "рассуждательных беседах" типа "как вы подступитесь к задаче такой-то". Думаю, никакие ваши смешные указатели не заменят умения видеть и описывать глобальные проблемы.
Вот задача, например, написать "торговую систему" для международной корпорации — за 5 минут можно выяснить на каком уровне думает собеседник и может ли он предвидеть подводные камни. А что можно увидеть, "оборачивая список"??


I>Умение взять в себя в руки очень важно. Умение работать в критической ситуации так же очень важно.

Та... это вы "Матрицу" пересмотрели — не должно быть у программиста таких авралов. И даже если они есть, решаются они не написанием вычурного алгоритма, а тупо либо фиксеньем проблемы (если нашлась), либо врéменными подпорками. Никто и никогда при мне не бегал по офису "всё пропало!", люди просто садятся и решают. Хотя признаю, софт для атомных реакторов или биржи не писал. Впрочем, как и многие из нас.

Здравствуйте, gandjustas, Вы писали:

G>А что есть "умение программировать как таковое"?
Качества программиста, инвариантные относительно используемой технологии.

IO>>Может лучше брать просто программистов, а не "SharePoint программистов"?
G>Нет, не лучше. Слишком многому надо научить до того как пользу принесет.

Просто я работал с этим вашим Шарепоинтом, поэтому интересуюсь. По-моему там бессмысленно пытаться
выучить всё нюансы. Всегда вылезет что-то неожиданное. Нужно постоянно лезть туда рефлектором, чтобы
понять как оно работает, или в лучшем случае гуглить не решил ли уже какой народный умелец проблему.

Или вы делаете типовые проекты обходя все острые углы? Тогда это получается вроде "программиста/дизайнера jQuery"
ИМХО, тупиковое направление. Выучить стопицот подробностей о монстрообразной системе, которые имеют крайне узкое применение...
Завтра Микрософт переведёт всё это на чистый AJAX (уже наполовину сделали), и значительная доля этих знаний станет мёртвым грузом.

И если говорить о найме: людей, которые всё это знают всегда будет слишком мало, и что самое плохое, среди них будут
доминировать кадры с закостеневшим мышлением, привыкшие решать задачи шаблонами.

Здравствуйте, ins-omnia, Вы писали:

IO>Здравствуйте, gandjustas, Вы писали:

G>>А что есть "умение программировать как таковое"?
IO>Качества программиста, инвариантные относительно используемой технологии.
Например? Так чтобы не было привязано ни к .NET, ни к SharePoint.

IO>>>Может лучше брать просто программистов, а не "SharePoint программистов"?
G>>Нет, не лучше. Слишком многому надо научить до того как пользу принесет.

IO>Просто я работал с этим вашим Шарепоинтом, поэтому интересуюсь. По-моему там бессмысленно пытаться
IO>выучить всё нюансы. Всегда вылезет что-то неожиданное. Нужно постоянно лезть туда рефлектором, чтобы
IO>понять как оно работает, или в лучшем случае гуглить не решил ли уже какой народный умелец проблему.
Вот как раз пример почему гуглить не всегда поможет http://www.gotdotnet.ru/forums/5/145950/.
Лезть рефлектором дело благородное, если знаешь куда. Обычно не знаешь.

IO>Или вы делаете типовые проекты обходя все острые углы? Тогда это получается вроде "программиста/дизайнера jQuery"
Как раз типовых проектов почти нет. Слишком дорого берем и типовые проекты проходят мимо нас. Зато можем брать лучших спецов.

IO>ИМХО, тупиковое направление. Выучить стопицот подробностей о монстрообразной системе, которые имеют крайне узкое применение...
В том то и дело, что тупо все выучить не поможет. Даже нету всех особенностей в одном месте. Нужно понимать как устроено внутри.

IO>Завтра Микрософт переведёт всё это на чистый AJAX (уже наполовину сделали), и значительная доля этих знаний станет мёртвым грузом.
Ага, лет 5 так говорят. А ajax все еще оооочеь мало. Меньше чем могло бы быть.
И, скорее всего, ситуация не поменяется.

IO>И если говорить о найме: людей, которые всё это знают всегда будет слишком мало, и что самое плохое, среди них будут
IO>доминировать кадры с закостеневшим мышлением, привыкшие решать задачи шаблонами.
Я же говорю, знать все невозможно. Нужно понимать.

Здравствуйте, gandjustas, Вы писали:

G>>>А что есть "умение программировать как таковое"?
IO>>Качества программиста, инвариантные относительно используемой технологии.
G>Например? Так чтобы не было привязано ни к .NET, ни к SharePoint.
В контексте такой специализированной области как Шарепоинт трудно даже сказать.
Ну хотя бы умение разобраться в неожиданной/нетривиальной ситуации когда
ничего не работает, а что и где именно — не понятно.

G>Вот как раз пример почему гуглить не всегда поможет http://www.gotdotnet.ru/forums/5/145950/.
G>Лезть рефлектором дело благородное, если знаешь куда. Обычно не знаешь.
Для чего и как работает камл это ж вроде самые основы, нет?

IO>>Завтра Микрософт переведёт всё это на чистый AJAX (уже наполовину сделали), и значительная доля этих знаний станет мёртвым грузом.
G>Ага, лет 5 так говорят. А ajax все еще оооочеь мало. Меньше чем могло бы быть.
G>И, скорее всего, ситуация не поменяется.
Однако ж в последней версии ввели DisplayTemplate'ы на чистом JS.

G>Я же говорю, знать все невозможно. Нужно понимать.
Да, понятно. И всё же, ИМХО, обучить человека с общими знаниями о .NET можно гораздо быстрее чем за год.

Здравствуйте, gandjustas, Вы писали:

G>>>на хабре появилась небольшая, но фактически меняющая картину мира, статья:
G>>>Google признала, что головоломки на собеседованиях бесполезны
G>>>

G>>>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее

G>>>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков.
IS>>а может быть просто они вошли в ту стадию когда им больше нужны люди которые могут херачить стабильный код, чем те которые могут придумать что-то кардинально новое (новые проблемы) или новый подход решения старых проблем?

G>Я выше писал как обычно гугл принимает такие решения. Это не мнение одного человека. Обычно это база данных по сотрудникам за 10 лет и корреляция между метриками и результатами собеседования. Корреляция маленькая — гномики неэффективны.

т.е. им 15 лет понадобилось чтобы понять это ... метрики все время меняли или люди научились подстраиваться под метрики (сюрприз, сюрприз но если у тебя не сток опшенс — надо как то зарабатывать бонус, нет?) или это просто новый главный HR решил отличиться? неубедительно. и еще не надо забывать что гугл большая компания — то что им подходит может не подходить в средних и мелких компаниях которыйх большинство.

IS>>p.s. личное мнение — что на собеседовании есть место и гномикам и разговору по делу.
G>В том-то и дело что личное мнение. А практика обычно отличается.
практика и есть реализация личного мнения. или ты что-то другое хотел сказать.

по поводу боязнии гномиков и разворота списков — а код вы писать то не боитесь? или ищите на стековерфлоу?

личное мнение и подверждение из уже непалой практики — человек который не может писать код на собеседовании не должен быть программистом.
пускай он будет дизайнером, аналитиком, менеждером, поддержкой, тестером но не программистом.

Здравствуйте, gandjustas, Вы писали:

G>Лично я могу

Тогда непонятно, в чем проблема.

G>Если у тебя в работе постоянно используется топосорт, то спрашивай на собеседовании

Зачем? Мне не нужно знание топосорта, я его уже написал, я просто тебе реальный пример привел. Мне нужно, чтобы человек умел в голове оперировать ссылками.

G>Мы используем разворот строки на C#. Причем любой.

Там нет ссылок.

Здравствуйте, herethere, Вы писали:

H>Я так понимаю, ты ждёшь медаль "главный переворачиватель списков"?
Нет, но я категорически против того, что бы считать алгоритмы и структуры данных — "фитчей для всезнаек".

H>Ну так слушай:
H>1. Ты ни струя ни знаешь ни первого, ни второго, иначе бы решил эту, с позволения сказать, "задачу" не "на бумажке", а сходу из головы — она тривиальна и тому, кто "знает алгоритмы", бумажки не нужны. Ты же себя таким всезнайкой выставляешь, правильно?
Нет. Я не зазубриваю алгоритмы переворотов списков, потому, что бы решить задачу, сначала я перевожу свои мысли на листочек. Так делают все хорошие программисты.
Потому, что на этом этапе уже можно разглядеть некоторые ошибки в своей логике.
H>2. "Более элегантно" только шорты расстёгиваются, твоё решение — обычное, сотню раз описанное и непонятно, кому ты хотел его написать "более понятно".
В задаче переворота списков, да. А что там можно еще выдумать?
Но если брать что-то более сложное...