Je vois de nombreux emplois qui nécessitent au moins x années d'expérience. La question est de savoir comment savoir quand un candidat possède les années d'expérience requises? Qu'attendez-vous d'une personne ayant x années d'expérience (éditez: comment vérifier efficacement si le CV ne ment pas sans se fier à la vérification des compétences)? Que peut faire une personne avec x années d'expérience qu'une personne avec y années (avec y <x) ne peut pas faire (modifier: en supposant qu'elles ont des compétences similaires)?

Il peut y avoir des cas avec un programmeur passionné avec y années d'expérience qui possède une vaste connaissance et a travaillé sur plusieurs projets et d'autres programmeurs avec x années d'expérience (x> y) qui a travaillé sur quelques projets et n'a pas beaucoup d'expérience.

Pourquoi ne peut-il pas être réduit à quelque chose comme ça "si vous connaissez cette technologie et que vous savez comment faire ce genre de choses (que ce soit la conception, la communication, les estimations, etc.), alors vous êtes adapté à notre travail"?

Je sais que vous ne pouvez pas embaucher un nouveau diplômé avec 1 an d'expérience pour le poste d'architecte d'entreprise, mais je vois également un problème avec le fait que presque toutes les annonces demandent de l'expérience. À mon humble avis, la passion doit tout d'abord être prise en compte.

Premièrement, je ne savais pas si la question convenait à ce site, mais comme il y a un tag pour le recrutement et l'expérience, je pense qu'il a sa place ici.

Votre question peut être traitée en se divisant en deux sous-questions.

Pourquoi utiliser des années d'expérience comme exigence?

Parce que c'est une métrique facilement vérifiable en corrélation positive avec la compétence en programmation . La réponse de Snagulus développe déjà les détails de la corrélation, donc je vais me concentrer sur le "pourquoi".

La dure vérité est qu'il y a généralement plus d'un candidat pour un poste donné. De plus, les entretiens consomment beaucoup de ressources, surtout s'ils sont effectués "correctement", c'est-à-dire que les entretiens techniques sont menés par du personnel techniquement compétent (dans ce cas, les programmeurs).

Par conséquent, un critère pour filtrage initial des CV entrants doit être utilisé, et de préférence un qui peut être vérifié par le personnel non technique - en cas de doute, les RH peuvent toujours appeler les employeurs précédents et vérifier que oui, John Smith a travaillé pour X ans avec eux.

Pourquoi ne pas plutôt utiliser la «passion» comme exigence?

Il y a au moins deux problèmes avec ceci:

comment mesurer la "passion"?

KLOC enregistrés? Bonne chance pour découvrir que, également, dans la programmation (et dans d'autres disciplines), plus abondant n'est pas synonyme de "meilleur".

Projets open source / passe-temps terminés? Pas facilement vérifiée par les RH, et de nombreux programmeurs compétents ont des raisons légitimes d'être inactifs à cet égard - autres obligations longues, longues heures de travail avec envie de se détendre, simple accomplissement professionnel pendant les heures de travail, etc.

Des années d'expérience? Oh, attendez...

la «passion» est-elle vraiment une bonne mesure de la compétence?

Comme le dit Robert Harvey dans son commentaire, la passion n'est pas vraiment révélatrice d'une programmation compétente. Par rapport à l'expérience, c'est une qualité principalement orthogonale - c'est-à-dire qu'il existe:

• programmeurs passionnés et compétents et
• programmeurs impartiaux et techniquement compétents et
• programmeurs passionnés et techniquement incompétents et
• des programmeurs passionnés et non techniquement incompétents,
• etc.

Le dernier exemple est important dans notre contexte - des années d'expérience montrent également qu'un programmeur donné a en quelque sorte réussi à fonctionner dans son travail, alors qu'un programmeur dysfonctionnel pourrait, par exemple, refuser catégoriquement de participer même au système de gestion des tâches le plus simple. (disons Scrum Post-it), parce que "ça me ralentit".

Clause de non-responsabilité finale

Tout d'abord, et heureusement, les "années d'expérience" sont souvent évaluées "de manière lâche" - c'est-à-dire si vous postulez pour un emploi avec la langue X, mais que vous n'avez qu'une expérience "commerciale" avec la langue Y, similaire à X, c'est-à-dire aussi souvent pris en compte.

Deuxièmement, personnellement, je ne suis pas fan de "N années d'expérience", et je ne suis pas le seul. Il existe une alternative simple - en spécifiant «expérience en» . Cela suffit généralement comme filtre, car les candidats sont obligés de documenter cette expérience dans leur CV - si vous obtenez un candidat pour un poste de programmation qui n'a auparavant fait que l'attente (et cela arrive!), Vous savez que quelque chose ne va pas.

"Années d'expérience" est plus une échelle de probabilité qu'une mesure de quelque chose de concret. Avec plus d'années, vous obtenez une chance accrue qu'une personne ait rencontré des choses telles que:

• A participé à un événement de type crise.
• A vu un projet du début à la fin.
• A vu un projet ne démarrer ni se terminer.
• A travaillé sur le code hérité.
• A travaillé sur une ardoise vierge et fait quelque chose.
• A mis en œuvre des décisions de conception.
• A conçu un système.
• A écrit un bug, publié une mauvaise correction, arrêté un serveur; A foutu, essentiellement.
• A corrigé une erreur.
• A trouvé les cas étranges dans la langue dans laquelle ils travaillent et a vu un endroit où ils comptent.
• A appris que les choses actuellement dans la base de code pourraient être stupides.
• Notez que ces éléments sont un petit échantillon non obligatoire et incluent également des dizaines de petites choses qui peuvent être trouvées en fonctionnement dans un environnement réel.

Encore une fois, c'est une chose fortuite, et cela dépend entièrement de / où / ils ont acquis ces années d'expérience. Une personne aurait pu travailler dans un seul projet sur une équipe de plusieurs centaines de personnes et devenir hautement spécialisée. Un autre aurait pu être dans une petite boutique d'essai par le feu, et devenir plus généraliste dans la gestion des serveurs / installation / codage / QA / DBA / gestion de projet. Il y a aussi des gens qui obtiennent la même année d'expérience encore et encore.

C'est une mesure approximative, mais en moyenne, une personne aura été exposée à plus d'événements d'apprentissage potentiels plus elle travaillait depuis longtemps, et c'est utile comme point de données préliminaire. Le reste du curriculum vitae (et, plus important encore, l'interview) sert à déterminer ce qu'ils savent réellement et ce qu'ils ont réellement fait.

Je vais répondre à cela en répondant à chacune de vos questions dans le post.

La question est de savoir comment savoir quand un candidat possède les années d'expérience requises?

C'est normalement ce que le processus d'entrevue vise à filtrer. Plusieurs entretiens sont menés et vous pouvez normalement évaluer l'expérience d'un candidat par rapport à certains de vos propres développeurs internes.

Qu'attendez-vous d'une personne ayant x ans d'expérience?

Vous vous attendriez à ce qu'ils remplissent les exigences du poste qui sont spécifiées dans un poste. Par exemple:

«Nous recherchons un développeur PHP senior avec plus de 10 ans d'expérience dans la conception et l'architecture de systèmes pour restructurer nos outils système en tant qu'architecte en chef, tout en gérant un nombre K de développeurs seniors et juniors et en les guidant tout au long du processus. exiger ... (etc. etc.) "

Que peut faire une personne avec x années d'expérience que celle avec y années (avec y <x) ne peut pas faire?

Vous cherchez une mauvaise expérience dans ce cas. Les offres d'emploi ne demandent pas seulement un nombre d'années, mais aussi une expérience dans les technologies que l'entreprise utilise. Comme vous pourriez avoir 10 ans d'expérience dans le développement C ++, et dire que je suis une entreprise de jeux à la recherche de développeurs C ++ avec même 5 ans d'expérience. Vous ne seriez toujours pas mon candidat idéal car vous n'avez jamais travaillé dans l'industrie du jeu auparavant. Mon poste précisera en fait: X le nombre d'années d'expérience dans les aspects A, B, C de la programmation.

Il peut y avoir des cas avec un programmeur passionné avec y années d'expérience qui possède une vaste connaissance et a travaillé sur plusieurs projets et d'autres programmeurs avec x années d'expérience (x> y) qui a travaillé sur quelques projets et n'a pas beaucoup d'expérience.

Lisez ma réponse précédente. L'expérience est liée aux outils dans lesquels vous êtes expérimenté. X nombre d'années dans les outils A, B, C.

Pourquoi ne peut-on pas reprendre quelque chose comme ceci "si vous connaissez cette technologie et vous savez faire ce genre de choses (que ce soit la conception, la communication, les estimations, etc.), alors vous êtes apte à notre travail"?

Cela peut arriver et arrive. Si vous pouvez faire vos preuves, l'expérience des années n'a pas d'importance. Pour un gars comme vous, vous semblez plus adapté à un petit magasin de développement, où l'intervieweur / recruteur est lui-même un développeur. Les grandes entreprises ont normalement des RH qui font ce genre de choses, c'est pourquoi elles rendent les exigences du travail si larges que vous avez essentiellement besoin d'un doctorat avec plus de 15 ans d'expérience pour écrire de petites fonctions pour leur site Web (exagération mais cela explique en quelque sorte les défauts dans le recrutement de programmeurs, en particulier pour les grandes entreprises - bien que tous ne souffrent pas de cette maladie)

Les années d'expérience ne sont qu'un filtre qui donne une estimation "approximative" de ce que l'on attend d'une personne utilisant les compétences souhaitées énumérées dans la description de poste.

Voici à peu près ce à quoi je m'attendrais, mais d'autres peuvent avoir des idées différentes:

2 ans ou moins - Vous devriez être en mesure d'accomplir des tâches spécifiques qui vous sont demandées, les employeurs sachant qu'il y aura une courbe d'apprentissage avec une bonne quantité de supervision pour la plupart de ces tâches.

3 à 5 ans - Vous devriez être en mesure d'accomplir les tâches qui vous sont demandées, sans trop de prise en main, car vous devriez déjà avoir effectué des tâches similaires dans votre expérience de 0 à 2 ans. Vous devriez également commencer à montrer une initiative "intelligente" et être capable de gérer des tâches plus petites qui ne sont pas nécessairement clairement définies. (Par exemple, être capable de concevoir des modules à partir des exigences, où vous devez suivre certaines de ces exigences par vous-même).

5 - 7 ans - Vous devriez être capable de travailler seul et de décider quelles sont ces "tâches" d'en haut. Vous devriez être capable de gérer des tâches de taille moyenne qui ne sont pas clairement définies. (Par exemple, être capable de concevoir / mettre en œuvre / vendre des sous-systèmes). Vous devriez également commencer à diriger des équipes de sous-systèmes dans cette période. Donner les présentations nécessaires des sous-systèmes dont ils sont responsables, au moins à l'équipe interne.

8 à 10 ans - Peut être invoqué pour obtenir des sous-systèmes très importants et / ou critiques du projet Expert résident dans plusieurs technologies. Peut diriger de grandes équipes de sous-systèmes. Donner des présentations des sous-systèmes dont ils sont responsables au client.

Plus de 10 ans - Peut gérer à peu près n'importe quelle tâche logicielle qui leur est lancée, dans les limites de la description de poste ET de la plupart des autres tâches logicielles semi-connexes. Expert résident dans un grand nombre de domaines logiciels. Peut mener de grands projets, des exigences à la vente. Comprend la conception du système et pas seulement la conception des modules / sous-systèmes. Est capable de concevoir des systèmes fiables, robustes et maintenables. Est l'interface logicielle du client, y compris les présentations du point de vue des systèmes. Peut convenablement préparer des propositions et des calendriers de soumission.

Bien que la définition des années d'expérience soit vague, ce n'est pas seulement pour le bénéfice de l'employeur mais c'est aussi un guide pour le demandeur d'emploi. Ainsi, si vous êtes embauché, prétendant que vous avez 8 à 10 ans d'expérience et que vous venez au travail et que vous devez être informé de chaque petite tâche que vous devez faire, au mieux votre avenir dans l'entreprise est "très limité" si vous durez même très longtemps. longtemps du tout. Les premières impressions sont difficiles à changer, donc même si vous vous améliorez en tant que développeur, les gens conserveront probablement leur impression d'origine de vous.

J'ai vu un bon nombre de développeurs "seniors" embauchés qui avaient disparu en quelques mois ou en quelques années ont été mis sur le programme de "développement des employés", qui est vraiment juste la voie rapide pour être le premier sur la liste des licenciements. Si ces mêmes développeurs étaient arrivés à un niveau inférieur (bien sûr, cela signifie un salaire inférieur), ils auraient très bien pu être considérés comme une embauche réussie et perçus comme performants.