Répondre à une offre d’emploi ou de stage : les bonnes et mauvaises pratiques

En ce moment, je suis en situation de recrutement de stagiaires, et je l’ai été plusieurs fois ces dernières années. Je reçois et traite de nombreuses candidatures. Ça m’a permis de compiler cette série de bonnes et mauvaises pratiques que je retranscrit ici sous forme de conseils bienveillants.

Imaginons que vous êtes candidat, que ma société s’appelle BigCorp et que je m’adresse à vous.

Postuler ou pas ?

Arroser la planète entière avec votre CV n’a que peu de chances de vous trouver un travail.

Cherchez bien à identifier le profil recherché et voir si vous pensez correspondre.

Si le profil recherché est expérimenté dans la construction de sites web de e-commerce et que vous êtes en première année d’IUT informatique de gestion, sans réelle expérience personnelle, ou bien si c’est un administrateur système qui est recherché alors que vous avez juste un peu bidouillé votre PC à la maison, ne répondez pas. Vous gagnerez du temps et surtout vous en économiserez au recruteur. Imaginez que vous soyez pris sur un malentendu ; c’est perdant-perdant.

Le mail de réponse

Si vous connaissez l’identité du destinataire, indiquez la en début de message lorsque vous vous adressez à lui/elle. Pas de “Madame, Monsieur, Mademoiselle” si vous savez que c’est Martine Durand qui est responsable de recrutement.

Indiquez à quelle offre vous répondez (et si possible comment vous l’avez trouvée), car il peut y avoir plusieurs recrutements en même temps dans l’entreprise.

Soyez attentif à la forme de votre message : politesse, orthographe, phrases courtes et bien construites, … Vous perdez de sérieux points lorsque vous laissez traîner plus d’une ou deux fautes d’orthographe dans votre message, lorsque la ponctuation est très mal (ou pas) utilisée, …

L’idéal est de coller au style de l’annonce sur le niveau de langage, le style de phrases, … Ça n’est pas simple, mais vous marquerez des points si c’est remarqué.

J’ai tendance à préférer l’expression de la motivation d’un candidat dans ce mail de réponse plutôt qu’un message presque vide et une pièce jointe “Lettre de motivation”.

Soyez original(e) si vous pensez que ça peut s’y prêter. Il n’est pas interdit de sortir du cadre des conventions classiques. Les meilleurs recrutements que j’ai fait sont souvent des personnes qui ont sur se différencier par le fond et la forme. Par contre c’est un exercice difficile car on peut aussi totalement tomber à côté de la plaque.

La “lettre de motivation”

Son but est de montrer que vous avez envie d’intégrer l’entreprise qui recrute et que vous lui apporterez ce qu’elle attend.

Ne sortez pas les phrases toutes faites, apprises à l’école. N’expliquez pas au recruteur ce qu’il sait déjà de son entreprise, surtout si c’est pour dire n’importe quoi (“Votre entreprise, leader sur son marché et son territoire” lorsque c’est une PME de 3 salariés). Trouvez d’autres moyens pour montrez que vous avez fait des recherches sur l’entreprise. Si elle dispose d’un blog, vous y trouverez des infos pertinentes pour comprendre la culture de l’entreprise, qui y travaille, …

Énumérer vos qualités risque de rapidement tomber dans les “sens des responsabilité”, “qualité relationnelle”, … qu’on attend presque toujours chez tout candidat. Indiquez plutôt ce qui peut vous démarquer au niveau de vos expériences, de votre parcours, … et qui est particulièrement adapté à l’entreprise.

Si vous y croyez, expliquez pourquoi vous pensez que n’êtes pas simplement “bon pour le poste”, mais le/la meilleur. Si vos arguments sont bons, ça ne passera pas pour de l’égocentrisme et de la vanité.

Le CV

Le CV est un piège dans lequel il est facile de tomber car les écoles nous apprennent souvent à faire des mauvais CV.

Soyez succinct ; le plus souvent 1 seule page suffit et pour ça il convient de bien choisir ce qu’on met en avant.

Tous les logiciels que vous avez utilisé, tous les micro-stages dans des entreprises qui n’ont rien à voir avec l’offre, le baby-sitting, … n’ont pas besoin de se trouver sur votre CV. Idem pour les hobbies personnels, mentionnez les s’il vous reste de la place.

Choisissez ce qui correspond particulièrement au profil du poste, quitte à mentionner que ça n’est pas tout et que seriez ravi de discuter de vos diverses expériences en annexes.

Si votre profil vous permet de postuler plusieurs offres, personnalisez un CV par poste, pour être bien ciblé.

Dans sa forme, un CV doit être sobre et très lisible. Si vous mettez une couleur ou un motif de fond, 3 polices de caractères différentes, des encadrés autour de chaque paragraphe, … vous vous y prenez mal.

Il conseillé d’annexer (directement ou avec un lien) un échantillon de vos précédentes réalisations, pourvu que ça soit adapté au poste pour lequel vous postulez. Si vous êtes développeur, indiquez ce qui est consultable en ligne (compte GitHub ou autre), un portfolio si vous êtes graphiste, …

Les pièces jointes

Format des fichiers

Il est indéniable que Microsoft Word est très répandu (bien que je doute que la plupart étudiants ait une licence valide), mais ça n’est pas non plus le standard.

J’ai le droit de ne pas vouloir payer plusieurs centaines d’Euros pour une licence entreprise de ce produit, ou bien d’utiliser un système sur lequel il n’est pas disponible. En m’imposant ce format propriétaire, vous réduisez les chances que je puisse consulter votre candidature.

Il existe cependant des formats libres, plus ouverts, et encore plus répandus.

• le texte brut : c’est assez rustique, mais la solution ultime en terme d’accessibilité. Le plus souvent, un CV n’a pas besoin de faire preuve d’une grande créativité en terme de mise en forme. Si vous êtes dans des métiers de l’image, créez des documents adaptés : animés ou statiques selon, mais qui correspondent au destinataire.
• le RTF : il permet une mise en forme plus riche, il est tout à fait standard et tous les logiciels de traitement de texte savent lire et exporter ce type de document.
• le PDF : bien que format pas totalement libre, il existe des “lecteurs de PDF” pour quasiment tous les systèmes. Il a l’avantage de permettre une mise ne forme très poussée, une bonne accessibilité s’il est bien construit, peut être imprimé sans dégradation de format, …

Nom de chaque document

Le plus souvent, lorsqu’une entreprise publie une offre, elle ne reçoit pas seulement votre candidature.

Des documents qui s’appellent “CV.doc”, “LM.doc”, “profil.doc” ou encore “modèle.doc” deviennent totalement anonymes lorsqu’ils sont sortis du contexte du mail auquel ils étaient joints. Je classe tous ces documents dans un dossier correspondant au recrutement en cours. Il m’est donc beaucoup plus utile d’avoir des fichiers du genre “John Doe – CV.pdf”, “John Doe – LM BigCorp.pdf”.

• votre nom en début permet de grouper plusieurs documents vous concernant lors d’un tri alphabétique.
• indiquez ensuite le type de document s’il y en a plusieurs.
• si votre lettre de motivation est personnalisée (fortement conseillé), indiquez le nom de l’entreprise destinataire, ça montre un effort d’adaptation.

Conclusion

Avec un minimum d’effort, c’est finalement assez facile de ne pas faire mauvaise impression lorsqu’on postule à une offre d’emploi ou de stage. Et si vous faîtes cet effort, vous serez probablement remarqué(e) et vous marquerez de précieux points lorsqu’il faudra décider de ne pas faire passer votre candidature dans la corbeille, mais à l’étape suivante de la sélection.

Mise à jour (31/11/2011) : Sur son blog, J-Mad complète judicieusement mes conseils.

Tutorat technique : tiens, c’est cadeau !

Je fais partie de ceux qui croient que lorsqu’on débute ou qu’on cherche à se perfectionner dans une pratique, être accompagné d’un “mentor” (ou tuteur, si vous préférez) est une grande aide.

J’ai pu en bénéficier quelques fois à mes débuts (trop peu à mon goût, d’ailleurs) et ça m’a beaucoup servi.

C’est pourquoi je voudrais consacrer un peu de mon temps, régulièrement (et gratuitement), pour accompagner des personnes qui souhaiterais avoir un œil extérieur sur leur code, leurs pratiques, leurs méthodes, leurs outils, …

Il ne s’agit pas de formation au sens institutionnel du terme, mais plutôt d’observation, de critique et de conseil, dégagé de tout troll (dans la mesure du plus possible).

Je propose donc de passer 30 minutes à 1h en tête-à-tête, lors de chaque réunion du PLUG, avec une personne pour une séance de pair-programming, ou de discussion technique sur un sujet, … Ça peut être sur mes technos de prédilection, mais aussi sur n’importe quel langage, framework, … ou sur des méthodes de travail car il ne s’agit pas forcément de décortiquer le détail de chaque ligne, mais pourquoi pas d’avoir un regard critique d’ensemble, …

Faites moi signe (en commentaire, par e-mail, via Twitter, …) si vous êtes intéressé. On peut faire une tentative dès la prochaine réunion du PLUG, le 4 novembre. En cas de demandes multiples, je me réserve la liberté de choisir le sujet avec lequel je me sentirai le plus à l’aise ou le plus intéressé.

Mise à jour (21/11/2011) : La première tentative est concluante (pour moi au moins), donc je propose de recommencer dès la réunion du PLUG le 2 décembre.

API Versioning in Rails with Accept HTTP headers

To implement API versioning in Rails, not using URL namespaces but custom MIME types, there are a few different approches.

The Tribesports way

Recently, I’ve seen a blog post about the Tribesports API. They chose to add a new MIME type to the application and use the rendering features of Rails.

Maybe I’ve not seen all the constraints they might have, and that lead to this choice, but from my point of view, 2 things are bothering me :

1. they had to change too much things in the rendering process
2. they created the api_v1 content type but in fact it’s plain JSON

What if they wanted to render JSON or XML but for the version 1 of their API ?

Another way

With a simple protected method in the ApplicationController, it’s possible to inspect the Accept HTTP header, and extract an API version number, while letting Rails decide what is the real content type to use.

class ApplicationController < ActionController::Base

  respond_to :html, :xml, :json

  protected

  def api_version
    default_version = '1'
    pattern = /application\/vnd\.com\.example\.api\.v([\d\.]+)\+.*/
    request.env['HTTP_ACCEPT'][pattern, 1] || default_version
  end
end

In this example, by default all the action method of all controllers will respond to HTML, XML and JSON, and Rails is probably using the default HTML if nothing is specified. I can even implement a rendering for another format in the respond_to block of a action method, like format.js for Ajax requests, …

We now have a method, accessible from all controller methods (including actions) to get the desired API version nummber. If an “application/vnd”-style Accept header is found and if a version number can be extracted, then it is used. There is a fallback to the default version.

With this, you can have any test you want at the controller level on the API version, without messing with the content type.

About the default version number, some prefer the lastest (and allow clients to set a specific version), and some prefer the first version. I prefer the “latest by default” way.

NB : I’m quite sure I’ve not made this one up, but I honestly can’t remember where I’ve read this from.