Как отвечать на вопросы интервью о стиле программирования [закрыто]

Как программист на C ++ в интервью, я неоднократно оказывался в ситуациях, когда интервьюер хотел проверить мои знания о хорошем стиле программирования. Как правило, они были сосредоточены вокруг базовых знаний ООП.

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

Как бы я решил лучшие вопросы?

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

Позже, когда вам будет предоставлена ​​возможность задать вопросы интервьюеру, вы должны поднять тему, задав такие вопросы:

• Вы только делаете ООП?
• Я использую другой подход программирования, как это приемлемо в вашей команде?

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

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

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

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

Я хотел бы подчеркнуть, что вы следуете принципу SOLID , который является ООП и многое другое. Мало того, что он гарантирует, что ваш код является объектно-ориентированным, но он создан таким образом, что замена объектов в соответствии с принципом SOLID является относительно простой задачей. Он не только отправит сообщение о том, что вы знаете ООП, но и продемонстрирует, что вы понимаете тонкие моменты, которые отличают хороший код ООП от хакерского сложного кода ООП, написанного кем-то, кто раньше программировал на C, и считает, что все другие языки должны быть запрограммированы на Таким же образом, поскольку давайте будем честными, это делает вас хорошим программистом, а не просто способным использовать ООП.

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