19.02.2011 9:37, Tilir пишет:
> Я ничего не сделал, чтобы избежать конфликта, совершенно точно. Но это > была ситуация в которой десять прошлых раз подряд конфликта не было даже > близко и я был к ней не готов (отчасти потому и написал чтобы послушать > мнения с разных сторон как себя положено вести). Что конкретно вы > предлагаете для разруливания таких ситуаций в будущем -- прекращать > собеседование и выдавать отказ сразу как только пациент занервничал на > первом же вопросе? А не слишком ли это жестоко, вдруг он просто > занервничал, сейчас чуточку отойдёт и ответит.
Вообще говоря, если предполагается, что он будет работать с вами, то в
первую очередь вы определяете эту возможность совместной работы, а не
его гениальность.
Поэтому, наиболее спокойно и мягко сворачиваете собеседование (если чел
показался неадекватным вам) и прощаетесь с ним.
19.02.2011 16:52, kaa.python пишет:
> > Значит что: программистов нельзя допускать до собеседований. т.к. они > мало того что облажаются, так еще и после этого свою лажу на всеобщее > обозрение выставляют.
Ну не все же такие, как ТС.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Так что тут все относительно. Для себя я лично сделал вывод — никогда не стоит задавать *слишком* простые вопросы. Это все равно что спрашивать профессионального наборщика, где какая буква на клавиатуре находится. Он точно ответит? Я, к примеру, нет, хотя печатаю вслепую.
ИМХО, если человек адекватный (профессионал), то он спокойно попробует ответить на простой вопрос и попросит перейти к более сложным вопросам.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
ВВ>>Так что тут все относительно. Для себя я лично сделал вывод — никогда не стоит задавать *слишком* простые вопросы. Это все равно что спрашивать профессионального наборщика, где какая буква на клавиатуре находится. Он точно ответит? Я, к примеру, нет, хотя печатаю вслепую. AJD>ИМХО, если человек адекватный (профессионал), то он спокойно попробует ответить на простой вопрос и попросит перейти к более сложным вопросам.
Неадекватности поведения я не оправдываю, но пользы от простых вопросов в действительности не так уж и много как кажется. И то, что человек профессионал не обязательно означает, что он хорошо умеют проходить интервью.
Здравствуйте, dilmah, Вы писали:
nvb>>Помню, смотрел код одного эмбеддера, весьма и весьма продвинутого. В одном месте я увидел копирование массива unsigned char[20] в цикле, хотя вполне можно было ограничиться ссылкой — данные не менялись.
D>ну не знаю специфики конкретно его процессора, но на обычных x86 скопировать жалкие 20 байт явно быстрее чем делать косвенные доступы.
Нет, это был совсем не х86, это был 16-битный msp430 с тактовой 8 МГц и оперативной памятью 2Кбайт. Там надо много думать, как код ляжет на архитектуру процессора. Эмбеддеры — это народ особый
nvb>>И он же, как мне потом рассказывал, на собеседовании не смог ответить на элементарный вопрос "как объявить две переменные, чтобы они гарантированно лежали в памяти рядом?"
D>ну и как? по моему, единственный разумный ответ это объявить массив, но тогда это будет уже не совсем переменные, а члены массива.
D>
D>int a[2];
D>int& x = a[0];
D>int& y = a[1];
D>
Ну.. почти Для разнотипных переменных это не пройдет. Надо структуру объявлять, и уже в ней — две переменных любого типа.
То есть я зря смотрел на эмбеддера выпученными глазами?
Здравствуйте, Олег К., Вы писали:
ОК>Предлагаю более прекрасный вопрос! Объявить указатель на массив десяти указателей на функцию которая принимает указатель на массив десяти указателей на функцию принимающую int и возвращающую void. Вопрос, по желанию, можно усложнить.
Объявить указатель на функцию, которая принимает в качестве аргумента указатель на функцию того же типа, что она сама. И возвращает в качестве значения указатель на функцию того же типа, что она сама.
Здравствуйте, dilmah, Вы писали:
nvb>>Ну.. почти Для разнотипных переменных это не пройдет. Надо структуру объявлять, и уже в ней — две переменных любого типа.
D>в структурах дырки ж бывают.
??? Не припомню. Впрочем, не претендую на доскональное знание плюсов. Пример можно? Впрочем, вспоминается что-то, типа резерва на будущее, но это же надо специально делать, само собой не получится. Не помню уже, многое забыл...
D>во-вторых, ты уверен (off-hand, не глядя в стандарт) что в стандарте прописано что элементы структуры не могут размещаться в другом порядке?
В стандарт не смотрел ни разу, вот такое я воинствующее невежество Но десять лет назад читал Подбельского "C++", там это все подробно расписано. Собственно, с этого раньше и начинали учить плюсы — с распределения памяти. Там же и ссылки на стандарт были. Приду домой — посмотрю точно.
Здравствуйте, Vzhyk, Вы писали:
V>18.02.2011 18:03, XuMuK пишет:
>> V>З.Ы. Да, мы поняли, что круче тебя только яйца. >> >> вы правда думаете что развернуть односвязный список это архисложная >> задача? тогда армадилло-таки прав, признаю. V>То есть ты согласен, что ты не представляешь как много программистов не V>способны сделать, написанное выше?
Я не согласен называть таких людей программистами, и уж тем более не согласен допускать их к разработке оптимизирующих компиляторов.
ЗЫ сколько таких людей работают в должности программиста я действительно не знаю, среди моих знакомых таких нет.
ЗЫЫ "разворот односвязного списка" это не трюки с хитровывернутыми указателями на массивы — это простейшая алгоритмическая задача (в рамках С/С++ она также проверяет знание базовых принципов работы с указателями).
21.02.2011 15:58, XuMuK пишет:
> ЗЫ сколько таких людей работают в должности программиста я действительно > не знаю, среди моих знакомых таких нет.
А в окружение ТС наоборот, по его словам.
D>>в структурах дырки ж бывают.
nvb>??? Не припомню. Впрочем, не претендую на доскональное знание плюсов. Пример можно? Впрочем, вспоминается что-то, типа резерва на будущее, но это же надо специально делать, само собой не получится. Не помню уже, многое забыл...
ну это ж классика: типа
struct { char x; int y; };
скорей всего на многобитных архитектурах будет дырка между x и y для выравнивания y.
Здравствуйте, dilmah, Вы писали:
D>>>в структурах дырки ж бывают.
nvb>>??? Не припомню. Впрочем, не претендую на доскональное знание плюсов. Пример можно? Впрочем, вспоминается что-то, типа резерва на будущее, но это же надо специально делать, само собой не получится. Не помню уже, многое забыл...
D>ну это ж классика: типа D>
struct { char x; int y; };
D>скорей всего на многобитных архитектурах будет дырка между x и y для выравнивания y.
Это не дырка, поскольку в нее ничего отдельно и неумышленно засунуть нельзя. Можно написать {char x[2]; int y}, и скорее всего, два char-а старый компилятор упихает в одно слово. Но вот struct {char x1; int y; char x2} точно займет 3 слова, и точно вначале будет расположен x1, затем y, затем x2, на чем это не компиляй.
И хватит, наверное, уже такую элементарщину рассматривать. Я понял, очевидно не для всех. И породил еще один вопрос для собеседований, оторванный от реальности
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, 0rc, Вы писали:
0rc>>Но самое ужасное — вы не закрыли позицию, а значит не факт что выиграли при этом.
J>Какой-то странный критерий J>Типа главное — закрыть позицию, а как и кем — не важно, и пофиг, что тебе потом с этим человеком на протяжении нескольких лет работать?
А только вопрос кандидату, то жители этого форума ответили бы так: "Что ты позволяешь себе спрашивать у человека с 10+ лет опытом, вот спросил бы меня такое, я бы немедленно ушел"
Здравствуйте, Vzhyk, Вы писали:
V>18.02.2011 8:07, Klatu пишет:
>> Яйца надо отрывать за такие задачки. V>Да ну. V>Подобные задачки с потолка не появляются, обычно они из кода рабочего V>выплывают.
Ну и зачем идти откапывать авгиевы конюшни от тонн этого говна. Такие вопросы хорошо характеризуют, с чем придется работать если принять предложение. Так что самое правильное- если жаль потраченного на дорогу времени, поболтать еще и забить, если нет- сразу послать интервьювера на йух.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, 0rc, Вы писали:
0rc>>>Но самое ужасное — вы не закрыли позицию, а значит не факт что выиграли при этом.
J>>Какой-то странный критерий J>>Типа главное — закрыть позицию, а как и кем — не важно, и пофиг, что тебе потом с этим человеком на протяжении нескольких лет работать?
M>Аутсорс...
Ты себе представляешь, что такое истерика аутсорсного программера? Это вообще весь проект поставить под удар. Особенно если сей программист действительно крут и ему в результате отдается на реализацию важная часть проекта.
Здравствуйте, jazzer, Вы писали:
J>Ты себе представляешь, что такое истерика аутсорсного программера? Это вообще весь проект поставить под удар. Особенно если сей программист действительно крут и ему в результате отдается на реализацию важная часть проекта.
"закрыть позицию" и есть задачи аутсорса. Проект это все второстепенное...
Здравствуйте, dilmah, Вы писали:
D>вот реальная ошибка связанная с непониманием массивов и указателей в реальном очень известном проекте (имена изменены):
D>
D>в результате копируются только первые байты (потому что sizeof(salt) < SALT_LENGTH) Самый прикол в том что этот баг теперь просто так не исправишь потому что это, грубо говоря, изменит хэши и все юзерские профили от старых версий окажутся некорректными.
Лично видел пару раз такие ошибки, и могу сказать, что реально это было следствие не непонимания указателей, а банальные описки.
По-хорошему вообще стандартами кодирования надо их исключать.
