Чи є користь у складанні коду, коли ви йдете разом?

Нещодавно у мене було співбесіду на роботі, в якій вони дали мені годину, щоб написати якийсь реальний код. Це була не величезна кількість, мабуть, менше 100 рядків. Приблизно через 45 хвилин я склав, запустив його і почав працювати. Можливо, я витратив 5-10 хвилин на розробку помилок компіляції та пару незначних помилок, але в цілому це було дуже гладко. (До речі, я отримав від них пропозицію.)

Однак мене здивувало те, що після того, як я передав заповнений код, інтерв'юер сказав мені, що єдине, що я зробив неправильно, - це "не складання, коли я йду далі". Я запитав його, в чому різниця, і він сказав "що б ти зробив, якби закінчив код, і він не склався вчасно".

На моє розуміння, це недійсний аргумент, оскільки "отримання коду для компіляції" за задану довжину коду, як правило, передбачає виправлення постійної кількості помилок компіляції і займає досить постійну кількість часу, що має бути однаковим, чи будете ви це робити після вас закінчіть написання коду, або якщо ви переплутаєте його зі своїм часом кодування. Якщо що-небудь, переривання кодування на пошук пропущених крапок може бути згубним для вашої ефективності. За винятком екстремальних обставин, коли я експериментую із неясними цінностями навколо реальних випадків на таких речах, як віртуальні функції у похідних класах тощо., Здається, розумно очікувати, що код, написаний досвідченим розробником, скомпілюватиме за вирахуванням випадкової помилки введення тексту і навіть якщо цього немає, це "

В іншому подібному випадку мені в інтерв'ю дали неповну базу коду, і я попросив закінчити її та внести необхідні модифікації, щоб запустити її. Я почав з читання існуючого коду, а потім через кілька хвилин (ще до того, як я закінчив роздивлятися код), інтерв'юер сказав мені, що цього достатньо. Коли я запитав у нього, що б він зробив (тобто "що я зробив не так"), він сказав мені, що він би почав з негайного отримання коду для складання.

Чому це навіть актуально? На мою думку та з мого досвіду, незалежно від того, чи компіляція фрагмента коду є по суті випадковою, включаючи такі речі, як відсутні крапки з комою чи ні, і мало стосується правильності основної програми. (Для мене, зосередження уваги на складанні - це як запуск статті через перевірку правопису без коректури, щоб перевірити граматику.)

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

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

Тож моє запитання таке: чи щось я пропустив? Чи є насправді користь для складання, коли ви йдете далі? Або це якийсь міф, котрий поширюється програмним співтовариством, що ви повинні часто збирати свій код?

Чи є насправді користь для складання, коли ви йдете далі?

Існує. Це дає коротший цикл зворотного зв'язку - що в цілому при проектуванні (інтерфейс, написання програмного забезпечення, візуальний дизайн тощо) - це гарна річ.

Короткий цикл зворотного зв'язку означає, що ви можете швидко виправити помилки на початку, перш ніж вони дорожчають виправити.

Щоб запозичити свій приклад, скажіть, що ви кодували мовою, схожою на C, і забули }десь посеред програми.

Якщо ви збираєтеся відразу після того, як ви закінчите писати заяву, ви можете бути впевнені, що ви тільки що ввели помилку компіляції і можете виправити її там і потім протягом декількох секунд.

Якщо ви цього не зробите, вам доведеться витратити багато часу на читання коду, шукаючи точну позицію }та переконуючись, виявивши помилку, що виправлення справді те, що було призначено. Це відбудеться деякий час після того, як ви залишили цей біт коду. Це було б не так ясно, як у той момент, коли ви це написали.

Тепер так, кінцевий результат той самий, але ви витратили багато часу на синтаксичні питання, з якими вам допомагає компілятор, - кількість часу, яка могла б бути значно коротшою, якби ви склали, як пішли далі.

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

Сказавши це, "складати, як ти йдеш", мені здається дуже ситуативною звичкою. Ви також можете бути відзначені тим, що ви "посміхнулися" за компіляцію частіше, ніж особисті упередження інтерв'ю. Це звучить як нитчінг; ніхто не любить визнавати, що опитаний вийшов з випробування; це підказує масштаби переговорів щодо зарплати.

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

Компілюйте, коли відчуєте, що зробили повну концептуальну одиницю в голові, і готові її перевірити. Раз на хвилину чи раз на тиждень, залежно від робочого процесу.

Тож моє запитання таке: чи щось я пропустив?

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

Складаючи кодову базу (все одночасно), вперше (подумайте, "проект з 20 файлами") змусить вас переключити контекст з того, про що ви думаєте (наприклад, "це значення встановлено на 5 тут, потім у для циклу blablabla, і складний алгоритм дає правильне значення при поверненні ") до проблеми компіляції, яка абсолютно не пов'язана з тим, про що ви думаєте (різні назви файлів / модулів / функцій / попередніх умов / синтаксисів / змінних, передумови тощо) ).

Чим більше коду ви складете одразу, тим більше контекстних комутацій потрібно зробити. Це не є проблемою для невеликої бази кодів, коли весь написаний вами код - це все, що ви написали за одну годину. Це велика проблема, хоча при роботі в існуючій кодовій базі з множинними (і багато разів недокументованими) взаємозалежностями.

Чи є насправді користь для складання, коли ви йдете далі?

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

Якщо ви компілюєте в дуже коротких ітераціях (це передбачає, що процес компіляції оптимізований для короткого часу), можна виправити помилки компіляції, не виходячи із "зони".

Або це якийсь міф, котрий поширюється програмним співтовариством, що ви повинні часто збирати свій код?

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

На мій погляд, це недійсний аргумент, тому що "отримання коду для компіляції" для заданої довжини коду, як правило, передбачає виправлення постійної кількості помилок компіляції і займає досить постійну кількість часу

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

Я б міг уявити, що люди, які опитали вас, зробили аналогічний висновок ("у вас мало досвіду у великих базах кодів").

Я думаю, що тут є більше ніж трохи професійного снобізму. Наслідком здається, що "якщо у вас ніколи не було необхідності регулярно збирати, тоді ви ніколи не працювали з чим-небудь складним - займіться додатковим досвідом і повертайтеся, коли навчились працювати саме так, як у нас".

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

Компілятор не може допомогти вам з логічними чи семантичними помилками, а помилки в синтаксисі насправді не так важко уникнути, щоб витратити половину вашого дня на компіляцію не варто. Звичайно, ви будете робити друкарські помилки, але я припускаю, що ви можете як дотикувати, так і читати. Якщо у вас є свобода вибору, використовуйте стиль кодування, який добре використовує макет, щоб візуально виділити помилки, і ви ніколи більше не скинете дужку, дужку або крапку з комою. Потрібно трохи практики і трохи більше дисципліни, ніж звикли більшість, але це можливо. Я можу писати код за пару годин за один раз у звичайному текстовому редакторі та скомпілювати його вперше краще, ніж дев'ять разів із десяти. Звичайно, я міг би компілювати частіше, але я не можу пригадати, коли востаннє у мене з’явилася помилка, яку було б простіше виправити в результаті.

Якщо ви не любитель постійних перекомпіляцій, ви в хорошій компанії. Ось Дональд Кнут:

Що стосується вашого справжнього запитання, то ідея негайної компіляції та "одиничних тестів" мені подобається лише рідко, коли я відчуваю себе в абсолютно невідомому середовищі і потребую зворотного зв’язку про те, що працює, а що ні. В іншому випадку багато часу витрачається на діяльність, яку мені просто ніколи не потрібно виконувати або навіть думати.

Все сказане ... якщо ви працюєте в контексті, коли компіляція - це вільна дія, то чому б вам це не зробити? Вдома, в особистих проектах, я натискаю ctrl-S приблизно кожні 30 секунд, а ярлик "компілювати" майже так само часто, в IDE, який постійно запускає код через передню частину компілятора, щоб забезпечити виділення помилок у реальному часі. Навіщо пропускати безкоштовний обід?

Є користь у складанні по дорозі. Але я дуже погоджуюся з тим, що залишатись над завданням - це нормально стратегія кодування.

Найбільш вагомою перевагою поступового компіляції є менталітет, який багато хто вступає, якщо вони чекають закінчення, щоб зібрати і протестувати : ми в кінці кінців більше стурбовані тим, щоб отримати код для запуску, ніж будь-що інше в цій точці. Ми говоримо "О, просто потрібно додати цю дужку, щоб компілятор перестав скаржитися" або "о, просто потрібно це використати з великої літери", не замислюючись, чи є основна смислова помилка, яку ховає ця синтаксична помилка. Я дійсно знаходжу синтаксичні помилки, часто вкладаються в смислові помилки (навпаки, неправда).

Наприклад, скажіть, що я змінив значення змінної і, як результат, змінив її назву. Зміна імені генерує синтаксичну помилку пізніше в коді, але якщо я просто порадую компілятора, виправляючи ім’я, я проігнорував, чому ця помилка з’явилася.

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

Але як ви будете перевіряти свій код, коли ви йдете разом, коли не компілюєте їх відповідно?

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

Тому не всі роблять TDD, принаймні, не завжди (я теж зізнаюся). Зі своєю нинішньою стратегією ви ніколи не матимете шансів навіть спробувати TDD. Але навіть коли ви не робите TDD, це дуже корисно для тестування вашого коду IMHO - що неможливо, коли ви не збираєте його регулярно. І коли ваш тест не вдасться, ви запускаєте його налагодження (що може допомогти вам зрозуміти, чому приємно виглядає алгоритм, який ви написали за кілька хвилин до цього, не так добре, як ви думали, що має робити). І чим більше коду ви пишете без компіляції, тим більше коду ви пишете без тестування, тим більше шансів на те, що трапиться справа, коли ви не можете передбачити, що час виправити проблему "O (1)", ти написав.

Я фактично погоджуюся з вами, що помилки компілятора не повинні бути великим ділом для досвідченого розробника. Я не думаю, що вартість їх виправлення з часом зростає достатньо істотно. Якби можна було відкласти виправлення всіх помилок компілятора до того самого часу, як це зробити, я б зробив це, оскільки це призвело б до набагато менших і консолідованих перерв.

На жаль, пошук помилок компілятора - не єдине, що роблять компілятори. Загрожуючи констатувати очевидне, потрібно запустити компіляцію для запуску програми, а для запуску програми потрібно знайти всі більш складні, тонкі та цікаві помилки виконання, які створюють навіть досвідчені розробники. І ці типи помилок є більш складними і , отже , більш дорогий , щоб виправити довше ви відкладаєте їх налагодженням, тому що вони можуть побудувати або маскувати один одного.

Однак я б не обов'язково когось відзначати в інтерв'ю для відкладання складання до самого кінця. Вправи на інтерв'ю, як правило, дуже прості, і досвідчені розробники зазвичай знають їх межі. Чим впевненіше ви ставитеся до написаного, тим довше будете переходити між компіляціями. Це просто людська природа.

Щоб не відзначити вас за це, хоч довіру доведеться виправдовувати. Якби ви витратили 45 хвилин на те, щоб щось писати, не компілюючи, а потім знадобилося ще 45 хвилин, щоб налагодити це, я б дуже важко поставився до вас.

Найважливіша річ у складанні часто, пропущених в інших відповідях, наскільки я бачу, це така: якщо ви збираєтеся рідко і отримуєте велику кількість помилок компілятора, більшість з них є безглуздими, оскільки вони породжуються першою помилкою. Це може бути тому, що у вас був неправильний тип, помилка друку або звичайна синтаксична помилка, яка робить декларацію недійсною.

Ви завжди можете просто виправити першу, перекомпілювати, виправити наступну, що залишилася тощо, але з великою базою коду це може бути повільним. Але якщо ви спробуєте проглядати довгий список помилок компілятора та помилки спотів, які є незалежними, ви витрачаєте багато часу на читання невідповідних повідомлень або навігацію коду з другої точки помилки до фактичної причини.

Інша річ, що стосується звичайних збірок, - це ніщо не заважає вам починати компілювати, як тільки у вас буде записаний повний блок коду, який слід зібрати. Потім ви можете продовжувати писати більше коду, поки компіляція триває, до тих пір, поки ви не збережете нові зміни, поки компіляція не закінчиться. Тож на очікування будівництва практично не витрачено часу. Якщо ви зачекаєте, поки ви не напишете все, що будете писати в той час, тоді вам доведеться чекати компіляції, нічого не робити. Це в основному ручна версія того, що сучасні IDE можуть робити у фоновому режимі автоматично.

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

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

Я регулярно пишу код протягом усього дня, не компілюючи, потім збираю і просто виправляю синтаксичні помилки та попередження звітів компілятора перед тим, як ввести свій код (із зауваженням, в якому сказано, що "потрібно перевірити!" ). У мене немає проблем з очищенням 1000+ рядків коду С або С ++ за кілька хвилин.

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

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

ps - Якби я дивився, як ви переглядаєте код, читаючи його, я б найняв вас на місці. Ось що робить професіонал кожного разу.

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

Наприклад, якщо ви дивовижний кодер, котрий витрачає свій час на те, щоб виправити це, і ви не пишете величезних сум або перекрученого коду, то регулярне компілювання - це марність, і, мабуть, також відволікання. Якщо ви цього не зробите, то компілювання кожної функції може бути хорошою справою. Це залежить від людини.

Як зустрічний приклад, уявіть, що ви пишете код JavaScript - компілятора немає. Замість цього (з огляду на характер більшості JavaScript-коду) ви запустили програму (або оновити сторінку), щоб побачити результати свого кодування. Тепер ви не можете цього робити, поки не напишете достатньо коду, щоб мати сенс. Як результат, розробники JavaScript прагнуть "компілювати" так часто, наскільки це можливо, що не обов'язково дуже часто.

Коротше кажучи, тут немає правильної відповіді - інтерв'юер не помиляється, але ви також не є. Робіть те, що робить вас продуктивними, і забувайте, що хтось скаже вам, що ви повинні робити. Існує набагато важливіші фактори кодування, ніж ваша схильність F7регулярно (або ні) вдарятися абсолютно не має наслідків.

У хорошому середовищі розробки я бачу мало підстав для компіляції, якщо ви насправді не плануєте тестувати код. Інструменти перевірки синтаксису фонів охоплюють більшість всього, про що, здається, говорить інтерв'юер, хоча, я визнаю, є ще кілька випадків (пов'язаних із змінами, які поширюються по файлах), які не завжди повністю ідентифіковані.

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

На мою думку та з мого досвіду, незалежно від того, чи компіляція фрагмента коду є по суті випадковою, включаючи такі речі, як відсутні крапки з комою чи ні, і мало стосується правильності основної програми. (Для мене, зосередження уваги на складанні - це як запуск статті через перевірку правопису без коректури, щоб перевірити граматику.)

Мій досвід дуже різний: менше 5% помилок компіляції, які я отримую, стосуються синтаксису . Я добре знаю мову, коли я отримую помилки, це в основному помилки типу, кажучи мені, що семантика не є правильною.

Ось чому я радий максимально швидко отримати користь від відгуків мого упорядника. Ви коли-небудь стикалися з використанням IDE, яка підкреслює помилки компіляції в режимі реального часу? Маючи коротший цикл зворотного зв’язку може бути дуже цінним.

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

Якщо вас очікує робота над кодом, написаним кимось іншим, ви не завжди встигаєте все прочитати. Хороша новина полягає в тому, що добре написаний код має низьке з'єднання, і він повинен давати можливість самостійно міркувати лише про ту частину коду, яка вам потрібна.

У цих випадках ви повинні вважати, що код, який ви ще не прочитали, є правильним, і ліниво досліджуйте, коли є проблема.

"отримання коду для компіляції" для заданої тривалості коду, як правило, передбачає виправлення постійної кількості помилок компіляції і займає досить постійну кількість часу, яка повинна бути однаковою, чи будете ви це робити після того, як ви закінчите писати код, або якщо переплутаєте це з вашим часом кодування.

Контекстна комутація дорого важить вашому мозку, тому виправлення невеликих помилок, як тільки ви їх пишете, може бути більш ефективним.

EDIT: Я також можу зробити аналогію з контролем джерел, коли ціла команда працює над одними і тими ж джерелами. Складаючи, як ви йдете далі, це як робити часті вчинки, це допомагає уникнути сильного болю в кінці, коли вам доведеться все злити і розібратися.

Ви кажете, що ви вимикаєте такі речі, як червоні рядки під текстом. Ви також робите це під час введення електронного листа або написання технічного документа? Тоді вам доведеться перечитати знову всі сторінки, а не виправляти помилки під час переходу.

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

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

Я трохи більше задумався над цим, бо відчув, що з інтерв'юером є щось дуже, дуже не так і не міг точно вказати, що це таке. Ось проблема: Для будь-якого коду, який я писав за останні двадцять років, кількість часу, необхідне для перетворення працездатного алгоритму в код, який компілюється, був мінімальним. Будь-який приріст ефективності в цій галузі має настільки малий вплив на загальний час розробки, що він є абсолютно незначним, а інтерв'юер, який відкидає кандидата на думку про неефективність у цій галузі, не має уявлення, що робить хорошого розробника.

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

Потім приходить невеликий проміжок часу написання коду, який складається.

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

Цей інтерв'юер зосередився на чомусь, що охоплене десятьма словами у моїй відповіді. Які становлять 10 відсотків або менше фактичного робочого часу. І майже нульовий вплив на здатність цього розробника виробляти надійний та робочий код.

Перевага "компіляції, коли ти йдеш" - це те, що ти отримуєш постійний зворотний зв'язок і не матимеш шансу піти не так, перш ніж підштовхнути в потрібному напрямку. Для грамотного програміста, як ви, це не є величезною увагою, але для багатьох інших це. Інакше кажучи, "компіляція під час проходження" - це спосіб "мінімізувати максимальну втрату", навіть якщо у вашому випадку є деякі потенційні втрати ефективності.

Компанії сьогодні цікавляться не просто готовим продуктом. Вони хочуть знати, що все це було "під контролем". Для них "потрапляння туди - половина задоволення".

Інші відповіді тут дають хороший захист для частого складання на роботі , але оскільки ваше питання зосереджене на інтерв'ю , я хотів би вирішити цей кут його.

У своїх інтерв'ю я роблю все навпаки: кандидати не можуть використовувати компілятор. Вони пишуть короткі програми на білій дошці, а потім ми їх обговорюємо. Я виявив, що занадто багато розробників використовують компілятор (або інтерпретатор) як милицю, і це набагато більша витрата часу, ніж занадто рідко збирання. Якщо я пропоную вам багато грошей і ви навіть не можете правильно написати FizzBuzz без компілятора, то ви ніколи не збираєтеся скорочувати це, працюючи над проблемами, які в 100 разів складніше, ніж іграшкові вправи в інтерв'ю. І все ж ці прості вправи відмовили більше кандидатів, ніж будь-яка інша частина інтерв'ю.

Мета інтерв'ю - оцінити взаємоздатність кандидата та бізнесу. Хороше запитання про співбесіду повинно визначати цілі питання та спосіб оцінювання респондента. Спростувати хитромудре запитання для опитаного, а потім покарати їх за те, що він не знає прихованої відповіді, не допоможе інтерв'юеру чи респонденту. На жаль, більшість програмістів - навіть старші - не навчаються інтерв'ювати інших програмістів, тому вони просто покладаються на кліше і задають ті самі типи питань, які їм задавали під час співбесіди, без особливих питань, чи це ефективні методи оцінювання кандидатів чи ні.

Я не стверджую, що мій підхід - це "єдиний вірний шлях", але він мені дуже добре послужив. Як і в багатьох програмних методологіях, які починаються з великої літери, існує однакова кількість "мандатів" на співбесіду. Всі вони двоярусні. Вам потрібно зробити те, що працює для вас і вашого бізнесу.

У великих проектах, що мають декілька підпрограм, ви хочете протестувати ці частини, перш ніж використовувати їх у більшій схемі, оскільки налагодити простіше, якщо ви знаєте, що певні частини вже працюють.

Для того щоб перевірити ці менші шматочки, вам потрібно скласти.

Можливо, інтерв'юер плутає цю ситуацію з невеликою програмою, яка не розроблена таким чином.

Щодо другого інтерв'ю, перевагою складання є те, що ви можете за кілька секунд спостерігати за тим, що програми роблять (чи ні). Звідти простіше прочитати код і зосередити свої зусилля на відповідних частинах. Можливо, саме цього і очікував інтерв'юер.

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