OO Domande relative al design nelle interviste tecniche [chiuso]

1. In una certa misura, sì. Chiunque può recitare la sintassi o copiare / incollare la propria strada attraverso una soluzione. Vogliamo assumere persone in grado di risolvere i problemi.

2. Si aspettano che tu possa documentare il design in modo sufficiente da poterlo capire (e non di più).

3. Chiedo alle persone come risolverebbero il problema XYZ, sì. Solitamente lo descrivono solo verbalmente. Voglio vedere se fanno domande per chiarire i requisiti. Voglio vedere come comunicano con altri programmatori. Voglio vedere se riescono a pensare in piedi.

È stato utile per me. Non voglio le scimmie del codice, voglio i tecnici del software.

Trovo che queste domande siano piuttosto sciocche. La vera risposta è "quali sono i casi d'uso?" Senza un caso d'uso, non è necessario alcun progetto. Ad esempio, ecco una risposta perfettamente ragionevole alla domanda del parcheggio:

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

Soddisfa un caso d'uso ovvio.

In realtà dimostri un uso di questa domanda nella tua modifica, in cui non riesci a progettare un modello realizzabile.

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

Hai anche menzionato la creazione delle classi Car e Motorcycle , che non ha molto senso senza ulteriori considerazioni. Il tuo progetto non trarrà alcun vantaggio dall'aver ottenuto una sottoclasse di Vehicle . Se introduci Motorcycle senza differenze comportamentali in Vehicle , lo considero un errore.

Se non hai individuato il singolo problema di Vehicle , in un colloquio avremmo praticamente finito. Se l'hai corretto (probabilmente rendendolo un List<IVehicle> ), userei questo come punto di partenza per analizzare l'evoluzione del tuo design. C'è un motivo per cui i requisiti sono fondamentali e non ci sono casi d'uso ben definiti - è praticamente il modo in cui il mondo funziona.

Potrei lanciare il nuovo requisito secondo cui "due motocicli possono parcheggiare in uno slot" per vedere come si evolverà il tuo progetto per gestirlo. Allora forse avremo una conversazione sulla concorrenza (e se avessimo due entrate e due macchine si fermassero contemporaneamente ... il tuo progetto fallirà? Come? Cosa possiamo fare per risolverlo?). Altre possibili strade da esplorare sarebbero come implementare il parcheggio assegnato, la ricarica per il parcheggio, i tassi per fila (forse le file più vicine devono pagare di più), parcheggi a tempo limitato e come trovare trasgressori, ecc. Ecc.

Vorrei anche considerare il tuo processo di pensiero intorno ai parcheggi per essere indicativo della tua capacità generale di analizzare in modo intelligente un problema. Se devi chiedermi i casi di utilizzo di base e / o inventare quelli stravaganti (come 2 per 1 speciali sul parcheggio), comincio a essere molto preoccupato che non hai mai usato un parcheggio prima e che siamo avere difficoltà a comunicare su qualcosa di leggermente complicato.

Ero solito chiederle - quando abbiamo creato diagrammi di classe per la generazione del codice. Faccio ancora occasionalmente, ma non di routine. Mi piace la domanda perché mi fa vedere la persona che pensa.

È destinato a essere aperto. Va bene. Non c'è una risposta giusta. Non ho una risposta nella mia mente; Voglio vedere dove conduce. Penso che sia una domanda migliore da fare di persona, non "email in risposta". Riguarda la comunicazione, le ipotesi e l'interazione; non solo una risposta!

1. Ho visto questo tipo di interviste almeno 12 anni fa. È l'approccio che ho usato negli ultimi 6 anni. L'esperienza dimostra che seleziona i candidati migliori per il lavoro rispetto alle domande su 20 e dà loro un punteggio su 20 approccio.

2. Ancora una volta, lo renderei anche molto aperto. L'obiettivo è fornire spazio al candidato per dimostrare abilità. Avere un candidato che ha posto domande pertinenti in questa fase sarebbe un vantaggio. Dato che un candidato sta facendo delle buone ipotesi, ma segnala che erano delle ipotesi, e avrebbe bisogno di essere riesaminato prima dell'implementazione.

3. Faccio appello a tutti i potenziali dipendenti per dimostrare le competenze di cui hanno bisogno per il lavoro al colloquio. Per i programmatori, dovranno implementare del codice e parlare del loro design per questo. È molto efficace per prevenire i brutti noleggi, ma essere preparato per un tasso di fallimento del 90% al colloquio.

Progettare un piccolo sistema è in realtà un esercizio molto importante da chiedere in un'intervista. Mostra le tue abilità nel trovare una buona soluzione software per un problema di dominio.

Tuttavia, trovo strano solo chiedere di pubblicare un diagramma di classe online senza interazione umana:

• Mancheranno l'essenziale: il ragionamento che sta dietro il diagramma e ciò che ti ha portato a progettare le cose in questo modo.
• Non esiste un "parapetto" per impedire al candidato di andare troppo lontano. Se rifletti un'implementazione finale nel diagramma, probabilmente avrai dozzine di classi e uno schema illeggibile.
• Essere in grado di disegnare un diagramma di classe UML non è davvero un'abilità essenziale, è solo una notazione OO tra le altre. La possibilità di creare disegni solidi è.

In un'intervista dal vivo, i passi ideali che mi aspetterei che un candidato prendesse sarebbero:

• Parla del problema con il reclutatore e inizia a esprimere verbalmente una soluzione di base, ponendo domande e modificando il recruiter in modo più preciso.
• Alzati e disegna una vista generale del sistema e su come i componenti potrebbero interagire insieme. Potrebbe essere lo stile più puro di UML, potrebbe essere solo scatole e cerchi.
• Scrivi un test, test di accettazione di alto livello o test di unità per uno dei componenti / classi.
• Inizia a scrivere l'implementazione corrispondente.

Si spera che a un certo punto il selezionatore avrà raccolto abbastanza informazioni sulle capacità del candidato e lo chiamerà un giorno. L'obiettivo non è quello di implementare una soluzione di lavoro completa (a meno che non sia uno di questi servizi non a pagamento in interviste in incognito).

Le domande OOP sono aperte. Non c'è una risposta giusta o sbagliata, ma ci sono alcuni principi che gli intervistatori si aspettano di vedere (come usare un costruttore per inizializzare le variabili, mantenere i metodi piccoli, usando l'incapsulamento / composizione / polimorfismo / ereditarietà quando applicabile, ecc.)

Aspettatevi sempre le domande relative a struttura dei dati, OOP e database nelle interviste, sono molto comuni. Libri come "cracking the coding interview" e "programming interviews exposed" possono aiutarti a prepararti.

Mi era stato chiesto di uscire da un progetto per un parcheggio non molto tempo fa. In primo luogo non mi è stato dato alcun caso d'uso, ma ne ho parlato un paio dopo. Credo che il mio design non corrispondesse a quello che l'intervistatore aveva in mente. Sono d'accordo che qualsiasi progetto software è valido solo per un determinato caso d'uso. Tornando a questa domanda di intervista, credo che il mio intervistatore non abbia avuto alcuna esperienza di progettazione del mondo reale. Quelle persone credono di sapere quello che chiedono. È un'altra storia se sia effettivamente vero o no.