Tag Archives: équipe

Faites coder vos futures recrues (une journée entière, en conditions réelles)

Posted on by
22

Cela fait quelques fois désormais qu’en discutant recrutement tech deci delà avec d’autres startupers / CTOs je me rends compte que mon process se démarque un peu et dénote parfois avec originalité par “sa journée test”.

Je ne pense pas avoir là trouvé la solution idéale, puisque malgré cela je n’ai pas fait que des recrutements heureux, parce que cela prends du temps et que ce n’est pas adapté à toutes les typologies de boîtes (cela marche pour nous en tout cas en ce moment), mais je pense que cela vaut le coup d’être tenté au moins pour quelques profils clés.

Dans mon process type de recrutement, il y a tout d’abord une phase amont où on apprends mon candidat et moi à se connaître sur le papier, puis ensuite lors d’un premier entretien. Là, je présente de la façon la plus limpide et franche ce que nous faisons, là où nous sommes bons, là où nous sommes mauvais, comment nous fonctionnons, et surtout, ce que j’attends du candidat pour le poste en question : pour pas qu’il n’y ait de zones d’ombres pour le candidat, sur l’environnement de travail et la mission envisagée. Et aussi pour le mettre en confiance en commençant à parler. Là, j’attends ensuite qu’il joue cartes sur table et me montre via des projets (open source, perso, pro, académiques) ce qu’il sait faire, ce qu’il aime faire, ce qu’il aime moins faire, et ce qu’il aimerait faire. Je pense qu’à cet entretien, j’essaye de jauger durant 40% du temps de l’entretien les compétences techniques de mon candidat, et le reste du temps sa personnalité, sa motivation, et le fit potentiel pour l’équipe. Et aussi occasionnellement ses “prétentions salariales” ;)

En général, sur 10 candidats initiaux, deux réellement se démarquent et m’intéressent suite à ce process. C’est à ce moment là que je propose une journée de test en condition réelle dans nos locaux.

L’intérêt de cette journée est double:

  • Pour le candidat : ça lui permet de voir réellement la qualité du code, des développements, de ses futurs collègues et l’ambiance de la startup durant toute une journée. Ce point est très important pour moi, car c’est à mon sens un raison majeure des mauvais recrutements: de fausses / mauvaises promesses (involontaires la plupart du temps) à l’embauche qui vont rapidement démotiver le développeur une fois in situ.
  • Pour moi recruteur, mais aussi pour mes développeurs, c’est le moyen de tester le candidat en live / en pair coding sur des réels problèmes de codes de la solution. Cela ne me sert pas à grand chose à priori un cador dans un domaine si au bout d’une demie journée je ne le vois pas force de propositions ingénieuses (pas forcément correctes hein) sur une réflexion réelle et business appliquée à mon cas réel. Certains candidats performent étonnamment bien sur des entretiens amont et des problèmes “types” d’entretien, et sont relativement “plats” en vrai. Cette journée permet aussi de jauger de la rapidité d’assimilation / réflexion / implémentation / proposition d’idées du candidat, en situation réelle toujours. C’est un point important que j’ai toujours trouvé difficilement quantifiable sans cette journée de test. Enfin, cela me permet de récolter plusieurs points de vue suite à cette journée, ceux de mes développeurs (trouvent-ils qu’il a le niveau ? se voient-ils travailler avec lui ?) et même ceux de mes commerciaux, ou tout autre domaine-related employé de la boite. Une nouvelle recrue dans une équipe, c’est certes un nouveau profil qui doit correspondre à une certaine attente, un certain profil, mais aussi une pièce de puzzle qui doit s’assembler avec les existantes déjà présentes, et cela a parfois autant de poids que la nouvelle pièce en elle-même.

Attention, cette journée est une journée bien huilée et préparée. Sans un minimum de préparation, cela ne servirait pas à grand chose, et serait plus une perte de temps. On ne catapulte pas un nouveau venu n’importe comment dans l’arène ;)

Le programme :

  • Bien souvent, je fais un petit tour du propriétaire avec le candidat, aussi bien au niveau de l’équipe que de l’archi et de certains bouts de code. Cela dure une petite heure.
  • Le candidat va ensuite rejoindre la team qu’il serait amené à compléter, et va cotoyer chaque dev de celle-ci entre 30 minutes et une heure. Ce temps sert pour chaque dev à expliquer son quotidien, et passer un peu de temps en pair coding afin de challenger le candidat et le jauger, chacun un peu à sa sauce (certains sont plus vicieux que d’autres, et bien plus souvent que moi).
  • Tout cela nous porte généralement au déjeuner tardif (14h): là c’est l’occasion pour une grande partie de la team de partager le repas avec le candidat et de se détendre autour d’un ping pong.
  • Suite à cela, il reste 1-2 heures de travail où le candidat est placé seul sur un sujet qu’il aura abordé et auquel il aura été “formé” par un autre dev le matin, afin de le continuer seul et de jauger en fin de journée sa rapidité, sa rigueur, sa technicité.

Cela fait une journée bien remplie, pour le candidat comme pour moi, où je dois trouver le plus de disponibilité au sein de mon équipe et avec un ou deux challenges techniques accessibles pour ce candidat (une matinée pour apprendre et s’immerger en pair coding, une aprèm pour y travailler seul).

Cela doit facilement prendre 4 heures de temps homme à la boite au niveau de la salle dev, 3 heures de “formation”/”culture gé” dispensé au candidat, et 2-3 heures de travail “effectif” réalisé par ce dernier. Il est à noter que cette journée n’est jamais rémunérée (mais dédommagée niveau transport et dejeuner) et que le travail effectué par le candidat est rarement repris (car même si le travail est bon, il ne sera jamais suffisant en l’état pour intégrer la branche principale, sans être lourdement refactorisé, et par conséquent, souvent repris from scratch par un des devs de la team).

Et vous, avez-vous ce genre de journée dans vos process de recrutement ? Avez-vous d’autres “curiosités” notables ?

Ce complot mondial des hackathons

Posted on by
6

Mon ami Liam a récemment jeté un pavé dans la mare avec ce billet au sujet des hackathons et introduisant son nouveau concept de coding in the dark.

Je n’ai pas souvenir d’avoir lu déjà (si vous avez de bonnes ressources, je suis preneur) de point de vue similaire à ce sujet, et une telle vérité sans masque ni hypocrisie:

Let’s face it. Hackathons suck. I’ve been to about a dozen of them, as a developer, as a mentor, as a jury member, and as press. Here’s what I’ve noticed.

Developers just want to code, but they have to pitch a business at the end. Juries just want to meet developers, but they get stuck with some B-School student talking about viral engagement and the mobile revolution. And Sponsors – well, Sponsors, after a weekend of hocking your company, you get the stiff reward of knowing that the 3rd place winner and the runner up for best UX used your API. Congratulations.

Pour avoir participé / suivi / sponsorisé des rendez-vous de la sorte, au bout d’un certain temps je suis arrivé à un constat similaire. Ces hackathons, qui, sur le papier, sont une bonne initiative pleine de bonne volonté et éventuellement de potentiel fun, business, etc. sont à mon sens souvent une perte de temps pour les participants et une bonne intention maladroite de la part des organisateurs.

Les bonnes idées/valeurs sur le papier du hackathon :

  • Se sortir les doigts du c** et taffer pour faire des rencontres et gagner en XP, en apprendre plus sur soi même en équipe et temps limité
  • Valider une idée business, faire adhérer des personnes / adhérer à une idée business et travailler dessus avec des personnes
  • Rencontrer de potentiels co-founders de tous horizons
  • Apprendre : en général et sur soi-même

Et je dois en oublier quelques unes.

Les (plus réelles) vérités de la plupart des hackathons :

  • Des teams bancales (90% de devs ou 90% de biz/produit)
  • Des sites statiques (limite powerpoint) qui ne prouvent rien niveau techno ou produit
  • Du crappy code spaghetti qui a juste fait perdre un week end à des devs et qui ne leur a rien appris
  • Des bizguys persuadés de tenir l’idée du siècle et qui perdurent des mois sur l’idée bancale trouvée du week end (et qui sortent le sempiternel “go viral” pitch)
  • Une horde de rapaces qui gravitent au sein de l’écosystème startup et qui cherchent de nouveaux pigeons à encadrer / mentorer dans leur projet et projets futurs (moyennant finance, parts de boite, etc..)
  • Des serials hackathoniens drogués qui se font leur fix et que l’on retrouvera au prochain sur une idée nouvelle (et peu évolué entre les deux)
  • De la fatigue, du bruit et pas de tant de fun que cela

Et je dois en oublier à nouveau quelques unes.

Et tous les gens qui auront perdu leur week end diront le lundi matin à leurs collègues qu’ils ont taffé sur un truc énorme, avec une team sympa, une organisation en or, des gens très intéressants et intéressés par eux et leurs projets avec qui ils ont gardé contact: et rejoindront ainsi le complot mondial des hackathons..

Bon, ok, je force un peu le trait.. Tous les hackathons ne sont pas tous mauvais, bien entendu :)

Les hackathons sont sur le papier une bonne idée, mais chaque personne doit en amont bien cibler son hackathon en fonction de ce qu’il recherche et de son niveau de connaissance startup / technique, sous peine de ne pas trouver ce qu’il recherche et perdre son temps.

  • Pour les tous novices, un petit hackathon “général” (startup weekend, bemyapp..) est un bon moyen de rentrer dans le bain startup. Pour des bizguys tous frais et des devs troglodytes, c’est l’occasion de se frotter un peu les uns aux autres et de faire connaissance, de voir comment travailler ensembles. Mais ce n’est pas là que vous trouverez (sauf exception) votre prochaine team et idée startup. N’en abusez pas, un ou deux suffisent, après c’est de la pure perte de temps. Sortez différemment.
  • Pour les plus expérimentés et pour les profils plus techno/produit, les hackathons plus “spécifiques/spécialisés” (hackathon sur une techno donnée, sur une API donnée organisés par une boite (Eg: Twitter, Dropbox, Foursquare), sur un framework donné) seront eux l’occasion d’apprendre réellement plus et d’aller plus loin: pour le coup, des possibilités réelles d’embauches sont là à la clé et une bonne émulsion techno / produit au rendez-vous avec des gens moins novices. On rentre plus dans le sujet.. Par contre ça ne sera pas là que vous rencontrerez le plus de variété de profils, et bizguys vous risqueriez de vous ennuyer un peu.
  • Enfin, fuyez comme la peste tous les hackathons mercantiles à la “Meilleur développeur de France” et consorts qui ne seront que perte de temps et d’argent !

Et vous, quelle est votre expérience / ressenti sur les hackathons que vous avez pu faire ? Faites vous partie du complot modial ?

Les différentes vies d’un CTO (en startup bootstrap)

Posted on by
5

Ce week end, je discutais avec Nicolas, Lead Dev d’une petite startup Belge qui endosse désormais le costume de CTO alors que sa start up recrute et étoffe son équipe technique. En réfléchissant aux différences de responsabilités, de travail au quotidien que cela occasionnerait, cela m’a donné à réfléchir à mon parcours depuis ces 2 dernières années à mon poste de CTO.

So far, je distingue 3 phases différentes pour ce poste, dépendant très fortement de la taille de la société, de son/ses produits, de sa croissance et de l’équipe en charge de la technique. Trois vies donc, deux que j’ai vécu ou que je vis actuellement, et une troisième dont je commence seulement à dessiner les contours.

Continue reading →

Soyez agiles, mettez des process!

Posted on by
1

Je pense que vous l’avez assez lu ou qu’on vous l’a assez répété, ce qui fait qu’une startup bien souvent tire son épingle du jeu c’est une pincée d’idée, un zeste d’équipe et une bonne dose d’exécution. Et l’exécution, quand on est une toute petite équipe, avec peu de moyens, une multitude d’idées et peu de temps, elle dépend de l’organisation et la rigueur que l’on va instaurer. Cela peut paraitre étrange voire paradoxal pour une startup qui se veut innovante, révolutionnant le monde et créative, mais une startup qui réussit est une startup qui met en place très tôt des process. Quand j’écris process, je ne parles pas de réunions interminables, de hiérarchie faisant pâlir un arbre généalogique, de points, de re-points, de rapports, etc… panoplie exacerbée des grosses boites type CAC40, mais de moyens/méthodes/outils simples et assez rigoureux qui permettent au petit monde d’une startup d’avancer droit, efficacement, focus et agilement.

L’agilité. Voilà dont il est question. Et cette agilité est cruciale lorsqu’on en vient à développer une solution technique avec peu de moyens, de budget une un grande ambition. Continue reading →

6 conseils pour mettre en place la méthode Scrum dans votre startup (pas plus)

Posted on by
Reply

Que d’activité blogistique après deux semaines d’abstinence (avec un déménagement de Balloon notamment, 115m2 de bureaux à repeindre, re-moquetter et meubler, rien que ça.. )!

Je vais essayer de reprendre le rythme d’écriture que je m’étais initialement fixé, à savoir un à deux (trois?) billets par semaine. Et cette semaine cela commence fort, avec un premier billet ce matin ci-dessous ainsi qu’avec un billet commun sur le célèbre blog de Guilhem Bertholet, qu’on ne présente plus: anciennement responsable de l’incubateur HEC Paris et désormais à full time sur sa nouvelle startup qu’il nous concocte aux petits oignons, nous avons eu l’occasion de discuter de nombreuses fois aux apéroentrepreneurs notamment (comment, vous n’y allez pas? C’est un tort ;) ) ainsi qu’au sein de l’incubateur sur les mêmes sujets qui nous animent (et là je reprends ses mots): “avancer le plus vite possible, avec des ressources limitées, parfois dans le brouillard et en tout cas en devant innover sans cesse…”.

Je partage dans ce billet ma mise en place simple et efficace du modèle Scrum pour la gestion de mes équipes de développement au sein de Balloon. Pas de recette magique, juste un petit retour d’expérience et un appel à une mise en pratique rapide. Guilhem agrémente fort bien cela de sa vision et méthodologie business qui vient encadrer / accompagner le Scrum avec le reste des équipes, au sein d’une Lean Startup.
Bref, déjà un must read ici!

PS: n’hésitez pas à laisser ici ou sur le blog de Guilhem vos commentaires, sur l’article comme sur l’éclairage que cette écriture à 4 mains a pu apporter ;)

Développement web: tenez vos délais! (ou tout du moins, essayez..)

Posted on by
5

Je profite de l’excellente réponse de Michael Wolfe qui buzz pas mal sur Quora à la question “Pourquoi la majorité des développements informatiques explosent régulièrement le planning prévu d’un facteur 2 à 3?” pour me pencher à mon tour sur celle-ci et essayer d’apporter quelques pistes qui jusqu’à présent semblent ne pas trop mal fonctionner.

Comment planifier au mieux les développements de sa solution et de ses différentes versions/features afin de tenir au mieux les délais engagés? Cette fameuse question, je pense que tout entrepreneur y a déjà été confrontée et y sera confronté en permanence tout au long de son aventure.

Il s’agit là d’une question relativement cruciale à ce niveau, car contrairement à de plus grosses entreprises, le retard des développements en début de vie d’une entreprise sur ses releases peut avoir des conséquences désastreuses… Contrairement à une grosse entreprise toujours, il est impossible souvent d’obtenir des subventions supplémentaires, d’ajouter des développeurs à l’équipe tirant la langue pour compenser/rattrapper le retard ou de commercialiser quoi que ce soit en attendant la fin du projet.

Voici quelques pistes qui méritent je pense d’être explorées et adapter en fonction de sa startup pour essayer de mieux gérer cela: Continue reading →