Вопросы для собеседования по языку Си

[vak]

A ‘C’ Test: The 0x10 Best Questions for Would-be Embedded Programmers
(PDF)

Comments

[ircicq]

Хитрая задача на C есть:
Напечатать числа 1..100 без использования условий (в том числа тернарного оператора) и циклов.

[sobriquet9]

А в чём хитрость? Вот решение для чисел от 1 до 3, точно так же можно и до ста напечатать.

printf("1\n2\n3\n");

[juan_gandhi]

#include <stdio.h>

void p(int i) {
  printf("%d ", i);
  int stopit = 1 / (100-i);
  p(i+1);
}

int main(int argc, char *argv[]) {
  p(1);
}

[vak]

Красиво однако! :)

[spamsink]

Только не печатает ничего по понятной причине.

[spamsink]

А без аварийного завершения в том же духе можешь?

[juan_gandhi]

Да я язык-то ваш, си, плохо знаю.

#include <stdio.h>

boolean p(int i) {
  printf("%d ", i);
  i < 100 && p(i+1);
}

int main(int argc, char *argv[]) {
  p(1);
}

[ircicq]

Лучшее решение!

если в кратчайшем виде:

#include

[Error: Irreparable invalid markup ('<stdio.h>') in entry. Owner must fix manually. Raw contents below.]

Лучшее решение!

если в кратчайшем виде:

#include <stdio.h>

int main(int argc) {
printf("%d ", argc);
return argc < 100 && main(argc+1);
}

[juan_gandhi]

А, точно, это ж не скала, return надо.

[spamsink]

Это всё равно читинг. См. моё решение ниже.

[spamsink]

Операторы сравнения и логические с шорткатом - это читинг. Вот как надо:

#include <stdio.h>
#include <stdlib.h>
void p(int i) {
  printf("%d ", i);
  (*(void(*)(int))(i/100*(unsigned long)exit + (1-i/100)*(unsigned long)p))(i+1);
}

int main(int argc, char *argv[]) {
  p(1);
}

[juan_gandhi]

Красивый фокус!!!

[ircicq]

Круто!
Единственная поправка: вместо unsigned long надо uintptr_t
иначе на VC x64 не работает

[vak]

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

[vak]

Простое решение без ухищрений:

#include <stdio.h>

void print_and_increment(int *p)
{
    printf("%d\n", *p);
    *p += 1;
}

void print_and_incr_ten_times(int *p)
{
    print_and_increment(p);
    print_and_increment(p);
    print_and_increment(p);
    print_and_increment(p);
    print_and_increment(p);
    print_and_increment(p);
    print_and_increment(p);
    print_and_increment(p);
    print_and_increment(p);
    print_and_increment(p);
}

int main()
{
    int x = 1;
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    print_and_incr_ten_times(&x);
    return 0;
}

[spamsink]

1. Я уж и думать забыл про 16-битные машины.
9. Правильный ответ должен начинаться с вопроса "как в вашей компании традиционно нумеруются биты, с младшего или со старшего, и с нуля или с единицы?" :)
10. Товарищ не понимает, что r-values всегда константного типа, но делает вид, что он умнее, чем он есть.


Интересно, в каком году эти вопросы были написаны.

[x86128]

Наверное во времена расцвета AVR.

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

[spamsink]

подглядывать что там компилятор на компилил

Это всю жизнь было моим любимым занятием. :)

[ex0_planet]

1. 32 бита точно также легко переполнить, достаточно посчитать количество миллисекунд.
2. #define MIN — никто уже так не делает, gcc поддерживает анонимные statement-блоки в выражениях с незапамятных времён
8. Я удивлен что про volatile почти правильно, хотя я бы предпочёл чтобы ответ был сформулирован в терминах сайд-эффектов.
8c. А вот тут строго нет, для этого есть atomic. Volatile тут прокатывает только в очень простых контроллерах.

В общем да, навскидку где-то год 2006 или даже раньше.

[spamsink]

2, 8с. Вот именно, потому и вопрос о датировке. :)

[caztd]

Вот есть люди, которые хорошо готовятся, проходят подобные тесты на отлично,
мнят себя экспертами, а потом пишут код на 10 klocs в одном файле с тучей
глобальных переменных и еще и с рекурсией (если они особенно крутые).
А потом на этот код приходит пара change requests и стопицот bug reports.
А разработчик/консультант, который все это нахерачил уже давно ушел в другой проект.
И что прикажете с этим делать, кроме как переписывать все нахрен?

У тоёты с тормозами такой же примерно специалист код писал,
наверняка все эти тесты на ура прошел :(

[vak]

Что делать: учить. Собеседование вовсе не гарантирует качества кода.

[caztd]

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

[vak]

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

[caztd]

> Программист должен писать код не менее свободно, чем говорить.

Это очень специфический тип программиста, так называемый кодер.
Дали задание -- он закодировал (предположим правильно).
Дали задание с ошибкой -- он закодировал как задали и ошибку не нашел.
Ошибку найдут потом через 2 года и она будет стоить много.
Нет, спасибо, не люблю работать с кодерами.

Я, например (ха-ха, себя милого конечно в пример),
давно уже не могу писать код свободно
(примерно после окончания уни разучился) --
да и редко я много кода пишу.
Мне гораздо важнее умение организовать процесс разработки и
выбор правильного дизайна в котором ошибки будут находить быстро.
В 100 раз пример важнее, чем умение свободно писать код.

Одна строчка критичного кода стоит >100 евро.
Мне абсолютно пофигу будет ли разработчик писать ее 1 минуту или
10 минут вспоминая синтакс и через SO, если она будет работать без ошибок
и ее не придется потом переписывать еще 10 раз.

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

[vak]

Умеющих организовать процесс у нас имеется. Я имею в виду компанию, где работаю. Нам нужны люди, которые любят и умеют писать код. Не любите работать с кодерами - не приходите к нам. Мы любим работать с кодерами.