A force de faire des billets sur le sujet, certaines personnes vont se poser des questions. 😉

Yakov Fain a écrit un article intitulé Interviewing Enterprise Java Developers dans lequel il traite les points importants sur l’entretien d’embauche pour des profils orientés Java.

D’après l’auteur, en général on ne se dit pas développeur Java mais plutôt architecte Java. Or très peu de personne peuvent prétendre à ce statut.

Les certifications n’assurent pas une plus-value conséquente sur un CV. Mises trop en avant, elles peuvent même traduire une faible expérience.

Il y a quelques années les EJB avaient le vent en poupe. Aujourd’hui c’est Struts. Pour se démarquer de la concurrence, il faut connaitre et comprendre ce qui ce passe dans ce genre de framework ainsi que dans les servlets ou le HTML. Car la plupart des développeurs Struts ne savent qu’utiliser ces frameworks.

De la même façon il faut comprendre comment fonctionne JDBC[1].

Il semble que des architectes Java souhaitent devenir chef de projet !? Maitriser la technique n’a rien à voir avec l’art de gérer un planning. 😉

Ensuite il donne une liste de gros mots qui doivent être présents sur un CV. Facile à mettre, mais encore faut-il réellement les utiliser. Et surtout, il faut savoir répondre à la question suivante : Pourquoi les avez-vous utilisé dans ce projet ? Et surtout ne jamais répondre : La décision avait été prise avant que j’arrive sur le projet. Il est préférable d’avoir une opinion même si elle est contraire au choix fait pour le projet.

L’auteur est contre les exercices du type tri d’un arbre binaire ou construction d’un automate d’état fini lors d’un entretien d’embauche. Ce genre d’implémentation peut être vu ou remémoré à l’occasion (grâce à internet ou à un livre)[2].

Dernier point important pour les personnes en poste : il faut maitriser le vocabulaire du métier pour lequel on travail ! Ceci ajoute de la crédibilité à la personne et montre son réel intérêt pour ses utilisateurs.

Notes

[1] J’ajouterai qu’il faut savoir utiliser de façon optimale cette API. Ce qui n’est malheureusement pas toujours le cas… :-/

[2] Ceci est vrai également pour les langages. Mince cette remarque va à l’encontre du précédent billet. 🙁