Récemment, en raison de mon travail, il m'est arrivé de sélectionner des stagiaires dans notre entreprise. Quiconque se souvient de ce que c'est que d'être stagiaire / junior doit se rappeler à quel point il est difficile de rester coincé dans un endroit plus ou moins normal sans expérience, où il dépensera des ressources pour votre formation. Étant donné que le flux de développeurs novices est très important, l'employeur a la possibilité de choisir parmi ce flux sinon le meilleur, puis au moins les gars prometteurs et sensés qui valent la peine de consacrer du temps à la formation afin de les employer plus tard.
Chaque entreprise a sa propre méthodologie pour trouver de tels candidats. Aujourd'hui, nous adhérons à ce qui suit: nous donnons une petite tâche de test (environ une heure de travail, pour un développeur expérimenté), pour laquelle les connaissances Java-core sont suffisantes et demandons de la mettre sur un github. Nous ne limitons pas le temps d'exécution. Ensuite, remplissant qualitativement la tâche, les candidats sont invités à un entretien.
Une tâche contient généralement une implémentation des méthodes CRUD dans un fichier via un
menu de console avec une ou deux entités plus la validation de certains champs. À titre d'exemple, je vais donner une situation classique avec un utilisateur qui doit implémenter la validation de l'e-mail et du téléphone selon un modèle donné et pour cela, il peut entrer de 1 à 3 téléphones. Il y a beaucoup de réponses, et il y a très peu d'endroits - en conséquence, la sélection est assez difficile.
En commençant à vérifier toutes les tâches d'affilée, il s'est avéré qu'il fallait environ 30 minutes pour tester les performances avec le lancement et le retour de chaque tâche, j'ai dû réviser la méthodologie de vérification et dériver des critères pour filtrer rapidement le code de qualité insuffisamment élevée. Par exemple, en ouvrant une solution sur un github, je vois que tout le code est concentré dans plusieurs classes et même empilé dans un seul paquet - un échec rapide (qu'en est-il des principes de la POO?).
Beaucoup peuvent trouver cette approche injuste, pour dire que le problème est résolu, le code fonctionne, mais la vie du stagiaire et du junior est dure et sans merci.
À cet égard, je propose ma liste de recommandations pour terminer la tâche de test
- Votre décision doit fonctionner conformément aux TdR
Suivez attentivement les exigences énoncées dans les conditions de résolution du problème. Ne réfléchissez pas à vos champs dans les entités, ne modifiez pas les conditions de validation, etc. et ainsi de suite. Cela montre à quel point vous êtes attentif aux détails, ce qui est très important pour le développeur. - Vérifiez soigneusement la tâche terminée
Terminé la tâche - vérifiez les performances. Tout d'abord, les fonctionnalités principales décrites dans les TdR, puis supplémentaires. Essayez de «casser» votre application: vérifiez ou saisissez l'application de manière adéquate à la tâche, si vous entrez des données invalides, les données sont aussi similaires que possible. N'oubliez pas de réparer tout ce que vous trouvez. - Encodage
Tous les fichiers doivent être dans le même encodage, à mon avis en UTF-8. Configurez votre IDE pour cela. N'oubliez pas que si vous avez Windows, le réviseur peut avoir Linux, et des squats supplémentaires avec encodage sont une perte de temps pour le réviseur. - Ne pas commettre en une seule validation
Vous devez vous engager lorsque vous résolvez votre problème, ajouter des descriptions claires aux validations. Si vous connaissez l'anglais, c'est mieux en anglais. Cela indique indirectement que vous n'avez pas simplement fusionné la solution de quelqu'un d'autre à partir du git, mais que vous avez écrit le code vous-même. - Essayez de ne pas fusionner les décisions des autres
Étant donné que vous réclamez le maximum pour juin, le plus souvent, vous n'avez toujours pas assez d'expérience pour utiliser le code de quelqu'un d'autre. Les conditions de la tâche peuvent varier légèrement et lorsque vous copiez simplement la solution de quelqu'un d'autre, elle peut déjà être légèrement décalée par rapport à la tâche en cours. Et la tâche doit être terminée exactement avec la tâche (voir P1). - Ajouter un fichier readme
Ajoutez le fichier readme.md à la racine du projet. Décrivez brièvement votre application, fournissez des explications supplémentaires pour le lancement, si nécessaire. Si d'autres tâches sont déjà terminées, ajoutez-y également un fichier Lisez-moi. Par exemple, si je suis intéressé par un candidat, je peux voir son autre code. Et si vous n'y allez pas, vous pouvez également joindre ce code à votre CV. - Faites un menu pratique
L'application doit être conviviale. N'oubliez pas que le temps de vérification est souvent limité, donc préchargez l'application avec des données, ajoutez une méthode pour afficher toutes les entités (qui est là dans les conditions). La navigation dans les menus doit être pratique, par exemple en utilisant des chiffres. Et parfois, ils l'implémentent de telle manière que pour supprimer une entité, vous devez entrer «Supprimer» dans la console. Cependant, on ne peut pas en faire trop et dépasser le cadre des savoirs traditionnels. - Faites de votre mieux.
Puisque vous avez décidé de réaliser la tâche de test, approchez sa solution avec un rendement maximum. Même si la tâche semble triviale et simple, vous n'avez pas besoin d'approcher sa solution de manière formelle et d'écrire du code à genoux. Et si vous n'allez pas dans cette entreprise, alors vous aurez une solution complète sur le github, ce qui est pratique. - N'oubliez pas les principes de la POO
Qu'il vous semble qu'une petite tâche, n'oubliez pas - la tâche est un test, et java est principalement un langage orienté objet. Et ils examineront non seulement l'opérabilité de l'application, mais aussi le code. La qualité du code est un élément très important de la solution . N'écrivez pas de code spaghetti. Mettez tout dans les classes, les packages. Créez des interfaces si nécessaire, effectuez des transferts vers ENUM , si nécessaire. - Essayez d'utiliser des modèles de conception
Une application réussie d'au moins un modèle de conception montrera que vous avez un concept sur les modèles de conception (ou non). Juste avant d'appliquer tel ou tel schéma - découvrez ce qu'est l'idée, comment elle devrait fonctionner et pourquoi elle a été inventée. Si je vois des modèles dans le code, alors lors de l'entretien, je peux poser une question sur le modèle appliqué. - Utiliser les ressources
Il est préférable de prendre tous les messages affichés à l'utilisateur dans les ressources et à partir de là . Cela montrera au réviseur que vous savez comment travailler avec les ressources et comprendre à quoi elles sont utilisées. Les messages sont mieux affichés en anglais. - N'oubliez pas de redéfinir où est égal à & hashcode est
- Utilisez des fonctionnalités java8 + comme les expressions lambda, les flux
N'oubliez pas que le plus souvent, les collections sont plus pratiques qu'un tableau. Si le choix est tombé en faveur des collections, utilisez les bonnes collections. Vous devez être prêt à l'entretien pour justifier votre choix en faveur d'une collection ou d'un ensemble particulier. - Les tests
Si vous le pouvez, écrivez des tests, mais c'est déjà cinq avec quelques avantages. Souvent, il est entendu que tout bon code est généralement couvert par des tests. Bien que pour la tâche donnée dans l'exemple, l'absence de tests ne sera pas un inconvénient, car il s'agit d'une application console simple pour connaître le noyau Java.
Résumé
Une grande moitié des candidats envoient une solution au problème sans erreur et un code solide - des unités qui passent par la sélection naturelle et tombent dans le tour suivant. Tous les artistes reçoivent des commentaires. Ceux qui ont écrit un code solide qui est venu de lancer - une rétroaction personnelle, ceux qui ont envoyé des spaghettis écrits à genoux - sont plus généralisés.
PS: J'espère que mes conseils vous aideront, chers candidats, à mieux effectuer vos tâches de test, et moins susceptibles de pleurer les testeurs avec des larmes sanglantes. Bonne chance dans votre recherche et un bon point de départ!