Discussion :

[erwanlb]

J'ai pas une grosse culture de dév pour l'instant, j'aurais du mal à expliquer avec les bons mots ce qu'est le polymorphisme, l'héritage, etc....et pourtant je suis le seul de la boite à faire du .Net, je tiens mes objectifs en terme de qualité et de délais. Le tout chapoté par un chef de projet qui a fait 5/6 ans dans une SSII.

Suis je un mauvais, moyen ou bon développeur ?

Parce que quand je lis les com's j'me sens un peu à coté d'la plaque

J'ai l'impression que beaucoup sortent d'universités, écoles, etc, on des méga bases, grosse culture mais n'ont finalement pas la possibilité d'en apprendre et découvrir autant que moi avec mes petites fondations

[Gugelhupf]

Si tu es passionné par l'informatique, que tu aimes ton travail, que tu t'appliques, je ne vois pas pourquoi tu serais mauvais.
On apprend beaucoup avec le temps sur le terrain, on n'a pas forcément besoin d'avoir un bac+5 pour être un bon développeur.

[Erouan]

Si tu es passionné par l'informatique, que tu aimes ton travail, que tu t'appliques, je ne vois pas pourquoi tu serais mauvais.
On apprend beaucoup avec le temps sur le terrain, on n'a pas forcément besoin d'avoir un bac+5 pour être un bon développeur.

Je suis totalement d'accord, je suis en 4ème année dans une école qui donne un niveau BAC+5, et c'est ce n'est pas grâce aux cours mais aux stages et à la pratique que j'ai vraiment progressé dans ce domaine.

[amezghal]

pour un développeur web par exemple, avoir des projets en ligne et selon la nature/complexité de ces projets, tu risques d’être accepté sur place sans tests techniques.

[alex_vino]

Lors de mon entretien j'ai quand meme du citer et expliquer tous les patterns du GoF.

Je ne les connais pas tous par coeur, et la plupart ne les ai meme jamais utilisé, mais l'essentiel n'était pas la, le fait d'etre capable de discuter sur ce sujet, d'avoir des notions et de partager des points de vue a montré l'aspect positif et ouvert.

Pour le polymorphisme et les autres questions de l'actualité oui je trouve cela assez basique, ce ne sont pas des questions pieges pour quelqu'un qui est ingénieur en développement. Si un ingénieur ne sait pas cela alors pourquoi ne pas embaucher une personne sans diplome, ma phrase est bien evidemment extreme mais l'idée est la. Les entreprises ne vont pas former des bac+5 sur les notions informatiques de bases pour le poste qu'ils postulent, sinon le monde tourne a l'envers.

Sinon il y a aussi les tests de personnalités et les tests de QI, raisonnement (abstrait, logique...) et des mini-projets a rendre.

[transgohan]

Pour le polymorphisme et les autres questions de l'actualité oui je trouve cela assez basique, ce ne sont pas des questions pieges pour quelqu'un qui est ingénieur en développement. Si un ingénieur ne sait pas cela alors pourquoi ne pas embaucher une personne sans diplome, ma phrase est bien evidemment extreme mais l'idée est la. Les entreprises ne vont pas former des bac+5 sur les notions informatiques de bases pour le poste qu'ils postulent, sinon le monde tourne a l'envers.

Disons que cela peut se concevoir dans certains cas... Je prends mon exemple j'ai une mémoire horrible (et c'est pas faute de la faire travailler). Je mets bien un mois pour retenir des noms voire même de visages...
Concernant les notions que vous citez je serais bien incapable de donner une définition à certaines, mais ce n'est pas pour autant que je ne les connais pas. C'est la faute de l'association au nom. Je les applique avec brio et ce naturellement mais ne sais pas les nommer.
Suis-je donc un mauvais développeur ou bien juste une personne qui code correctement mais qui n'est pas pédagogue ?

[psychadelic]

Je suis tombé une fois sur un recruteur qui ne savait même pas de quoi il parlait, pourtant c’était le chef de projet (sur des applications c#).

La question : vous connaissez les threads ?

Ma réponse : oui, je connais bien la question, et même de « l’intérieur », puisque j’ai même moi-même développé un sémaphore au sein de … (renvoi à mon cv qu’il a sous les yeux).

Apres l’entretien on me dit que je n’avais pas répondu à sa question…
Ce type ne savait même pas ce qu’est un sémaphore en informatique !

Depuis cette histoire, je me suis rendu compte que lors des entretiens d'embauche, que certains n'ont qu'une connaissance très partielle des questions qu'ils posent...

[laerne]

@pavel, c'est sur que le mec qui écrit "int i = ++++a++a," on a pas envi de bosser avec lui. Mais le mec qui ne sais pas répondre à la question, on a encore moins envie !!!

Euh c'est quand même vicieux ce bout de code… Je me crois pas un gland en informatique mais là j'ai du mal… Si on parenthèse ça donne quoi*?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int i = (++(++(a))+(+a)?

Non mais si on me demande, je dis que je consulte le K&R pour décrypter et que je change la ligne du projet en quelque chose de lisible*!

[LLB]

Euh c'est quand même vicieux ce bout de code… Je me crois pas un gland en informatique mais là j'ai du mal… Si on parenthèse ça donne quoi*?

Ne t'embête pas, ça ne parse pas. Si on ajoute une espace, "++++a+ +a" :
- ça ne parse pas en C (++a n'est pas une lvalue)
- ça parse en C++ et ça renvoie une valeur non définie (lecture et écriture d'une variable dans le même sequence point)
- ça ne parse pas en C# (++a n'est pas une lvalue, mais un truc comme "++a + a++" est défini et s'évalue de gauche à droite)

Le seul truc intéressant à connaître ici, c'est de savoir quand du code est susceptible d'avoir un comportement non défini (mais pas besoin de connaître tous les détails des sequences points). De même façon, un overflow ne renvoie pas une valeur définie en C et C++. Il arrive souvent que ça boucle en pratique, mais le compilateur est libre d'optimiser autrement (il peut remplacer "a+1 > a" par true).


Quant aux entretiens, c'est intéressant, ça donne une bonne idée de ce que l'entreprise cherche, de la culture d'entreprise. Si l'entretien ne correspond pas à mon profil, est top simple, trop peu technique, s'attarde sur des choses qui ne m'intéressent pas (design patterns, UML...) ou s'il n'y a pas d'entretien avec quelqu'un de technique... je sais d'avance que je refuserai le poste.

[erwanlb]

Je suis tombé une fois sur un recruteur qui ne savait même pas de quoi il parlait, pourtant c’était le chef de projet (sur des applications c#).

La question : vous connaissez les threads ?

Ma réponse : oui, je connais bien la question, et même de « l’intérieur », puisque j’ai même moi-même développé un sémaphore au sein de … (renvoi à mon cv qu’il a sous les yeux).

Apres l’entretien on me dit que je n’avais pas répondu à sa question…
Ce type ne savait même pas ce qu’est un sémaphore en informatique !

Depuis cette histoire, je me suis rendu compte que lors des entretiens d'embauche, que certains n'ont qu'une connaissance très partielle des questions qu'ils posent...

Sémaphore, c'est un poste de guet établi sur la côte

[epeios]

Cela fait plus de 10 ans que je développe quotidiennement en C++. Pourtant, cela n'en fait pas de moi un expert dans ce langage, dans la mesure où (entre autres) je n'ai jamais utilisé la STL, ou que je peine à me souvenir de la dernière fois que j'ai utilisé l'opérateur new.

Concernant la STL, ce n'est qu'une bibliothèque, certes standard, mais qui n'est nullement nécessaire au langage proprement dit. Hélas, pour la plupart, un bon développeur C++ est nécessairement quelqu'un qui connait et utilise la STL.

Le langage C++ n'est pour moi qu'un outil ; je n'en utilise que ce dont j'ai besoin, et de la manière qui me convient le mieux. Du moment que le code que je fourni est techniquement équivalent voire souvent supérieur à ce qui est généralement produit par ailleurs, je ne vois pas ce que l'on pourrait trouver, d'un point de vue technique, à y redire.

Il y a d'ailleurs souvent confusion entre un langage, ses bibliothèques et la technologie associée, ces trois éléments étant souvent considérés comme indissociables. Pourtant, me concernant, je développe pour Java, mais sans faire de Java. En d'autres termes, je développe des composants Java, c'est-à-dire destinés à être mis en œuvre dans la JVM, mais en code natif, c'est-à-dire codés en un autre langage que Java. C'est une approche techniquement viable, et présentant des avantages par rapport au développement Java 'traditionnel', dans la mesure ou de tels composants en code natif procèdent de la même démarche et ne se distinguent en rien de ceux fournis en standard avec le JDK et mis en œuvre dans le JRE.

Bref, il existe un nombre important de préjugés concernant le développement, préjugés malheureusement partagés par la plupart des recruteurs, qui conduisent ces derniers à rejeter des profils utilisant des méthodes de développements originales, innovantes et performantes, et ce absolument sans aucune justification technique.

[Peacecraft95]

J'ai passé un entretien d'embauche il y a 15 jours pour une "grosse" boite spécialisée Internet/mobile etc etc.

Les questions n'étaient aucunement techniques mais académique à mort :"Que veux dire XML, que veut dire HTML".

Je fais du web professionnellement parlant depuis 7 ans maintenant (ASP,PHP, VB.NET avc diverses DB) et je trouve qu'en entretien ce genre de question n'a pas lieu d'être, surtout quand on annonce "Vous travaillerez sur un projet qui a couté jusqu'à présent 500 millions d'euros".

La seule question "technique" ça a été "Pouvez vous me faire une requête SQL qui me donne tous les clients dont le prénom contient 'Jean' ?"... je l'ai regardé bizarrement car à ce moment, j'ai cru qu'il me faisait une blague !

Bref, demander des définitions à un candidat pendant 30 minutes au lieu d'avoir un entretien approfondi pour montrer ma valeur m'a donné l'impression de perdre mon temps.

Autre chose que je trouve dommage chez ce recruteur, c'est qu'on me dit "Si vous n'avez pas de réponse, envoyez moi un mail dans 10 jours".

2 relances plus tard (11 jours et 15 jours), toujours pas de nouvelles, pas très pro comme attitude je trouve.

[Nathanael Marchand]

La seule question "technique" ça a été "Pouvez vous me faire une requête SQL qui me donne tous les clients dont le prénom contient 'Jean' ?"... je l'ai regardé bizarrement car à ce moment, j'ai cru qu'il me faisait une blague !

Bah tu sauras qu'il y a plus de candidats que tu ne le penses qui ne sauront pas le faire ou le feront de manière erronée... Même une requête bateau comme ca!

[alex_vino]

Bah tu sauras qu'il y a plus de candidats que tu ne le penses qui ne sauront pas le faire ou le feront de manière erronée... Même une requête bateau comme ca!

C'est gros quand meme
En meme temps les recruteurs ou les RH qui font passer les entretiens croivent etre des cadors alors qu'ils ne connaissent bien souvent pas grand chose. Par exemple lors d'un de mes entretiens j'explique brievement l'un de mes derniers projets sur lequel j'ai passé plusieurs années. Le recruteur me dit que c'est impossible a réaliser ce que je lui raconte... pas facile d'argumenter avec des gens comme ca...

Mais aujourd'hui on peux tout de meme travailler sur de gros projets complexes en base de données sans meme écrire une seule ligne de SQL ou le comprendre, exemples: Entity Framework et NHibernate en .Net.

[Nathanael Marchand]

C'est gros quand meme

Et pourtant... L'informatique étant un secteur qui recrute toujours, y a quand même un max de gens qui ont fait une école par hasard (par désespoir?) ou qui sont là pour être développeur 6mois et chef après (du coup ca sert a rien de connaitre la technique pour 6 mois hein)...

[FR119492]

Bonjour à tous.
Pour résoudre un problème par l'informatique, il y a toujours trois étapes:

1. Bien comprendre le problème posé.
2. Choisir les algorithmes pour le résoudre.
3. Programmer ces algorithmes.

Dans les forums que je fréquente régulièrement, je constate que, très fréquemment, les lacunes se trouvent dans la première étape: beaucoup de nos membres ne savent pas poser un problème, dire quelles sont les données, quelle est la solution, à quelles conditions celle-ci est soumise. Je pense qu'autant la formation que la sélection des candidats devrait se concentrer sur la première étape, et accessoirement sur la deuxième étape. Les compétences et les lacunes éventuelles au sujet des outils de programmation n'ont que très peu d'importance: quand on a pratiqué 23 langages, l'apprentissage du 24^ème n'est l'affaire que de quelques jours.
Jean-Marc Blanc

[Nathanael Marchand]

Bonjour à tous.
Pour résoudre un problème par l'informatique, il y a toujours trois étapes:

1. Bien comprendre le problème posé.
2. Choisir les algorithmes pour le résoudre.
3. Programmer ces algorithmes.

Dans les forums que je fréquente régulièrement, je constate que, très fréquemment, les lacunes se trouvent dans la première étape: beaucoup de nos membres ne savent pas poser un problème, dire quelles sont les données, quelle est la solution, à quelles conditions celle-ci est soumise. Je pense qu'autant la formation que la sélection des candidats devrait se concentrer sur la première étape, et accessoirement sur la deuxième étape. Les compétences et les lacunes éventuelles au sujet des outils de programmation n'ont que très peu d'importance: quand on a pratiqué 23 langages, l'apprentissage du 24^ème n'est l'affaire que de quelques jours.
Jean-Marc Blanc

Je partage ton analyse à quelques points près! Certains languages se basent sur des paradigmes différents c'est pas toujours "si simple" même si effectivement ca n'est qu'une affaire de jours. Toutefois, tout dépend du contexte: pour un "client final" embaucher un bon mais qui ne connait pas forcément le language utilisé dans la boîte est tout à fait pertinent. Pour une SSII, ca ne l'est pas toujours. Faut que la SSII accepte l'investissement de la formation et qu'elle arrive à placer la personne par la suite. L'équation n'est plus si simple.

Et puis tout dépend du candidat, si il arrive avec 3 ans d'xp sur C# je peux lui poser question un peu tordue sur C# en m'attendant à ce qu'il sache y répondre puisqu'ici je cherche également à connaitre l'étendu de sa connaissance sur ladite techno (pourqu'une fois recruté on puisse plus ou moins le former). Si le gars n'a jamais fait de C# alors oui l'entretien sera totalement sur sa capacité d'adaptation, de reflexion et sa culture technique.

Dernier point, apprendre 24 languages ca peut être chouette, mais déjà que certains ont du mal à en maitriser un...

Le recrutement, c'est pas tous les jours des stars malheureusement... Comme dans la réalité de tous les jours: c'est quelques stars, beaucoup de moyens et quelques uns franchement mauvais.

Pour ceux qui disent qu'ils ne connaissent pas les termes sur les concepts, mettez vous à la place des recruteurs aussi. Imaginez un recruteur qui vous dit "Donnez moi un exemple d'addition" et que vous répondez "Ah désolé je ne sais pas ce qu'est une addition". Même si vous en faites tous les jours, c'est assez dur côté recruteur d'évaluer ce cas là.

[FR119492]

Dernier point, apprendre 24 languages ca peut être chouette, mais déjà que certains ont du mal à en maitriser un...

Effectivement, mes 51 ans de programmation me donnent une vision un peu particulière du problème ...
Jean-Marc Blanc

[transgohan]

Pour ceux qui disent qu'ils ne connaissent pas les termes sur les concepts, mettez vous à la place des recruteurs aussi. Imaginez un recruteur qui vous dit "Donnez moi un exemple d'addition" et que vous répondez "Ah désolé je ne sais pas ce qu'est une addition". Même si vous en faites tous les jours, c'est assez dur côté recruteur d'évaluer ce cas là.

J'ai passé un entretien où le recruteur a su réagir très rapidement pour déterminer si je ne connaissais pas ou non ce qu'il voulait savoir. Vu que le nom ne m'inspirait rien il m'a sorti plus loin un bout de code mettant en application ce concept en me demandant les avantages et inconvénients. C'est un très bon moyen de voir si la personne connait ou non et ce malgré un trou de mémoire du nom.

[erwanlb]

Bah tu sauras qu'il y a plus de candidats que tu ne le penses qui ne sauront pas le faire ou le feront de manière erronée... Même une requête bateau comme ca!

En même temps sur le terrain ça s'apprend en quelques secondes...si c'est un besoin "périphérique", beaucoup ne prendront pas la peine de retenir comment on fait...surtout en ce qui concerne SQL