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

Любитель, я думаю хороший тест должен быть составлен так, чтобы никто не мог выбить максимальный балл.
Должны быть простые вопросы, сложные, и почти нерешаемые. 
Ты ведь не станешь жаловаться на то, что в тестах на IQ некоторые вопросы слишком сложные?
Если присутствовать только простые вопросы будут, то по какому принципу отсеивать кандидатов?
Конкретно этот решенный вопрос будет свидетельствовать о способности кандидата разбирать чужой код, 
если справится с этим чудовищем, то со всем остальным и подавно.
Мой итог: вопрос имеет право на жизнь, при правильной оценки работодателем решения кандидата.

То, что за такие функции в практике надо руки отрывать - неоспоримый факт, но, в рамках собеседования, задача, имхо, имеет право на существование.
1. Проверка первой реакции человека на предложенную задачу - первое что хочется сделать, это действительно оторвать руки собеседника и отойти в сторону, но с какой стороны это охарактеризует вас для работодателя?
2. Проверка способностей к разбору чужого кода + знание побитовых операций, префиксного, постфиксного декрементов в целом...
На вопрос сколько было дано времени на решение - думаю около 15 минут, вряд ли больше... В любом, случае, мое мнение таково - хватать ручку, бумагу, задавать входные значения и анализировать, анализировать (Freak_FB, насколько я понимаю, анализировал под дебагерром). Лучше анализировать вслух, тогда, если не хватит времени, будет видно, что все усилия были приложены. В конце концов, я думаю, zkv был прав насчет того, что задание было не обязательным для решения.
Вообще, забавно, что вы заговорили о самом собеседовании.. Вот вам еще задачка, заданная там же:
Есть некий класс A, где-то в программе создан указатель на этот класс и объект типа данного класса. Как реализован класс, что будет ошибка компиляции, в строке обозначенной в коде ниже. Что это за ошибка? Каково тело класса? Подсказка: вопрос связан с областью видимости переменных.
Старайтесь провести анализ без использования компилятора для моделирования реальных условий   !


Это сообщение отредактировал(а) FiMa1 - 30.8.2007, 08:49

у меня не связано 

есть конструктор с параметрами и нет конструктора без параметров.

Это первое что я сказал, но ВОПРОС СВЯЗАН С ОБЛАСТЬЮ ВИДИМОСТИ ПЕРЕМЕННЫХ, ответили мне    (здесь изменено для моделирования ситуации)...

Добавлено @ 09:06

Что имел в виду?

Это сообщение отредактировал(а) FiMa1 - 30.8.2007, 09:07

что такой код выдаст именно такую ошибку, что и требовалось 

Ладно не будем тянуть кота за х..., zkv - пять баллов, ты прав и успешно принят на работу   ! Я не сомневаюсь, что ты знаешь о чем говоришь, но не мог бы раскрыть чуть более подробнее для последователей...

Это сообщение отредактировал(а) FiMa1 - 30.8.2007, 09:18

дык у меня решение не связано с областью видимости.

все просто, по умолчанию все члены класса закрытые, можно было явно написать private: или protected: перед конструктором, только не так интересно будет 
ну а дальше ясно - указатель он и в африке указатель, он и на абстрактный тип может быть, для него конструктор не нужен
а вот для объекта вызывается конструктор умолчания, а он закрыт, вот компилятор и сообщает: "ты определись давай!"

   тогда ставим слушателям на собеседовании не зачет, потому что однозначно убеждали, что cannot access private member declared in class 'A', в данном случае связана с областью видимости, т.к., в их случае деструктор, закрыт... Меж тем, может быть правда на их стороне и данная ситуация подпадает под понятие области видимости...

Это сообщение отредактировал(а) FiMa1 - 30.8.2007, 09:29

FiMa1, я под областью видимости привык понимать следующее:

а то о чем шла речь выше - это модификаторы доступа.
Может где-нибудь принято называть по другому.

Это каким надо быть извращенцем, чтобы accessibility перевести на русский как область видимости. В топку таких работодателей. Лучше не иметь с ними никаких дел.

О переводе речь не ведется, cannot access private member declared in class 'A' - копипаст трактования ошибки студией..
Насколько я понял, само то, что закрытые классом конструктор/деструктор невидимы (а по моему, лучше недоступны) на данном участке программы (Керниган: область видимости - участок программы, где это имя известно), подгоняли под понятие области видимости.
Пробежался по стандарту - в разделе Declarative regions and scopes ничего про данный взгляд на область видимости не нашел...

Видимость и доступность – совсем разные вещи. Давай посмотрим на такой пример:


При разрешении перегрузки метод void f(int) видим, но для вызова он не доступен. Поэтому в первом случае, когда разрешение перегрузки оказывается в пользу вызова открытой функции, проблем не возникает, когда же оно оказывается в пользу вызова закрытой функции, возникает ошибка.



Вот scope – это и есть область видимости.


Это сообщение отредактировал(а) UnrealMan - 30.8.2007, 10:48

По-моему из моей фразы:
 видно, что я осознаю эту разницу и, разумеется, согласен с тем, что ты говоришь..

Спасибо  , но это мне тоже было известно...