Est-ce que «Embaucher seulement le meilleur» est un conseil vraiment pratique pour la programmation d'applications de bureau normales? [fermé]

Pour le fond, nous travaillons sur des applications d’ingénierie de bureau, avec une interface utilisateur comme AutoCAD, quelque chose de similaire à etabs .

Une chose qui me dérange vraiment est la suivante: faut-il engager les meilleurs développeurs? Pour commencer, nous rencontrons de grandes difficultés de recrutement; la plupart des CV que nous voyons utilisent soit de simples applications CRUD, soit une personnalisation de SharePoint qui, à mon avis, ne nécessite pas beaucoup de programmation hardcore. Même ceux que nous appelons pour un entretien, la plupart ne peuvent pas faire une séquence de Fibonacci et une simple recherche binaire, et nous sommes assez aimables pour donner des astuces et épeler les problèmes de manière explicite pour que les candidats ne soient pas obligés de chercher un dictionnaire pour vérifier que signifie "séquence de Fibonacci"?

Cela m’a amené à penser: oui, nous avons besoin d’un certain niveau d’aptitude à la programmation lorsque nous effectuons des tâches de programmation géométrique / linéaire, et nous avons également besoin d’un certain niveau , beaucoup de nos codes sont juste du code de plomberie (je pense), ce qui peut être fait par une personne ayant une certaine connaissance de la programmation.

Étant donné que nous avons vraiment besoin de talents en programmation maintenant, et que recruter des développeurs superstar est très difficile, je veux abaisser mon niveau et embaucher uniquement des soi-disant bons, en contradiction directe avec ce que prêche Joel .

Qu'est-ce que tu penses?

Edit: vous n'avez pas besoin de réécrire l'ensemble des bibliothèques de programmation géométrique / linéaire de calcul; Pour ce qui est de mon application, tout ce que vous avez à faire est de savoir comment transformer les problèmes rencontrés en termes de programmation informatique et géométrique appropriés et de savoir quand et comment utiliser les bibliothèques existantes. Donc, ce n'est pas aussi difficile qu'il y paraît.

Je vous suggère d'arrêter de lire trop Joel. Ce qu'il a écrit sur son blog est en contradiction avec ses réponses sur ce site, donc je ne prendrais pas vraiment sa parole pour grand-chose.

Ce qui fait une superstar et pourquoi il est nécessaire d’en avoir une ouvre une discussion longue et sans issue. C'est de l'élitisme et ce n'est pas pratique.

Ce dont vous avez besoin est une personne qui:

1. Aimerais faire ce que vous faites
2. Serait un programmeur enthousiaste passionné
3. Aurait le potentiel d'apprendre ce qu'il faut pour bien faire son travail

Le reste n'a pas d'importance.

Vous ne voudriez pas croire combien de jeunes diplômés sont là-bas et ne veulent rien d'autre que de se plonger dans ce genre de projet fort sur CS et de ne jamais chercher à coder des applications CRUD. Il y a quelque temps, j'étais l'un d'entre eux. Je rêvais pratiquement de rejoindre un projet concernant le développement d'un compilateur, mais je ne pouvais pas en trouver un. Pourquoi ne pas donner une chance à l'un d'entre eux?

Je ne crois pas qu'AutoCAD ait été écrit par des surhommes. La plupart des projets couronnés de succès ont été réalisés par des personnes qui voulaient simplement que la chose soit faite et qui le voulaient vraiment.

la plupart des CV que nous voyons font soit de simples applications CRUD, soit une personnalisation SharePoint

À quoi s'attendre si la plupart des emplois exigent simplement cela? Les gens ont peut-être étudié la CS à la fac et ont même été vraiment bons, mais vous ne pouvez pas vous attendre à ce qu'ils s'en souviennent s'ils ne l'ont jamais utilisée dans des programmes pratiques en 10 ans. Évidemment, personne ne lira chaque année d'anciens livres CS simplement pour le garder au frais si ces connaissances ne sont utilisées nulle part.

Un livre que j’aime vraiment, c’est First, casser 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 plusieurs bons gestionnaires ont répété à maintes reprises a été résumé par l'un d'entre eux dans la phrase: je n'ai jamais attendu trop longtemps pour trouver le bon employé et je n'ai jamais licencié le mauvais employé assez rapidement. Oui, il est frustrant de prendre beaucoup de temps à embaucher, mais cela en vaut la peine.

Vous devez également garder à l’esprit que si vous mesurez le débit du projet, il existe 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 lorsque vous développez une équipe au-delà de la taille requise pour une dynamique d'équipe réduite. Et si vous voulez rester en dessous de ce seuil, vous voulez vraiment que ces 5 à 8 personnes soient bonnes.

Les deux points parlent fortement en faveur de la recherche de la bonne embauche.

Tout le monde prétend "n'embaucher que le premier centile". Si cela était vrai, 100% des personnes occupées figureraient toutes dans le "premier centile" de toutes les personnes, de sorte que 99% de toutes les personnes seraient au chômage (dans n'importe quel domaine). Comme ce n'est clairement pas le cas et que nous avons tous expérimenté des personnes qui ne font clairement pas partie de ce groupe (pourquoi, sinon, posez-vous cette question du tout ...), nous savons que ce n'est pas vrai.

En réalité, des organisations composées uniquement de telles personnes seraient extrêmement instables. Trop d'ego, trop d'idées contradictoires. Cela s'effondrerait comme tout le monde le ferait, s'enliserait dans des discussions théoriques sans fin sur les mérites relatifs de tout, ou bien évoluer en un affrontement criant à mesure que les sentiments s'éclairciraient chaque fois qu'une décision devait être prise.

La première chose que vous devez demander est pourquoi vous obtenez des CV qui ne répondent pas 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 des personnes capables de faire des séquences de Fibonacci et une recherche binaire (ce qui est plus difficile qu'il n'y parait; selon Knuth, il s'écoulait plusieurs années entre sa première publication et sa première publication correcte), les bons loin.

Demandez-vous plus de compétences que vous êtes prêt à payer? Faites-vous de la publicité aux mauvais endroits? Votre entreprise est-elle peu attrayante par emplacement ou par 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 pas. Vous êtes peut-être trop près du problème pour le comprendre sans aide.

N'embauchez pas de personnel, car ce sont les meilleurs qui s'appliquent. Embauchez des personnes, car elles pourront faire ce que vous voulez. Si vous embauchez médiocre parce que c'est tout ce qui s'applique, alors vous allez perdre lentement de bonnes personnes et vous allez vous retrouver avec des personnes dont l'algèbre est fragile en essayant de faire des choses avec la géométrie calculatoire. (Embaucher médiocre parce que vous avez un emploi pour deux programmeurs médiocres est une autre chose, mais vous devez être capable d'engager des personnes de qualité là où vous en avez besoin.)

"la plupart ne peuvent pas faire une séquence de Fibonacci et une simple recherche binaire"

Vos critères sont certainement faux. Dans mon groupe, nous sommes tous des physiciens ou des ingénieurs. Je parie que personne ne pourrait faire de recherche binaire parce que nous n’avions pas suivi les cours de CS et dans la vraie vie, nous utilisons une bibliothèque pour cela. Je dirais même que quelqu'un qui écrit binsearch lui-même ne sait pas comment se concentrer sur des choses importantes.

Il 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 combien de temps cela lui a pris et discutez des résultats pour savoir s’il s’agit d’un travail authentique du candidat.

Je pense qu'embaucher les meilleurs devient de plus en plus un culte.

La plupart des travaux de programmation sont routiniers et non créatifs. Même en travaillant sur de nouveaux projets vraiment créatifs. La plupart d’entre elles sont banales et reposent souvent sur des modèles. c'est particulièrement vrai pour l'interface utilisateur.

La plupart des systèmes modernes exigent également que tant de personnes les écrivent, qu’en soi, ils ne peuvent tous être les meilleurs. La plupart des gens sont dans la moyenne, même s'ils ne le sont pas, ils doivent quand même faire beaucoup de tâches d'une personne "moyenne".

Cela étant dit, exiger des compétences de base et des exigences minimales raisonnables n'est pas déraisonnable et ne doit pas faire l'objet de compromis.

Pensez à la chirurgie de routine: selon votre tolérance au risque, vous préféreriez probablement qu’un médecin moyen la réalise 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 devriez laisser l'ordonnance effectuer l'opération.

«Embaucher les meilleurs» signifie généralement «embaucher les meilleurs 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 des ingénieurs en logiciel méticuleux et le prochain, des artisans du logiciel expérimentés. Il n'y a pas de "meilleur universel", alors gardez cela à l'esprit, et peut-être que votre cahier des charges suggère que vous recherchez un type de programmeur et que l'interview indique que vous recherchez un autre programmeur. Du coup, vous n'obtenez pas d'allumettes.

Cela dit, je n'aime pas travailler avec des programmeurs pas comme les autres. So-so n'a donc rien à voir avec l'expérience (ils ont peut-être programmé pendant 20 ans et ne sont toujours pas très bons), mais tout a à voir avec l'aptitude et l'enthousiasme. Si tel est le cas, vous avez un problème. Il est également inutile d'embaucher une personne dont les contributions doivent être retravaillées par d'autres membres de l'équipe, car leur code ne suffit pas. Plus de gens sur les sièges ne sont pas toujours au rendez-vous, mais plus sur les sièges peut malheureusement aussi signifier plus de travail pour les meilleurs membres de l'équipe qui tentent de faire leur travail et de nettoyer les dégâts que le programmeur so a fourni .

Certaines personnes ne sont pas des stars du rock, mais de solides programmeurs de niveau intermédiaire. C’est bien d’être dans l’équipe et ce n’est pas ce que je veux dire par "un tel programmeur". Ce dernier est une personne qui évite à peine de se faire licencier chaque année au moment de l’évaluation des performances.

En tant que type de gestionnaire, je suis d’accord pour dire que l’embauche de «1% supérieur» n’est ni pratique ni nécessaire. Mon conseil serait d'engager la bonne équipe pour construire et entretenir votre produit (il peut s'agir de deux équipes très différentes, dans la mesure où leurs besoins sont très différents).

Je suggérerais fortement que vous identifiiez les personnes que vous avez actuellement dans votre équipe qui sont des "personnes clés" (par exemple, faites avancer les choses, ayez de bonnes attitudes, pouvez travailler avec des exigences de haut niveau d'incertitude / de haut niveau, etc.), puis engagez les personnes dont elles disposent. travaillé avec dans le passé (et le respect, évidemment). Cela élimine une grande partie de l'incertitude entourant le processus d'entrevue et contribue à dissoudre l'équipe.

En outre, plus "à long terme" - investir fortement dans un programme de stagiaire. Si votre équipe de programmation compte 20 personnes, recrutez 5 stagiaires par an et donnez-leur un vrai travail. Ramenez le 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 alors embaucher à l’extérieur de manière opportuniste et relever le niveau de 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 de retour à la maison») et demandez-leur de déjeuner avec l’équipe. Apprenez à connaître leurs compétences techniques et interpersonnelles. Et n’ayez jamais peur de dire «non», même si vous avez besoin de 20 personnes supplémentaires pour un grand projet qui commence 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é, environ 20% des employés effectuent 50% du travail (par travail, je parle de bon travail, pas simplement de lignes de code). En fait, cela ressemble plus à une courbe en cloche. Donc, dans une équipe de 10 personnes, vous aurez 1 héros, 2 grands gars, 4 moyens et 2-3 pathétiques.

De nombreuses entreprises utilisent la courbe de Bell pour évaluer les évaluations. Donc, peu importe la qualité de vos candidats, ils tomberont à leur niveau. 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à pas mal de réponses ici, mais je pense qu'il reste un point à débattre: l'impact de l'embauche de ces personnes sur la qualité de votre logiciel et sur la manière dont il rend votre vie de gestionnaire beaucoup plus difficile.

La réponse à "est-il nécessaire d'engager les meilleurs développeurs?" est toujours un gros gros OUI. Bien sûr, en réalité, ce n'est pas toujours possible. La dangereuse erreur que vous commettez même en considérant cette question est de penser "notre logiciel est si simple, même un mec capable de le faire". C'est faux.

Votre logiciel sera terminé, n’en doutez pas, mais attendez-vous à des résultats très différents d’une excellente équipe et d’une équipe médiocre. Vous aurez plus de bugs, plus de problèmes de performances, plus de problèmes de maintenabilité et d'évolutivité, etc. Vous devrez garder vos gars pour des problèmes plus complexes. Vous devrez garder les gars comme ci comme ça si vous prenez des décisions d'architecture appropriées.

Si vous acceptez cela et que vous êtes prêt à gérer cela, c'est bon. Juste être préparé pour le processus et pour les résultats.

Je pense que ce n'est pas vraiment un problème d'embaucher un excellent développeur. Le véritable défi consiste à leur donner envie de travailler pour vous.

Est-il nécessaire d'embaucher les meilleurs?
Je le crois. Un bon développeur n’est pas le seul à avoir tout fait à temps. Non seulement un tel individu est beaucoup plus productif que les autres. Un excellent développeur est également un exemple à suivre et une source d'inspiration pour les autres membres de l'équipe. D'autres pourraient grandement progresser en travaillant avec eux.

OK, vous allez donc abaisser vos normes. C'est cool, vous allez probablement changer d'avis après avoir embauché une personne vraiment moche. Celui qui répondra parfaitement à toutes vos questions CS mais qui ne peut pas écrire une seule ligne de code de production. Bonne chance avec ça :)

Permet de prendre du recul.

Qu'essayons-nous de faire? Écrire un logiciel.

Pourquoi pensons-nous avoir besoin d'embaucher les meilleurs? Parce que ce gamin d'Arnold n'a pas réussi à se sortir d'un sac en papier mouillé et que le code SQL est tout foiré et que je ne peux pas me connecter.

Ok, alors quel est le meilleur ? Je ne sais pas, c'est probablement quelqu'un qui veut beaucoup d'argent et qui a un CV de six pieds de long avec un excellent portefeuille et qui a travaillé chez Google ou quelque chose du genre. Il devrait avoir un diplôme et peut-être quelques lettres à la fin de son nom. Ouais, ça me semble être le meilleur, et par les meilleurs, je veux dire quelqu'un qui n'est pas ce gamin d'Arnaud. Oh, et il devrait savoir comment faire des conneries vraiment dures dont j'ai entendu parler à l'école, comme "écrire un genre de bulle" ou peu importe ce qu'elles appellent. Je vais demander à l'un des autres gars de nommer quelques trucs difficiles qu'ils ont dû faire à l'école, oui.

On dirait que vous ne voulez tout simplement pas que ce foutu Arnold soit? Voudriez-vous? J'en ai marre d'avoir un code buggy, ça prend une éternité, et ces nouveaux gars que j'ai interviewés me disent que j'ai besoin de tout réécrire!

Bien, alors qu'est-ce que vous demandez au foutu Arnold de faire? Créez un site Web PHP, écrivez du jQuery, demandez à PHP de faire quelques CRUD de base avec MSSQL et modifiez les couleurs de l’arrière-plan.

Cela vous semble-t-il être une tâche exclusivement réservée aux meilleurs? Je suis sûr que les meilleurs pourraient le faire, mais probablement, quiconque possède les compétences adéquates correspondant à cela pourrait le faire.

Donc, vous n'avez pas besoin du meilleur? Oui, j'ai juste besoin de quelqu'un avec les compétences qui répondent à mes objectifs.

Oh. Ouais.

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 sur plusieurs décennies, avec des conséquences sociétales énormes sur toute avancée (rappel, allocation de ressources par résumé de programmation linéaire ). 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 catégories de problèmes,
• peut-être pas familier avec les solutions communes,
• ne serait probablement pas au courant des meilleures choses qui soient (astuce: la plupart des étudiants de premier cycle n'entendent jamais parler de choses intéressantes, s'ils entendent parler des problèmes du tout), et
• Cela prendrait presque certainement des siècles pour mettre en œuvre de telles choses (étant donné que j'ai vu certaines d'entre elles donner un séminaire complet pour diplômé en structures de données, y compris le professeur).

En d'autres termes, demandez-vous si vous travaillez vraiment sur quelque chose de piéton. Si vous êtes génial, l'embauche devrait être beaucoup plus facile. Si vous ne l'êtes pas, demandez à quelqu'un qui peut faire ce dont vous avez besoin.

Je ne suis sûrement pas un programmeur superstar par rapport aux normes de Joel. Néanmoins, au cours de mes 20 années de carrière en tant que développeur, j'ai écrit plusieurs projets réussis. J'aurais pu résoudre vos questions. Mais moins de mon expérience au travail, où une grande partie du travail plus compliqué est 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 collaborateurs et laissez les autres implémenter l'interface utilisateur dans Visual Basic.

Notez les valeurs que vous recherchez chez un employé qui rejoindra vos rangs.

Lorsque la seule valeur appréciée est la compétence en programmation, vous serez rapidement entouré de personnes qui attachent de la valeur à cela. Étant donné que la plupart des programmeurs réellement 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 novatrices, 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 adhérez aux valeurs de vos employés actuels et communiquez-les dans vos candidatures. Les bonnes entreprises, avec un système de valeur durable, attirent de bons employés.

Dans toute organisation, vous avez des personnes plus expérimentées et des personnes moins favorisées. Non seulement cela, mais un expert dans un domaine peut être un 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 comme cela qu’ils apprendront - en corrigeant leurs erreurs et en discutant de leur expérience avec leurs collègues plus expérimentés.

Ma suggestion serait que plutôt que d'essayer d'embaucher des superstars, vous essayez d'embaucher des personnes qui sont raisonnablement intelligentes, qui s'intégreront à la culture de votre entreprise, qui souhaitent apprendre et ont une conscience de leurs propres limites.

Certes, vous devriez aspirer à n’embaucher que les meilleurs. Cela ne signifie pas automatiquement que vous aurez du succès, il n'y a que très peu de "meilleurs", 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 au problème et aux ressources dont vous disposez.

Abandonner 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 (il en parle doucement dans Programming Pearls ). Ce n’est peut-être pas si mal de le tester tant que vous n’excluez pas les candidats en raison de leur incapacité à le résoudre. S'ils résolvent le problème rapidement et correctement, cela indique au moins quel type de programmeur ils sont, pour que vous ayez plus d'informations dans ce cas particulier.

vous devez embaucher les meilleurs. mais le terme a été cité plusieurs fois hors contexte. vous devez trouver le meilleur candidat possédant les compétences requises pour ce poste et non le meilleur programmeur dans son ensemble. Le développement de logiciels est vaste et chaque poste ne nécessite pas les mêmes connaissances techniques.

Posez-vous cette question (vous l'avez déjà un peu déjà fait ..): Si vous avez un autre ingénieur dans le même poste depuis 5 ans, voudriez-vous qu'elle se souvienne de la série de fibonanci et des recherches binaires?

Si la réponse est non, changez votre schéma d’entrevue. Peut-être avez-vous besoin de connaître une dizaine d'algorithmes de recherche si vous souhaitez travailler sur une application de recherche comme Google ou Bing. Tout le monde utilise simplement map.get ("");

ciblez vos entretiens en fonction des besoins du poste, et non d'un bon programmeur générique.

Si vous ne vous souciez vraiment pas de la qualité, je vous suggérerais d'utiliser l'un des sites Web d'impartition et de commencer par de petits projets. Ensuite, vous pouvez les payer s'ils peuvent faire le travail et disposer d'un moyen facile de payer leur caution s'ils ne le peuvent pas.

Cependant, je me demande s’il existe 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 très bien la complexité. Vous pouvez facilement créer beaucoup de code hérité instantané qui liera 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.

Je suis totalement d'accord avec la plupart des commentaires ci-dessus qui concernent l'ajustement 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 régler un problème régulier - ce qui le frustrera simplement de partir rapidement.
Cela dit, vous devriez toujours essayer de recruter pour votre entreprise plutôt que pour un poste en particulier. Parce que ce même gars va basculer d'une équipe à l'autre, tôt ou tard, avec des contacts personnels, etc., et qu'il pourrait devenir un poids mort ailleurs. Assurez-vous que votre entreprise applique des directives de transfert internes très strictes et que vous avez une idée précise de ce que vous ferez dans votre équipe au cours des deux prochaines années avant d’embaucher une personne qui, selon vous, ne rencontrera peut-être pas l’obstacle de la société (mais résoudra le problème actuel). ) J'ai vu trop de cas où la médiocrité chez les développeurs a rendu l'équipe plus difficile à gérer.