Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 148 sur 148 PremièrePremière ... 4898138140141142143144145146147148
Affichage des résultats 4 411 à 4 430 sur 4430
  1. #4411
    4h de tests techniques c'est un peu lourd quand même... Par contre tu te places du point de vue où tous les dev sont de ton niveau voir meilleurs. Les questions te semblent simples, voir débiles, mais je suis certains que la plupart des candidats reçus n'entravent rien ni au C++ ni aux questions.
    J'ai déjà vu des recrutements mal se terminer car aucun tests techniques, juste de la discussion (quelques questions techniques mais pas trop et de la mise en situation). Au final le candidat retenu n'a pas terminé sa période d'essai car techniquement il était à la ramasse: il avait vraiment juste le vernis suffisant pour un entretien pas trop stressant.
    Avec un autre collègue nous avions évité les questions trop orientés framework par exemple en nous disant qu'une personne qui connait une techno x ou y peut aussi apprendre z.
    Mais en fait non. Et le code produit par ce candidat était au final dangereux pour le projet, et il faisait les mêmes erreurs après explications multiples... et pourtant c'était du Java/Spring assez basique.

    Maintenant je me méfie un peu plus: les tests techniques c'est pas la panacée mais ça filtre pas mal quand même. Et en plus là j'ai l'impression que c'est pour un projet un peu plus complexe que du "Java Enterprise" à base de formulaire.

  2. #4412
    Effectivement je ne me suis jamais retrouvé dans la situation de l'entreprise qui cherche à recruter. Enfin j'ai déjà contribué à recruter des gens pour mon équipe, mais les enjeux sont assez faibles (pour moi). À vrai dire je veux surtout que le mec soit sympa et prêt à échanger

    C'est sûr que la question du recrutement est complexe, comment garantir que tu n'embauches pas un guignol. Mais j'ai le sentiment qu'une discussion est le meilleur outil, avec simplement des exemples de codes et d'architecture "critiquez ce code", "critiquez cette archi".

    Il m'apparait vraiment difficile de pouvoir passer pour ce qu'on n'est pas au cours d'une discussion informelle

    À vrai dire un truc qui m'avait énormément plu c'était une boite Irlandaise qui m'avait donné un mini projet à faire. Le truc est faisable en quelques heures mais ils te donnent une semaine.

    En l'occurence il fallait traiter 4GB de données financières (des ticks de prix), l'intérêt du truc c'est que y'avait un objectif de perf/temps d'exécution et qu'il fallait être malin et utiliser les algo dit "online" https://en.wikipedia.org/wiki/Algori...line_algorithm qui te permettent de faire des stats en ne lisant qu'une seule fois les données linéairement.

    Je pense qu'un projet "clefs en main", où tu as vraiment le temps de tout faire dans les régles de l'art donne une bien meilleur idée de ce que vaut quelqu'un. Ca laisse le temps aux détails d'apparaitre et de voir comment fonctionne quelqu'un véritablement vu la part de liberté. Fallait aussi faire une mini doc, etc.

  3. #4413
    Et sinon complètement hors sujet mais je découvre cette chaine, incroyable!

    C'est un développeur qu'a bossé dans les années 90 sur des jeux vidéos et qui explique tous leurs secrets, de l'or en barre


  4. #4414
    Citation Envoyé par gros_bidule Voir le message
    Mais est-ce que c'est grave s'il est capable de les apprendre plutôt une fois en poste ? Est-ce que le savoir à la base, ça change bcp les choses ?

    Parfois en entretien on me reproche (ou je fais l'erreur de reprocher) de ne pas connaître un truc. Mais ce truc c'est un détail qui se maîtrise en 5min, ou une techno que tu apprendras vite. Et on ne peut pas se targuer de tout connaître. Un bon dev, il évolue.
    Donc modifier la façon d'allouer la mémoire, n'est-ce pas juste une histoire de convention à appliquer, et donc d'habitude à prendre sur le projet ? Demain tu passes sur un autre projet et on va te dire nan mais allo, nous on fait du Rust, ton C il est inutilement compliqué.
    Pour moi c'est complétement l'inverse : le savoir fonctionne par couche. Tu veux faire du C++, je suis désolé, mais il faut connaitre un minimum de C. Tu veux faire du C++ moderne, OK mais il faut connaitre un minimum de C++ classique. C'est enseigné comme ça partout (et j'ai enseigné dans 3 endroits différents, de la FAC à l'école d'ingénieur publique et actuellement en école d'ingé privé) et ça a une logique de fond je pense. Tout comme il est nécessaire de connaitre des bases de math pour faire pleins de choses, même si tu ne les réutilise pas strictement ensuite, ce sont les briques de bases de ta compréhension.
    Bah idem, pour moi la compréhension de la mémoire et de l’interaction programme-mémoire, c'est la brique de base de la prog. C'est tout à fait pertinent de faire un premier tri des candidats sur ce genre de question de base pour t'assurer que le candidat a bien le savoir nécessaire. Même si tu ne lui demande jamais ça ensuite.
    Enfin du moins, c'est mon avis.

    Citation Envoyé par Garrluk Voir le message
    Justement, pour l'avoir vu dans un certain nombre de code scientifiques/HPC, faire des new/delete à tout bout de champs est une super mauvaise idée niveau performance.
    Surtout que jusqu'en 2018 (je crois ?), il y avait toujours un mutex global sur la gestion de la mémoire dans la libc standard, donc dès que t'es sur un programme multithreadé, et que tu ne compiles pas avec un compilateur récent, tu le paies super cher en perfs.
    Certes mais justement, ce que tu recherche à ce moment là c'est une maitrise parfaite du timing auquel tu libère ou tu alloue la mémoire. En fonction de la logique de ton programme. Ce que tu perds complétement en passant sur des mécanismes plus haut niveau.
    Dernière modification par Nilsou ; 22/11/2021 à 23h37.

  5. #4415
    Toujours le même biais, je dirais.
    "Les gens qui ne savent pas les trucs que je sais sont mauvais."
    +
    "Les savoirs que je n'ai pas ne servent à rien."

    Parfois un peu vrai mais il faut lutter contre ça un minimum.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  6. #4416
    Citation Envoyé par Nilsou Voir le message
    Certes mais justement, ce que tu recherche à ce moment là c'est une maitrise parfaite du timing auquel tu libère ou tu alloue la mémoire. En fonction de la logique de ton programme. Ce que tu perds complétement en passant sur des mécanismes plus haut niveau.
    Ben c'est ce qu'on répète hein. On peut toujours trouver des cas particuliers où une gestion à la main est nécessaire, mais dans la grande majorité des cas avec les containers standards + une bonne gestion du scope des variables on a tout ce qu'il faut.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  7. #4417
    Certes, mais c'est pas tout à fait le propos initial de Kamikaze, qui avait l'air de dire que ce type de savoir était parfaitement obsolète. Et que de fait les questions posées par les recruteurs n'ont aucun sens.
    Je ne suis pas d'accord avec cette analyse.

  8. #4418
    Citation Envoyé par Nilsou Voir le message
    Pour moi c'est complétement l'inverse : le savoir fonctionne par couche. (...)
    J'imagine que nos divergences viennent de nos métiers. Tu évolues dans un domaine plutôt scientifique si je ne dis pas de bêtise ? En tous cas je crois avoir compris que tu ne passes pas tes journées à pondre des API REST abrutissantes :-) Si tu as des contraintes fortes de performances, ou simplement besoin de comprendre comment fonctionne le matos, ce genre de chose, je comprends que des connaissances plutôt bas niveau et/ou scientifiques soient nécessaires, tout comme maîtriser la plateforme/langage.

    Perso, je travaille avec un niveau d'abstraction bien plus élevé, où l'on a pas forcément besoin de chercher les meilleures performances.
    Une de mes dernières missions c'était par ex le Chèque Energie du gouvernement (API REST pour déclarer les chèques, des batchs pour faire les paiements, parsing de fichiers normés, ce genre de trucs basiques). Le projet type d'une grosse ESN (et c'était le cas), où tu vises la rentabilité maximale, et où un gosse qui sort de l'école est vite opérationnel là dessus (et justement, je devais encadrer des jeunes diplomés).
    J'adore aller dans les détails, comprendre comment ça marche en interne (le fonctionnement d'une JVM, les trucs internes de Spring..., en général en entretien c'est moi qui explique le métier au recruteur) etc. Ca "peut" aider en cas de soucis, mais 99% du temps c'est inutile car on te demande juste de pisser du code. Sur les 1% restants, ton expertise coute trop chère, on préfère un workaround pété mais moins cher. Ca me désole.
    En 12 ans je n'ai jamais rencontré un collègue qui était curieux de savoir comment ça marchait une JVM, un Spring Boot, un Spring Batch (la db qu'il y a derrière par ex), divers algos de compression ou de chiffrement... certains ne savaient même pas qu'il existait des types primitifs en Java (ce qui les amène à créer des booléens à 3 états dans des cas où ce n'est pas utile, ouaip : true/false/null, et tu te prends des NullPointer partout car le dev considère que ça n'arrive jamais), c'est dire... et pourtant c'est ce que demande le projet. Un type comme moi n'a pas sa place (et je l'ai assez vite perdue), je ne suis pas rentable et les chefs me l'ont souvent rappelé (et puis bon... je m'ennuyais à mourir aussi). Mon expertise je l'aime, c'est ma passion, j'apprends par couche, mais elle n'est pas reconnue (en France en tous cas, depuis que je suis au Canada c'est très, très différent).

    Je comprends donc que l'apprentissage par étapes peut être nécessaire dans certaines disciplines, être un plaisir personnel pour certains aussi, mais hélas une partie de l'informatique se contente de gens que je considère comme peu passionnés, ou peu curieux. Ils apprennent directement le Java ou dotNET haut niveau, et n'ont jamais touché une ligne d'assembleur ou de C, donc ils ne savent même pas ce qu'est un pointeur, un pipe, un socket, ou pourquoi un GOTO c'est pas glop. Ces gens là n'ont aucune chance de passer des tests compliqués décrits plus haut dans le thread, alors qu'ils pourraient peut être faire le taff. Enfin bien... disons que le projet sera livré sans trop de retard et le patron gagnera plein de pognon.
    Dernière modification par gros_bidule ; 23/11/2021 à 00h09.


  9. #4419
    Je suis dans le privé en France et je ne me reconnais absolument pas là-dedans.
    Nulle offense hein, mais j'ai pas du tout performé en ESN et (par chance) assez facilement réussi à trouver des jobs en direct...

  10. #4420
    Aucun soucis
    Clairement, les ESN d'informatique de gestion c'est un monde à part J'aurais teeeeeellement aimé trouver des boites comme la tienne ou celle de Nilsou etc. Ce que je vois comme de la vraie informatique, où tu comprends ce que tu fais. Vos posts transpirent l'informatique, et même si ça fait un peu mal au crane, je trouve ça beau.


  11. #4421
    Je suis exactement dans le cas que tu donne gros_bidule. Incapable d'implémenter un sort ou d'optimiser une recherche dans un arbre. Mes connaissances en math s'arrêtent au niveau seconde (et encore...). Mais ce n'est pas un manque de curiosité ou de passion, que j'ai pour plein d'autres domaines dans le dev, simplement que je n'en ait jamais eu besoin et que c'est l'architecture et le haut niveau qui me plaisent. Un employeur qui me demande un algorithme pointu d'optimisation me prendrais pour un débutant, alors que si il a besoin d'une app web je pourrais surement faire très bien faire le taff.

    Donc non Nilsou, je ne suis vraiment pas d'accord, pas besoin de connaître le C ou des maths pour faire un bon développeur.

  12. #4422
    Sauf qu'après c'est une question de langage choisi. Si tu veux faire une app web pas besoin de C sans doute, mais si tu veux faire du C++ c'est loin d'être accessoire.

    Quant aux math, pour moi elles sont nécessaires pour tout bon développeur. Ou du moins, elles facilitent grandement l'apprentissage des langages et de nombreux concepts liés à ces langages. C'est toujours possible de faire un bon développeur avec des maths de niveau seconde. Est-ce efficient comme stratégie d'enseignement quand on veut amener le maximum de personne à un bon niveau dans un temps donné ? À mon sens, non. (raison pour laquelle, d'ailleurs, la plupart des écoles d'info ont tendance à recruter des gens qui sortent avec un bac ayant des maths dedans ...). Le cerveau fonctionne par acquis qui s'applique ensuite à l'apprentissage des autres acquis, couche après couche (cf : Piaget : apprentissage chez l'enfant). Tu peux sauter les étapes, mais c'est globalement inefficace en moyenne et ça peut amener à de gros troubles persistant dans la compréhension de certains concept (cf : méthode globale en lecture).

    Puis la question est plus large en définitive, et un brin plus philosophique que la simple efficacité. Si le but n'est de former que des gens ultra-spécialisés en pissage de code, à la limite on peut éviter de leur enseigner l'histoire, le français et qu'une pomme qui tombe d'un arbre a une accélération liée à la gravitation. C'est juste pondre le « meilleur des mondes » que faire cela. Un monde de personne dans des cases qui seront ensuite incapables de changer de domaine en fonctions de leurs envies, incapables de s'adapter à des contraintes changeantes dans le temps, etc. Bref, de bons rouages de machines.

    En général on essaie de pondre autre chose dans les milieux d'enseignements et de construire les cursus sur des bases larges, du moins spécialisé au plus spécialisé. Le but n'est pas que d’être efficace, mais d'amener une meilleure compréhension, une souplesse et une certaine « curiosité » comme le pointe gros_bidule.

  13. #4423
    Tout ce que je veux dire c'est que cette histoire de couche d'apprentissage ne me semble pas juste. C'est normal de se spécialiser de nos jours, et ne pas connaître les rouages des tonnes de couches d'abstractions qui sont en dessous de sa spécialité n'empêche pas d'être compétent. Bien sûr ça ne fait pas de mal d'être au courant, mais ce n'est pas sur des choses complètement en dehors du domaine de prédilection du candidat qu'un recruteur devrait le tester, sous prétexte que c'est "les bases".

  14. #4424
    D'un point de vue purement « méthode d'enseignement » et science de la formation du cerveau, cette histoire de couche d'apprentissage est un fait scientifique démontré dans le domaine des sciences cognitive (première formulation par Piaget, puis confirmation successive par la neurobiologie puis par les sciences expérimentale autant en science sociale qu'en IA).

    Sur l'aspect pratique de la discussion. Je ne vois pas comment on peut dire que connaitre un delete est « complétement en dehors du domaine de prédilection d'un candidat » quand celui-ci postule sur du C++, c'est quand même un brin exagéré ...

    Tester les bases pour un recruteur est un très bon moyen de filtrer les candidats.

  15. #4425
    Je me prononcerai pas sur les aspects C++ (j'en ai touché qu'étant étudiant) mais pour le coté "questions d'entretiens" je suis toujours ambivalent sur les trucs un peu pointus/bas niveau/question académiques/truc qu'on utilise pas au quotidien.

    Bien franchement si on me demande de recracher un truc d'algo en entretien, je décrirai plutôt "comment" je me comporterai dans une situation qui nécessiterai cette connaissance, que de recracher ladite connaissance. Car personnellement je trouve que c'est le plus parlant. D'ailleurs c'est ce dont je parle le plus en entretiens : qu'est-ce que j'ai fais, quels problèmes j'ai rencontré, comment je les ai résolu (ou tenter de résoudre) comment j'ai réussi / échoué et pourquoi. En général ça marque un max de points et on m'emmerde pas avec des questions à la con.

    Et concernant la capacité de juger de la qualité technique d'un candidat : la période d'essai est justement là pour ça, vous aurez l'heure juste et ça vous évitera de juger sur un reflet de qualité franchement questionnable. Rien ne vous protégera d'un gars qui pourrai performer en entretien et être une véritable plaie une fois en poste. A mon avis, plutôt que de passer des mois à chercher le candidat parfait (comme ça se fait parfois en France) on ferai mieux de mettre à l'essai le premier qui semble faire l'affaire et le virer si ça va pas quelques jours/semaines plus tard.

  16. #4426
    Citation Envoyé par Nilsou Voir le message
    Quant aux math, pour moi elles sont nécessaires pour tout bon développeur. Ou du moins, elles facilitent grandement l'apprentissage des langages et de nombreux concepts liés à ces langages.
    Plus que les maths c'est surtout la capacité d'abstraction qui est très utile en info.
    Est-ce qu'apprendre les maths aide à l'améliorer ? Certainement.
    Est-ce que c'est le seul cursus qui permet de le faire ? J'en doute.

    Citation Envoyé par hijopr Voir le message
    Tout ce que je veux dire c'est que cette histoire de couche d'apprentissage ne me semble pas juste. C'est normal de se spécialiser de nos jours, et ne pas connaître les rouages des tonnes de couches d'abstractions qui sont en dessous de sa spécialité n'empêche pas d'être compétent. Bien sûr ça ne fait pas de mal d'être au courant, mais ce n'est pas sur des choses complètement en dehors du domaine de prédilection du candidat qu'un recruteur devrait le tester, sous prétexte que c'est "les bases".
    Citation Envoyé par Nilsou Voir le message
    D'un point de vue purement « méthode d'enseignement » et science de la formation du cerveau, cette histoire de couche d'apprentissage est un fait scientifique démontré dans le domaine des sciences cognitive (première formulation par Piaget, puis confirmation successive par la neurobiologie puis par les sciences expérimentale autant en science sociale qu'en IA).
    Non mais là vous ne parlez pas de la même chose et vous dites tous les 2 un truc juste.

    Citation Envoyé par Dross Voir le message
    Bien franchement si on me demande de recracher un truc d'algo en entretien, je décrirai plutôt "comment" je me comporterai dans une situation qui nécessiterai cette connaissance, que de recracher ladite connaissance. Car personnellement je trouve que c'est le plus parlant. D'ailleurs c'est ce dont je parle le plus en entretiens : qu'est-ce que j'ai fais, quels problèmes j'ai rencontré, comment je les ai résolu (ou tenter de résoudre) comment j'ai réussi / échoué et pourquoi. En général ça marque un max de points et on m'emmerde pas avec des questions à la con.
    Ceci.
    Les capacités d'analyse, de recherche d'information et d'adaptation sont bien plus importantes pour un bon ingénieur que les connaissances purement théoriques.
    C'est la faute à Arteis

  17. #4427
    Citation Envoyé par Orhin Voir le message
    Non mais là vous ne parlez pas de la même chose et vous dites tous les 2 un truc juste.
    Je rejoins hijopr sur le fait qu'il y a probablement beaucoup de personnes avec des profils qui ne sont ni scientifiques ni même techniques, qui sont formées juste ce qu'il faut pour de la programmation "Ikea" et qui s'en sortent très bien.
    I.e. s'appuyer sur des bibliothèques et des modules fonctionnels conçus et maintenus par des gens plus compétents que soi, et surtout savoir s'insérer dans un existant complexe sans forcément en maîtriser tous les rouages.
    « Sans puissance, la maîtrise n'est rien »

  18. #4428
    Pour avoir travailler dans un lieu avec des centaines d'éminents scientifiques, le constat était que c'était de piètres développeurs. A tel point qu'un des devs de l'équipe "des trucs administratifs chiant pas scientifique en java" (la mienne) avait était débauché pour tenter de remettre de l'ordre dans un bordel monstrueux de Python/C++.
    En gros chaque chercheur de chaque équipe avait ses bouts de pythons inmaintenables et quand le chercheur s'en allait, plus personne ne pouvait rien faire du code. Il n'y avait ni architecture commune, ni gestionnaire de source, ni standard de code. Le seul truc commun c'était les libs scientifiques et de dessins en C++ et/ou la glue python qui allait avec.
    Et évidemment le code était toujours le plus concis et 'malin' possible, donc très dur à comprendre même pour d'autres chercheurs aux profils similaires.

    Pour moi c'est clairement deux mondes distincts les "sciences" (maths/physiques/bio) et l'informatique. C'est des compétences finalement très différentes, même la capacité d'abstraction est différente: un matheux peu abstraire un algorithme en une formule ésotérique incompréhensible par le commun des mortels.
    Un développeur sera capable d'abstraire un comportement pour le modéliser et le rationnaliser. Pourtant le cursus pour devenir dev c'est encore et toujours par les maths, et quand je dis "je suis ingé en informatique" j'ai souvent droit à "tu dois être balaise en Maths alors !" (en plus "de mon imprimante est en panne"...) alors qu'en fait je suis plutôt moyen.
    Il y a tout une frange de dev qui sont aussi des matheux ou qui utilisent des outils mathématiques avancés, mais j'ai l'impression que c'est une minorité...

    J'ai pu constater aussi que des devs juniors avec un parcours académique scientifique très poussé (genre thèse en physique nucléaire) luttaient tout autant que les autres avec des concepts d'abstraction type les proxy de Spring (AOP pour gérer les transactions par exemple).

    Et pour revenir au sujet du recrutement, c'est vrai que c'est compliqué. Les petits projets maison c'est très sympa mais une frange de dev peut ne pas avoir le temps de consacrer une dizaine d'heures ou plus de sa semaine pour faire un TP. Le recruteur va aussi devoir prendre du temps pour bien éplucher tout ça. Les QCMS et autres tests sont toujours un peu nazes (périmés, à côté de la plaque, trop simple, trop compliqué)... Les énigmes à la Google (ils font encore ça ?) je trouve ça pas terrible non plus. C'est finalement assez compliqué de trouver le bon candidat...

  19. #4429
    Citation Envoyé par William Vaurien Voir le message
    Pour avoir travailler dans un lieu avec des centaines d'éminents scientifiques, le constat était que c'était de piètres développeurs. A tel point qu'un des devs de l'équipe "des trucs administratifs chiant pas scientifique en java" (la mienne) avait était débauché pour tenter de remettre de l'ordre dans un bordel monstrueux de Python/C++.
    En gros chaque chercheur de chaque équipe avait ses bouts de pythons inmaintenables et quand le chercheur s'en allait, plus personne ne pouvait rien faire du code. Il n'y avait ni architecture commune, ni gestionnaire de source, ni standard de code. Le seul truc commun c'était les libs scientifiques et de dessins en C++ et/ou la glue python qui allait avec.
    Et évidemment le code était toujours le plus concis et 'malin' possible, donc très dur à comprendre même pour d'autres chercheurs aux profils similaires.
    So true.
    Dans mon labo, vu que les codes sont aussi utilisés par des partenaires industriels on a une mini-équipe qui bosse uniquement sur l'intégration et la qualité du code pour être sûr que ce qui doit sortir de la partie recherche est utilisable par d'autres.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  20. #4430
    Citation Envoyé par William Vaurien Voir le message
    Et pour revenir au sujet du recrutement, c'est vrai que c'est compliqué. Les petits projets maison c'est très sympa mais une frange de dev peut ne pas avoir le temps de consacrer une dizaine d'heures ou plus de sa semaine pour faire un TP. Le recruteur va aussi devoir prendre du temps pour bien éplucher tout ça. Les QCMS et autres tests sont toujours un peu nazes (périmés, à côté de la plaque, trop simple, trop compliqué)... Les énigmes à la Google (ils font encore ça ?) je trouve ça pas terrible non plus. C'est finalement assez compliqué de trouver le bon candidat...
    De notre coté, on a fait un choix : on écrème les CVs sur des critères sommaires mais peu restrictif (langue, localisation vraiment pas compatible, expérience annoncée vraiment trop réduite par rapport aux attentes), et on balance un test technique en ligne via la plateforme CodingGame (QCM et de vrai exos de prog), et on prendra le haut du panier pour un entretien technique qu'on fera sans doute par visio, l'idée étant surtout de garder le coté technique pur au strict minimum (juste s'assurer que le candidat est bien celui qui a passé le test technique) mais surtout de voir si l'etat d'esprit est compatible avec le reste de l'équipe.

    D'ailleurs, si y'a des devs Java/Spring (une connaissance de kotlin est un vrai plus mais pas indispensable) dispo sur Lyon et ses environs (ça sera du full TT dans un premier temps, mais on passera sans doute a un ou deux jours en local a moyen/long terme, les locaux seront choisis en fonction des dispos et de la localisation des membres de l'equipe), faites péter les CVs. Je mord pas (Shotmaster peut témoigner) et le projet est plutot cool.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •