Category Archives: General

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 ?

Le meilleur développeur de France: entre fumisterie et imposture

Posted on by
19

Après avoir bien bavé sur Twitter et m’être pas mal gaussé en lisant les échanges du compte @MeilleurDev, je pense qu’il est important de s’attarder plus sérieusement sur deux points importants que soulève ce “concours” et qui m’ont laissé un goût amer en bouche en découvrant l’existence de ce dernier.

# Pourquoi ce concours est une grosse opération mercantile

Fort d’un amateurisme total et évident (Logo dégueu, WordPress minimaliste visible dans l’url, vidéo montée à la va-vite, intonation et musique à la Koh Lanta), ce concours est monté par:

  • une école qui veut racoler du jeune développeur et introniser dans ses locaux le nouveau French Dev Killer 2013 qu’elle aura découvert
  • une agence de recrutement qui va exploiter allègrement les coordonnées de tous les candidats inscrits, présents, perdants ou gagnants
  • une société qui veut installer le TOSA comme une norme universelle d’aptitudes au développement, et qui effectue un remarquable coup de com’ et assoit sa crédibilité si son test sert à nous débusquer le meilleur développeur de France

Ajoutez à cela un tarif plus que prohibitif (~90€ pour les étudiants, ~140€ pour les autres) pour 1 400 candidats max, ce qui nous donne un événement qui rapporterait en moyenne 150k€, pour décerner 10k€ à l’unique vainqueur, et quelques mugs/casquettes/autres goodies aux 30 meilleurs je suppose… Dans des locaux fournis par l’école 42, je doute donc que la logistique et les sandwich triangles coûtent plus de 100k€..

# Pourquoi ce concours est une imposture

Franchement, qui va croire qu’un meilleur développeur de France existe ? Ce concept est profondément faux et non pertinent.

Les développeurs ont leurs forces et leurs faiblesses. Les “bons” développeurs à mon sens ont un profil “T-shaped” (dont je parle dans ce précédent billet) et malgré leur culture G seront bien moins bons qu’un autre dans tel ou tel domaine, tout en étant le killer recherché dans son domaine de choix.

[EDIT: merci aux footix qui ont suivi, la phrase qui suit est bien évidemment fausse..] C’est un peu comme au foot, on élit bien un ballon d’or du meilleur buteur chaque année, pas du meilleur footballer. Elle aurait l’air fine l’équipe composée que d’attaquants (les meilleurs) ou que de défenseurs (les meilleurs). C’est pareil en développement. [FIN EDIT]

Et quand bien même il y aurait un développeur ultime le plus skillé sur tous les fronts, remportant ce concours, il ne m’intéresserait pas pour mon équipe de développement car fort certainement trop rockstar/diva/individuel pour les besoins de ce qui compte vraiment: fédérer une équipe complémentaire de gens doués dans leur domaine, pour construire le meilleur produit qu’il soit.

Voila les raisons de la profonde tristesse que m’a inspiré ce concours. Un événement purement mercantile, totalement faux, mal préparé (dans la forme et le buzz en tout cas), qui très certainement rencontrera un succès suffisant pour satisfaire ses organisateurs et suffisamment pour ternir un peu l’image des développeurs en France, parqués dans leurs immenses salles à faire des tests de merde pour quelques € et quelques goodies, au lieu de réellement mettre à profit leurs connaissances ce jour là pour leurs boites, leur projets open-source, leurs projets persos..

7 conseils pour plomber techniquement votre startup web

Posted on by
9

C’est l’été, il fait beau, les oiseaux chantent, ça sent bon la fin du mois de mai !

Oui, cela fait aussi peut-être un an que je n’ai rien posté ici, j’ai décidé (pour combien de temps ?) de reprendre les choses en main. Aujourd’hui, je vous propose une petite réflexion et 7 conseils tirés de mon expérience personnelle pour bien plomber votre startup niveau techno. Allons-y gaiement:

1 – N’utilisez pas de framework

Je pense que ce point est de loin le plus essentiel. Les frameworks, c’est bien trop hype et sur-évalué. Cela ne sert strictement à rien d’embarquer des milliers de lignes de code dans son projet, et encore plus des milliers de lignes de codes d’inconnus ! De plus, ces frameworks vont vous faire perdre votre précieux temps à coder propre et bien, alors qu’en deux trois coups de cuillère à pot, quelques variables globales et boucles imbriqués bien placés, vous pouvez sortir la vue web qui va bien ! D’ailleurs, c’est sûr que vous coderez mieux avec vos petits doigts boudinés ce que des inconnus ont érigé en plusieurs mois.

2 – N’utilisez pas git (et à fortiori, Github)

Quelle perte de temps que de devoir apprendre des commandes obscures dans votre terminal (heu, c’est quoi un terminal d’abord ?), brancher, forker, rebaser à tout va, plutôt que de vous concentrer à ce qui compte vraiment, votre code, au sein de votre IDE ! De toutes façons, vous êtes en startup, à deux ou trois, débrouillards, vous pouvez bien vous envoyer les fichiers modifiés par email, c’est bien plus pratique ! En plus, en se débrouillant bien, vous n’aurez même pas à travailler en même temps sur les mêmes fichiers. Github, c’est vraiment pour les bobos hipsters du code qui veulent se faire mousser ! FTP FTW sur mon serveur !

3 – Ne perdez pas de temps à écrire des tests

Vous aussi vous avez entendu parler de ces gens qui passent bien 20-25% de leur temps à écrire des tests ?! Parfois même avant d’entamer leur code ? Dingue, non ? Il y en a qui n’ont vraiment que ça à faire. Autant aller travailler dans une SSII s’ils ont autant de temps à perdre ! Allez, zou, un peu de code, une bonne feuille Excel avec quelques tests fonctionnels à refiler à ses stagiaires, et c’est parti, ça marche super bien !

4 – Ne vous souciez pas de la sécurité

La sécurité, c’est pour Facebook ou la NASA. En startup, on en a pas besoin. Qui irait se soucier de nous et nous chercher des noises ? Il est important de ne pas se soucier de la sécurité pour avancer en codant vite. J’ai vu ce tweet circuler hier, qui parlait d’injections SQL en PHP. C’est un mythe ça, ça n’arrive jamais “en vrai”. Imaginez tous ces gens (qui d’ailleurs sont tombés dans le panneau du conseil n°2), s’ils devaient (suivez mon conseil n°1) coder leur ORM ou préparer / sanitizer leurs requêtes. Ils n’avanceraient jamais !

5 – N’utilisez pas de scripts de déploiement

Pour les mauvais élèves du conseil n°2, faites directement un git fetch en prod. Et à la rigueur exécutez quelques scripts / commandes sur la PROD. Mais je ne vous félicite pas ! La vraie solution miracle, c’est le FTP. FTP FTW sur mon serveur. Tellement plus facile de filer les accès à toute votre startup pour aller éditer en live et rapidement ce qui ne va pas sur votre serveur. C’est aussi facile d’envoyer que quelques fichiers remplacer les existants pour fixer vos bugs ou améliorer vos features. En plus, ça marche sur tous les serveurs le FTP, même les hébergements mutualisés ! :)

6 – Ne mettez pas de cache, alignez plutôt des serveurs / instances

Comme pour n°4, le caching, c’est pour Facebook ou Twitter. Franchement, pourquoi s’embêter et se casser la tête à réfléchir à de complexes stratégies de cache alors que ça coute presque plus rien les serveurs ? Commencez avec un petit Kimsufi (2Go de RAM), et si ça ne passe plus, prenez plus gros. Toujours plus gros. En plus, si vous avez bien suivi le conseil n°5, d’un coup de FTP, le tour est joué pour passer sur le nouveau serveur !

7 – Ne travaillez qu’avec des stagiaires ou des agences

Enfin, si vous arrivez à respecter tous les conseils précédents, faites vous ce cadeau: ne prenez que des stagiaires ou des agences à la rigueur. Mais ne perdez pas de l’argent à payer cher des développeurs qui se prennent pour des rockstars du code, qui ne comprennent rien au business, et qui vont vous faire perdre du temps à configurer des environnements de travail, retoucher des alignements et fixer des virgules ! Hop hop hop, ni une, ni deux, un cahier des charges, un feuille de recette (conseil n°3), un accès FTP à votre serveur de dev (ou prod?) (conseil n°5), et roulez jeunesse !

Voila, c’est tout. Je crois qu’avec ça, vous allez être parés désormais pour bien bien looser dans votre startup, et pouvoir dormir sur vos deux oreilles ou boire des coups avec vos associés en shippant rapidement du garbage tout en contentant vos clients ou utilisateurs à court (voire très court) terme.

Disclamer: ce billet n’est pas une fiction. Je suis moi-même passé par une bonne partie de ces points, et pu constater les autres au sein de startups de connaissances. Malgré le ton léger, ce billet est bien entendu à comprendre à l’envers (sinon, je vais avoir toute la profession et les associations sur le dos), et je vous encourage à partager vos expériences à ce sujet dans les commentaires.

Enfin, ceci doit probablement être mon premier billet depuis de longs mois (années ?) d’inactivité, veuillez m’excuser pour cette absence. Et si par ailleurs, vous avez des idées de sujets à traiter que je pourrais éventuellement couvrir, n’hésitez pas à m’en faire part dans les commentaires ou par email. Merci ! :)

Je suis désormais une minorité représentée.. (a #geonpi imposture)

Posted on by
1

Beaucoup d’encre a coulé, et beaucoup de débats ont déjà été menés à ce sujet. À n’en point douter, c’est désormais une affaire d’état, la fronde des “pigeons” ne manque pas une occasion pour vociférer et se pavaner à la télé. Amusant aux premiers abords, je trouve que face à tant de véhémence et de revendications de basse-cour, rapidement ce mouvement a pris du plomb dans l’aile et j’ai bien peur en fin de compte que les “vrais” entrepreneurs en fassent les frais et deviennent les malheureux dindons de la farce. Mon sentiment à ce sujet n’est pas clairement tranché, c’est pourquoi j’ai mis un peu de temps à réagir, observant de loin tout d’abord la fronde des volatiles et les revirements/chavirements de ce gouvernement de femmes et d’hommes “normaux”. Entre ces deux points de vue, mon coeur balance:

Schizophrène moi? :) Non je ne pense pas. Continue reading →

Post léger d’été #1: utilisez des frameworks (et choisissez-les bien)

Posted on by
1

Après un vide intergalactique de quelques mois sur ce blog, dû aux moult péripéties Balloonesques de ces derniers temps, j’ai eu l’envie de faire un gros post bien indigeste mais racoleur inspiré de mes “erreurs” commises dans ma startup et si possible à éviter à l’avenir, du genre, “les 10 erreurs tech à éviter en lean startup” (ok, ce n’est peut-être pas tant racoleur que ça en fin de compte..). Je me suis dit ensuite qu’il serait peut-être plus sympa et léger de distiller ces erreurs à éviter tout au long de cet été, sous forme de saga, a lire au bord de la piscine ou sur le sable chaud d’une plage ensoleillé..

 

Episode #1: choisissez bien et utilisez des frameworks

Lorsque j’ai commencé ma startup, en mode vraiment vraiment lean (j’entends par là que nous avions 2 mois pour sortir le premier MVP de Balloon et pas une seconde de plus, car vendu déjà à deux clients prestigieux et qu’on n’avait donc pas droit à l’erreur ni au retard), j’ai été tenté “pour aller vite” de coder en natif sous “framework maison” la solution. Mes arguments étaient les suivants: Continue reading →

Saas et B2B: rien ne sert d’innover sans compatibilité

Posted on by
3

Je viens récemment de faire les frais d’une évidence accablante: faire du Saas pour des clients B2B et des grosses boites du CAC, c’est bien plus contraignant et complexe d’un point de vue techno et interopérabilité que de dealer avec des utilisateurs lambda dans leur canap’ derrière leur Freebox ou Livebox..

Imaginez vos utilisateurs, bloqués sur Internet Explorer 7 ou Firefox 3, sans aucun pouvoir de changement (pas les droits d’admin, c’est ballot..) sous 5 couches de pare-feux d’entreprises plus méchants et débiles qu’utiles (je connais un admin sys qui veut pas d’ennuis, et qui par précaution, bloque tout..).
Dès lors, deux possibilités s’offrent à vous: Continue reading →

Quelques conseils pour rendre votre startup plus developer-friendly

Posted on by
Reply

Comme le montrent les réactions du précédent billet, un bon (voire un excellent) développeur ne rejoindra pas votre startup juste pour vos beaux yeux, trois nèfles, quelques pizzas et quelques bières. C’est sur ce point que nous avons décidé de plancher avec Guilhem cette semaine: comment rendre votre startup plus développeur-friendly ?

Une vraie situation d’équilibriste : comment, avec des moyens financiers limités et plein de batailles onéreuses à mener de front, valoriser le travail de vos développeurs, les gratifier à hauteur de leurs succès, de leur importance pour votre startup et les mettre dans les meilleures conditions possibles pour qu’ils produisent le meilleur d’eux-mêmes tout en « kiffant » réellement leur job? Attention, je ne dis pas ici de ne pas les payer, ni de les sous-payer! C’est un autre débat, si vous n’avez pas de sous, associez-les au projet, au capital, et il ne s’agit plus là d’employés mais de fondateurs qui prennent 100% des risques avec vous sans salaire. Ja parle ici de vos premiers réels employés, que vous payez, mais que vous ne pouvez engraisser honteusement comme peuvent se le permettre nos fameuses SSII, Web Agencies, banques, boites du CAC40 et consorts..

Je vous invite à lire la suite de cette réflexion co-écrite avec Guilhem sur son blog.

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 →

3 petits conseils aux wanabe entrepreneurs (Interview Business-Actor.com)

Posted on by
Reply

La semaine dernière j’ai eu la chance de re-croiser une bonne connaissance, @Flo__Hernandez, qui non content d’être un street-hockeyeur émérite, tiens désormais quelques bon blogs dont le récent http://business-actor.com/

Je vous invite à lire mon interview sur business-actor pour en savoir un peu plus sur Balloon surtout. En attendant et si ça peut vous aider à aller la lire en entier, voici une question extraite de cet interview:

FH : Si tu avais 3 conseils à donner aux jeunes entrepreneurs qui vont lire cette interview, quels seraient-ils?

GP : Ces conseils sont bien évidemment tintés de mon expérience chez Balloon, mais cela serait plutôt ça :

  • Ne vous lancez pas seul ou mal accompagné, cherchez des profils complémentaires
  • Croyez impérativement à votre vision et votre produit : c’est l’unique chose qui vous fera tenir dans les moments durs. Monter sa startup ce n’est pas pour être riche, aménager ses horaires ou faire uniquement ce qui plait : ces points en découleront avec un peu de chance si vous avez eu raison dans votre vision et que vous vous y êtes accrochés jusqu’au bout.
  • Parlez. Beaucoup. A votre famille, à vos amis, à de potentiels clients, à d’autres jeunes entrepreneurs. Vous êtes en terrain inconnu, pas besoin de faire signer de NDA et de développer secrètement votre idée dans votre garage. Prenez tout le feedback que vous pourrez récolter. Adaptez, pivotez si besoin.

 

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 ;)