"Embaucher uniquement les meilleurs" est-il un conseil vraiment pratique pour la programmation d'une application de bureau normale?
Pour le fond, nous faisons des applications d'ingénierie de bureau, avec une AutoCAD comme UI, quelque chose de similaire à etabs .
Une chose qui me dérange vraiment, est-il nécessaire d'embaucher les meilleurs développeurs? Pour commencer, nous éprouvons de grandes difficultés de recrutement; la plupart des CV que nous voyons font soit de simples applications CRUD, soit une personnalisation de SharePoint qui, je ne pense pas, implique vraiment beaucoup de programmation hardcore. Même ceux que nous appelons pour une entrevue, la plupart ne peuvent pas faire la séquence de Fibonacci et une simple recherche binaire, et nous sommes assez aimables pour donner des indices et énoncer explicitement les problèmes afin que les candidats n'aient pas à rechercher un dictionnaire pour vérifier ce que signifie "séquence de Fibonacci".
Cela m'a fait penser: oui, nous avons besoin d'un certain niveau d'aptitude à la programmation lors de la géométrie computationnelle/de la programmation linéaire, et nous avons besoin d'un certain niveau d'aptitude à la programmation lors de la conception de l'architecture logicielle/ou de la décision du modèle logiciel à utiliser, mais au-delà de cela , beaucoup de notre code n'est que du code de plomberie (je pense), ce qui peut être fait par quelqu'un avec une certaine familiarité avec la programmation.
Étant donné que nous avons vraiment besoin de talents en programmation maintenant, et étant donné que l'embauche de développeurs de superstars est très difficile, je veux abaisser mon niveau et n'embaucher que des so-so, en contradiction directe avec ce que Joel prêche .
Qu'est-ce que tu penses?
Edit: Vous n'avez pas besoin de réécrire l'ensemble des bibliothèques de géométrie de calcul/programmation linéaire; tout ce que vous devez faire, en ce qui concerne mon application, est de savoir comment transposer les problèmes en termes de programmation géométrique/linéaire de calcul appropriés et savoir quand/comment utiliser les bibliothèques existantes. Ce n'est donc pas aussi difficile qu'il y paraît.
Je vous suggère d'arrêter trop de lire Joel. Ce qu'il a écrit dans son blog contredit ses réponses sur ce site, donc je ne prendrais pas vraiment sa Parole pour beaucoup.
Ce qui fait une superstar et pourquoi il est nécessaire d'en avoir une ouvre une discussion longue et nulle part. C'est de l'élitisme et ce n'est pas pratique.
Ce dont vous avez besoin, c'est d'une personne qui:
- J'adorerais faire ce que vous faites
- Serait un programmeur passionné et enthousiaste
- Aurait le potentiel d'apprendre ce qu'il faut pour bien faire votre travail
Le reste est sans importance.
Vous ne croiriez pas combien de jeunes diplômés sont là-bas qui ne veulent rien d'autre que de plonger dans ce genre de projet CS-fort et ne jamais regarder le codage des applications CRUD. Il y a quelque temps, j'étais l'un d'eux, je rêvais pratiquement de rejoindre un projet autour du développement de compilateurs, mais je n'ai pas pu en trouver un. Pourquoi ne pas donner une chance à l'un d'eux?
Je ne pense pas qu'AutoCAD a été écrit par des surhommes. La plupart des projets réussis ont été réalisés par des gens qui voulaient simplement faire avancer les choses et ils le voulaient vraiment.
la plupart des CV que nous voyons font des applications CRUD simples ou une personnalisation de SharePoint
À quoi s'attendre si la plupart des emplois ne nécessitent que cela? Les gens ont peut-être étudié le CS à l'université et ont même été vraiment bons dans ce domaine, mais vous ne pouvez pas vous attendre à ce qu'ils s'en souviennent s'ils n'ont jamais utilisé cela dans la programmation pratique en 10 ans. De toute évidence, personne ne lira tous les ans de vieux livres CS juste pour le garder à jour si ces connaissances ne sont utilisées nulle part.
Un livre que j'aime vraiment est Brisez d'abord toutes les règles . Il contient beaucoup d'informations sur les différences entre les gestionnaires moyens et les bons gestionnaires. L'un des points clés que les bons managers ont répété à maintes reprises a été résumé par l'un d'eux dans la phrase, Je n'ai jamais attendu trop longtemps pour trouver la bonne embauche, et j'ai n'a jamais tiré la mauvaise embauche assez rapidement. Oui, il est frustrant de prendre beaucoup de temps à embaucher, mais cela en vaut la peine.
Un deuxième point que vous devez garder à l'esprit est que lorsqu'il est mesuré sur le débit du projet, il y a un pic de productivité pour des équipes de 5 à 8 personnes. Vous ne retrouverez pas la même productivité avant d'avoir une équipe de plus de 20 personnes. Soyez très, très prudent sur la croissance d'une équipe au-delà de la taille où la dynamique de petite équipe fonctionne. Et si vous allez rester en dessous de ce seuil, alors vous voulez vraiment que ces 5-8 personnes soient bonnes.
Les deux points parlent fortement de la tenue de la bonne location.
Tout le monde prétend "n'embaucher que le premier centile". Si tel était le cas, 100% des personnes occupées seraient toutes dans le "1 centile supérieur" de toutes les personnes, de sorte que 99% de toutes les personnes seraient sans emploi (dans n'importe quel domaine). Comme ce n'est clairement pas le cas, et nous avons tous des gens expérimentés qui ne sont clairement pas dans ce groupe (pourquoi sinon posez-vous cette question du tout ...), nous savons que ce n'est pas vrai.
En fait, les organisations composées uniquement de ces personnes seraient très instables. Trop d'ego, trop d'idées contradictoires. Cela s'effondrerait alors que tout le monde fait son propre truc, s'enliserait dans des discussions théoriques sans fin sur les mérites relatifs de tout, ou évoluerait en un cri de constance tandis que les sentiments s'embrasent chaque fois qu'une décision doit être prise.
La première chose que vous devez demander est pourquoi vous obtenez des CV qui ne sont pas conformes aux normes que vous souhaitez. J'ai travaillé avec beaucoup de bonnes personnes, donc elles sont là-bas, et l'application me semble très intéressante. Si vous ne pouvez pas trouver de personnes capables de faire des séquences de Fibonacci et une recherche binaire (ce qui est plus difficile qu'il n'y paraît; selon Knuth, il a fallu plusieurs années entre sa première publication et sa première publication correcte), vous faites quelque chose pour bons loin.
Demandez-vous plus de compétences que ce que vous êtes prêt à payer? Faites-vous de la publicité aux mauvais endroits? Votre entreprise est-elle peu attrayante par son emplacement ou sa réputation? C'est votre premier et le plus fondamental problème, et celui que vous devez résoudre de toute urgence. Vous et vos collègues connaissez sans doute de bonnes personnes qui ne travaillent pas pour vous. Montrez-leur ce que vous avez et demandez-leur s'ils seraient tentés et sinon pourquoi. Vous pouvez être trop près du problème pour le comprendre sans aide.
N'embauchez pas de gens parce qu'ils sont les meilleurs qui s'appliquent. Embauchez des gens car ils pourront faire quelque chose que vous voulez faire. Si vous embauchez médiocre parce que c'est tout ce qui s'applique, alors vous allez lentement perdre de bonnes personnes et vous allez vous retrouver avec des gens dont l'algèbre est fragile en essayant de faire des choses avec la géométrie informatique. (Embaucher des médiocres parce que vous avez un travail pour quelques programmeurs médiocres est une autre chose, mais vous devez être en mesure d'embaucher des personnes de qualité là où vous en avez besoin.)
"la plupart ne peuvent pas faire la séquence de Fibonacci et une simple recherche binaire"
Vos critères sont certainement faux. Dans mon groupe, nous sommes tous physiciens ou ingénieurs. Je parie que personne ne pourrait faire de recherche binaire car nous n'avons pas suivi de cours CS et dans la vraie vie nous utilisons une bibliothèque pour cela. Je dirais même: quelqu'un qui écrit lui-même la recherche de résultat ne sait pas se concentrer sur des choses importantes.
Cela est beaucoup plus important si le candidat est intelligent et s'intègre dans le groupe. Si vous voulez vérifier son talent en programmation, donnez-lui un travail à faire à la maison. Notez le temps qu'il lui a fallu et discutez des résultats pour savoir s'il s'agit d'un véritable travail.
Je pense que "recruter les meilleurs" devient trop culte.
La plupart des travaux de programmation sont routiniers et non créatifs. Même lorsque vous travaillez sur de nouveaux projets vraiment créatifs. La plupart d'entre eux sont banals et souvent basés sur des modèles. cela est particulièrement vrai pour l'interface utilisateur.
La plupart des systèmes modernes nécessitent également tellement de personnes pour les écrire que, par nature, ils ne peuvent pas tous être les meilleurs. La plupart des gens sont moyens, même s'ils ne le sont pas, ils doivent encore faire beaucoup de tâches "moyennes".
Cela étant dit, exiger des compétences de base et des exigences raisonnables minimales n'est pas déraisonnable et ce n'est pas quelque chose sur lequel vous devriez faire des compromis.
Pensez à la chirurgie de routine: selon votre tolérance au risque, vous préféreriez probablement qu'un médecin moyen l'exécute plutôt que d'attendre 10 ans que le doyen de la faculté de médecine ait le temps de le faire. Cela ne signifie pas que vous devez laisser l'ordonnanceur effectuer la chirurgie.
"Embaucher les meilleurs" signifie généralement "embaucher les meilleurs qui sont actuellement disponibles à peu près là où nous sommes" et signifie différentes choses pour différentes entreprises. Certains veulent des codeurs rockstar, d'autres veulent des ingénieurs logiciels méticuleux et le suivant veut des artisans expérimentés. Il n'y a pas de "meilleur universel", alors gardez cela à l'esprit, et peut-être que vos spécifications d'emploi suggèrent que vous recherchez un type de programmeur et l'interview indique que vous recherchez un autre type de programmeur. Soudain, vous n'obtenez pas de matchs.
Cela dit, je n'aime pas travailler avec des programmeurs. So-so n'a rien à voir avec l'expérience (ils ont peut-être programmé pendant 20 ans et ne sont toujours pas très bons dans ce domaine), mais tout à voir avec des aptitudes et de l'enthousiasme. Si le so-so affecte l'un de ces deux, vous avez un problème. Il est également inutile d'embaucher quelqu'un dont les contributions doivent être retravaillées par d'autres membres de l'équipe car leur code n'est pas assez bon. Plus de clochards sur les sièges ne sont pas toujours dans la réponse, plus de clochards sur les sièges peuvent malheureusement aussi signifier plus de travail pour les meilleurs membres de l'équipe alors qu'ils essaient de faire leur travail et nettoyer le gâchis le programmeur moyen a livré.
Certaines personnes ne se présentent pas comme des rockstars, mais sont de solides programmeurs de niveau intermédiaire. Ils sont bons à avoir dans l'équipe et ce n'est pas ce que je veux dire avec "so-so programmer". Ce dernier est quelqu'un qui évite à peine de se faire licencier chaque année au moment de l'examen des performances.
En tant que type Manager, j'accepte que l'embauche du "top 1%" ne soit pas pratique et n'est pas nécessaire. Mon conseil serait d'embaucher la bonne équipe pour construire et maintenir votre produit (il pourrait s'agir de deux équipes très différentes, car la construction et la maintenance sont très différentes dans leurs besoins)
Je vous suggère fortement d'identifier les personnes que vous avez actuellement dans votre équipe qui sont des "personnes clés" (par exemple, faire avancer les choses, avoir de bonnes attitudes, bien travailler avec des incertitudes/exigences de haut niveau, etc.), puis embaucher des personnes qu'elles ont travaillé avec dans le passé (et respect, évidemment). Cela élimine beaucoup d'incertitude autour du processus d'entrevue et aide à geler l'équipe.
En outre, à plus long terme, investissez massivement dans un programme de stage. Si votre équipe de programmation est de 20 personnes, obtenez 5 stagiaires par an et donnez-leur du vrai travail. Ramenez la ou les deux que vous aimez chaque année et introduisez 5 autres variables aléatoires. C'est probablement le meilleur moyen de garder votre équipe remplie de bons programmeurs. Vous pouvez ensuite embaucher à l'extérieur de façon opportuniste et élever la barre pour ces candidats.
Comme cela a déjà été mentionné, faites attention à votre processus d'entrevue. Demandez aux candidats d'écrire du code (ou mieux, expliquez leur solution à un problème de "1 heure à emporter"), faites-leur déjeuner avec l'équipe. Apprenez à connaître leurs compétences techniques et interpersonnelles. Et n'ayez jamais peur de dire "non" même lorsque vous avez désespérément besoin de 20 personnes de plus pour un grand projet qui démarre la semaine prochaine.
D'après mon expérience, le principe de Paretto s'applique également à la programmation: 80% du travail est accompli par 20% des développeurs et vice versa. OK, les chiffres peuvent être exagérés. En réalité, vous aurez quelque chose comme 20% des employés qui font 50% du travail (par travail, je veux dire du bon travail, pas seulement des lignes de code). C'est en fait plus comme une courbe en cloche. Donc, dans une équipe de 10, vous aurez 1 héros, 2 grands gars, 4 moyens et 2-3 pathétiques.
De nombreuses entreprises utilisent la courbe de Bell pour peser les évaluations. Donc, peu importe à quel point vos candidats sont brillants, ils tomberont dans leurs niveaux. Vous ne pouvez pas avoir une équipe où tout le monde est au même niveau. Ça n'arrive pas.
Il y a déjà un tas de réponses ici, mais je pense qu'il y a encore un point à discuter: l'impact que l'embauche des gars a sur la qualité de votre logiciel et comment cela rend votre vie de gestionnaire beaucoup plus difficile.
La réponse à "est-il nécessaire d'embaucher les meilleurs développeurs?" est toujours un gros OUI gras. Bien sûr, en réalité, ce n'est pas toujours possible. La dangereuse erreur que je pense que vous faites en considérant cette question est de penser que "notre logiciel est si simple même un gars moyen peut le faire". C'est faux.
Votre logiciel sera fait, n'en doutez pas, mais attendez-vous à des résultats très différents d'une excellente équipe et d'une équipe moyenne. Vous aurez plus de bogues, plus de problèmes de performances, plus de problèmes de maintenabilité et d'évolutivité, etc. Vous devrez garder vos so-so gars à travers des problèmes plus complexes. Vous devrez garder les gars comme ça par des décisions d'architecture appropriées.
Si vous l'acceptez et êtes prêt à gérer cela, c'est ok. Soyez juste prêt pour le processus et pour les résultats.
Le titre de votre question mentionne une "application de bureau normale", mais votre texte parle de la nécessité d'appliquer des connaissances en géométrie de calcul et en programmation linéaire. Ce sont des domaines d'application qui ont engendré d'énormes programmes de recherche pluriannuels avec des conséquences sociétales massives de toute avancée (rappel, résumés de programmation linéaire allocation des ressources). En conséquence, il existe de nombreuses approches sophistiquées pour résoudre les problèmes dans ces domaines qui fonctionnent très bien.
Une mauvaise location
- peut-être même pas entendu parler de ces classes de problèmes,
- pourrait ne pas être familier avec les solutions courantes,
- ne connaîtrait probablement pas les meilleures choses qui existent (indice: la plupart des étudiants de premier cycle n'entendent jamais parler des choses fantaisistes, s'ils entendent parler des problèmes), et
- il faudrait presque certainement des années pour mettre en œuvre de telles choses (étant donné que j'ai vu certains d'entre eux donner un séminaire complet sur les structures de données, professeur compris).
En d'autres termes, demandez-vous si vous travaillez vraiment sur quelque chose de piéton. Si vous l'êtes, très bien, l'embauche devrait être beaucoup plus facile. Si ce n'est pas le cas, tenez-vous pour quelqu'un qui peut faire ce dont vous avez besoin.
Prenons un peu de recul.
Qu'essayons-nous de faire? Écrire un logiciel.
Pourquoi pensons-nous que nous devons embaucher les meilleurs? Parce que cet enfant Arnold flippant ne pouvait pas se frayer un chemin hors d'un sac en papier mouillé et maintenant le SQL est tout foutu et je ne peux pas me connecter dans.
D'accord, alors quel est le meilleur ? Je ne sais pas, c'est probablement quelqu'un qui veut beaucoup d'argent et qui a un curriculum vitae de six pieds de long avec un excellent portefeuille et travaillé chez google ou quelque chose. Il devrait avoir un diplôme, et peut-être quelques lettres à la fin de son nom. Ouais, ça sonne comme le meilleur pour moi, et par le meilleur, je veux dire quelqu'un qui n'est pas ce gamin Arnold flippant. Oh, et il devrait savoir comment faire des conneries vraiment dures dont j'ai entendu parler à l'école comme "écrire une sorte de bulle" ou peu importe comment ils l'appellent. Je vais demander à l'un des autres gars de nommer quelques choses délicates qu'ils ont dû faire à l'école, oui.
On dirait que vous ne voulez tout simplement pas que ce foutu gamin Arnold? Souhaitez-vous? Je suis fatigué d'avoir du code bogué, les choses prennent une éternité à se faire, et ces nouveaux gars que j'interviewe me disent que je dois tout réécrire!
Bon, alors qu'est-ce que vous demandez au gamin Arnold de faire? Créez un site Web PHP, écrivez du jQuery, demandez au PHP de faire un CRUD de base avec MSSQL, et modifiez les couleurs d'arrière-plan.
Est-ce que cela ressemble à une tâche bien adaptée exclusivement aux meilleurs? Je suis sûr que les meilleurs pourraient le faire, mais probablement quiconque a le bon ensemble de compétences qui correspond à cela pourrait le faire.
Donc, vous n'avez pas besoin du meilleur? D'accord, j'ai juste besoin de quelqu'un avec les compétences qui répondent à mes objectifs.
Oh. Ouais.
Je pense que ce n'est pas vraiment un problème d'embaucher un grand développeur. Le vrai défi est de les faire vouloir travailler pour vous.
Faut-il engager les meilleurs?
Je le crois. Un grand développeur n'est pas seulement celui qui fait tout à temps. Non seulement un tel individu est bien plus productif que les autres. Un grand développeur montre aussi l'exemple et met simplement les autres membres de l'équipe à contribution. D'autres pourraient grandement progresser en travaillant avec eux.
OK, vous allez donc baisser vos standards. C'est cool, vous changerez probablement d'avis après avoir embauché une personne vraiment moche. Celui qui répondra parfaitement à toutes vos questions CS mais qui ne peut pas vraiment écrire une seule ligne de code de production. Bonne chance avec ça :)
Je ne suis sûrement pas un programmeur superstar selon les standards de Joel. Néanmoins, j'ai écrit pas mal de projets réussis au cours de mes 20 années de carrière en tant que développeur. J'aurais pu résoudre vos questions. Mais moins de mon expérience au travail, où en fait une grande partie du travail plus compliqué se fait en demandant à votre base de données ou à une fonction de bibliothèque de le faire.
Mais si vous décidez d'embaucher des personnes moins expérimentées, vous devriez envisager d'utiliser des technologies faciles à manipuler. Par exemple, si vous envisagez d'utiliser C++ pour l'ensemble du projet, limitez la partie C++ aux bibliothèques écrites par vos meilleurs employés et laissez les autres implémenter l'interface utilisateur dans Visual Basic.
Notez les valeurs que vous recherchez dans un employé qui rejoindra vos rangs.
Lorsque la seule valeur appréciée est la compétence en programmation, vous vous retrouverez rapidement entouré de gens qui apprécient cela. Étant donné que la plupart des programmeurs vraiment compétents ont un système de valeurs plus élaboré, ils s'abstiendront de rejoindre votre équipe.
Cependant, il est plus probable que vous recherchiez des personnes innovantes, créatives, dignes de confiance, érudites, curieuses, autodidactes, sociables, compétentes et dévouées. Montrez que votre entreprise comprend et respecte ces valeurs et est disposée à aider ses employés à les développer davantage.
Comprenez et adoptez les valeurs de vos employés actuels et communiquez-les dans vos demandes d'emploi. Les bonnes entreprises, avec un système de valeurs durable, attirent de bons employés.
Vous devriez certainement aspirer à n'embaucher que les meilleurs. Cela ne signifie pas automatiquement que vous réussirez - il n'y a que trop de "meilleurs" pour faire le tour, et il y aura des gagnants et des perdants dans la bataille pour les attirer. Cela dépendra en grande partie de votre aptitude et de votre volonté de travailler dur sur le problème et des ressources dont vous disposez.
Renoncer avant de commencer est le moyen le plus sûr de perdre.
La recherche binaire est un problème intéressant car il est bien connu que la plupart des programmeurs auront du mal à l'écrire correctement ( Bently écrit à ce sujet dans Programming Pearls ). Ce n'est peut-être pas si mal de le tester tant que vous n'excluez pas des candidats en raison de leur incapacité à le résoudre. S'ils le résolvent rapidement et correctement, au moins cela indique quel type de programmeur ils sont afin que vous ayez plus d'informations dans ce cas particulier.
vous devez embaucher le meilleur. mais le terme a été cité hors contexte à plusieurs reprises. vous devez trouver le meilleur candidat possédant les compétences requises pour ce poste, et non le meilleur programmeur au sens large. Le développement de logiciels est large et tous les postes ne nécessitent pas les mêmes connaissances techniques.
Posez-vous cette question (vous l'avez déjà fait ..): Si vous avez un autre ingénieur dans la même position pendant 5 ans, vous attendriez-vous à ce qu'elle se souvienne des séries de fibonanci et des recherches binaires?
si la réponse est non, changez votre modèle d'entrevue. Peut-être devez-vous connaître une douzaine d'algorithmes de recherche si vous voulez travailler sur une application de recherche comme Google ou Bing. Tout le monde utilise simplement map.get ("");
ciblez vos entretiens sur ce dont le poste a besoin, pas sur un bon programmeur générique.
Si vous ne vous souciez vraiment pas de la qualité, je vous suggère d'utiliser l'un des sites Web d'externalisation et de commencer par de petits projets. Ensuite, vous pouvez les payer s'ils peuvent faire le travail et avoir un moyen facile de cautionner s'ils ne le peuvent pas.
Cependant, je me demande s'il y a vraiment beaucoup de codage de routine dans une application d'ingénierie de bureau. Ils peuvent être très complexes et la plupart des programmeurs ne maîtrisent pas bien la complexité. Vous pouvez facilement créer de nombreux codes hérités instantanés qui lieront votre équipe pour les années à venir. En général, les premières embauches pour un nouveau projet sont les plus cruciales et donneront le ton à l'ensemble du projet.
Dans toute organisation, il y a des gens avec plus d'expérience et des gens avec moins. Non seulement cela, mais un expert dans un domaine peut être novice dans un autre. Bien sûr, un amateur enthousiaste peut faire plus de mal que de bien à une base de code, mais c'est ainsi qu'il apprend - en corrigeant ses erreurs et en discutant de son expérience avec ses collègues plus expérimentés.
Ma suggestion serait que plutôt que d'essayer d'embaucher des superstars, vous essayez d'embaucher des gens qui sont raisonnablement brillants, qui s'intègrent dans la culture de votre entreprise, qui souhaitent apprendre et qui apprécient leurs propres limites.
Je suis totalement d'accord avec la plupart des commentaires ci-dessus qui concernent l'adaptation d'une personne à un problème. Cela se traduit généralement par une relation à long terme plutôt que par l'embauche d'une superstar pour travailler sur un problème régulier - ce qui le frustrera simplement de partir rapidement.
Cela dit, vous devriez toujours essayer d'embaucher pour votre entreprise plutôt que pour un poste particulier. Parce que ce même gars va tôt ou tard basculer entre les équipes avec des contacts personnels, etc. et il pourrait se révéler être un poids mort ailleurs. Assurez-vous que votre entreprise a des directives de transfert interne très strictes et que vous avez une image claire de ce que vous ferez dans votre équipe pour les deux prochaines années avant d'embaucher une personne qui, selon vous, pourrait ne pas respecter la barre de l'entreprise (mais résoudra le problème actuel ). J'ai vu trop de cas où la médiocrité des développeurs a rendu l'équipe très difficile à contourner.