Comment gérer les questions d'entrevue sur le style de programmation [fermé]

En tant que programmeur C ++ dans les interviews, je me suis retrouvé à plusieurs reprises dans des situations où l'intervieweur voulait sonder ma connaissance d'un bon style de programmation. Celles-ci étaient généralement centrées sur les connaissances de base de la POO.

Je sais que la POO est utile pour encapsuler des concepts et je l'utilise quotidiennement. Cependant, comme un langage comme C ++ autorise de nombreux styles différents et que certaines approches C ++ comme les algorithmes TMP ou STL ne sont pas du tout OOP (mais plutôt plus comme de la programmation fonctionnelle), je me retrouve coincé sur la meilleure façon de "vendre" ma connaissance d'autres approches comme bien sans paraître arrogant ou comme quelqu'un sans apprécier les bases. Je crains que l'accent mis sur la POO des demandeurs ne provienne de leur socialisation dans les années 90 où la POO était considérée comme la panacée, mais c'est un point de vue arrogant à adopter.

Comment puis-je tirer le meilleur parti de questions comme celle-ci?

Je dirais que vous devez faire de votre mieux pour répondre à ce genre de questions, comme vous devriez faire de votre mieux pour répondre à tout type de questions.

Plus tard, lorsque vous aurez la possibilité de poser des questions à l'intervieweur, vous devrez aborder le sujet en posant des questions telles que:

• Faites-vous uniquement de la POO?
• J'utilise une approche de programmation différente, comment est-ce acceptable dans votre équipe?

Et ainsi de suite ... et de cette façon, vous pouvez non seulement entamer une conversation sur la vente de votre expertise avec ces autres approches, vous pouvez également voir à quel point rigide et à quel point l'accent est vraiment mis sur la POO dans cette équipe / entreprise.

Ne vous inquiétez pas trop des motivations du demandeur et répondez simplement honnêtement. N'oubliez pas qu'une entrevue est une rue à double sens. Vous ne voulez pas plus rester coincé dans une entreprise idéologiquement inflexible qu'ils ne veulent rester avec vous.

Cela étant dit, je pense que vous êtes un peu paranoïaque quant aux intentions des enquêteurs. Un nombre incroyable de programmeurs prétendument professionnels ne comprennent pas les principes fondamentaux de la POO. 99% du temps, les enquêteurs n'essaient pas de voir si vous avez bu le kool-aid OOP, mais veulent seulement voir si vous avez une compréhension de base. Même si vous sentez qu'un autre paradigme est mieux adapté à une certaine solution, les enquêteurs veulent savoir que c'était une conclusion éclairée et non fondée sur l'ignorance de la POO.

La rationalisation est un mécanisme de défense très courant lorsque quelqu'un ne comprend pas quelque chose. Si les gens ne comprennent pas un concept, ils soutiennent que le concept est stupide ou inapplicable plutôt que d'admettre leur propre ignorance. Même si vous pensez vraiment que la POO est un mauvais choix pour une réponse, vous devez néanmoins vous distinguer des rationaliseurs. La façon de le faire est d' expliquer à la fois la solution de POO et pourquoi vous pensez que c'est un mauvais choix dans cette situation.

Je tiens à souligner que vous suivez le principe SOLID , qui est la POO et plus encore. Non seulement cela garantit que votre code est orienté objet, mais qu'il est conçu de telle manière que la substitution d'objets suivant le principe SOLID est une tâche relativement simple. Non seulement cela enverrait le message que vous connaissez la POO, mais cela démontre que vous comprenez les points subtils sur ce qui distingue un bon code POO d'un code POO compliqué et hacky écrit par quelqu'un qui avait l'habitude de programmer en C et pense que toutes les autres langues devraient être programmées en de la même façon, puisque soyons honnêtes, c'est ce qui fait de vous un bon programmeur, pas seulement pouvoir utiliser la POO.

Soyez prêt à expliquer en détail pour chacun des cinq principes pourquoi chacun est important et ce qui pourrait arriver au code qui ignore ce principe.