Укороченная версия
Если работа заключается в поддержке приложения, навыки, которые необходимо проверить во время собеседования:
Способность понимать большую кодовую базу с ее документацией, юнит-тестами и т. Д.
Возможность рефакторинга кода и внесения изменений, не нарушая все.
Попросить людей прочитать код не поможет вам оценить эти способности.
Длинная версия
Вас попросили написать код? Если да, как отметил в своем ответе Знак , этого достаточно. Если мы немного обобщим, человек, который пишет ясный, понятный исходный код, сможет прочитать исходный код, написанный другими людьми.
Если вас не просили написать код, тогда, вероятно, вы были допрошены сотрудником отдела кадров. Такие собеседования не могут быть слишком техническими и в основном бесполезными, поскольку они не оценивают ваши навыки и вашу способность хорошо работать, а скорее количество лет, которые вы провели в колледже, и другие вещи, которые не имеют ничего общего с работой.
Есть еще несколько причин не просить прочитать код для технического обслуживания:
1. Сложно сделать надежно
Конкретно, что бы вы сделали, если бы вы были интервьюером? Пусть ваши кандидаты прочтут какой-нибудь код. Какой код? На каком языке? Насколько хорошо или плохо написано? С комментариями или без? С или без документации?
Что еще более важно, что это говорит о кандидате? Насколько хорошо это соотносится с самой кодовой базой?
Допустим, у вас есть устаревшее приложение для поддержки VB.NET. Вы знаете, что исходный код в основном уродлив и непроверен, а некоторые комментарии устарели или вводят в заблуждение. Последние три месяца у вас был очень опытный разработчик, работавший над решением; он провел рефакторинг и протестировал наиболее важные части приложения, добавил комментарии там, где требовались комментарии, и, самое главное, написал подробную документацию об общей архитектуре, критических частях и подводных камнях.
Теперь вы нанимаете разработчика для поддержки этой кодовой базы. Во время собеседования, не могли бы вы дать часть устаревшего (некрасивого) кода или часть кода, которая была реорганизована предыдущим разработчиком?
Вы бы дали документацию? Для того, чтобы прочитать документацию, кандидату нужно потратить как минимум несколько часов. Это делает это невозможным во время собеседования.
2. Чтение короткого фрагмента кода - это не то же самое, что чтение кода знакомого проекта.
Помните, что работа заключается в поддержании проекта. Трудно поддерживать большую кодовую базу в первые дни или недели, когда вы не знакомы с проектом. Гораздо проще сделать это через несколько месяцев, когда вы написали всю документацию и имеете четкое представление об общей базе кода.
Самое главное, чтобы проверить, будет ли человек эффективен в эти месяцы . Вам все равно, если человек не сможет ничего понять в течение первых двух дней.
Попросив человека прочитать короткий кусок кода с нуля, вы не проверяете, как этот человек сможет справиться со знакомым, документированным кодом, примерно из тысячи LOC .
3. Поддерживать исходный код - это не просто читать
Когда вы поддерживаете кодовую базу, вы модифицируете ее. Разработчик, который просто читает код, не приносит ничего полезного для его компании.
Полезными навыками являются способность реорганизовывать код , добавлять модульные тесты , прогнозировать влияние изменений и т. Д. Вы не проверяете эти навыки, когда просите человека прочитать код во время интервью.