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

V>>Т.е. площади кругов считаете?

M>Гм... странный вопрос. Думаете, в Гугле программеры ребусы решают?

M>Да, минимальные знания школьной математики необходимы. Я хочу на собеседовании прикинуть их наличие/отсутствие.

Вспомнилось. На интервью в Гугл я не смог вспомнить формулу площади поверхности шара. Поскольку точного ответа не требовалось (open ended question), сошлись на том, что это величина порядка квадрата радиуса (из соображений размерности).

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

I>>как образом ты хочешь пользовать здесь C# что бы все было достаточно наглядно, быстро и гладко ?
O>Пишешь на C# сборку, которая берет в качестве параметра конфиг и по нему разбирает текстовый файл. Подключаешь ее, как плагин к основной программе. Если надо разбирать хитровы..тый формат, пишешь сборку заточенную под него, если есть варианты данного формата, то цепляешь к ней еще и конфиг. Потом ассоциируешь тип файла со сборкой и конфигом. Все.

Ну, а сборка чем его разбирает? Чудом, что ли?

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

O>Описываешь эти операции на C#. Если есть повторяющиеся или похожии операции, то группируешь их в одну сборку и цепляешь к ней конфиг. Нет, я правда не понимаю в чем сложности.
+1, тоже ни черта не понимаю. Более того, за счет строгой типизации + очертененной гибкости C# я не представляю, как можно на самописном языке что-то описать лучше и понятнее, чем средствами самого C#. При нормальном проектировании код на С# будет как понятнее, так и компактнее написанного на наколенном языке. И кроме того, в случае с С# кроме нормального языка еще получаем нормальную среду разработки (особенно вместе с решарпером ), потенциальные баги вообще находятся до компиляции, а тем более до выполнения.

PS С наколенными языками или вкраплениями чужеродных языков сталкиваюсь постоянно. И всегда это языки оказывались самым узким местом, вынуждают копипастить логику, ограничевают в возможностях, содержат черти какое количество багов, приходится на них программировать в ноутпаде, падают и глючат в самом неожиданном месте, даже не записав в лог никакой ошибки, тормозят и жрут память черти как. Мое мнение, что наколенные языки придумывают с целью оправдать большее количество народа в проекте, с целью замедлить разработку и не отпустить заказчика от себя, так как кроме писателей уже в творчестве не разберется никто. И кроме времени на разработку языка, прибавляем сюда время на написании документации (которая не поддерживается в актуальном состоянии — если что не так — надо спрашивать у авторов, а документация листов на 100 минимум английского текста с кучей опечаток). Далее пишем под наш мегаязык плагин к студии, в результате чего студия начинает безбожно тормозить и постоянно падать, а при багфиксинге языкового движка изменяется синтаксис языка, и приходится героически искать ошибку — вчера все работало, никто ничего не менял, а щас половина функциональности не работает (да, для этого есть еще обратная совместимость, в результате в одном файле потом четырьмя стилями пишем). Слов называется нет, создаем себе трудности и потом героически их преодолеваем.
Я не сомневаюсь, что автор языка прекрасно будет на нем программировать, вот только этот автор мгновенно становится незаменимым, кроме него в этом никто не разберется.

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

Pzz>Ну, а сборка чем его разбирает? Чудом, что ли?

В зависимости от формата файла
1) Regex — годится для большинства форматов
2) String.Split — если поля разбиты разделителями типа запятой
3) String.Substring — если поля имеют фиксированную позицию
4) XmlReader или как там его — если xml
Делаешь эти четыре сборки с элементарным конфигом и их тебе хватит на 90%.

Есть извращенные форматы файлов, в том числе бинарные, их приходится разбирать ручками. Свой собственный язык тут не помогает, т.к. надо писать примерно то же, что и на чистом C#. А если еще прицепить helper assembly с утилитками помогающими разбору файлов, то вообще все замечательно получается.
В чем смысл собственного языка, можешь пояснить на наглядном примере?

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

BZ>код пишется один раз, а читается 10. и если второе будет понятней, то я обязательно перепишу

IMHO, понятно, обычно, то, что до преобразований
А вариант после преобразований, зачастую и компилятор могёт придумать...

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

AVK>Не, не все так просто. Кроме простейших правил преобразования логических выражений там много интересного, навроде методов устранения избыточности. Это, к примеру, применяется, когда функция описана только таблицей истинности, и нам нужно преобразовать эту таблицу в минимальный набор логических выражений в заданном базисе.

А на хрена это надо? Можно же выражение написать в дизьюнетно-коньюнктной (или как там это зовут?) форме, а дальше пусть компилятор упрощает, или матлаб какой, на самый худой конец. Ты же определители матриц, например, вручную не считаешь, наверное? На кой такие логические выражения руками упрощать?..

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

ГВ>Понятно: "сам не умею и другим не позволю". В принципе, я чего-то подобного и ожидал.
Я так понял, что скорее "знал, но забыл за ненадобностью"...

Я, кстати, тут подумал, и понял, что тоже не знаю нахрена бы булева алгебра нужна кодеру, кроме как для общего развития

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

M>Что касается логических выражений, то я согласен, что их надо писать "читабельно". Вот умение оперировать логическими выражениями и позволяет записывать их более читабельно. Первая мысль, которая приходит в голову, далеко всегда не ясная и понятная. Иногда результат условного выражения это результат разнесенных во времени размышлений. Мозг не всегда идет к цели кратчайшим путем. Бывает, что он ломится в открытую дверь, делает замысловатые изгибы и т. п. Результат этого---рабочее логическое уловие, но повторяющее все эти изгибы. Если его преобразовать можно (1) получить интересные открытия (например, ветвление совсем не зависит от переменной, которая казалась нам необходимой) (2) устранить все лишние изгибы и сделать его более понятным. Никогда не было такого: упрощаешь условие и думаешь "надо же, как все просто, а такого наворотил?"

В целом согласен. Но, IMHO, для того, чтобы писать простые и понятные условия надо таки уметь просто и ясно мыслить. Если тебе в этом помогает знание булевой алгебры -- прекрасно, что хоть что-то помогает. Аналитический ум дар крайне редкий.
Но в целом, IMHO, опять же, для того, чтобы ясно мыслить булева алгебра не нужна. Мало того, ясно мыслить намного важнее. Просто потому, что обычно программы устроены намного сложнее, чем какие-то условия в if'ах...

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

Pzz>А как вы себя убеждаете в том, что тот код, который вы понаписали, действительно решает поставленную задачу (или хотя бы завершается)? Методом научного тыка?

Неужели ты проводишь формальные доказательства?

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

M>>Ваше мнение?
E>Итого, в студенческие годы или если б я претендовал на первое место работы, я бы эти тесты прошел влегкую. Сейчас у меня шансов мало . Ну и далее, мне что-то кажется, что люди, прошедшие ваш фильтр при работе как раз и будут использовать везде массивы там, где нужны коллекции, в коде каждый раз будут лепить операции с файлами, даже не вынося эту логику в отдельный метод, так и будут 1000 раз в коде в разных местах открывать файл, проверять коды возврата, писать туда что-то и закрывать файл. Метрики на количество строк кода, написанного в день, будут потрясающие, сразу будет видно, что народ работает .

Так они вроде бы индусов и набирают...

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

Pzz>>А как вы себя убеждаете в том, что тот код, который вы понаписали, действительно решает поставленную задачу (или хотя бы завершается)? Методом научного тыка?

E>Неужели ты проводишь формальные доказательства?

Прикидываю в голове, как бы я его приводил.

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

M>Ну а как проверить знание элементарной математики?

Да надо что-то простовыводимое спрашивать. Скажем попросить посчитать сумму чисел от 1 до 1000, или спросить что-нибудь типа "что больше два в пятой или пять во второй?"
Только тут есть одна проблема. Всё-таки типа собеседование, стресс, у нормального кандидата могут начаться проблемы, с тем, что он не понимает где же его кинуть-то хотят?

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

M>У меня такой принцип, всем кандидатам сходу задается три простейших вопроса: на любом языке программирования написать ф-ции, ну например:
...
M>Ваше мнение?

Разумеется не стоит изменять принципам из-за одного кандидата. Тем более, что он экономит вам кучу времени. Но Вы сэкономите еще больше времени если к этому необходимому требованию добавите еще одно — достаточное.

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

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

ГВ>Хотя казалось бы — ну спросили и спросили. Быстро ответил, поржали вместе. Заодно, глдишь, и стресс снял бы.
Зависит от того, как спросить, IMHO. Можно так, что стресс снял, а можно так, что загрузишь зачем ты это спрашиваешь

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

SE>А что тогда, простите, спрашивать? Разглагольствовать на любую тему могут и дилетанты. Профессионалов как раз отличает знание деталей.
IMHO, лучше всего спрашивать про предыдущие проекты. Насколько логично и последовательно их делал чел, насколько он ими был увлечён, насколько детально разбирается...
А знает ли он какие-то конкретные тех. детали -- это лотерея, на самом деле...

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

AVK>Ты несколько меня не понял. Помнить специально наизусть — не нужно. Но я не представляю, как можно, если ты написал не одну игрушечную программку, не запомнить такой базовый момент. Это как для С++ программиста не помнить, что такое cout и с чем его едят. А уж если ты постоянно используешь .net в повседневной работе ...

Интересно, на хрена бы cout в Windows-программе? А ещё интереснее, нахрена в программе под MAC OS...

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

ГВ>У-у-у, как всё запущено-то, оказывается... Хотя, чему я удивляюсь, если никто из комментаторов о банальнейших вещах не вспомнил?
Особенностью вопросов на собеседовании является то, что не ясен контекст вопроса. Так, например, интересует ли кого-то в вопросе про суммирование массива твоё знание о том, что бывают переполнения, или твоё знание std::accumulate совершенно не понятно...

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

M>А если мне вдруг хочется засыпать кандидата, то задаю написать ф-цию для решения системы двух линейных уравнений. a11..a22, b1, b2, x1, x2 \in R.
M>Еще никто не справился. Впрочем, в свое время я и сам засыпался на этом вопросе

А что в данном случае обозначает "справиться"? Насколько я понял, суть разводки состоит в том, что множество значений представимых float это не R?..

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

M>Ваше мнение?

IMHO, в системе собеседований главное -- стабильность. Даже самый причудливый подход к отбору людей хорошо тем, что отбирает людей более или менее одинаковых, то есть способных понимать друг друга...

Хотя мне кажется, что все три вопроса сильно страдают тем, что совершенно не понятно ответ какого уровня от тебя хотят получить. Особенные подозрения у меня лично, например, вызвала бы площадь круга, конечно. Просто потому, что если в остальных двух вопросах я примерно понимаю в чём мог бы быть подвох, то в площади круга я бы впал в бесконечный цикл: "что же ему надо-то на самом деле?"
Правда бы сработал аварийный останов и я бы наверное переспросил, что нужна именно известная школьная формула Правда я не индус, с другой стороны.

Возможно неправильные во всём этом именно критерии зачёта. Типа должно быть чуть тоньше -- полный ступор, значит лесом, тот ответ, которого ждём -- значит идём дальше, а если не ступор, но и не то, чего ждём, то спрашиваем что-то ещё...

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

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

работать-то с новичком не только коллеге, "мнению которого нужно больше доверять".

Тут не надо дизъюнкции — тут конъюнкция уместна.

Если не согласны с этим — попробуйте ответить на следующий вопрос согласно Вашей логике:
если мнение коллеги настолько серьезно — то зачем Вам тратить свое время?

Еще веселее представить deadlock или always hire — каждый вежливо расшаркивается, мол
— Ах, так если Вам нравится этот кандидат — из чувства глубокого уважения к Вам лично я просто не могу возражать!
— Нет, нет! не подумайте чего — я только хотел сказать то же самое, я совершенно согласен с любым Вашим мнением!

при том что в кач-ве кандидата — хоть черт лысый. не знающий формулу площади круга. что характерно (с)

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