Conseil sur mon Cv (echec de mission)

[solitude]

voilà j'aimerai avoir votre avis j'ai quitté ma boite en juin et j'ai été recruté par une SSII et j'ai fais une mission chez un client soldée par un echec au bout de 2 mois juillet-août. La SSII a mis fin à mon contrat. Le client s'est plaint que je ne suis pas à la hauteur de cette mission. maitenant je suis entrain de postuler pour d'autres offres, est ce que je dois laisser cette mission sur mon Cv ou l'enlever carrement sachant que si je l'enlève ça me fera un trous de 6 mois que je dois justifier.

Merci pour votre conseil.

[YannPeniguel]

Je pense que c'est mieux de laisser ça. C'est moins grave d'avoir échoué une mission que d'être resté au chômage pendant tout ce temps.

Cela nous arrive tous un jour de rater quelque chose, t'auras au moins eu le mérite d'avoir essayé.

[phili_b]

6 mois ?! C'est clair qu'on ne peut pas supprimer une telle durée d'un CV.

[solitude]

mon pb maintenant que dois je dire à un nouveau recruteur concernant cette mission que j'ai raté. S'il me pose la question pourquoi tu as quitté ta boite au bout de 2 mois , je dirai qu'ils ont mis fin à mon contrat et s'il me dit pourquoi alors je peux dire la verité je n'étais pas à la hauteur mais ça va jouer contre moi et si je dis c'est une petite mission et qu'il appelle la SSII en question , ils vont lui dire que c'est eux qui m'ont viré parce que je n'étais pas à la hauteur.
Enfin.

[la drogue c'est mal]

la vraie question est la raison de cet echec et ce que tu as fait pour que cela ne se reproduise plus.

si tu arrives devant un recruteur en disant que tu as été nul et que tu n'en as tiré aucune conséquence, tu vas te faire balourder, c'est certain

[solitude]

Envoyé par la drogue c'est mal

la vraie question est la raison de cet echec et ce que tu as fait pour que cela ne se reproduise plus.

si tu arrives devant un recruteur en disant que tu as été nul et que tu n'en as tiré aucune conséquence, tu vas te faire balourder, c'est certain

oui je sais pourquoi ça s'est arrivé , c'est parce que là où je travaillais avant on developpait d'une certaine façon qui avec le temps ne me plaisait pas du tout , c'etait des petits projets et ils sont developpés avec l'assistant de l'environnement de developpement (visual studio) , on ne faisait pas beacoup de developpement (production de code en particulier la decomposition en couche, l'abstraction , on ne maitrisait pas tout ça), et du coup j'ai decidé de voir ailleurs et quand je suis arrivé chez le nouveau client avec ma nouvelle boite, je me suis retrouvé avec une equipe tres competente , jamais ils n'utilisent l'assistant de developpemnt (ils font tout par code), j'avais du mal à suivre , je ne dormais pas le soir , les week end j'essai de comprendre ce qu'ils font , je sentais mon niveau tres bas par rapport à eux alors ils se sont aperçu que je ne suis pas celui qu'il faut.
leçon: j'ai beaucoup developpé mais pas d'une façon professionnelle, pourtant les applications marchaient bien , elles fonctionnaient mais au fond de moi ce n'est pas professionnel.

Voilà un peu pourquoi j'ai raté la mission.

[phili_b]

Envoyé par solitude

je n'étais pas à la hauteur

ça veut dire quoi ne pas être à la hauteur ? Ils t'ont mis au pied du mur avec une demi-journée de formation, ou alors un poste trop lourd pour tes épaules, ou alors comme tu le penses tu as été mauvais ?

Et si tu as été mauvais, est-ce que c'est facile à corriger (genre avoir développé le nez dans le guidon et avoir dépassé le délai sans demander d'aide) ?

[solitude]

Envoyé par phili_b

ça veut dire quoi ne pas être à la hauteur ? Ils t'ont mis au pied du mur avec une demi-journée de formation, ou alors un poste trop lourd pour tes épaules, ou alors comme tu le penses tu as été mauvais ?

Et si tu as été mauvais, est-ce que c'est facile à corriger (genre avoir développé le nez dans le guidon et avoir dépassé le délai sans demander d'aide) ?

Ils m'ont confié des taches et j'ai pris du temps pour les faire , en plus le code que je produisais c'était un code basique , il n'avait pas la norme d'un codage d'un professionnelle. Je ne maitrisais pas bien les concepts de la programmation orientée objet.

[YannPeniguel]

Envoyé par solitude

Ils m'ont confié des taches et j'ai pris du temps pour les faire , en plus le code que je produisais c'était un code basique , il n'avait pas la norme d'un codage d'un professionnelle. Je ne maitrisais pas bien les concepts de la programmation orientée objet.

[Mode Recruteur]
Et donc, depuis ce temps, avez vous fait en sorte de mieux maîtriser ces concepts afin de ne pas tomber dans le même piège?
[/Mode Recruteur]

[solitude]

Envoyé par YannPeniguel

[Mode Recruteur]
Et donc, depuis ce temps, avez vous fait en sorte de mieux maîtriser ces concepts afin de ne pas tomber dans le même piège?
[/Mode Recruteur]

oui effectivement j'ai fais des efforts dans ce sens, mais le doute m'envahi , au point j'hesite de postuler de peur de paraitre incompetent.

[YannPeniguel]

Commence par croire en toi.

Fais toi un projet Java ou C# avec du bel orienté objet, histoire de te prouver que tu en es capable, si vraiment ça te travaille.

N'importe quoi, genre un pong ou un jeu de dames, en plus c'est marrant.

[vpourchet]

Le truc face au recruteur c'est de ne pas mettre en cause tes competences. Si tu sens que le projet de ton nouveau recruteur te convient et que tu penses etre a la hauteur, ne te grille pas en insinuant que tu doutes de tes capacites.

Un echec de mission c'est pas catastrophique, t'as pas formate un serveur ou fait perdre des millions au client. Tu peut l'expliquer en disant par exemple qu'on a 'surevaluer' tes capacites. Si t'est JD c'est encore mieux parce qu'on pardonne plus facilement a un JD.

Et si le recruteur ne cherche pas a connaitre ton niveau de connaissances lors de l'entretien tu peut poser des questions aussi du genre 'quel EDI utilisez vous ?',' Utilisez vous des composants/api/technos specifiques ?', etc ... Il est bon de savoir ou l'on met les pieds. Et au pire tu peut aussi demander a rencontrer l'equipe que tu vas integrer avant de signer et leur poser les questions sur les ;ethodes de travail.

Corrigez moi si je dis des trucs invraisemblables.

[YannPeniguel]

Envoyé par Valus25

..
tu peut poser des questions aussi du genre 'quel EDI utilisez vous ?','
..

Corrigez moi si je dis des trucs invraisemblables.

Typiquement ce genre de question fait plus rigoler qu'autre chose je pense.
Tu code avec ce que tu veut, en tout cas la ou je suis, du moment que le code que tu produit est bon.

L'EDI n'est qu'un outil de travail, c'est comme si tu demande à un mécano la marque de ses tournevis.

[vpourchet]

je ne suis pas d'acord

dans certaines boites des standard niveau prog existent du genre ViSualStudio only + WinCVS + AGILE ... mais bien sur cela ne vaut que si tu est integre a une equipe sur un projet. si tu gere tout seul apres oui c'est sur que tu fais ce que tu veut ... mais je pensais qu en general les boites obligaient a utiliser un EDI et des outils particuliers ...

[YannPeniguel]

Envoyé par vpourchet

mais bien sur cela ne vaut que si tu est integre a une equipe sur un projet. si tu gere tout seul apres oui c'est sur que tu fais ce que tu veut ... mais je pensais qu en general les boites obligaient a utiliser un EDI et des outils particuliers ...

Mais tu peut travailler en équipe sans avoir le même IDE que les autres! Les IDE ne sont que des logiciels d'édition de code source, ce qui importe c'est d'utiliser les mêmes technos et standards.

Exemple: Ton projet est du Java, les sources sont sur un SVN et les composants utilisés sont Maven, Apache POI et Hibernate (je dis au hasard).

Du moment que tu fais du Java avec les mêmes composants que tes collègues, autrement dit ceux choisis pour ce projet, on s'en fiche que tu édites tes sources avec Eclipse, Netbeans, ou mêmes VIM + un shell! Ce que tes collègues récupèrent, c'est le code que tu auras commité sur le serveur de sources, qui ne dépend pas de ton IDE.

[el_slapper]

Y'en a qui n'ont jamais bossé en milieu bancaire, à ce que je vois, où le développeur n'est même pas admin de son poste, et doit donc utiliser les outils validés par l'installateur centralisé. Ma brève incursion chez un éditeur de logiciel m'a permis d'entrapercevoir un monde de liberté à la frontière entre le grisant et le dangereux, mais ma carrière m'a bien vite ramené dans les très grandes entreprises ou il faut parfois 3 semaines de négociations pour obtenir un accès internet limité developpez.com et consorts.....

Non, demander les outils utilisés n'a rien de stupide - sauf si on postule en SSII sur profil.

[YannPeniguel]

Je suis un profil dans une SSII

Je considère que un développeur est assez grand pour choisir ses outils, mais peut être suis-je utopiste...

Après, est-ce vraiment important? J'ai utilisé des choses très variés pour faire du Java pendant mes études, mes stages et mon travail, ça va de VIM + scripts bash à Eclipse, et je trouve que ce n'est pas un critère très pertinent, on s'en sort toujours et on fait la même chose avec. Cela m'intéresse beaucoup plus de savoir ce que je dois coder, et à l'aide de quelles briques logiciels.

[el_slapper]

Envoyé par YannPeniguel

Je suis un profil dans une SSII

Moazossi.

Pour tes missions, la question peut être utile. Pour entrer dans ta SSII, non. Pareil pour moi.

Envoyé par YannPeniguel

Je considère que un développeur est assez grand pour choisir ses outils, mais peut être suis-je utopiste...

j'ai croisé assez d'incapables pour me méfier de telles assertions. J'ai aussi fait beaucoup de maintenance, et j'en suis arrivé à la conclusion que mieux vaut un mauvais style de programmation qu'un mélange de 2 bons.

Envoyé par YannPeniguel

Après, est-ce vraiment important? J'ai utilisé des choses très variés pour faire du Java pendant mes études, mes stages et mon travail, ça va de VIM + scripts bash à Eclipse, et je trouve que ce n'est pas un critère très pertinent, on s'en sort toujours et on fait la même chose avec. Cela m'intéresse beaucoup plus de savoir ce que je dois coder, et à l'aide de quelles briques logiciels.

Sauf que chez des clients de taille industrielle(je parle du SI, la taille réélle du client on s'en fout), une bonne standardisation des process et des outillages est indispensable à une bonne maitrise de l'existant. Si chacun fait son truc dans son coin à sa sauce, on obtient un mélange indigeste. Surtout, il devient difficille de reprendre le travail du petit camarade qui a eu un empechement(enfant malade, accident, départ précipité). Nul ne doit être indispensable.

Bon, je fais du COBOL/MVS, c'est un poil différent, mais ce que je code doit être obligatoirement être mis dans un PDS(un répértoire, en gros) défini par les normes du client. Comme ça, si je ne rentre pas de vacances, mon collègue sait déjà ou chercher mon boulot. Et comme il a le même IDE que moi(ISPF pour ne pas le nommer), il n'aura pas de problème de compatibilité ou que sais-je. La standardisation est obligatoire au travail en groupe.

[vpourchet]

perso quand j'etais dev on m'a toujours impose les outils justement a cause des standards au niveau procedures tout ca ... (grands comptes du secteur immobilier). j'ai peut etre generalise un peu vite en pensant que c'etait partout pareil.

Après, est-ce vraiment important? J'ai utilisé des choses très variés pour faire du Java pendant mes études, mes stages et mon travail, ça va de VIM + scripts bash à Eclipse, et je trouve que ce n'est pas un critère très pertinent, on s'en sort toujours et on fait la même chose avec. Cela m'intéresse beaucoup plus de savoir ce que je dois coder, et à l'aide de quelles briques logiciels.

pour l'EDI peut etre pas mais par exemple pour :

Maven, Apache POI et Hibernate

si tu pose pas la question et qu'ensuite on te demande de les utiliser sans que tu connaisse ca risque d'etre un peu plus 'touchy'

[YannPeniguel]

Envoyé par el_slapper

j'ai croisé assez d'incapables pour me méfier de telles assertions. J'ai aussi fait beaucoup de maintenance, et j'en suis arrivé à la conclusion que mieux vaut un mauvais style de programmation qu'un mélange de 2 bons.

Quel est le rapport avec les IDE? Ce n'est qu'un logiciel d'édition de sources et d'aide au développement, il n'a rien a voir avec ton style de programmation.

Si chacun fait son truc dans son coin à sa sauce, on obtient un mélange indigeste.

En terme de code produit, oui, il faut coder selon les mêmes conventions! Mais l'éditeur que tu as utilisé pour le faire n'influence pas cela.

Et comme il a le même IDE que moi(ISPF pour ne pas le nommer), il n'aura pas de problème de compatibilité ou que sais-je.

Si le format de tes fichiers de travail est propriétaire, cela se comprend.
Mais avec la plupart des langages que j'ai utilisé, les sources ne sont que des fichiers textes avec une extension particulière. Donc on les ouvre avec ce que l'on veut.

Envoyé par vpourchet

si tu pose pas la question et qu'ensuite on te demande de les utiliser sans que tu connaisse ca risque d'etre un peu plus 'touchy'

Les librairies et Frameworks c'est normal, c'est des éléments du projet, et c'est des compétences techniques pointues.

J'ai l'impression qu'il y a un malentendu ici entre les différents maillons d'un projet. Dans un projet, tu dois effectivement produire quelque chose qui s'intègre à ce que font les autres, mais ce qu'il faut bien comprendre c'est que en Développement Java/C/C++/C#... tes sources ne sont que du texte, que tu peut éditer avec ce que tu veut. Du moment que les sources que tu produit sont conformes à ce qui est attendu, les autres n'ont aucun problème pour l'intégrer.
Je le répète, les IDE ne sont que des super-éditeurs de code source assorti d'outils d'aide au développement.
C'est un petit peu comme si on enfonce un poteau à plusieurs en tapant chacun notre tour: cela n'a pas d'importance qu'on ai des marteaux différents.