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

_>Огромных БД с высокой нагрузкой тоже вроде процент небольшой. А так если несколько десятков пользователей, то до планов дело вряд ли дойдет.

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

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

S>ИМХО, задачи из категории "вот код, посмотрите и скажите нам, что мы увидим на экране" однозначно указывают на профнепригодность интервьюера. И прозрачно намекают на гнилость компании, в которой такие персонажи интервью проводят.

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

Уважаемый so5team, я могу только глубоко посочуствовать тому программисту, который:
1) Не в состоянии разобраться в 10-15 строках кода, распечатанных на бумаге. Как было указано, речь шла о простейшей программке.
2) Не помнит нескольких элементарных функций ANSI C (с которымы практически ежедневно так или иначе мы сталкиваемся).

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

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

AN>>Но язык был C++ и имеет ли смысл вопрос "чем отличается интерфейс от абстрактного класса", применительно к C++? Отдельных языковых конструкций для разделения этих сущностей нет.

S>имеет ли смысл такой вопрос? Серьезно? Каким образом отсутствие специализированных языковых конструкций является поводом не знать настолько базовыер вещи для человека, работавшего разработчиком 12 лет?

Ну ладно С++, а вот в С (без плюсов) например интерфейсы есть? А абстрактные классы?
Языковые примитивы и базовые концепции — где граница-то?

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

N>3. На foo(C) и foo('C'): это C++, а не C, значит, 'C' это char. При этом это не signed char и не unsigned char — значит, остаётся 1 или 2.
N>Уже дотягивает до мидла.

Серьезно?
В моем мире этот пример вообще ничего не говорит об уровне разработчика. Он говорит только о том, что он еще помнит некоторые тонкости системы типов (например, что char != signed char), которые в реальной жизни не нужны практически никогда (и быстро забываются).
Соответственно, пользы от таких примеров практически никакой.

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

bnk>Ну ладно С++, а вот в С (без плюсов) например интерфейсы есть? А абстрактные классы?
bnk>Языковые примитивы и базовые концепции — где граница-то?
В MSSQL к примеру уникальный ключ реализуется уникальным индексом, и от и то будет работать одинаково. Это не повод не знать об одном из этих понятий

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

AG>Уважаемый so5team, я могу только глубоко посочуствовать тому программисту, который:

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

AG>1) Не в состоянии разобраться в 10-15 строках кода, распечатанных на бумаге. Как было указано, речь шла о простейшей программке.

Вот вам пример простейшей задачки с кодом на "бумажке", которая, на мой взгляд, на 100% уместна:

auto x = 92;
auto y = 34;
auto a = x + y;
std::cout << ++y + x++;

What value is a?

Эта задачка настолько уместна, что используется в качестве капчи на одном их C++ных ресурсах.

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

Если же ваши задачки настолько же тривиальны, как пример с перегруженными функциями, который я привел в разговоре с уважаемым netch80, и при этом вы не ищете разработчика C++ компилятора или C++ stdlib, то вы профнепригодны по причинам, которые я изглагал в разговоре с netch80.

AG>2) Не помнит нескольких элементарных функций ANSI C (с которымы практически ежедневно так или иначе мы сталкиваемся).

Мне совершенно непонятно что именно из рассказанного мной позволило вам сузить пространство выбора до "нескольких элементарных функций ANSI C". Видимо, это еще одно проявления домысливания.

Но если вы хотите получить представление о том, о чем я говорил, то скажем я не помню формата метода std::list::splice. Более того, регулярно лезу в справочник, дабы перепроверить его название. И, могу предположить, процентов около 50 C++ников его название дословно наизусть не помнят. А процентов 25-30% так и не в курсе его существования.

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

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

AG>Уважаемый so5team, я могу только глубоко посочуствовать тому программисту, который:
AG>1) Не в состоянии разобраться в 10-15 строках кода, распечатанных на бумаге. Как было указано, речь шла о простейшей программке.
AG>2) Не помнит нескольких элементарных функций ANSI C (с которымы практически ежедневно так или иначе мы сталкиваемся).

Ну второе уже явно перебор.
У меня, например, сетевая специфика, и в зависимости от — я буду использовать или BSD sockets, или ASIO. Но помнить, например, где у start_async_read (или как оно там зовётся в ASIO) в коллбэке код результата, а где объём принятого... не помню, и лезу в доку. Это не мешает понимать общий принцип. А вот ANSI C при этом я могу по многу дней не использовать.
А если наоборот у меня какой-то переходник с управлением пайпами — то там в основном ANSI C + базовое Unix API. И снова — я помню порядок аргументов в memset() только от статей Viva64, а иначе смотрел бы в доку или подсказки IDE (а там этот порядок иногда критически важен).

Ну а что я ожидаю от чтения с бумаги — уже объяснял.

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

AG>>Уважаемый so5team, я могу только глубоко посочуствовать тому программисту, который:

S>Вот вам пример простейшей задачки с кодом на "бумажке", которая, на мой взгляд, на 100% уместна:

S>auto x = 92;
S>auto y = 34;
S>auto a = x + y;
S>std::cout << ++y + x++;

S>What value is a?

Что будет в `a` или что будет напечатано? Разница таки заметная.

S>Эта задачка настолько уместна, что используется в качестве капчи на одном их C++ных ресурсах.

И что, на неё нельзя ответить без компиляции?\

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

Что вы называете предварительными этапами? Скрининг от HR, предварительное техническое интервью по сети, или что?

S>Если же ваши задачки настолько же тривиальны, как пример с перегруженными функциями, который я привел в разговоре с уважаемым netch80, и при этом вы не ищете разработчика C++ компилятора или C++ stdlib, то вы профнепригодны по причинам, которые я изглагал в разговоре с netch80.

И я не согласен — и тоже уже объяснил, почему (и что ожидается от кандидата).

AG>>2) Не помнит нескольких элементарных функций ANSI C (с которымы практически ежедневно так или иначе мы сталкиваемся).
S>Мне совершенно непонятно что именно из рассказанного мной позволило вам сузить пространство выбора до "нескольких элементарных функций ANSI C". Видимо, это еще одно проявления домысливания.

Тут согласен.

S>Вероятно, если бы я попал к вам на собеседование, то завалил бы его и не получил возможности работать под вашим началом. Чему совершенно искрене рад.

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

N>>3. На foo(C) и foo('C'): это C++, а не C, значит, 'C' это char. При этом это не signed char и не unsigned char — значит, остаётся 1 или 2.
N>>Уже дотягивает до мидла.

L>Серьезно?
L>В моем мире этот пример вообще ничего не говорит об уровне разработчика. Он говорит только о том, что он еще помнит некоторые тонкости системы типов (например, что char != signed char), которые в реальной жизни не нужны практически никогда (и быстро забываются).

"Реальная жизнь" она разная. Например, если речь про работу с бинарным форматом, то это постоянно надо иметь в виду. Может, у вас такие задачи редки, а у меня текущие компоненты на C++ все имеют подобную специфику.

Таки да, разные миры — тут согласен.

L>Соответственно, пользы от таких примеров практически никакой.

Ну я, видимо, к вам и не пошёл бы. (Что-то этот тезис начинает тут в теме всё чаще звучать.)

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

N>>когда начали приводить маргинальные примеры в качестве обоснования своего мнения и когда в ответ на прямое указание, что эти примеры маргинальны и совершенно не обязательно следуют из ваших общих слов — начали кидаться фразами типа "показать себя самым мудрым и опытным" или, как в данном случае, "объясню на пальцах" (ещё одна откровенная попытка принизить оппонента).
S>Простите, но я не могу спорить с тем, как вы воспринимаете мои слова. Я высказал свое мнение (оно специально было помечено аббревиатурой "ИМХО", причем заглавными буквами). Затем объяснил, почему оно такое.

На этом этапе я ещё просил уточнения. А вот ваши пояснения не просто показали их... мнэээ... странную мотивацию, но и тут же начали сопровождаться сомнительными полемическими приёмами.

S>Но вы, похоже, наполнили мои слова каким-то своим смыслом. И теперь спорите не с тем, что я сказал. А с тем, что вы за меня домыслили. При этом еще и меня в домысливании обвиняете.

Да, можно и так считать. Потому что в разных сообщениях приводятся разные тезисы, и обоснования связи между ними откровенно недостаточны.

N>>Из, например, написания на бумаге никак не следует придирка к порядку аргументов или опечатке в названии.
S>Не следует, согласен. Но я приводил конкретный пример. В котором есть придирки и к названием, и к порядку следования аргументов.

OK, уже хорошо, что не следует.

S>Может быть вам не нравится этот пример. Ну ОК. Однако, я именно такой привел. И не просто так я его привел.

N>>Ну так и я могу загнать в крайность: например, ok, пусть вам дан IDE, компилятор и прочее. Вам дадут код на 50 экранов и потребуют починить проблему за 5 минут. За это время вы успеете только выделить в уме основные сущности, потом вам скажут "как, вы ничего не сделали? ваш уровень — джун за 100$" и погонят. Устраивает такое?

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

Серьёзно? Ну, может, таких инженеров сотня на всю планету найдётся.

N>>Да, я доказываю, что вы зачем-то берёте маргинальные примеры
S>Спасибо, не нужно. Я их специально такими привожу. Чтобы явно обозначить крайности которые вряд ли применимы на собеседованиях.

И вот зачем вы так делаете?
При вас упоминают подход — вы тут же его загоняете в крайность, и на основании свойств этой крайности его отрицаете.

N>>Вы понимаете вообще, что обсуждение всегда предполает взвешивание аргументов и поиск логических связей?
S>Вы, похоже, просто не принимаете аргументов, которые вам не нравятся. А потом жалуетесь на отсутствие логических связей.

Это как раз то, что я про вас говорил.

N>>Я вот периодически таки в сложных случаях печатал код на бумагу и разбирался с ним. Потому что удобно обвести, почёркать, нарисовать стрелки, и всё такое. Потом шёл, да, к редактору/IDE, и правил, если надо. И я совершенно нормально воспринимаю и написание на бумаге — а какая разница от рисования примеров, например, на доске мелом? Главное — что при этом не должно быть действительно придирок в том, что большинству при этом несущественно — на данном этапе. Вот это и надо смотреть в интервью.

S>Это все прекрасно. И вы не один такой. Но это совершенно не относится к моему мнению о том, что когда программисту дают какой-то фрагмент на бумаге и просят показать, что буде напечатано, то это

S>a) вряд ли будет хоть как-то соотноситься с тем, чем человеку придется заниматься впоследствии;

Есть статистика? Вы не привели её и даже не сказали про её существование.

S>b) подвержено ошибкам потери внимания (из-за которых неверный ответ ничего не скажет о том, насколько соискатель хороший программист);

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

S>c) есть более эффективный подход с использованием распечатанного на бумаге кода.

Какой?

N>>Дальше я могу развить мысль о том, что, например, мне крайне странно, что кто-то вообще ничего не напишет без IDE (или даже без редактора). Я не буду вспоминать перфокарты, но мне странно, что пример на 10 строк не может быть отработан на whiteboardʼе. Вот это уже осмысленное обсуждение и если вы скажете "ну не получается у меня это, мне только IDE", это будет осмысленно — тогда можно будет сравнивать интервьеров (какие на это сразу говорят "вы ничего не умеете", а какие входят в специфику) и искать доли таких. Или собирать опросы. Думаю, кто-то это уже делал.
S>Да сколько угодно. Только вся эта лирика не относится к тому, о чем я говорил.

И опять "вся эта лирика" как отмахивание и "не относится" без аргументов. Ну что ж, слив засчитывается.

N>>Но пусть это действительно ваша личная субъективная специфика, ok. Хотя если бы тут реально не увидели (опросом это не решить, надо тестировать вживую) тот break менее 5% кандидатов, то ваша специфика уже становится неактуальной в среднем, как бы она ни была важна для вас лично.
S>Если я попадаю в эти 5% отсеянных в результате подобной методики собеседования, то мне как-то пофиг на средние показатели.

Должны ли мы в теме интервьюирования привлекать вопросы социального равенства?

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

Умный и опытный интервьюер хотя бы попытается поискать личный подход к кандидату. Ну а если нет — см. выше.

N>>Вот я считаем правильно ответил по 3 из 4 моментов. Всё, меня не принимают? Даже если именно эта особенность просто не может встретиться мне за всю работу, потому что такой код писать никто не будет?
S>Это вы спросите у тех, кто подобные методики применяют. Мне они кажутся порочными. О чем я и говорю. Так что ответить на вопрос "Всё, меня не принимают?" не могу.

Ещё раз — что из "подобных методик" порочно?
Просто оценка по одному примеру и немедленное отсечение по мелочи? Да, согласен.
Вообще использование подобного примера? Безусловно нет, он хороший материал для проверить (разумеется, если не единственный).

N>>Который тут вообще не должен помочь (проверил на gcc). Зачем ему тут такое упоминать-то?

S>Затем, что это бонус, когда C++ник знает, что знаковость char может "плавать" туда сюда. И что на эту знаковость не стоит расчитывать. Не все знают, особенно в начале карьеры.

Тема знаковости char и тема его отличия от signed char и unsigned char — разные. Мой вопрос был не к тому, что какой смысл в знании знаковости char (и тем более в компиляторе от MS), а в том, как это связано с примером. Но это уже вопрос опыта — может, вы видели, что какая-то заметная часть вспоминает это.

S>>>При этом оговорюсь, в моем чек-листе на собесдование пункта "разбирается в правилах C++ной перегрузки" не было бы вообще. Если бы только я не искал разработчика C++ного компилятора или хардкорной C++ной библиотеки с десятиэтажными шаблонами внутри.
N>>А у меня — было бы.
S>А у меня было бы лишь в перечисленных выше случаях. И что, мы теперь будем до посинения повторять друг другу "а у меня, а у меня"?

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

S>Напомню лишь, что этот пример был приведен как пример того, что обычно предлагают в подобных задачках на интервью. Сам я такое не практиковал, т.к. считаю подобную практику порочной.

Так всё-таки какие признаки этой "обычности"? Доля случаев, специфика мест работы?

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

Безусловно. С этим и не собирался спорить.

N>>Ну так цифры будут? Типа "100 кандидатов, на бумаге смогли что-то изобразить только 6, нашли проблему в этом коде не запуская 17, запуская поняли ответ 33". Если не секрет, конечно. Если секрет — ну что ж, тогда действительно продолжать незачем.
S>Цифр не будет. Просто я сам думал, что есть одна причина. А начал проверять, оказалось, что как миниму две. Поскольку сам я средней руки разработчик, то предположу, что подобную ошибку в определении причин легко допустили бы такие же как я, т.е. многие.

Вторая, если я правильно понял, о чём речь — совсем не принципиальна (разве что для разработчика компилятора — и то не всегда).
Что цифр не будет — жаль.

N>>А вот на шаг дальше — зачем это "строго хуже" нужно для сравнения? Поужасать?
S>Показать конечный пункт направления движения при использовании сомнительных подходов к собеседованиям. В вашей классификации это может быть "поужасать".

OK, спасибо за откровенность.

S> А нужно или не нужно -- это пусть каждый читатель форума сам решает. Вам не нужно. Но вы и не все.


принято.

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

S>Вот вам пример простейшей задачки с кодом на "бумажке", которая, на мой взгляд, на 100% уместна:
S>[code]
S>auto x = 92;
S>auto y = 34;
S>auto a = x + y;
S>std::cout << ++y + x++;

127 (написал, не глядя в компилятор, просто следуя логике C/C++)

Но так писать всё-же не стоит, этот стиль я называя "запутать_врага"

Ну и конечно же — есть разница между: простейший и короткий.

Я упоминал о именно о простейшей задачке, демонстрирующей самые основы.
Вы привели достаточно непростую, но короткую.

S>Мне совершенно непонятно что именно из рассказанного мной позволило вам сузить пространство выбора до "нескольких элементарных функций ANSI C". Видимо, это еще одно проявления домысливания.

S>Но если вы хотите получить представление о том, о чем я говорил, то скажем я не помню формата метода std::list::splice.
+100500
Так никто и не настаивает его запоминать (я тоже на память такое не помню).

Но не помнить, например:
printf("%d", n);
или
std::cout << i << ", " << j << ", "<< k << std::endl;
Это уже нужно быть совсем не программистом.

Всё именно рассчитано НЕ на зазубривание чего либо, а именно на знание и понимание.

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

N>Что будет в `a` или что будет напечатано? Разница таки заметная.

Что будет в `a`. По поводу "что будет напечатано" мне вообще сложно вспомнить какие-то вменяемые примеры подобных задач. Все, что вспоминается, так это как раз вариации на тему перегрузки функций и неявного конвертирования типов (вроде того, что передача строкового литерала приводит к вызову функции, ожидающей bool, или что-то типа этого). Но это так себе задачки.

А вот именно в такой формулировке -- хорошо. Типа детской задачки "представьте, что вы водитель троллейбуса...", только для высоковозрастных детей, работающих программистами.

S>>Эта задачка настолько уместна, что используется в качестве капчи на одном их C++ных ресурсах.

N>И что, на неё нельзя ответить без компиляции?\

Подозреваю, что это риторический вопрос.

N>Что вы называете предварительными этапами? Скрининг от HR, предварительное техническое интервью по сети, или что?

Зависит от того, как процесс найма построен. Это может быть вообще форма подачи резюме на сайте компании, в которой для того, чтобы отослать резюме нужно пройти через такую капчу.

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

N>На этом этапе я ещё просил уточнения. А вот ваши пояснения не просто показали их... мнэээ... странную мотивацию, но и тут же начали сопровождаться сомнительными полемическими приёмами.

Боюсь, все это можно отнести к особенностями вашего восприятия чужого текста. Поэтому комментировать это не буду. Равно как и другие ваши высказывания по поводу того, насколько стройно или нестройно я веду дискуссию.

N>OK, уже хорошо, что не следует.

И никогда не следовало.

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

N>Серьёзно?

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

N>>>Да, я доказываю, что вы зачем-то берёте маргинальные примеры
S>>Спасибо, не нужно. Я их специально такими привожу. Чтобы явно обозначить крайности которые вряд ли применимы на собеседованиях.

N>И вот зачем вы так делаете?
N>При вас упоминают подход — вы тут же его загоняете в крайность, и на основании свойств этой крайности его отрицаете.

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

Т.е. я специально говорю о крайностях для того, чтобы обозначить степень порочности.

S>>a) вряд ли будет хоть как-то соотноситься с тем, чем человеку придется заниматься впоследствии;

N>Есть статистика? Вы не привели её и даже не сказали про её существование.

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

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

S>>b) подвержено ошибкам потери внимания (из-за которых неверный ответ ничего не скажет о том, насколько соискатель хороший программист);

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

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

S>>c) есть более эффективный подход с использованием распечатанного на бумаге кода.

N>Какой?

Внимательнее, пожалуйста, читайте то, что вам пишут. Я уже говорил: дайте соискателю распечатку реального кода и попросите рассказать, что он о нем думает.

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

N>>>Но пусть это действительно ваша личная субъективная специфика, ok. Хотя если бы тут реально не увидели (опросом это не решить, надо тестировать вживую) тот break менее 5% кандидатов, то ваша специфика уже становится неактуальной в среднем, как бы она ни была важна для вас лично.
S>>Если я попадаю в эти 5% отсеянных в результате подобной методики собеседования, то мне как-то пофиг на средние показатели.

N>Должны ли мы в теме интервьюирования привлекать вопросы социального равенства?

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

N>>>Вот я считаем правильно ответил по 3 из 4 моментов. Всё, меня не принимают? Даже если именно эта особенность просто не может встретиться мне за всю работу, потому что такой код писать никто не будет?
S>>Это вы спросите у тех, кто подобные методики применяют. Мне они кажутся порочными. О чем я и говорю. Так что ответить на вопрос "Всё, меня не принимают?" не могу.

N>Ещё раз — что из "подобных методик" порочно?
N>Просто оценка по одному примеру и немедленное отсечение по мелочи?

Да, именно это. Хотя тут можно расширить: подход с демонстрацией N примеров, допускающих только однозначно верные ответы, и оценка по количеству правильных ответов. Т.е. вариация тупого тестирования.

N>Да, согласен.

Тогда к чему спор?

N>Вообще использование подобного примера? Безусловно нет, он хороший материал для проверить (разумеется, если не единственный).

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

N>Тема знаковости char и тема его отличия от signed char и unsigned char — разные. Мой вопрос был не к тому, что какой смысл в знании знаковости char (и тем более в компиляторе от MS), а в том, как это связано с примером.

Меня очень бы порадовал ответ типа такого: "Я думаю, что ответ будет вот таким, но следовало бы еще проверить, если ключиком компилятора выставить char как unsigned". Это сразу бы был большой бонус соискателю.

N>Так всё-таки какие признаки этой "обычности"? Доля случаев, специфика мест работы?

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

N>Вторая, если я правильно понял, о чём речь — совсем не принципиальна (разве что для разработчика компилятора — и то не всегда).

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

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

AG>127 (написал, не глядя в компилятор, просто следуя логике C/C++)

"Поздравляю, Шарик, ты балбес" (с)

Задача была вовсе не в этом.

Но зато вы наглядно показали как легко упустить важную деталь из поля зрения. Как раз для статистики netch80.

S>>Но если вы хотите получить представление о том, о чем я говорил, то скажем я не помню формата метода std::list::splice.
AG>+100500
AG>Так никто и не настаивает его запоминать (я тоже на память такое не помню).

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

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

S>Спиральная динамика рулит. Не всегда, правда, успевает за ростом ЧСВ, но рулит. И бибикает.

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

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

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

AN>>Но язык был C++ и имеет ли смысл вопрос "чем отличается интерфейс от абстрактного класса", применительно к C++? Отдельных языковых конструкций для разделения этих сущностей нет.

S>имеет ли смысл такой вопрос? Серьезно? Каким образом отсутствие специализированных языковых конструкций является поводом не знать настолько базовыер вещи для человека, работавшего разработчиком 12 лет?

Разработчик мог всё это использовать не зная, как это называется. Для C++ вместо термина "интерфейс" как правило применяется термин "чисто виртуальный класс". И для объявления абстрактного класса достаточно добавить = 0 к определению метода, без дополнительных объявлений в классе. И наследовать их можно как угодно. Т.е. — граница между интерфейсом и абстрактным классом в C++ очень размыта. В отличие других языков, например Java, где эти понятия жёстко разделены.

Если хочется проверить умение применять ООП, имеет смысл спросить примерно накидать иерархию классов и взаимодействие объектов для какого-нибудь примера и объяснить, почему именно так сделано. А вопрос по терминам покажет только знание терминологии, а не понимание ООП и умение его применять.

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

A>Ну вот такая контора, у них (нас уже) план собеседование четко прописан и точка входа у всех одна, дальше уже отличия.
Только надо понимать, что ты шёл на 200к в год и в компанию где ошибка и время программиста очень дорого, а ТС шёл в компанию где достаточно условной лопаты и копать от забора и до ужина.

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

N>>На этом этапе я ещё просил уточнения. А вот ваши пояснения не просто показали их... мнэээ... странную мотивацию, но и тут же начали сопровождаться сомнительными полемическими приёмами.
S>Боюсь, все это можно отнести к особенностями вашего восприятия чужого текста. Поэтому комментировать это не буду. Равно как и другие ваши высказывания по поводу того, насколько стройно или нестройно я веду дискуссию.

Не требуется комментирования, просто учтите, что так делать нежелательно даже на таком полемическом форуме.

S>>>Сколько угодно, хозяин барин. На этот пример я скажу, что по-моему, это плохой подход к проведению собеседования. Но, может быть, если вы ищите инженеров в первую линию техподдержки, для круглосуточных дежурств, когда ночью могут срочно потребовать найти и исправить баг, то этот подход себя и оправдает.
N>>Серьёзно?
S>Настолько же серьезно, насколько серьезно вы сами такой подход предлагаете.


Ну вот, вы, оказывается, сами понимаете, что доводить до абсурда — бессмысленно. Тогда зачем всё это было?

N>>>>Да, я доказываю, что вы зачем-то берёте маргинальные примеры
S>>>Спасибо, не нужно. Я их специально такими привожу. Чтобы явно обозначить крайности которые вряд ли применимы на собеседованиях.
N>>И вот зачем вы так делаете?
N>>При вас упоминают подход — вы тут же его загоняете в крайность, и на основании свойств этой крайности его отрицаете.
S>Потому, что я совершенно серьезно считаю такой подход порочным. И он настолько порочен, что крайностей хуже него найдется не так уж много. Одна из таких крайностей -- это требовать написать код на бумажке сходу и без ошибок.

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

S>Т.е. я специально говорю о крайностях для того, чтобы обозначить степень порочности.
S>>>a) вряд ли будет хоть как-то соотноситься с тем, чем человеку придется заниматься впоследствии;
N>>Есть статистика? Вы не привели её и даже не сказали про её существование.
S>Вам серьезно нужна статистика случаев, когда на собеседовании просят рассказать что выведет напечатанный на бумажке код, а после приема на работу программист никогда такими вещами по работе заниматься больше не будет? Вы, блин, серьезно?

Да, я серьёзно. Потому что я не считаю различие "на бумажке" и "в IDE" сколь-нибудь значимым самим по себе, без прочих параметров, как сложность, объём и всё такое. Это не различие, как, например, когда приходит кандидат на C, а его посылают на совершенно незнакомый до того Javascript (как сделали со мной в одном месте), или когда приходит на GUI, а его посылают на бинарные сетевые протоколы.
Ничего фатального тут в бумаге нет, пока не требуются специфические возможности IDE (о которых уже упоминал).

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

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

Читать код — норма. Понимать, что делает код, если он объёма, например, до экрана и все вызываемые средства понятны — тоже норма. И это можно проверить с бумаги, при тех же ограничениях. Перенос, как вы описали — что на работе будет тоже бумага — не имеет смысла.

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

S>Не игнорирую, а считаю, что если нам важно посмотреть, как кандидат думает, то давать пример, предполагающий однозначно проверяемый ответ, не лучшая стратегия.

И тем не менее вы привели как положительный — пример, для которого хотели однозначный ответ.

S>>>c) есть более эффективный подход с использованием распечатанного на бумаге кода.
N>>Какой?
S>Внимательнее, пожалуйста, читайте то, что вам пишут. Я уже говорил: дайте соискателю распечатку реального кода и попросите рассказать, что он о нем думает.

А это ничего, что я предложил как раз осмысливание кода вслух? Вы теперь то же самое говорите мне.

S>Кстати говоря, вы почему-то решили, что здесь речь должна идти о стиле кода. Непонятно почему.

Потому что стиль тоже важен. И я написал

>> а потом и к стилю перейти?

"потом" тут принципиально.

N>>>>Но пусть это действительно ваша личная субъективная специфика, ok. Хотя если бы тут реально не увидели (опросом это не решить, надо тестировать вживую) тот break менее 5% кандидатов, то ваша специфика уже становится неактуальной в среднем, как бы она ни была важна для вас лично.
S>>>Если я попадаю в эти 5% отсеянных в результате подобной методики собеседования, то мне как-то пофиг на средние показатели.
N>>Должны ли мы в теме интервьюирования привлекать вопросы социального равенства?
S>Мы должны хотя бы определиться с тем, кого мы ищем: середнячков, коих нужно набрать в товарных количествах, дабы они работу работали и были взаимозаменяемы, либо мы стараемся отбирать людей, производительность которых будет в два-три раза выше и которые будут предлагать нешаблонные решения, но которыми может быть гораздо труднее управлять. Разные задачи, разные подходы.

И что из этого должно следовать?
Вот я предлагаю прочитать 10-строчный пример с бумаги. Он тут же разворачивается и хлопает дверью, как ТС по рассказам его критиков?
В чём вы пытаетесь меня убедить — что если кто-то предложил прочитать с бумаги, то он робот, действующий по алгоритму и он отбракует самых интересных?
Должен ли я на этом основании считать, что вы уже перешли к необоснованным домыслам?

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

"Оценка по количеству правильных ответов" != "оценка только по количеству правильных ответов"
Уже говорил: я такое проходил. Вначале дали тест, на пачке коварных примеров. Потом пошло обсуждение. Просто тест сам по себе недостаточен, но заведомо непригодных позволяет отсеять.

N>>Да, согласен.
S>Тогда к чему спор?

Ко всему остальному, что обсуждалось.

N>>Вообще использование подобного примера? Безусловно нет, он хороший материал для проверить (разумеется, если не единственный).
S>Возможно, в ваших условиях подобные примеры работают хорошо. И это дает вам основание думать, что я не прав.
S>Я же, когда изучал вопрос о том, как лучше проводить интервью, пришел к выводу, что подобный подход порочен. И что он может быть легко модифицирован чтобы приносить лучшие результаты. А уж если он не был модифицирован и применяется как есть, то это говорит о профнепригодности интервьюера.

"Когда изучал", был после этого реальный фидбэк?

N>>Тема знаковости char и тема его отличия от signed char и unsigned char — разные. Мой вопрос был не к тому, что какой смысл в знании знаковости char (и тем более в компиляторе от MS), а в том, как это связано с примером.
S>Меня очень бы порадовал ответ типа такого: "Я думаю, что ответ будет вот таким, но следовало бы еще проверить, если ключиком компилятора выставить char как unsigned". Это сразу бы был большой бонус соискателю.

А то, что именно тут ключ не влияет — для вас несущественно?
Тогда вы, наоборот, отсеете тех, кто грамотнее (помнит с ходу, что char !== signed char !== unsigned char).

N>>Так всё-таки какие признаки этой "обычности"? Доля случаев, специфика мест работы?
S>Послушайте, а откуда народ узнает, что на собеседованиях спрашивают про форму крышек люков и условных гномиков? Вам реально нужно знать какой процент контор все еще практикует подобные задачи?

Если идти по собеседованиям — да, надо знать. Потому что если таких заметная часть, придётся к этому готовиться, даже если знаешь, что внутри есть реальные задачи.
Это не очевидно?

N>>Вторая, если я правильно понял, о чём речь — совсем не принципиальна (разве что для разработчика компилятора — и то не всегда).
S>Поскольку никто причин потенциально провальной компиляции не озвучил, то даже не буду гадать, что вы подразумеваете.

Я оценивал в следующем порядке: 1) 'C++' (до 20-го) 2) отсутствие include.

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

U>А эта компания еблая и пушистая, с идеальной репутацией.

Это опечатка, или вывод?

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

S>если программист не может обьяснить чем интерфейс отличается от абстрактного класса и что такое экспепшн, то брать такого на работу совершенно точно нельзя.

Я так понял, что ТС на этот вопрос как раз ответил (и об интерфейсах, и об exceptions).

S>Тем более фрилансера, который непонятно что там в одиночестве кодил сам с собой многие годы. Налицо полное неумение работать в команде (что очень характерно для фрилансеров),

...знаю людей, вышедших из фриланса, и теперь отлично работающих в команде.

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

Мегатоксичными могут быть и те, кто всю жизнь проработал в стенах офиса. Эти будут потоксичнее фрилансера.

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

ИМХО здесь ТС очень много ожидал от компании, много рисовал себе. Вот собственно и результат.
Вывод: не нужно слишком большие надежды возлагать — ни на человека, ни на компанию.
Вот тогда и не будет горьких разочарований.