Як повинен виглядати мій "зразок коду"? [зачинено]

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

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

Всі ідеї чи пропозиції вітаються!

Я хотів би побачити чистий код :

Чистий код : програмний код, відформатований правильно та організовано, щоб інший кодер міг легко його читати чи змінювати.

Це означає:

• Функціональність - Деякі прості біти функціональності, які є нетривіальними (купа геттерів / сеттерів не показує, що ви нічого не знаєте)
• Постійний, чистий стиль - Популярний або принаймні загальний стилі корпусу, відступи, інтервали та дужки
• Гарне найменування - Назви якості - не використовуйте, iякщо це не єдине значення приросту. Не використовуйте імен змінних дурниць.
• Інші атрибути чистого коду - належні практики щодо перевірки помилок, умов, циклів, методів зручності чи корисних методів, а також належного розмежування проблем (між методами). І це гарний час бути 100% сухим - повторення немає!

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

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

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

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

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

І тоді, створений вами код повинен бути зрозумілим, послідовним, легким для читання та легким для розуміння.

І останнє:

• Варто вирішити їх просто заради задоволення, і це хороша практика.

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

Ну, якби я опитував вас, я хотів би побачити ваш код.

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

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

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

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

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

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

1. Ідентичність : аромат коду. Якщо ви виставляєте рахунки як кодер UI / HCI, я хочу бачити гарний вигляд / відчуття чогось візуального, коли запускаю його. Якщо ви будівельник БД, я хочу побачити щось цікаве з поданням даних або їх аналізом. Зразок повинен бути чим ви пишаєтесь . Якщо у вас немає хоча б одного з них, у вас немає особи.
2. Зрілість : чи зміщуєте стратегії для різних проблем? Ви вирішуєте цікаві проблеми? Чи легко легко поширити код або підхід до подібної проблеми? З іншого боку, я відчуваю, що дивлюсь на члена вантажної культової комуни?
3. Спілкування : Чи легко код пояснює, що він робить і чому? Це не означає, що код повинен бути простим. Насправді, це бонус зробити складний код легким для розуміння.

Аспекти низького рівня простіші:

1. Стиль : Код повинен бути чистим, послідовним (дотримуватися деяких встановлених вказівок) та добре задокументованим.
2. Упаковка : Повинно бути, як мінімум, коротка література, версія, яку можна виконати та тести на виконання. У readme слід сказати мені, як запустити останні два, а також чому ви демонструєте саме цей зразок коду.
3. Мова (мови) : Я зазвичай прошу когось проби з мовою на посаду, а також того, в якому вони відчуваються найсильнішими. Дає гарне уявлення про поточні стелі людини.

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

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

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