Discussion :

[romatou18]

Bonjour,

Je suis expatrié vivant en Ecosse depuis 4 ans, developpeur en Ecosse depuis 2 ans, depuis qq mois chez Cadence Design Systems, une grosse boite et ai travaillé dans 2 PMEs en Ecosse avant cela. A chaque entretiens que j'ai eu, env 5 sur les 2 dernieres annees j'ai toujours eu une mise en situation, epreuve/ exercices de codage, modelisation de données, de logique, exercices au tableau en tout genre (math, geometrie, algorithmique).
PAs tout a chaque fois mais au moins une epreuve de ce genre.

Ici on fait pas a la tete du client ou au diplome ou meme au dires on te dit " ok tu nous dis que tu sais faire ca ? alors montre le nous". En general jusqu'a 4 entretiens sont necessaires au mieux, dans mon cas 2 mais pas moins.

Oui car les entreprises ne sont pas dupes, certains viennent de Facs ou ecoles pourries ou les 3/4 n'apprennent pour ainsi dire rien sauf du par coeur, mais il y a malgré tout de bons elements. A l'inverse certains font ronfler des gros noms de FAC mais n'en n'ont pas foutu une rame, sont passés razibus et au final sont plus ou moins incompétents au regard de leur diplome prestigieux.

Donc oui oui oui et re oui la mise en situation est revelatrice des capacités d'un travailleur. Certains dirons que on ne peut demander qqchsoe comme ca en 5 mins, on ne peut certe pas tout demander, mais au moins un debut de raisonement, de reponse, une piste sur un probleme concret touchant aux domaines de competences de la personne est il me semble le minimum qu'un employeur puisse attendre d'une personne compétente digne de ce nom.

Pour info je ne sors d'aucune grand ecole d'info, mais de l'IUT 2 de Grenoble Genie logiciel et de la FAC Edinburgh Napier University (pas une tres bonne fac pour l'enseignement, juste pour la recherche), mais malgré tout je suis apprecié dans mon equipe, recherche et developement chez Cadence, boitre fournisseur d'intel, nvidia, Apple, ST micro ou encore Infineon et Motorola en outils de conception de microprocesseurs.

Employeurs ce n'est que mon avis mais cessez de regarder uniquement ou presque, les diplomes et le prestige d'une supposée grand Ecole et mettez vos candidats a l'epreuve ca évite les surprises et est je pense beaucoup plus juste et egalitaire, car ce n'est pas parcequ'on a pas l'argent de se payer une grande ecole que l'on est pour autant moins bon, les passionés et les bosseurs en petite ecole ou fac ca existe aussi.

Je pense qu'un gros travail est a faire en France la dessus, toute une culture de recrutement a réformer, la faute a notre histoire sans doute, histoire de hierarchie dans le systeme, et de respect et grande importance attachée a la notion d'institution.

Pour finir la periode d'essai, 6 moins dans mon cas, vu le cout d'un recrutement en CDI c'est pas excessif, pas ici en tous cas et ca ne me choque absolument pas. Si un jour je fonde ma propre boite je serais content de pouvoir appliquer cela.

Romain S

[Bluespear]

Faut-il faire coder les candidats durant les entretiens d'embauche ?

Non. Je pense qu'après avoir eu le blablabla de la RH sur l'entreprise pendant 15 minutes, avoir raconté sa vie pour montrer qu'il saura s'intégrer dans une team et résisté à des questions de "mise en pression cass-pied" pour voir comment réagit le candidat à des provocations, le faire jouer avec du code C sur un tableau blanc et plein de pointeurs supervisé par 1-2 développeurs qui le font tous les jours c'est un peu jouer au lotto pour avoir 5% de chance de recruter le bon candidat.

Quelle est selon-vous la meilleure méthode pour ne pas rater le recrutement d'un développeur ?
1/ Ne pas faire aveuglément confiance au candidat. Si il a pas mal d'expérience, il est malgré tout devenu habituel de "bullshiter" dans les CV. En Suisse, profiter des 3 mois d'essais pour lui infliger les plus grosses épreuves qu'il pourrait avoir à affronter, surtout si la place que le candidat vise est du genre "Scrum Master" / "Senior Architect"... il y a surement de belles grosses "story" trainant en backlog qui pourraient passer en en implémentation, ça aurait de quoi montrer que le sujet sait y faire face

2/ Si la roadmap est déjà planifiée sur du long terme, la meilleure façon de s'assurer des capacités du canditat sont à mon avis:

a/ De lui demander des exemples de projets comparable à ce qu'il devra faire
b/ Lui donner un projet à réaliser dans un temps imparti, par exemple 1 à 2 semaines sur son temps libre suivant sa condition et qu'il devra présenter / défendre durant l'entretient. Je trouve ça plus utile que de lui faire pondre 30 lignes de code après 40 minutes d'entretient avec la RH Et vu que (d'après les offres d'emploi actuel), tout le monde veut quelqu'un avec 5 ans d'expérience dans le domaine, connaissance de .Net avec 5 ans d'exp, maitrise de l'anglais du français et de l'allemand, certif SQL,...: candidat introuvable pour le salaire de misère que certains proposent, ça prouvera qu'il saura s'adapter pour se débrouiller dans son job.

[gokudomatic]

Faut-il faire coder les candidats durant les entretiens d'embauche ?

Non. Je pense qu'après avoir eu le blablabla de la RH sur l'entreprise pendant 15 minutes, avoir raconté sa vie pour montrer qu'il saura s'intégrer dans une team et résisté à des questions de "mise en pression cass-pied" pour voir comment réagit le candidat à des provocations, le faire jouer avec du code C sur un tableau blanc et plein de pointeurs supervisé par 1-2 développeurs qui le font tous les jours c'est un peu jouer au lotto pour avoir 5% de chance de recruter le bon candidat.

Quelle est selon-vous la meilleure méthode pour ne pas rater le recrutement d'un développeur ?
1/ Ne pas faire aveuglément confiance au candidat. Si il a pas mal d'expérience, il est malgré tout devenu habituel de "bullshiter" dans les CV. En Suisse, profiter des 3 mois d'essais pour lui infliger les plus grosses épreuves qu'il pourrait avoir à affronter, surtout si la place que le candidat vise est du genre "Scrum Master" / "Senior Architect"... il y a surement de belles grosses "story" trainant en backlog qui pourraient passer en en implémentation, ça aurait de quoi montrer que le sujet sait y faire face

2/ Si la roadmap est déjà planifiée sur du long terme, la meilleure façon de s'assurer des capacités du canditat sont à mon avis:

a/ De lui demander des exemples de projets comparable à ce qu'il devra faire
b/ Lui donner un projet à réaliser dans un temps imparti, par exemple 1 à 2 semaines sur son temps libre suivant sa condition et qu'il devra présenter / défendre durant l'entretient. Je trouve ça plus utile que de lui faire pondre 30 lignes de code après 40 minutes d'entretient avec la RH Et vu que (d'après les offres d'emploi actuel), tout le monde veut quelqu'un avec 5 ans d'expérience dans le domaine, connaissance de .Net avec 5 ans d'exp, maitrise de l'anglais du français et de l'allemand, certif SQL,...: candidat introuvable pour le salaire de misère que certains proposent, ça prouvera qu'il saura s'adapter pour se débrouiller dans son job.

Donner un projet à réaliser dans un temps imparti? En théorie, l'idée est bonne. Mais en pratique, aucun chercheur d'emploi n'aura le temps de faire ça. A moins que ce soit vraiment un micro-projet qui tient plus du devoir scolaire de la semaine qu'autre chose.

[Flaburgan]

Rajoute de plus que rien ne te prouve que ce sera lui qui l'aura fait.
Si les gens sont prêt à tricher sur leur CV, alors ils seront aussi prêt à faire passer les tests à d'autres.

Et puis quoi, on bosse pas pour des prunes non plus, coder un projet pour une entreprise qui ne nous a pas encore (et peut être jamais) embauché...

[gillai]

en revanche, quand on voit certaines offres où il est demandé à un développeur de connaître 10 base de données, 20 langages de programmation etc....

on se rend compte que les recruteurs sont vraiment de gros incompétents !!!

Ca c'est sûr. =)

Le nombre de fois que j'ai pu voir une recherche pour un junior qui avait 5 ans d'expérience Java et qui maîtrisait parfaitement Oracle et MySQL.

[gangsoleil]

Je pense qu'un gros travail est a faire en France la dessus, toute une culture de recrutement a réformer, la faute a notre histoire sans doute, histoire de hierarchie dans le systeme, et de respect et grande importance attachée a la notion d'institution.

Ce qui est dommage, c'est que le blog dont l'article est issu est tenu par un australien qui travaille a Sydney... Donc on peut reformer en France, ca ne changera pas son probleme.

Tu as eu une bonne experience en Ecosse ? Tant mieux pour toi. Moi j'en ai eu une bonne en France (hors SSII pour lesquelles je n'ai pas travaille), donc je pourrai aussi dire que le systeme francais fonctionne tres bien.

[gangsoleil]

b/ Lui donner un projet à réaliser dans un temps imparti, par exemple 1 à 2 semaines sur son temps libre suivant sa condition et qu'il devra présenter / défendre durant l'entretient. Je trouve ça plus utile que de lui faire pondre 30 lignes de code après 40 minutes d'entretient avec la RH

"Mon bon monsieur, je vous remercie de l'exercice que vous me proposez. Quelle est la remuneration que vous proposez pour que je me fasse chier pendant 2 semaines sur mon temps libre a vous prouver que quelqu'un (moi ou un autre) est capable de resoudre votre probleme ?"

Serieusement, si un recruteur me sort ca lors d'un entretien, je lui explique qu'il est bien gentil, mais que j'ai autre chose a foutre que de bosser le soir pour rentrer dans sa boite. Je pense d'ailleurs que je mets fin a l'entretien.

Et vu que (d'après les offres d'emploi actuel), tout le monde veut quelqu'un avec 5 ans d'expérience dans le domaine, connaissance de .Net avec 5 ans d'exp, maitrise de l'anglais du français et de l'allemand, certif SQL,...: candidat introuvable pour le salaire de misère que certains proposent, ça prouvera qu'il saura s'adapter pour se débrouiller dans son job.

Ca veut juste dire que ton candidat a suffisamment besoin de ce poste pour accepter de travailler au noir pour ta societe sur ses heures de temps libre, et de te rendre un projet que tu revendras tres cher a tes clients, pour peu que le candidat soit bon.

Oui, beaucoup d'offres sont delirantes, mais tes propos le sont egalement.

[narutobaka]

Ne pas s'étonner du recrutement de personnes ayant participer à des projets open source :
le recruteur peut voir leur technique et leur compétence facilement, en plus de se dire que la personne est motivée.

vous voulez vous faire voir ? participez activement à l'open source

Bonjour,

J'aimerai bien integre le développement d'un projet open source. Par contre je ne sais pas trop ou chercher et comment m'y prendre. J'avais commencé à regarder sur sourceforge, mais le plus dur je pense est de trouver un projet dont le sujet soit interessant.

De plus je ne suis qu'un développeur débutant. Je recherchais un projet genre développement LUA pour les add on WOW histoire d'allier l'utile à l'aggreable.

Si du monde connais des projets open source recrutant des développeurs pas spécialement très doué, ca me permettrait d'apprendre et de me faire la main .

Bon je retourne à mon code DELPHI

++

[bleporini]

Je fais la distinction entre celui qui pipeaute son CV en prétendant maitriser et celui dont ce n'est pas le cas, mais que l'on pourra mener à niveau.

On peut toujours faire monter une personne techniquement, à partir du moment où l'humain est viable, l'inverse est quasi impossible. C'est pour cela que je privilège toujours l'humain chez un candidat.

Mes propos portaient sur les candidats mythos.

Attention, je suis 100% d'accord sur le fait qu'il faut détecter les mauvais dans le process de recrutement; toutefois je considère que même un mauvais ou un fumiste prend la peine de se déplacer pour se plier aux étapes du recrutement ainsi je trouve que l'expédier après un test rate n'est pas très respectueux. De toutes façons je ne trouve pas que faire passer une interro écrite a un candidat soit très respectueux: les maçons ne demandent pas a leur candidat a aligner des querons pendant l'entretien pour savoir s'il vont l'embaucher, les restaurateurs ne le font pas non plus pour les serveurs.

Si toutefois on le reçoit même après un test foire, il ne faut pas perdre de vue que le candidat sera en position de justification par rapport a ses réponses précédentes. Et si on le reçoit après autant procéder a l'évaluation technique lors de l'entrevue.

Au risque d'en froisser certains, je pense que les tests techniques sont rassurants pour des personnes qui sont en position de recrutement et qui ne sont pas armées pour le faire: c'est quand même pas complique de demander a un candidat de lister quelques uns des design patterns qu'il a utilisé dans sa carrière et dans quelles situations, que signifie implémenter serializable ; que trouve-t-on dans un web.xml, quelles sont les possibilités pour mettre ne place un héritage dans un schéma relationnel, etc. Il y a quand même pas mal de questions qui permettent s'enchaîner sur des débats qui en diront beaucoup plus long que le résultat d'une interro!

[Bluespear]

"Mon bon monsieur, je vous remercie de l'exercice que vous me proposez. Quelle est la remuneration que vous proposez pour que je me fasse chier pendant 2 semaines sur mon temps libre a vous prouver que quelqu'un (moi ou un autre) est capable de resoudre votre probleme ?"

Serieusement, si un recruteur me sort ca lors d'un entretien, je lui explique qu'il est bien gentil, mais que j'ai autre chose a foutre que de bosser le soir pour rentrer dans sa boite. Je pense d'ailleurs que je mets fin a l'entretien.



Ca veut juste dire que ton candidat a suffisamment besoin de ce poste pour accepter de travailler au noir pour ta societe sur ses heures de temps libre, et de te rendre un projet que tu revendras tres cher a tes clients, pour peu que le candidat soit bon.

Oui, beaucoup d'offres sont delirantes, mais tes propos le sont egalement.

J'ai du être un peu trop vague dans mes propos. Je pense à un projet "à trou" qui pourrait prendre au grand maximum 2 heures au meilleur dev de la boîte (le plus expérimenté dans le job proposé). Ca serait surtout un projet où des bouts de codes clés sont manquant. Selon moi, ça permettrait de ne pas exclure un candidat qui sera capable d'apprendre rapidement.

Exemple: une boîte qui cherche un dev qui a de l'expérience Java, Spring, Hibernate, Swing, tests. On peut lui demander d'ajouter une fonctionnalité toute simple à un projet "factice" existant qui toucherait à ces trois domaines. Une personne maitrisan Java, Spring, Hibernate mais pas Swing passerait peut-être 3 heures au maximum en comptant le temps d'apprentissage de la documentation et l'écriture des tests qu'il juge pertinents.


Et cette méthode ne serait pas à appliquer à tous les postulants, mais par exemple au 2-3 candidats restants du 1er entretient. Enfin, ça reste une idée, et je sais que c'est déjà pas mal utilisé comme méthode

[omar24]

Un chef projet .NET qui ne sait même écrire une boucle!!!

[gangsoleil]

e pense à un projet "à trou" qui pourrait prendre au grand maximum 2 heures au meilleur dev de la boîte [...] Selon moi, ça permettrait de ne pas exclure un candidat qui sera capable d'apprendre rapidement.

Exemple: une boîte qui cherche un dev qui a de l'expérience Java, Spring, Hibernate, Swing, tests. On peut lui demander d'ajouter une fonctionnalité toute simple à un projet "factice" existant qui toucherait à ces trois domaines. Une personne maitrisan Java, Spring, Hibernate mais pas Swing passerait peut-être 3 heures au maximum en comptant le temps d'apprentissage de la documentation et l'écriture des tests qu'il juge pertinents.


Et cette méthode ne serait pas à appliquer à tous les postulants, mais par exemple au 2-3 candidats restants du 1er entretient. Enfin, ça reste une idée, et je sais que c'est déjà pas mal utilisé comme méthode

Le fait que ce soit utilise ne prouve en rien que ce soit une bonne methode.

Dans ton cas, tu parles de projets factice, mais on a deja vu ici quelques posts sur des entretiens dans lesquels il a clairement ete demande au postulant de travailler sur un vrai projet "pour voir ce qu'il vaut".

Quoi qu'il en soit, toute entreprise me demandant de passer 2 ou 3 heures chez moi sur un projet, tout factice qu'il soit, je les envoie promener - sauf si j'ai des problemes financiers bien sur.

[yoyo88]

pour ma part je n'ai pas eu de code a faire, mais on a parler pendant presque une heure au telephone sur divers point technique.

puis a l'entretiens j'ai amener un CV tres "ligth".
d'ailleurs les gens a face de moi on été etonné de voire si peu de language et technique.
j'ai alors expliqué que se n'es pas que je ne connais pas d'autre language, mais que ceux sur mon CV sont maitriser et que je ne voyais pas l'interet de me vanté de savoir faire du php, par example, alors que la dernierre fois que j'y ai toucher c'etait en premierre année de BTS et que je serrai strictement incapable de faire quoique faire quelque chose aujourd'hui.


J'ai volontairement jouer sur un CV épurer. je suis sur que j'ai été mis a l'ecart d'entré dans certaine société, mais d'un autres coté je me voyais mal faire du flash ou du php...

[HerQuLe]

Il y a un blog très interessant qui parle quelques fois de ces problématiques:
http://www.makinggoodsoftware.com/20...g-programmers/
http://www.makinggoodsoftware.com/20...-interviewing/
http://www.makinggoodsoftware.com/20...job-interview/



Vous oubliez pas mal de parler:

1) Des qualités de design du développeur.
Car savoir pondre un algo de tri bulle de tête c'est génial, et encore plus si vous savez programmer une fenêtre swing, et supercool si savez faire attendre et repartir des threads avant de les rejoindre et uberleet si vous savez exactement quelles exceptions sont levées par quelles methodes dans la stack IO de Java.

Vous pourriez être un expert algo, un expert langage, que vous ne seriez pas pour autant un bon développeur dans tel ou tel contexte, tout dépend des compétences recherchées...
C'est toujours bien de vérifier qu'un développeur sait au moins utiliser un grand minimum le langage, mais franchement, est-ce qu'il a réellement besoin d'être certifié SCJP pour être un bon développeur?
C'est sur que ça aide, mais c'est loin de faire tout.

Même en comprenant bien le fonctionnement des principaux concepts objets et les subtilités du langage, si on ne sait pas un minimum les appliquer correctement en fonction des situations, de factoriser son code, de le rendre lisible, et maintenable...
Je préfère largement quelqu'un qui ne va pas maîtriser a 100% de langage mais qui sera capable de pondre du code (pas forcement optimisé certes) efficace, robuste, maintenable.

Il vaut mieux quelqu'un qui utilise une ArrayList au lieu d'une LinkedList (en supposant que le choix ne soit effectivement pas bon), plutôt que quelqu'un qui va savoir quelle instance de List utiliser mais qui va faire un truc crado à coté... Je trouve ça moins risqué pour le projet en tout cas...



2) De ses connaissances des concepts fondamentaux des applications et méthodes de développement d'aujourd'hui (ioc, caching, locking, threads, middleware, rest, aop, transactions, tdd, agile, design patterns...). Pas forcément besoin d'un langage pour tester ces connaissances.

Je trouve pertinent de savoir, pour un développeur web qui a déjà travaillé sur des applications de paiement, de savoir ce qu'il pense d'un pattern comme le post/redirect/get.

Je trouve pertinent, pour un dev EJB3 / Spring, de voir s'il a bien compris le concept de propagation de la transaction (et pourquoi pas isolation)

Je trouve pertinent de voir si un dev comprend l’intérêt de l'injection de dépendance.

Je trouve pertinent de demander à un dev JEE son opinion sur la manière dont fonctionne un conteneur EJB3 (pourquoi pas l'aiguiller, et voir comment il avance petit à petit dans ses suppositions).

Je trouve pertinent de demander à un dev webservice/middleware ce qu'il pense des technologies SOAP / REST / ESB / AMQP / CORBA et autre et d'ouvrir le débat sur ses outils préférés (et raisons), en fonction des situations qu'il a pu rencontrer...



3) La personnalité.
C'est un point important également. Il y a des gens qui sont très bon mais qui vont s'attirer les foudres.
Entre ceux qui ne se remettent jamais en question et qui n'acceptent pas qu'on passe derrière eux, ceux qui refuseront de faire les taches chiantes ou les feront à l'arache, les associables, les codeurs illisibles sans doc...





Si un jour je dois faire passer un entretien, une des choses indispensables pour moi est que le candidat doit être capable d'avoir une opinion propre et de la justifier. Il doit aussi être capable de m'intéresser.
Si on est pas capable d'avoir un échange ou je peux lui apprendre des choses, voir sa manière de réagir et de raisonner, et lui de même, je pense que ça n'est pas la peine...

[el_slapper]

Un chef projet .NET qui ne sait même écrire une boucle!!!

Et???

L'important, c'est qu'il en aie conscience. J'ai vu une programmeuse minable(bon, pas à ce point) devenir une excellente chef de projet.

Le plantage garanti, c'est le CdP qui croit comprendre et qui ne comprend pas. Lui, il va imposer des solutions à la con, et ça va aller au casse-croute. J'ai vécu, c'est pénible.

Mais un CdP qui assume ses lacunes techniques, qui sait motiver les gens, qui sait contrôler le résultat, ça peut marcher. Avec des progs expérimentés dans l'équipe, évidemment. Avec des débutants, il y aura toujours des trous techniques qui poseront problème à terme.

Quand à l'argument du pipotage, certes il peut exister, mais quand on a ce genre de ressources, c'est mal barré de toutes façons. Le mec a pas envie de bosser, il trouvera toujours un moyen de ne pas bosser. D'ou le point que certains ont soulevé : la compétence ne suffit pas.

[pseudocode]

Quelle est selon-vous la meilleure méthode pour ne pas rater le recrutement d'un développeur ?

Google {nom du développeur}

[cs_ntd]

Tout le monde n'a pas la "chance" ou l'envie d'etre référencé sur google ceci-dit

[air-dex]

Le but d'un entretien est d'en savoir un maximum sur les aptitudes d'un candidat. Partant de là, je ne vois pas pourquoi il faudrait proscrire les tests techniques.

Sans oublier les compétances sociales de la personne (3 pages et il y a pas un post qui les cites... Bravo les gars!) vu qu'une équipe qui s'entend bien a tendance à mieux travailler qu'une équipe de chiffonnier.

Quand je parlais des aptitudes d'un candidat page 2, je voulais parler de ses aptitudes sociales et de ses aptitudes techniques. Désolé de ne pas avoir été plus clair.

Des tests de recrutement avec des pièges, des cas tordus etc.., on en voit de plus en plus
Beaucoup de société passe à côté de bon recrutement parceque les candidats se sont plantés sur des QCMs machiavéliques

La meilleure façon pour recruter un bon CP, c'est d'exposer un problème et de trouver une solution en appliquant un design pattern par exemple (composite, factory, observateur etc ...).

Parce que les design patterns ne font pas partie de la technique peut-être ?

si on recrute un candidat pour faire du développement Java, on doit lui mettre à disposition un IDE qu'il a indiqué pratiqué dans son CV, la Javadoc .

On recherche des compétences sur un langage de programmation, pas un outil ! Dans ce cas là, tu peux aussi prétendre à une place à l'Académie Française parce que tu sais utiliser le correcteur d'orthographe de Word.

Pour le techos je me devais de connaitre l'ensemble des méthodes du langage, ce qui pour moi ne sert à rien avec IntelliSense et les docs sur le net.

Dans ce cas là, dis nous en plus sur la question. Parce que si t'as échoué sur une exception du genre NullPointerException ou LeNumeroDePortEstMauvaisException, ça ne le fait pas. Certes on ne peux pas tout connaitre mais il y a quand même un minimum à savoir, IntelliSense ou pas.

Tout le monde n'a pas la "chance" ou l'envie d'etre référencé sur google ceci-dit

Ou d'être bien mis en valeur (j'en connais ).

[highleaf]

A quand les tests pour les faux managers et faux chefs de projets qui ne savent pas écrire un email sans faire 10 fautes d'orthographe ? Je crois qu'il faudrait commencer par la dictée.

"Ce qui se conçoit bien s'énonce clairement - Et les mots pour le dire arrivent aisément.", je pense que cela peut aider en informatique, me trompe-je ?

Pour aller plus loin ,des tests sur de la syntaxe, je trouve cela débile, des tests d'algo pourquoi pas...je ne suis pas non plus pour les certifications. Je suis un vrai républicain, je préfère un savoir plus large, de meilleure qualité, permettant une adaptation aisée et pas seulement devenir un pseudo codeur/commercial sponsorisé .

Il me semble qu'un problème informatique est avant tout un problème d'analyse avant un langage ou une syntaxe. De toute façon, les SSII et ce type de recruteur, en général, ça me dégoûte , je laisse ça aux jeunes diplômés qui aiment frimer en smart avec leur iPhone.

[Higgins]

... Ou alors la période d'essai n'a pas été bien faite, mais là c'est un autre problème.

C'est pas faux
Un malheureux enchainement de circonstances:
recrutement fin juin avec période d'essai sur juillet-août avec un suivi réparti entre plusieurs personnes au gré des congés ( On ne refera plus).
Les premières étapes, comme l'habituelle période de familiarisation avec la base du code (et le langage), l'épreuve des bogues, avant de le mettre sur des choses plus sérieuses ne se sont pas trop mal passées, c'est quand il a fallu rentrer dans le vif du sujet que ça a merdé.