Geekly articles weekly

Entrevues d'algorithmes: théorie vs pratiquer

tl; dr Au cours des dernières décennies, la façon d'interviewer les programmeurs a changé plusieurs fois, et chacun d'eux a l'air ridicule rétrospectivement. Soit on a enfin trouvé le vrai secret des interviews efficaces, soit on s'est laissé emporter par la prochaine tendance mode, qui dans dix à vingt ans paraîtra tout aussi ridicule.

Quand je demande aux gens des grandes entreprises technologiques à la mode pourquoi il est si nécessaire de poser des questions sur les algorithmes lors d'une interview, la réponse la plus courante est quelque chose comme: «Nous avons une telle échelle, nous ne pouvons permettre à personne d'écrire accidentellement le O(n^2) et a renversé tout le système " 1 . Ce qui est particulièrement drôle, ces derniers temps, j'ai beaucoup appliqué ces algorithmes et résolu de vrais problèmes, mais je ne peux pas passer par des interviews où les gens posent des questions à leur sujet! Pensez-vous que j'échoue la moitié des interviews ou quelque chose? Non, plus de la moitié. J'ai participé à environ 40 «vrais» entretiens et j'en ai peut-être réussi un ou deux. Ou pas un seul 2 .

Quand j'ai écrit un brouillon de cet article, mes amis l'ont trouvé ennuyeux parce que j'avais raté trop d'entretiens. Ils disent que tous les échecs doivent être tabulés car personne ne lira dix pages de texte avec une longue liste d'échecs. Bon conseil. Je travaille déjà sur une table.

Regardons quelques exemples.

Dans une grande entreprise où je travaillais, l'équipe a écrit une bibliothèque de base avec sa propre implémentation d'un tableau dynamique. S'il n'y avait pas assez de taille pendant l'opération, l'implémentation a ajouté un nombre fixe de lignes au tableau, puis a copié l'ancien tableau dans un nouveau tableau de taille légèrement plus grande. Il s'agit d'un exemple classique d'implémentation incorrecte d'un réseau dynamique , car il conduit à une augmentation linéaire du temps au lieu d'un temps constant amorti . Il s'agit d'un exemple tellement classique qu'il est souvent utilisé comme canonique pour expliquer l'analyse de la dépréciation.

Dans les grandes entreprises informatiques, les entretiens téléphoniques typiques se répartissent en trois catégories:

  1. Une question de programmation / algorithme «simple», peut-être d'abord avec une question d'échauffement «très simple».
  2. Une série de questions de programmation / algorithmique "très simples".
  3. Un tas de faits bien connus (rarement pour de bonnes positions, mais souvent pour des postes de bas niveau ou non créatifs).

Ce problème d'implémentation de tableau est considéré comme si simple qu'il tombe dans la catégorie des "très faciles" et est soit un échauffement pour une "vraie" question, soit il est livré avec un tas des mêmes questions simples. Et pourtant, dans notre entreprise, un tel tableau dynamique était responsable d'environ 1% de la charge totale sur le garbage collector dans le code JVM (c'était la deuxième plus grande source d'allocations de mémoire dans tout le code), ainsi que d'une part importante de la charge CPU.

Heureusement, cette implémentation n'a pas été utilisée comme un tableau dynamique universel, mais a été créée uniquement à l'aide d'une coque semi-spécialisée, elle n'était donc responsable que de «seulement» 1% de la pression sur le GC. Si demandé lors de l'entretien, la plupart des membres de cette équipe y répondraient correctement. Mon patch a rapporté à l'employeur plus d'argent en un an que je n'en ai gagné dans ma vie.

C'était la deuxième plus grande source d'allocations de mémoire, la principale étant la conversion d'une paire de valeurs long en tableaux d'octets à partir de la même bibliothèque de base. Apparemment, quelqu'un a écrit ou copié une fonction de hachage qui a pris un tableau en entrée, puis a changé le code pour prendre deux tableaux et travailler avec eux dans une séquence à partir d'une ancienne fonction de hachage comme byte[], byte[] . Pour appeler cette fonction sur deux longs, ils ont utilisé la fonction de conversion commode de long en byte[] dans la bibliothèque d'utilitaires largement utilisée. En plus de mettre en évidence l' byte[] et de le coller long , cette fonction modifie également l'ordre des octets long (apparemment, la fonction a été conçue pour convertir long valeurs long en ordre d'octets du réseau).

Malheureusement, le passage à une fonction de hachage plus appropriée a été considéré comme un changement trop sérieux, donc mon correctif consistait à changer l'interface de la fonction de hachage pour prendre une paire de longs au lieu d'une paire de tableaux d'octets et supprimer une étape distincte pour changer l'ordre des octets (puisque la fonction de hachage a déjà changé lui, une étape distincte n'était pas nécessaire). L'élimination de ces opérations inutiles a rapporté à l'employeur plus d'argent en un an que ce que j'ai gagné dans ma vie.

L'optimisation n'est pas techniquement une question d'algorithmes, mais en pratique, elle est constamment demandée. En réponse à une question sur les algorithmes, ils me demandent généralement: "Pouvez-vous l'accélérer?" La réponse à une telle question comprend souvent une optimisation simple, qui accélère le code plusieurs fois.

Un exemple spécifique qui m'a été demandé deux fois au cours de l'interview: vous stockez les identifiants sous forme d'entiers, mais du contexte, il s'ensuit que les identifiants sont densément compressés, de sorte qu'ils peuvent être stockés sous la forme d'un champ de bits. Mais la solution existante dans le monde réel est si loin de la réponse attendue sur le champ binaire qu'il n'est guère possible de réaliser plusieurs fois l'accélération. Très probablement, l'entretien se terminera là.

Un autre exemple d'une question simple sur les algorithmes est la configuration réelle de BitFunnel , l'index de recherche utilisé dans Bing 3 .

Décrire le contexte complet de cette entreprise particulière prendra trop de temps, mais en bref, vous devez configurer un ensemble de filtres Bloom. Une façon consiste à écrire une fonction d'optimisation selon le modèle de boîte noire, qui, en utilisant la descente de gradient, essaie de trouver la solution optimale. Ils l'ont fait, mais la fonction a montré des propriétés étranges, et la configuration de sortie n'a jamais fonctionné parfaitement. Cela a été corrigé en diluant les filtres Bloom, c'est-à-dire en allouant encore plus de ressources (et donc d'argent) au problème.

Lors de l'analyse des opportunités d'optimisation, vous pouvez remarquer que l'opération fondamentale dans BitFunnel équivaut à multiplier les probabilités. Par conséquent, pour toute configuration spécifique, vous pouvez simplement multiplier certaines probabilités et déterminer comment la configuration fonctionnera. Étant donné que l'espace de configuration n'est pas si grand, vous pouvez parcourir toutes les options possibles, puis choisir la meilleure. En réalité, ce n'est pas entièrement vrai, car la multiplication des probabilités implique une certaine indépendance, qui n'a pas lieu en réalité, mais la méthode fonctionne toujours bien pour la même raison que le filtrage bayésien naïf du spam a plutôt bien fonctionné, ce qui suppose à tort une probabilité indépendante d'occurrence dans la lettre deux mots arbitraires. Pour une solution complète, vous pouvez analyser les interdépendances. Bien que cela dépasse probablement le cadre de l'entretien.

Ce ne sont que trois exemples qui me sont venus à l'esprit, et je rencontre constamment des choses similaires et je peux trouver des dizaines d'exemples, peut-être plus d'une centaine, si je m'assois et essaie de lister tout ce sur quoi j'ai travaillé. Et plus d'une centaine d'exemples sur lesquels quelqu'un d'autre (ou personne) a travaillé. Ces deux exemples, ainsi que ceux que j'ai omis, ont les propriétés suivantes:

  1. Un exemple peut être formulé comme une question pour un entretien.
  2. Si la question est formulée, vous vous attendez à ce que la plupart (ou tous) les employés de l'équipe concernée connaissent la bonne réponse.
  3. Économiser de l'argent grâce à cette solution apportera à l'employeur plus d'argent en un an que je n'en ai gagné dans ma vie.
  4. Le problème de l'exemple a persisté assez longtemps, sinon il n'aurait pas été remarqué.

Au début de l'article, nous avons noté que les grandes entreprises informatiques posent des questions sur les algorithmes, car l'inefficacité à grande échelle leur coûtera très cher. Mon expérience montre que dans chaque entreprise d'interview, il existe un million d'exemples de telles inefficacités. Il s'avère que les questions sur les algorithmes lors de l'entretien ne permettent pas de résoudre de vrais problèmes algorithmiques au travail.

L'une des raisons est que les grandes entreprises tentent de trouver des personnes capables de résoudre des puzzles d'algorithme, mais interdisent un tel raisonnement en production.

Des trois solutions pour les exemples ci-dessus, deux sont allées au prod. Pour moi, c'est un pourcentage normal si j'étais simplement invité à un projet aléatoire, que je ne suis pas constamment en train de suivre. Les cyniques peuvent dire que le pourcentage est encore élevé. Dans une équipe aléatoire, les résultats pourraient être pires, car il n'est pas avantageux pour eux de mettre en œuvre une solution, même efficace. Après tout, il leur faut tester, intégrer et déployer les changements. De nouveaux risques sont créés. Autrement dit, je demande à l'équipe de faire un travail et de prendre des risques afin de faire quelque chose d'utile pour l'entreprise, mais inutile pour eux-mêmes. Malgré tout cela, les gens acceptent généralement le code, bien qu'ils ne soient pas très enclins à consacrer du temps à l'optimisation (leur temps de travail sera consacré à des choses cohérentes avec les objectifs de l'équipe) 4 .

Supposons qu'une entreprise refuse d'offrir des puzzles d'entrevue aux candidats et encourage les développeurs à utiliser des algorithmes plus simples et relativement efficaces. Il est peu probable que l'un des exemples ci-dessus passe inaperçu pendant de nombreuses années. Le problème serait probablement résolu. Un développeur hypothétique dans une entreprise avec un profilage de code verrait les éléments les plus «chauds» dans le profil de la bibliothèque la plus gourmande en ressources.

Dans deux cas, la solution pratique n'est pas une sorte de magie des algorithmes, mais juste une analyse complète. Le troisième exemple est moins évident car il n'y a pas d'outil standard pour analyser le problème. Vous pouvez essayer de présenter le résultat comme une sorte de maîtrise suprême, après tout, cet exemple est basé sur un article scientifique, qui a reçu un prix pour le meilleur article lors de la conférence la plus prestigieuse dans son domaine, mais en réalité il y a les mathématiques au lycée, c'est-à-dire, pour une vraie solution au problème, vous avez juste besoin étudier où ces méthodes mathématiques sont applicables.

J'ai vraiment travaillé une fois dans une entreprise qui ne posait pas de questions sur les algorithmes lors des entretiens, mais se concentrait sur des questions pratiques. Pendant mon séjour là-bas, je n'ai trouvé qu'une seule opportunité d'optimisation qui répond presque aux critères ci-dessus (en raison de sa petite taille, elle ne va pas un peu le troisième point, c'est-à-dire qu'à ce moment-là, j'avais gagné plus dans ma vie que les économies annuelles réalisées grâce à la fixation ce bug).

Pourquoi cette entreprise n'a-t-elle eu pratiquement aucun problème avec les plugs de performance? Je pense que la raison principale est que beaucoup de gens pensaient que l'amélioration de l'entreprise était leur travail. Par conséquent, les systèmes ont été initialement conçus de manière presque optimale. À de rares exceptions près, il y avait suffisamment de spécialistes qui ont essayé de continuer à bénéficier à l'entreprise, plutôt que personnellement pour eux-mêmes et leur équipe (ce qui est complètement différent de l'avantage global pour l'entreprise). Ainsi, il y avait toujours quelqu'un qui avait résolu le problème avant qu'il ne me vienne.

Dans les grandes sociétés informatiques, l'entretien sur des algorithmes avec des compétences de codage de test est généralement plus simple que le dépistage initial par téléphone. Habituellement, les problèmes de conception du système ne sont pas traités ici.

Il y a quelque temps, nous avons essayé de poser une question sur les algorithmes dans une interview en face à face. Une question assez difficile, mais dans le cadre de ce que vous pourriez rencontrer par filtrage téléphonique dans les grandes entreprises (mais toujours plus facile que ce à quoi vous vous attendriez d'un entretien personnel). Nous avons abandonné cette pratique, car absolument tous les candidats ont échoué cette partie (nous n'avons pas posé de question sur les algorithmes aux candidats expérimentés). Notre entreprise n'est pas assez connue pour trouver des nouveaux arrivants qui peuvent facilement répondre à ces questions.Par conséquent, ces filtres de sélection de candidats à la mode ne fonctionnent pas pour nous. Dans les articles d'embauche modernes, ce que nous avons fait est souvent appelé «abaisser la barre», mais je ne comprends pas pourquoi nous devrions nous soucier de la hauteur maximale du saut du candidat si son travail implique presque (ou jamais) des sauts élevés. Et dans les cas où vous avez vraiment besoin de sauter, la barre est réglée à une hauteur d'environ cinq centimètres.

À en juger par les performances réelles, c'était l'entreprise la plus productive dans laquelle je travaillais. Je crois que les raisons sont dans la culture, et elles sont trop complexes pour être complètement démontées dans un article, mais cela nous a probablement aidés à ne pas filtrer les bons candidats en utilisant des quiz par algorithmes. Nous avons suggéré que les gens puissent étudier ce matériel au travail si nous avons la bonne culture et que les employés font la bonne chose au lieu de se concentrer sur les tâches locales pour eux-mêmes ou leur département.

Si d'autres entreprises veulent que les gens résolvent au travail des problèmes d'algorithmes du même niveau qu'ils demandent lors des entretiens, vous devez essentiellement encourager les gens à résoudre des problèmes d'algorithmes (le cas échéant). Cela peut être fait en plus ou même au lieu de sélectionner des candidats pour des problèmes théoriques.

Annexe: comment en sommes-nous arrivés là?


Au bon vieux temps, des questions «triviales» étaient posées lors des entretiens. Les versions modernes pourraient ressembler à ceci:

  • Qu'est-ce que MSI? MESI? MOESI? MESIF? Quel est l'avantage de MESIF sur MOESI?
  • Que fait un destructeur? Et si c'est C ++ 11? Et si vous appelez le destructeur de sous-objet à partir du destructeur de niveau supérieur, alors quels autres destructeurs de sous-objet seront exécutés? Et lors de la promotion de la pile? Dans quelles circonstances pouvez-vous éviter d'appeler std::terminate ?

J'ai entendu parler de ces simples entrevues à l'école et j'ai même vu dans certaines entreprises la «vieille école». C'était sous la direction de Microsoft, lorsque tout le monde s'est tourné vers une entreprise prospère et a copié Microsoft. Le blogueur en programmation le plus lu (Joel Spolsky) a déclaré que tout le monde doit adopter une certaine pratique de développement X parce que Microsoft le fait. Par exemple, dans l'un des articles de programmation les plus influents de l'époque, Joel Spolsky a présenté le soi-disant test Joel, qui détermine dans quelle mesure vous suivez des entreprises comme Microsoft:

12 points est excellent, 11 points sont tolérables, mais avec une note de 10 ou moins, vous avez de sérieux problèmes. La vérité est que la plupart des logiciels fonctionnent à un niveau de 2-3 points, et ils ont besoin d' une aide sérieuse , car des entreprises comme Microsoft travaillent au niveau 12 à plein temps.

Selon les légendes populaires de l'époque, Microsoft a posé de telles questions lors des entretiens (et j'ai vraiment posé l'une de ces tâches lors d'un entretien chez Microsoft dans la région de 2001, sans poser de questions sur les algorithmes ou la programmation):

  • Comment sortir d'un mixeur si votre taille est de 1 cm?
  • Pourquoi les plaques d'égout sont-elles rondes?
  • La pièce sans fenêtre a trois lampes, chacune étant contrôlée par un interrupteur de l'extérieur. Vous êtes à l'extérieur de la pièce et ne pouvez y entrer qu'une seule fois. Comment déterminer quel interrupteur contrôle quelle lampe?

Depuis que j'ai été interviewé à une époque de changement, on m'a posé beaucoup de questions simples et un tas de tâches (y compris tout ce qui précède). Lors des interviews de cette époque, les questions de Fermi , qui ne sont techniquement pas des énigmes, étaient toujours populaires. Une autre tendance de l'époque était les entretiens comportementaux sans problème technique unique.

Quoi qu'il en soit, les gens ont essayé de copier les interviews de style Microsoft. Quand j'ai demandé quel genre de casse-tête ou les questions de Fermi étaient bonnes, ils m'ont répondu que de cette façon, il était possible de vérifier si le candidat était capable de réflexion, par opposition aux questions de connaissances qui disent seulement qu'une personne s'est souvenue de certaines informations. Et nous avons besoin de candidats qui peuvent vraiment réfléchir!

Avec le recul, il est désormais clair pour tout le monde que cela était inefficace, et copier chaque astuce Microsoft ne ferait pas le succès de votre entreprise, car Microsoft a utilisé de nombreuses autres astuces - elles n'étaient efficaces ensemble qu'en raison de l'effet réseau. En copiant des interviews Microsoft, vous serez une entreprise qui mène simplement des interviews dans le même style, mais ne peut pas profiter des effets de réseau utilisés par Microsoft.

Pour les candidats, la procédure d'entretien était fondamentalement la même que maintenant avec les algorithmes. Juste pour préparer une interview, au lieu de "Pirater une interview de programmation", vous avez dû lire "Comment déplacer le mont Fuji". Autrement dit, vous aviez besoin d'apprendre beaucoup de connaissances sur les tâches que vous n'utiliserez jamais au travail, au lieu de la connaissance d'algorithmes que vous n'utiliserez jamais de la même manière.

À cette époque, les enquêteurs ont trouvé des questions d'entrevue dans des livres de préparation aux entretiens, comme Comment déplacer le mont Fuji. Ces questions ont été posées aux candidats qui ont appris les réponses dans les mêmes livres. La jeunesse moderne trouve cela ridicule - il est évident que les questions n'ont rien à voir avec le travail, et la probabilité d'une bonne réponse dépend plus de la préparation de l'entretien que de la compétence du candidat. Mais l'approche d'aujourd'hui n'est pas si différente.

Au cours des dernières décennies, la mode d'interview des programmeurs a changé plusieurs fois, et chacun d'eux a l'air ridicule rétrospectivement. Soit on a enfin trouvé le vrai secret des interviews efficaces, soit on s'est laissé emporter par la prochaine tendance mode, qui dans dix à vingt ans paraîtra tout aussi ridicule.

Sans tenir compte de l'efficacité, les méthodes d'interview au niveau méta n'ont pas changé (à l'exception de la technologie de haut niveau de l'entreprise la plus prestigieuse), donc tout est très similaire à un autre passe-temps à la mode, qui ne diffère pas des pratiques ridicules précédentes. Des recherches empiriques ou une vérification indépendante de l'efficacité de différentes méthodes peuvent ébranler mon opinion.

Inspiré par le commentaire de Wesley Pharmacist-Cassels , j'ai récemment demandé spécifiquement aux représentants des employeurs comment ils vérifient l'efficacité de leurs entretiens et comment ils gèrent les préjugés. Voici ce qu'ils ont répondu (par ordre décroissant de fréquence):

  • Quoi? Rien, pourquoi ça?
  • Nous ne savons vraiment pas si notre processus est efficace.
  • Nous savons juste que tout fonctionne.
  • Nous n'avons aucun parti pris.
  • Nous aurions remarqué des biais s'il y avait eu un processus d'évaluation.
  • Quelqu'un a étudié et / ou mené des recherches, mais ne peut rien dire de concret sur la façon dont il a été étudié et par quelle méthodologie l'étude a été menée.

Application: formation


Comme pour la plupart des problèmes réels, il est impossible de trouver la seule raison pour laquelle des bogues valant des dizaines et des centaines de millions de dollars restent fermés en production. D'une part, nous rencontrons une sorte de défense en profondeur avec des incitations inadaptées. D'un autre côté, l' apprentissage est malheureusement sous-estimé .

J'ai déjà mentionné que dans presque toutes les entreprises, le système n'encourage pas les gens à consacrer du temps à l'amélioration de l'efficacité, même si un simple calcul montre que la correction des bugs peut facilement économiser des dizaines ou des centaines de millions de dollars. Et en l'absence d'incitations, les développeurs n'ont nulle part où acquérir de l'expérience pour effectuer un tel travail. Un travail inconnu semble toujours plus compliqué qu'il ne l'est réellement. Ainsi, même si une journée de travail peut rapporter 1 million de dollars par an sous forme d'économies ou de bénéfices (c'est assez courant dans les grandes entreprises, d'après mon expérience), les gens ne comprennent pas qu'il ne s'agit que d'une journée de travail et cela peut se faire sans distraction du reste des cas. Une façon de résoudre ce dernier problème est la formation. Cependant, il est encore plus difficile pour un manager de le justifier que d’augmenter l’efficacité, qui ne fait pas partie des tâches principales!

Par exemple, une fois que j'ai écrit un petit guide (4500 mots, moins que cet article, sauf pour l'image) sur la recherche de diverses inefficacités dans le système: comment utiliser le profileur pour allouer de la mémoire et du temps CPU, comment configurer notre GC pour des tâches spécialisées, comment utiliser certains de mes outils pour trouver automatiquement les goulots d'étranglement dans les configurations JVM, les conteneurs, etc. Ce sont des astuces simples et très efficaces, faciles à réaliser. Quelques personnes ont pu déboguer et résoudre le problème par elles-mêmes, et j'ai entendu de seconde main que quelqu'un d'autre avait augmenté l'efficacité de leur service. Eh bien, si 10% des ingénieurs ont bénéficié de ce manuel, j'espère qu'il a aidé des dizaines d'ingénieurs, et peut-être plus.

Si, au lieu d'un guide, je passais une semaine sur un «vrai» travail, j'obtiendrais quelque chose de spécifique, avec une valeur quantitative, qui a l'air magnifique dans un package promotionnel ou une évaluation des performances. Au lieu de cela, j'ai une sorte de vague réalisation, qui au mieux peut être considérée comme un «mérite supplémentaire». Je ne me plains pas - c'est exactement le résultat que j'attendais. Mais en moyenne, les entreprises obtiennent ce qu'elles stimulent elles-mêmes leurs employés. S'ils s'attendent à ce que la formation provienne des développeurs eux-mêmes (sans financer la production de matériel de formation), mais ne l'apprécient pas autant que le travail des développeurs, alors la formation deviendra une rareté.

Je pense qu'il est facile de remarquer la mauvaise qualité du matériel d'enseignement public en raison de la difficulté relative de monétiser l'éducation et la formation. Si vous souhaitez monétiser des programmes de formation, il existe de bonnes méthodes. Apparemment, la monétisation de cours vidéo précieux fonctionne bien (des centaines ou des milliers de dollars pour un cours de courte durée). Les formations en entreprise, lorsque les entreprises vous invitent à parler avec 30 personnes et que vous prenez 3 000 $ chacune, fonctionnent également très bien.

Si vous souhaitez toucher (et potentiellement aider) un grand nombre de personnes, la publication sur Internet est efficace, mais ne vous attendez pas à la monétisation. En ce qui concerne les sujets techniques, il est peu probable que le public sans bloqueurs de publicités soit suffisamment important pour monétiser le contenu via la publicité (par opposition à l'accès payant).

Par exemple, Julia Evanssuffisamment de revenus pour la vente de bandes dessinées, qui rapportent récemment environ 100 000 $ par an. Un spécialiste de la formation en entreprise peut gagner cela en un à deux jours.

Annexe: défense en profondeur avec incitation incitative, partie 3


Parmi les trois exemples ci-dessus, dans deux cas, j’ai reçu des encouragements pour économiser l’argent de l’entreprise. D'après mon expérience, cela se produit rarement dans les grandes entreprises, mais même ainsi, la répartition des incitations s'est avérée plutôt médiocre. À un moment donné, après promotion et augmentation de salaire, j'ai calculé le ratio de mon augmentation et de mes économies que j'ai apportées à l'entreprise. Le ratio était d'environ 0,03% directement en argent, sans tenir compte des outils développés par mes soins, pour lesquels il est difficile de calculer une valeur spécifique. Cette valeur est probablement en réalité plus qu'une valeur quantifiable. Par conséquent, nous pouvons conclure que j'ai reçu beaucoup moins de 0,01% du montant que l'entreprise a apporté. Et c'est une évaluation surestimée: en réalité, je soupçonne fortement qu'en fait le travail accompli ne m'a rien apporté,et l'augmentation n'a rien à voir avec ce projet qui a permis à l'entreprise d'économiser des dizaines de millions de dollars. Après les 10 premiers millions de dollars par an, ou peut-être 20 millions de dollars par an, il n'y a plus d'incitation à faire du travail en termes d'évaluation de l'efficacité, de la promotion, de l'amélioration, etc. Parce qu'il n'y a pas d'avantages, mais il y a quelques inconvénients (vous pouvez s'impliquer dans des intrigues secrètes, faire accidentellement tomber le site, etc.), de sorte que le retour sur l'exécution de travaux optionnels risque de devenir négatif.mais il y a quelques inconvénients (vous pouvez vous impliquer dans des intrigues secrètes, faire accidentellement tomber un site, etc.), de sorte que le retour sur l'exécution d'un travail optionnel devient probablement négatif.mais il y a quelques inconvénients (vous pouvez vous impliquer dans des intrigues secrètes, faire accidentellement tomber un site, etc.), de sorte que le retour sur l'exécution d'un travail optionnel devient probablement négatif.

Certaines entreprises accordent régulièrement des primes très importantes, mais je n'avais pas une telle entreprise, et en réalité, l'employeur ne peut pas évaluer un employé pour un travail supplémentaire, sauf en tant que note maximale dans l'évaluation des performances, et elle représente une quantité de travail «suffisante». En termes de conception des mécanismes , l'entreprise demande en fait aux employés de cesser de travailler dès qu'ils en ont «assez» fait.

Ainsi, même dans cette équipe relativement professionnelle, le système de récompense de l'entreprise limite les personnes sans les inciter à maximiser leur efficacité.

Il est également arrivé que les gestionnaires reçoivent un budget d'équipe pour augmenter les salaires, qui dépend principalement du nombre d'employés, puis est réparti entre les employés. Fondamentalement, l'équipe n'a que des développeurs productifs, donc personne ne se démarquera des autres. Dans le même temps, le roulement du personnel est très faible car les programmeurs aiment travailler avec de bons collègues. Pour inciter les gens à intégrer des équipes moins efficaces, l'entreprise utilise l'un des leviers les plus puissants: la rémunération.

Comme il s'agit d'un régime commun, dans certaines entreprises, les dirigeants essaient de garder les employés inoffensifs mais inefficaces afin de contourner les restrictions de bonus. Si l'on se demande théoriquement si les entreprises doivent embaucher et retenir des personnes inefficaces, la réponse est non. Mais en pratique, le système de primes universelles pour une équipe stimule indirectement cela.

Liens connexes




1. Premièrement, les interviews Google copient souvent de petites entreprises pour lesquelles cet argument est inapproprié. Mais même aucune des grandes entreprises ne développe ou ne met en œuvre d'algorithmes à grande échelle (Google l'a peut-être fait vers 2003, mais dans les grandes entreprises informatiques modernes, personne ne se concentre particulièrement sur le développement d'algorithmes). [retour]

2. Le «vrai» est entre guillemets parce que j'ai effectué plusieurs entrevues pour des raisons non liées au processus d'entrevue lui-même. Peut-être que j'avais de très bonnes recommandations, ou peut-être que quelqu'un avait lu mon blog ou demandé des renseignements à d'anciens collègues, ou regardé mes projets open source (pour autant que je sache, cela s'est produit une ou deux fois). Habituellement, après un échec manifeste lors de l'entretien, je demande pourquoi on m'a proposé un emploi, alors j'ai déjà rassemblé un ensemble de ces raisons.

Je suggère également la possibilité d'un résultat nul, car la seule "vraie" interview de programmation était chez Google, mais les mauvais gars sont venus m'interviewer. Je suis allé travailler avec du matériel, et les programmeurs m'ont interviewé, donc j'ai essentiellement eu une interview de programmeur standard, sauf qu'un intervieweur a posé quelques questions sur la machine d'état et la cohérence du cache (ou quelque chose comme ça). Ensuite, ils ont organisé un entretien téléphonique avec un ingénieur hardware pour m'assurer que je ne mentais pas sur le fait de travailler dans une startup hardware de 2005 à 2013. Il est possible que j'ai échoué à la partie programmation de l'entrevue et que j'ai été embauché uniquement en raison de la conversation téléphonique qui a suivi.

Veuillez noter que mes faibles résultats ne concernent que les interviews de programmation, pas le matériel. Je suis vraiment bon en interview pour le fer, même si je n'ai pas pratiqué ce travail depuis longtemps. Un de mes amis dit que les entretiens sur le matériel sont si bons pour moi à cause du jargon spécifique: je «parle comme un ingénieur en matériel» et en fait, nous parlons le même langage avec les ingénieurs en électronique. D'un autre côté, nous disons certaines choses de telle manière qu'elles semblent incroyablement stupides pour la plupart des programmeurs, mais le problème vient du vocabulaire, du jargon et non des connaissances ou des compétences réelles. [retour]

3. Il s'agit d'une question légèrement plus compliquée que ce à quoi vous vous attendiez par téléphone, et une telle question peut être attendue lors d'une entrevue en personne. Bien que mon ami lors d'une interview téléphonique avec Google ait une fois posé une question lors de la finale mondiale de Google Code Jam , donc pour une complexité maximale, il n'y a vraiment pas de limite, selon qui vous le demande.

Au fait, si vous êtes intéressé, mon ami connaissait la réponse, car il a résolu ce problème sur Google Code Jam. Lors de la compétition, il n'a pas trouvé la bonne réponse, mais il l'a ensuite cherché pour le plaisir. Cependant, il n'a pas jugé raisonnable de répondre immédiatement par téléphone, mais a demandé à l'intervieweur de poser une autre question. Il a refusé, alors mon ami a échoué à un entretien téléphonique. Bien que je doute qu'il y ait plus de quelques centaines de personnes dans le monde qui puissent répondre correctement à une telle question par téléphone, et presque toutes comprendraient probablement l'absurdité de la situation. Après avoir échoué à l'entretien, mon ami cherchait du travail depuis près de six mois avant d'entamer un entretien pour une startup, pour laquelle il a finalement développé plusieurs systèmes clés (tant en termes d'impact sur l'entreprise que de difficultés techniques). Il continue d'y travailler aprèscomment l'entreprise a procédé à une introduction en bourse de plus d'un milliard de dollars. L'entreprise comprend combien il est difficile de remplacer cette personne et la traite très bien.[retour]

4. En plus des problèmes architecturaux criants qui conduisent simplement à une baisse de service, il y a un autre point. Les équipes résolvent souvent les problèmes de performances simplement en demandant des ressources informatiques supplémentaires. Certaines entreprises tentent de résoudre ce problème. J'ai entendu que sur Facebook, de nombreuses équipes travaillant sur l'amélioration de l'efficacité rendent compte à un département spécial qui leur permet de bloquer les demandes d'extension de capacité s'ils remarquent une inefficacité extrême dans une équipe qu'ils refusent de corriger. Mais personnellement, je n'ai pas rencontré de telles entreprises. Google a essayé de résoudre ce problème avec un système qui, entre autres choses, corrélait le nombre d'employés avec les ressources informatiques, mais j'ai entendu dire qu'il a finalement été abandonné au profit d'un système plus traditionnel pour une raison quelconque.. [retour]

Source: https://habr.com/ru/post/fr485596/

More articles:


All Articles