Candidat: quelles questions poser à une start-up ?
Que demander en entretien ? Comment passer outre le vernis “tout est parfait chez nous/on a un babyfoot” ?
Après 7 ans à travailler comme développeur/lead technique et interviewer pour deux start-ups, je me suis retrouvé à nouveau à chercher “la prochaine aventure”.
J’ai reproduit ci-après la liste des questions auxquelles je voulais des réponses. Bien évidemment certaines se trouvent sur le net, se déduisent d’une conversation où s’avèrent complètement hors-sujet. Elles reflètent mes interrogations de codeur et lead cherchant un job sur Paris, mais bon nombre d’entre elles peuvent s’appliquer à n’importe quel profil.
Je les ai classées par type d’interlocuteur mais il faut bien entendu savoir composer: une start-up de 5 personnes n’aura pas de RH; le CTO dans une R&D de 10 personnes sera aussi le VP Eng, le manager, et probablement contributeur individuel; tu ne rencontreras pas le founder d’une boîte en serie F de 400 personnes mais le recruteur saura répondre.
A poser à un RH/tech recruiter
Remote work OK ?
Est-ce que je peux travailler de chez moi de temps en temps ? Régulièrement ? Un jour par semaine ? Deux ?
Surtout pertinent dans une équipe assez importante, où souvent le seul moyen de rester concentré sur son code ou de dépiler ses tâches sans être interrompu par des réunions/des questions/des NERF battles au calme et sans casque audio est de bosser de chez soi (ce qui présente l’avantage supplémentaire de pouvoir se faire du vrai bon café)
Score au Joel test ?
Dont voilà le lien: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
9 Août 2000. Oui, c’est encore d’actualité. C’était indiqué sur les pages entreprises de stackoverflow jobs avant qu’ils ne le virent, dommage. Si le recruteur ne sait pas ce que c’est, garder la liste pour plus tard (à poser aux dévs, ce sont eux qui savent le mieux répondre avec un niveau minimum de bullshit)
Quel était le dernier off site / team building ?
Donne une idée de ce que la société est prête à dépenser (en terme de temps et d’argent) pour le bien-être de ses employés. Evidemment c’est complètement à côté de la plaque pour une boîte où tout le monde travaille encore dans le salon d’un appart reconverti en pépinière.
Parfois l’ambiance est tellement bonne que rien n’est formellement organisé, mais c’est quand même un autre type d’engagement des dirigeants quand c’est la CB corporate qui règle la note de l’escape game.
Equity aux salariés ?
Où plutôt: est-ce que le package que vous allez me proposer contiendra de l’equity (en général sous la forme de stock options) ? Corollaire: est-ce que tous les employés en touchent ?
Quand on est junior on n’ose jamais poser cette question, mais mon expérience chez Criteo m’a appris deux choses:
- Cela peut paraître étonnant mais c’est un réel élément de motivation de tous les employés: il se développe un fort sentiment d’appartenance, de co-ownership, c’est aussi une arme de rétention efficace.
- En cas très improbable (sur lequel il ne faut jamais compter sérieusement) de grosse “success story” avec entrée en bourse à la clé ou gros rachat, la partie salaire peut devenir assez accessoire.
A creuser plus tard:
- de quel type ? (BSPCE/BSA par exemple pour une entreprise française)
- quel vesting schedule ? (en général 4 ans)
- y a-t-il une clause d’accélération et sous quelle(s) condition(s) ?
- Ca représente combien pour moi en pourcentage du total ? (pour une boîte early stage)
Si certains éléments indiqués ci-dessus sont du charabia, Google les. Vraiment. Fais-le.
Objectifs de recrutement de l’année (tous postes confondus)
Pour savoir si la société prévoie une grosse croissance, si celle-ci semble maîtrisée, quelle est la capacité à grossir, quelles équipes sont impactées (R&D ou sales ?).
C’est une donnée qui peut être considérée comme confidentielle, pas la peine d’insister en cas de réponse floue.
A poser à un CTO/founder
Levée de fonds, combien, auprès de qui ?
Info qu’on trouve en général sur le net en cherchant “<nom de la boîte> lève * euros”, qui est le titre type de Frenchweb sur ce genre d’évènement. Pour les boîtes US, c’est sur crunchbase ou angel list.
Je la pose toujours parce qu’en général si une startup recrute avec appétit c’est qu’elle vient de lever. Donc même sans nouvelle publique, il est tout à fait possible (probable en fait) que ce soit le cas mais que la maîtrise de sa communication l’oblige à attendre pour sortir sa PR.
Cela permet de savoir si tu seras bien payé ou pas, si la boîte a les moyens de ses ambitions, si de gros fonds lui font confiance (donc de profiter du fait qu’ils ont déjà fait la “due diligence” pour toi), combien de temps tu peux espérer garder ton job (avec la réponse à la question rentabilité cashburn plus bas)
Modèle économique
La question fondamentale: comment les sous rentrent-ils ? La réponse peut tout à fait être: on en a pas. Voir tous les réseaux sociaux à leurs débuts.
C’est une réponse qui est acceptable dans certains cas (ou dans la Silicon Valley) mais est plus difficile à tenir en France. Les VCs européens préfèrent largement qu’on leur en présente un.
Au final cela donne une indication sur la capacité de la société à lever ses tours suivants et/ou arriver à l’équilibre.
Si le modèle économique est très difficilement compréhensible ou semble tiré par les cheveux, c’est souvent mauvais signe.
Rentabilité/Cashburn ?
Deux parties: avez-vous atteint le point d’équilibre (“break even” en anglais) (en général: non), et combien dépensez-vous tous les mois (en général: beaucoup trop)?
Pour l’équilibre, ce n’est pas grave si ce n’est pas le cas, l’important est de savoir qu’il est atteignable un jour. Les fonds poussent d’ailleurs en général pour que la start-up investisse au lieu de garder sa trésorerie au chaud.
Si la réponse sur le cashburn n’est pas précise ou trop sensible, il faut reformuler la question pour savoir si “sachant le niveau de dépense actuel et projeté prenant en compte la croissance des équipes mais pas les levées de fonds futures, et sachant ce qui reste en banque, combien de temps reste-t-il avant de devoir fermer boutique?” (en start-up speak on dit poliment “mettre fin à notre incroyable aventure”)
Ton plus gros problème actuellement ?
Une de mes questions préférée. En fait je la pose à tous les opérationnels que je rencontre. On peut reformuler la question de manière moins négative “quel est ton plus gros point de focus actuellement ?”
Les réponses peuvent être, pèle-mêle, et sans exhaustivité: recruter des gens pour vider mon backlog, me décharger d’une partie de mes tâches parce que je bosse trop, lever un nouveau round (en général non :-) ), répondre à l’avalanche de demandes de mes clients, faire face à un afflux de nouveaux clients, stabiliser ma code base, formaliser les process…
Cela te donne une idée de ce en quoi va consister ton job, de l’ambiance, bref de l’état d’esprit de la boîte.
Exit strategy/où tu vois la boîte dans 5 ans ?
Tous les fondateurs en ont une, et en tout cas les investisseurs en ont une pour eux.
En général la réponse est: “vendre la boîte à un gros” (avec le non-dit “pour un gros paquet et avec un lock-in le plus court possible”)
Cela permet de séparer ceux qui veulent “faire un coup” (ils ont une idée très précise de la valorisation à laquelle ils commenceront à chercher un acheteur, voire ils ont déjà commencé), de ceux qui croient en leur projet (“on verra, ça dépend de la croissance, des investisseurs…”) et de ceux qui sont très ambitieux (“on verra, mais on a de grandes ambitions” == on se verrait bien en full screen sur Time Square)
A poser à un manager/VP engineering
Prioritization bug/features/refactoring
Ou plutôt quels sont à la louche les ratios en terme de ressources dev (personnes ou temps) entre traiter les tickets en attente (je ne parle pas des bugs critiques qui en général passent avant le reste), travailler sur les projets du backlog et nettoyer la dette technique.
Un environnement R&D sain dans une start-up en croissance consacre toujours une partie de son énergie à fixer les tickets ouverts mais passe la majorité de son temps à avancer sur le projet.
Le temps pour refactoring/nettoyage de l’existant est plus compliqué à obtenir et donne plus une indication sur la capacité de la R&D à négocier avec le produit ou de sa volonté de s’occuper du problème.
Collaboration tools (email/JIRA/Confluence/Slack/github…) ?
Quels sont les outils utilisés pour travailler ? Cela va des outils de release management, de repos de code aux outils permettant la communication avec les équipes produit où entre différentes équipes R&D.
On obtient une certaine idée de l’organisation et de la maturité des processus de développement en place.
Ton ratio habituel de réunions ?
Réunion s’entend par “être assis autour d’une table avec plus de 2 personnes sur un créneau réservé dans ton calendrier”. Sinon ça s’appelle un “point impromptu”, un “one on one”, une “discussion de machine à café”.
Important pour savoir si le middle management tech a encore les mains dans le cambouis à coacher les équipes, coder des petites améliorations ou régler des bugs ou si la part “politique” a pris une part importante.
Ce ratio varie avec la taille de la société, l’important est de détecter quand il est anormal. Une équipe de R&D de 10 personnes dont 2 VP Engineering qui passent 70% de leur temps “en réunion” est probablement à fuir.
Quel est le process si je veux plus de RAM ?
Une question type “competency based interview” (à Googler si tu ne sais pas ce que c’est. On va te poser des questions de ce genre), méthode qui fonctionne aussi très bien en tant que candidat et qui présente l’avantage d’éviter les réponses rapides et peu précises.
Ici le but est d’avoir une idée du niveau d’autonomie du middle management (“tu me dis quoi, tu commandes sur amazon et je te valide ton expense/tiens, voilà le numéro de carte corpo”), de l’existence ou non d’un service IT interne (qui s’occupe des problèmes de wifi ? de mon écran qui ne marche plus ?), de la souplesse de l’organisation (“ah non, c’est pas possible, tu fais avec ce que tu as”)
A poser à un dev
Décrit moi la tâche/story sur laquelle tu travailles en ce moment (dans ce sprint) ?
Cette question permet d’éviter la description succincte de l’intégralité du projet sur lequel ton interlocuteur travaille.
On obtient aussi une idée de l’enthousiasme du développeur pour son projet, on apprend son niveau de compréhension de la manière dont une tâche de développement atomique s’inscrit dans le contexte plus global du produit/de l’entreprise.
On peut aussi découvrir plein de petits détails sur le produit, et surtout sur tout ce qui n’est “pas top” dans l’architecture nickel vendue par le recruteur.
Ce que tu préfères dans ton travail/Si il y avait une seule chose que tu pourrais magiquement changer ?
Les fameuses questions “j’aime/j’aime pas”, “points positifs/négatifs”, “forces/faiblesses” mais reformulées de manière à obtenir une vraie réponse.
Comment releases-tu ton code? (étapes)
On peut préciser “donc, tu viens de produire 15 lignes de JS/C#/Java/Python pour corriger un bug/ajouter une évolution, que se passe-t-il jusqu’à ce que ce patch soit effectivement exécuté en production?”.
Donne une idée du niveau de maturité des process R&D, explique réellement quel est le processus d’intégration continue si il existe (et pas seulement “on fait du CI bien sûr”), quel branching model, comment on teste le code, quel est le niveau d’étanchéité entre la prod et le dév, combien de temps durent les cycles de release, quel est le niveau de stress vis à vis des modifications.
Comment as-tu su sur quoi tu devais travailler ce matin ?
Au lieu d’avoir une indication vague sur le processus de développement (“on est lean” “on fait du scrum”), indique ce qui se passe vraiment, et le mode de management (directif ou assez libre).
On peut bien entendu rebondir sur les process en général, le niveau de pureté de l’agile utilisé, la perte de focus par la fréquence d’apparition de bugs et de nouvelles fonctionnalités “tombées du ciel”.
C’est lequel le bar du bureau ?
Est-ce que tu vas boire une bière/un jus de tomate avec tes collègues après le boulot ? Est-ce qu‘il n’y a que la R&D ou bien vois-tu aussi des sales/products/administratifs ?
Le nombre de problèmes qui se règlent ou d’idées qui surgissent à 22h autour d’une pinte étant non négligeable il est utile de savoir si cela fait partie de la culture.
emacs ou vi ?
La question troll à poser à la fin. Le vieux codeur répondra selon sa religion, le n00b qui passe plus de temps sur Hacker News que sur Stack Overflow utilisera vi(m), l’ops aussi. L’important est de pouvoir continuer la discussion sur l’IDE actuellement utilisée, et donc l’opinion du dév sur les langages/outils internes imposés (ou pas).
On peut évidemment la remplacer par “tabs ou space” mais elle a moins de sens puisque toute l’entreprise utilise forcément la même règle (si ce n’est pas le cas, c’est désespéré).
