Есть ли польза от компиляции кода по ходу дела?

Недавно у меня было собеседование, на котором мне дали час, чтобы написать настоящий код. Это не было огромное количество, вероятно, менее 100 строк. Примерно через 45 минут я скомпилировал, запустил его и заставил работать. Возможно, я потратил 5-10 минут на разработку ошибок компиляции и пару незначительных ошибок, но в целом все было очень гладко. (Кстати, я получил предложение от них.)

Однако, то, что озадачило меня, было то, что после того, как я передал законченный код, интервьюер сказал мне, что единственное, что я сделал неправильно, это «не компилирую, как я иду». Я спросил его, в чем разница, и он сказал: «Что бы вы сделали, если бы вы закончили код, а он не скомпилировался вовремя».

В моем понимании это неверный аргумент, потому что «получение кода для компиляции» для заданной длины кода обычно включает в себя исправление постоянного числа ошибок компиляции и занимает довольно постоянное количество времени, которое должно быть одинаковым, если вы делаете это после того, как закончите писать код, или если вы чередуете его со временем кодирования. Во всяком случае, прерывание вашего кодирования для поиска пропущенных точек с запятой, вероятно, нанесет ущерб вашей эффективности. За исключением экстремальных обстоятельств, когда я экспериментирую с неясностями вокруг граничных случаев с такими вещами, как виртуальные функции в производных классах и т. Д., Кажется разумным ожидать, что код, написанный опытным разработчиком, будет компилироваться, за исключением случайной ошибки ввода и даже если это не так

В другом подобном инциденте мне дали неполное кодовое основание в интервью, и попросили закончить это и внести необходимые изменения, чтобы заставить это работать. Я начал с чтения существующего кода, а затем, через несколько минут (даже до того, как я закончил просматривать код), интервьюер сказал мне, что этого достаточно. Когда я спросил его, что бы он сделал (то есть «что я сделал не так»), он сказал мне, что начал бы с немедленного получения кода для компиляции.

Почему это вообще актуально? По моему мнению и по моему опыту, является ли часть кода компиляцией по существу случайной, включая такие вещи, как отсутствие или отсутствие точек с запятой, и имеет мало общего с правильностью базовой программы. (Для меня сосредоточение на компиляции похоже на проверку статьи без проверки правописания для проверки грамматики.)

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

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

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

Есть ли польза от компиляции по ходу дела?

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

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

Если взять пример, скажем, вы программировали на C-подобном языке и забыли }где-то в середине программы.

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

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

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

Компиляция - это форма теста, особенно в языках, в которых широко используются такие типы, как Haskell или ML . На других языках это синтаксическое сканирование, которое мало что говорит.

Сказав это, «компилируй по ходу дела» кажется мне очень ситуативной привычкой. Точно так же вы можете быть отмечены за то, что «раздражительны» для составления чаще, чем личные предубеждения интервьюера. Это звучит как придирки; никто не любит признавать , что интервьюируемый успешно справился тест; это склоняет чашу весов переговоров о зарплате.

Не все системы сборки работают быстро. Я работал над проектом (C ++) , где Make будет тратить 30 секунд только стат «тин все , чтобы определить , нужно ли строить или нет, а большинство файлов будут занять несколько минут , чтобы построить , если вы сделали изменения. Мы не хотели делать это чаще, чем каждые 10-15 минут. Кто-то, без сомнения, предоставит анекдот о том, что во время компиляции вы берете колоду перфокарт и переносите их в другое здание ...

Скомпилируйте, когда вы почувствуете, что выполнили полный концептуальный блок в своей голове и готовы его проверить. Раз в минуту или раз в неделю в зависимости от рабочего процесса.

Итак, мой вопрос заключается в следующем: я что-то пропустил?

Да, ваш разум не является компилятором. Хотя компилятор может сделать n переключений контекста в секунду, ваш ум не может. Количество переключений контекста, которые ваш ум может сделать за день, зависит от ряда факторов, таких как опыт / знакомство с базой кода, насколько вы погружены в код, насколько чистым является код, насколько сложна проблема, которую вы решаете, насколько вы устали, если вас часто прерывают или в шумной обстановке и так далее.

Компиляция базы кода (все одновременно) в первый раз (например, «проект с 20 файлами») заставит вас переключать контекст с того, о чем вы думаете (например, «здесь это значение установлено на 5, затем в for for blablabla, и комплексный алгоритм возвращает правильное значение при возврате ") к проблеме компиляции, которая совершенно не связана с тем, о чем вы думаете (разные имена файлов / модулей / функций / предварительных условий / синтаксиса / переменных, предварительных условий и т. д. ).

Чем больше кода вы компилируете за раз, тем больше переключает ваш контекст. Это не проблема для небольшой базы кода, когда весь код, который вы написали, - это то, что вы написали за один час. Тем не менее, это большая проблема при работе в существующей кодовой базе с множеством (и много раз недокументированных) взаимозависимостей.

Есть ли польза от компиляции по ходу дела?

Вы минимизируете контекстные изменения, которые должен сделать ваш ум, позволяя вам больше сосредоточиться на воздействии и побочных эффектах изменений, которые вы делаете. Это также делает вас менее уставшим (и менее склонным к ошибкам) ​​и повышает качество выходных данных (т. Е. Вы можете минимизировать побочные эффекты легче, когда вы изменяете и компилируете один файл за раз, чем когда вы компилируете и изменяете десять).

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

Или это какой-то миф, распространяемый сообществом разработчиков программного обеспечения, о том, что вы должны часто компилировать свой код?

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

В моем понимании это недопустимый аргумент, потому что «получение кода для компиляции» для заданной длины кода обычно включает в себя исправление постоянного числа ошибок компиляции и занимает довольно постоянное количество времени

Для меня это звучит так, будто у вас мало (или нет) опыта в обслуживании средних и больших унаследованных кодовых баз (сотни или тысячи исходных файлов). Именно здесь это отношение (т.е. «компилируйся по ходу дела») поможет больше всего, и именно здесь вы формируете такую ​​привычку.

Я полагаю, что люди, которые вас интересовали, пришли к аналогичному выводу («у вас мало или совсем нет опыта работы с большими кодами»).

Я думаю, здесь есть больше, чем небольшой профессиональный снобизм. Смысл, по-видимому, в том, что «если у вас никогда не было необходимости регулярно компилировать, то вы никогда не работали с чем-то таким сложным - получите больше опыта и вернитесь, когда научитесь работать именно так, как мы».

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

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

Если вы не поклонник постоянной перекомпиляции, значит, вы в хорошей компании. Вот Дональд Кнут:

Что касается вашего реального вопроса, идея немедленной компиляции и «модульных тестов» привлекает меня очень редко, когда я чувствую себя в совершенно неизвестной среде и нуждаюсь в обратной связи о том, что работает, а что нет. В противном случае тратится много времени на действия, которые мне просто не нужно выполнять или даже думать о них.

Все это, как говорится ... если вы работаете в контексте, где компиляция - это бесплатное действие, то почему бы и нет? Дома, в личных проектах, я нажимаю ctrl-S примерно каждые 30 секунд, а ярлык «компиляция» почти так же часто, в IDE, которая постоянно запускает код через интерфейс компилятора, чтобы обеспечить подсвечивание ошибок в реальном времени. Зачем отказываться от бесплатного обеда?

Есть преимущества для компиляции, как вы идете. Но я очень согласен с тем, что выполнение задачи - это нормальная стратегия кодирования.

Самым значительным преимуществом инкрементной компиляции является менталитет, который многие приобретают, если они ждут окончания, чтобы скомпилировать и протестировать : в конце мы больше заинтересованы в том, чтобы заставить код работать, чем что-либо еще в этой точке. Мы говорим: «О, просто нужно добавить эту скобку, чтобы компилятор перестал жаловаться» или «о, просто нужно использовать это заглавные буквы», не думая, есть ли скрытая семантическая ошибка, которую скрывает эта синтаксическая ошибка. Я действительно считаю, что синтаксические ошибки часто вкладываются в семантические ошибки (обратное неверно).

В качестве примера, скажем, я изменил значение переменной и в результате изменил ее имя. Изменение имени генерирует синтаксическую ошибку позже в коде, но если я просто угожу компилятору, исправляя имя, я проигнорировал, почему эта ошибка появилась.

Я понимаю преимущества тестирования вашего кода по мере продвижения, но зачем компилировать?

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

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

Так что не каждый делает TDD, по крайней мере, не всегда (я тоже, я признаю). С вашей текущей стратегией у вас никогда не будет возможности даже попробовать TDD. Но даже если вы не используете TDD, IMHO крайне полезно проверять ваш код более регулярно - что невозможно, если вы не компилируете его регулярно. А когда ваш тест не пройден, вы запускаете его для отладки (что может помочь вам понять, почему красивый алгоритм, который вы написали за несколько минут до того, не ведет себя так хорошо, как вы думали, что должен). И чем больше кода вы пишете без компиляции, тем больше кода вы пишете без тестирования, и тем больше вероятность того, что вы столкнетесь с ситуацией, когда вы не можете предсказать, что время для устранения проблемы равно «O (1)», так как вы написали.

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

К сожалению, поиск ошибок компилятора - это не единственное, что делают компиляторы. Риск констатировать очевидное: для запуска вашей программы требуется компиляция, а для ее запуска требуется найти все более сложные, тонкие и интересные ошибки времени выполнения, которые создают даже опытные разработчики. И эти типы ошибок являются более сложными и , следовательно , более дорогой , чтобы исправить дольше вы откладываете их отладкой, потому что они могут построить или маскировать друг друга.

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

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

Одна важная вещь при компиляции, которая, насколько я вижу, отсутствует в других ответах: если вы компилируете редко и получаете большое количество ошибок компиляции, большинство из них бессмысленны, потому что они генерируются первой ошибкой. Это может быть связано с тем, что у вас был неправильный тип, опечатка или простая синтаксическая ошибка, из-за которой некоторые объявления были недействительными

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

Другое дело для обычных сборок: ничто не мешает вам начать компиляцию, как только у вас есть полный блок написанного кода, который должен скомпилироваться. Затем вы можете продолжить писать больше кода, пока идет компиляция, до тех пор, пока вы не сохраните новые изменения до завершения компиляции. Так что практически не тратится время на ожидание сборки. Если вы подождете, пока не напишете все, что собираетесь написать в то время, вам придется ждать компиляции без каких-либо действий. Это в основном ручная версия того, что современные IDE могут делать автоматически в фоновом режиме.

Для достаточно опытного программиста компиляция кода никогда не является узким местом.

Когда вы достаточно хорошо знаете язык (то есть, когда вам больше не нужно думать о синтаксисе, а просто кодировать функциональность), вы не склонны делать простые синтаксические ошибки. Те, что вы делаете, обычно являются опечатками или ошибками копирования-вставки, и они могут быть устранены в короткие сроки всего за несколько проходов компиляции.

Я регулярно пишу код весь день без компиляции, затем скомпилирую и просто исправлю, какие синтаксические ошибки и предупреждения компилятор сообщает перед тем, как зафиксировать свой код (с пометкой «нужно проверить!» ). У меня нет проблем с очисткой более 1000 строк кода на C или C ++ всего за несколько минут.

С другой стороны, отладка и тестирование - это то, что нужно. Логические ошибки возникают по разным причинам, и мне еще предстоит встретиться с компилятором, который расскажет мне о подпрограмме, которую я совершенно забыл написать, или заметит, что мое двоичное дерево не работает, потому что я вставил, node->leftкогда это должно было быть node->right.

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

PS - Если бы я смотрел ваш обзор кода, прочитав его, я бы нанял вас на месте. Это то, что профессионал делает каждый раз.

Нет, откладывать компиляцию вполне разумно, пока вы не выполнили достаточное количество кода (а «достаточное количество» зависит от кодера и кода, который пишется).

Например, если вы замечательный программист, который тратит время на то, чтобы все сделать правильно, и вы не пишете большие объемы или сложный код, то регулярная компиляция - это пустая трата и, вероятно, отвлечение. Если нет, то компиляция каждой функции может быть полезной. Это зависит от человека.

В качестве контр-примера представьте, что вы пишете код JavaScript - здесь нет компилятора. Вместо этого (учитывая природу большей части кода JavaScript) вы должны запустить программу (или обновить страницу), чтобы увидеть результаты своего кодирования. Теперь вы не можете сделать это, пока не напишите достаточно кода, чтобы иметь смысл. В результате, разработчики JavaScript склонны «компилировать» так часто, как могут, что не всегда очень часто.

Короче говоря, здесь нет правильного ответа - интервьюер не ошибается, но и вы тоже. Делай то, что делает тебя продуктивным, и забудь, что кто-то говорит тебе, что ты должен делать. Есть много более важных факторов, связанных с кодированием, чем ваша склонность к F7регулярным попаданиям (или нет) не имеет абсолютно никакого значения.

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

При этом я постараюсь скомпилировать и запустить в значительной степени самый маленький блок кода, который может на самом деле дать результат. Полчаса назад я создавал средство для печати некоторых результатов поиска и сделал полдюжины тестовых отпечатков (в формате .pdf, а не на бумаге), внося изменения в результат, чтобы он выглядел лучше - примерно 1 компиляция на линий.

По моему мнению и по моему опыту, является ли часть кода компиляцией по существу случайной, включая такие вещи, как отсутствие или отсутствие точек с запятой, и имеет мало общего с правильностью базовой программы. (Для меня сосредоточение на компиляции похоже на проверку статьи без проверки правописания для проверки грамматики.)

Мой опыт совершенно другой: менее 5% ошибок компиляции, которые я получаю, связаны с синтаксисом . Я хорошо знаю язык, когда я получаю ошибки, это в основном ошибки типа, говорящие мне, что семантика неверна.

Вот почему я рад как можно быстрее извлечь пользу из отзывов моего компилятора. Вы когда-нибудь сталкивались с использованием IDE, которая подчеркивает ошибки компиляции в режиме реального времени? Более короткий цикл обратной связи может быть очень ценным.

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

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

В этих случаях вы должны предположить, что код, который вы еще не прочитали, верны, и лениво исследовать проблему.

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

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

РЕДАКТИРОВАТЬ: Я также могу сделать аналогию с контролем источников, когда целая команда работает над одними и теми же источниками. Компиляция по мере продвижения - это как частые коммиты, это помогает избежать большой боли в конце, когда вам нужно объединить и разобраться во всем.

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

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

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

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

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

Затем нужно немного времени для написания кода, который компилируется.

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

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

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

Компании в наши дни не просто заинтересованы в готовом продукте. Они хотят знать, что все это время было «под контролем». Для них «попасть туда - это половина удовольствия».

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

В своих интервью я делаю прямо противоположное: кандидаты не могут использовать компилятор. Они пишут короткие программы на белой доске, а потом мы их обсуждаем. Я обнаружил, что слишком много разработчиков используют компилятор (или интерпретатор) в качестве опоры, и это гораздо большая трата времени, чем компиляция слишком редко. Если я предлагаю вам много денег, и вы не можете даже написать FizzBuzz правильно без компилятора, то вы никогда не собираетесь сокращать его в долгосрочной перспективе, работая над задачами, которые в 100 раз сложнее, чем игрушечные упражнения. в интервью. И все же эти простые упражнения отсеивают больше кандидатов, чем любая другая часть интервью.

Целью собеседования является оценка взаимного соответствия кандидата и бизнеса. Хороший вопрос для интервью должен указывать цели вопроса и то, как будет оцениваться интервьюируемый. Возникновение вопроса с подвохом для интервьюируемого, а затем наказание его за то, что он не знает скрытого ответа, не помогает интервьюеру или интервьюируемому. К сожалению, большинство программистов - даже старших - не обучены брать интервью у других программистов, поэтому они просто полагаются на клише и задают те же типы вопросов, которые им задавали, когда они брали интервью, хотя и мало о том, являются ли они эффективными методами оценки кандидатов. или нет.

Я не утверждаю, что мой подход - это «один верный путь», но он мне очень помог. Подобно многим программным методологиям, которые начинаются с заглавной буквы, существует равное количество «мандатов» для проведения интервью. Они все нары. Вы должны делать то, что работает для вас и вашего бизнеса.

В более крупных проектах с несколькими подпрограммами вы хотите протестировать эти части, прежде чем использовать их в более крупной схеме, поскольку отладку намного проще, если вы знаете, что определенные части уже работают.

Для того, чтобы протестировать эти маленькие кусочки, вам нужно скомпилировать.

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

Что касается второго интервью, то преимуществом компиляции является то, что вы можете в течение нескольких секунд наблюдать, что программы делают (или не делают). Оттуда легче читать код и сосредоточить свои усилия на соответствующих частях. Возможно, это то, что ожидал интервьюер.

Чтение неизвестной кодовой базы от начала до конца может быть довольно непродуктивным (вы не компилятор), в то время как компиляция / запуск приложения быстро даст вам большую картину.