Umgang mit Interviewfragen zum Programmierstil [geschlossen]

Als C ++ - Programmierer in Interviews befand ich mich wiederholt in Situationen, in denen der Interviewer mein Wissen über einen guten Programmierstil testen wollte. Diese konzentrierten sich typischerweise auf Grundkenntnisse in OOP.

Ich weiß, dass OOP nützlich ist, um Konzepte zu kapseln, und ich benutze es täglich. Da eine Sprache wie C ++ jedoch viele verschiedene Stile zulässt und einige C ++ - Ansätze wie TMP- oder STL-Algorithmen überhaupt nicht OOP sind (sondern eher funktionale Programmierung), bin ich nicht sicher, wie ich mein Wissen über andere Ansätze am besten "verkaufen" kann gut, ohne arrogant oder als jemand ohne Verständnis für die Grundlagen zu wirken. Ich befürchte, dass diese Betonung der OOP der Fragesteller darauf zurückzuführen ist, dass sie in den 90er Jahren sozialisiert wurden, als OOP als Allheilmittel galt, aber das ist ein arroganter Standpunkt.

Wie würde ich das Beste aus solchen Fragen machen?

Ich würde sagen, Sie müssen Ihr Bestes geben, um diese Art von Fragen zu beantworten, so wie Sie Ihr Bestes geben sollten, um jede Art von Fragen zu beantworten.

Wenn Sie später die Möglichkeit haben, dem Interviewer Fragen zu stellen, sollten Sie das Thema ansprechen und Fragen stellen wie:

• Machst du nur OOP?
• Ich verwende einen anderen Programmieransatz. Wie ist das in Ihrem Team akzeptabel?

Und so weiter ... und auf diese Weise können Sie nicht nur ein Gespräch über den Verkauf Ihres Fachwissens mit diesen anderen Ansätzen beginnen, sondern auch sehen, wie starr und wie stark OOP in diesem Team / Unternehmen wirklich betont wird.

Sorgen Sie sich nicht zu sehr um die Motivationen des Fragestellers und antworten Sie einfach ehrlich. Denken Sie daran, ein Interview ist eine Einbahnstraße. Sie wollen nicht mehr in einem ideologisch unflexiblen Unternehmen stecken bleiben, als sie mit Ihnen stecken bleiben wollen.

Davon abgesehen denke ich, dass Sie in Bezug auf die Absichten der Interviewer ein wenig paranoid sind. Eine erstaunliche Anzahl angeblich professioneller Programmierer versteht die Grundlagen von OOP nicht. In 99% der Fälle versuchen Interviewer nicht zu sehen, ob Sie die OOP-Kool-Hilfe getrunken haben, sondern nur, ob Sie ein grundlegendes Verständnis dafür haben. Selbst wenn Sie der Meinung sind, dass ein anderes Paradigma für eine bestimmte Lösung besser geeignet ist, möchten die Interviewer wissen, dass dies eine fundierte Schlussfolgerung war und nicht von der Unkenntnis der OOP getragen wurde.

Rationalisierung ist ein sehr häufiger Abwehrmechanismus, wenn jemand etwas nicht versteht. Wenn Menschen ein Konzept nicht verstehen, argumentieren sie, dass das Konzept dumm oder nicht anwendbar ist, anstatt ihre eigene Unwissenheit zuzugeben. Auch wenn Sie wirklich der Meinung sind, dass OOP eine schlechte Wahl für eine Antwort ist, müssen Sie sich dennoch von den Rationalisierern unterscheiden. Die Art und Weise , das zu tun ist , um sowohl die OOP Lösung erklären und warum Sie denken , es ist eine schlechte Wahl in dieser Situation.

Ich möchte betonen, dass Sie dem SOLID- Prinzip folgen , das OOP und mehr ist. Dies garantiert nicht nur, dass Ihr Code objektorientiert ist, sondern auch so gestaltet ist, dass das Ersetzen von Objekten nach dem SOLID-Prinzip eine relativ einfache Aufgabe ist. Es würde nicht nur die Nachricht senden, dass Sie OOP kennen, sondern es zeigt auch, dass Sie die subtilen Punkte darüber verstehen, was guten OOP-Code von hackigem, kompliziertem OOP-Code unterscheidet, der von jemandem geschrieben wurde, der früher in C programmiert hat und der Meinung ist, dass alle anderen Sprachen programmiert werden sollten Die gleiche Art und Weise, da wir ehrlich sind, macht Sie zu einem guten Programmierer, der nicht nur OOP verwenden kann.

Seien Sie bereit, für jedes der fünf Prinzipien gründlich zu erklären, warum jedes wichtig ist und was mit Code geschehen kann, der dieses Prinzip ignoriert.