История изменений

BTW, я вот один из тех, кто собеседует людей с написанием кода на доске в том числе.

Я не фанат такой методики и не считаю ее 100% верной, но:
1. Считаю, что на собеседовании нужно обязательно писать код (если речь не про архитектора 99 уровня, хотя и ему иногда полезно опускаться до реализации того, что он напроектировал).
2. Практика показывает, что у кандидатов, которые знают изначально, либо выстраивают сами правильный алгоритм решения задачи, обычно не возникает серьезных проблем с его реализацией вне зависимости от носителя, на котором он будет записан.
3. Поиск (или недопущение) багов при написании кода без возможности его запуска и проверки – хорошая проверка аккуратности и умения понимать, что делает тот или иной код из него самого, а не из результатов его работы. Потому что:
3.1. Если ты понимаешь, в каком месте твое решение фейлит – ты, скорей всего, исправишь его правильным образом, а не закостылишь лишь бы тесты проходили.
3.2. Когда у тебя в тестовом окружении все работает, а в продакшне ВНЕЗАПНО умирает раз в месяц при особой фазе луны – у тебя может не быть вариантов, кроме как вдумчиво анализировать код и пытаться найти, как же именно фаза луны может на него повлиять. Если код многопоточный/асинхронный – еще и читать по ролям с коллегой, возможно.

Естественно, при собеседованиях на доске мы не требуем детального знания стандартной библиотеки (если человек говорит «есть такая-то функция, которая делает вот это, но я не помню точно, из какого модуля ее взять и какая у нее сигнатура» – ты просто называешь ему искомую функцию) и прощаем опечатки и синтаксические ошибки.

BTW, я вот один из тех, кто собеседует людей с написанием кода на доске в том числе.

Я не фанат такой методики и не считаю ее верной, но:
1. Считаю, что на собеседовании нужно обязательно писать код (если речь не про архитектора 99 уровня, хотя и ему иногда полезно опускаться до реализации того, что он напроектировал).
2. Практика показывает, что у кандидатов, которые знают изначально, либо выстраивают сами правильный алгоритм решения задачи, обычно не возникает серьезных проблем с его реализацией вне зависимости от носителя, на котором он будет записан.
3. Поиск (или недопущение) багов при написании кода без возможности его запуска и проверки – хорошая проверка аккуратности и умения понимать, что делает тот или иной код из него самого, а не из результатов его работы. Потому что:
3.1. Если ты понимаешь, в каком месте твое решение фейлит – ты, скорей всего, исправишь его правильным образом, а не закостылишь лишь бы тесты проходили.
3.2. Когда у тебя в тестовом окружении все работает, а в продакшне ВНЕЗАПНО умирает раз в месяц при особой фазе луны – у тебя может не быть вариантов, кроме как вдумчиво анализировать код и пытаться найти, как же именно фаза луны может на него повлиять. Если код многопоточный/асинхронный – еще и читать по ролям с коллегой, возможно.

Естественно, при собеседованиях на доске мы не требуем детального знания стандартной библиотеки (если человек говорит «есть такая-то функция, которая делает вот это, но я не помню точно, из какого модуля ее взять и какая у нее сигнатура» – ты просто называешь ему искомую функцию) и прощаем опечатки и синтаксические ошибки.