Bonjour,  
 
On me demande de faire passer un entretien a un mec qui veut rentrer dans ma boite.
Ils veulent tester son niveau technique en JAVA J2EE.
Quelles questions techniques sur java poseriez vous ?
En même temps je saurais si je sais y répondre!
Merci

Tu sors les questions classiques sur encapsulation et polymorphisme (pour voir si c'est pas un goyo).
 
Ensuite des trucs sur la gestion des Error/Event.
 
La mode en ce moment c'est de parler de Tiger : generics, autoboxing, concurrency ...
 
Pour le J2EE : j'y connais rien donc je te laisse trouver.
 
Amuse toi bien !

ouh la la...c du chinois ca pour moi alors que je vais faire un master un peu info ("reconversion" )

 
fais le en chine alors

Sur ca ok, principe de Java classique
 

       
Je fais du Java depuis un moment et je connais pas tout ca!!!
 
Je dirai pour J2EE : EJB, Struts, et les logiciels type Eclipse, et serveur : Weblogic, Websphere &co...
 
Regarde sur google (define:Java puis define:J2EE) tu devrai trouver ton bonheur!

Ca c'est salaud de poser des questions sur les EJB, j'aimerais pas qu'on me les pose! c'est la qu'il me dit "je sais pas mais j'aimerais bien que vous me donniez la reponse" ....

je viens de passer des tests JAVA completement débiles dans une boite (Horizon Software pour ne pas la citer)
 
je postulais pour un poste d'ingé sécurité réseau, le gars a absolument insisté pour que je passe le test java (j'ai bien précisé que ça faisait bien 1 an que je n'avais pas fait une ligne de java, et encore en projets scolaires ..)
 
bref au début questions faciles sur l'héritage, ensuite ça se corse, ils me demandent les différences entre des treeset, map, et compagnie (y en avait 4/5 et de tete ...)
ensuite le gars attaque sur des questions sur les interfaces graphiques, me demandant des méthodes pour faire telle chose, des questions sur les Container ...
 
enfin plus simple, des questions sur les sockets, entrées sorties, thread, et gestion d'erreurs ..
voila pour mon feedback perso ...  
 
petite précision, ils ne m'ont pas recontacté

moi je vais pas faire le salaud, je vais pas poser des questions vaches, parce que meme si tu connais bien java , il est jamais facile d'expliquer certaines choses .... surtout avec le stress d'un entretien...

 
Un test dur n'est pas forcément débile  
A noté que des Ingé réseaux tatent en Java et c'est toujours bon à savoir.

Ils ont rien à tater en Java, les ingés réseaux proprement dits  ... la seule chose qu'ils doivent connaitre, tout au plus, c'est comment installer et bien configurer un environnment runtime Java complet, parce que certains de leurs outils sont écrits en Java mais à part ça ... ... Si ça va au delà de ça, le type dérive gentiment ves du système voire de la maintenance/développement de soft ...
 
Maintenant, si tu parles d'un développeur pour des équipements réseaux, ça change un peu ...
 
Seulement, quand on te colle une étiquette d'informaticien, on te fourre tout et n'importe quoi sur le dos, et ça arrive fréquemment dans les services/boites mal organisés/structurés ...

 
Dans le cadre d'un entretient et j'en sais quelque chose, connaitre le potentiel de quelqu'un en terme de développement peut être intéressant.
En l'occurence dans le cadre de cette entreprisepetite SSII de la finance ou la mobilité est très importante, il est bon de savoir si tel ou tel personnes peut avoir des aptitudes en terme de développement.
 
C'était le cas ici

C'est comme ça qu'on voit se construire des usines à gaz bancales, parce qu'on a pas toujours mis des gens qui comprenaient et maitrisaient un minimum les technos qu'ils devaient employer ...
 
Quand tu passes derrière, "faire le pompier", c'est toujours la joie ...
 

 
  aucun rapport

 
Je dirais en gros :
 
_ c'est quoi la finalité programmatique des EJB ? (les adapter de l'extérieur à l'environnement sans toucher au code interne rien qu'en jouant sur les fichiers de déploiement)
 
_ combien il existent d'EJB différents, à quoi ils servent ? (Session Stateless, Session Stateful, Entity, MDB)
 
_ de quoi on a besoin pour produire un EJB ? (Home, Interface Remote/Locale, le Bean lui même)
 
_ différence de comportement entre exception système et applicative ? (système le Bean dégage, applicative le Bean gère l'erreur)
 
_ pourquoi il y a "ejbCreate()" et "ejbPostCreate()" dans un Entity Bean, et à quoi servent ils ?
 
_ combien y a t'il d'attributs transactionnels et quel est leur rôle ? (6 : Required, RequiresNew, Mandatory, Supports, NotSupported,  Never)
 
_ pourquoi un MDB ne lance pas d'exception applicative ? (un MDB n'a pas de vue cliente, il ne sait pas qui l'appelle donc à qui remonter l'erreur)
 
_ utilité des interfaces Remote et Locale ? (Remote = appel lent en réseau, Locale = appel rapide en JVM)
 
_ inconvénient des interfaces Locale et qu'est ce qu'on utilise pour y pallier ? (Locale => pas Remote    donc on ne peut pas l'appeler à distance en réseau, génial pour une application Internet, donc on utilise un Data Object)
 
_ c'est quoi un Value Object ? (un Data Object en lecture seule, donc que des getter mais aucun setter)
 
_ c'est quoi essentiellement les améliorations des EJB-3 par rapport à la version d'avant ? (plus de Home ou d'Interface Remote/Locale, déduit par introspection ou méta-définitions)
 
Voili voilou, t'as plus qu'à piocher. C'est plus ou moins évident comme niveaux de questions/réponses mais je pense que le type qui sait répondre à ça a une bonne vue d'ensemble sur la question.
 
Tu peux utiliser des ressources pratiques pour avoir une vue d'ensemble vite fait genre :
 
"Développons en Java" : http://perso.wanadoo.fr/jm.doudoux [...] frames.htm
"Les meilleurs cours et tutoriels Java" : http://java.developpez.com/cours/#ejb

 
Je ne veux casser personne ou être irrespectueux, mais connaitre le potentiel de quelqu'un en terme de développement s'il n'est pas développeur n'est pas "peut être intéressant", c'est complètement débile.
 
Les OS, le réseau, et le développement, sont trois métiers complètement différents qui nécessitent de vraies compétences, pas un potentiel. Je suis bien placé pour le savoir car j'ai pratiqué les 3. Il est vrai que tout les informaticiens ont des compétences plus ou moins poussées en OS, tous se débrouillent plus ou moins car tous en ont besoin pour utiliser un ordinateur, au moins utilisateur éclairé sinon carrément administrateur. Par contre les types formés au développement ne connaissent rien de sérieux au réseau, et de même les types formés au réseau ne connaissent rien de sérieux au développement, car ces métiers sont trop différents et ils n'ont aucun besoin de connaître l'autre pour pratiquer le leur.
 
Si vous avez des doutes, demandez à un développeur quelle est la différence technique entre un switch et un hub, que traite le switch, que traite le routeur, est ce qu'un routeur est un appareil spécial ou est ce qu'un simple PC peut le remplacer, quelle est la définition d'un routeur.
De même en face pour un type du réseau ce que sont encapsulation, polymorphisme, héritage, interface, patterns, etc...
Vous verrez bien que les types ne sauront pas répondre, pas parce qu'ils ne sont pas compétents, ils sont parfaitement compétents mais dans leur métier pour lequel ils ont été formés.
 
Alors que je connaissais Linux et le développement depuis 10 ans, moi qui croyais me débrouiller correctement en réseau parce que je savais établir un firewall ou un serveur DNS ou DHCP, mes collègues réseau se foutaient de ma tronche en affirmant que j'étais une vraie bille en réseau. A un moment j'ai vraiment du m'y former, j'ai constaté qu'ils avaient raison, j'étais bien une vraie bille en réseau. Ca m'a pris 6 mois pour assimiler les bases, et c'était rapide paraît il.

Je connais les tests Ils permettent de jauger du niveau en Java dans une entreprise qui fait du Java, pour un poste ou on embauche ce genre de profil pour faire de l'administration chez le client de solutions clients serveurs complete en Java...
 
Excuse moi, mais s'il connait rien en Java, tu m'expliques comment il comprend un fichier de .log ?!
 
Non mais pardon quoi...

Tu lui demandes :
 
- les méthodes de dév qu'il connaît (Cycle en V d'UML, RUP, MERISE, etc...).
 
- les outils de dév qu'il connaît (Eclipse, JBuilder, ect...).
 
- les APIs qu'il connaît (EJB, JDBC, SWING, etc...)
 
- et les projets sur lesquels il a bossé.

 
Et un test pour situer les gens dans tels ou tels domaines, même si c pas leur spécialité C'est toujours utile pour batir des étalons

faire un petit test d'implementation quand meme, parce que connaitre rup par coeur c'est beau, mais si apres le mec est pas capable de pondre plus de 50 lignes par jour, c'est bof