J'ai un entretien d'embauche demain pour un poste où la connaissance de PERL fait partie du cahier des charges.
Malheureusement je ne connais rien à PERL pour l'instant, à part quelques généralités trouvées sur Google.
L'entretien a lieu avec le chef des ressources humaines qui ne connaît pas grand chose, le poste en cause étant le seul poste d'informaticien de la boîte.
Puis-je avoir quelques grosses ficelles que je peux lui asséner pour le convaincre que je maîtrise bien PERL. Il va sûrement me sonder de manière basique en se référant à des notions élémentaires.
Pour la moralité de la cause, je précise que si je suis engagé, je me mettrais à PERL (j'assure avec ADA), ce que je n'ai pas envie de faire pour un simple entretien d'embauche.
Malheureusement je ne connais rien à PERL Puis-je avoir quelques grosses ficelles que je peux lui asséner pour le convaincre que je maîtrise bien PERL.
Et au Directeur Informatique tu vas lui raconter quoi ?
François wrote: > Et au Directeur Informatique tu vas lui raconter quoi ?
C'est un entretien d'embauche pour le *seul poste d'informaticien* de la boîte. Ils sont pressés car celui qui occupait le poste est décédé la semaine dernière dans un accident de la route.
Ainsi parla Andre FAGO le jeudi 18 mar 2004 vers 10:03 à propos de « Re: APPEL A L'AIDE » :
> François wrote:
> > Et au Directeur Informatique tu vas lui raconter quoi ?
> C'est un entretien d'embauche pour le *seul poste d'informaticien* de > la boîte.
Et sur quels critères pourrait bien te juger le directeur ? Je serais, pour ma part, incapable de juger un comptable (par exemple), sauf en le testant avec des questions style « hmmm, et que pensez vous de la méthode de Staunzen dans l'application du quota à part pleines non égales ? » ;)
> Ils sont pressés car celui qui occupait le poste est décédé > la semaine dernière dans un accident de la route.
OK, donc par respect tu devrais laisser ta place à des gens plus compétents. La boite est déjà bien fragilisée si tout son service info viens de se faire décapiter, pas la peine d'en rajouter. Tu risques de couler la boite avec tes conneries (non, perl ne s'apprend pas « comme ça »).
-- Nicolas Rueff · Montbéliard · France · http://rueff.homelinux.org (^> nico...@rueff.homelinux.org · GPG 0xDD44DAB4 /v\ Jabber ru...@jabber.org · ICQ 97700474 <__/ « We are Penguin. Resistance is futile. You will be assimilated. »
Nicolas Rueff wrote: > Ainsi parla Andre FAGO le jeudi 18 mar 2004 vers 10:03 à propos de « Re: > APPEL A L'AIDE » :
>>François wrote:
>>>Et au Directeur Informatique tu vas lui raconter quoi ?
>>C'est un entretien d'embauche pour le *seul poste d'informaticien* de >>la boîte.
> Et sur quels critères pourrait bien te juger le directeur ? Je serais, > pour ma part, incapable de juger un comptable (par exemple), sauf en le > testant avec des questions style « hmmm, et que pensez vous de la > méthode de Staunzen dans l'application du quota à part pleines non > égales ? » ;)
>>Ils sont pressés car celui qui occupait le poste est décédé >>la semaine dernière dans un accident de la route.
> OK, donc par respect tu devrais laisser ta place à des gens plus > compétents. La boite est déjà bien fragilisée si tout son service info > viens de se faire décapiter, pas la peine d'en rajouter. Tu risques de > couler la boite avec tes conneries (non, perl ne s'apprend pas « comme > ça »).
Tu as le droit de pas connaitre Perl, de vouloir l'apprendre, mais là il faut lacher le mot : t'es malhonnête.
C'est préjudiciable pour la boite donc les gens qui y bossent.
> J'ai un entretien d'embauche demain pour un poste où la connaissance de > PERL fait partie du cahier des charges.
> Malheureusement je ne connais rien à PERL pour l'instant, à part > quelques généralités trouvées sur Google.
> L'entretien a lieu avec le chef des ressources humaines qui ne connaît > pas grand chose, le poste en cause étant le seul poste d'informaticien > de la boîte.
> Puis-je avoir quelques grosses ficelles que je peux lui asséner pour le > convaincre que je maîtrise bien PERL. Il va sûrement me sonder de > manière basique en se référant à des notions élémentaires.
> Pour la moralité de la cause, je précise que si je suis engagé, je me > mettrais à PERL (j'assure avec ADA), ce que je n'ai pas envie de faire > pour un simple entretien d'embauche.
J'espere pour vous que André FAGO n'est pas votre vrai nom. Je connais plein de gens qui font des recherches sur google groups avant de recevoir des informaticiens en entretien d'embauche.
On 2004-03-18, Andre FAGO <fagox...@ephemail.net> wrote:
> Puis-je avoir quelques grosses ficelles que je peux lui asséner pour le > convaincre que je maîtrise bien PERL. Il va sûrement me sonder de > manière basique en se référant à des notions élémentaires.
> J'ai un entretien d'embauche demain pour un poste où la connaissance de > PERL fait partie du cahier des charges.
> Malheureusement je ne connais rien à PERL pour l'instant, à part > quelques généralités trouvées sur Google.
> L'entretien a lieu avec le chef des ressources humaines qui ne connaît > pas grand chose, le poste en cause étant le seul poste d'informaticien > de la boîte.
> Puis-je avoir quelques grosses ficelles que je peux lui asséner pour le > convaincre que je maîtrise bien PERL. Il va sûrement me sonder de > manière basique en se référant à des notions élémentaires.
> Pour la moralité de la cause, je précise que si je suis engagé, je me > mettrais à PERL (j'assure avec ADA), ce que je n'ai pas envie de faire > pour un simple entretien d'embauche.
'lut c'est a double trachant ton truc une petite histoire a titre d'exemple soit une certaine boite ... dont son informaticien pour X raison est parti ... le Dit informaticien laisse un papier avec les competences requise pour le poste au hasard : Win9x , Linux, Shell, NFS, Perl, Samba , Proxy Squid Le DRH ( ou celui qui en fait office ) ecoute les postulant.
Soit un postulant : qui arrive, dans les 10 20 min qui lui sont imparties ... il raconte que Linux il a travaille dessus win 95 n'a aucun secret ...
Resultat : ca fait maintenant 3 mois que j'ai quitter cette boite ca fait 3mois - 1 semaine que le reseau ne fonctionne plus ... l'acces internet n'existe plus .. les machine Linux ne tourne plus
J'ai passer + d'une heure a telephone avec mon remplacant ... pour constater qu'il n'y connaissait rien a Unix
Je pense que tu a tout interet a potasser un peu ce que tu a pu recuperer sur le Web ( y a pas de formule magique ) tu fait un coup de P2P pour choper des bouquins sur Perl
et tu lis ...
Sinon le risque c'est d'etre completment largue au bout de quelque jour au mieux quelque mois
"Andre FAGO" <fagox...@ephemail.net> writes: > J'ai un entretien d'embauche demain pour un poste où la connaissance de > PERL fait partie du cahier des charges.
> Malheureusement je ne connais rien à PERL pour l'instant, à part > quelques généralités trouvées sur Google.
> L'entretien a lieu avec le chef des ressources humaines qui ne connaît > pas grand chose, le poste en cause étant le seul poste d'informaticien > de la boîte.
> Puis-je avoir quelques grosses ficelles que je peux lui asséner pour le > convaincre que je maîtrise bien PERL. Il va sûrement me sonder de > manière basique en se référant à des notions élémentaires.
> Pour la moralité de la cause, je précise que si je suis engagé, je me > mettrais à PERL (j'assure avec ADA), ce que je n'ai pas envie de faire > pour un simple entretien d'embauche.
Si en quelques heures, tu n'es pas capable d'apprendre suffisamment d'un langage pour « blouser » un gars qui ni connait rien en informatique, ton cas est désespéré.
En plus d'être malhonnête mais cela n'a même pas l'air de t'effleurer l'esprit.
Andre FAGO wrote: > Puis-je avoir quelques grosses ficelles que je peux lui asséner pour le > convaincre que je maîtrise bien PERL. Il va sûrement me sonder de > manière basique en se référant à des notions élémentaires.
Ca ne marchera que s'il n'y connait rien. Si je devais tester que quelqu'un a quelques notions de base de Perl (sans même qu'il soit question de bien le maîtriser), je lui dirais : "Voici un fichier contenant un texte ASCII, écrivez-moi le programme qui fait le hit-parade des mots utilisés". Qu'il y ait dedans quelques petites erreurs qu'on rectifierait à la premire compil ou au debugging n'est pas bien grave. Ce qui compterait, c'est qu'il sache quoi faire sans hésitation et écrive son affaire en trois minutes environ.
Et des candidats sachant faire ça sans problème, sois sans crainte, il y en aura.
>> Puis-je avoir quelques grosses ficelles que je peux lui asséner pour le >> convaincre que je maîtrise bien PERL. Il va sûrement me sonder de >> manière basique en se référant à des notions élémentaires.
> Ca ne marchera que s'il n'y connait rien. Si je devais tester que > quelqu'un a quelques notions de base de Perl (sans même qu'il soit > question de bien le maîtriser), je lui dirais : "Voici un fichier > contenant un texte ASCII, écrivez-moi le programme qui fait le > hit-parade des mots utilisés". Qu'il y ait dedans quelques petites > erreurs qu'on rectifierait à la premire compil ou au debugging n'est pas > bien grave. Ce qui compterait, c'est qu'il sache quoi faire sans > hésitation et écrive son affaire en trois minutes environ.
Pour rassurer les lecteurs qui se sentiraient nuls à la lecture de ce poste, je me permet d'ajouter qu'on peut aussi s'en sortir même si on ne sait pas faire un programme « en trois minutes » et « sans hésitation ». Personellement je suis incapable de réaliser le moindre bout de code en moins d'une heure. D'ailleurs, je me demande même si quelqu'un qui se met à coder « sans hésitation » est digne de confiance pour des projets d'envergure.
Enfin, j'ajouterais qu'on donne souvent trop d'importance aux langages et aux outils lors des embauches. Les langages ne sont pas très importants, ils ne sont que l'expression d'une pensée. Ce qui est important c'est de savoir capter un besoin, spécifier une interface et concevoir une architecture. Ce sont des compétences transversalles qui demandent une réelle expérience, bien plus précieuse à mes yeux que la simple expertise dans tel ou tel langage de programmation.
> > Enfin, j'ajouterais qu'on donne souvent trop d'importance aux langages <snip>
> Ce sont des compétences transversalles qui > demandent une réelle expérience, bien plus précieuse à mes yeux que la > simple expertise dans tel ou tel langage de programmation. >
Entièrement d'accord si ce n'est que pour le poste dont on parle ici, ils cherchent le *seul* informaticien de la boîte (déploiement rapide de petite solutions, maintenance/admin). Je pense q'un "Mac Gyver" sera plus performant qu'un AS de l'UML. D'ailleur ils cherchent quelqu'un qui connaisse Perl ;)
> Enfin, j'ajouterais qu'on donne souvent trop d'importance aux langages > et aux outils lors des embauches. Les langages ne sont pas très > importants, ils ne sont que l'expression d'une pensée.
Encore faut il avoir une pensée qui peut être adaptée à ces langages et ne pas avoir sa pensée perdue à chaque instate dans la recherche du manuel. Les entreprises préfèrent embaucher quelqu'un qu'elles n'ont pas à former sur les rudiments.
On 2004-03-26, olivier.dugas <olivier.du...@free.fr> wrote:
> Entièrement d'accord si ce n'est que pour le poste dont on parle ici, > ils cherchent le *seul* informaticien de la boîte (déploiement rapide de > petite solutions, maintenance/admin). Je pense q'un "Mac Gyver" sera > plus performant qu'un AS de l'UML.
Justement, ce qui fait la qualité de Mac Gyver, ce n'est pas de connaitre parfaitement tel ou tel modèle de perceuse, mais c'est d'avoir une bonne aptitude à analyser des problèmes et à y trouver des solutions avec ce dont il dispose.
Quant à UML, vous charriez ;) Il est évident qu'on a pas, dans toutes les situations, besoin d'un tel formalisme pour réfléchir un minimum avant de faire quelque chose, notamment aux aspects de modularité et de maintenabilité, lesquels doivent être pris en compte même si on fait du sh.
On 2004-03-26, Laurent Wacrenier <lwa@teaser> wrote:
> Alex Marandon <al@ENLEVER_CECIalpage.org> écrit: >> Enfin, j'ajouterais qu'on donne souvent trop d'importance aux langages >> et aux outils lors des embauches. Les langages ne sont pas très >> importants, ils ne sont que l'expression d'une pensée.
> Encore faut il avoir une pensée qui peut être adaptée à ces langages
Assujetissement du codeur au langage ? Tiens donc. Je préfère l'inverse.
> et ne pas avoir sa pensée perdue à chaque instate dans la recherche du > manuel.
Les manuels sont vastes, mais de là à y perdre sa pensée tout de même...
> Les entreprises préfèrent embaucher quelqu'un qu'elles n'ont > pas à former sur les rudiments.
>> Encore faut il avoir une pensée qui peut être adaptée à ces langages
> Assujetissement du codeur au langage ? Tiens donc. Je préfère l'inverse.
C'est vous qui sortez "assujetissement". Des idées, certains en ont plusieures d'excellentes par jour (pensez à certains chefs ou certains commerciaux). Mais rien de programmable en réalité.
>> et ne pas avoir sa pensée perdue à chaque instate dans la recherche du >> manuel.
> Les manuels sont vastes, mais de là à y perdre sa pensée tout de même...
Et bien, c'est que soit vous n'êtes pas un débutant, soit vous l'êtes et vous ne lisez pas le manuel.
>> Les entreprises préfèrent embaucher quelqu'un qu'elles n'ont >> pas à former sur les rudiments.
> Perl ? Les rudiments ? Ah, bon.
J'ai peut être l'air de vous apprendre quelque chose, mais la maîtrise d'un langage de programmation est l'une des bases du métier de developpeur.
Laurent Wacrenier wrote: > J'ai peut être l'air de vous apprendre quelque chose, mais la maîtrise > d'un langage de programmation est l'une des bases du métier de > developpeur.
D'autant qu'on vu passer quelques statistiques intéressantes dans la presse concernant le nombre d'erreurs par milliers de ligne de code en fonction des langages utilisés : la corrélation la plus significative ne se trouve pas comme on aurait pu le croire entre proportion d'erreurs et langage utilisé (tant pis pour les flame wars :o))) ), mais entre proportion d'erreurs et /nombre/ de langages pratiqués (ceux qui n'en pratiquent qu'un, au bout d'un moment de pratique, font trois à quatre fois moins d'erreurs que les autres; et ce n'est pas des erreurs de syntaxe que l'on parle : il existe bien une interférence - nocive - des langages entre eux, dans l'esprit).
Les articles n'en parlent guère, mais plus les langages qu'on pratique se ressemblent, plus doivent augmenter le risque d'erreurs par confusion momentanée (surtout après 21h, je suppose). Mieux vaut sans doute faire une croix sur le C quand on se met à travailler en Perl (ainsi que sur le C shell): il s'agit carrrément d'un autre métier, avec un autre langage (même si on a vu un programme particulier amusant faire la même chose qu'il soit fourni à une chaîne C ou Perl!) et d'autres techniques de debugging sans rapport. C'est d'ailleurs dommage, de renoncer au C, mais l'efficacité de pensée est sans doute à ce prix.
>>"Voici un fichier >>contenant un texte ASCII, écrivez-moi le programme qui fait le >>hit-parade des mots utilisés". Qu'il y ait dedans quelques petites >>erreurs qu'on rectifierait à la premire compil ou au debugging n'est pas >>bien grave. Ce qui compterait, c'est qu'il sache quoi faire sans >>hésitation et écrive son affaire en trois minutes environ.
> Pour rassurer les lecteurs qui se sentiraient nuls à la lecture de ce > poste, je me permet d'ajouter qu'on peut aussi s'en sortir > même si on ne sait pas faire un programme « en trois minutes » et « sans > hésitation ».
Oui, mais la minute de programmeur coûte un euro. Et comme les petits ruisseux font les grandes rivières :o(
Précisons tout de même que ce genre de programme et l'une des premières choses que fait quiconque a appris Perl en /jouant/ avec (ce qui est la meilleure façon de l'apprendre; "les chats attrapent bien les souris parce qu'ils ont eu le meilleur des professeurs: la souris" (Ashby)). Pourquoi ? Parce que grâce aux hashs, ce n'est pas plus compliqué à écrire qu'un tri pr bulles en FORTRAN. Et même plutôt moins.
> Personellement je suis incapable de réaliser le moindre > bout de code en moins d'une heure.
Pas de fausse modestie. "Lisez des noms au clavier jusqu'à ce qu'on vous renvoie une chaîne vide, et imprimez-les alors par ordre alphabétique", je doute tout de même /fortement/ qu'il te faille une heure ;o)
> D'ailleurs, je me demande même si > quelqu'un qui se met à coder « sans hésitation » est digne de confiance > pour des projets d'envergure.
On cherche ici un programmeur Perl de base, capable de coder des petites choses vite et bien (et donc pas cher). Il n'y a de véritable projet que lorsqu'il y a une équipe à encadrer, ou si on est soi-même encadré dans une équipe. Là encore, ce serait un autre métier.
N'oublions pas que le "top-down", ça paie uniquement sur les domaines déjà archiconnus (une paie, une compta, une petite CAO, un petit traitement de texte ou tableur) que l'on sait déjà décomposer avant même de commencer à travailler. Dans les réalisations vraiment nouvelles, on est obligé de faire au contraire du "bottom-up" pour bâtir sur le concret plutôt que sur le marécageux (source: Gerald Chandler, Caltech).
> Enfin, j'ajouterais qu'on donne souvent trop d'importance aux langages > et aux outils lors des embauches. Les langages ne sont pas très > importants, ils ne sont que l'expression d'une pensée.
Il y a là du vrai (les langages algorithmiques se ressemblent) et du faux : on ne peut utiliser pour les langages fonctionnels les modes de pensée adaptés aux langages algorithmiques, on ne peut utiliser pour le transactionnel les modes de pensée du batch, la conception d'un programme orienté GUI ne peut utiliser les habitudes de programmation adaptés aux programmes séquentiels.
> Ce qui est > important c'est de savoir capter un besoin, spécifier une interface et > concevoir une architecture. Ce sont des compétences transversalles qui > demandent une réelle expérience, bien plus précieuse à mes yeux que la > simple expertise dans tel ou tel langage de programmation.
Là encore, c'est très gentil, mais /il s'agit d'un autre métier/. Un architecte n'est pas un maçon, et là où on a besoin d'un maçon, l'architecte est très exactement d'utilité nulle, quelle que soit par ailleurs la beauté de son métier. Si l'architecte essaie de prétendre avoir des compétences de maçon et que sa productivité n'est pas à la hauteur dans ce type de job, c'est la porte. Exactement comme un ingénieur qui essaierait de se faire embaucher à faire de la saisie: son succès n'y est pas assuré.
