Удивительное рядом

[avysk]

Читал стандарт C99, много офигедумал.

void f(int a[static restrict 10], const int b[static restrict 10]) { ... }

Comments

[k-79.livejournal.com]

Мне кажется, что задачки, рассчитанные на знание какой-нибудь сверххитрой тонкости стандарта языка, никогда или почти никогда не использующейся на практике, не совсем подходят для отбора стандартных разработчиков from the bottom of the barrel стандартных программ.

[avysk]

А это не задачка.

[avysk]

Ну вот тебе использующееся:

     char *
     strcpy(char *restrict s1, const char *restrict s2);

Это из мана.

[avysk]

Не из линуксового мана, впрочем. Из макосовского (те из дарвина).

[avysk]

Задачка из предыдущего поста вполне жизненная, кстати. Нет?

[tobotras]

Жизненная, жизненная :)

[avysk]

Кстати, если я правильно понимаю, то, что на юзерпике, очень неэффективное. Нет? :)

[alexott.livejournal.com]

угу, неэффективное...

[tobotras]

Абсолютно :-)

[mkevac.livejournal.com]

Нет. В man-е написано что getchar возвращает int.

[avysk]

Вы не представляете, какое количество поступающих на работу смутно представляют себе, что такое man. Или чем int отличается от char.

90% не в состоянии написать функцию, которая определяет, является ли аргумент степенью двойки.

[mkevac.livejournal.com]

Тут есть несколько уровней.

1. Чем отличается число являющееся степенью двойки от других чисел?

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

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

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

Интересно, как ты будешь воспринимать кандидата, который ответил на 1-й, но по-разному ответил на второй?

P.S. Это не претензия ни в коей мере :-) Действительно интересно. Никогда не приходилось так набирать людей.

[avysk]

Всё зависит от того, какой был ответ на второй вопрос.

[mkevac.livejournal.com]

1. Быстрое решение

(x && x-1) == 0

2. Медленное решение

Циклы, сдвиги...

3. Не знаю

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

[avysk]

Ответ 1 с ошибкой :)

К тому же я обычно прошу написать int f(int x), а не int f(unsigned int x).

[avysk]

1 -- попрошу найти ошибку
2 -- годится, но покажу более быстрый вариант и попрошу объяснить, почему он работает
3 -- десять минут на подумать
4 -- то же самое, что и 3

[mkevac.livejournal.com]

А если через 10 минут не придумает, то это пропащий случай?

[avysk]

Не обязательно, посмотрим на другие задачи, но на позицию senior developer уже вряд ли.

[andy-shev.livejournal.com]

Мы с heviosso обсудили задачку в раздевалке...

[mkevac.livejournal.com]

А что, они подходят для отбора нестандартных разработчиков? Это какие? Те, которые знают наизусть стандарт языка? Или по ночам вместо решения задач изучают тонкости языка?

[avysk]

Кто "они"? Причём в данном случае отбор разработчиков? Приведённый кусок C-кода вызывает у меня, в лучшем случае, недоумение.

[mkevac.livejournal.com]

Я на "Мне кажется, что задачки, рассчитанные на знание какой-нибудь сверххитрой тонкости стандарта языка, никогда или почти никогда не использующейся на практике, не совсем подходят для отбора стандартных разработчиков from the bottom of the barrel стандартных программ." отвечал.

Они имелось в виду "задачки, рассчитанные на знание какой-нибудь сверххитрой тонкости стандарта языка".

[avysk]

Ответил ниже :)

[avysk]

А, нашёл, кто "они" :) В этом посте никакой задачи не было, а было сплошное недоумение по поводу стандарта.

[k-79.livejournal.com]

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

[mkevac.livejournal.com]

Находить проблемы - согласен. Избегать проблемного кода - не согласен.

Ведь как раз тонкости приводят к написанию "нестандартного" кода. Странного, непонятного, трудного. С которым другие программисты намучаются. А "стандартный путь" (который в man-ах) протоптан миллион раз.

ИМХО тонкостей нужно избегать. Они нужны только в самых специфичных задачах. Таких как ядро ОС, например и\или работа с железом.

[k-79.livejournal.com]

Избегать проблемного кода - не согласен

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

ИМХО тонкостей нужно избегать

Полностью согласен. И это никак не противоречит сказанному мной.