OO Questions liées à la conception dans les entretiens techniques
J'ai assisté à plusieurs entretiens récemment et des entreprises m'ont demandé de répondre à plusieurs fois aux questions "concevoir un [insérer le modèle]".
- Est-ce normal dans l'industrie de nos jours? Je suis dans le monde du logiciel depuis plus de deux décennies et j'ai assisté à ma part d'entrevues, mais je vois ce modèle émerger récemment.
- Je pense que la question est très ouverte. Par exemple: on m'a demandé de dessiner un diagramme de classe pour "Concevoir un parking". Je ne sais pas à quel niveau de détail l'intervieweur s'attend. C'était dans un test en ligne où je devais joindre un diagramme visio, donc je ne pouvais pas leur demander quelles étaient leurs attentes.
- Utilisez-vous ce genre de questions dans votre processus d'entrevue? Sont-ils liés uniquement aux diagrammes de classes ou demandez-vous également la séquence, les organigrammes et les DRE (bien sûr, en fonction de la nature du poste). Ont-ils été efficaces dans votre processus d'embauche?
* Modifier pour la réponse de Kevin *
Par exemple: Une question complète pourrait être "Concevoir un système de gestion de parking qui peut être utilisé pour trouver des emplacements vacants"
Je peux terminer avec 2 classes, ParkingLot et Slot ou je pourrais continuer en ajoutant IVehicle et Vehicle et Car et Motorcycle classes. Où dois-je tracer la ligne?
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; }
}
Dans une certaine mesure, oui. Tout le monde peut réciter la syntaxe ou copier/coller son chemin à travers une solution. Nous voulons embaucher des gens capables de résoudre des problèmes.
Ils s'attendent à ce que vous documentiez suffisamment la conception pour qu'ils puissent la comprendre (et pas plus que cela).
Je demande aux gens comment ils résoudraient le problème XYZ, oui. Habituellement, ils le décrivent verbalement. Je veux voir s'ils posent des questions pour clarifier les exigences. Je veux voir comment ils communiquent avec d'autres programmeurs. Je veux voir s'ils peuvent penser debout.
Cela m'a été utile. Je ne veux pas de singes codés, je veux des ingénieurs logiciels.
Je trouve ces questions plutôt stupides. La vraie réponse est "quels sont les cas d'utilisation?" Sans cas d'utilisation, aucune conception n'est nécessaire. Par exemple, voici une réponse parfaitement raisonnable à la question du parking:
class ParkingLot {
boolean isFull();
void carEntered();
void carExited();
}
Il satisfait un cas d'utilisation évident.
Vous démontrez en fait une utilisation de cette question dans votre édition, où vous ne parvenez pas à concevoir un modèle réalisable.
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!??
Vous mentionnez également la création de classes Car et Motorcycle, ce qui n'a pas beaucoup de sens sans plus de considération. Votre conception ne bénéficiera d'aucune sous-classe Vehicle. Si vous introduisez Motorcycle sans aucune différence de comportement dans Vehicle, je considérerais cela comme un échec.
Si vous n'avez pas repéré le seul problème de Vehicle, alors nous ferions à peu près une interview en direct. Si vous avez corrigé cela (éventuellement en faisant un List<IVehicle>), Je l'utiliserais comme point de départ pour regarder l'évolution de votre conception. Il y a une raison pour laquelle les exigences sont basiques, et il n'y a pas de cas d'utilisation bien définis - c'est à peu près la façon dont le monde fonctionne.
Je pourrais vous lancer la nouvelle exigence selon laquelle "deux motos peuvent se garer dans un emplacement" pour voir comment vous évolueriez votre conception pour la gérer. Alors peut-être que nous aurons une conversation sur la concurrence (Et si nous avons deux entrées et deux voitures s'arrêtent simultanément - votre conception échouera-t-elle? Comment? Que pouvons-nous faire pour y remédier?). D'autres voies possibles à explorer seraient de savoir comment mettre en œuvre le stationnement assigné, facturer le stationnement, les taux par rangée (peut-être que les rangées plus proches doivent payer plus), le stationnement limité dans le temps et comment trouver les délinquants, etc., etc.
Je considérerais également votre réflexion sur les parkings comme une indication de votre capacité générale à analyser intelligemment un problème. Si vous devez me demander des cas d'utilisation de base et/ou trouver des cas excentriques (comme des offres spéciales 2 pour 1 sur le stationnement), je commence à m'inquiéter fortement que vous n'ayez jamais réellement utilisé un parking avant et que nous sommes va avoir du mal à communiquer sur quelque chose de légèrement compliqué.
J'avais l'habitude de les demander - en arrière lorsque nous avons créé des diagrammes de classes pour la génération de code. Je le fais encore à l'occasion, mais pas régulièrement. J'aime la question car elle me permet de voir la personne réfléchir.
Il est destiné à être ouvert. C'est bon. Il n'y a pas de bonne réponse. Je n'ai pas de réponse en tête; Je veux voir où ça mène. Je pense que c'est une meilleure question à poser en personne, pas un "e-mail en réponse". Il s'agit de communication, d'hypothèses et d'interaction; pas seulement une réponse!
J'ai vu ce type d'interviews il y a au moins 12 ans. C'est l'approche que j'utilise depuis 6 ans. L'expérience montre qu'il sélectionne de meilleurs candidats pour le poste que de poser 20 questions et de leur attribuer une note sur 20.
Encore une fois, je le rendrais très ouvert aussi. L'objectif est de fournir un espace au candidat pour démontrer sa capacité. Avoir un candidat qui a posé des questions pertinentes à ce stade serait un plus. Tout comme un candidat faisant de bonnes hypothèses, mais signalant qu'il s'agissait d'hypothèses, et qu'elles devraient être examinées avant la mise en œuvre.
Je demande à tous les employés potentiels de démontrer les compétences dont ils ont besoin pour le travail lors de l'entretien. Pour les programmeurs, ils devront implémenter du code et parler de leur conception pour cela. Il est très efficace pour prévenir les mauvaises embauches, mais soyez prêt à un taux d'échec de 90% lors de l'entretien.
La conception d'un petit système est en fait un exercice très pertinent à poser lors d'un entretien. Il montre vos compétences pour trouver une bonne solution logicielle à un problème de domaine.
Cependant, je trouve étrange de simplement demander à publier un diagramme de classe en ligne sans interaction humaine:
- Ils manqueront l'essentiel - le raisonnement derrière le diagramme et ce qui vous a amené à concevoir les choses de cette façon.
- Il n'y a pas de "parapet" pour empêcher le demandeur d'aller trop loin. Si vous reflétez une implémentation finale dans le diagramme, vous aurez probablement des dizaines de classes et un schéma illisible.
- Être capable de dessiner un diagramme de classe UML n'est pas vraiment une compétence essentielle, c'est juste une notation OO entre autres. La capacité de créer des designs solides l'est.
Dans une interview en direct, les étapes idéales que j'attendrais d'un candidat seraient:
- Discutez du problème avec le recruteur et commencez à exprimer verbalement une solution de base, posez des questions et ajustez-le lorsque le recruteur donne des besoins plus précis.
- Levez-vous et esquissez une vue d'ensemble du système et de la façon dont les composants peuvent interagir ensemble. Peut-être le style UML le plus pur, peut-être juste des boîtes et des cercles.
- Rédigez un test, soit un test d'acceptation de haut niveau ou un test unitaire pour l'un des composants/classes.
- Commencez à écrire l'implémentation correspondante.
Espérons qu'à un moment donné, le recruteur aura rassemblé suffisamment d'informations sur les compétences du candidat et l'appellera un jour. Le but n'est pas de mettre en œuvre une solution de travail complète (sauf s'il s'agit de l'un de ces services non rémunérés lors d'entretiens déguisés).
Les questions OOP sont ouvertes. Il n'y a pas de bonne ou de mauvaise réponse, mais il y a certains principes que les enquêteurs s'attendent à voir (comme utiliser un constructeur pour initialiser des variables, garder vos méthodes petites, utiliser encapsulation/composition/polymorphisme/héritage le cas échéant, etc.).
Attendez-vous toujours à des questions sur la structure des données, la POO et la base de données dans les entretiens, elles sont très courantes. Des livres comme "cracker l'interview de codage" et "interviews de programmation exposées" peuvent vous aider à vous préparer.