Bonjour,
 
Ma boite compte recruter un DBA junior Oracle/SQL Server.
Après une mauvaise expérience de recrutement, des tests techniques sont prévus pour filtrer les mythos.
 
Je recherche des pistes pour constituer un jeu de tests pour trouver un bon problem-solver.
 
Je pense à des choses comme un minimum de SQL ISO, des problèmes de logiques, du debugging.
Auriez-vous des idées la dessus ?
 
Merci de vos suggestions !
 
 

ca aurait été de l'Oracle ptet que j'aurais pu t'aider =)
mais bon on va faire abstraction, voici quelques idées en vrac :
 
- alterner questions difficiles et faciles, une personne qui n'a pas de sang-froid butera sur les questions faciles après une question difficile => genre de profil à éviter en Production
- poser des questions autour de tes projets futurs et actuels, histoire de voir comment il imagine les choses, ca peut apporter des idées et une vision différente
- poser des questions sur la culture technique, un mec qui connait les principes d'un datawarehouse, de clustering, de réplication de bases... c'est qqun de débrouillard qui saura s'adapter rapidement aux nouveaux environnements, alors qu'une personne fermée sur le fonctionnement de la base ne proposera jamais rien de concret
- après les questions pures techniques, j'y connais pas grand chose en SQL server, mais je pense qu'un minimum sur le vocabulaire et le fonctionnement de la base pourrait faire effet genre :
> comment fonctionne les logs dans une base ?
> que gagne-t-on à faire des shrink de base ? que perd-on ?
> que feriez-vous si le DBA actuel meurt dans un accident avec le moty de passe du user "sa" ?

et de tte manière, je n'ai qu'une chose à dire : Oracle c'est mieux

je suis pas pro en SQL Server mais en vrac;
- securite ?
- comment remonter une sauvegarde?
- comment ameliorer la disponibilite d'une bdd (et la on enchaine sur la gestion de la replication)
- Connaissance des outils de surveillance?
- Strategies de migration ?
- Une ou deux requetes sympa a optimiser

Il y a de l'Oracle si vous relisez bien.

maintenant qu'on sait qu'il y a de l'Oracle, plus personne n'a d'idées
 
moi j'en ai qques unes :
- différence entre un pfile et spfile
- qu'est ce qu'un archive log
- qu'est ce que le cache buffer hit ratio
- qu'apporte les tablespace gérés localement

Ok, c'est pas mal pour les questions admins.
Il y aura également pas mal de développements à réaliser sur les DB.
 
En fait, je recherche un gars capable de s'adapter à de nouvelles technos sans forcément être un DBA senior.
Je pensais plus à des trucs comme des petits tests pour évaluer son sang-froid (deja des suggestions), sa rigueur, sa méthode, son sens du service, son esprit d'initiative, son rédactionnel, etc ; plutôt que de voir s'il a bien appris sa leçon avant de venir à l'entretien.

Sinon tu peux m'engager, comme ca pas besoin de questions LOL :-)

C'est un topic sérieux

Tiens, en ce moment on n'arrête pas de me contacter pour savoir si je suis dispo.
Il y a d'ailleurs un gus qui voudrait me voir et me faire passer des tests.
Parmi ceux-là, il y a un test sur la modélisation. Je sens que je vais le repomper pour mes besoins...

/me ne voit pas trop ce que viennent faire les mots "développement" et "rédactionnel" dans le poste de DBA
 
pour le reste, je trouve que les questions sont pour des profiles de DBA sur gros système. perso, jamais vu de réplication, quand bien même je bosse pour un ERP (donc système chargé et absolument critique)
 
nan, par contre, simplement prendre un serveur de prod, ghoster le disque avec les tablespace, shooter quelques tablespace, et mettre ça sur un serveur "neuf" avec juste Oracle installé, et lui dire "t'as 30 minutes pour faire démarrer la base dans l'état qu'elle étant avant le crash du disque système", là ouais, t'es sûr que t'as un mec qui va faire l'affaire.
au tout du moins, il sera capable de te dépanner quand t'aura une vraie merde...
ps: c'est un cas qui est arrivé à ma boîte, pour une grosse société il y a peu : raid du disque système qui est parti en live. obligés de réinstaller en catastrophe sur un serveur de test, avec restauration des tablespace de prod et redo des logs. quand le client a vu sortir les bons de prépa pour les camions qui s'impatientaient devant le dépôt, le client nous a facilement pardonné ensuite de perdre quelques heures à trouver la petite bidouille qui permet de gagner 30% de vitesse.

Pour un junior, ça inclut aussi qqn qui sort de l'école.
 
Sans doute pas trop la peine de l'interroger sur spmon, pfile ou redo log.
 

En tant que débutant sous oracle, je dirais que la gestion des utilisateurs/roles/profils est assez peu évidente à comprendre aux premiers abords.
Il y a peut être deux trois questions intéressantes à pondre sur le sujet.
 
Le fait de poser des questions pas forcèment adaptée au niveau 'junior' permet de distinguer ceux qui ont au moins des notions même si la réponse ne sera pas exacte.
 
Je doute qu'un junior connaisse 100% des réponses qui ont été posées ici. Ou alors il n'est plus vraiment junior .
Ce sera donc plus facile de faire un tri si il n'y a pas que des réponses adaptées au niveau du poste.

AMHA, je vous trouve tous fort sévères, dans l'ensemble. Encore une fois, pour un impétrant diplômé, je doute que le socle de connaissances spécifiques soit suffisant. Tout au plus le jeune padawan aura potassé et fait joujou, ce qui peut montrer son intérêt pour le job, mais ce n'est pas un critère déterminant.
 
Je préfère opter pour un jeune ayant (relativement à son âge) de très fortes connaissances DB générales et/ou avec un DBMS particulier, même s'il ne s'agit pas d'Oracle, plutôt que celui qui a un peu potassé ORA mais sur des bases plus faibles.
 
On engage un junior pour investir en lui. Il ne doit donc pas être complètement opérationnel. Sinon, ce n'est plus vraiment un junior.
 
Ne tombez pas dans le travers "junior avec expérience équivalente à 5 ans pour salaire de base" en tapant des critères trop hauts.
 
Bien entendu, si vous parlez d'un junior avec 3 ans d'expérience dans le domaine, les choses seront différentes, mais on ne parle plus tout à fait d'un junior...
 
     

moi pour mon embauche, si on m'avais posé des questions oracle j'aurais jamais pu répondre je savais tout juste ce qu'était un tablespace

sircam > Par rapport à l'objectif de pains-aux-raisins, j'ai plutôt en tête un test typé concours avec des questions 'pas que facile' et/ou des questions trop nombreuses pour que le temps imparti ne permette de toute y répondre.
 
Le but c'est quand même d'arriver à distinguer un candidat et pas d'avoir un test où la moyenne est de 10/20.
 
Me tromperais-je ?

Disons que ce ne sera pas forcément un expert en réplication ou en tuning. Il devra gérer les aspects techniques de nos bases de données mais pas uniquement.
Il nous faut un gars capable de s'exprimer correctement et savoir communiquer avec des DBA experts et des fonctionnels pour proposer et mettre en oeuvre par la suite des améliorations et des évolutions.
Un pur techos ne nous intéresse pas.

T'a pigé l'esprit du problème
edit : On recherche plus un potentiel qu'un expert.

Poser trop de questions, bof. Si c'est pour tester les capacités de resistance au stress ou la réaction face à l'inconnu et les capacités de raisonnement, pq pas essayer, à l'oral, une question du style "Combien y a-t-il de stations essence à Bruxelles?" Ou plus vache, contredire le candidat alors qu'il a parfaitement répondu. J'aime aussi cuisiner sur un sujet au choix, là où le candidat est supposé être le plus à l'aise et où il devra se montrer à son avantage, sans être bridé. Tu en tireras sans doute plus d'enseignement qu'une réponse blanche à la question "kesako pmon?".
 
Alterner questions faciles et plus difficiles, c'est bien. Mais qu'est-ce qu'une question facile ?
 
Ce qu'il faut, c'est rester pertinent. Un questionnaire trop facile ne permet pas de bien filtrer. Un trop difficile ne permet pas de conclure. Des questions toutes du même type (uniquement QCM, uniquement ouvertes, uniquement de détails, ...) ne mènent à rien.
 
Mais en aucun cas je ne passerais trop de temps sur Oracle avec un junior à l'embauche. S'il est déjà calé en DB2 alors qu'il sort de l'école, ça veut dire que le potentiel est là et tu peux raisonnablement présumer qu'il atteindra rapidement un niveau équivalent en ORA.
 
Ce qui t'interesse avec le jeune padawan, c'est de t'assurer qu'il maîtrisera la Force et ne passera pas du côté obscur.
 
Il doit être encore un peu naïf, ayant la foi en la technologie, mais pas arrogant. Le junior qui me dit que J2EE, c'est super génial, c'est bien. S'il a 5 ans d'expérience, je vais approfondir.
 
Contrairement à un senior, où tu sais qu'un gars avec 10 ans d'expérience Oracle ne fera pas l'affaire en J2EE et vice-versa.
 
Un candidat, ça se teste comme une voiture : voir là où il est à l'aise, là où il ne l'est pas, et s'assurer que ça convient à ton style de conduite. Ou plutôt à celui de ton entreprise.

 
Il doit y avoir méprise, je n'ai mentionné nulle part qu'il faudrait passer du temps sur Oracle.  Ou tout de moins ce n'était pas le but de mon intervention si cela a été perçu comme tel.  
 
Sinon je partage également ton avis. Je pense mêem qu'il n'y a pas une seule manière de faire, mais plutôt notre propre manière de tester le candidat agrémentée des idées piquées ça et là  

Merci pour les idées
Ca m'a permis de voir plus précisémment ce que je souhaite de ce que je ne souhaite pas.
 
Un petit retour sur des tests que je viens de passer pour un éventuel poste dont je ne suis pas sûr du tout de bien vouloir
Mais en tout cas, ça m'a permis de voir la technique de recrutement d'une SSII (nom en MP selon mon humeur).
Ca consistait en trois parties

• Rédactionnel : Rédiger une page word sur un de ses hobbies (thème un peu libre)
• Algorithmique : Pondre un algo de tri d'un tableau à 10 entrées dans un langage se nommant TL, très limité en puissance expressive.
• Modélisation : Modéliser une école (sans plus de précision...)

C'était plutôt instructif et ça a du sens. Je pense que ça permet de juger pas trop mal des capacités globales du candidat.
L'inconvénient c'est que ça mobilise minimum 2h30 le candidat.
Qu'en pensez-vous ?

 
Et s'il n'a pas d'hobbies ?    
 
De toute façon ça devient une pratique courante dans les SSII : tu te déplaces pour la journée entière, tu passes 4 étapes, et à la fin on te refile 24k€ ... là tu dis non, et t'as perdu ta journée (alors que si on t'avais dit direct 24k€ au départ, tu te serais vite barer sans perdre ta journée...mais après avoir fait le parcours du combattant, difficile de dire non )