Domande relative a OO Design in interviste tecniche [chiuso]

Recentemente ho partecipato a parecchie interviste e mi è stato chiesto dalle aziende di rispondere alle domande "progettare un [inserire modello]" più di alcune volte.

1. Oggi è normale nel settore? Sono stato nel mondo del software per più di due decenni e ho partecipato alla mia parte di interviste, ma vedo questo schema nelle interviste emergere solo di recente.
2. Sento che la domanda è molto aperta. Ad esempio: mi è stato chiesto di disegnare un diagramma di classe per "Progettare un parcheggio". Non sono sicuro del livello di dettaglio che l'intervistatore si aspetta. Questo è stato in un test online in cui mi aspettavo di allegare un diagramma di Visio, quindi non potevo chiedere loro quali fossero le loro aspettative.
3. Usi questo tipo di domande nel processo di intervista? Sono collegati solo a diagrammi di classe o chiedete anche sequenza, diagrammi di flusso ed ERD (ovviamente basati sulla natura della posizione). Sono stati efficaci nel vostro processo di assunzione?

* Modifica per la risposta di Kevin *

Ad esempio: una domanda completa potrebbe essere "Progettare un sistema di gestione dei parcheggi che può essere utilizzato per trovare slot liberi"

Mi può essere fatto con 2 classi, ParkingLote Sloto potrei andare avanti per aggiungere IVehiclee Vehicleed Care Motorcycleclassi. Dove posso disegnare la linea?

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; }
}

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 documenti sufficientemente il design da poterlo comprendere (e non di più).

3. Chiedo alla gente come risolverebbero il problema XYZ, sì. Di solito 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.

Mi è stato utile. Non voglio scimmie codice, voglio ingegneri del software.

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

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

Soddisfa un caso d'uso ovvio.

In realtà si dimostra un uso di questa domanda nella modifica, in cui non si riesce 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!??

Citi anche la creazione Care le Motorcyclelezioni, il che non ha molto senso senza ulteriore considerazione. Il tuo design non trarrà alcun vantaggio dall'aver effettuato la sottoclasse Vehicle. Se presentiMotorcycle senza differenze comportamentali Vehicle, lo considererei un fallimento.

Se non hai individuato il singolo Vehicle problema, avremmo praticamente finito in un'intervista dal vivo. Se lo correggessi (possibilmente facendo quello a List<IVehicle>), lo userei come punto di partenza per esaminare l'evoluzione del tuo design. C'è una ragione per cui i requisiti sono di base e non esistono casi d'uso ben definiti - è praticamente così che funziona il mondo.

Potrei lanciarti il ​​nuovo requisito secondo cui "due motociclette possono parcheggiare in uno slot" per vedere come faresti evolvere il tuo design per gestirlo. Quindi forse avremo una conversazione sulla concorrenza (e se avessimo due ingressi 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, l'addebito per il parcheggio, le tariffe per fila (forse le file più vicine devono pagare di più), il parcheggio a tempo limitato e come trovare i trasgressori, ecc., Ecc.

Considererei anche il tuo processo di pensiero intorno ai parcheggi come indicativo della tua capacità generale di analizzare in modo intelligente un problema. Se devi chiedermi casi d'uso di base e / o inventarne di strani (come gli speciali 2 per 1 sui parcheggi), comincio a preoccuparmi fortemente che non hai mai usato un parcheggio prima e che stiamo sarà difficile comunicare qualcosa di leggermente complicato.

Prima chiedevo queste domande quando abbiamo creato diagrammi di classe per la generazione di codice. Lo faccio ancora in occasione, ma non di routine. Mi piace la domanda perché mi fa vedere la persona pensare.

È inteso per 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 porre di persona, non "e-mail in risposta". Riguarda la comunicazione, i presupposti 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 20 domande poste e fornisce loro un punteggio su 20 approcci.

2. Ancora una volta, lo renderei anche molto aperto. L'obiettivo è fornire spazio al candidato per dimostrare capacità. Avere un candidato che ha posto domande pertinenti in questa fase sarebbe un vantaggio. Come un candidato sta facendo buone assunzioni, ma segnalando che si trattava di ipotesi che avrebbero dovuto essere riviste prima dell'implementazione.

3. Richiedo a tutti i potenziali dipendenti di dimostrare le competenze di cui hanno bisogno per il lavoro durante il colloquio. Per i programmatori, dovranno implementare un po 'di codice e parlare della loro progettazione. È molto efficace per prevenire i cattivi assunti, ma al colloquio preparatevi per un tasso di fallimento del 90%.

La progettazione di un piccolo sistema è in realtà un esercizio molto rilevante da chiedere in un'intervista. Mostra le tue abilità nel trovare una buona soluzione software a un problema di dominio.

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

• Mancheranno l'essenziale: il ragionamento alla base del diagramma e cosa ti ha portato a progettare le cose in quel modo.
• Non esiste un "parapetto" per impedire al richiedente di andare troppo lontano. Se rifletti un'implementazione finale nel diagramma, probabilmente avrai decine 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 gli altri. La capacità di creare progetti solidi è.

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

• Parla del problema con il recruiter e inizia a esprimere verbalmente una soluzione di base, ponendo domande e adattandoti mentre il recruiter fornisce esigenze più precise.
• Alzati e disegna una visione d'insieme del sistema e di 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 collaudo di alto livello o unit test per uno dei componenti / classi.
• Inizia a scrivere l'implementazione corrispondente.

Spero che a un certo punto il recruiter abbia 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 retribuiti nelle interviste mascherate).

Le domande OOP sono a tempo indeterminato. Non esiste 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 piccoli i metodi, usare l'incapsulamento / composizione / polimorfismo / eredità quando applicabile, ecc.).

Aspettatevi sempre domande sulla struttura dei dati, OOP e relative al database nelle interviste, sono molto comuni. Libri come "rompere l'intervista di programmazione" e "interviste di programmazione esposte" possono aiutarti a prepararti.

Non molto tempo fa mi era stato chiesto di presentare un progetto per un parcheggio. In primo luogo non mi sono stati dati casi d'uso, ma ne ho parlato un paio dopo. Credo che il mio design non corrispondesse a quello che aveva in mente l'intervistatore. Accetto che qualsiasi progetto di software sia valido solo per un determinato caso d'uso. Tornando a questa domanda dell'intervista, credo che il mio intervistatore non abbia avuto alcuna esperienza di design nel mondo reale. Quelle persone credono di sapere cosa chiedono. È un'altra storia che sia davvero vera o no.