Come gestire le domande del colloquio sullo stile di programmazione [chiuso]

Come programmatore C ++ nelle interviste mi sono ripetutamente trovato in situazioni in cui l'intervistatore voleva sondare la mia conoscenza del buon stile di programmazione. Questi in genere erano incentrati sulla conoscenza di base di OOP.

So che OOP è utile per incapsulare concetti e lo uso quotidianamente. Tuttavia, poiché un linguaggio come C ++ consente molti stili diversi e alcuni approcci C ++ come gli algoritmi TMP o STL non sono affatto OOP (ma piuttosto più come la programmazione funzionale) mi trovo bloccato su come "vendere" meglio la mia conoscenza di altri approcci come bene senza imbrogliare come arrogante o come qualcuno senza apprezzare le basi. Temo che questa enfasi su OOP dei richiedenti derivi dal fatto che sono stati socializzati negli anni '90, dove si credeva che OOP fosse la cura per tutti, ma questo è un punto di vista arrogante da prendere.

Come potrei trarre il meglio da domande come questa?

Direi che devi fare del tuo meglio per rispondere a questo tipo di domande, come dovresti fare del tuo meglio per rispondere a qualsiasi tipo di domanda.

Successivamente, quando ti viene data la possibilità di porre domande all'intervistatore, dovresti sollevare l'argomento, ponendo domande come:

• Fai solo OOP?
• Uso un approccio di programmazione diverso, come è accettabile nel tuo team?

E così via ... e in questo modo non solo puoi iniziare una conversazione sulla vendita delle tue competenze con quegli altri approcci, ma puoi anche vedere quanto sia rigida e quanta enfasi viene data a OOP in quel team / azienda.

Non preoccuparti troppo delle motivazioni del richiedente e rispondi onestamente. Ricorda, un'intervista è una strada a doppio senso. Non vuoi rimanere bloccato in un'azienda ideologicamente inflessibile più di quanto non vogliano rimanere bloccato con te.

Detto questo, penso che tu sia un po 'paranoico sulle intenzioni degli intervistatori. Un numero sorprendente di programmatori presumibilmente professionali non comprende i fondamenti di OOP. Il 99% delle volte, gli intervistatori non stanno cercando di vedere se hai bevuto il kool-aid OOP, ma vogliono solo vedere se ne hai una conoscenza di base. Anche se ritieni che un altro paradigma sia più adatto a una determinata soluzione, gli intervistatori vogliono sapere che si trattava di una conclusione informata e non nata dall'ignoranza di OOP.

La razionalizzazione è un meccanismo di difesa molto comune quando qualcuno non capisce qualcosa. Se le persone non capiscono un concetto, sostengono che il concetto è stupido o inapplicabile piuttosto che ammettere la propria ignoranza. Anche se pensi davvero che OOP sia una cattiva scelta per una risposta, devi comunque distinguerti dai razionalizzatori. Il modo per farlo è quello di entrambi spiegare la soluzione di programmazione orientata agli oggetti e perché si pensa che sia una scelta sbagliata in quella situazione.

Vorrei sottolineare che segui il principio SOLID , che è OOP e altro ancora. Non solo garantisce che il codice sia orientato agli oggetti, ma che sia modellato in modo tale che la sostituzione di oggetti secondo il principio SOLID sia un'attività relativamente semplice. Non solo invierebbe il messaggio che conosci OOP, ma dimostra che capisci i punti sottili su ciò che distingue il buon codice OOP dal complicato codice OOP scritto da qualcuno che era solito programmare in C e pensa che tutte le altre lingue dovrebbero essere programmate in allo stesso modo, dal momento che siamo onesti, questo è ciò che ti rende un buon programmatore, non solo essere in grado di utilizzare OOP.

Preparati a spiegare a fondo per ciascuno dei cinque principi perché ognuno è importante e cosa potrebbe accadere al codice che ignora quel principio.