Discussion :

[L'Aigle]

Bonjour,

Je suis étudiant en Master 2 Infomatique, et je recherche actuellement un stage pour une mission en Java (J2EE ou Android) qui est le langage avec lequel je suis le plus à l'aise et que j'apprécie le plus.

Je voudrais avoir votre avis sur mon CV que j'ai réalisé après avoir lu le guide de Cécile Quiquempoix (en post-it) ainsi que les nombreux conseils et exemples présents sur ce forum.

N'ayant pas d'expérience ou de projets J2EE à mettre en avant, ne sera t'il pas difficile trouver un stage qui utilise ces technologies?
J'ai commencé a m'auto-former, je connais les notions de Servlet ou de JSP, mais pas plus.

Je vous remercie d'avance pour votre aide et le temps que vous allez m'accordez.

[Glutinus]

Salut,

Sur la forme ton CV est vraiment nickel, rien à redire.

Sinon effectivement si tu n'as pas fait de projet en Java c'est un moins, mais tu seras à peine derrière un autre. Si tu recherches un stage, n'oublie pas de le préciser dans le titre.

Tu n'as pas fait de projet personnel en Java ?

[MarieKisSlaJoue]

Salut, un lien vers un dépôt avec des petit projet scolaire en Java pourrai peut être d'aider à te vendre. Un dépôt ou tu as tester le TDD, le swing, le FX ou des patern particulier peut être non ?

Sinon en effet sur la forme rien à redire ton CV est très agréable. une seul partie quand même m'a fait un peu ouvrir les yeux.
Anglais niveau moyen

C'est totalement subjectif, mais je pense que d'autre serons du même avis. Niveau moyen c'est pas très parlant, dit comme ça c'est même dévalorisant. Si tu connais ton niveau TOIC ou européen tu peux le mettre. Sinon tu peux d'inspirer de site comme linkedin ou viadeo.
Eux mette :
- Notion
- capacité professionnel limité
- capacité professionnel
- capacité professionnel complète
- bilingue

ou bien si tu préfère
- Débutant
- Intermédiaire
- Avancé
- Bilingue

voila c’était vraiment histoire de pinaillé mais au moins tu auras eu une critique.

[Carhiboux]

Cv très clair, super aéré, concis.

Bravo, un modèle du genre sur la présentation!

Pour J2EE, à partir du moment où tu as fait du dev sur android, j'ai presque envie de dire que ne pas avoir fait de J2EE pur n'est pas vraiment un handicap!

Et puis, J2EE, c'est tellement vaste que finalement, tu as pu en voir un petit bout et avoir à travailler sur tout autre chose. Chaque boite, parfois chaque projet, à sa manière d'architecturer les choses. Donc no panic.

Mets en avant tes devs android, cela devrait plus que compenser.


Instant pinaillage : pour moi, BDD != de persistance des données. Persistance de données, je pense plus à Hibernate ou TopLink qu'à Oracle ou MySQL qui sont les BDD en dessous. Enfin là je pinaille vraiment.

[Uncharted]

pareil que les autres
le petit + en entretien c'est de ramener son travail de faire la demo
avec revue de code

[Carhiboux]

le petit + en entretien c'est de ramener son travail de faire la demo
avec revue de code

Perso, je ne l'ai jamais fait. Et j'ai toujours à peu près eu les postes que je voulais.

Et il faut bien cibler le public avec qui le faire.

Si c'est un entretien RH ou avec un manager non technique, sortir du code, c'est la meilleure façon de se planter. Parce qu'ils vont se concentrer sur tout sauf le code (puisqu'ils ne le comprennent pas).

Si c'est clairement estampillé comme entretien technique, pourquoi pas. Encore que, je trouve que c'est presque donner des bâtons pour se faire battre pour peu qu'il manque de la doc, que les classes ne soient pas bien factorisées, que ça ne respecte pas les bonnes pratiques (ou en tout cas celle de l'entreprise...), que tu n'a pas bien respecté le pattern MVC (ou équivalent) si il y a une UI, etc...

Mais ce n'est que mon avis.

[L'Aigle]

Merci à tous pour vos avis éclairés!

Pour le niveau d'anglais, j'ai remplacé "moyen" par "capacité professionnelle".
Et j'ai également replacé "Persistance" par "SGBD".

Si tu recherches un stage, n'oublie pas de le préciser dans le titre.

Sinon pour le titre vous me conseillez quoi? "Stage développeur Java" conviendrait?

Enfin, je comptais l'envoyer par mail a plusieurs SSII de la ville où je souhaite aller, est-ce une bonne pratique?

[Carhiboux]

Salut, dans le titre, il faut que tu précise la nature du stage, genre "stagiaire M2 développeur java" ou quelque chose de ce gout là.

[yildiz-online]

...Si c'est clairement estampillé comme entretien technique, pourquoi pas. Encore que, je trouve que c'est presque donner des bâtons pour se faire battre pour peu qu'il manque de la doc, que les classes ne soient pas bien factorisées, que ça ne respecte pas les bonnes pratiques (ou en tout cas celle de l'entreprise...), que tu n'a pas bien respecté le pattern MVC (ou équivalent) si il y a une UI, etc...

C'est justement tout l'intérêt de la chose, si quelqu'un pouvait produire des logiciels parfaits, ça se saurait.
Dans ce cas, c'est une opportunité pour échanger, se remettre en question sur ses choix, mais également éprouver sa capacité à défendre ces choix, et de mesurer si les personnes en face sont également ouvertes d'esprit.

Face à une critique, il est avant tout important de pouvoir justifier un aspect du logiciel qui peut sembler mauvais: "ok la gui est pourrie mais avant la beta j'ai considéré le fonctionnel comme étant prioritaire",

et surtout ne pas se chercher des excuses : "je l'ai fait en 15 min sur un coin de table, imaginez ce que je sortirais en bossant 1h"(ça ressort souvent sur le forum JV ça)

[Carhiboux]

Je pourrais trouver encore beaucoup de critique à faire à une telle approche :

* Pourquoi est-ce que tu n'as pas fini le travail sur l'UI?

* Pourquoi tu penses que le fonctionnel est plus important que l'UI? Moi je pense que l'UI est plus important que le fonctionnel. (***DEBUT TROLL INSIDE***) Regarde iOS, windows et linux. (***FIN TROLL INSIDE***)

* Est-ce que tu n'as pas fait une plus belle UI parce que tu es limité en compétences ou que tu es ignorant de l'état de l'art des UI?


Bref, je reste sur ma position qui est que présenter un code en entretien, à moins que ce soit expressément demandé, ce n'est pas une bonne idée. Cela donne beaucoup d'angle d'attaque aux recruteurs, et il faut être sacrément solide pour justifier ses choix. Et pour un peu que vous ayez fait un choix qui soit contraire aux convenances personnelles du recruteur, ça peut vite être carton rouge.

Surtout, que, encore une fois, rien ne prouve que le code que vous présentez est bien le votre... ce qui ne devrait pas manquer d'interroger le recruteur.

Mieux vaut faire passer un test technique, sur papier, sur machine ou sur tableau.

[yildiz-online]

Je pourrais trouver encore beaucoup de critique à faire à une telle approche :

* Pourquoi est-ce que tu n'as pas fini le travail sur l'UI?

Comme dit précédemment, priorité basse, c'est important de savoir gérer les priorités non?

* Pourquoi tu penses que le fonctionnel est plus important que l'UI? Moi je pense que l'UI est plus important que le fonctionnel. (***DEBUT TROLL INSIDE***) Regarde iOS, windows et linux. (***FIN TROLL INSIDE***)

Parce que les priorités sont relative à un projet, si un recruteur essaie de généraliser ce genre de chose, mieux vaut aller voir ailleurs.

* Est-ce que tu n'as pas fait une plus belle UI parce que tu es limité en compétences ou que tu es ignorant de l'état de l'art des UI?

L'interface utilisateur et l'expérience utilisateur sont un boulot à part entière, y a pas de quoi rougir de ne pas maitriser le sujet, sinon c'est plus le mouton à 5 pattes qu'il faut, ça tourne autour du myriapode.

Bref, je reste sur ma position qui est que présenter un code en entretien, à moins que ce soit expressément demandé, ce n'est pas une bonne idée. Cela donne beaucoup d'angle d'attaque aux recruteurs, et il faut être sacrément solide pour justifier ses choix. Et pour un peu que vous ayez fait un choix qui soit contraire aux convenances personnelles du recruteur, ça peut vite être carton rouge.

Si on a des codes perso, j'ose espérer que les choix autour ont été fait en connaissance de cause, et si on s'est planté, c'est justement une bonne occasion d'écouter les conseils d'en face pour corriger le tir sur un sujet qu'on ne maîtrise pas.
Par contre si le recruteur campe sur ses positions alors qu'on sait qu'il a tort, c'est bien d'en être conscient pour savoir à quoi s'en tenir pour continuer ou non.

C'est de cette manière que j'ai été engagé sur ma position actuelle(et qui s'était également révélée positive sur 3/4 des autres entretiens que je passais)

Surtout, que, encore une fois, rien ne prouve que le code que vous présentez est bien le votre... ce qui ne devrait pas manquer d'interroger le recruteur.

Mieux vaut faire passer un test technique, sur papier, sur machine ou sur tableau.

L'un n'empêche pas l'autre.