+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
  1. #21
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    24 941
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 24 941
    Points : 47 686
    Points
    47 686

    Par défaut

    Citation Envoyé par bihetq Voir le message
    On peut faire de la veille techno et utiliser internet ou de la doc quand on dev, je ne vois pas le rapport... Je suis développeur et je fait énormément de veille techno, et pourtant pour certaines choses je préfère garder la doc ouverte à côté de moi...

    Pourrais-tu expliquer plus précisément le lien entre les 2 points car je t'avoue que je ne le vois absolument pas....
    Heu je crois justement que son message allait dans ton sens. Il est presque impossible de reprendre des vieux trucs qui ont évolués sans avoir un minimum d'accès à la doc. Seule les techno morte et qui ne bougent plus depuis 20 ans peuvent être maitrisées par coeur, pour le reste le tableau blanc est de la blague.
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

  2. #22
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    24 941
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 24 941
    Points : 47 686
    Points
    47 686

    Par défaut

    Citation Envoyé par ultimatemanu Voir le message
    Pour ma part j'ai vécu un recrutement de rêve il y a qqs années: les mecs m'ont donné une clef USB avec tout l'environment de dev + la doc dessus et m'ont dit: vas-y, tu prends une semaine pour développer un truc, ce que tu veux, et tu nous le présente.
    Bilan: cela va faire 10 ans que je travaille avec eux. D'abord en tant que salarié, et depuis quelques années comme un de leur prestataire. Que du bonheur!
    Il y avait déjà un sujet sur ce genre de recrutement. C'est bien si c'est bien maitrisé: a savoir donner un temps au candidat ET le rémunérer pour ce temps. Sinon tu va passer en tant que recruteur à coté de candidats compétent qui ne peuvent se permettre de consacrer 10 à 20h à un seul recrutement. Quand tu cherche du boulot parce que t'as plus le tiens, entre perdre 10h à bosser sur un projet demo, ou passer 5 interview, mon choix est vite fait, je maximise mes chances d'avoir une offre.
    Le projet demo gratuit ne va te permettre que de viser deux types de candidats à mon avis:
    • Celui qui a déjà un boulot, n'as pas de contraintes familiales, et veut juste viser ta boite
    • L'étudiant qui a le temps entre son TFE fini à l'avance et la remise des diplômes.

    En l'occurence, ici, tu as été engagé. Quel aurait été ton ressentit par rapport au processus de recrutement si après tout cet investissement on t'aurais laché "désolé, on a pris quelqu'un d'autre qui a fait un super projet sur lequel il a passé 50h" ?
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

  3. #23
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    143
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 143
    Points : 344
    Points
    344

    Par défaut

    Je pensais peut être naïvement que tout le monde allait chercher ses "snippets" sur le net pour les adapter dans son propre code mais puisque que cela fait un sujet pourquoi pas approfondir. Les recruteurs sont effectivement à côté de la plaque car ils ne posent pas les bonne questions et n'évaluent en aucun cas les qualités requises pour le développement. Les compétences techniques sont déjà obsolètes une fois que l'on arrive sur le marché du travail donc ce n'est pas la dessus q'u'il faut évaluer les candidats. Je vois bien des candidats dans 10 ans devant un recruteur, "moi j'ai fait 10 ans d'Angular", la belle jambe les frameworks ont tous ont changé depuis ... Ce que je regrette c'est qu'on ne cherche pas à savoir si le candidat sera capable de travailler au sein d'une équipe et pas de bosser en mode hermite, de communiquer ses idées même après d'un public non technique (chef de projet), de former d'autres collègue, d’élaborer des spécifications techniques pour les soumettre à un architecte, de penser plus large que son domaine de prédilection pour trouver des solutions cadrant avec l'environnement et le besoin du client et surtout s'il sera capable de se remettre en question d'apprendre de nouvelles technos sur le tas ...

  4. #24
    Membre expérimenté Avatar de CodeurPlusPlus
    Profil pro
    Inscrit en
    septembre 2013
    Messages
    528
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 528
    Points : 1 703
    Points
    1 703

    Par défaut

    Citation Envoyé par Jitou Voir le message
    (...) Les compétences techniques sont déjà obsolètes une fois que l'on arrive sur le marché du travail (...)
    Ah bon ?


    (...) surtout s'il sera capable de se remettre en question d'apprendre de nouvelles technos sur le tas ...
    Du coup, pour quoi faire ? Si tout devient si vite obsolète...

  5. #25
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 819
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 819
    Points : 4 038
    Points
    4 038

    Par défaut

    Le tableau blanc oui. Mais pas pour écrire du code !

    Y a pas si longtemps que ça (tout juste un an), j'ai fait les entretiens techniques pour une place (d'analyste-programmeur/dba/testeur/tout le reste) chez nous (en interne dans un chaîne de magasins de distribution).

    Mon approche était la suivante : Reproduire une situation réelle de demande interne. Bien souvent, le chef d'un service vient nous voir en disant "j'ai besoin d'un soft pour faire ci et ça". Et c'est à nous de lui tirer les vers du nez pour découvrir ce qu'il veut réellement faire et ce dont il a besoin.

    Conclusion, j'ai fait "un jeu de rôle" (c'est à la mode en plus ^^) avec les candidats. Ils jouaient le prestataire et moi le client.

    Comme situation, j'ai pris l'exemple de gestion d'un cabinet vétérinaire car cela ne nécessite pas, selon moi, d'avoir des connaissances spécifique au métier pour identifier les besoins de bases. Surtout que de toute façon, c'était à eux de me poser les questions. Moi j'avais un peu préparé mon sujet. L'objectif en 30 min (1h max), avoir un ébauche de schéma de DB ou de diagramme de classe (au final, c'est pareil).

    L'objectif n'étant bien sûr pas de déterminer si le candidat connait la syntaxe de toutes les fonctions du framework utilisé par coeur mais de déterminer s'il est capable de raisonner correctement pour extraire les informations importantes de mes réponses.

    Le tableau n'intervient donc ici comme médium de communication plus pratique que si le candidat écrivait sur un papier et que je doive regarder par dessus son épaule...
    Kropernic

  6. #26
    Membre régulier
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mai 2016
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 42
    Points : 115
    Points
    115

    Par défaut

    Tout dépend pour quel type de poste on recrute et quelle facultés on souhaite mettre en évidence par ces tests. Ne pas être capable d'écrire un algorithme de tri n'est pas rédhibitoire pour un technicien. Par contre, un ingénieur R&D qui n'est pas capable de résoudre tout seul un problème aussi simple, en raisonnant un peu, n'a probablement pas les aptitudes pour attaquer des problèmes plus complexes, et a un niveau réel de technicien.
    Ca ne veut pas dire que je n'embaucherais pas cette personne, qui peut avoir d'autres qualités intéressantes, mais j'éviterais de lui confier des problèmes trop complexes, pour lesquels il n'y a pas nécessairement de solution standard disponible sur Internet.
    Je ne me souviens pas combien font 9*8, je ne sais pas le retrouver en réfléchissant, mais attendez, avec une connection Internet, et en travaillant en équipe, je vais
    vous trouver la solution.
    Par contre, qu'un responsable ayant 30 ans d'expérience ait besoin de chercher comment obtenir la longueur d'une chaine Python ne me choque pas spécialement : il s'agit ici de mémoire d'un détail technique, associé à une technologie particulière, c'est une petite lacune facile à combler, contrairement aux difficultés à raisonner.

  7. #27
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2016
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2016
    Messages : 16
    Points : 29
    Points
    29

    Par défaut

    Combien d'entretiens j'ai annulé de peur à cause de ça... Je trouve cette façon de tester tellement stupide ... En tous cas, merci à ces gens de conforter mon avis sur la question

  8. #28
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    24 941
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 24 941
    Points : 47 686
    Points
    47 686

    Par défaut

    Citation Envoyé par wolinn Voir le message
    Tout dépend pour quel type de poste on recrute et quelle facultés on souhaite mettre en évidence par ces tests. Ne pas être capable d'écrire un algorithme de tri n'est pas rédhibitoire pour un technicien. Par contre, un ingénieur R&D qui n'est pas capable de résoudre tout seul un problème aussi simple, en raisonnant un peu, n'a probablement pas les aptitudes pour attaquer des problèmes plus complexes, et a un niveau réel de technicien.
    Alors d'abord pour résoudre un problème avancé, je préfère le gars qui va d'abord fouiller la littérature pour savoir si une solution existe à son problème qui est robuste et à déjà été testée ailleurs. Pour prendre un exemple, je pense pouvoir dire que pour mon travail de fin d'étude, j'en ai chié pour inventer des techniques innovantes pour résoudre le problème. Et pourtant j'ai bien passé 60% de mon temps à me documenter sur des algorithmes éprouvé et des mathématique dont je n'ai plus jamais eu à utiliser par la suite. Je devrais faire ça aujourd'hui devant un tableau blanc, j'en serais incapable car certaines briques fondamentales font appel à des formules mathématiques dont je ne me souviens plus exactement, et dont l'exactitude est importante pour garantir le reste de l'algo puisqu'il se base sur des propriétés démontrées de ces formules.


    La première fois où on m'a demandé d'implémenter un quicksort, je me suis basé sur la description de l'algo plutot que sa connaissance, et j'ai fait travailler mes méninges. Résultat, mon algo était performant, mais c'était pas un quicksort. C'était un heapsort au final, je ne l'ai su que plus tard. Au tableau blanc, j'aurais échoué, c'était pas un quicksort.

    Ensuite, pour le tableau blanc, on demande pas du pseudo code pour ce que j'ai compris, mais de pondre un bout de code de a à z sans doc. Quand je réponds aux questions sur ce forum sur comment faire x ou y, je n'utilise pas de compilateur, juste la box code de developpez. Et, "surprise", j'ai toujours besoin à chaque fois de charger la javadoc dans un onglet parce que rien à faire, je ne connait pas par coeur toutes les méthodes et l'ordre de leur paramètres en java. Je sais où elles sont, je sais ce qu'elles font, dans quelles contraintes, mais je laisse à l'IDE le boulot de gérer la forme. Au tableau blanc, je serais un homme mort.

    Enfin, une fois dans ma vie, j'ai du écrire un bout de code en C sur un tableau, avec un feutre. Après trois lignes, mon prof de l'époque fronçait les sourcils. J'ai fait trois pas en arrière, j'ai vu le n'importe quoi. Entre la manière dont je réfléchissait, le temps pour écrire proprement et le fait de ne pas voir plus 10 lettres à la fois, ça partait en couille. J'ai demandé à pouvoir l'écrire au stylo sur du papier plutôt qu'au tableau. Le tableau était blanc.

    Bref, j'échouerais lamentablement sur un tableau blanc. Et pourtant je suis bon en analyse, en architecture et en technique. Mais je suis à chier en gestion de projet et je pense avoir une phobie des tableaux blancs... Au moins, pour le premier point, je suis sûr que ça peut se travailler.
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

  9. #29
    Membre régulier
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mai 2016
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 42
    Points : 115
    Points
    115

    Par défaut

    Je ne vois pas non plus l'intérêt d'écrire du code C détaillé au tableau.
    Et ma remarque faisait référence à un des exemple donné dans l'article, cette personne incapable d'écrire un tri à bulle, même pas un quicksort. Je n'ai pas l'impression que ce soit un problème particulièrement avancé.
    On s'attend normalement à ce qu'un développeur sache :
    - que cette méthode est inefficace, et rarement utilisée
    - mais qu'il soit quand même capable de l'écrire en 10 mn sans faire des heures de recherches bibliographiques, pour trier une douzaine de valeurs dans un environnement/langage sans fonction de tri
    Après, si on a besoin de quelque chose de plus élaboré, pour trier beaucoup de valeurs, évidemment qu'on va chercher du code ailleurs.

    Il y a quelques années, je posais le problème suivant : écrire une librairie de calcul en précision arbitraire sur des entiers, implémentant les 4 opérations de base, en mettant à disposition de la personne un ordinateur, du papier, un tableau, et 2h pour travailler tranquillement, sans être dérangé, tout seul dans une salle.
    Le but n'était pas de tester la capacité de la personne à travailler en équipe, ni de vérifier que c'est un virtuose de google, mais d'évaluer sa méthode de travail autonome et capacités de raisonnement, sur un problème de nécessitant pas plus de connaissances en mathématiques que ce que connait un élève de CM2.
    Il y a plus de 20 ans, je ne faisais pas passer de tests, juste entretien d'embauche, en comptant sur la période d'essai, j'y suis venu après avoir embauché quelques candidats pas incompétents de façon évidente, mais peu efficaces au travail.
    Et encore une fois, tout dépend pour quel type de poste on recrute, et ce qu'on cherche à vérifier, je ne prétend pas que les tests techniques soient la panacée pour sélectionner des candidats dans toute situation.

  10. #30
    Membre actif
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 112
    Points : 229
    Points
    229

    Par défaut

    Hmmm, ce n'est pas un défaut des recruteurs mais plutôt un problème de vérification des connaissances.

    Beaucoup voir énormément de candidats bidonnent leurs CV. D'un langage qu'ils connaissent à peine, ils vont se prétendre "Expert", se rajouter des expériences professionnelles, s'approprié des programmes qu'ils n'ont pas écrit. Face à ça, le recruteur ne peut pas vérifier chaque cas surtout si le CV ne donne pas assez de références externes. Le seul moyen est de mettre le candidat dans une situation extrême et de juger non pas forcement le résultat mais la méthode et l'attitude.

    Aujourd'hui, même dans les écoles, on n'apprend que très peu de choses comparé à une dizaine d'années. Les notions d'algorithmiques sont mises de coté pour se concentrer sur des choses plus futiles mais plus "vendeuses". Le programmeur qui ne sait pas retrouver l'algo d'un bubble-sort ne devrait même pas se prétendre informaticien. Je suis incapable de le faire de mémoire mais je sais comment retrouver cet algo et c'est bien là l'essentiel. J'aurai réinventé la roue lors de l'entretien (ce qui n'arriverait pas en situation réelle sur un poste) mais j'aurai démontré que j'ai une méthodologie pour avancer et appréhender le problème et trouver une solution.

  11. #31
    Membre régulier
    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 42
    Points : 110
    Points
    110

    Par défaut Le dinosaure se marre !

    Ce type d'entretien est normalement la marque d'une grande incompétence de la part de ceux qui le font passer. Il revient à un QCM : Pas besoin de réfléchir au contenu, pourvu que les bonnes cases soient cochées.
    Cette manière de faire est en contradiction totale avec ce qui m'a amené à l'informatique (analyse, conception, programmation, installation, maintenance, sans parler de la partie matérielle ni du réseau...) il y a fort, fort longtemps. Et c'est bien dommage. Depuis des décennies "on" essaie d'industrialiser le processus de création d'applications. Mais la contradiction est inhérente à l'expression : Une application est "créée", elle n'est pas usinée. Ou si on l'usine, on obtiendra un produit industriel, adapté au plus grand nombre pour 80% de ses fonctions. Ca peut suffire pour une comptabilité, qui est la même en gros pour tout le monde. Mais ensuite, industrialiser des applications métier ne fait aucun sens et aboutit au contraire à stériliser un domaine.
    Bref ! Je préfère infiniment quelqu'un capable d'expliquer ses choix de développement, de me montrer ce qu'il utilise et comment il l'utilise pour écrire son code, comment il organise son poste de travail, à quel rythme il avance et d'où il tire ses ressources de référence qu'un petit robot bien calibré capable de me dégoiser le Knuth par coeur. Vous ne savez pas ce qu'est le Knuth ? Tant mieux !
    Vous voulez vraiment tester ce que quelqu'un peut faire ? Donnez-lui un bout d'application à maintenir, un truc qu'il n'aura pas encore vu. Et voyez comment il s'y prend et comment il évolue. En quatre heures, vous saurez si oui ou non, et ce sera de la vraie connaissance.
    Quant au péché... J'ai dû produire pas mal de code COBOL, partie en maintenance, partie de neuf. J'ai dû écrire pas loin d'un million de lignes, plutôt plus (si, si, je vous jure, ça va vite et j'ai duré longtemps). Je suis toujours incapable de démarrer un programme COBOL de rien, j'ai absolument besoin d'un patron syntaxique. Et ça ne m'a jamais, mais alors jamais posé le moindre problème !
    Donc, vu d'un oeil de dinosaure, ne vous cassez pas la tête avec le tableau blanc. Si quelqu'un vous y colle, tournez les talons, vous trouverez sans doute une boîte plus intéressante pas loin dans le coin.

  12. #32
    Membre à l'essai
    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    octobre 2014
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Enseignant Chercheur

    Informations forums :
    Inscription : octobre 2014
    Messages : 8
    Points : 17
    Points
    17

    Par défaut

    Bonjour

    Je n'ai jamais eu à faire ce genre de tests mais j'en suis curieux.

    Si j'ai bien compris, on demande au candidat de développer quelque chose ou résoudre des problèmes "à la main levée" sans autre ressource que ce dont il se souvient.

    C'est bien ça ?

    Je trouve que c'est un exercice intéressant dans la mesure où cela oblige à faire avec ce que l'on a en tête, ça permet de prendre confiance.

    Quant à en faire un examen au cours d'un entretien d'embauche ... j'avais déjà entendu parler de cette pratique, c'était pour le concours de l'Ecole Normale Supérieure.
    Lors de l'épreuve orale pour cette école, un candidat s'était retrouvé en face d'un tableau presque vide avec juste un circuit électrique dessiné dessus, très simple en apparence,
    avec l'injonction de dire tout ce qu'il savait dessus.

    Je fais du travail de développement depuis plusieurs années dans le monde scientifique en C++/fortran/python/swig/Ocaml/lua, je code très rarement à partir de rien et m'inspire
    souvent de bout de codes trouvés sur internet. Je crois que si je passais ce genre d'entretien, je passerais pour un gros imposteur, j'aurais même je pense quelques difficultés
    à expliquer les notions et algorithmes que je récupère car bien souvent, je ne cherche pas à tout comprendre, le plus important est d'en bien saisir les entrées et sorties.

    Si je devais faire passer des entretiens d'embauche, je chercherais à m'assurer que la personne est rapidement capable de retrouver ce qu'il lui faut dans de la doc ou sur internet,
    l'essentiel étant de ne pas s'enliser dans la pagaille de toutes les solutions possibles. Je regarderais aussi ses précédentes réalisations. Je garderais le type d'entretien "tableau blanc"
    comme un exercice pour éviter de devenir trop dépendant de la documentation.

  13. #33
    Membre habitué

    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2005
    Messages
    98
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : octobre 2005
    Messages : 98
    Points : 172
    Points
    172
    Billets dans le blog
    1

    Par défaut

    Jarodd
    quoi de plus a ajouter drrrrrr tu as raison

  14. #34
    Membre expérimenté
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 322
    Points : 1 341
    Points
    1 341

    Par défaut

    Si un recruteur demande à un candidat d'écrire un algorithme de tri simple de son choix, sans forcément savoir comment s'appelle cet algorithme, mais que ce dernier n'y parvient pas, alors je comprends que le recruteur craint que le candidat ait un niveau algorithmique trop faible pour travailler dans sa boîte.
    Par contre, si un recruteur demande à un candidat de coder un tri à bulles mais que ce dernier ne se rappelle plus à quel algorithme cela correspond, je pense que ce serait injuste de pénaliser le candidat. Après tout, le tri à bulles n'est pas le seul algorithme de tri trivial à complexité quadratique. Il y a aussi le tri par insertion et le tri par sélection. A quoi bon se rappeler lequel correspond à quoi alors que, dans 99,99% des cas, on va seulement appeler une fonction standard qui fait un tri avec une complexité en O(n log n) ?

    Citation Envoyé par tchize_ Voir le message
    La première fois où on m'a demandé d'implémenter un quicksort, je me suis basé sur la description de l'algo plutot que sa connaissance, et j'ai fait travailler mes méninges. Résultat, mon algo était performant, mais c'était pas un quicksort. C'était un heapsort au final, je ne l'ai su que plus tard.
    Heu... es-tu sûr que c'était un heapsort ? Je vois mal comment on peut se retrouver à implémenter un heapsort à partir d'une description, même vague, du quicksort.

    Description simplifiée du tri rapide (quicksort) : On choisit un élément comme pivot. Puis on s'arrange pour que tous les éléments à gauche du pivot soient inférieurs ou égaux au pivot et que tous les éléments à droite du pivot soient supérieurs ou égaux au pivot. Le pivot coupe alors le tableau en deux sous-tableaux. On applique l'opération de manière récursive à chacun de ces sous-tableaux.

    Description simplifiée du tri par tas (heapsort) : On voit le tableau comme un arbre binaire. Le premier élément est le sommet, les 2 suivants sont les enfants du sommet, les 4 suivants sont les petits-enfants et ainsi de suite. On s'arrange pour que chaque nœud soit plus grand que chacun de ses enfants. Ensuite, on échange le sommet (qui est forcément le plus grand élément) et le dernier élément du tableau. On ignore le dernier élément du tableau (la taille du tableau diminue alors de 1) et on recommence récursivement l'opération.

  15. #35
    Candidat au Club
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    janvier 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : Conseil

    Informations forums :
    Inscription : janvier 2014
    Messages : 1
    Points : 4
    Points
    4

    Par défaut Cela va de soi

    Comme disent les ricains, c'est un NO BRAINER, autrement dit ce n'est même pas une question. Je n'ai que 40 ans d'expérience en programmation et Depuis que l'informatique existe, les bons programmeurs ont toujours fait de la réutilisation. Pourquoi ? : parce qu'on est plus productif, parce que c'est un moyen d'apprendre, parce que c'est un moyen de trouver de nouvelles idées, parce que réinventer la roue peut parfois donner l'impression d'être génial ou créatif mais... En fait c'est comme dans le monde universitaire, qui prétendrait réinventer les maths en partant de zéro ? Au contraire c'est en ça s'appuyant sur le savoir des anciens et en sachant repérer et reprendre ce qu'ils ont fait de mieux et de plus intelligent que l'on prouve sa propre intelligence et que l'on passe au stade supérieur. Et aujourd'hui internet nous la merveilleuse facilité de ne pas avoir que les livres à fouiller pour trouver le savoir.
    NO BRAINER

  16. #36
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 520
    Détails du profil
    Informations personnelles :
    Âge : 59
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 520
    Points : 16 956
    Points
    16 956
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par TJ1985 Voir le message
    ....
    Donc, vu d'un oeil de dinosaure, ne vous cassez pas la tête avec le tableau blanc. Si quelqu'un vous y colle, tournez les talons, vous trouverez sans doute une boîte plus intéressante pas loin dans le coin.
    Citation Envoyé par cooleurZ Voir le message
    Comme disent les ricains, c'est un NO BRAINER, ....
    NO BRAINER


    Vu de l'oeil d'un autre dinosaure, qui a dû coder plus de 7 millions de lignes dans une quinzaine de langages sur 5 plateformes différentes sans jamais avoir eu un cours d'informatique, je suis tout à fait d'accord avec mes 2 collègues plus haut..

    Je trouve que ce genre de choses est absurde.... Même de savoir la différence entre un tri à bulle et le reste....

    Tu cherches "tri" sur ton système d'exploitation et tu auras "qsort". OK. testé et optimisé. Basta...


    Quant à mon péché.... dans une application critique de plus de 700 000 lignes dont j'étais et le CP et le principal codeur, en particulier de l'IHM, tous mes fichiers faisaient plus de 5000 lignes, quelques uns plus de 10 000, et j'ai fait 2 fonctions de plus de 3000 lignes.... Yep.... Une immense boucle de contrôle de l'affichage, qui pouvait fonctionner temps réel ou non, être repassée dedans pendant une utilisation normale pour générer un film, et où tous les paramètres pouvaient être changés dynamiquement en même temps que la boucle tournait... avec des données et des tableaux de données se créant en cours de boucle... Trrrrooooooppppp compliqué de tout découper, avec en plus des overheads prévisibles plus que non négligeables (appeller 20 fonctions avec (même par pointeurs), une vingtaine de paramètres, ... et surtout tenir compte dynamiquement des changements ailleurs)..

    Oui je l'avoue


    Et je ne connais ni le nom ni le détail d'aucun algo de base, sauf éventuellement une moyenne glissante, et les moindres carrés.....




    C'est d'ailleurs une des raisons pour lesquelles je ne retrouve pas de boulot et ai abandonné l'idée d'en retrouver... On ne croit plus aux "têtes bien faites" mais aux "têtes bien pleines"....

    J'échouerais lamentablement à ce type de test, et je n'ai pas envie de me taper d'apprendre des trucs si les gens qui m'embauchent ne sont pas capables de lire et comprendre mon CV..




    PS: ce code a quand même tourné 16 ans opérationnellement dans un environnement 24/24 7/7 dans un grand service gouvernemental de sécurité publique dit "service essentiel" ...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  17. #37
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 471
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 471
    Points : 18 173
    Points
    18 173

    Par défaut

    Oui, on a parfois besoin de faire des monstres. Pas souvent, mais parfois.

    En bancaire, j'ai été backup sur la maintenance d'un monstre de 36,000 lignes, quand son auteur était en vacances. On m'a demandé si on pouvait le découper pour le rendre plus digeste. J'ai passé une semaine dessus, et ma conclusion a été : "vous pouvez gagner 6/7 miile lignes en factorisant les gestions d'erreurs. Le reste, vous pouvez vous gratter, si vous découpez, ça sera encore pire".

    Parceque tout était dépendant de tout(la spécification le voulait, et elle dépendait essentiellement du réglementaire, donc non négociable). Tout ce qui était déjà exportable(à part la gestion d'erreurs, vraiment optimisable) avait déjà été exporté. Les urbanistes ont hurlé que j'étais incompétent, et je leur ai montré mes autres réalisations : des trucs standards, avec plein de petites fonctions, bien découpées, et tout. Mais c'étaient des cas ou c'était possible. Pour ce cas précis, non.

    J'ai plus tard moi-même commis un monstre de 2000 lignes(certes, c'est moins impressionnant) d'un bloc, avec des boucles imbriquées partout, alors que ce n'est pas du tout mon style. Mais, là non plus, je n'avais pas le choix. Dans ce cas spécifique, les limitations du COBOL (qui en 8 ans ne m'avais jamais trahi) m'ont empêché de faire un truc propre. Comme le dit Souviron34, les deux codes tournent comme du papier à musique. C'est certes peu satisfaisant intellectuellement, mais l'important, à la fin, c'est que ça tourne, et qu'en plus on arrive à peu près à le maintenir. Ce qui était le cas.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  18. #38
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 085
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 085
    Points : 11 526
    Points
    11 526

    Par défaut

    Citation Envoyé par Jitou Voir le message
    Je pensais peut être naïvement que tout le monde allait chercher ses "snippets" sur le net pour les adapter dans son propre code mais puisque que cela fait un sujet pourquoi pas approfondir.
    encore une fois je vais le réecrire maitriser et utiliser des technos ça ne sert strictement à rien si le projet est mal construit, mal conceptualisé...et même si on utilise les dernières technos distribuées sur le marché
    Une "techno" n'est pas une finalité c'est un moyen contrairement à ce que les gens du marketing veulent nous faire croire..

    c'est comme si on m'offrait une licence d'Unity 3d le middleware qui permet de créer des jeux vidéos sans trop de code , bon c'est bien d'avoir une licence de cet outil mais si j'ai pas un concept de jeu vidéo valable et valide , cet outil me servira à rien..
    Citation Envoyé par CodeurPlusPlus Voir le message
    Du coup, pour quoi faire ? Si tout devient si vite obsolète...
    ça c'est le gros problème de notre société consumérisme et conditionnée par les codes du marketing c'est comme la mode ou les produits de beauté..
    une entreprise va développer un projet avec une techno A , le marketing nous dit "bon eh bien vous pouvez jeter votre projet il est devenu obsolète" comme ça les éditeurs de matériel et de logiciels gagnent de l'argent avec les royalties le cas échéant.

    Ensuite pour ce qui est de l'obsolescence des technos , un projet qui est bien conceptualisé un max et bien d'équerre, l'évolution technologique c'est pas un problème (quoique dans la pratique c'est souvent différent et ça entraine pas mal de travail supplémentaire )
    Si on conçoit une classe générique clients en Java ou en NET bref on fait abstraction au maximum des technos en principe c'est pas un problème pour porter ces classes avec des nouvelles technos
    je conçois une classe pour les clients qui peut être héritée le cas échéant ça peut être largement réutilisé et pas besoin de réecrire du code
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    public class Client
    {
    private:
     string nom;
    string prenom;
    string Raison_sociale;
    puiblic:
    void AfficheClient{};
    }
    * Descartes: "je pense donc je suis"
    * Bob l'éponge : "je pense donc j'essuie"
    * l'infirmière : "je panse donc je suis"

Discussions similaires

  1. Réponses: 151
    Dernier message: 13/05/2016, 07h51
  2. Programmation : les cours d’informatique qui manquent dans le cursus des développeurs
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 50
    Dernier message: 14/01/2016, 11h55
  3. Réponses: 14
    Dernier message: 22/09/2015, 21h35
  4. Réponses: 1
    Dernier message: 10/06/2013, 01h09
  5. Réponses: 6
    Dernier message: 16/04/2010, 10h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo