Come gestire le domande di intervista sullo stile di programmazione [chiuso]

Question

Come gestire le domande di intervista sullo stile di programmazione [chiuso]

#1 da (6 voti)
#2 da (5 voti)
#3 da (3 voti)

11

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

So che OOP è utile per incapsulare concetti e io 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 come programmazione funzionale) mi trovo bloccato su come "vendere" meglio le mie conoscenze di altri approcci come bene senza imbattersi in arrogante o come qualcuno senza apprezzamento delle basi. Temo che questa enfasi su OOP dei richiedenti derivi dalla loro socializzazione negli anni '90 in cui si credeva che OOP fosse il toccasana, ma questo è un punto di vista arrogante.

Come farei meglio delle domande come questa?

c++ interview concepts

posta Benjamin Bannier 07.05.2012 - 11:25

fonte

3 risposte

Leggi altre domande sui tag c++ interview concepts

Inoltra dichiarazione vs include Classe concreta di derisione - Non raccomandato

score 6 · Answer 1

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

Successivamente, quando ti viene data l'opportunità di porre domande all'intervistatore, devi sollevare l'argomento, ponendo domande come:

Fai solo OOP?
Uso un approccio di programmazione diverso, com'è accettabile nella tua squadra?

E così via ... e in questo modo non puoi solo iniziare una conversazione sulla vendita della tua esperienza con quegli altri approcci, puoi anche vedere quanto rigida e quanta enfasi sia realmente data a OOP in quella squadra / azienda.

score 5 · Answer 2

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

Detto questo, penso che tu sia un po 'paranoico sulle intenzioni degli intervistatori. Un numero incredibile di programmatori presumibilmente professionisti non capisce i fondamenti dell'OOP. Il 99% delle volte, gli intervistatori non stanno cercando di vedere se hai bevuto l'aiuto di kool OOP, ma vuoi solo vedere se ne hai una comprensione di base. Anche se ritieni che un altro paradigma sia più adatto per una determinata soluzione, gli intervistatori vogliono sapere che si tratta 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 scelta sbagliata per una risposta, devi comunque distinguerti dai razionalizzatori. Il modo per farlo è entrambi spiegare la soluzione OOP e perché pensi che sia una scelta sbagliata in quella situazione.

score 3 · Answer 3

Vorrei sottolineare che segui il principio SOLID , che è OOP e altro ancora. Non solo garantisce che il tuo codice sia orientato agli oggetti, ma che sia modellato in modo tale che la sostituzione di oggetti seguendo il principio SOLID sia un compito relativamente semplice. Non solo invia il messaggio che conosci OOP, ma dimostra che comprendi i punti sottili su ciò che distingue il buon codice OOP dal codice OOP complicato e hacky scritto da qualcuno che ha programmato in C e pensa che tutte le altre lingue debbano essere programmate in allo stesso modo, dal momento che siamo onesti, questo è ciò che ti rende un buon programmatore, non solo la possibilità di usare OOP.

Siate pronti a spiegare esaurientemente per ciascuno dei cinque principi perché ognuno è importante e cosa potrebbe accadere al codice che ignora tale principio.