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

SE>Вот интересно, а как часто пользователь RSDN используют при регистрации адрес, "слишком сложный" для регекспа из одной строки?

Я имею ввиду синтаксис, с помощью которого можно указать одновременно адрес и имя-фамилию. Например

Vasya Pupkin <vasya@pupkin.com>

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

SE>Рассказывал мне когда-то коллега, в мейлер-демонах ранних версий была уязвимость, при передаче почтового адреса в качестве командной строки, этот вполне корректный с точки зрения RFC, но содержащий управляющие последовательности, адрес валил к чертям мейлер демона, и хорошо, если только его, и хорошо, если не перехватывал управление

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

Мир в те времена был безопаснее, и ключи от дверей можно было смело оставлять под ковриком

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

BZ>это как?

Ну, если скорость не интересует, то складываешь все числа в кучу, достаёшь два самых мелких, складываешь и засовываешь сумму обратно. И так пока не останется только одно число

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

D>Тоже интересно. Оказывается, Хаффман разносторонний человек был.

Да вы тут все знатоки переполнений, я гляжу

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

OW>Сумма элементов как впрос на отсеивание совсем нулёвых подходит, факториал тоже.
OW>А можно спросить на c++ факториал стадии компиляции через templates. Может он и не ответит, а если ответит?)

IMHO, это очень очень очень C++-specific, а кроме того, для предварительно отсева индусов это точно совершенно overkill...

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

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

M> 1. посчитать сумму элементов целочисленного массива
M> 2. найти площадь круга по радиусу
M> 3. записать текущую дату в текстовый файл

M>Неправильный ответ на любой из этих вопросов -- автоматическое no hire. Только если правильно и быстро смог ответить на все три вопроса, будем продолжать разговор. Детские ошибки, типа непроверки кода возврата open() в C -- означают, что в лучшем случае получит рекомендацию на junior.

M>Коллега считает подход неправильным, дескать, может человек на интервью что-то забыть, стресс там и все такое. Вот сегодня один штрих не смог "вспомнить" ф-лу площади круга. Я сразу сказал "no hire", коллега же еще поспрашивал ну и человек вроде бы всякую пургу типа AJAX на mid-level тянет. Коллега предлагает hire.

У меня такой принцип, приходит разработчик, я ему предлагаю выполнить три простых теста:
— стать в правильную боксерскую стойку
— сделать сальто
— забросить трехочковый мяч в корзину для баскетбола
Если допускает ошибку в любом из тестов — "no hire". Только если правильно и быстро смог выполнить три теста, будем продолжать разговор.
Детские ошибки, типа "поднятый подбородок в боксерской стойке" — означают, что в лучшем случае получит рекомендацию на junior developer.

Недавно пришел разработчик, не смог сделать сальто, и плохо закрывает печень в боксерской стойке. Я сразу сказал "no hire", коллега же еще поспрашивал ну и человек вроде бы всякую пургу типа T-SQL, C#, ASP.NET, ABAP, XSLT, WPF/Silverlight, WCF, IDEFX'ы на mid-level тянет. Коллега предлагает hire.

Ваше мнение?

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

ГВ>>Другого способа нет, как бы ты ни уповал на некие врождённые инженерные таланты. Поскольку таланты и способности — это одно, а владение системой символов и формальными методами — совсем другое.
E>IMHO, есть. Вот, скажем человек с подготовкой инженера-механика может быть подходящим?
E>А, лингвист?

Смотря, для каких задач и что это за специалисты. Если говорить о программировании, то мне кажется, что могут подойти оба. AFAIK, по крайней мере, подготовка по специальности "структурная лингвистика" кое-какую математику включает (глубже не расспрашивай — я здесь дилетант). Инженер-механик тоже подойдёт. Правда, скорее всего, подучивать той же ДМ придётся обоих. Но для них это не должно составить сложности.

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

ГВ>>>>Смотреть надо не только на то, что они знают сейчас, а ещё и на то, чему их учили до того, как. Отсюда естественно выводятся и тезисы о кодерах и т.д.
E>>>Это трудноисследуемо, увы.
ГВ>>Да ну. Это исследуется путём внимательного прочтения строчки "образование" в резюме.
E>Ну в современной РФ это не очень информативно, а насколько я понял топикстартера, в Индии, вообще бессмысленно читать что-то в резюме.

Думается, что это вопрос опыта таких исследований. Тебя никогда не спрашивали: "кто преподавал"?

E>>>Хотя я согласен, что отношение и степень вовлечённости и понимания предыдущих проектов — очень важный показатель.
ГВ>>При чём тут проекты...
E>При том, что именно там кандидат мог что-тоизучать "по ходу" и учиться учиться в таком режиме...

Ну, это да, конечно. Но базовой подготовки, ИМХО, такое "обучение" не заменит.

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

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

BZ>>это как?

E>Ну, если скорость не интересует, то складываешь все числа в кучу, достаёшь два самых мелких, складываешь и засовываешь сумму обратно. И так пока не останется только одно число
Месье знает толк в извращениях.....

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

D>Месье знает толк в извращениях.....
Месье не видит большой разницы между переполнениями и округлениями...

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


S>Недавно пришел разработчик, не смог сделать сальто, и плохо закрывает печень в боксерской стойке. Я сразу сказал "no hire", коллега же еще поспрашивал ну и человек вроде бы всякую пургу типа T-SQL, C#, ASP.NET, ABAP, XSLT, WPF/Silverlight, WCF, IDEFX'ы на mid-level тянет. Коллега предлагает hire.
А должность-то какая?

S>Ваше мнение?
Кто-то из вас, с коллегой, недавно открыл в стойке голову...

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

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


S>>Недавно пришел разработчик, не смог сделать сальто, и плохо закрывает печень в боксерской стойке. Я сразу сказал "no hire", коллега же еще поспрашивал ну и человек вроде бы всякую пургу типа T-SQL, C#, ASP.NET, ABAP, XSLT, WPF/Silverlight, WCF, IDEFX'ы на mid-level тянет. Коллега предлагает hire.
E>А должность-то какая?

Программист! Мне кажется мои тесты показывают способность человека быть программистом не хуже, чем тесты mymuss'а.

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

S>>>Недавно пришел разработчик, не смог сделать сальто, и плохо закрывает печень в боксерской стойке. Я сразу сказал "no hire", коллега же еще поспрашивал ну и человек вроде бы всякую пургу типа T-SQL, C#, ASP.NET, ABAP, XSLT, WPF/Silverlight, WCF, IDEFX'ы на mid-level тянет. Коллега предлагает hire.
E>>А должность-то какая?

S>Программист! Мне кажется мои тесты показывают способность человека быть программистом не хуже, чем тесты mymuss'а.

Вам не кажется, что "напишите программу подсчитывающую сумму элементов целочисленного массива" это несколько иное чем "сделайте сальто"?

Хотя кстати мысль неплоха (это я в шутку ), по моему опыту хорошее физическое развитые у программиста идущего скажем на сениора показывается, что программист вполне успешен — у него время и деньги на серьезные занятия в спортзале есть.

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

M> 1. посчитать сумму элементов целочисленного массива
M> 2. найти площадь круга по радиусу
M> 3. записать текущую дату в текстовый файл

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

Результат: можно с уверенностью сказать, что все ваши работники знают как:
M> 1. посчитать сумму элементов целочисленного массива
M> 2. найти площадь круга по радиусу
M> 3. записать текущую дату в текстовый файл

Теперь к Вам два вопроса:
1.Сколько Вам лет?
2.Вы хоть раз на собеседовании были?

А теперь история из жизни.
Когда я после увольнения из вооружённых сил устраивался на работу меня тоже не брали. У меня не было опыта о котором можно было бить себя в грудь. Ну не могу я зная два слова на иностранном языке сказать, что владею им в совершенстве(иняз- аналогия). А потом меня взял один человек( в последствии мой непосредственный начальник) и не задавал никаких умных вопросов. В результате, когда через несколько лет я уходил оттуда, вся работа была продвинута мной на совершенно другой уровень.
И вот теперь, когда у меня есть опыт, я бывает хожу на собеседования и выслушиваю там вопросы, решаю задачи, а потом полчаса объясняю умникам как эти две строчки работают. Или решил задачу, отослал, молчат, потом между прочим, спрашиваешь, ну как решение? Да так,- ВАЛИДНОЕ(слово то какое). А что, спрашиваю, у Вас есть другое, более эффективное-правильное-лучшее? Мялся мялся, потом с неохотой говорит: Да нет, это и есть правильное решение. А в вакансии написано что и такие они крутые и сякие, одним словом,- КОМАНДА.
Короче- детсад.

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

E>Ну, если скорость не интересует, то складываешь все числа в кучу, достаёшь два самых мелких, складываешь и засовываешь сумму обратно. И так пока не останется только одно число

Однажны на этот алгоритм мне ответили этим:

http://docs.sun.com/source/806-3568/ncg_goldberg.html
Theorem 8 (Kahan Summation Formula)

Линейный алгоритм с оценкой точности лучше чем в "наивной" реализации.

ГВ>Упс. А что, может???

переполнение это undefined behaviour. UB может сделать все что угодно, в частности спасти от переполнения

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

ГВ>>Упс. А что, может???

D>переполнение это undefined behaviour. UB может сделать все что угодно, в частности спасти от переполнения

Ни одной акулы не осталось, их всех распугали электрические скаты. (c)

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

G>И вот теперь, когда у меня есть опыт, я бывает хожу на собеседования и выслушиваю там вопросы, решаю задачи, а потом полчаса объясняю умникам как эти две строчки работают

вы в команде никогда не работали, похоже?

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

По-моему, полный бред. Спрашивать надо только то, чем реально придется заниматься кандидату после приема на работу (он же берется на какой-то конкретный проект, конкретную должность). Вот в прошлом проекте я в течение месяца помогал проводить техн. часть интервью, собеседовали ASP.Net разработчиков от mid до тим-лид уровней. Как это было в нашем случае:

Дается небольшой (20 вопросов) тест по C# и ASP.Net. Все вопросы уровня junior-mid. Пример вопросов: "Есть ли множественное наследование в С#?", "Где можно хранить состояние в ASP.Net", "Чем отличается Responce.Redirect от Server.Transfer?", "Чем плох тип Double для работы с денежными суммами?", "Тип String — value или reference type?" и т.п. Таким образом, правильно сделанный тест является предметом дальнейшего разговора и экономит массу времени. Любой mid level и выше с легкостью отвечает на все вопросы.

Но пока не начнешь проводить собеседования — и не узнаешь, сколько неадекватов и людей с гипертрофированной самооценкой приходят к HR. Никогда бы не подумал, что человек, написавший в резюме, что он 2 года работал тим-лидом на ASP.Net проекте не сможет мне сказать, чем отличаются value и reference types, где может храниться сессия и можно ли реализовать несколько интерфейсов одному классу. Оказывается, есть и такие "работники". При этом наверняка человек знал площадь круга и сумму массива может быть и написал бы... Только зачем мне это, если человека завтра сажать за сложный .Net проект?

В общем, проведя около трех десятков собеседований, получилось вот, что:

1. всего несколько человек прошли тест без ошибок (подтвердили заявленный в резюме уровень)
   
2. большая часть т.н. "тим-лидов" путались в эл. вещах и кричали об каком-то опыте "руководства", "анализа", "проектирования" и т.п.

Имхо, максимально конкретные вопросы, ответы на которые реально требуются для работы на проекте, куда берется кандидат — лучший способ проведения техн. интерью. Если человек не помнит площадь круга, треугольника, квадрата и не знает, что 2+2=4, но при этом видно, что он за короткий срок "въедет" в проект и обладает всеми необходимыми скилами для работы — надо его брать.

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

D>По-моему, полный бред. Спрашивать надо только то, чем реально придется заниматься кандидату после приема на работу (он же берется на какой-то конкретный проект, конкретную должность). Вот в прошлом проекте я в течение месяца помогал проводить техн. часть интервью, собеседовали ASP.Net разработчиков от mid до тим-лид уровней. Как это было в нашем случае:

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

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

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

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

Пример второго проекта в студию? И не забудьте, мы говорим о должности developer, разработка коммерческих бизнес-систем (окошкоклепапние).