On trouve trop d’articles sur le net décrivant les choses à faire pour réussir sa startup mais par contre on ne trouve pas d’article pour les entrepreneurs qui voudraient rater leurs startup donc j’ai décidé de combler ce manque.

Comme le dit Gilles Babinet, “réussir sans échec, (mais) c’est comme trouver de l’or du premier coup de pioche.”. Derrière beaucoup de projets à succès se trouvent des entrepreneurs qui ont planté plusieurs projets/startup dans le passé. Et comme les Shadok l’ont fait remarquer il y a des 10aines d’années : “La probabilité de réussir la mise sur orbite d’une fusée est d’une chance sur un million. Dépêchons-nous de rater 999.999 lancements !” et “en essayant continuellement on finit toujours par réussir. Donc plus ça rate, plus on a de chance de réussir.”

Alors plus vite vous planterez vos premières boîtes, plus vite vous aurez votre startup gagnante !

Maintenant rentrons vite dans le vif du sujet, voilà mes conseils pour rater à coup sûr votre startup:

Développez votre projet en sous-marin le plus longtemps possible

La plus grosse erreur que vous pourriez commettre serait de sortir votre projet trop tôt, et une fois qu’il sera sorti, il sera trop tard pour faire machine arrière. Le plus sûr est donc d’attendre le plus longtemps possible avant de le sortir. Développez le maximum de features, peaufinez au maximum, faites, refaites jusqu’à ce que ça soit parfait. Comme cela, le jour de la sortie, tout le monde sera ébloui, impressionné et pleurera même de joie à la vue de votre projet si parfait et révolutionnaire (on appelle cela le WOW effet, aucun rapport avec world of warcraft)

Avant, pendant et après, n’écoutez surtout personne

Tout le monde le sait, quand on se lance dans un projet innovant, les autres ne comprennent jamais rien et ne voient jamais le potentiel hallucinant et révolutionnaire des projets, même si on leur prouve par A+B pendant des heures… donc pas la peine d’écouter avant de vous lancer. Une fois le projet lancé, on sait aussi que les clients ne sont jamais contents et ne comprennent jamais rien non plus, donc pas la peine de perdre du temps à les écouter non plus.

Attendez que le besoin devienne indispensable pour recruter la première personne venue

J’avais déjà écrit un article il y a quelques années sur comment recruter un mauvais ingénieur informatique. Il s’applique en fait bien pour recruter tout type de personne. Vous êtes à la pointe de l’innovation, vous n’avez pas le temps d’attendre, quand il vous faut quelqu’un, il faut que ça soit tout de suite donc le plus sûr est de lancer une annonce, attendre une semaine (voir même quelques jours) et choisir un de ceux là. Après tout, si les gars mettent plus d’une semaine à postuler, c’est bien qu’ils ne sont pas si intéressés que ça par votre projet. Prenez le CV qui vous impressionne le plus, et limite, engagez-le sans même le voir, après tout, votre temps est trop précieux pour faire ce genre de basses besognes.

Soyez innovant dans tout ce que vous faites

Avoir un projet innovant, c’est la base, mais il faut aussi prendre le dernier langage de programmation à la mode que personne n’utilise encore tellement il est révolutionnaire. Un OS, des frameworks, des lib, des outils de la même trempe. Bref, multipliez les risques dans tous les domaines, plus il y aura de risques plus votre succès forcera le respect.

Ne pensez pas à comment vous gagnerez de l’argent

Ça c’est évident, je me demande même pourquoi j’en parle. Votre projet sera utilisé par des millions, voir des milliards de personnes, donc un petit bandeau de pub et vous serez millionnaire en quelques jours (voir quelques heures). Pas la peine donc de vous casser la tête à faire payer les utilisateurs ou réfléchir à d’autres systèmes pour gagner de l’argent.

Voila, je pense que ces 5 recommandations sont un bon début pour arriver à vos fins et si par malheur vous appliquez ces règles et que votre startup est quand même un succès, n’hésitez pas à me contacter, je vous enverrai de plates excuses.

Honnêtement, je ne pense pas que plus de 5 % des entreprises savent recruter des programmeurs. Depuis que je suis dans la vie active (une demi-douzaine d’années), je n’ai dû en croiser qu’une qui savait vraiment bien le faire, qu’une ou deux où il y avait de l’idée et tout le reste, c’était du grand n’importe quoi.

Tout d’abord, il faut définir ce qu’est un “bon programmeur”. Selon moi, avoir un diplôme reconnu n’est pas un critère, connaître par coeur les puissances de 2 jusqu’à 2 puissance 32 non plus. Je définirais un bon programmeur comme quelqu’un d’extrêmement curieux, qui maîtrise ce qu’il fait, qui a une très bonne capacité d’écoute et de résolution de problèmes techniques. Il doit aussi être capable de se remettre en question, aimer travailler en équipe et être capable de finir ce qu’il commence.

Dans les 95 % des entreprises, on est confronté à l’un de ces scénarios :

- Si l’entreprise a de la chance, quelques bons ingénieurs vont être recrutés par erreur et se retrouveront au milieu d’une grande majorité d’ingénieurs qu’ils trouveront incompétents. Ces bons ingénieurs ont toutes les chances de vite quitter la société, car un bon ingénieur a besoin de trouver dans son environnement de travail des gens au moins aussi bons que lui. La société ne se retrouvera donc rapidement plus qu’avec des ingénieurs de niveau moyen ou mauvais et cela reviendra au cas suivant.

- Si l’entreprise n’a pas de chance, elle ne recrutera que des ingénieurs moyens ou incompétents. Pour que cela fonctionne quand même un minimum, la solution choisie est souvent de les encadrer de très près par des managers. Le problème est que ces managers n’ont aucune raison d’être mieux recrutés que les ingénieurs et donc sont du même niveau de compétence. Il faut alors mettre en place une énorme hiérarchie où tout le monde surveille tout le monde et où personne n’ose plus rien faire de peur de se faire taper sur les doigts par son chef… Dans ces entreprises, les managers mettent alors en place des méthodologies très lourdes et complexes avec beaucoup de paperasse, de planning, etc., pour essayer de se protéger en cas de problème et pouvoir rejeter la faute sur quelqu’un d’autre. On pourrait croire que ce genre de scénario n’arrive que dans les grosses sociétés, mais j’ai pu rencontrer des PME avec ce schéma (par exemple 6 ingénieurs pour 4 managers). Autant dire tout de suite, dans ces entreprises, les ingénieurs n’ont aucune reconnaissance. Ils sont vus comme le bas de l’échelle, les ouvriers, les moins bien payés, ceux qui sont à l’origine de tous les problèmes (retards, bugs, mauvaise qualité, …). Ils sont souvent considérés comme des gens qu’on peut remplacer comme on remplacerait une roue sur une voiture. Bref, il est évident que l’effet le plus indésirable de cette organisation est que l’ingénieur se trouve à détester sa position et va tout faire pour, soit partir, soit monter dans la hiérarchie pour gagner plus d’argent et arrêter de se sentir un moins que rien. Évidemment, on va vite se retrouver avec une énorme compétition entre ingénieurs, car le nombre de place de chef est inférieur au nombre de place d’ingénieur (enfin normalement). Ca crée alors des conflits d’intérêts, des histoires politiques entre équipes et les ingénieurs passent plus de temps à essayer de bien se faire voir par leurs chefs plutôt qu’à faire du bon code. Autre problème, c’est l’organisation idéale pour rencontrer le principe de Peter.

Dans ce genre d’entreprises, passer aux méthodes agiles où n’importe quelle autre méthode ne servira à rien, car c’est un problème de fond, un problème culturel où seule une prise de conscience de la part du boss peut prétendre à une amélioration. Mais même dans ce cas, il serait très long et très compliqué de faire des changements de fond, car cela nécessiterait forcément des licenciements, de remettre des managers en programmeurs et souvent les esprits sont trop habitués à la culture de leur entreprise et considèreraient ça comme un affront. Bref, je ne pense pas que ça soit réellement possible de changer une culture d’entreprise, car les personnes sont recrutées en général parce qu’ils partagent justement cette culture.

Maintenant, prenons le cas des 5 % restants (et encore, je crois que je suis gentil, je dirais plutôt 1 %), ce sont des sociétés où le recrutement est une partie primordiale et ils feront tout ce qui est nécessaire (ne pas céder à la pression, mettre les budgets et le temps nécessaire) pour ne pas laisser entrer dans leur société des individus qui ne correspondent pas. L’idée de base est la suivante : “On ne recrute que des gens vraiment intelligents, ou on ne recrute pas.” Dans ce genre de société, le recrutement est permanent et maximal. Permanent, car ces ingénieurs vraiment intelligents sont difficiles à trouver et souvent déjà en poste, si on ne recrute que 2 mois dans l’année, la probabilité de tomber dessus est très faible. Maximal, car pour être vu par les meilleurs, il faut se faire voir. C’est exactement la même chose que pour vendre un produit à un client sauf que dans ce cas, le produit c’est la société et le client est l’ingénieur talentueux. Et comme ils savent qu’ils sont bons, ils sont difficiles et veulent aller dans des sociétés où ils se sentiront vraiment bien. Comment réussir toucher ce genre de personnes mériterait un sujet à part entière (JoelOnSoftware en à déjà parlé). Cela n’est pas gratuit, ça coûte même cher à une entreprise aussi bien en temps (car il faut des gens pour faire passer les entretiens) qu’en argent. Mais c’est un investissement qui sera extrêmement rentable sur le long terme.

Une fois que vous avez réussi à attirer les meilleurs, il faut savoir faire le tri et c’est là qu’intervient l’entretien. Comment faire passer un bon entretien ? Encore une fois, ça mériterait un article complet (vous pouvez lire ça).

Supposons que la structure est en place pour ne recruter que des bons ingénieurs, qu’est ce que ça change ? Tout d’abord, vous pouvez avoir une confiance beaucoup plus importante dans ces personnes. Vous n’avez pas à fliquer leurs horaires de travail (ils en feront même surement beaucoup plus que la normale sans même le demander), à vérifier s’ils bossent vraiment ou s’ils se tournent les pouces, etc. Bref, vous pouvez alléger au maximum la hiérarchie. Du côté des ingénieurs, ils sont beaucoup plus contents, car ils sentent qu’on leur fait confiance, ils sont beaucoup plus libres et le résultat est qu’ils bosseront beaucoup mieux et qu’ils ne voudront pas aller voir ailleurs. En plus, ces ingénieurs se retrouvent avec d’autres bons ingénieurs, ils se comprennent, s’entraident, se respectent plus facilement. Ils ne vont pas se prendre la tête pour savoir s’il faut mettre des espaces ou des tabulations, s’il faut faire des tests unitaires ou pas, car ils sont assez intelligents et ont assez d’expérience pour savoir ce qu’il en retourne et où se situent les vrais problèmes.

Donc dans ces sociétés, la hiérarchie est réduite à son minimum, il y a des ingénieurs qui programment, des lead ingénieurs qui sont aussi très techniques, mais qui peuvent facilement gérer 10 à 20 personnes, car les méthodes de travail peuvent elles aussi être très simplifiées. Pour que cela fonctionne, il faut évidement savoir mettre l’argent où il faut, par exemple ne pas lésiner sur les locaux, les ordinateurs, les tables, chaises, etc. Plus l’environnement sera agréable, plus il y a de chances que l’ambiance y soit bonne et donc que les gens y travaillent bien.

Ça peut paraître simple de mettre en place ce genre d’équipes, mais ce n’est clairement pas le cas. Tout d’abord, les lois de la concurrence, la pression des investisseurs, le manque d’ingénieurs sur le marché du travail font que les boss ont souvent tendance à vouloir recruter au plus vite, quitte à ne pas suivre la règle de base en pensant qu’après tout, ce n’est pas si grave que ça, on verra plus tard. Au début, ça marche bien, car la boite est petite, mais au fur et à mesure que des personnes peu compétentes arrivent, les problèmes arrivent par la même occasion et l’entreprise tombe dans les 95 %. L’autre problème est que les fondateurs/boss ont beaucoup de mal à mettre de l’argent sur quelque chose qui n’est pas rentable à très court terme (le problème du bûcheron). Ils prendront les chaises premier prix qui font mal au dos sans penser que derrière cela augmentera le turn-over (qui veut passer 8 heures ou plus sur une chaise inconfortable?) qui au final coûtera beaucoup plus cher que d’avoir mis des fauteuils corrects dès le début (l’exemple de la chaise vous parait peut-être exagéré pourtant c’est du vécu et des histoires comme celle-là, j’en ai vu tellement d’autres…).

Le meilleur exemple d’entreprise qui utilise la 2ème méthode est Google. Bizarrement, ils sont devenus la boite la plus recherchée par les ingénieurs et c’est aussi une société qui fait beaucoup d’argent. Je suis convaincu que leur réussite tient d’abord à leurs méthodes de recrutement et leur culture d’entreprise. Je suis aussi convaincu que même s’ils n’avaient pas eu l’idée de faire un moteur de recherche ou un business sur Internet, ils auraient obtenu un résultat similaire dans une autre industrie.

Vous allez me dire que c’est facile pour eux, ils ont énormément argent, mais ils ont commencé à moins de 10 personnes et ont tout bâti eux même. C’est avant tout leur façon de construire la société (et donc l’équipe) qui leur a permis d’arriver là où ils sont aujourd’hui.

Un autre exemple d’une entreprise qui suit ces principes est FogCreek. C’est une petite société qui ne fait que grossir, doucement, mais sûrement. Ils ont un peu la même philosophie que Google, mais avec seulement une 20aine de personnes. Cette boite a toujours été rentable. Ils suivent la règle d’or qui dit que si on recrute les bonnes personnes, quel que soit le projet qui sera choisi, il sera rentable. Et ils le prouve par exemple avec leur bugtracker. Il existe des 10aines de bugtracker différents, dont beaucoup de gratuits, mais bien que le leur soit payant il se vend bien et suffit pour faire vivre la société.

Tout ça pour dire que le processus de recrutement commence dès les premiers jours de la vie d’une entreprise et que de mauvaises méthodes de recrutement risquent d’entrainer par la suite de gros problèmes qui ne pourront pas être rattrapés. Malheureusement, c’est aussi la période où il y a tellement de choses à faire que le recrutement des programmeurs peut être mis au second plan où alors les conséquences du choix de mauvais programmeurs sont clairement sous-estimées.

Je rêve un jour de pouvoir rencontrer des créateurs d’entreprises français assez ouverts pour pouvoir comprendre l’intérêt et le potentiel énorme de ces nouvelles façons de construire et gérer une société informatique. Si vous pensez en être un, n’hésitez pas à me contacter, je serais ravi d’en discuter plus longuement !

Quand on est chômeur, tenir un blog est une nouvelle méthode originale pour faire parler de soi et montrer ses compétences aux recruteurs potentiels. Bien que ça soit encore assez marginal, je voulais me faire remarquer en créant quelque chose que personne encore n’avait fait.
Je voyais beaucoup de sociétés Internet surfer sur la vague du buzz. Le but du jeu est de rendre une société connue par un très grand nombre de personnes à moindre frais, et si possible, avec aucun frais du tout.

J’ai alors décidé de faire pareil, essayer de monter un buzz. Plutôt que de faire un buzz sur une société, j’ai décidé de faire un buzz sur moi. Mes motivations étaient multiples ;

Tout d’abord, je voulais utiliser l’API de google map. C’était une occasion idéale pour développer une petite page web qui l’utilise.

Ensuite, j’avais envie de faire quelque chose d’humoristique autour du buzz du Web2.0. Dès qu’une société veut faire un buzz, elle utilise tout un vocabulaire comme Web2.0, nuage de tags, google map, api, AJAX, rss, mashup. Ca va loin, comme utiliser des couleurs pastel, mettre des dégradés de couleurs partout, des coins arrondis. Il faut aussi un nom de site dans le vent comme soonr, flickr, del.icio.us, beembo, mangoo, …

Pour finir, je voulais voir si j’arriverais à lancer mon propre buzz.

Bref, ça ne me coûtait pas grand-chose et j’avais tout à y gagner.

J’ai donc commencé à écrire une liste de tout ce qui fait un bon buzz Web2.0, tous les mots et les outils utilisés et je me suis lancé. Le but était de faire un CV à la sauce Web 2.0. J’ai décidé de le faire en anglais pour toucher un maximum de monde. J’ai utilisé Google Maps pour localiser les différents endroits géographiques de ma vie (chez moi, mes anciens boulots, …). Je voulais utiliser flicker pour mettre les photos mais c’était beaucoup trop lent donc j’ai juste fait un système de chargement d’images dynamique. J’ai aussi voulu essayer script.aculo.us qui est une superbe librairie pour faire des effets graphiques en tout genre sur sa page web. Pour finir, j’ai fait un logo à la Web2.0 pour mon nom, un nuage de tag pour mes connaissances, plein de moyens pour me contacter, et des liens pour voter sur les sites de news. Au final, je me suis retrouvé avec une page web complètement statique (un seul .html) qui était très dynamique grâce au javascript et qui parodie pas mal les sites Web2.0.

Une fois que tout était prêt, j’ai mis cette page en ligne, j’ai posté des news sur plusieurs sites web. Et il n’y avait plus qu’à attendre et voir si ça allait prendre ou pas.

Quelques blogs ont relayé l’information. Par contre, les votes sur les sites de news n’ont jamais décollé parce que le sujet n’intéressait pas ces communautés. Je visais un marché très spécialisé, le marché des recruteurs dans les sociétés web hi-tech et je savais qu’ils n’étaient pas faciles à atteindre. Malgré cela, j’ai tout de même reçu une demi-douzaine de mails de sociétés françaises spécialisées dans l’Internet 2.0 qui étaient intéressées par mes compétences de programmeur. Malheureusement, comme je l’avais écrit dans mon CV, j’étais à la recherche d’un poste de manager et donc le profil ne correspondait pas.

J’ai reçu toutes sortes de mails comme par exemple d’autres chômeurs qui voulaient savoir quel logiciel j’avais utilisé pour faire mon CV ou des personnes qui ne savaient pas programmer et qui se demandaient si c’était facile à faire.

Au bout de quelques semaines, je ne recevais plus rien. Autant dire que le buzz n’avait pas pris et que malgré tout ce que j’ai appris de cette expérience, j’étais un petit peu déçu du résultat…

Quelques mois plus tard, alors que je ne m’occupais plus du tout de ce CV, je reçois un email :

Hi Vianney,

I wanted to send you an email as I came across your profile recently on the web and I wanted to find out if you would be interested in exploring Google opportunities. Your interest in working on challenging projects using extreme programming methodology particularly interested me.

I work with the engineering recruitment team and my role is to find talented individuals, like you, in our industry and share with them details about exciting opportunities at Google across the world.

Google is continually growing and evolving to meet the challenges and changes that make up the world of technology and information. I look forward to hearing from you even if you are not interested at this point.

Thank you,

J’ai eu l’occasion de passer pas mal d’entretiens pour des postes d’ingénieur informatique mais j’ai aussi fait passer plus d’une centaine d’entretiens lors de mon dernier job, surtout pour des postes de développeurs et de chefs d’équipe. Cela m’a souvent amené à discuter de comment recruter et comment choisir de bons profils.

Comme c’est un sujet qui m’intéresse particulièrement et que cette semaine j’ai abordé ce sujet dans 3 groupes de discussions différents, il est temps d’écrire une série de tickets à ce propos.

Voici quelques règles permettant à coup sûr de recruter un mauvais ingénieur :

1. Lire son CV avant l’entretien

Lire le CV avant l’entretien est le meilleur moyen d’avoir des préjugés sur la personne, ce qui est particulièrement dangereux car en 30 minutes d’entretien il est difficile de s’en défaire.

Evidemment, si vous devez sélectionner les profils à partir des CV, vous êtes obligés de les lire à un moment ou à un autre. Dans ce cas, il est préférable de prendre tous les CV, sélectionner ceux qui vous intéressent et de laisser passer une semaine avant de commencer les entretiens.

Cela permet d’oublier le contenu du CV et le jour J de se concentrer uniquement sur la personne.

2. Juger sur ses diplômes

C’est sûrement là la plus grosse erreur à commettre. La France est un pays fier de ses écoles d’ingénieurs prestigieuses et aime beaucoup mettre des étiquettes sur les gens. J’ai eu l’occasion de faire passer un entretien à un jeune qui avait passé plus d’un an à chercher activement un job mais qui avait systématiquement des refus car il n’avait jamais réussi à valider un diplôme universitaire. Il est apparu que malgré un CV vide et « aucun » diplôme cette personne était très bonne en tant que développeur. A l’opposé, on a malheureusement pris en stage un étudiant qui était en dernière année d’une grande école en informatique et qui s’est avéré avoir un niveau en informatique très bas. Avec son diplôme on s’était dit qu’il devait forcement connaître un minimum de chose pour en être arrivé là…

3 Le mettre dans une position de stress

Certains pensent qu’il est nécessaire de mettre le candidat dans une position de stress pour voir comment il réagit. Le but étant de savoir s’il pourra gérer efficacement les situations de stress de son futur job. Or, les situations de stress sont censées être rares. De plus, c’est au chef de projet ou au manager d’encaisser ces situations critiques et de trouver des solutions pour que les ingénieurs n’aient pas à subir ce stress qui est souvent contre productif. Tester le candidat face au stress à plus de chance de le bloquer, de le mettre mal à l’aise et de ne pas se montrer sous son meilleur jour. Le jeu en vaut-il la chandelle ? D’autant plus que la majorité des candidats est déjà suffisamment stressée par l’entretien pour ne pas en rajouter. Au contraire, tout faire pour détendre l’atmosphère est une meilleure solution. Un candidat qui se sent bien sera lui-même, et risque même de baisser sa garde et cachera moins ses défauts.

4 Le croire sur parole

Il arrive de rencontrer des personnes qui sont à l’aise pour baratiner et ce n’est pas pour autant qu’ils sont bons. A contrario, il y a des personnes très compétentes qui ne savent pas se vendre (timides, stressées, …). Si la personne parle beaucoup, il est important de la focaliser sur un projet qu’il a bien aimé, et d’approfondir le sujet par des questions de plus en plus précises. Le but est de voir s’il maîtrise réellement le projet en question. Cela permet aussi de discuter de la manière dont il a abordé le problème, pourquoi il a choisi telle ou telle solution…

5 Trop parler


J’ai eu l’occasion d’aller à des entretiens où le recruteur a dû passer plus du 80% du temps à parler de lui, de sa société, de ce qu’il recherchait, de comment il voyait les choses… Autant dire que ce n’est pas avec les 20% restants qu’il a pu en apprendre beaucoup sur moi.
Autant il est important de se présenter et de présenter la société, autant cela ne doit pas durer plus de quelques minutes. Le but de l’entretien est de créer un échange, un dialogue entre deux personnes. C’est uniquement en instaurant un vrai dialogue que l’on arrive à savoir ce que vaut l’autre personne. Moins le recruteur parle, plus le candidat parle et donc plus on en apprendra sur lui.

6 Lui faire passer des tests psychologiques

Mais pourquoi donc ??? Faire passer ce genre de tests est totalement inutile. Je ne remets pas en doute le bienfait des tests, mais franchement… Selon moi, les tests ne montrent qu’une seule chose : si le candidat a déjà passé le test par le passé. Il existe des dizaines de livres contenant tous les tests logiques et psychologiques. Si un candidat connaît déjà le test, il peut sans problème lui faire dire ce qu’il veut.

7 Lui parler de technologie

A part dans de très rares cas où l’on recherche un expert extrêmement calé dans un domaine très précis dans le but de faire du consulting, parler de technologie est une perte de temps. Est-ce que le candidat connaît le C++ ? Si oui, connaît il les templates ? Le polymorphisme ? Les RTTI ? Les trigraphes ? La délégation croisée ? Et après ??? Même s’il ne connait pas le nom ou ce que ça fait, il suffit de l’apprendre ! J’ai eu l’occasion de bosser avec un ingénieur généraliste qui, bien qu’excellent, n’avait qu’une connaissance basique du C++. Il s’est pourtant très vite mis à niveau. Aujourd’hui, il bosse même sur STLPort.

Les technologies évoluent tout le temps, à quoi bon engager quelqu’un qui connaît bien une technologie à un moment donné ? Si on recrute quelqu’un pour du long terme, il est largement préférable de savoir comment il s’adapte aux évolutions technologiques. Est-ce qu’il est capable de se remettre en question ? D’apprendre par lui-même ? De s’auto-former ? De poser des questions quand il ne connaît pas la réponse ?

8 Lui demander d’écrire un programme sur papier

Cela part d’une bonne intention ; savoir s’il est capable de résoudre un problème simple (compter le plus gros palindrome dans une string). Mais en fait non, c’est loin d’être une bonne idée. Matt Gerrans l’explique bien dans cet article (traduction approximative) :

Je n’aime pas quand on me demande d’écrire un programme qui fait X sur un bout de papier. Ne demandez pas au candidat d’écrire un programme sur papier. C’est une perte de temps et de sueur. Les gens n’écrivent pas de programmes sur papier, ils le font avec des ordinateurs en utilisant l’auto-completion, les macros, la documentation, et l’aide contextuelle. Ils y pensent, le refactor, et le récrivent même. Si vous voulez voir le travail d’une personne, demandez-lui d’écrire un petit module ou de mettre en application une certaine interface avant l’entrevue et d’apporter le code sur un PC portable, ou imprimé. Vous pourrez alors le passer en revue et discuter de la conception, du style de programmation, et des décisions qui sont venues. Ceci vous donnera une évaluation beaucoup plus réaliste et plus utile du travail et du style d’une personne.