[entretien] insuffisance technique

[ighost]

bonjour a toutes et a tous ,

le problème que j'aimerais vous exposer est le suivant:

jai eu affaire a pas mal d'entretien ces derniers temps (au moins 7-8) et malgré une expérience d'un an et demi en dot net, je me suis souvent vu refusé l'emploi car je "n'avais pas les bases" ou bien encore "pas assez d'experience" ou encore "niveau technique très bas".

personnellement j'ai développé seul un logiciel de gestion des affaires et des contrats avec donc plusieurs module contenue chacun dans une dll:
module affaire
module projet
module suivi et management de la qualité
module lettre de mission

chaque module se complétant ou se soustrayant (le module lettre de mission ne peut pas être avec le module de projet)

j'ai manié visual studio .net 2003 pendant 1 ans et demi, utilisé le maximum de fonctions possible, creer des classes, encapsuler les données,creer des methode pour ses classes, utiliser les winforms et webforms (pour la version asp du logiciel), utiliser des bibliothèques de classes deja créé dans le logiciel.

tout ca pour venir au fait:
qu'est ce qui cloche avec moi? suis je reellement un noob techniquement ou ai'je un réél problème d'explication de mes connaissances, j'aimerais savoir.

je suis un peu décu d'être obligé de réviser mon dico des termes techniques avant chaque entretien.

bref j'aimerais un eclaircissement.

[LuckyLiam]

Envoyé par ighost

bonjour a toutes et a tous ,

le problème que j'aimerais vous exposer est le suivant:

jai eu affaire a pas mal d'entretien ces derniers temps (au moins 7-8) et malgré une expérience d'un an et demi en dot net, je me suis souvent vu refusé l'emploi car je "n'avais pas les bases" ou bien encore "pas assez d'experience" ou encore "niveau technique très bas".

personnellement j'ai développé seul un logiciel de gestion des affaires et des contrats avec donc plusieurs module contenue chacun dans une dll:
module affaire
module projet
module suivi et management de la qualité
module lettre de mission

chaque module se complétant ou se soustrayant (le module lettre de mission ne peut pas être avec le module de projet)

j'ai manié visual studio .net 2003 pendant 1 ans et demi, utilisé le maximum de fonctions possible, creer des classes, encapsuler les données,creer des methode pour ses classes, utiliser les winforms et webforms (pour la version asp du logiciel), utiliser des bibliothèques de classes deja créé dans le logiciel.

tout ca pour venir au fait:
qu'est ce qui cloche avec moi? suis je reellement un noob techniquement ou ai'je un réél problème d'explication de mes connaissances, j'aimerais savoir.

je suis un peu décu d'être obligé de réviser mon dico des termes techniques avant chaque entretien.

bref j'aimerais un eclaircissement.

C'est idiot mais malgrés tes réalisations et ton expérience opérationnelle, j'ai l'impression que c est tes 1an et demi d'expérience qui gêne les recruteurs.
Essaye d'être moin technique lors de tes entretiens (laisse venir les questions) et mets en avant les acotés (relations avec les utilisateurs, autonomie dans le travail) etc ..., je pense que c'est ce qui est intéressant dans ton profil

[titides]

Quelque part, 1 an 1/2 d'expérience, c'est pour certains recruteurs être "débutant".
Donc après, il faut voir à quelle annonce tu réponds, car si c'est pour des postes de sénior, c'est évident que tu es "trop faible".
Il faut ainsi voir comment tu te présentes, voir la présentation de ton cv et surtout à quel type d'annonces d'emploi tu réponds.

[bizet]

Je te connais pas mais peut etre as-tu appris à programmer en .NET mais tu ne connais pas le fonctionnement et les concepts.

Je sais que dans la boite où je suis, ils cherchent à embaucher des dev .NET, et le genre de questions qu'ils posent sont :

- quel est le principe de fonctionnement du framework .NET?
- quelles sont les nouveautés du Framework 3.0?

ou sur des concepts comme l'heritage des objets, les evenements,design patterns ....

Et ben tu peux etre super bon en technique mais si tu n'as pas lu ou appris ca, difficile de répondre.

De même souvent on te pose une question dont il est impossible de trouver la solution mais le recruteur cherche à discerner ta façon d'analyser le problème et le résoudre en proposant des solutions.

[pinocchio]

Envoyé par bizet

Je te connais pas mais peut etre as-tu appris à programmer en .NET mais tu ne connais pas le fonctionnement et les concepts.

Je sais que dans la boite où je suis, ils cherchent à embaucher des dev .NET, et le genre de questions qu'ils posent sont :

- quel est le principe de fonctionnement du framework .NET?
- quelles sont les nouveautés du Framework 3.0?

ou sur des concepts comme l'heritage des objets, les evenements,design patterns ....

Et ben tu peux etre super bon en technique mais si tu n'as pas lu ou appris ca, difficile de répondre.

De même souvent on te pose une question dont il est impossible de trouver la solution mais le recruteur cherche à discerner ta façon d'analyser le problème et le résoudre en proposant des solutions.

+1
Je travaille en . Net depuis juillet 2002 et pourtant je me fais bouler facilement en entretien technique sur des questions comme ci-dessus. Tout simplement car contrairement à une personne tout juste sorti des études, j'ai la pratique mais je ne connais pas les termes technique de ce que j'utilise. En général, par contre, je m'en sors car je ne trouve pas les réponses à leurs questions mais j'anlyse et explique leurs réponses. Ce qui permet de prouver que je connais
cordialement
Pinocchio

[Eowyn]

C'est clair qu'en 1.5 ans tu as eu le temps de tester, d'utiliser et d'apprécier ? .net
Il faut voir qui te pose les questions techniques .net
Si c'est un collaborateur des RH, imagine-toi bien qu'il n'y connaît que dalle et qui va noter ce que tu dis, va comparer avec ce que lui a donné l'IT et si le terme exact n'est pas là, ben t'as tout faux. Alors que peut-être tu maîtrises complétement le sujet...
Si c'est quelqu'un de l'IT, tu ne devrais pas trop avoir de problème à "prouver" que tu maîtrises le sujet. Je pense qu'avec quelqu'un du IT, c'est aussi la façon de "résoudre" le problème qui va l'intéresser. Comment est-ce que tu t'en sors devant un problème de type xy.

Alors, oui, peut-être il faut que tu révises ton vocabulaire ou alors peut-être revoir ta façon de te présenter, ou ta façon d'argumenter.

Bon courage

[gangsoleil]

Bonjour,

Chaque poste est différent d'un autre, et chaque entreprise est différente de celle d'en face, d'où une certaine difficulté à répondre à une question qui reste somme toute assez vague...

Selon l'entreprise et le poste, on peut attendre un super-spécialiste d'un domaine (par exemple quelqu'un qui a passé au moins la dernière année à trifouiller dans tous les sens les frameworks .NET), ou au contraire un super-généraliste : quelqu'un qui a beaucoup de recul sur divers technologies/environnements/....

Bien sur, moins on a d'expérience, moins les contraintes sont élevées pour avoir le poste.

Saches aussi que passer 7 ou 8 entretiens n'est, malheureusement, plus suffisant aujourd'hui pour trouver du boulot, surtout si ces entretiens ne sont pas dans des SSII et qu'en plus tu n'as pas un profile atypique (spécialiste Cobol par exemple).

Enfin, une fois que tu as une réponse négative sur un entretien, rien ne t'empêche de demander un rendez-vous à la personne que tu as rencontré pour essayer de voir avec elle quels sont les points qui ont fait que tu n'as pas eu le poste (c'est à dire quels sont tes points faibles à travailler).

[Louis-Guillaume Morand]

j'ai manié visual studio .net 2003 pendant 1 ans et demi,

tu as fait du 1.0 voire 1.1.

tu es donc probablement à la ramasse sur le framework 2.0 qui implemente plein de concepts importants du developpements, (generics, etc)

Ensuite y a le 3.0 puis le 3.5 donc si en plus tu n'as pas par toi meme fait de veille technologique c'est déjà mal parti pour prouver ton intérêt.


Ensuite, dans un entretien en plus d'une personne qui cherche à être à la pointe d'une techno ils cherchent des personnes ayant du recul sur le developpement objet. faire un programme, tout le monde peut le faire. Mais ensuite programmer proprement (=intelligemment niveau archi), c'est plus pareil pour tout le monde. Si faire le parallèlisme entre abstraction et implémentation dans un cas pratique ne te semble pas évident à expliquer alors c'est que ces concepts qui ne dépendent pas du .Net particulièrement ne sont pas maitrisés.
je te conseille fortement de te mettre aux design patterns car souvent ca tombe aux entretiens et surtout, comprendre les DP necessitera de ta part une maitrise des concepts objets.

Après cela, tu seras mieux préparé aux entretiens mais ca ne sera jamais facile pour autant

[Jester]

Juste pour te donner une impression (ne le prend pas mal), mais à te lire ça ne donne pas l'impression que tu maîtrise bien la chose (c'est peut-être le cas, mais tu le décrit mal dans ton écrit).

> creer des classes, encapsuler les données,creer des methode pour ses classes, utiliser les winforms et webforms (pour la version asp du logiciel), utiliser des bibliothèques de classes deja créé dans le logiciel.

Tu écrit plus ou moins que tu sais parler les bases du français : construire des phrases, utiliser des adjectifs, mettre des verbes ... c'est du trop bas niveau.

C'est difficile à dire ce qu'il faudrait mettre à la place, apprendre un peu le génie logiciel c'est déjà une bonne idée. Mais montrer que tu pense en .Net que par défaut ton esprit visualise comment architecturer une idée que tu dois implémenter.

Plus pragmatique, regarde aussi du coté des test unitaires, extreme programming (cf wikipedia par exemple). Si tu "vis" le code, chaque sujet doit t'intéresser pendant au moins une heure. Ca t'aidera à avoir le feeling de faire les choses bien.