Як поводитися з інтерв'ю «поганого коду»? [зачинено]

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

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

Інтерв'ю з поганим кодом (якщо вони виконані належним чином) повинні показувати вам код із наступним:

• Неправильна мовна техніка (не використовуючи usingвираз у C # за потреби або використовуючи ArrayListзамість а List<T>)
• Неправильне дизайнерське рішення (чому, до біса, ми передаємо рядки скрізь, або так багато використовуємо refі outпараметри?)
• Помилки синтаксису (це навіть не слід компілювати!)
• Помилки під час виконання (наприклад, переповнення стека, спричинене властивістю, що посилається на себе в C #)

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

Нещодавно я розповів про фрагмент коду, який демонстрував усі ці проблеми , він повинен допомогти вам пройти той самий ментальний процес.

Ейенде заглиблюється в серію « Заробітки за гріх ».

Не намагайтеся зрозуміти це швидко. Мета тут - не побачити, чи зможете ви зрозуміти код, як гуру, а скоріше побачити, як ви думаєте.

Ключовий ІМО - просто думати вголос. Тож навіть якщо ви замерзнете - тоді просто скажіть: "Я тут стрес, але дозвольте мені пройти через це повільно вголос".

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

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

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

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

Перш за все, поговоріть через те, що ви робите і думаєте - це допоможе вам і інтерв'ю.

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

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

Почніть із кроків із значеннями вашого щасливого шляху. Для функції додавання ви можете почати з 3 або 4. Вивчіть кожен рядок на помилки помилок та логіки, відстежуючи значення локальних змінних у процесі руху. Сподіваємось, ви знайдете кілька помилок. Коли ви закінчите щасливий шлях, у вас буде краще почуватися код, і, сподіваємось, ви відчуєте себе трохи перевантаженим - тому скажіть щось на кшталт: "Тепер, коли я краще відчуваю, що робить цей код, я збираючись відступити назад і поглянути на це ", тоді зробіть саме це - шукайте речі, які вам виділяються як речі, які ви зробили б інакше (погані дизайнерські рішення, погано названі змінні, досліджуйте можливі помилки тощо).

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

Це, принаймні, змусить вас піти.

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

Якщо ви відчуваєте менший тиск, роблячи це як письмовий тест, тоді дістаньте свій зошит і починайте робити нотатки. Я витягнув зошит і почав замальовувати конспекти як частину мого мислення в інтерв'ю. Наявність ноутбука та ручки дозволяє вам виглядати організовано. Ви можете записати кілька пунктів, які потрібно шукати, синтаксис, логічні помилки, невідповідність типів даних, значення локальних змінних (список може змінюватись залежно від типу коду, який ви отримали, мій список для складної частини SQL бути іншим, ніж той, хто отримав фрагмент коду, який не був орієнтований на дані), коли ви проходили процес тощо. Після того, як ви написали декілька з них, почніть їх шукати. Таким чином, навіть якщо ви не знайдете всіх проблем, перш ніж інтерв'юер захоче рухатися далі, він / вона зможе побачити список речей, які ви збиралися перевірити. Якщо ви заздалегідь створите контрольний список речей, які, можливо, захочете шукати, тоді ви будете почувати себе впевненіше, починаючи процес, знаючи, які речі ви планували подивитися. Зазвичай ці питання стосуються того, як ви могли б знайти помилки, ніж насправді знайти їх.

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

Можливо, два питання:

Це може бути "стрес-інтерв'ю" http://en.wikipedia.org/wiki/Job_interview#Stress . Інтерв'юер намагається побачити, як ви справляєтеся зі стресом, оскільки їхнє робоче середовище таке.

АБО

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