Мне кажется, что задачки, рассчитанные на знание какой-нибудь сверххитрой тонкости стандарта языка, никогда или почти никогда не использующейся на практике, не совсем подходят для отбора стандартных разработчиков from the bottom of the barrel стандартных программ.
А что, они подходят для отбора нестандартных разработчиков? Это какие? Те, которые знают наизусть стандарт языка? Или по ночам вместо решения задач изучают тонкости языка?
Я на "Мне кажется, что задачки, рассчитанные на знание какой-нибудь сверххитрой тонкости стандарта языка, никогда или почти никогда не использующейся на практике, не совсем подходят для отбора стандартных разработчиков from the bottom of the barrel стандартных программ." отвечал.
Они имелось в виду "задачки, рассчитанные на знание какой-нибудь сверххитрой тонкости стандарта языка".
Знание тонкостей стандарта языка и его конкретных реализаций, свойственные "нестандартным" разработчикам, позволяют им быстрее и легче находить тонкие, не видимые большинству разработчиков с превого взгляда, проблемы в коде. Более того, это знание позволяет им избежать написания проблемного кода.
1. Чем отличается число являющееся степенью двойки от других чисел?
Человек должен понимать как выглядит двоичное представление числа и что у такого числа только одна единица. Не знает - долой.
2. Как убедится программно и в то же время быстро, что единица только одна.
Здесь как минимум два варианта. Быстрый и не быстрый. Ну и еще есть "не знаю". Или "я слишком волнуюсь, не могу придумать, но наверняка google поможет"
Интересно, как ты будешь воспринимать кандидата, который ответил на 1-й, но по-разному ответил на второй?
P.S. Это не претензия ни в коей мере :-) Действительно интересно. Никогда не приходилось так набирать людей.
Находить проблемы - согласен. Избегать проблемного кода - не согласен.
Ведь как раз тонкости приводят к написанию "нестандартного" кода. Странного, непонятного, трудного. С которым другие программисты намучаются. А "стандартный путь" (который в man-ах) протоптан миллион раз.
ИМХО тонкостей нужно избегать. Они нужны только в самых специфичных задачах. Таких как ядро ОС, например и\или работа с железом.
Почему? Если человек хорошо осведомлён о возможных неочевидных побочных эффектах того или иного кода, он - если он хороший разработчик - будет избегать его использования. Именно для того, чтобы другим потом не пришлось с ним мучаться.
ИМХО тонкостей нужно избегать
Полностью согласен. И это никак не противоречит сказанному мной.
1 -- попрошу найти ошибку 2 -- годится, но покажу более быстрый вариант и попрошу объяснить, почему он работает 3 -- десять минут на подумать 4 -- то же самое, что и 3
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
from the bottom of the barrelстандартных программ.no subject
no subject
char * strcpy(char *restrict s1, const char *restrict s2);Это из мана.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
90% не в состоянии написать функцию, которая определяет, является ли аргумент степенью двойки.
no subject
Они имелось в виду "задачки, рассчитанные на знание какой-нибудь сверххитрой тонкости стандарта языка".
no subject
no subject
no subject
no subject
1. Чем отличается число являющееся степенью двойки от других чисел?
Человек должен понимать как выглядит двоичное представление числа и что у такого числа только одна единица. Не знает - долой.
2. Как убедится программно и в то же время быстро, что единица только одна.
Здесь как минимум два варианта. Быстрый и не быстрый. Ну и еще есть "не знаю". Или "я слишком волнуюсь, не могу придумать, но наверняка google поможет"
Интересно, как ты будешь воспринимать кандидата, который ответил на 1-й, но по-разному ответил на второй?
P.S. Это не претензия ни в коей мере :-) Действительно интересно. Никогда не приходилось так набирать людей.
no subject
Ведь как раз тонкости приводят к написанию "нестандартного" кода. Странного, непонятного, трудного. С которым другие программисты намучаются. А "стандартный путь" (который в man-ах) протоптан миллион раз.
ИМХО тонкостей нужно избегать. Они нужны только в самых специфичных задачах. Таких как ядро ОС, например и\или работа с железом.
no subject
Почему? Если человек хорошо осведомлён о возможных неочевидных побочных эффектах того или иного кода, он - если он хороший разработчик - будет избегать его использования. Именно для того, чтобы другим потом не пришлось с ним мучаться.
ИМХО тонкостей нужно избегать
Полностью согласен. И это никак не противоречит сказанному мной.
no subject
no subject
no subject
(x && x-1) == 0
2. Медленное решение
Циклы, сдвиги...
3. Не знаю
4. Не могу сейчас вспомнить, но какое-то легкое решение точно было, в гугле найдется.
no subject
К тому же я обычно прошу написать int f(int x), а не int f(unsigned int x).
no subject
2 -- годится, но покажу более быстрый вариант и попрошу объяснить, почему он работает
3 -- десять минут на подумать
4 -- то же самое, что и 3
no subject
no subject
no subject