Вопросы на интервью, на которые нельзя не знать ответы

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

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

К сожалению, отказывать приходится порой из-за радикально тривиальных вещей, незнание которых просто несовместимо с профессией.

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

Интервьюирование было на позицию "Senior C/C++ developer”.

Ответы приведу тут же, так как они очевидны.

1. Сколько примерно будет 2^32? (обычно задается по телефону)

Ответ "Около четырех миллиардов" является исчерпывающим.

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

2. Как сравнить две переменные типа double или float на равенство? (обычно задается по телефону)

Ответ "Вычесть одно из другого и сравнить результат на больше/меньше с каким-то малым числом, например 10E-6" является исчерпывающим. Конечно, много зависит от используемой библиотеки работы с числами с плавающей точкой, но смысл, в целом, одинаков.

Увы, количество неотвечающих тоже весьма значительно.

3. (Хит!) Что распечатает данная программа? (не забываем, что собеседование на позицию разработчика на C/C++). В принципе, его тоже можно задать по телефону.

char* f() {
  char buf[100];
  strcpy(buf, "TEST”);
  return buf;
}

int main() {
  char* s = f();
  /* (1) */
  printf("%s\n", s);
}

Ответ: "Нельзя сказать с уверенностью, скорее всего мусор, но в целом это неопределенное поведение, так как локальный буфер формально прекращает существование после выхода из функции f()" является почти исчерпывающим.

Почему "почти"? Потому что обычно за ним дополнительный вопрос: "Что именно может с высокой вероятностью затирать заветное слово TEST и приводить к выводу мусора? Для конкретности: платформа x86, 32-bit, компилятор Visual Studio. Если остановить программу отладчиком в точке (1) и посмотреть, на что указывает указатель "s", то очень высока вероятность, что там будет таки "TEST", а вот printf() таки с высокой вероятностью распечатает мусор. Почему?".

Более половины собеседований, в которых я участвовал, заканчивались со знаком "минус", так как человек даже не делал попытку сказать что-то типа "В данных условиях скорее всегда слово TEST будет перезатерто параметрами функции printf(), которые передаются через стек и ложатся на то место, где был раньше размещен буфер "buf". Конечно, многое зависит от режимов оптимизации, так как аргументы могут быть переданы через регистры."

Фактически, произнесенные слова "стек" и "параметры функции" являются достаточным ответом на вопрос.

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

Но все же есть такая черта, ниже которой уже нельзя.

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