Як вирішувати питання інтерв'ю щодо стилю програмування [закрито]

Як C ++ - програміст в інтерв'ю, я неодноразово опинявся в ситуаціях, коли інтерв'юер хотів перевірити свої знання про хороший стиль програмування. Вони, як правило, були орієнтовані на основні знання про ООП.

Я знаю, що OOP корисний для інкапсуляції понять, і я його використовую щодня. Однак, оскільки мова на зразок C ++ дозволяє багато різних стилів, а деякі C ++ підходи, такі як алгоритми TMP або STL, зовсім не є OOP (а скоріше, як функціональне програмування), я вважаю, що я застряг у тому, як найкраще "продати" свої знання щодо інших підходів, як добре, не натрапляючи на нахабне чи як хтось, не розуміючи основ. Я побоююсь, що цей акцент на ООП запитуючих походить від їх соціалізації у 90-х, де, як вважалося, ООП є лікувальним, але це зарозуміла позиція.

Як би я зробив найкращі такі питання?

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

Пізніше, коли вам надається можливість задавати питання інтерв'юеру, вам слід підняти тему, задаючи такі питання:

• Ви робите тільки OOP?
• Я використовую інший підхід до програмування, як це прийнятно у вашій команді?

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

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

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

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

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

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