Reprise du message précédent :
http://reho.st/medium/self/2848259 [...] 635796.jpg

 
 
Moi je suis d'accord sur le fond. Mais ca ne scale pas aussi bien
 
C'est vendredi, j'ai le droit au franglais, et j'ai aucune idée comment traduire scale dans ce contexte

C'est stupide. Quelqu'un qui sait développer un programme utile à tout le monde a plus de valeur que quelqu'un qui sait reproduire un algo qu'on trouve dans les livres.
 
" if I were you, I would have flipped the whiteboard upside down and said, "here, I inverted this one for you".'

Preums

À ce propos je viens de foirer un entretien avec une des rares boîtes qui a un processus sensé :
- Test en ligne, QCM sur des points subtils de Java, trois trucs à coder dont une question assez complexe. J'avais 5 jours pour le faire, j'ai fait ça en une soirée, score: 96%
- Une heure de pair programming. Le mec m'envoie un projet dix minutes avant que ça commence, je partage mon écran sur Skype. Je devais ajouter un test pour montrer que les spécifications étaient pas respectées, ensuite fixer le bug, puis améliorer certaines fonctionnalités. C'était du vieux Java 1.4, j'ai fait de la merde Le recruteur m'a donné le feedback complet, c'est super rare, généralement je suis jamais vraiment au courant de ce que j'ai foiré.
- L'étape suivante aurait été de parler avec les équipes intéressées par mon profil.

Tu peux développer ? J'aurais dit comme sligor mais peut-être que je comprends pas la question.

C'est plus compliqué que ça  
 
L'entreprise défend un système juste, et considère qu'il y a trop de contingences liées au passé des candidats pour pouvoir les juger sur ce qu'ils ont fait. Au lieu de ça, ils choisissent (et ils l'expliquent en long en large et en travers tout au long du processus) qu'ils évaluent les candidats sur le tas, pendant qu'ils programment.
 
Pour ça, il faut bien leur donner des trucs à programmer. Là aussi, pour éviter les biais,ils choisissent de faire coder tout le monde sur la même chose. Le thème c'est "les algorithmes que tout les informaticiens peuvent apprendre en 5 minutes mais que personne n'utilise au quotidien". Ils te donnent la liste. Plusieurs fois. Traversée de graphe. Récursion. Tri. STL. Dictionnaire. Probabilités. Ils te donnent les sites, les livres pour t’entraîner. Ils te laissent le temps que tu veux avant de te faire venir.
 
Le jour venu, ils te posent les questions, il y en a une dizaine en tout (2 par interview). Elles sont presque toutes directes, pas de piège, pas de truc à trouver. Le but ce n'est pas de voir si tu es capable de résoudre le problème, la note ne porte pas sur ça mais sur la propreté de la démarche, sur la communication pendant l'exécution, et sur la qualité du code produit.
 
Alors certes le monsieur dont on parle est sans doute largement au niveau, manifestement bien meilleur que moi, mais il n'a pas pris 3 heures pour préparer les questions de base que ses interlocuteurs lui avaient dit qu'ils allaient poser. C'est quand même une erreur de ne pas le prendre, lui, mais en faisant ça ils défendent un processus de recrutement qu'ils estiment avoir plus de valeur que cette personne.

je soupçonne que c'est pas le graphe qu'il devait inverser, mais juste sortir une représentation dans l'autre sens des données qui sont dedans.
donc passage en suffixe dans le graphe (on descend en profondeur dans le noeud de droite avant le noeud de gauche)

 
Y'a QtCreator aussi qui fonctionne bien, avec ou sans Qt.

Prems au boulot, grosse mise en prod ce weekend. J'avais oublié qu'on nous offrait tous les repas et à boire tant qu'on est là (je m'étais fait à bouffer pour midi)

Même pour une question d'échauffement ça me paraît un peu trop simple.
 
Mais remarque, inverser droite/gauche c'est pas bien compliqué non plus:
https://leetcode.com/problems/invert-binary-tree/

pas besoin de savoir manier la théorie des graphs ou d'apprendre par coeur l'algo pour le ressortir là. Il faut juste savoir trouver une solution à un problème simple. (comme dit précédemment)  
 
Il a merdé tel un sprinteur super bon qui se rate pendant les qualifications. Ca arrive, c'est comme ça et en faire un tel drame comme il l'a fait sur twitter ne me donnerait pas envie de l'embaucher si j'étais recruteur.

Il a posté une réaction sur twitter, mate la gueule du drame

c'est vrai qu'en relisant son message il n'y a rien de dramatique ou d'insultant, ce sont plutôt les réactions autour de ça qui sont assez débile (mais "never ever read comments on internet" j'oublie à chaque fois )

 
D'une manière générale, je suis bien d'accord avec toi. Les programmeurs capables de mener à son terme des projets qui sont ensuite réellement utilisés dans la vraie vie sont bien plus rares que les mecs capables de reproduire un algo. D'ailleurs combien de prétendus progueux super spécialistes de prog objet, normes, standards etc... Mais au bout du compte incapables de programmer une grosse application jusqu'au bout ?
C'est semblable au musicien d'orchestre ou de scène VS prof de musique qui souvent sait bcp plus de théorie que le premier mais est incapable de réellement bosser en tant que musicien.
 
Mais je dirais que ça va bcp dépendre aussi de ce que l'on attend. Dans de très grosses structures, j'imagine qu'on veut des gens capables de construire des petites briques qu'on va ensuite assembler entre elles, donc on peut vouloir des gens qui rentrent parfaitement dans un moule déterminé à l'avance.

je rappelle juste que ce qui fait gagner beaucoup de pognon à google ce sont leurs algos ultras efficaces et surement assez avancés et surement avec beaucoup de théorie derrière.
 
C'est pas du tout avec juste des petits utilitaires géniaux que google fait un max de bénefs.

Mais en pratique quel pourcentage de leurs développeurs travaillent là dessus?
En l'occurrence Max Howell ‏postulait pour une place de développeur iOS. J'ai pas lu son CV mais j'imagine que si t'arrives à implémenter un gestionnaire de paquets avec résolution des dépendances, tu dois pouvoir gérer la complexité d'une app mobile.
 
Après en effet il a foiré une question super facile, sans piège ou truc, ça arrive. Et Hephaestos a raison, ils sont super clairs sur le processus, dans mon cas le recruteur m'avait même refilé des liens vers des copies pirates des livres nécessaires à la préparation.
Mais c'est pas la première fois que j'entends qu'ils gèrent mal la communication avec des développeurs un peu connus. Donc je veux bien lui accorder le bénéfice du doute.

Les questions d'échauffement sont souvent très simples (du genre : tu as une liste, donne moi la longueur de la chaîne d'éléments consécutifs la plus longue). Et la suivante à peine plus compliquée (ce n'est plus une liste mais un arbre) .

Faut voir aussi que l'interview Google c'est un genre de bizutage, un rite de passage. Prendre une rock star parce que c'est une rock star en lui donnant un passe-droit sur les modalités d'admission c'est envoyer un message dissonant à tous les autres employés. La boîte elle mise sur le fait d'avoir 10000 très bons ingénieurs, pas sur une poignée de génies.

Le processus d'entretien dans ma moi est dans la même veine. Et je pense que si j'ai mon job, c'est parce que je n'ai pas eu à passer par ce système..

@hepha: Mouais, jsais pas.. Peut être es tu habitué à ces notions que je trouve « scolaires », un peu à la mode « grandes écoles » avec barrière à l'entrée (élite blablabla).

C'est pas mon kiff, j'ai jamais aimé ce genre de pratiques, ni les gens que ça « agglomère » dans une espèce de consanguinité de « on a passé le test ». Je préfère au contraire avoir des profils très différents (techniquement et en terme de parcours d'études/de vie) mais avec des qualités humaines certaines.

C'est pour ça que par exemple, que tu dis que l'équipe finale à des craintes vu ton parcours, ça en dit long sur leur façon de voir les choses (alors que les filtres humains/RH/techniques sont OK).

M'enfin, my2cents.

edit : c'est aussi un point de vue par rapport à mon parcours à moi, j'ai toujours été scolairement très moyen, jamais non plus très pointu techniquement. Je préfère être un « généraliste » et comprendre le raisonnement (comment ça marche) que le spécialiste qui connaît par cœur tous les détails. Au fond de moi, j'ai le sentiment que je suis plus fait pour piocher des idées un peu partout en m'inspirant des très nombreuses choses qui m'intéressent.

C'est quoi ton expérience pour recruter des 10aines ou 100aines d'ingénieur du haut du panier par an ?
 
Encore une fois, le problème est la. Et le choix est qu'il est préférable de rater un bon iconoclaste que de laisser entrer le vers dans la pomme
 
Personnellement ça me fait chier, mais il faut avouer que ça marche pas trop mal.
 
 
Et c'est vraiment pas une question spécialiste/généraliste.

Je suis sûr que le processus de Google répond à leur besoin mais le problème, selon mon expérience et d'après ce que je lis à droite et à gauche, c'est le nombre de boîtes qui font la même chose sans vraiment comprendre que le but c'est pas forcément d'engager seulement les gens qui ont mémorisé toutes les réponses.

Sur HN un ex-Googler expliquait ça bien :

Quand la mode c'était les entretiens style Microsoft où on te demande combien tu ferais payer pour laver toutes les vitres de Seattle, Google posait ce genre de questions aussi, jusqu'à ce qu'ils se rendent compte que c'était une métrique complètement pourrie. Et là j'ai également l'impression qu'on a tout un pan de l'industrie qui utilise une métrique également bien pourrie, uniquement parce que ça marche pour Google.

Oui de toutes évidences j'aime ce système en particulier parce que j'y réussis. Je ne sais pas s'il est meilleur (je pense qu'il est carrément mauvais pour la plupart des boîtes qui ne sont pas Google), mais il a le mérite d'être cohérent et juste.

Concernant ton PS c'est pas tout à fait pertinent : ils ne recrutent pas des spécialistes des algorithmes, encore une fois les questions sont plutôt faciles techniquement. Ils recrutent des gens qui réagissent bien face à un problème inconnu qu'ils savent résoudre.

Quant au problème de consanguinité, pour ma part je trouve que ça en dit long qu'en un an de recherche mes seuls entretiens aient été obtenus avec un gars du forum, et avec Google (et avec une boite qui fait exactement ce que je fais aujourd'hui dans mon labo) .

Aucune des autres boîtes que j'ai contactées n'était prête à écouter ce que j'avais à dire, j'ai la faiblesse de penser que c'est parce que je ne suis pas du sérail.

 
« tapasdegamins - tupeuxpascomprendre-proof » 
 
L'expérience que j'ai c'est effectivement que la mienne à petite échelle certes, et 2 journées chez Google avec diverses conversations parfois assez critiques sur eux-même. Tout ça ne m'empêche pas d'avoir mon opinion et que c'est le genre de système que je n'aime pas des masses (note : je suis pas aigri ou anti Google, c'est le process en lui-même que j'apprécie guère).
 

 
Moi je trouve ça figé et injuste. On est pas des robots, il y a tellement de paramètres différents qu'un rite de passage identique pour tous, c'est l'assurance d'avoir un nivellement (sans jugement sur le dit nivellement, c'est un constat). Tu rentres dans le moule quoi.  
 
Je sais pas, ya un truc qui me trouble avec ça (depuis toujours). Peut être est-ce bon pour Google, je ne sais pas, je juge pas ça, je dis juste que c'est vraiment pas quelque chose auquel j'adhère.
 
Petit digression sur « l'esprit corporate » : à ma très petite échelle (Vates), je suis activement dans la démarche opposée. Je ne souhaite pas du tout que mes salariés soient fiers d'être « Vates », ni doivent rentrer dans un moule. Pour moi, on se défonce pas tous les jours pour l'entreprise dans laquelle on est salarié. On le fait pour d'autres raisons (son équipe, les gens qu'on apprécie). Ça nécessite une bonne communication, que chacun comprennent pourquoi il est là et la vision globale/répercussion de son travail sur les autres. Bref, « Turn the ship around ».
 
Chez nous ça donne, en recrutement :
 

• un alternant qui vient du monde... de la restauration et qui a repris ses études en « développement d'entreprise » (recherche de fonds etc.)
• un dev en CDI qui a fait 10 ans de la guitare dans un groupe de metal, repris ses études à l'AFPA pour faire du dev
• une stagiaire qui a fait des études de documentaliste et qui va faire 2 mois de tests unitaires
• peut être une channel manager qui a 15 ans d'XP dans le domaine bien que passé par des études techniques à la base, et fait un MBA 10 ans après la fin de ses études (ça, ça sera une histoire de sioux si on peut l'embaucher ou pas )

Bref, on aurai cherché des devs de plus, ça m'aurait pas choqué du tout de voir un profil comme le tiens, au contraire. Et si ça t'intéressait vraiment de bosser avec nous, j'y aurai vu aucune restriction pour te faire rentrer dans l'équipe ! Note que j'exclus pas les profils « classiques » non plus, si ça colle humainement, ya pas plus de questions à se poser.

 
Ça fait 2x que je dis que je ne suis pas fan mais tu réfléchis en artisan et pas en industriel là. Du coup tu compares choux et carottes
 
D'où ma question : quel serait ton approche si tu devais résoudre ce problème ?
 
J'ai jamais bossé dans une aussi grosse boîte que celle dans laquelle je suis actuellement, et ce n'est que 130 personnes. C'est très intéressant de voir la machine que représente le recrutement.
On a 4-6 personnes qui ne font que gérer les candidats/potentiel candidats. Ils organisent des événements sur les campus pour choper les bons avant la fin des études par exemple.
 
Comme un peu tout, quand tu fais quelque chose à grande échelle, tu dois rationaliser. Ca a ses défauts, mais aussi ses qualités.

Parce que je pense que l'humain c'est pas un truc qui « scale » (nombre de Dunbar, tout ça). Comme je disais, on est pas des robots. À grande échelle, tu scindes en entités plus petites, pour garder une cohésion.

Je suis persuadé que les performances individuelles diminuent dans un « gros système » s'il n'y a pas des « îlots » humains.

Prenons exemple (comme j'aime bien le faire ) sur l'Histoire et la gestion des armées

La tradition prussienne (et de la Wehrmacht plus tard, qui a montré son efficacité, permettez moi de le dire   ) :

• garder le noyau humain, re-affecter les blessés à leurs anciennes unités.
• confier une bonne autonomie aux sous-off (j'en pense pas moins, mais je développe pas ici)

À l'inverse, les ricains, fan de la rationalisation à outrance (héritage du Fordisme ), ont traité les hommes comme des pions qu'on va placer là où c'est nécessaire en terme de pure « comptabilité ». Les résultats ont pas été bon... du tout ! Avec plein d'effets de bords en plus[0].

Bref, mon opinion (qui n'engage que moi   ) est qu'on gère pas bien des hommes à l'échelle industrielle.

edit : c'est bien entendu une démonstration simplifiée de ma pensée, mais je vais pas écrire un roman là dessus (ou alors plus tard, quand j'aurai plus d'XP )

[0] : à lire : la cata de la gestion RH purement comptable des US pendant la guerre du Vietnam, et le résultat calamiteux sur la cohésion des unités : http://www.historynet.com/vietnam- [...] policy.htm

Mais le pire c'est que le processus style Google est super lourd pour une entreprise. Cf. Amazon:
"Our hiring process is extremely intensive and we're still growing at such a rapid pace that many of our engineers are spending 30 to 40% of their time on hiring."

 
Y a facilement moyen de diviser par ~4 le temps nécessaire à évaluer les aspects purement techniques, tout en rendant l'expérience plus raisonnable pour le candidat.

 
Comment ?

 
Tu déplaces le problème du coup, non ? Comment tu gardes la cohésion entre tes structures du coup ?

Cf. ce que je raconte plus haut sur cette page (boîte australienne qui fait des outils de bug tracking, revue de code, collaboration... ).

Temps que j'y ai passé: 4h quand ça m'arrangeait plus une heure sur Skype. Donc pour moi c'était plus pratique qu'une journée d'entretiens sur site. Pour eux ça a leur a coûté même pas deux heures d'un de leurs ingénieurs.

 
Ca remplace un entretien téléphonique, qui ne coute pas plus de 30 min à un ingénieur, pas un entretien sur site.

 
Disons que tu fais moins d'économies d'échelles (structures plus indépendantes). Par contre oui, faut trouver un liant global pour éviter les frictions. Mais je reste persuadé que c'est plus facile de fonctionner en communication intergroupes soudés VS un seul groupe monolithique avec plein d'humains différents à l'intérieur.
 
Tout ça pour dire que les boîtes US ont tendance à tout vouloir rationaliser à l'extrême et en minimisant le facteur humain (c'est le mauvais côté de leur pragmatisme parfois très agréable, qui est poussé à l'extrême).

Je vais me faire l'avocat du diable, mais en quoi Google néglige le facteur humain ?
 
Et tu as du coup un exemple d'une boite non américaine qui suivrait les principes que tu proposes ?

Les boîtes comme la tienne recrutent les profils comme le mien parce qu'elles sont obligées de prendre des risques au recrutement compte tenu des salaires qu'elles proposent. Avec une femme, une ex-femme, deux gosses et un crédit immobilier sur 25 ans je me sens pas de perdre 20 à 30% de salaire pour un job qui me branche.

Ca plus le fait que ça se bouscule pas à la porte pour rentrer

Travail du jour avec 0x90 \o/

Le nouveau Disney pour Noël ?

Sympa le détail en haut à droite  

 
ouh putain ça y est j'ai compris : vous allez ouvrir un stand de lettre au marché de Noël ? et le super panier à fruit taillé dans une pièce de bois qui est tout plat fermé, et qui fait un panier quand on l'ouvre ?

 
1/ encore une fois, l'efficacité d'un process d'un recrutement est jugée par l'employeur (dans le cas quasi toujours existant où il existe plus de gens qui cherchent un job que de jobs). Si t'es content du coût, et que ça amène le type d'employé que tu recherches, le process est bon. Si tu recherches 2 bons dev, et que ton process te permet de recruter 2 bons dev, même si il en rejette 2 qui auraient été très bien aussi, ça reste un bon process
Là où je te rejoins c'est que les process de recrutements tendent à trouver des personnes très homogènes, donc tu perds la chance d'avoir une diversité de groupe. Mais c'est possible à atteindre en faisant attention
 
2/ tu es encore au stade où tu connais et a recruté 100% des gens avec qui tu bosses toi meme. (c'est une chance énorme, j'ai connu ça aussi c'est un luxe inouit). Quand tu seras occupé à dealer 100% avec ton board, et que tu devras avoir un flight controller rien que pour gérer les entrées/sorties de personnel dans ton bureau à cause de la croissance et du turnover, on rediscutera de la policy de recrutement
 
3/ ce que tu décris est une culture d'entreprise : c'est la votre Là encore, je pense que ça fonctionne très bien parce que vous etes petits. Quand t'auras ne serait-ce que 2 sites, ou plus de X personnes, ou si ta boite fusionne avec un autre, etc... ça te sera très difficile de maintenir une culture personnifiée.
Après je trouve que la culture d'entreprise, c'est comme les formations en management : bien appliqué c'est génial, mais quand ça se voit trop qu'on applique une recette c'est dégueulasse, et contre-productif. Bien fait en général c'est souvent crystalisé autour d'une truc où l'entreprise excelle pour de vrai (qualité des produits, innovation, valeur forte transmise par le fondateur ou un des dirigeants historiques notables). Les 2 boites où j'ai bossé avaient ça, et ça marchait bien (chez Volvo les gens étaient fier de faire des produits surs (Volvo a démocratisé la ceinture de sécurité), et chez NN les gens aiment ce que représente la marque, et le fait d'avoir fait une success story en inventant un segment marketing)