À quoi devrait ressembler mon «exemple de code»? [fermé]

Je viens d'avoir une assez bonne interview téléphonique (pour un poste lié à CakePHP, pas que ce soit particulièrement important pour la question). L'intervieweur a semblé impressionné par mon curriculum vitae et ma personnalité. À la fin, cependant, il m'a demandé de lui envoyer un échantillon de code de mon projet de travail actuel, "pour vérifier que vous n'êtes pas secrètement un mauvais programmeur, ha ha!"

Je ne suis pas trop inquiet que mon code ne puisse pas se débrouiller seul, mais je suis vraiment un programmeur intermédiaire plutôt qu'un expert. Quels pièges évidents devrais-je m'assurer que mon exemple de code ne tombe pas , au cas où ils m'excluraient sur le champ? Deuxièmement, et c'est probablement la partie la plus difficile de la question à répondre, quelles fonctionnalités d'un exemple de code seraient si impressionnantes qu'elles vous rendraient instantanément beaucoup plus favorable au programmeur?

Toutes les idées ou suggestions sont les bienvenues!

J'aimerais voir du code propre :

Code propre : code logiciel formaté correctement et de manière organisée afin qu'un autre codeur puisse facilement le lire ou le modifier.

Cela signifie:

• Fonctionnalité - Quelques fonctionnalités simples qui ne sont pas triviales (un groupe de getters / setters ne montrerait pas que vous savez quoi que ce soit)
• Style cohérent et propre - styles de boîtier, d'indentation, d'espacement et de support populaires ou au moins courants
• Bonne dénomination - Noms de qualité - ne pas utiliser isauf s'il s'agit de la seule valeur d'incrémentation. N'utilisez pas de noms de variables absurdes.
• Autres attributs du code propre - Bonnes pratiques sur la vérification des erreurs, les conditions, les boucles, les méthodes de commodité ou les méthodes utilitaires, et bonne séparation des préoccupations (entre les méthodes). Et c'est le bon moment pour être 100% SEC - pas de répétition!

Vous voulez leur envoyer quelque chose qui est suffisamment complexe pour être intéressant mais suffisamment propre pour qu'un bon développeur puisse presque immédiatement comprendre ce qu'il fait.

Certains des commentaires ci-dessus semblent préoccupés par la facilité avec laquelle cela peut être truqué. * Si vous souhaitez vous protéger contre cela, envoyez éventuellement une description rapide de l'objectif et de l'historique du code dans l'e-mail.

^{* Au moins si l'intervieweur a demandé sur les projets passés à l' avant, alors vous avez demandé un échantillon de ce projet, et a demandé à ce que vous nécessaire de l' écrire ou comment il a évolué, je pense que le processus serait assez menteur à l' épreuve. Je pense que la plupart des candidats qui serait mentir vont montrer des problèmes dans d' autres domaines, de toute façon.}

Quand je cherchais du travail, j'ai résolu un tas de questions du concours de programmation ACM, dans plusieurs langues différentes, et les utiliser depuis pour des exemples de code. Je pense qu'ils ont fait de bons exemples de code parce que:

• Ils ont résolu des problèmes difficiles
• Le problème ne nécessitait pas une énorme quantité de contexte, plus il est facile d'obtenir les questions
• Le code écrit n'a aucun risque IP associé.
• Chaque problème peut raisonnablement exister dans un seul fichier, et souvent pas extrêmement long, il devrait donc être facile pour quiconque de compiler et de tester votre solution et d'utiliser les données de test des questions.
• Montre que vous pouvez décomposer un problème complexe en petits morceaux.
• Si l'on vous demande comment fonctionnent les aspects de votre solution, cela vous donne une excellente occasion de démontrer que vous savez de quoi vous parlez, surtout si elle date de plusieurs années mais que vous pouvez rapidement déchiffrer ce qui se passe.

Et puis, le code que vous créez doit être clair, cohérent, facile à lire et facile à comprendre.

Et enfin:

• Cela vaut la peine de les résoudre juste pour le plaisir, et c'est une bonne pratique.

• Il doit compiler / interpréter sans erreur ni avertissement au plus haut niveau de rigueur.
• Ce ne doit pas être du code standard que vous écrivez tous les jours. Rendez-le unique et intéressant, il est donc évident que vous ne l'avez pas copié / collé.
• Il devrait avoir des décisions de conception intéressantes avec des commentaires expliquant comment / pourquoi vous les avez prises.
• Ne visez pas plus de 2-3 pages imprimées.
• Il devrait être dans la langue pour laquelle vous postulez.
• Cela ne devrait pas me faire mal au cerveau quand je l'ai lu la première fois. Demandez à un ami de l'examiner ou de publier sur la révision du code.

Eh bien, si je vous interviewais, j'aimerais voir votre code.

Nettoyer c'est bien, résoudre des problèmes c'est bien, mais le vrai code c'est mieux. Un bon programmeur sait quand il / elle a été victime d'une arnaque par un autre programmeur, donc la confiance pourrait baisser.

Lire le code d'une autre personne, c'est comme danser en ayant des relations sexuelles: vous savez quand c'est la vraie chose, et si l'autre la simule, à la fin une catastrophe se produira. (Je viens de réaliser que les vrais nerds ne savent pas danser)

Ayez confiance en vous et en vos capacités de codage . À moins que vous ne connaissiez vraiment votre interlocuteur, vous ne pouvez pas anticiper ce qu'il attend de votre style / compétences de codage.

Faites également très attention à ce que ce ne soit PAS du code de votre employeur actuel (ils le possèdent, vous ne le possédez pas et je vous garantis qu'ils n'aimeront pas que vous le partagiez.). Prenez quelque chose dont vous êtes fier et retravaillez-le par vous-même pour ne pas être spécifique à l'employeur (supprimez toutes les références à leurs tables de base de données ou noms de serveurs, etc.). Quoi que vous fassiez, ne soumettez pas de code comportant des erreurs ou une mauvaise technique pour le type de code (je rejetterais probablement quelqu'un qui a soumis un curseur lorsqu'une opération basée sur un ensemble serait plus simple et plus performante lors de l'examen du code SQL. Il existe des techniques similaires pour d'autres langues qui sont là pour résoudre un problème relativement rare qui peut être utilisé pour d'autres problèmes plus courants, mais qui ne sont pas le meilleur choix pour ces autres problèmes. Cette phrase avait-elle du sens?)

J'appuierais le post de Renesis sur le code propre, mais ajouterais à la liste fournissant des tests unitaires de qualité et bien documentés au code que vous soumettez. Un bon programmeur devrait écrire des tests unitaires pour leur code.

Comme une opinion de quelqu'un qui demande des échantillons de code lors de l'évaluation des candidats, il existe quelques fonctionnalités de haut niveau (contenu du code) et quelques fonctionnalités de bas niveau (structure du code). Caractéristiques de haut niveau:

1. Identité : la saveur du code. Si vous vous présentez comme un codeur UI / HCI, je veux voir une bonne apparence pour quelque chose de visuel lorsque je l'exécute. Si vous êtes un constructeur de bases de données, je veux voir quelque chose d'intéressant avec la représentation ou l'analyse des données. L'échantillon devrait être quelque chose dont vous êtes fier . Si vous n'en avez pas au moins un, vous n'avez pas d'identité.
2. Maturité : changez -vous de stratégie pour différents problèmes? Résolvez-vous des problèmes intéressants? Serait-il facile d'étendre le code ou l'approche à un problème similaire? À l'inverse, ai-je l'impression de regarder un membre d'une commune culte cargaison?
3. Communication : le code explique-t-il facilement ce qu'il fait et pourquoi? Cela ne signifie pas que le code doit être simple. En fait, c'est un bonus de rendre le code complexe facile à comprendre.

Les aspects de bas niveau sont plus simples:

1. Style : Le code doit être propre, cohérent (suit certaines directives établies) et bien documenté.
2. Empaquetage : Il devrait y avoir au minimum un fichier Readme court, une version exécutable et des tests exécutables. Le fichier Lisezmoi devrait me dire comment exécuter les deux derniers, ainsi que pourquoi vous démontrez cet exemple de code particulier.
3. Langue (s) : Je demande généralement à quelqu'un un échantillon dans la langue du poste, ainsi que celui dans lequel il se sent le plus fort. Donne une bonne idée des plafonds actuels d'une personne.

Pour un bon candidat, je m'attends à ce qu'un échantillon soit: A) Un petit échantillon à l'épreuve des balles ou B) Une bonne partie d'un projet intéressant plus vaste (par exemple, un module d'un dépôt personnel Github). Je m'attends à ce que ce soient des projets personnels ou des projets académiques. S'ils en envoient un à partir d'un projet rémunéré, j'attends une note qu'ils ont été autorisés à l'utiliser. Si je ne reçois pas cette note, je vais les couper des candidats (candidat faible) ou les interroger lors de l'entretien (candidat fort). Ne pas avoir l'autorisation serait un grand drapeau rouge (probablement insurmontable). Pour un candidat avancé, je m'attends à un avertissement notant que certains de leurs meilleurs échantillons source ne peuvent pas être affichés car cela a été fait dans le cadre de leur travail. Cependant, je m'attends alors à un témoignage jaillissant de la raison pour laquelle ils sont fiers de ce design non montrable et comment ils l'aiment comme un enfant.

Enfin, autant que certains disent que "Oh, quelqu'un pourrait simplement obtenir un échantillon de code sur Internet", le contre-argument est que la plupart des gens qui ne comprennent pas un bon code de qualité de production ne le comprennent pas non plus lorsqu'ils le voient. . En outre, on peut toujours Google une ligne distinctive pour le code à vérifier. De plus, au mieux, le vol de code amènera un candidat à une entrevue où il s'embarrassera ("Alors pourquoi l'avez-vous fait de cette façon ...?").

Une dernière note sur le code de l'emploi précédent: tout simplement pas. Du point de vue des ressources humaines, demander le code d'un emploi précédent est inapproprié et un drapeau rouge sur l'entreprise. Vous auriez tous deux une responsabilité légale (c'est-à-dire que vous pourriez tous deux être poursuivis) et cela montre qu'ils n'ont aucune idée de ce qu'ils font. Le code fait pour un employeur précédent ne doit jamais être donné, sauf si le code est déjà accessible au public ou si vous avez l'autorisation explicite de cet employeur. Pire, dans une grande entreprise, votre patron direct peut ne pas avoir le pouvoir de vous donner la permission, alors amusez-vous avec le service juridique dans ce cas? Je suis sûr qu'ils seront ravis d'exposer leur adresse IP pour un employé sortant.