Très cher 'nal,
Il y a bien longtemps que je ne me suis pas confié à toi, néanmoins, sache que je ne t'ai pas oublié.
Mais aujourd'hui, j'ai atteint un niveau de saturation, et j'ai besoin de te parler pour ne pas exploser.
Voici ma petite histoire (oui, ça commence par ma vie):
Je suis dans le monde du travail depuis maintenant presque 8 ans, en temps que développeur, et suis un véritable passionné de code (principalement C++ et PHP). C'est à dire que j'ai toujours cherché un faire le meilleur code possible, à monter en compétences, et à pousser dans les retranchements les capacités des langages utilisés, en me mettant des défis de coding. C'est ainsi que je suis relativement vite monté dans les échelons, et, même si le salaire de suivait pas toujours, ai eu des responsabilités toujours croissante.
Jusque là, je pensais bêtement avoir un niveau normal pour tout développeur, qui as quelques années de pratique.
Mais voilà, depuis environs deux mois, on m'a chargé de recruter une équipe. J'ai juste attaqué la recherche du poste de Lead Developper PHP, c'est à dire, quelqu'un qui devra relire systématiquement les commits d'autres dev, afin de maintenir un niveau de qualité et une homogénéité, ce qui demande une bonne maîtrise du langage. Donc c'est après un entretien avec les potentiels candidats, que je leur ai fait passer un test, que je pensais extrêmement basique, et faisable par n'importe qui (il consiste en gros, à parser un fichier vCard, et à l’insérer dans une base de données).
Et là, c'est le drame. Je suis tombé de très haut, en m'apercevant à quel point il y a un fossé, entre le CV/entretien et les compétences technique réelles.
Entre ceux qui n'ont visiblement jamais programmé en objets (où qui ne sont pas capable d'imaginer un code découpé en objets), et qui font des kilomètres de procédurale difficilement lisible et maintenable (alors que le test est fait de façon à pouvoir être fait en objet). Et ceux, où la protection des variables SQL se limite à $sql = "INSERT INTO [...] SET col1='".$col1."', col2='".$col2."'";, ça fait juste peur.
La majorité des gens ont juste pondu un truc qui était le standard d'il y a 12 ans, j'aurai honte de me présenter pour ce genre de poste en faisant ce genre de chose.
Et le pire, c'est que personne n'a fini le test. Alors que pour l'avoir fait dans les mêmes conditions (il est issue d'une problématique que j'ai eu un jour, donc il m'a fallu réfléchir « from scrach », comme un candidat), je l'ai fait en 1h40, bien structuré, alors que je donne 3h aux personnes… Je pensais que c'était large 3h.
Mais en regardant les codes, j'ai compris où était le soucis rencontré. Ces "dev" ne savent pas penser de façon générique, et perdent un temps phénoménale à écrire toutes les combinaisons possible, alors que la structure et toujours identique, et se doit d'être traité comme tel. Ce qui fait qu'ils passent 3 fois plus de temps sur la même chose.
En résumé, je pense qu'il y a une très très grosse surestimation de niveau pour les dev du marché. Et je pense que malheureusement, ils n'en sont même pas réellement conscient, et ça m'inquiète pas mal, de voir à quel point on peu se déclarer "développeur expérimenté", en ayant a peine quelques bases. Et d'autre s'en foutent carrément, car si ils trouvent une boîte où il sont entouré de "médiocrité", ça permet de masquer la leur.
Le plus triste dans l'histoire, c'est que la majorité réclamais - où avait déjà - un salaire supérieur au mien, et parfois bien supérieur. Ça fait mal, et ça fait un peu déprimer… Il va falloir que je réclame une augmentation :p.
La question que je fini par me poser, c'est: Est-ce que j'accorde une trop grande attention, à la qualité de code ? Suis-je un cas particulier à aimer le travail bien fait ? Quand j'en voit certain qui pondent des bouses infâme, mais "On s'en fou, tant que ça marche… Tout le monde est content." je sais plus trop. Au final, quelqu'un qui code mal et aussi bien vu, que quelqu'un qui code bien.
Voilà donc, c'était un bout de ma life, et mon interrogation du soir.
Sur ce, bonne nuit 'nal, et merci de m'avoir écouté. Ça fait du bien.
PS: Si par contre, vous êtes très bon en PHP, et je vous voulez travailler proche de Lille, j'ai un poste dispo pour vous ;).
PSS: Et si vous avez un poste vacant, est que vous cherchez quelqu'un qui aime les défis, ça pourrait m’intéresser également.
# hint: PHP
Posté par ckiller . Évalué à 10.
PHP ? je croyais que tu aimais le développement
[^] # Re: hint: PHP
Posté par Snarky . Évalué à 10.
J'aurai été étonné de pas avoir cette remarque ^ ^ .
Oui, le PHP c'est dégelasse, si on l'utilise mal.
Mais depuis PHP5, les choses ont énormément bougé, et il est possible de faire du bon code, à condition de savoir s'en servir. Entre les typages d'objet, surcharge et namespace, ça commence a ressemble à quelque chose, même si il lui manque encore certaines fonctionnalités (genre, véritable gestion unicode), et qu'il a encore trop de largesse à mon goût.
[^] # Re: hint: PHP
Posté par Renault (site web personnel) . Évalué à 10.
Le problème de PHP est que son développement est indigne d'un langage aussi populaire et utilisé notamment dans des contextes professionnels.
PHP c'est : une incohérence de conception (noms des fonctions, fonctions qui font des choses pratiquement identiques, organisation du bouzin), pas de tests de non régressions (la correction d'un bogue qui réveille une faille déjà corrigée par le passé ce n'est pas acceptable), etc.
Personnellement, je trouve cela problématique.
[^] # Re: hint: PHP
Posté par Anonyme . Évalué à 10.
sinon ton test est peut être un peu dure, le stress du candidat, la peur de foirer le test.
Les ingé développement par chez moi avec un CV long comme un vendredi après midi, ca code en dur TOUT, les chemins, les variables etc … même ce que tu n'imagine pas ! les fichier XML sont parsés, mmh a l'arrache et si une valeur manque sa segfault, si la valeur a plus de caractère que prévu, sa segfault aussi. La fenêtre de l'appli métier se positionne hors de l'écran car l'écran du dev est immense, et comme c'est codé en dur, pas de bol sur l'écran du client plus petit ca ne s'affiche pas, lol. la solution : acheter un écran plus grand \o/
mais étonnamment ca marche :). Pour le profil que tu souhaite, a par écumer github, ou poster une annonce ici même. Faire la sortie de l'ecole 42. A ta place j'oublierais tout espoir, ou prendre un jeune et le former.
après ils ont pas de bol tu connais le métier, ils passeraient par un DRH sortant d une grande école de commerce c'était bon !
[^] # Re: hint: PHP
Posté par Kioob (site web personnel) . Évalué à 3.
Je ne peux malheureusement que confirmer. J'ai été dans une situation similaire, j'ai fait passer pas mal d'entretien, et j'ai bien été obligé de revoir mes exigences à la baisse. On cherchait des développeurs expérimentés, on s'est retrouvé avec de simples exécutants.
Le seul à me satisfaire, c'est l'apprenti, qu'on a pu former dès le début et qui sera probablement assez bon avec l'expérience.
alf.life
[^] # Re: hint: PHP
Posté par totof2000 . Évalué à 10.
Le problème vient aussi des recruteurs.
Je m'explique : on demande de plus en plus de personnes surexpérimentées pour des taches basiques. Ce ne sont pas forcément les techos qui demandent ça mais les RH ou les chefs de services qui ne comprennent pas grand chose au métier et à ce que font les gens qu'ils dirigent (ce sont des "managers") De ce fait, les personnes avec un peu moins d'expérience et de compétences se voient obligés d'enjoliver subtilement leurs compétences pour pouvoir au moins décrocher un entretien et ensuite avoir la chance d'apprendre à faire mieux.
Si l'honnêteté était la norme côté recruteur, je serais plus prompt à condamner ce genre de comportement, mais là je ne peux qu'être désolé de la situation.
Sinon d'un autre côté, la démarche "on s'en fiche tant que ça marche" est fortement encouragée par les entreprises de nos jours : om préfère promettre monts et merveilles avec des délais intenables quitte à sacrifier la qualité du produit livré, juste parce que des commerciaux, ou des pseudo-techos ayant les dents longues et un peu de pouvoir ont promis des miracles pour pouvoir grimper les échelons.
[^] # Re: hint: PHP
Posté par totof2000 . Évalué à 8.
J'oubliais :
Sinon d'un autre côté, la démarche "on s'en fiche tant que ça marche" est fortement encouragée par les entreprises de nos jours : om préfère promettre monts et merveilles avec des délais intenables quitte à sacrifier la qualité du produit livré, juste parce que des commerciaux, ou des pseudo-techos ayant les dents longues et un peu de pouvoir ont promis des miracles pour pouvoir grimper les échelons. Et là, malhereusement, je ne fais pas de caricature : c'est malhereusement ce que je constate depuis plusieurs années ( plus ou moins prononcé, je dois le reconnaitre, selon les boites ou je suis allé). Il n'y a que quelques domaines qui résistent (domaines ou les défaillances peuvent couter cher : télécoms par exemple, et encore, pas pour toutes les applis, et peut-être certaines applis bancaires ou industrielles ou le moindre pépin peut couter cher en terme d'argent ou de sécurité physique).
Maintenant, si on en revient au PHP, utilisé majoritairement pour faire des pages web, globalement, qu'est-ce que ça peut faire que le code est un peu plus lent, ou que certaines requêtes plantent ? Il n'y a pas mort d'homme, et tant que les stats de consultation ne souffrent pas trop, ce n'est pas dramatique (ce n'est pas ce que je pense, je te rassure, c'est la mentalité générale).
[^] # Re: hint: PHP
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Il faut ajouter aussi que les boites qui font des relectures de code par un expert interne, est très rare. La relecture des tests est encore plus rare. Il n'y a donc pas de pression pour avoir un code de qualité.
"La première sécurité est la liberté"
[^] # Re: hint: PHP
Posté par barmic . Évalué à 8.
Là où je bosse on a mis en place une relecture (code, test et doc), mais faite par un autre de l'équipe. Un moins bon qui relis le code d'un bon, doit vraiment chercher à le comprendre et pourra une fois qu'il aura compris le code voir s'il y a des manques (ce n'est pas parfait bien sûr). Ça crée une dynamique ou chacun progresse. C'est un peu comme du pair programing en étant moins coûteux et plus flexible.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: hint: PHP
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Une relecture fait par soi-même, ce n'est pas une relecture.
Ensuite, est-ce que vous avez fait des fiches de relecture ? Genre une série de point à vérifier (ex: est-ce que le coding standard est respecté ? Est-ce qu'il peut y avoir des divisions par zéro ?, est-ce que des exceptions peuvent remonter sans être pris en charge ? etc…)
"La première sécurité est la liberté"
[^] # Re: hint: PHP
Posté par barmic . Évalué à 2.
Oui et la grille est enrichie/améliorée au fure et à mesure.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: hint: PHP
Posté par GG (site web personnel) . Évalué à 3.
Bonsoir,
Le PHP est maintenant utilisable en pure programmation objet, dans sa dernière version. Peut être depuis la version 5.4 au moins, ce qui fait déjà un bon bout de temps.
Ceux qui sont restés aux vieilles version pensent encore que le php n'est pas adapté pour de la programmation objet… pourtant il y a tout ce qu'il faut maintenant.
Tricher sur les CV, c'est devenu tellement courant, et bien souvent par les SSII elles-même pour vendre leur candidats.
Quelqu'un qui a son CV sur Internet est déjà un peu plus fiable, parce que ça limite l'envie de la SSII de truquer le CV (il est déjà sur Internet…).
Oui, les tests sont importants, pour compléter l'entretien.
As-tu mis ton annonce sur http://fr.lolix.org/ ?
Bonne soirée
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: hint: PHP
Posté par ckiller . Évalué à 8.
Ce n'est pas la programmation objet qui fait un bon langage.
Il y a tellement de bizarreries syntaxiques. par exemple:
Il y a un tel mélange de gruikerie que les libs de base viennent avec leur standards, et bonjour les mélanges CamelCase, prefix_ et autres conventions.
Bref, c'est moche.
[^] # Re: hint: PHP
Posté par Snarky . Évalué à 3.
Je suis d'accord dans le principe pour le 42, ça peut paraître étrange, mais ça a aussi ses avantages le castage implicite. Mais c'est aussi pour ça qu'il existe en PHP le triple égal qui prend en compte le type:
"0042"==="00042"retourne false. Mais c'est comme tout langage, quand tu comprend la mécanique interne, c'est pas un soucis.[^] # Re: hint: PHP
Posté par Zylabon . Évalué à 0.
Quand tu comprend la mécanique interne et que tu fais jamais de faute de frappe, c'est tellement vite fait d'écrire == au lieu de === ou réciproquement.
Please do not feed the trolls
[^] # Re: hint: PHP
Posté par Marotte ⛧ . Évalué à 10.
Aussi vite fait que d'écrire = au lieu de == ou réciproquement. Je vois pas le rapport.
[^] # Re: hint: PHP
Posté par Zylabon . Évalué à 1. Dernière modification le 20 novembre 2013 à 21:59.
Ben si, c'est juste qu'il y a deux expressions très proche syntaxiquement, et très différente sémantiquement.
Alors si le compilateur peut voir un problème potentiel, c'est très appréciable.
Please do not feed the trolls
[^] # Re: hint: PHP
Posté par Larry Cow . Évalué à 7.
En ce cas, c'est un problème majeur avec BEAUCOUP de langages, dans lesquels = et == ont des sémantiques très différentes. Je crois que c'était ça, l'esprit de son commentaire.
[^] # Re: hint: PHP
Posté par TImaniac (site web personnel) . Évalué à 10.
A part les langages un peu trop "laxistes" comme le C, n'importe quel compilateur de langage moderne hurlera dans la majorité des cas si tu écrit = au lieu de ==. == et === retournent tous les 2 un booléen, il est impossible pour le compilateur de t'empêcher de faire une connerie.
[^] # Re: hint: PHP
Posté par rewind (Mastodon) . Évalué à 10.
Les compilateurs modernes C (comme GCC ou Clang) hurlent aussi quand tu écris = au lieu de ==.
[^] # Re: hint: PHP
Posté par vieuxshell (site web personnel) . Évalué à 1.
Etant donné que tu fais du TDD et que donc tu as des tests unitaires qui couvrent ~100% de ton code ca ne pose pas vraiment de problemes
[^] # Re: hint: PHP
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu fais du 100% en taux de couverture instruction, branch, MCDC, MCDC avec couverture d'instance ou exhaustif ?
"La première sécurité est la liberté"
[^] # Re: hint: PHP
Posté par flan (site web personnel) . Évalué à 10.
Je ne suis pas du tout d'accord. On peut tout à fait avoir des langages qui sont plus mauvais que d'autres. L'excuse « il suffit de comprendre comment ça marche » est totalement foireuse. Dans le fameux article de blog (PHP, a fractal of bad design), il prend l'analogie suivante : Oui, on peut tout faire en PHP comme en Python (par exemple), tout comme on peut utiliser une pierre pour entrer en clou, il suffit de savoir l'utiliser, mais n'importe qui prendra un marteau.
Par exemple, le == est une source d'erreur phénoménale (un « presque égal », quelle idée fantastique ! ), mais il y en a d'autres, je ne vais pas recopier l'article en question…
[^] # Re: hint: PHP
Posté par Kaane . Évalué à 10.
Je suis d'accord dans le principe pour le 42, ça peut paraître étrange, mais ça a aussi ses avantages le castage implicite. Mais c'est aussi pour ça qu'il existe en PHP le triple égal qui prend en compte le type: "0042"==="00042" retourne false. Mais c'est comme tout langage, quand tu comprend la mécanique interne, c'est pas un soucis.
C'était un exemple gentil, on peut parler de null, de 0, de "" et de undefined si on veut être méchant. Avec des belles brochettes sur is_null et isset (déjà rien qu'à la façon dont l'un et l'autre s'écrivent on commence à pouffer). Après on peut se marrer avec des classes nulle ou des interfaces non définies. Tu rajoutes de la création de classe dynamique avec des noms en UTF-8 et c'est festival.
[^] # Re: hint: PHP
Posté par Dinosaure (site web personnel) . Évalué à 6.
Le castage (?) implicite n'est pas un avantage et le triple égal est une aberration qui n'est là que pour pallier à un système de type inexistant - un bout de scotch sur une grosse fuite d'eau.
[^] # Re: hint: PHP
Posté par Batchyx . Évalué à 9.
5.4, ça fait quoi, 2012 ? Et tu voudrai pas par hasard des gens avec 5 ans d'expérience là dedans, pendant qu'on y est ?
Faire adopter une nouvelle version d'un langage, c'est difficile, quelque soit le langage. Pense qu'une grosse boite à redmond vent encore des compilateurs qui supportent pas C99, qui date de 14 ans.
[^] # Re: hint: PHP
Posté par lasher . Évalué à 4.
Il ne supporteront jamais C99, ils ne sont pas intéressés. Si C++ et C ont des standards qui se recouvrent, tant mieux pour les développeurs C. Sinon, tant pis.
[^] # Re: hint: PHP
Posté par Batchyx . Évalué à 2.
On peut parler de C++11 aussi, si tu veux. Combien de codeurs C++ connaissent son existence ? Combien ont déjà expérimentés avec ? Et surtout: Combien l'ont réellement pratiqué pendant une durée suffisante pour monter en compétence dans des boites qui sont encore au standards d'il y a 5 ans ? Et c'est bien plus vieux que PHP 5.4.
[^] # Re: hint: PHP
Posté par lasher . Évalué à 3.
Tout ce que je voulais dire, c'est que C99/C11/C3001 ne seront sans doute jamais mis en place dans Visual C++ parce que ce n'est pas ce que veut faire Microsoft…
# qui sait
Posté par hervé Couvelard . Évalué à 10.
Alors, je ne sais pas par quoi commencer.
je vais commencer par le plus simple. Vouloir parler de code des autres cela ne fait toujours doucement rigoler. Il suffit de lire les discussions, ici dès que cela parle de code, sur 100 personnes il y a 100 avis différents de ce qui est bien ou mal. Donc peut être que le code que tu fais et qui te semble parfaitement génial, poussé dans ses retranchements blablabla, sera considéré par un autre mec d'une autre boite comme une bouse immonde.
je ne vais pas faire la liste de l'armée mexicaine de ce que les gens peuvent sortir. Le code c'est comme les voitures pratiquement tout le monde à l'impression de pondre le bon.
Le coté un peu moins objectifs : peut être que le poste que tu proposes, le triplet (boite, lieu, salaire), n'attire que des mauvais.
Enfin les gens qui ont travaillé sont "formés" par les endroits ou ils ont travaillés et donc leur manière de coder est fortement empreinte de l'environnement qu'ils avaient. Ils sont peut être capable de changer de s'accorder au tien (qui n'est peut être pas la bonne solutions, in fine)
Enfin, proposer au débotté de faire du code à un mec, moi je l'aurais pas fait, car je ne te connais pas assez pour être certain que le code que tu me demandes n'est pas un code dont tu as besoin et que tu ne sais pas faire ou que tu cherches à avoir un code meilleur que le tien, sans être certain de ne pas être juste un pigeon que l'on va faire travailler gratos.
Enfin, tu dis avoir mis 1h40 à le faire, mais peut être que tu as eu le temps d'y réfléchir avant, que ca s'inscrit dans un flow de travail et que si tu devais le faire à blanc dans un lieu que tu ne connais pas, avec des outils qui ne sont pas forcément tiens, à froid, sans ta bibliothèque perso de fonctions tu ne l'aurais pas fini en 3 heures non plus.
Et puis peut être que ta manière d'aborder le problème n'est pas la bonne et que ce que tu cherches à voir chez l'autre est une mauvaise chose.
Enfin, comme je suis vachement sympa, j'ai fait un truc en moins de 5 minutes… j'ai le poste ?
http://vcardphp.sourceforge.net/
Heu et puis se tirer sur la nouille en criant objet objet objet pour un truc qui est en client/serveur déconnecté, je veux bien discuter des avantages.
[^] # Re: qui sait
Posté par Framasky (site web personnel) . Évalué à 10.
<troll>
Nan mais attends : les mecs indentaient avec des tabulations. Des TABULATIONS ! Et ça ose se prétendre dév !
</troll>
:-)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: qui sait
Posté par hervé Couvelard . Évalué à 10.
nan, ils indentaient ? c'est pour les nuls… c'pas du python
[^] # Re: qui sait
Posté par Framasky (site web personnel) . Évalué à -10.
Pas d'indentation en Python ? T'indentes pas pour faire tes blocs ?
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: qui sait
Posté par dyno partouzeur du centre . Évalué à 0.
C'est acceptable si les tabulations font exactement 2 espaces.
[^] # Re: qui sait
Posté par max22 . Évalué à 10.
je suis d'accord, les bouts de code c'est comme les pets, on ne supporte que les siens.
(malheureusement ce n'est pas de moi).
[^] # Re: qui sait
Posté par Snarky . Évalué à 7.
Tu as raison, mais je pense connaitre assez mon métier pour ne pas tomber aussi bas.
Dans le test, je me contrefiche de comment il a codé réellement, et encore moins que ça fonctionne à la fin. Qu'il ai mis commentaires ou pas. Qu'il ai factorisé ou pas. Et surtout des règles de coding. Ce qui m’intéresse, c'est la logique employé.
Par exemple, seul une personne a réussi le test à l'heure actuel (on ne l'a pas engagé pour une autre raison). Et pourtant, au bout des trois heures, je lui ai demandé si ça fonctionnais, il m'a répondu "Je sais pas."
Il n'avait pas testé son code une seule fois, et n'avait fait que dans le structurel brut. Et je lui ai posé cette question car j'avais clairement vu des erreurs, et rien de fonctionnais lors du test. Mais ce que j'ai pris en compte, c'est la façon de penser de la personne. Elle avait parfaitement structuré les choses, de façon souple et générique. Et donc, à démontré une connaissance avancé en programmation, en structurel et pas uniquement fonctionnel.
Je ne suis pas là pour pourrir les personnes, loin de là. Je sais parfaitement qu'il y a certain nombre de point qui ne peuvent pas être comme je l'entend, et heureusement ! Ça veut dire que cette personne arrive avec une vision différente, ce qui ne peut être qu’intéressant.
Exact, mais je répartis les dev en deux groupes. Les juniors qu'il va falloir former au bon coding (role des Lead Developper), et les leads, qui sont censé bien connaitre le métier, et que leur seul apprentissage, c'est d'utiliser partout les mêmes règles, qui peuvent un peu varier de leurs habitudes, mais qui permettent d'avoir une uniformité.
On demande toujours aux gens si ils sont d'accord pour le test. De plus, ce qui est demandé, existe déjà tout fait, comme tu l'as précisé à la fin. Si ça personne propose d'elle même d'utiliser une lib, c'est même un bon point, même si on lui dis "non" ;p. Et puis, c'est 3h, pas une journée. Difficile d'exploiter des gens en si peu de temps.
C'était un ami qui m'a demandé de convertir son fichier vcf, en fichier excel, rien a voir avec un truc prévu. Je lui ai rendu la chose juste 2h après la demande. J'ai étudié le format, et je n'ai utilisé aucun élément externe pour écrire mon code, dans cette seule période. Donc non, j’estime être dans la même condition qu'un candidat. Le seul point qui change, c'est que oui, je connais mon outil. Un simple éditeur de texte.
[^] # Re: qui sait
Posté par Batchyx . Évalué à 10.
T'est mignon.
Est ce que tu l'a dit au candidat ? Tout me laisse à penser que non. Et même moi en tant que candidat je pourrai pas réfléchir à ce que veut vraiment l'examinateur en ayant la tête dans le guidon, j'aurai quand même tendance à vouloir faire du code propre et maintenable, du type de ceux dont les gens sont près à me payer pour faire. Toi tu t'attendait à du code torché en 1h40 qui va aller à la poubelle avant la fin de la journée.
Donc en gros t'est en train de nous dire que tu voulais surtout savoir comment le mec raisonne, que le candidat l'a parfaitement bien compris, qu'il s'est concentré à te montrer comment il raisonne. Et ensuite tu viens te plaindre qu'il n'a pas pensé à tester son code ?
Je vais t'apprendre un scoop: Si tu ne dit pas ce que tu veux, tu n'aura pas ce que tu veux.
Ton candidat à déjà deviné une grande partie de ce que tu voulais, mais c'est manifestement pas assez. T'a passé toutes ses compétences techniques (peut-importe qu'elles soient maigres, ou pas assez avancées à ton goût) à la trappe parce que il ne t'a pas assez bien cerné. Et après on se plaint des entretiens d'embauches qui ne sélectionnent pas les gens les plus compétents.
[^] # Re: qui sait
Posté par ckyl . Évalué à 9.
Bordel, on cherche pas des robots mais des devs expérimentés !
Ton job ca va être d'analyser et de comprendre. De discuter avec le business pour deviner ce qu'ils attendent. La tête dans le guidon à un entretient ? Ca va donner quoi le jour où tu troobleshoot la prod qui s'est écrasé, que tu dois concevoir des hotfix, ou que tu vas gérer la direction d'un produit ? Ce qu'on cherche c'est justement des gens qui n'ont pas la tête dans le guidon.
En entretient l'important c'est d'adapter ton approche et surtout de discuter et d'expliquer. C'est souvent vachement plus important que de pondre du code correct. Tu peux raisonnablement faire beaucoup de choix, mais c'est expliquer ta démarche, pourquoi et comment qui est importe vraiment.
Par exemple un mec te file un ordi et te dit "J'ai besoin d'une implémentation d'un ring buffer borné".
Si tu commences à coder une structure adhoc comme un bourrin, à écrire les tests, la doc, optimiser. Tu as tout faux. Tu n'as aucune idée de ce qu'attend le gars.
Commence par lui demander dans quel contexte ca va être utiliser, essaies de tater le terrain pour voir ce qu'il attend et sur quoi il va être pointilleux. En général tu fais bien chaque chose une fois, en expliquant ce que tu es en train de faire puis tu peux demander si tu dois maintenir le même niveau pour la suite ou si c'est bon.
Cette démarche est vraiment importante pour les deux côtés. Pour la boîte ca permet d'essayer de détecter les mecs bons techniquement mais où le reste ne suit pas ainsi que d'avoir des critères plus objectifs que le résultat produit en entretient. Au final la démarche du mec est vachement plus intéressante.
Pour le candidat, comme dans la vraie vie, c'est la seule facon de faire ce que l'autre attend de toi. Il faut savoir collecter les informations nécéssaires à ton travail et ne pas partir tête baissée. Tu peux avoir un mec qui va vouloir que tu codes une strucuture adhoc parfaite au tableau sans possibilité de compiler ou TU et va te dégager à la moindre typo ou bug. Et un autre qui voulait simplement que tu lui demandes et comprennent le contexte pour décider qu'au final le seul truc que tu avais besoin de faire c'est définir une interface minimaliste et faire de la composition sur une strucuture déjà existante. Il s'en fou pas mal du code ou que t'écrive des tests si tu lui demandes. Ce choix découle d'une démarche rationnelle basé sur les informations disponibles, et il est évolutif. C'est le meilleur à faire, aujourd'hui.
Dans tout les cas, si tu ne cherches pas à comprendre le but de l'exercice et les attentes de l'autre. C'est un très mauvais point pour toi. L'entretien c'est un échange. Si tu ne cherches pas à comprendre ce que l'autre attend, et à expliquer systématiquement et clairement tout tes choix, tu as tout faux.
[^] # Re: qui sait
Posté par hervé Couvelard . Évalué à 10.
eh, moi je suis d'accord, mais pas dans un poste à smic +10% avec évolution salariale inférieur au coût de la vie.
Si vous voulez des gens qui savent conceptualiser, comprendre le non dit, se projeter, voir que ce qui est voulu va planter et modifier en loucedé pour que ca passe, faut penser à les payer un poil au dessus d'une femme de ménage, ou d'un éboueur.
Ensuite parler de compétence des gens lorsqu'ils ont 10 ans d'expérience, ce n'est pas parler de la personne que vous avez en face de vous, c'est de parler des entreprises ou elle a travaillé ou la formation c'est tout seul sur son temps libre, ou le temps pour faire un truc est pas suffisant pour le faire, ou les questions qu'ils posent ne sont jamais adressées, ou les interrogations qu'il émet sont toujours ignorées.
Et vos employés, lorsqu'ils postuleront ailleurs, ils seront regardé comment ? C'est quand la dernière fois qu'ils ont fait une vraie formation, sur un techno naissante, sur un truc connexe à leur travail (qui leur ouvre l'esprit et ne sert pas à juste leur faire pisser du code plus vite ?)
Parce que là on arrive au paradoxe français :
on attend des gens qui soient formés, mais on n'envoie jamais les siens en formation, on préfère recruter des déjà formés, or toute les entreprises font pareil, donc personne n'est formé.
on a une brochette de recruteurs qui ont l'impression que ce qu'ils font est proprement génial et ont une telle opinion d'eux même qu'ils ne trouve pas UNE seule personne de bonne dans un recrutement (avec 5 millions de chômeurs). C'est statistiquement impossible. Peut être que l'annonce ou le poste ou la fourchette de salaire est juste bonne à attirer des mauvais, peut être que la boite ne donne pas envie, peut être que la région ne donne pas envie. C'est comme si je disais, mes élèves sur les 25 il y a en a pas un qui comprend, ils sont tous cons : vous souririez en pensant que je suis mauvais.
Mais effectivement il y a une baisse du niveau de la formation général, et la baisse est d'autant plus forte que l'on essayé de former des gens à l'entreprise et plus au savoir. DONC 5 ans après, ils ne savent plus rien car tout à évolué, ils ne savent plus apprendre (parce que ce n'était pas le but de l'enseignement), ils ne sont plus "à la page" car l'entreprise les a pressuré sans les faire évoluer.
Les entreprises ont globalement ce qu'elles ont fabriqué. L'inertie du marché enseignement-formation-travail est importante, et tout s'est tassé dans l'indifférence générale (les recrutements horizontaux, ca date bien des années 90) les chaises musicales ca dure un temps. Le manque de compétence (de formation) commence à se payer maintenant. Et encore nous avons 5 millions de chômeurs, heureusement ; ce qui permet d'écrémer à chaque fois ceux dont on ne s'est pas occupé. Parce que l'enseignement, ok, dans les 2 premières années, mais dès que la personne à quittée l'école depuis 5 ans, c'est le monde de l'entreprise que vous jugez. Et oui quelques cas au travers peuvent être mauvais tout seul, mais toute la masse des candidats ?
[^] # Re: qui sait
Posté par Larry Cow . Évalué à 1.
Ce n'est pas exclu, mais pourquoi serait-ce inconcevable que tes 25 élèves soient cons?
[^] # Re: qui sait
Posté par hervé Couvelard . Évalué à 10.
non la seule chose impossible est qu'une chose et son contraire soit vraie (ou fausse) en même temps.
Mais cela voudrait dire que le conseil de classe à fait passer 25 élèves qui n'ont pas le niveau, que ces 25 élèves se trouvent tous dans MA classe et que je sois le seul à avoir une classe comme cela (sinon ca ne me poserait pas de problème).
c'est pas impossible, on gagne même à euro million, c'est dire.
[^] # Re: qui sait
Posté par Larry Cow . Évalué à 0.
Chez toi je ne sais pas, mais ailleurs ça se pratique.
S'ils ne sont que 25, effectivement. S'ils sont beaucoup plus nombreux (mon hypothèse), alors tes "chances" augmentent considérablement.
Je ne me rends pas bien compte à quel point c'est grave chez toi, mais la majeure partie (pour ne pas dire "totalité" : je connais peut-être des profs sans le savoir) des profs que je connais font des constats qui s'approchent de ça. Sauf que eux ne sont pas à 25 par classes.
[^] # Re: qui sait
Posté par hervé Couvelard . Évalué à 10.
Effectivement ils n'ont pas le niveau que l'on pourrait(devrait?) attendre, mais sur les 25 je ne suis pas capable de dire "j'en prendrais aucun dans ma classe si je devais construire moi même ma classe." (que dieu m'en préserve). D'ailleurs c'est quoi le niveau que l'on attend ? on juge le monde de demain avec les outils de celui d'hier.
Il y a une théorie intéressant en éducation : les 3 tiers.
tu prends les 30 1er de la classe d'un niveau, tu les met dans la même classe, avec un prof qui ne le sait pas : il trouvera 1/3 de bons, 1/3 de moyens et 1/3 de mauvais.
C'est de cela dont je parle, un recruteur qui vient expliquer qu'il ne trouve personne de "potable" alors que lui c'est le cador (et qu'il cherche du taff), j'ai même pas envie de lui demander c'est quoi sa boite. Parce que nous sommes des humains, c'est à dire que l'important c'est le savoir être. Le langage, la technique, ca s'apprend plus facilement que de pas être juste suffisant avec un candidat en face de toi, ca s'apprend plus facilement que de chercher ce qui est bon en l'autre plutôt que de chercher ce qui ne va pas.
Des connards (de mon point de vue), j'en ai soupé dans ma vie, j'ai dit stop. Palme des palmes à ceux qui ont l'impression de tout savoir, borné dans leur petites vies et qui trouvent que tes questionnements sont idiots parce qu'ils n'y ont jamais été confronté, parce que la "limite" qu'ils posent entre le mal, le bien, le trop bien est tout ce qu'il y a de subjectif. Ceux qui disent : "regarde, c'est pas mieux comme ça hein ?" avec 3 lignes de code sorties de tout contexte, on ne sait pas si c'est pour challenger qui va partir pour une autre galaxie et 200 ans de voyages ou juste pour un truc interne utilisé par 4 personnes 2 fois par an, et on sait même pas à quoi va servir le code.
[^] # Re: qui sait
Posté par ckyl . Évalué à 4.
Y'a que toi qui est sur ton refrain en boucle mechante boite, mechant patron… Qu'est ce que tu connais de la situation ? D'ailleurs si le mec qui t'interview le fait correctement et est competent, tu penses vraiment qu'il est paye smic +10% ?
Mais encore une fois la question de la remuneration vient souvent après cette etape. Avant tu n'as aucune info. Tu peux facilement avoir des propositions avec 10-20K d'écart selon les avis apres interview. Après le refrain des ingés mal payé, franchement vu le niveau général et les contraintes je trouve que c'est plutôt bien payé quand tu compares aux autres domaines… Pour les bons, oui ca suit pas forcément.
Pour finir tu penses que les personnes qui parlent ici sont dans la case, recruteur bidon, mechante boite qui cherche des petites pour le smic ? Une question, tu as recruté combien de mecs ces dernieres annees ? Pour combien d'interview ?
[^] # Re: qui sait
Posté par hervé Couvelard . Évalué à 2.
je ne suis pas sur mon refrain gnagnagna.
j'en ai plein de cul d'entendre une poignée plus ou moins large de mecs se lamenter sur le niveau que c'est plus ce que c'était, qu'on trouve pas de gens compétents.
je regarde de très loin les annonces d'emploi de temps en temps et je vois des salaires (ou des fourchettes de salaires) qui sont juste lol pour le niveau de compétences recrutés. D'ailleurs, tu m'attaques la dessus, il est combien le salaire proposé pour le poste de lead architecte ? dans les 35 KF plus avantage ?
Le niveau de salaire est en train de diminuer, je n'y peut rien. Il y a peut être une exception dans certains secteurs pointus.
Je ne me pose pas la question de ce que font les gens ici, je ne cherche pas à juger, dans l'absolu je m'en contre fiche d'une force. Je partage MON expérience de ce que je vois ou de ce que j'ai vu. Tu n'as pas le même ressenti, c'est parfait, tu ne connais pas des ingés (pas si mauvais) à smic +10%, tant mieux pour ceux que tu connais.
Maintenant je vis peut être dans un microcosme unique sur terre, j'en suis désolé crois le bien, mais des entretiens d'embauche j'en ai fait quelques un, ca m'a coûté des sous et parfois je me retrouvais en face de recruteurs qui n'avaient aucune idée de ce qu'il fallait pour le poste, j'en ai même qui m'ont demandé si je ne connaissait pas quelqu'un qui serait intéressé par le poste et qui pourraient convenir.
[^] # Re: qui sait
Posté par ckyl . Évalué à 4.
En même temps si tu regardes sur Monster ou autre c'est pas étonnant que tu n'ai que de la merde. Mais tu dois pas bien connaître le sujet si effectivement tu te bases sur les salaires que tu vois passer… Par ce que statistiquement le salaire est extrêmement rarement indiqué, et encore plus dans les entreprises qui investissent dans leur recrutement.
Perso j'ai très rarement eu ne serait ce qu'une fourchette avant d'être passé en entretient. Mais lors du screening le niveau d'attente des deux parties apparaît rapidement et permet de s'arrêter maintenant si ça colle clairement pas (un mec qui postule à 60K pour un poste lambda, une boîte qui cherche un bon à 35K, une boite qui dit chercher un bon mais à clairement le recrutement d'une SSII etc.).
Comme tu dis "lol". Aucun poste précis et surtout pas de "lead architect". Un mec qui est bon et qui est à 35K, il suffit qu'il se réveil et qu'il se bouge…
Mais pourquoi tu te déplaces alors ? Bordel on peut passer son temps à se plaindre et à blâmer les autres. Mais avant de faire un truc qui te coûte tu t'assures que ça en vaut la peine. Déjà un mec pas prêt à te payer un billet de train ou d'avion c'est un mec qui s'en fou de toi et c'est très mauvais signe. Maintenant si tu décides de le faire tu t'assures que c'est pas pour rien.
Notre métier c'est du bon sens, de la technique, et des relations…
[^] # Re: qui sait
Posté par lasher . Évalué à 4.
Juste une question bête : depuis combien de temps travailles-tu aux USA (je crois que c'est le cas en ce moment) ?
J'ai quand même l'impression que le recrutement (surtout dans les grosses boites françaises) est très très différent de ce qui se pratique aux US…
[^] # Re: qui sait
Posté par ckyl . Évalué à 9.
Je ne suis pas aux USA mais en province française.
Oui beaucoup de boîtes font n'importe quoi et offrent de la merde, tu n'as clairement pas le marché des US ou de Londres, mais à l'inverse beaucoup de gens n'ont rien à faire dans le métier. Alors ça va clairement pas te tomber tout cuit dans la bec, 100K pour un techos ca n'existe plus, y'aura des compromis à faire etc.
Mais le discours "y'a pas de taf, ou que de la merde payée 30K alors que je suis super bon" j'achète pas. Simplement par ce que du taff y'en a. Que puisque les entretiens sont merdiques tu passes partout sans aucun soucis, donc qu'est ce que tu fous à 30K quitte à faire de la merde ? Et qu'avec de la patience tu peux trouver des choses intéressantes, des bons et des bons taff y'en a dans presque toutes les boites.
Après tu peux pleurer par ce que tu veux pas passer 3h en entretient, par ce que c'est trop dur d'essayer de comprendre ce qu'on attend de toi, ou penser que c'est partout pourri donc à quoi bon etc. Mais c'est un choix. L'autre c'est d'être malin et pro pour faire des trucs cools, donc augmenter ton employabilité, donc ton salaire, donc faire des trucs plus cool… Sortir du lot n'est pas très compliqué, suffit de brancher son cerveau pour comprendre ce que le business veut et bosser à côté si besoin (combien de métiers offrent cette possibilité pour évoluer ?).
Et pour ceux qui pense que c'est tout pourri ici, il suffit de prendre un billet d'avion. Se plaindre en étant software engineer je trouve ca osé, le monde nous déroule le tapis rouge. Pour je ne sais quelle raison…
[^] # Re: qui sait
Posté par lasher . Évalué à 3.
Je suppose que ton « tu » ne m'est pas adressé. Après tout, je suis aux USA depuis un petit bout de temps… :-P
Sinon je suis content de savoir que ce genre d'opportunités (et de tests) existent, mais j'avoue que lorsque j'étais sorti d'école d'ingénieur, ce qu'on me montrait comme opportunités pour faire du dév, c'était quand même plutôt les boulots payés 30k€—35k€ pour des débutants, et ~40k€—45k€ pour ~5 ans d'expérience. Bref, sans forcément parler de super hauts salaires, je connaissais peu de dévs qui pouvaient se vanter de toucher 60k€, même avec de l'expérience (j'en connais quelques uns quand même).
Pour ce qui est des entretiens d'embauche, j'ai déjà vécu le couple <entretien téléphonique technique, visite d'une journée sur place>. Durant la journée d'entretiens, j'ai eu droit à une discussion avec le VP of engineering, 4 sessions techniques, un déjeuner avec d'autres ingés… Et en effet, je n'ai pas eu à payer un centime (avion, hôtel, voiture de location, tout était aux frais de la boite). Mais j'ai l'impression que dans pas mal de boites franchouillardes, et surtout en IdF (avec les transports en commun, tout ça), souvent c'est pas trop trop le cas.
[^] # Re: qui sait
Posté par ckyl . Évalué à 4.
Oui bien sur, il faut lire le tu comme impersonnel.
Ta vision du marché Francais me semble assez bonne. C'est à dire pas folichon mais sans tomber dans la caricature que certains veulent en faire. Y'a du mauvais, beaucoup de médiocre et des trucs corrects. Ton 60K semble réaliste (je connais mal le marché parisien mais les salaires semble pas très loin d'en province…). Bref tu peux faire des trucs intéressant, sans contrainte forte, en étant dans le 90 percentile des salaires sans être un tueur. Ca tire vachement moins la larme que la vision smic, larbin, pousser des cartons, entretien difficiles pour rien…
Pour les entretiens en France c'est généralement beaucoup plus faible que ce que font les boîtes anglosaxonnes, ce qui fait que c'est plus facile de passer. La contrepartie c'est qu'il faut bien vérifier où on met les pieds.
Mais encore une fois si quand on pense que son travail vaut 100..150K au coût de vie max. Il suffit de se déplacer, il n'y a pas de fatalité a être à 30K ET faire de la merde quand on a les compétences. Ne pas voir ca, c'est se foutre de la gueule de tout ceux qui ont vraiment des problèmes.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"le monde nous déroule le tapis rouge. Pour je ne sais quelle raison…"
Parce que le niveau mondial est encore pire ! (sauf peut être dans les pays de l'est) Et le salaire est bien moindre pour un français qu'un américain.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par Renault (site web personnel) . Évalué à 10.
On en a discuté régulièrement de cette assertion ici pour conclure que c'était difficilement comparable.
Si le salaire américain est de manière brute plus élevé qu'un développeur équivalent français, ça ne signifie pas qu'il peut plus profiter de la vie. Car si le salaire du français est plus bas, c'est à cause des cotisations nombreuses notamment pour la sécu, la retraite, autres impôts qui permettent de bénéficier de services d'État à un prix bien plus bas qu'aux USA. Mais c'est sûr que si tu es un homme célibataire en bonne santé, le salaire américain est plutôt intéressant mais si avoir une famille t'intéresse ce n'est pas forcément une garantie (l'éducation et le coût d'un enfant sont bien plus à la charge du couple aux USA qu'en France via les allocations et un prix de la scolarité ridiculement bas).
Bref, pour comparer les salaires, il faut prendre en compte tous les coûts de la vie à côté sinon ça n'a pas une grande valeur…
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Non certainement pas pour un ingénieur logiciel. J'ai le cas très précis d'un voisin parti à Boston.
Le seul désagrément sont les 3 semaines de congé au lieu de 5 (les grosses boites font cadeau d'une semaine en général). Son salaire net est quasiment double. Pour le prix d'un F3, il a une maison de 200m² avec jardin. Tous les prix de la vie quotidienne sont moins chère qu'en France (en gros 1$ = 1€). Sa boite lui paye son assurance, qui est au niveau des meilleurs mutuelles françaises (+sécu).
Il a 2 enfants, et ne semble pas du tout pressé de partir.
Mais pour une boite, les salaires R&D français sont peu élevés. Un PDG d'une boite japonaise disait que la France était le Maroc de la R&D…
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par lasher . Évalué à 6.
Même avec une bonne mutuelle, ça ne suffit pas forcément. J'ai un pote parti à Seattle, qui a eu la malchance d'avoir une leucémie, mais qui, dans sa malchance a quand même eu le bol d'avoir une femme qui bosse dans le meilleur hôpital pour traiter son type de leucémie particulier. Il bossait aussi pour une boite qui couvrait déjà énormément les frais médicaux… Mais pas complètement (il y a des plafonds au-delà desquels les individus doivent y mettre de leur poche). Bref. Il est en ce moment en rémission, mais a du coup perdu son job (car malade plus de X mois¹).
De façon générale, à cause de la façon dont le système US de santé fonctionne, ce qui en France (et en général dans le reste de l'Europe) coûte très peu et est le plus souvent couvert par la sécu ou une mutuelle, peut se révéler extrêmement coûteux aux USA. Une amie devait passer une radio. On lui a réclamé 1000$. Soit le prix d'un A/R en France depuis les USA. Truc qu'elle aurait pu faire: puisqu'elle était encore couverte par la sécu, au final cela aurait eu le double effet kisscool de lui permettre de revoir sa famille pendant un jour ou deux²… Les plafonds des assurances maladies sont vite atteints. En règle générale, oui, le système US favorise les plus riches : plus on est élevé dans la hiérarchie d'une boite, meilleure est la couverture pour tout. Mais il y a aussi des plafonds pour tout, et étant donné les prix bien plus élevés qu'en France pour tout ce qui est médical, on y arrive assez vite dès qu'on dépasse le simple rhume (j'exagère, je sais).
Pour ce qui est des enfants, il faut tout de même compter entre 50k$ et 150k$ minimum (en fonction de la fac, et suivant si l'on paie le tarif « in-state » ou « out-of-state ») par enfant pour tout ce qui est éducation supérieure, rien qu'en frais d'inscription pour obtenir une licence (qui dure 4 ans aux US — ensuite le plus souvent au niveau master/thèse, le directeur/mentor se charge de payer les frais pour l'étudiant). En règle générale, l'étudiant travaille pendant ses études pour se payer la chambre étudiante ou l'appart, la bouffe, l'assurance maladie qui n'est pas trop chère — dans la fac où je bosse, je crois qu'ils paient ~250$ / an pour l'équivalent d'une assurance qui couvre façon LMDE. Tous les étudiants américains que je côtoie ici, y compris ceux qui sont en « grad school » (c'est-à-dire en master/thèse, avec une orientation de recherche, et qui bossent dans mon labo) ont toujours une partie de leur crédit à rembourser. Les frais d'inscriptions des facs augmentent largement plus que l'inflation chaque année. Par exemple, l'université où je bosse est passée l'an dernier de ~7000$/an pour un in-state à ~11000$ de frais d'inscription. Similairement, les out-of-state devaient auparavant payer ~20000$/an, et désormais ~30000$/an. Cette bulle explosera sans doute à terme, mais je pense qu'elle va encore enfler quelques années.
Concernant la bouffe, oui, elle est moins chère — à condition de ne pas trop chercher à faire gaffe à comment elle a été produite. Si on veut de la bouffe avec à peu près les mêmes garanties qu'en France, on se retrouve avec un prix relativement comparable (ça reste tout de même moins cher aux USA). En règle générale, les besoins de base (bouffe, loyer, vêtement) sont moins chers qu'en France, tant qu'on est pas regardant sur la provenance/la qualité (les murs sont en papier dans la plupart des complexes d'appartements).
Par contre, je trouve qu'on oublie un peu facilement d'autres trucs vachement plus chers aux USA. Les câblo-opérateurs règnent en maîtres, et le font payer très cher : pour avoir un débit plus ou moins équivalent à ce qu'on a avec l'ADSL en France, je paie ~75$ tous les mois. Le téléphone, c'est encore pire : je paie ~95$ / mois. Ça comprend voix et SMS illimités, data 4G (Web) jusqu'à 2Gio de téléchargement (montant et descendant cumulés), puis bande-passante limitée au-delà. Je paie aussi ~10$/mois supplémentaire pour avoir le droit de téléphoner sur des lignes fixes sans autre surcoût à l'étranger. Le tethering est possible si on paie ~15$/mois supplémentaire, et faire office de routeur wifi est aussi possible si on paie le prix (~10$/mois je crois). Bien entendu, si je réinstalle une version « vanilla » d'Android sur le smartphone, les logiciels de mon opérateur ne bloqueront plus les deux dernières options… Ce que je vais faire d'ici 2 mois, quand la garantie aura expiré. En France on ne paie que si on appelle (en national), alors qu'aux US on paie quand on émet et quand on reçoit — et c'est aussi valable pour les SMS³.
Bref, ce qui en France coûte en cumulé (en prenant Free comme exemple, mais on pourrait prendre d'autres opérateurs) ~50€ (abo internet + mobile) coûte ~150$ ici aux USA. Même en faisant la conversion Euro-Dollar, on y perd clairement. Il y a d'autres exemples du même genre que je n'ai pas en tête en ce moment; je les retrouverai sans doute plus tard…
[1] En pratique, ils auraient préféré le garder car il était bientôt remis, et chercher un remplaçant prend du temps et en règle générale coûte des sous. Mais la politique de la (grosse) boite en question fait qu'au bout de X mois en congé maladie, un employé est automatiquement viré.
[2] Elle a réussi à se débrouiller autrement, et à faire baisser le prix, par je ne sais plus quelle magouille.
[3] Autant pour la voix sur mobile je peux comprendre le principe — on paie pour le droit d'être joint n'importe où — autant pour les SMS ça m'énerve un chouïa: même si le SMS n'est pas sollicité, on paie quand même : avec un coup de téléphone, j'ai le choix de ne pas décrocher…
[^] # Re: qui sait
Posté par claudex . Évalué à 3.
Du coup, il a aussi perdu son assurance santé ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: qui sait
Posté par lasher . Évalué à 2.
Il a toujours le droit de souscrire à l'assurance en question, mais sa boite ne paie plus sa part. Heureusement pour lui, il bénéficie de celle de sa femme (médecin). Quelqu'un d'autre aurait pu se retrouver dans la merde juste à cause du prix à payer par mois pour avoir les mêmes bénéfices que procure cette assurance. Comme il était déjà client, mon pote n'a pas de problème, tant que quelqu'un paie (s'il avait tenté de contracter une assurance avec comme condition pré-existante « leucémie », il n'est pas dit qu'il eut réussi…).
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 2.
C'est effectivement tres dur de comparer. A chaque fois que j'en parle, j'ai peur de faire du mal a mes amis restes en France et en Suisse…
Sur la cote ouest, un gars qui a 10-15 ans d'experience, qui est bon, peut faire jusqu'a $250'000 / an , avec assurance payee, l'employeur qui paie une partie des cotisations retraite (401K match comme on appelle ca), …
Ensuites les vacances sont plus courtes qu'en Europe oui, mais en meme temps t'arrives au boulot quand tu veux, tu pars quand tu veux, si un jour tu veux bosser depuis chez toi ben… tu bosses depuis chez toi, pas besoin de demander, etc…
Voila, t'enleves les impots(on va dire 40% du brut pour faire tres large), ca te laisse $150'000 / an net… Bonne chance pour avoir ca en France ou en Suisse en tant que simple developpeur / ingenieur securite / testeur / program manager…
[^] # Re: qui sait
Posté par Kerro . Évalué à 4.
Et ça c'est dans 0,01% des entreprises du pays, ou plutôt 1% ?
Les dernières études semblent montrer que les américains sont ceux qui détestent le plus leur job (en moyenne). J'ai comme un doute sur la description paradisiaque que tu avances.
[^] # Re: qui sait
Posté par Renault (site web personnel) . Évalué à 2.
C'est clair, à part peut être des personnes d'un niveau excellent et dans certaines boîtes, je doute que ce salaire et ces avantages concernent la majorité des ingénieurs en informatique aux USA.
Car en Europe aussi il y en a qui doivent toucher de très gros salaires, mais c'est loin d'être le cas de tous.
[^] # Re: qui sait
Posté par Yann Hodique (site web personnel) . Évalué à 2.
Non ce n'est pas le cas de tous, mais ce n'était pas non plus le propos de PBPG. Tout ce qu'il dit c'est que quelqu'un qui est en position de gagner X (pour X "gros") "relativement facilement" aux USA a beaucoup de mal à faire de même en Europe. Pour avoir quitté les USA il y a 2 ans, avoir bossé en France, Suisse et Angleterre depuis, et être rentré aux USA il y a 2 mois, je confirme la tendance.
Concernant le chiffre avancé (250k), il s'agit probablement du "package", donc pas seulement salaire fixe (mais aussi bonus, stock, etc.). Sans être courant, ce n'est effectivement pas du tout absurde dans le monde du soft, surtout avec 15 ans d'expérience.
Note qu'on parle de grosses boîtes, pas de startups (qui elles ont un package plus axé sur le stock, donc par définition incertain, en positif ou négatif)
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
En même temps, un salaire de plus de 100k€/mois pour une personne technique, c'est de la SF en France.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 1.
Euh par mois meme aux USA c'est de la SF hein :)
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
par an, je voulais écrire :)
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par ckyl . Évalué à 5.
Ca a existé dans certaines boîtes. Des techos salariés a 80-120K j'en ai croisé. Par contre c'est pas des embauches récentes et maintenant tu peux bien te grater.
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 0.
Pas la majorite, je l'ai bien precise : t'es bon et t'as de l'experience.
Mais ca te donne l'echelle compare a l'Europe.
Le salaire de base, quand tu commences a bosser, est plus eleve aux US, et l'ecart continue de grandir a mesure que ta carriere avance.
[^] # Re: qui sait
Posté par Kerro . Évalué à 3.
On trouve de tout, mais en gros le revenu médian en dollars est de 90000 annuel.
J'ignore ce que ça vaut en équivalent € en France, mais à vue de nez c'est bien mieux payé aux USA.
D'où viennent les données ? Quelle représentativité par rapport au terrain ?
Certaines données sont issues des annonces, donc représentativité proche de zéro.
http://www.indeed.com/salary?q1=Developer&l1=
http://www.itjobswatch.co.uk/jobs/uk/developer.do
http://money.usnews.com/careers/best-jobs/software-developer/salary
http://www1.salary.com/Software-Developer-III-salary.html
http://www1.salary.com/Software-Engineer-V-salary.html
http://jobsearchtech.about.com/od/careertypes/a/Software-Application-Developer-Salary.htm
Par contre le maxi est très inférieur à 250000$ dans tous les cas présentés ici.
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 0.
250K c'est le package total salaire + bonus + stocks. Je sais parfaitement qu'il existe parce que :
a) C'est ce que je gagne
b) J'ai des amis qui gagnent plus
[^] # Re: qui sait
Posté par Kerro . Évalué à -2.
Une personne qui gagne 250000$ par an vient troller sur linuxfr ? Sérieux avec ce fric va te prendre du bon temps plutôt que de prendre le chou des autres.
Avec ce salaire je paie ma maison en un an, en plus de mes dépenses habituelles, et il me reste de l'argent.
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 0.
Prendre le choux des autres ? Parles pour toi.
Quand au salaire, il est évidemment en adéquation avec le coin, l'immobilier est plutôt cher, ce qui normal quand t'as plein de gens bien payés dans la région. Si tu avais un salaire pareil tu aurais payé ton bien immobilier plus cher car les prix auraient été poussés à la hausse par les gens ayant un salaire similaire au tiens. Maintenant je vais pas me plaindre, on a la chance de faire un boulot à très forte demande, c'est pas le cas de tout le monde.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'ai un énorme doute sur les prix dont tu parles. Combien pour un F3 de 70m² dans ton coin ? (sachant qu'un américain m'avait dit qu'un appartement de moins de 100m² F4, cela n'existait pas dans sa ville); Combien pour une maison de F5 de 120m² avec 800m² de terrain ?
Un F3 bien dans ma région c'est 300k€. La maison, c'est plutôt 600/700k€.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 2.
Les F(X) je sais pas ce que c'est…
Ici a Seattle et la region, tu as des prix qui varient selon le quartier evidemment comme partout. La ou je suis (plein centre ville), j'ai un appart d'environ 100m2 (1 chambre + 1 cuisine + un coin bureau + une salle de bain, je te laisse calculer quel F ca fait :) ). Selon les quartiers de la ville et la qualite de l'immeuble/appart, un appart de cette taille ira dans la fourchette 250K-700K j'imagines. Au centre ville dans un immeuble moderne c'est du genre 500-700K.
Les maisons je suis pas trop et ca va vraiment de toutes les tailles et qualites, donc je sais pas trop comment comparer ca. Mais une maison on va dire un peu moderne, avec 3-4 chambres et pas loin de la ville, c'est minimum $600-700K, si tu la veux proche de la ville, ca augmente evidemment, et si tu es dans la commune ou habite Bill Gates(au bord du lac, que des maisons avec grand jardin, etc…), ben il n'y a rien a moins d'un ou deux million.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tes prix sont comparables aux miens (cote d'azur).
F3, c'est 3 pièces, 2 chambres plus salon (cuisine/salle de bain/WC ne sont pas compté).
A Antibes, le m² varie de 5000 à 10000€/m² en front de mer, soit le 100m² de 500k€ à 1M€. Pour les villas sur le cap d'Antibes, je ne te dis pas :) (le coin de Paul Allen)
Je parle du 06, à Paris, et les villes qui touche Paris, c'est encore plus chère (je crois que la valeur médian, c'est 7k€/m²).
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 0.
Oh je suis convaincu que Paris est plus cher que Seattle niveau immobilier (j'en viens a me demander comment autant de gens vivent la-bas vu les salaires francais). Mais j'imagines que l'enorme majorite de la France est moins chere que ca.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Disons que dans le coin le moins chère que je connaisse (entre Lyon et Saint Étienne), pour 250/300k€, tu as une maison de 120m², au lieu d'un appartement.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par windu.2b . Évalué à 6.
Facile : ils n'y habitent pas. Les gens habitent majoritairement les départements alentours (petite couronne) voire les départements un peu plus loin (grande couronne), avec les conséquences qu'on connait (qualité du logement, distance, emmerdes quotidiennes avec les transports en commun ou les embouteillages, …).
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Ou alors, il loue intra-muros ce qui permet d'économiser une voiture. ou alors, ils ont acheté autour de l'an 2000, quand les prix étaient moitié moindre.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par windu.2b . Évalué à 4.
La location à Paris, c'est pire que le parcours du combattant (cf. ce sketch de Groland : http://www.dailymotion.com/video/xa7uq_trouver-un-appartement-a-paris_fun)
Quant aux prix avant 2000, c'était certes plus "abordable", mais pas pour tout le monde, pour autant !
[^] # Re: qui sait
Posté par lasher . Évalué à 3.
Oui, j'allais dire que quand t'es en Californie et que tu gagnes (disons) 200k$/an, mais que tu paies ~2000k$/mois (le cas d'un pote qui vient d'être embauché chez Apple, à Cupertino — sauf que lui gagne ~150k$ en tant que « junior »), après les taxes et tout, il reste quand même beaucoup moins… Petit calcul : 2000 × 12 = 24k$. Il reste donc ~116k$/an à mon pote; sauf qu'en fait, il faut mettre une partie de son salaire de côté pour le 401k dont parlait PbPG plus tôt (hé oui dans son cas, y'a un plan 401K, mais il faut le soustraire de sa paie…); les impôts locaux sont très élevés; etc. Bref, la paie est bien plus élevée aux US, mais pour avoir le même niveau de « services » que ce qui est proposé en France (retraite, santé, éducation) il faut souvent payer presqu'autant que ce qui est prélevé sur le salaire côté patron. Malgré tout, un ingénieur compétent gagne plus au final que « le même » en France. Juste pas tant que ça.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Tu n'as le rapport 200k$ vs 50k€, mais il y a facilement un rapport 2 sur le salaire net.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par lasher . Évalué à 3.
Oui, et tant que tu n'as pas de problèmes de santé ni de gosses, tout se passe bien. Pour tout le reste, il y a master card: crèche (pas toutes les boites proposent quelque chose, loin de là), maternelle (souvent — toujours ? — privées), fac, santé en règle générale, etc.
Exemple à la con : une amie ingénieur en génie des procédés (elle a un bachelor of science, pas un master) bosse dans le New Hampshire. Tous les ans il faut renouveler l'enregistrement de sa voiture : 600$. On pourrait dire, « boah, c'est pas grand chose », et c'est vrai. Mais il y a aussi les impôts locaux, le loyer (elle paie ~900$/mois pour un ~50-55m²). Dans son domaine, un Master n'apporte pas grand chose, et il faut tenter le Ph.D pour voir un vrai changement dans le salaire (incidemment, c'est aussi vrai pour l'informatique dans plein de boites aux US, de nos jours — enfin de ce que je vois). Du coup quand je vois les gens parler de « tu touches Xk$ / an », souvent je pense qu'on oublie le nombre d'années passées en école doctorale, payé ~24k$/an (ici, la plupart des thésards restent au moins 5 ans).
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La vignette auto a disparu en France, c'est vrai. 900€/mois pour 55m², c'est le prix pour les villes françaises tendu, mais moins que Paris. Pour comparer, il faudrait que tu donnes son salaire net.
Je note bien l'histoire des plafonds de remboursement, qui existent même pour les "bonnes assurances", ce qui n'existe pas en France. C'est d'ailleurs bizarre de voir de très longue maladie pris en charge à 100% par la sécu. Alors qu'elle refuse de prendre en charge les lunettes ou le dentiste.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par Renault (site web personnel) . Évalué à 3.
Car ces longues maladies (cancer, diabète, autres) peuvent coûter plusieurs milliers d'euros par mois que ce soit en analyse, frais divers et traitements. Souvent le dentiste et les lunettes sont bien moins onéreux, typiquement un dentiste doit coûter dans les 30-100€ par an (et encore, les soins de bases sont bien remboursées, ce sont les gros frais qui ne le sont pas) si tu fais des visites régulières et que tu t'entretiens bien, les cas de soins à 1000€ sont souvent dus à de la négligence (mais je sais que ce n'est pas systématique).
Je pense personnellement plus important que ce soit ainsi, pour ne pas appliquer la double peine à celui qui subit une longue maladie.
L'avantage de la sécu en France, c'est que c'est comme une mutuelle mais dirigée par ses clients, si la France veut augmenter les remboursements de lunettes et du dentaire c'est possible mais dans ce cas il faudra soit réduire les coûts (en remboursant moins d'autres trucs), soit en augmentant les prélèvements. C'est un choix, personnellement je n'ai rien contre mais il faut trouver un système à l'équilibre pour que ce soit une situation pérenne.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A force de réduire les remboursements de "confort", les mutuelles sont devenu obligatoires, et la CMU a été créé. Ce qui créait un stupide fossé autour du point de ceux qui y ont droit et les autres ! Je trouve que si on a eu besoin de créé la CMU, c'est que la sécu ne fait plus assez son boulot.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par Renault (site web personnel) . Évalué à 2.
Je ne suis pas en désaccord avec toi, je suis en soit pour un remboursement intégral des frais médicaux pour tous.
Après il faut bien sûr trouver un modèle économique viable pour que ce soit possible, j'ignore si ça l'est de manière raisonnable. Si on veut plus de remboursement il faudra plus prélever, c'est inévitable (et certains, pas forcément quelqu'un ici en particulier, l'oublient…).
Il peut être aussi possible d'être plus raisonnable dans la dépense sans aller dans la réduction de service, il faut optimiser (frais administratives, aller voir le médecin ou l’hôpital quand c'est vraiment nécessaire, favoriser les soins légers dès le début plutôt que d'attendre la catastrophe onéreuse à soigner…).
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"favoriser les soins légers dès le début plutôt que d'attendre la catastrophe onéreuse à soigner…"
Oui mais la sécu rembourse peu les petit soin et beaucoup les soins lourds.
J'avais entendu une fois une émission qui parlait de la gestion des hopitaux. En général, le doyen est un médecin et pas un gestionnaire. Ils ne font pas (faisaient pas ?) de comptabilité analytique. Il n'avait donc aucun idée des dépenses d'un service en particulier, et encore moins si elles étaient justifiés ou pas.
J'ai beaucoup d'espoir dans le big data et l'open data pour trouver des solutions innovantes.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par Renault (site web personnel) . Évalué à 2.
Ah bon, tu as des exemples ?
Typiquement dans le dentaire c'est vraiment l'inverse, le détartrage voire la carie sont bien pris en charge mais la couronne tu peux rêver.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour les lunettes, les grosses corrections sont mieux pris en charge que les légères.
L’arrêt du tabac est pris en charge à hauteur de quelques centaines d'euros, alors que 100% d'un cancer des poumons ou de la gorge est pris en charge.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par Renault (site web personnel) . Évalué à 2.
Le problème c'est que tous les cancers du poumons et de la gorge ne sont pas liés au tabagisme (ou il peut être du à un tabagisme passif), on ne peut pas trier les patients.
Je n'y connais rien dans le domaine. Après ça peut avoir une explication (coût plus faible ?).
C'est typiquement le genre de choses qu'on pourrait facilement corriger, si le peuple le veut.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si j'ai bien compris on a 46% du pib pris par les prélèvements obligatoires, et 54% de dépense. La différence est prise par la dette.
Certain économise pense qu'il y a une point d'équilibre vers 60% de prélèvement obligatoires. Par contre, cela veut dire que l'état prendre en charge encore plus de chose ? (flexi sécurié aussi pour les entreprises ? Guichet unique ? formation tout au long de la vie ? financement des syndicats comme pour les partis politiques ? rapprochement des contrats de travail public/privé ? etc…)
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par Zylabon . Évalué à 2.
− Prendre l'argent là où il est
− Ne pas subir les politiques commerciales des labos (rien que ça…)
− Ne plus engraisser les cliniques privées en laissant les hôpitaux se délabrer
Please do not feed the trolls
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à -2.
Le probleme de sante est dur lorsque tu perd ton job a cause de cela, mais le cout du traitement normalement l'assurance le prend en charge totalement avec les assurances que les boites technologiques ont et normalement ton job t'offre une assurance pour cela qui te paie genre 80% de ton salaire pendant un an.
Pour les couts medicaux, il y a le plafond de base que tu dois payer (genre 1000-1500$ par an) mais l'assurance couvre tout le reste normalement, sauf si tu choisis le plan medical qui ne couvre que genre 90% pour economiser $10/mois, ce qui serait stupide…
Au hasard il y a 5 ans je me suis perfore un poumon en snowboard, et j'ai paye 0 sur les $11'000 de l'hospitalisation (a l'epoque MS n'avait pas le plafond de base). Aujourd'hui je paierais $1000. Alors oui les couts de la sante sont totalement dingues ici, c'est une vraie arnaque, mais les employes techs sont en bonne partie isoles de cela.
Pour le reste, moi je paie $60/mois pour 100Mo/s , je pourrais avoir 1Gb/s pour $100/mois mais je n'en ai evidemment aucun besoin. Les telephones c'est effectivement une vraie arnaque.
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il y a un plafond au dela duquel l'assurance ne te suit pas, ou est-ce que tu as une franchise à payer ? C'est très différent par rapport aux risques financiers.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à -3.
Dans mon cas, je paie les premiers 1000$, l'assurance paie tout ce qui suit, et paie aussi 100% du preventif.
Mon assurance dentaire couvre 85% pour les petits incidents (plombage…) et 50% pour les gros jusqu'a maximum $1500 par an
[^] # Re: qui sait
Posté par ckyl . Évalué à 4.
Tu sais que le pré-condition n'est pas requise ?
Je ne vois pas ce que le salaire change. Si poster ici c'est de la merde, bha c'est de la merde gros salaire ou smic…
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
On m'a dis que pour comparer le niveau de vie France/US, il fallait prendre 1€=1$ pour les prix de la vie de tous les jours.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 3.
Pas convaincu… la (bonne) bouffe m'a toujours semblee moins chere en France. Le McDo est certainement moins cher aux US, mais si tu aimes manger decemment, j'ai toujours eu l'impression que la France etait plus accessible (viande a part).
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En Paca, tu manges bien à 30€/personne sans vin, tu manges très bien pour 40€, et au dessus, cela n'a plus trop de limites. La bouteille de vin revient souvent au prix d'une personne à ajouter pour 3 ou 4.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à -1.
Dans un 'bon' resto ici, ton plat principal est a 16-28$, le verre de vin a 8-X $ , une entree a 5-15$, etc… tu additiones, tu rajoutes 18-20% de tip et environ 9% de taxes…
Bref, tu veux bien bouffer, c'est facilement 60$
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Fait le calcul, sans vin, cela revient à 40$ (en prenant (20$+10$)*1.2*1.09).
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à 3.
L'Americain moyen n'est pas developpeur, je parles bien evidemment de ce microcosme en particulier. Si t'es caissier a Champion, je te suggeres de rester en France, ta vie sera bien meilleure.
[^] # Re: qui sait
Posté par Batchyx . Évalué à 10.
Ce n'est pas ça que tu évalue lors d'un entretien d'embauche. Ce que tu évalue est une personne stressée qui est potentiellement au chômage en crevant la dalle, qui va se retrouver en face d'un pair qui va plus préjuger que juger, sur des critères totalement différents à la fois sur le résultat et la démarche, et auquel il est plus ou moins malvenu de poser des questions.
Au final, celui qui s'en sortira le mieux c'est le beau mâle blanc valide du même age que le recruteur, avec le moins de problème, le plus à l'aise et qui n'est pas trop mauvais techniquement, et sans doute déjà en poste. En gros, le mec qui avait le moins besoin du job.
Si tu considère qu'un entretien d'embauche c'est la même chose qu'un entretien avec des clients, ou que la personne auquel tu fait un entretien d'embauche se comporte de la même manière que si il était hors période d'essai, t'est mal barré.
Avec certains recruteurs, si tu commence à discuter ou à poser des questions, c'est déjà fini pour toi. T'est censé répondre aux questions et c'est tout, il à des cases à remplir (mais tu va pas scruter ce qu'il est en train d'écrire, ça serait impoli).
Si tu t'attend à ce que le mec te pose la question "qu'est ce que vous attendez de moi ?", alors fait lui bien comprendre que tu n'est pas le recruteur sadique qu'ils ont vu juste avant avec qui ils ont foiré leur entretien. Et non, le mettre à l'aise n'est pas suffisant, ça, le recruteur d'avant l'a fait mieux que toi.
Alors le mec est obligé de deviner tes intentions sans pouvoir poser de questions. C'est difficile, et c'est normal que tes candidats se trompent. Et va pas leur dire que c'est de leur faute.
[^] # Re: qui sait
Posté par pasBill pasGates . Évalué à -2.
On va dire que t'as fait tes interviews dans la mauvaise boite…
Ce dont ckyl parle est exactement ce qui se passe chez MS (et dans leurs succursales, ainsi que chez Google et ses succursales et plein d'autres notamment)
[^] # Re: qui sait
Posté par Batchyx . Évalué à 8.
C'est pas comme si je pouvait choisir dans quelle boite je fait mes interview. J'ai juste le choix de là ou je postule.
[^] # Re: qui sait
Posté par ckyl . Évalué à 4.
Je me fou de qui a besoin du job. Ce qui m'intéresse c'est d'avoir quelqu'un qui est capable de le faire bien.
C'est bêtement offre/demande. On travail dans domaine ou il est facile de se former, d'évoluer et de prouver ce qu'on sait faire. Il suffit de se sortir les doigts. Quand je vois des mecs 6 mois en intercontrat qui préfèrent aller sur youtube plutot que de se former ou de pousser sur github, tu te dis que les gens sont juste stupides…
Je n'ai jamais supposé ca.
Le but c'est de deviner si le mec à des compétences techniques, un cerveau qui marche et l'attitude qui va avec. C'est l'objectif. Après personne n'a le filtre magique.
Mais note que les deux derniers critères impliquent que ne soit pas un robot en entretient et soit capable de s'interroger sur ce qu'on lui demande. On passe pas le bac…
Bha tu te casses et tu t'en fou par ce que tu veux pas bosser chez eux.
[^] # Re: qui sait
Posté par totof2000 . Évalué à 3.
Ton job ca va être d'analyser et de comprendre. De discuter avec le business pour deviner ce qu'ils attendent. La tête dans le guidon à un entretient ? Ca va donner quoi le jour où tu troobleshoot la prod qui s'est écrasé, que tu dois concevoir des hotfix, ou que tu vas gérer la direction d'un produit ? Ce qu'on cherche c'est justement des gens qui n'ont pas la tête dans le guidon.
Dans ce cas, ne te focalise pas sur le langage : demande un mec capable de faire de l'analyse. assure-toi pour ton test qu'il a bien analysé et structuré le problème. Après, le langage ce n'est pas le plus important : on s'y adapte.
[^] # Re: qui sait
Posté par ckyl . Évalué à 6.
Qui a dit que c'était le cas ?
Tu as 10000 approches possibles. De entrient code Google où t'es au white-board avec un homme-machine qui trouve tes typos plus vite qu'un compilo. A celui qui en fait veut juste voir si comment tu fais tes choix et que tu as grosso modo le niveau. D'ailleurs la plupart des boites font différents type d'interview.
Je n'arrive pas à comprendre comment vous pouvez émettre des jugements sans aucune information. J'ai passé des dizaines d'entretiens et y'en a pas un qui se ressemblait. Certains étaient mauvais, d'autres excellents; mais sans le vivre je serais incapable de prédire si c'est bon ou mauvais.
Le seul point commun aux bons était que les mecs étaient la pour trouver un mec avec lequel ils avaient envie de bosser, et non pas de piéger les gens. Ca donne des discutions intéressantes pour les deux personnes. Ceux où j'ai appris le plus de choses sont ceux ou j'ai été refusé. Et j'ai appris des choses à des gens qui m'ont refusé. L'entretient n'est pas un examen. Si tu pars avec cette idée de quelque côté que tu soit du bureau, ca me semble un mauvais départ.
[^] # Re: qui sait
Posté par totof2000 . Évalué à 3.
Je crois que je réponds à la mauvaise personne, En fait j'ai l'impression que le posteur initial se focalise trop sur la maîtrise du langage, alors que si je lis ses propos, j'ai l'impression que ce n'est pas tant d'un développeur PHP faisant du beau code dont il a besoin. a la limite, vu l'historique dégueux de PHP sur la "beauté" de code, je pense qu'il n'a même pas besoin d'un développeur ayant une longue expérience en PHP et trainant avec lui toutes les tares anciennes du langage, mais de quelqu'un ayant moins d'expérience dans ledit langage, mais sachant analyser les problèmes et structurer son code.
Sinon, je ne juge pas, j'exprime juste ce que je ressens et ce que j'entrevois à partir des propos exprimés par le posteur initial. Mais là je me suis trompé de personne, désolé.
[^] # Re: qui sait
Posté par KAeL . Évalué à 3.
et tu serais prêt à prendre quelqu'un qui ne teste pas ce qu'il code ?
comme lu précédemment, un autre candidat aurait pu faire un code qui te semblerait moins joli mais qui aurait le mérite d'être testé et de fonctionner
[^] # Re: qui sait
Posté par adonai . Évalué à 4.
Mais ce que j'ai pris en compte, c'est la façon de penser de la personne.
Tu arrives à comprendre la façon de penser d'une personne et à la cibler à partir de seulement un entretien et un test de 3h ?
Tu as un vrai don, tu devrais essayer d'en profiter un peu plus, je suis sûr que ça doit pouvoir servir l'humanité :)
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Il y a beaucoup de dev qui se font recruter sans aucun test, ce qui est bien pire.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par Batchyx . Évalué à 4.
Ça dépend pour qui.
[^] # Re: qui sait
Posté par max22 . Évalué à 2.
ouais, j'ai du mal à comprendre ça…
[^] # Re: qui sait
Posté par Gof (site web personnel) . Évalué à 1.
Donc en gros tu préfère un truc qui ne fonctionne pas ?
Mouais, l'important c'est d'avoir un truc qui marche, pas d'avoir un truc « souple et générique », en particulier quand cette fameuse généricité rends les choses plus compliqué que ce qu'elle ne devrait l'être.
À lire aussi: http://sebastiansylvan.com/2013/08/16/the-perils-of-future-coding/
[^] # Re: qui sait
Posté par Snarky . Évalué à 2.
Pour le poste de lead, oui. Son rôle est justement de s'occuper de la relecture des commits, d'organiser globalement le code pour pas que ça parte dans tous les sens, et de faire les mises en prod.
Pour le pissage de code fonctionnel, il y a une équipe de dev.
[^] # Re: qui sait
Posté par Julien Jorge (site web personnel) . Évalué à 5.
J'ai aussi eu l'occasion d'organiser des entretiens d'embauche et j'ai eu le même sentiment que l'auteur du journal. À l'opposé, j'ai aussi passé des entretiens dans des domaines ou je pensais avoir un niveau moyen et où j'ai appris que mon niveau était plutôt débutant. À mon avis quand il parle de code dégueu, c'est plus pour soulever l'absence de sensibilité du candidat à bien présenter son code et à se faire comprendre, plutôt qu'une simple histoire de goût.
Justement, quand je fais un entretien j'attends du candidat qu'il soit ouvert sur le style et la façon de travailler. Tous les projets sur lesquels j'ai travaillé avaient des conventions différentes (présentation, commentaires, flux de travail, etc.) et la seule chose qui était commune était que chacun avait la volonté de produire un code clair pour les autres. C'est exactement ce que je veux voir en entretien : quelqu'un qui ne s'arrête pas dès que ça marche, mais qui fait attention à être cohérent avec le code qui l'entoure ; quelqu'un qui sait me donner une estimation juste de son temps de travail, et non pas pour avoir un truc qui marche et qu'il ne reste plus qu'à finir.
Sans savoir précisément la quantité de travail que représente l'exercice proposé par l'auteur, je peux néanmoins t'indiquer que dans mon cas les exos sont très très courts, comme une recherche sur une propriété des objets d'une liste. Ça me demande même plus de temps d'écrire l'énoncé que d'implémenter la solution. Pourtant ça permet déjà de bien filtrer entre les solutions fausses, les recherches en n², les recherches qui utilisent simplement les fonctions déjà présentes dans le fichier… Bref, avant que je file du vrai boulot au candidat il faut déjà qu'ils aient les bases.
[^] # Re: qui sait
Posté par ckyl . Évalué à 8. Dernière modification le 20 novembre 2013 à 22:36.
Non. J'ai le même constat que lui. 80% des mecs qui poussent la porte avec "senior" arrivent à leur limite quand tu leur demande de faire la différence entre overriding et overloading, la différence entre passage par valeur et par référence ou autre trivialité sans aucun piège. Bref niveau première année d'étude.
Et le code qu'ils écrivent est en adéquation. Il n'y a rien de subjectif la dedans. Ils ne devraient même pas être autorisé à toucher un clavier. Le truc le plus étonnant c'est qu'au final ils trouvent un taff… Le niveau en informatique est ridiculement bas pour un salaire relativement élevé…
Heu tu peux déjà lever le salaire du triplet, en général ça commence à se discuter après. Avant soit t'es à l'aveugle, soit la fourchette est tellement large qu'elle ne veut rien dire.
Oui bien sur, ça coûte vachement moins cher et c'est mieux de se faire chier à organiser des interviews pour faire pisser du code critique à un mec que t'as jamais vu que de payer un freelance pour une journée…
Merde j'ai du me faire exploiter par les boîtes qui demandaient grosso une bonne journée de boulot pour un mec bon, simplement pour décrocher son billet d'avion et rentrer dans le processus d'interview. Je suis sur que le code est maintenant au cœur de leur infra. C'est absolument impossible qu'ils s'en servent pour filtrer les mecs qui n'ont rien à faire là et se consacrer sur ceux qui ont quelque à offrir…
Si t'es un peu moins con que ce que tu veux montrer, et que tu avances des arguments cohérents, y'a même une chance que ca joue en ta faveur… Comprendre ce que le mec veut voir et ouvrir la discussion dans cette direction.
En général on demande juste des gens techniquement compétents, qui sont capable d'analyser et de comprendre les problèmes (rare) et d'apporter des solutions adaptées à ces problèmes, ni plus ni moins (très rare).
[^] # Re: qui sait
Posté par hervé Couvelard . Évalué à 10.
je ne suis pas moins con que ce que je veux montrer.
Mais je suis certain que le php objet à pour seul objectif d'ameuter du dev qui vient de java et passer dans la "cour des grands" car ceux qui ont l'impression de tout savoir savent que ceux qui font pas d'objet sont des brelles.
Parce que c'est vrai : un objet client, qui a un objet compte, qui a un objet opération, qui a un objet transactions, qui a un objet montant qui a un objet debit_credit c'est achement mieux en terme de tout (à chaque chargement de la page, il faut charger tous les objets en cascade) que juste une fonction insère débit avec le compte en variable de session pour un panier par exemple.
D'ailleurs ce paradigme objet encapsulé dans des trucs, encapsulés dans des trucs encapsulés dans des trucs, c'est ce qui a imposé à ovh de changer toute son infra juste pour les blog à 2 balles en wordpress de ses clients.
Et, il y a pas que des brelles, les personnes qui travaillent chez l'un, lorsqu'elles postulent pour travailler chez l'autre, ca doit être des tueurs, vous devez les payer des millions si le niveau général est aussi bas pour les garder chez vous.
[^] # Re: qui sait
Posté par windu.2b . Évalué à 8.
Seulement 100 avis différents ? Moi, j'aurais dit plus. Ou pas. Si, plus. T'es sûr ? Ouais, plus.
# Même avis…
Posté par Nahuel . Évalué à 2.
Oui, je suis du même avis… Les gens se disent "expert" parce qu'ils ont passé 10 ans à faire du PHP procédural ET dégueulasse et ils se pointent en entretien. Sauf que nous on offre un salaire de "merde", donc ça ne m'étonne pas (fonction publique oblige) ;)
Mais il est évident que beaucoup de développeurs se croient "capable" de bosser dans des contextes poussés (genre haute dispo par exemple) avec leur bagage dans une petite boite de comm' qui fait les sites web pour les petites boutiques de leur patelin, et ils se présentent comme très compétents avec pleins de noms techniques sur leur CV, alors que lorsqu'on pousse, ils ont juste "testé un jour".
Bref… c'est dur de trouver de bons développeurs, et le meilleur moyen que j'ai pu voir c'est le cooptage: machin connait bidule qui connait truc qui cherche un boulot et en plus est un bon dev.
Bon courage à toi pour le froid cet hiver ;)
[^] # Re: Même avis…
Posté par Nahuel . Évalué à 5.
J'ai oublié de dire, c'est aussi le boulot du lead dev de pousser son équipe vers le haut et de la faire avancer techniquement. Tu peux partir avec une équipe de débutants et les faire évoluer très rapidement si tu prends des gens qui aiment apprendre et évoluer. Et en général c'est un bon investissement, encore faut-il avoir le temps de les former, la motivation, et faire le bon choix de qui t'embauche.
# FizzBuzz
Posté par rakoo (site web personnel) . Évalué à 10.
Ah, tu viens de comprendre que le CV n'est rien d'autre qu'une plaquette promotionnelle vérifiée par personne si ce n'est l'embaucheur officiel ? Bien, te voilà entré dans un monde plein de surprises !
Le problème des Expert PHP/Perl/Java/C/C++/ complètement faux sur les CVs n'a rien de nouveau, et les tests basiques de coding n'ont rien de nouveau: le fameux test de FizzBuzz (ou, en tout cas, un test dans le genre) permet d'éliminer une grande partie des candidats. Tu as inventé ton propre test, et tu en es arrivé aux même conclusions, il est juste dommage que tu le découvres aujourd'hui !
J'ai juste une petite remarque sur ton test: Est-ce que les candidats n'ont pas passé une grande partie de leur temps sur le déchiffrage de vCard ? C'est un format très utile et très utilisé, mais pas connu de nombres de développeurs (de la même manière qu'à peu près tout le monde sait comment marche DNS, mais en proportion très peu savent à quoi ça ressemble dans les tuyaux). Bon, ça n'excuse pas d'écrire du code dégueulasse, mais ça peut faire perdre du temps pour rien. Si vraiment tu veux garder le même test, je pense qu'il serait pas mal d'utiliser un format plus connu, même fictif (allez, pourquoi pas JSON), histoire de voir les gens se pencher sur la logique.
Si tu fais du logiciel open source/libre, qui a pour principale valeur la qualité technique, tout le monde ici s'accordera à dire que les gens comme toi sont bien. On est des artisans, on aime le travail bien fait. Si tu fais du logiciel en vue de gagner ta vie, là les choses sont complètement différentes: le client est là pour un logiciel qui marche, pas pour un joli logiciel. Tu ne peux pas forcément lui reprocher ça, parce qu'il n'a pas forcément le temps ni l'envie de savoir comment déterminer si un logiciel et bien fait ou pas, donc il ne peut pas savoir si le code est dégueulasse (surtout s'il n'a pas accès au code). C'est là la principale différence, et tant que la grande majorité de la population n'aura pas une connaissance poussée dans le développement logiciel et l'accès aux sources, ça ne changera pas.
[^] # Re: FizzBuzz
Posté par hervé Couvelard . Évalué à 8.
il y a un autre truc : quel est l'utilité de faire un beau code (en doublant le temps de travail) sur une fonctionnalité qui va servir 4 fois par an à 3 personnes, sur une machine qui iddle 99.99% de son temps avec une pointe à 2% processeur ?
[^] # Re: FizzBuzz
Posté par Anonyme . Évalué à 4.
éviter les merdes lors d'une mise a jour de sécurité ?
[^] # Re: FizzBuzz
Posté par rakoo (site web personnel) . Évalué à 5.
C'est quoi une mise à jour de sécurité ? Le truc qui arrive tous les 5 ans quand la licence Windows expire ?
Tu n'imagines pas le coût d'une mise à jour système (ou même application) par rapport aux gains supposés. Si l'application n'est pas critique ou est très peu utilisée, il est difficile de justifier un passer du temps (donc de l'argent) pour quelque chose qui n'apporte rien de mesurable.
Encore une fois, il ne faut pas confondre le monde technique et le monde de l'entreprise: le premier veut faire du bon techniquement, le deuxième veut faire du profit. Parfois les 2 se rencontrent, mais ça reste assez rare pour qu'on entende parler des cas qui sortent du lot.
[^] # Re: FizzBuzz
Posté par hervé Couvelard . Évalué à 1.
quelle est la probabilité qu'une merde arrive parce que la recherche est pas optimale, ou que la fonction met 2 fois plus de temps qu'une autre ?
J'ai un peu de mal, en php de voir un code merdique entraîner les merdes lors d'une mise à jour de sécurité.
[^] # Re: FizzBuzz
Posté par ckyl . Évalué à 9.
Du beau code c'est du code qui fait le job en ayant la complexité minimale correspondant aux attentes business… C'est pas du code fait pour se palucher.
[^] # Re: FizzBuzz
Posté par Jean B . Évalué à 6.
Je dirais même plus, c'est du code qu'on aura pas besoin de jeter intégralement quand les gens du produit aurons changé d'idée pour la ennieème fois.
Oui les entreprises recherchent avant tout la valeur, mais la valeur à court terme ne fait pas tout.
Pour l'auteur: Je te conseille de chercher un emploi chez un éditeur, ou un poste R&D, tu verra que les notions de maintenabilité sont beaucoup moins souvent poussées sous le tapis que dans les sociétés de service.
[^] # Re: FizzBuzz
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
J'ai failli recracher mon café par le nez, je ne te remercie pas!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: FizzBuzz
Posté par Jean B . Évalué à 3. Dernière modification le 21 novembre 2013 à 15:40.
Peux être as-tu un commentaire constructif à opposer ?
[^] # Re: FizzBuzz
Posté par Snarky . Évalué à 5.
C'est ça l'erreur, en pratique, je vais minimum aussi vite qu'un code "normal", voir plus vite dans la majorité des cas. Certainement parce que j'ai l'habitude de faire de cette façon.
Là ou se situe la grande différence, c'est dans la maintenance. Certe, si c'est vraiment un truc isolé, je suis d'accord que l'utilisé est minimal, mais dans une conception plus globale, la maintenance est extrêmement facilité si il doit y avoir des modifications, suite à des bugs, ou des évolutions.
[^] # Re: FizzBuzz
Posté par hervé Couvelard . Évalué à 10.
moi avec l'age que j'ai je me méfis toujours de ceux qui ont toutes les réponses, qui savent ce qui est bon et ne se pose pas de question.
Moi je n'ai pas de réponses (car il n'y en a pas) mais il y a une palette de sensibilité aussi large qu'il y a de personne.
Dire je vais minimum aussi vite en faisant un beau code qu'un code "crade" je demande à voir.
Parce que tu vois, rien que pour l'insertion dans la base de donné :
1 - on peut décider d'insérer sans se poser de question : "insert into",mysql_query, 5 secondes.
Mais on peut aussi vérifier que ce que l'on insère est du bon type
faut du temps, parce qu'on doit faire une fonction à qui on passe le type et la valeur. pour faire cette fonction on a une foule de manière de faire, par exemple on peut fabriquer un tableau des paires champs-type et on passe le post au crible de ce tableau, mais vérifier pour les numéros de tel ou des références de pièces c'est pas si évident.
on peut juste passer chaque élément à la fonction avec le type qui est attendu et si aucune erreur faire l'insertion, sinon redemander.
Ensuite on peut vérifier qu'il n'y a pas de problème ou tentatives unsécure
on peut enlever les caractères bizarres
on peut vérifier qu'il n'y a pas de javascript pour les commentaires qui vont s'afficher dans des pages,
on peut vérifier que c'est une image et pas un exécutable….
Il y a des tonnes de choses que l'on peut vérifier suivant le niveau de code que l'on veut.
Et si tu arrives à coder aussi vite toutes ces vérifications que moi je vais un mysql_query("insert bla"), effectivement tu es sous payé.
[^] # Re: FizzBuzz
Posté par SigNix . Évalué à 1.
A tout hasard je dirais qu'une requête paramétrée serait déjà un bonus pour une complexité identique dans le cas d'une requête directe en BD. Les ORM existent aussi…
[^] # Re: FizzBuzz
Posté par hervé Couvelard . Évalué à 2.
A tout hasard est-ce que tu pourrais l'écrire ?, en autant de temps que mon mysql_insert("insert into blablabla");
oui on peut aussi utiliser des classes toutes faites, mais ce n'est pas ce qui était dit, on peut aussi réutiliser son code, mais ce n'est pas le contexte…
[^] # Re: FizzBuzz
Posté par flagos . Évalué à 7. Dernière modification le 21 novembre 2013 à 11:06.
Disons qu'entre ca:
Et ca:
Alors, je ne suis pas un specialiste php, mais il me semble que c'est déja une bonne protection contre les injections SQL. Et je trouve que ca ne coûte pas cher et que c'est bien le minimum pour quelqu'un qui prétend avoir une quelconque expertise en php.
Et, sincèrement, je trouve même que la première écriture plus compliquée à écrire et à lire car il faut bien mettre les échappements et les ' la où il faut..
[^] # Re: FizzBuzz
Posté par Marotte ⛧ . Évalué à -2. Dernière modification le 21 novembre 2013 à 11:17.
Je ne vois pas en quoi (mais moi non plus je ne suis pas un expert).
Dans les deux cas le contenu de $_GET['possesseur'] n'est pas vérifié et peut contenir n'importe quoi…
À moins que le fait de le passer par la fonction array() empêche l'injection ? Comment ?
[^] # Re: FizzBuzz
Posté par windu.2b . Évalué à 3.
Non, c'est la fonction
executequi nettoie les variables reçues en entrée, avant de les placer dans la requête et d'exécuter cette dernière.La fonction
arrayest là pour créer un tableau à partir des valeurs (ici, une seule) qui lui sont passées en paramètre.[^] # Re: FizzBuzz
Posté par flagos . Évalué à 4.
C'est la fonction execute qui empeche l'injection.
[^] # Re: FizzBuzz
Posté par yohann (site web personnel) . Évalué à 2.
C'est plus la requête préparé qui empêche l'injection sql (ou du moins qui offre une bonne protection contre), le moteur de bdd est ainsi conscient que ce qui est envoyé dans
executeest le contenu de la colonne et non pas des bouts de requete sql, qui ne seront du coup pas interprétés par le moteur sql de la bdd.Cependant, il est indiqué dans la doc php, que les requêtes préparées sont surtout utiles pour gagner du temps d’exécution si une requête doit être exécutée plusieurs fois (sur une requête simple, une grosse partie du temps de traitement est le parsage de la requête). Cela dit, je n'ai jamais trouvé (ou entendu parlé) d'exploit sql sur une requête préparée mais je ne suis pas un expert en sécu non plus.
bref: les requêtes préparées ne sont pas conçues pour protéger des injections, mais elle offre par la bande une (très) bonne protection contre ces attaques au prix d'un traitement plus long (dans le cas d'une seule requête).
[^] # Re: FizzBuzz
Posté par Thomas Douillard . Évalué à 1. Dernière modification le 21 novembre 2013 à 12:11.
Tu oublies le "execute" dans ton analyse, c'est probablement lui qui fait les échappements qui vont bien.
[^] # Re: FizzBuzz
Posté par Thomas Douillard . Évalué à 5.
Bon, forcément je ne suis que le 12ème à le signaler, vive les oeufs de pâques !
[^] # Re: FizzBuzz
Posté par chinoisfurax . Évalué à 1. Dernière modification le 22 novembre 2013 à 09:48.
Comme le dit Yohann, c'est en réalité parce qu'une requête préparée est compilée et qu'on lui passe des arguments ensuite. Le fait qu'elle soit compilée avant d'être exécutée fait que sa structure n'est plus modifiable au moment où on l'exécute, donc qu'on ne peut plus faire d'injection SQL dessus.
EDIT: et ça explique également pourquoi l'exécution (après compilation) est plus rapide et qu'on puisse réutiliser la requête préparée plusieurs fois avec différents arguments.
[^] # Re: FizzBuzz
Posté par hervé Couvelard . Évalué à 0.
je dois être très rouillé, mais il me semble comprendre qu'entre
et
il y a une différence : toute la partie de code caché par $bdd.
sinon je peux faire aussi, encore plus rapide
liste(nettoie($_GET['possesseur']))
[^] # Re: FizzBuzz
Posté par flagos . Évalué à 3.
Et quel est le problème avec ca ? Il vaut mieux réutiliser une lib adaptée à l'usage plutôt que de présenter un code vulnérable aux injections non ? Ou encore pire, passer 1 heure à coder des regexp (potentiellement troué) pour détecter une injection alors que l'exercice n'est pas la dessus.
Et quelle est cette fonction nettoie ? (Je connais très peu php)
[^] # Re: FizzBuzz
Posté par Kioob (site web personnel) . Évalué à 2. Dernière modification le 21 novembre 2013 à 11:57.
Pour aller jusqu'au bout :
premier cas :
second cas :
Y a rien de "caché".
alf.life
[^] # Re: FizzBuzz
Posté par hervé Couvelard . Évalué à -1.
Je n'ai pas de problème avec les libs, je dis juste que l'on ne parle pas de la même chose.
Dans un cas on fait des requêtes dans l'autre on envoie des info à une lib qui fait des requêtes.
ce qu'il y a de caché ? ben… tout le code dans PDO peut être
[^] # Re: FizzBuzz
Posté par Kioob (site web personnel) . Évalué à 3. Dernière modification le 21 novembre 2013 à 12:27.
PDO n'est pas une "librairie" externe, c'est une "API" standard de PHP, fournie de base, cf http://fr.php.net/manual/en/mysqlinfo.api.choosing.php
Au contraire de "mysql_" d'ailleurs, qui est «deprecated» : http://fr.php.net/manual/en/intro.mysql.php
Ces quelques lignes de code fonctionnent d'entrée de jeu, sans rien charger de plus.
alf.life
[^] # Re: FizzBuzz
Posté par hervé Couvelard . Évalué à 0.
Cela fait plus de 5 ans que je n'ai pas écris de code php. Ce que je vois dans la page de doc c'est que tout devient de l'objet pur.
Et c'est, de mon point de vue, en environnement web, pas aussi intéressant qu'on le dit. Je ne suis pas non plus persuadé que "The overall performance of all three extensions is considered to be about the same". On sait que monter des objets en mémoire n'est pas neutre. On sait que dans un script d'accès à la base de donnée, la partie la plus lente est d'obtenir une connexion (ce qui a vu naître les _pconnect), donc oui la performance (y compris l'empreinte mémoire ?) est secondaire. Mais lorsque l'on voit des pages d'un wordpress (php/myql) mettre plus de 8 secondes à arriver dès que l'on parle de select en base, on peut se poser la question de l'intérêt : les serveurs sont plus puissants en proc et mémoire et c'est toujours aussi lent. mais bon je m'en moque dans l'absolu.
Cela ne n'est pas important, si demain je voulais reprendre à coder, et en php, je rachèterais le bouquin avec toutes les fonctions et je le re-lirais entièrement avant de coder.
[^] # Re: FizzBuzz
Posté par Kioob (site web personnel) . Évalué à 2.
PDO est une interface full objet oui. Mais si tu optes pour mysqli, tu as le choix entre l'objet et le procédural.
Pour ce qui est d'établir la connexion, ce n'est justement pas le cas avec MySQL qui se connecte très rapidement (environ 2ms de manière générale, voir moins).
D'après ce que j'ai pu constater si les Magento et autres sont si lents/gourmands, c'est à cause de leur non-utilisation du SQL : plutôt que de faire des jointures, ils font une miriade de requêtes SQL (facilement des centaines par page) et "assemblent" les objets directement dans le code. Qu'ils utilisent mysql_*(), mysqli ou PDO n'aurait probablement aucun impact sur les performances ici : elles sont déjà catastrophiques.
Il parait que ça rend le code hyper souple…
alf.life
[^] # Re: FizzBuzz
Posté par GG (site web personnel) . Évalué à 2.
J'ai déjà eu du Wordpress sur mon serveur dédié.
Je me suis juré de ne plus jamais héberger du Wordpress, à cause de la consommation de ram et de CPU même pour des trucs simple.
Je crois que c'est la conception de Wordpress qui n'est pas correct, et aussi que beaucoup pensent que c'est un CMS alors que ce n'est qu'un truc pour faire des blog.
Autant utiliser Dotclear. Il y a moins de failles de sécu aussi.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: FizzBuzz
Posté par Le Gab . Évalué à 1.
Au sujet du Fizzbuzz, une opinion intéressante et honnête d'un architecte technique qu'on va dire assez "crédible".
# Je me fais l'avocat du diable
Posté par MTux . Évalué à 10. Dernière modification le 20 novembre 2013 à 21:02.
Ton expérience est intéressante, mais il faut voir que de l'autre côté de la barrière, c'est à dire en tant que chercheur d'emploi, tu es obligé d’embellir ton CV et mentir sur tes compétences. Pourquoi ? Parce que beaucoup de boites passent par des intermédiaires, qui sont là pour faire rentrer les gens dans les cases. Tu peux être le meilleur développeur du monde, prêt à tout apprendre, tu peux très bien te faire exclure parce que tu ne maîtrises pas un des langages mentionnés dans la fiche de poste. En temps normal tu aurais pu l'apprendre, malheureusement le recruteur n'est pas technicien et va considérer que tu n'es pas apte.
J'ai l'impression que c'est typiquement français, des collègues expatriés que je connais changent de boite presque tous les mois et pourtant ils ont débuté leur métier en autodidacte.
[^] # Re: Je me fais l'avocat du diable
Posté par Anthony Jaguenaud . Évalué à 6.
Pour continuer à faire l’avocat du diable. Je pense que quand tu l’as réalisé en 1h40, tu connaissais déjà la structure d’une vcard, tu avais déjà réfléchie plus ou moins consciemment que tu devrais le faire, leur donnes-tu la structure de la base de donnée ? Doivent-ils la choisir ?… ne néglige pas ce temps là, que tu as fais en amont sans même t’en rendre compte. Et puis il y a ceux qui perdent leur moyen en cas d’examen.
Après, il y a une période d’essai faite pour ça aussi.
[^] # Re: Je me fais l'avocat du diable
Posté par Snarky . Évalué à 2.
Non, comme j'ai dis sur une autre réponse, c'est issu une demande d'ami, que j'ai rendu 2h après. J'ai appris le format sur le tas. De plus, j'explique rapidement le format aux candidats pour pas qu'ils y passent trop de temps (pas plus de 10mn, normalement). C'est l’intérêt d'avoir pris un format simple.
[^] # Re: Je me fais l'avocat du diable
Posté par Batchyx . Évalué à 10.
vCard ? Format simple ? On parle bien du même là ?
On parle bien du format avec 3 version différentes avec 3 grammaires incompatibles entre elles (et ne parlons pas de la réunion des trois), dont une (2.1) ou le numéro de version peut se trouver n'importe ou (y compris à la fin) ? ou l'encodage peut changer n'importe quand, et ou l'encodage par défaut dépend du contexte (ex type MIME quand c'est attaché à un mail) ? Ou un peut mettre une vCard 2.1 entière dans une propriété AGENT d'une autre vCard 2.1 (ça sert à renseigner le secrétaire d'une personne) ? Avec des extensions sauvages d'organismes indépendants ? Avec plein de fonctionnalités à la sémantique non définies que personne n'utilise mais que le format t'impose de gérer quand même ? Ou la version la plus utilisée (2.1) est la plus pourrie ?
[^] # Re: Je me fais l'avocat du diable
Posté par zebul0n (site web personnel) . Évalué à 4.
Entièrement d'accord, ce serait comme expliquer qu'on est capable d'écrire une regex pour valider une adresse email en 2mn. J'aimerais bien en voir une seule qui en serait capable, quand on lit toutes les RFC, ça me prend déjà 2 bonnes heures à tout assimiler, et au final je suis toujours incapable de produire une regex qui couvrirait tous les cas de figures.
[^] # Re: Je me fais l'avocat du diable
Posté par wysman . Évalué à 2.
Au besoin,
https://github.com/wysman/photon/blob/master/src/photon/form/validator.php#L141
[^] # Re: Je me fais l'avocat du diable
Posté par dave_null (site web personnel) . Évalué à 2.
Trop compliqué, t'as ça :
http://php.net/manual/fr/filter.filters.validate.php
[^] # Re: Je me fais l'avocat du diable
Posté par wysman . Évalué à -5.
Il y a valide et valide, c'est comme les chasseurs
Ce mail est donc valide…
[^] # Re: Je me fais l'avocat du diable
Posté par dave_null (site web personnel) . Évalué à 8.
Oui il est valide, je ne vois pas le problème.
[^] # Re: Je me fais l'avocat du diable
Posté par Larry Cow . Évalué à 5.
Tu confonds "valide" et "existant".
[^] # Re: Je me fais l'avocat du diable
Posté par GCN (site web personnel) . Évalué à 6.
Une lecture intéressante sur laquelle je suis tombé il y a quelques mois: http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html
[^] # Re: Je me fais l'avocat du diable
Posté par Snarky . Évalué à 5.
Sincèrement, comme moi je suis technique, si dans ton CV tu as en expérience 15 ans de boulangerie, mais dans tes loisirs tu es développeur de GIMP/Blender/Gnome/Kde… je t'appelle dans les 10mn. Je préfère 100 fois un réel passionné autodidacte, qu'un ingénieur qui rale car il est pas assez payé pour son diplome.
[^] # Re: Je me fais l'avocat du diable
Posté par ckiller . Évalué à 10.
C'est pas très cool de sous-payer ses ingénieurs
[^] # Re: Je me fais l'avocat du diable
Posté par palm123 (site web personnel) . Évalué à 4.
Tiens tu aurais embauché Michael Foord, qui était commercial en béton avant de devenir développeur à temps complet
ウィズコロナ
[^] # Re: Je me fais l'avocat du diable
Posté par mael . Évalué à 7.
Ce n'est pas que ça. Quand tu postules dans une boîte, tu as généralement en face de toi des gens qui n'hésiteront pas à t'entuber, à te mentir, à être clairement malhonnêtes. Je parle principalement des entretiens RH, c'est moins le cas des entretiens techniques, mais tu ne vas pas changer ton CV entretemps.. Et on voit ça dans les grandes boîtes comme dans les petites boîtes : la hiérarchie est là pour faire tourner la boîte, et si ça passe par des mensonges ben elle s'en accommodera très bien.
Il faut arrêter un peu ce refrain sur les vilains chercheurs d'emplois qui mentent sur le CV. Combien de fois vos boîtes ont fait passer un candidat pour un con en le vendant pour des compétences qu'il n'avait pas ? Combien de fois elles ont promis la lune à un employé pour qu'il ne se barre pas trop vite ?
Ça ne me choque absolument pas que des gens trafiquent leurs CV. Il faut bien manger, non ? Perso, je ne le fais pas parce que je n'ai pas envie d'être placé sur des missions où je serais incompétent. Mais je ne le fais pas surtout parce que pour l'instant, je n'ai pas trop de mal à trouver du boulot…
[^] # Re: Je me fais l'avocat du diable
Posté par Renault (site web personnel) . Évalué à 5.
Le problème vient aussi du fait que les entreprises cherchent une chimère.
Ils veulent un CV où tous les mots clés sont présents, les 3/4 sont l'utilisation basiques d'un outil où la simple lecture du manuel dans la journée suffit pour avoir les compétences voulues. Puis parfois ça concerne des langages peu connus et il faut que tout colle sinon c'est rejeté.
C'est sans compter les conneries qu'on peut voir dans les annonces comme par exemple : "Quelqu'un de motivé, sérieux, curieux, etc.", comme si on allait dire forcément la vérité dessus et comme si c'était forcément très important… Dans l'idéal on a toutes les qualités du monde mais non.
[^] # Re: Je me fais l'avocat du diable
Posté par Marotte ⛧ . Évalué à 10.
C'est vrai que ça fait un peu pitié de voir ça dans une annonce.
« Je suis blasé, insouciant, indifférent. Je peux postuler quand même ? »
[^] # Re: Je me fais l'avocat du diable
Posté par zebul0n (site web personnel) . Évalué à 10.
En fait, c'est comme les annonces immobilières, il faut savoir interpreter :
# Poste vacant
Posté par iguane39 (site web personnel) . Évalué à 4.
Hello,
j'ai éventuellement un poste dispo pour un développeur PHP expérimenté proche de Lille.
Si tu veux me contacter, on peut se rencontrer pour en discuter.
Seb.
[^] # Re: Poste vacant
Posté par hervé Couvelard . Évalué à 6.
il y a un test ? genre développer un code pour lire un fichier mbx outlook ?
[^] # Re: Poste vacant
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 10.
C'est un peu différent: il y a un chimpanzé qui fait du code. Le test c'est faire du code meilleur et plus vite que lui. NB: il a 6 ans d'expérience.
:)
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: Poste vacant
Posté par hervé Couvelard . Évalué à 2.
un seul ?
je croyais que le "truc" marchait seulement s'ils étaient une infinité, travaillant pendant un temps infini ;-)
[^] # Re: Poste vacant
Posté par François (site web personnel) . Évalué à 10.
Le chimpanzé il traîne sur linuxfr, il connaît ton pseudo et il t'emm… ;-)
[^] # Re: Poste vacant
Posté par ekyo . Évalué à 10.
Toi aussi tu es victime des colifichets et tu voudrais qu'on commence à te considérer en tant que tel ?
[^] # Re: Poste vacant
Posté par Marotte ⛧ . Évalué à 1.
C'est pas plutôt « quolibet » le mot que tu voulais employer ?
Enfin je comprends pas plus la phrase :|
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Poste vacant
Posté par Marotte ⛧ . Évalué à 1.
Ah bah je l'ai pas encore assez regardé :/
[^] # Re: Poste vacant
Posté par zebul0n (site web personnel) . Évalué à 2.
Plus vite on peut mesurer, mais meilleur ça veut dire quoi ? Un codeur qui met des cœurs sur les i ?
# Précisions nécessaires
Posté par Obsidian . Évalué à 10.
Bonsoir,
Je pense qu'il y a une bonne dose de fausse modestie dans ton post, caractéristique des gens qui commencent à avoir effectivement un peu de bouteille mais pas encore assez pour inspirer l'humilité, ni pour voir leurs connaissances commencer à vieillir et à décliner. Ce parce que la programmation intensive est une forme d'athlétisme à mon goût et qu'à l'instar de la plupart des sports de haut niveau, on ne peut pas la pratiquer efficacement jusqu'à l'âge légal de la retraite. J'ai donc quelques questions à te poser :
— Quel âge as-tu ?
— Quel âge en moyenne ont les postulants à ton poste ?
— Quel est le salaire que tu estimes correct à ce poste (celui que tu exigerais, pas celui que tu proposes) ?
— D'où sort ce test ? Tu comprends que si c'est toi qui l'a écrit, tes conclusions seront forcément biaisées, même si (« surtout » devrais-je dire) si tu t'estimes impartial ;
— Quel niveau estimes-tu avoir en C++ ? Je pensais moi-même en avoir fait pratiquement le tour (en lisant un certain nombre de cours) je me suis rendu compte qu'en définitive, je ne savais rien ou presque (j'exagère mais à peine) ;
… et surtout :
— Dans quelles conditions fais-tu passer ce test ? En situation, avec une machine dûment équipée, un café, et trois heures de tranquillité après lesquelles tu reviens voir tes candidats ou bien dans une salle d'examen sur papier, voire même sous forme d'interrogatoire avec un feutre et un tableau blanc ?
— Tes candidats ont-ils accès à la doc quand ils passent le quiz ? La programmation est quand même devenue une activité dans laquelle il vaut mieux savoir chercher que tout retenir par cœur (surtout quand on sait à quelle vitesse les connaissances deviennent obsolètes).
J'ai moi-même commencé à écrire mes premiers programmes en BASIC autour de 10 ans peu avant d'entrer au collège. J'en ai aujourd'hui 37. Cela fait donc 27 ans que j'écris des logiciels par passion ou professionnellement. Plusieurs accidents de parcours m'ont obligé à plusieurs reprises à quitter le circuit scolaire et à y revenir jusqu'à suivre une formation d'ingénieur en partenariat il y a un peu plus de cinq ans, que je n'ai malheureusement pas pu conclure car j'ai perdu mon emploi peu avant la fin. Il se trouve que depuis que je travaille, j'ai fait face à pas mal de situations différentes. Après avoir fait mon service national et quelques petits boulot, j'ai fait un certain nombre de mission en SSII comme pas mal d'entre nous (et comme pas mal d'entre nous, j'ai fini par claquer la porte). J'ai occupé mon avant-dernier poste pendant six ans à l'issue duquel mes collègues proches avaient une haute estime de moi, mais où pratiquement tous les autres pensaient que j'étais un stagiaire (même après six de boîte, oui).
Mon dernier employeur, en revanche, était une boîte de sécurité informatique dont le nom est assez connu dans leur secteur d'activité : il se trouve que j'ai été recruté avant même d'avoir postulé, par réputation, par un membre de l'équipe assez bien placé lui aussi et qui me connaissait simplement par les messages que je déposais depuis plusieurs années sur le forum que l'on fréquentait tous les deux. Je connaissais son pseudo de visu mais nous n'avions jamais pris contact avant cela. J'ai été pratiquement accueilli avec le tapis rouge par son superviseur qui visiblement me considérait également comme un « bon ». Je n'ai donc jamais rien prétendu et heureusement parce que mon recruteur m'a voué un respect tout au long de ma mission alors qu'objectivement, il était meilleur que moi ! À aucun moment je n'ai été franchement dépassé mais à aucun moment non plus je n'ai dominé un développeur de l'équipe de mon savoir et il a fallu que je travaille sans relâche pour me maintenir à niveau.
Or, il se trouve que cette personne a été chargé, comme toi, de faire du recrutement ou au moins de participer aux entretiens. Comme il était très intransigeant sur ses propres connaissances, il l'a été également dans ses évaluations et là, objectivement, je pense que je n'aurais pas été capable de les passer.
J'avais moi-même également écrit mes propres tests d'évaluation, notamment en C++, il y a huit à dix ans, avec pas mal de pièges syntaxiques et de petites subtilités que j'avais moi-même rencontrées, en effet. Sauf qu'il ne s'agissait pas de procéder à un écrèmage systématique mais plutôt de voir facilement, en un coup d'œil, si la personne que j'avais en face de moi était capable de s'en sortir avec un peu de doc ou si elle était en mesure de me donner des leçons.
Ceci pour dire que je me reconnais totalement dans tes propos lorsque tu cherches à écrire le code le plus propre possible. Tu as entièrement raison de le faire et ne supporte pas les gens qui sont volontairement approximatifs quand ils exercent. Tu es probablement très compétent mais malgré cela, je pense que même toi, tu ne serais pas capable de passer un test de même niveau écrit directement par un programmeur de l'équipe que tu souhaites intégrer. D'une part parce qu'il serait lui-même très pointu dans son domaine et d'autre part parce qu'il serait au fait des problématiques rencontrées dans son secteur alors que tu ne le saurais pas encore à ce moment. C'est à cela que servent les périodes d'essai.
À la limite, si tu peux te le permettre, essaie d'envoyer par mail un exercice de second niveau à un candidat volontaire mais qui n'aurait pas forcément le niveau à l'entretien et laisse lui deux ou trois jours pour le mener à bien. Ça se faisait dans ma dernière compagnie. En général, on a de belles surprises de la part des personnes qu'on a jugé en premier lieu. Ça leur permet aussi de se relire, de déboguer et de prendre le temps d'examiner à tête reposée toutes les approches possibles pour choisir la meilleure .Et c'est bien ce que l'on attend d'eux, en définitive, lorsqu'ils sont en activité.
[^] # Re: Précisions nécessaires
Posté par benoar . Évalué à 4.
Tout à fait vrai, j'ai le même genre de pratique « programmatique » que toi, et même si je suis un tout petit peu moins vieux, je me rends compte qu'on ne garde pas l'agilité qu'on avait quand on était jeune toute sa vie… J'espère que les p'tits jeunes d'ici pourront comprendre, mais s'amuser à détecter les « pièges syntaxiques ou les petites subtilités » comme tu dis, c'est marrant au départ, mais à la longue tu sais que la programmation ça n'est pas vraiment ça, et que ton cerveau devient moins agile pour détecter ce genre de piège. Bref, je me ferais avoir, mais je ne sais pas si c'est le signe que je suis « mauvais » (car forcément, je pense être très bon :-)). C'est pour ça que les tests, je préfère quand c'est constructif en restant plutôt « haut niveau », en discutant, et en essayant de comprendre pourquoi quelqu'un n'y arrive pas.
[^] # Re: Précisions nécessaires
Posté par Guillaume Denry (site web personnel) . Évalué à 8.
A partir de quel âge tu as sentis ton cerveau "moins agile" ? Vous commencez vraiment à me foutre la trouille :)
[^] # Re: Précisions nécessaires
Posté par benoar . Évalué à 3.
Je suppose que ça dépend des gens. Perso, je dirais que ça commence avec la trentaine. On sait bien que le cerveau commence à décliner à partir de 25 ans, je suppose qu'on commence vraiment à s'en rendre compte quelques années après. Mais bon, je parle juste de mon cas, et j'ai sûrement des antécédents qui ne me favorisent pas qui jouent en plus.
[^] # Re: Précisions nécessaires
Posté par lasher . Évalué à 3.
Je bosse de temps en temps avec [Jack Dennis]. Il a 81 ans, et continue de coder. Là, il est en train de terminer un simulateur pour une architecture multi/many core, avec un langage de programmation qui cible son jeu d'instruction, etc.
Il existe un bouquin, Coders at Work qui recueille un ensemble d'entretiens avec des « nouveaux » (Jamie Zawinski, dév. Netscape à la grande époque), des moins nouveaux (Joe Armstrong, inventeur de Erlang; Guy Steele, co-créateur de Scheme, « formalisateur » du langage Java, créateur de Fortress, et plein d'autres trucs) et des vénérables (Donald Knuth, mathématicien/informaticien, inventeur de TeX — entre autres). Beaucoup des gens interrogés ont largement passé 50 ans. Et pourtant une grande partie d'entre eux continuent de développer. Certes, je parle de gens qui sont relativement exceptionnels. Pourtant, mon expérience (statistiquement non significative, je le sais bien) me fait penser que les « vrais programmeurs¹ » n'arrêtent jamais vraiment de programmer, et ne perdent pas forcément de leur acuité…
[1] Je ne m'inclus pas dans cette catégorie.
[^] # Re: Précisions nécessaires
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Je pense que l'impression d'être moins bon ou efficace, vient du fait que lorsque tu maitrises un sujet, et que tu dois passer à une techno plus récent, tu ne te sens plus expert du domaine, ta productivité tombe et tu as l'impression de décliner.
"La première sécurité est la liberté"
[^] # Re: Précisions nécessaires
Posté par Obsidian . Évalué à 9. Dernière modification le 22 novembre 2013 à 22:17.
Oui, mais pas seulement :
D'abord parce que, jusqu'à une certaine limite, cette « baisse » est compensée par l'expérience de la programmation en général qui t'apporte naturellement les bons réflexes pour aller chercher l'info là où elle se trouve et te fait gagner beaucoup de temps.
Ensuite, c'est très fatiguant pour l'esprit. Il m'est arrivé plusieurs autres choses à côté qui jouent aussi sur le psychique, mais à l'approche de la quarantaine, la mémoire commence tout doucement à décliner : non seulement ça devient difficile d'acquérir une nouvelle technologie depuis zéro comme on l'avait fait auparavant mais on commence à douter de ses propres connaissances, ne serait-ce que parce qu'elles commencent elles-mêmes à prendre de l'âge.
Avec ça, à part « l'expérience générale de la programmation » dont je parlais juste au-dessus, on ne peut pas s'appuyer sur un solide bagage comme on le ferait en physique ou en mathématiques par exemple : certes ces disciplines progressent comme les autres, mais les théorèmes enseignés et les lois de la physique, sauf bouleversement majeur, restent en principe valides tout au long d'une vie. En informatique, ça a beau être vrai aussi, la forte obsolescence repousse rapidement la majeure partie des technologies aux oubliettes dans un temps relativement court.
Par exemple, étant ado, j'ai fait énormément de Minitel : je connaissais les codes Vidéotex par cœur à force de les pratiquer, on savait à quoi servait la séquence « Esc 9 g », et je m'étais même bricolé un câble pour piloter le mien à travers le port cassette (ou crayon optique, je ne sais plus) de mon TO8D qui n'était pas équipé d'un UART en standard. Pendant très longtemps, le Minitel a été la norme un peu partout, tant en entreprise que dans les foyers français. Aujourd'hui, c'est une somme de connaissances qui ne me sert à rien.
Enfin, il faut se rendre compte que les technologies évoluent et se complexifient. Quand j'avais commencé l'informatique, les technologies passées me paraissaient ridiculement simples par rapport à ce qui se faisait à mon époque, alors qu'il ne devait y avoir en fait que 15 ans d'écart entre les deux. Cette escalade se perpétue jusqu'à un point qui finit par dépasser nos capacités. Nos parents disaient cela de nous quand ils nous voyaient manipuler nos ordinateurs avec aise, nous allons visiblement connaître le même sort à notre tour.
Ça a toujours été vrai mais là, on assiste en une demi-carrière à quelque chose qui prend 100 ans dans le reste de l'industrie. Ça demande de s'y investir à 100 % sachant qu'à moins d'être très doué, il faudra se reconvertir, et ça va devenir un problème de société à mon avis.
[^] # Re: Précisions nécessaires
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
De mon coté, j'ai dit que je quitterais l'informatique, lorsque l'informatique quantique aura remplacé l'informatique classique. Il faut totalement repenser la manière d'écrire un algorithme, et penser complètement différement.
"La première sécurité est la liberté"
# simplifier le test
Posté par PLuG . Évalué à 10.
Si personne ne réussit, peut être que le test est … trop compliqué.
Pas forcément techniquement, mais peut-être à cause de la pression, de l'environnement, …
Une solution que je te propose est de prendre l'exercice dans l'autre sens:
montrer des morceaux de code choisis et demander au candidat de les analyser.
dire ce que fait le code, si il fonctionne, si il buggue dans un cas tordu, … comment il pourrait l'améliorer.
A mon sens c'est moins déstabilisant que la feuille blanche et ça permet aussi de voir comment le mec raisonne,
s'il cherche a faire du beau code ou pas, s'il est logique …
Avec ce genre de tests pour du java ou du C, on a nous même rencontré pas mal de personnes
qui prétendaient coder … mais qui étaient incapables de comprendre un morceau de code présenté.
In fine, on a réussi nos recrutements de développeurs avec ces tests.
# Mauvais langage; changer langage
Posté par Jean B . Évalué à 10.
Je sais que mon commentaire va sonner comme un troll, mais je suis très sérieux.
J'ai moi même été amené à recruter pour des positions PHP dans un lieu tout autre (Montréal) et en suis arrivé au même constat que toi.
La façon dont je le rationalise, c'est que les gens qui aiment le métier de développeur, qui aime le code bien écrit (quelque soit la définition de bien écrit), ne font pas ou plus de PHP. Et les rares qui le font encore c'est car ils ont réussit à trouver un bon poste.
Je ne saurait que trop te conseiller de te former à d'autres languages qui attirent plus les passionnés.
Et comme je l'ai dit plus haut, recherche des éditeurs ou autre sociétés qui maintiennent leurs projets sur le long terme. La vision de la qualité du code, de la gestion de la dette technique, etc y est totalement différente (ou alors ils se foutent dans le mur après quelques années)
# Bonjour, je suis un développeur médiocre et je le sais.
Posté par groumf . Évalué à 10.
Je code en python, mais je n'arrive pas à faire de test unitaire.
Je ne crée jamais d'objet, quand je fais des classes c'est pour regrouper les fonctions qui font la même chose.
Je m'intéresse aux bonnes pratiques de développement, mais il y a plein de concept qui me passe au-dessus de la tête.
Par exemple la fonction super en python , j'ai relu la doc 20 fois à plusieurs jours/semaines/mois d'intervalle je n'ai toujours pas compris comment ça marche. Quand je pompe du code issu du net et qu'il y a un super dedans je mets super et pis c'est tout.
Je serai incapable de faire le design d'une API.
A côté de ça, je dois avoir des bons côtés.
Je m'applique quand je fais des commits sur git. Une nouvelle fonctionnalité = un commit, pas de commit avec à moitié une correction de bug et du refactoring en même temps.
Je note les versions des libs utilisées pour bien mettre les mêmes en prod.
J'anticipe les problèmes…
Au final pour revenir au fait de se surévaluer sur le CV, si j'avais mis texto ce qui est au-dessus je serai en train de mourir de faim à lors actuelle.
[^] # Re: Bonjour, je suis un développeur médiocre et je le sais.
Posté par Littleboy . Évalué à 6.
Ugh, c'est pas forcement un enorme probleme pour un dev si tu fonctionnes en equipe et que tu es capable d'apprendre (en considerant que tes collegues n'ont pas envie de te couper en petits morceaux quand tu ecris du code sans tout a fait comprendre ce que tu fais), mais ca va forcement de poser des problemes pour evoluer a un moment ou a un autre.
On a l'impression que tu es resigne. Pourquoi ne pas acheter quelques bouquins sur Python et commencer a maitriser tous ces concepts petit a petit? La doc direct c'est parfois un peu aride et c'est pas vraiment fait pour apprendre les concepts du language (sauf dans les quelques cas ou la doc est vraiment exceptionnelle).
Je connais pas trop le python donc je ne pourrais pas recommander des bouquins en particulier, mais peut-etre que d'autres lecteurs de LinuxFR peuvent lister leur preferes.
[^] # Re: Bonjour, je suis un développeur médiocre et je le sais.
Posté par manatlan (site web personnel) . Évalué à 2.
lire ça:
http://www.amazon.fr/Python-Petit-guide-lusage-d%C3%A9veloppeur/dp/2100508830
[^] # Re: Bonjour, je suis un développeur médiocre et je le sais.
Posté par manatlan (site web personnel) . Évalué à 2.
Je comprends ;-)
J'ai plus de 10ans de python, je n'utilise pas "super", j'ai du mal à comprendre aussi. Par contre, je lui préfère, et de loin, l'ancienne méthode pour appeler/initialiser l'objet parent (je trouve cette forme plus naturelle, plus logique ;-) … du coup j'arrive à la retenir)
Mais on est HS là
[^] # Re: Bonjour, je suis un développeur médiocre et je le sais.
Posté par GaMa (site web personnel) . Évalué à 1.
Super, c'est le mal ! Enfin, c'est pas moi qui le dit (mais j'ai toujours réussit à m'en passer)
https://fuhm.net/super-harmful/
Matthieu Gautier|irc:starmad
# Niveau de l'enseignement
Posté par needs . Évalué à 10.
J'adore ce genre de test et c'est vraiment avec plaisir que je les fais. Je suis sortis d'un IUT informatique, soit 2 ans de formation de 30h par semaine, 50% Informatique, 50% matières annexes (Mathématique, Économie, Droit, …). Et avant de me poser des questions sur la qualité d'un candidat, je mettrais très sérieusement en cause la qualité de l'enseignement de l'informatique, du moins pour ce genre de formation.
Le bilan est simple : ceux qui sont rentrés dans cet IUT sans savoir écrire une ligne de code, sont ressortis 2 ans (ou 3) plus tard sans savoir écrire deux lignes de code.
On a eu des cours sur les réseaux assez intéressants, des cours sur les bases de données plutôt bien fournis, on sait à peu près à quoi correspond un arbre binaire, une liste chaînée, les plus téméraires auront vaguement compris ce qu'est un compilateur et seulement une poignée d'entre eux auront compris ce qu'est un système d'exploitation.
Par contre, on a eu aucune, mais vraiment aucune formation sur :
La plupart de ceux qui sortent de cet IUT manquent énormément de pratique et de confiance en soi : l'informatique, c'est de la magie noire. C'est pourquoi je dis qu'ils ne sont pas capable d'écrire 2 lignes de code : ils n'ont pas assez de pratique pour établir des algorithmes simples et fonctionnels. Un peu comme si dans les auto-écoles ont apprenait comment fonctionne une voiture sans montrer comment la conduire.
Pour revenir un peu sur le sujet du journal, à la fin de cet IUT on avait un stage obligatoire de 2 mois. Plusieurs élèves avaient postulé pour le même stage. L'entreprise a alors décidée de faire passer un entretien, avec un test de deux heures. Le test : "Écrivez un programme qui affiche les 100 premiers nombres premier". Ils avaient accès à internet, ils devaient écrire ce programme avec PHP, la machine était fournie, tout était configuré, bref, de la pure programmation. Aucun d'entre eux n'a été capable d'afficher les 100 premiers nombres premier, le responsable m'a montré les programmes et deux d'entre eux n'ont pas réussi à afficher les nombres allant de 1 jusqu'à 100.
Alors évidemment il ne faut pas s'attendre à avoir au bout de deux ans des virtuoses de la programmation, mais au moins des élèves qui ont appris les bons principes de la programmation, qui ont confiance en eux et qui ont assez de pratique pour pouvoir écrire leurs propre programme, de manière propre et organisé, même s'il s'agit d'écrire les 100 premiers nombre premier. Mais je vais être honnête : on aurait fait passer ce test à l'équipe enseignante, il y aurait eu beaucoup de surprises.
Tout ça pour dire que les formations en informatique ont une très grande responsabilité sur le niveau actuel des développeurs.
[^] # Re: Niveau de l'enseignement
Posté par manatlan (site web personnel) . Évalué à 0.
Justement … NON !
Beaucoup de personnes, quand ils rencontrent un problème informatique qu'il n'arrive pas à résoudre au premier abord : abandonne, en considérant qu'il y a un peu "magie noire" là dedans. Et que par conséquent : ils n'y arriveront pas !
L'erreur est là, Il n'y a pas plus déterministe qu'un ordinateur, un programme. Il faut juste chercher (et du coup : monter en compétence). Ce que tu cherches maintenant, te feras moins chercher plus tard, et ainsi de suite.
[^] # Re: Niveau de l'enseignement
Posté par navaati . Évalué à 4.
Nan mais… Bien sûr que "NON !", on le pense tous ici. Il voulait dire "Pour les élèves sortant d'IUT".
En IUT réseaux et télécoms, c'est pareil. Consternant. Et, pareil, les profs d'info sont des merdes.
Alors ici ils ont l'excuse que ça soit du réseau et que l'informatique est un peu annexe, et de fait les profs de réseau sont bien meilleurs (ils sont même très bons) et les élèves comprennent mieux ce qui se passe.
Mais si le niveau d'info est mauvais en IUT info… Je me demande où sont les bons profs d'info.
[^] # Re: Niveau de l'enseignement
Posté par liberforce (site web personnel) . Évalué à 3.
En IUT GEII (Génie Électrique et Informatique Industrielle). J'ai eu des cours de C là bas (IUT Cachan), et clairement c'était bien expliqué (merci M. et Mme Priou), bien que j'ai un peu galéré avec les pointeurs. En revanche, 2 ans plus tard en école d'ingé, j'ai eu un enseignant chercheur qui a essayé de nous enseigner le C. J'avais déjà développé en C, et j'avais du mal à comprendre ce qu'il disait et où il voulait en venir… Sachant que d'autres personnes venaient de formation diverses et n'avaient pas programmé avant, je te raconte pas le carnage. À cause de cette andouille, les gens dans la classe ont été dégoûtés de la programmation, et on était plus assez nombreux à de mander l'option "Génie Logiciel" en 3ème année pour qu'elle ouvre. Le côté positif, c'est que ça m'a préservé du Java…
[^] # Re: Niveau de l'enseignement
Posté par needs . Évalué à 2.
Je suis maintenant en L3 à la FAQ, et c'est une sorte de renaissance : les profs sont géniaux, plutôt jeunes et avec beaucoup plus de passion, les cours sont bien fait, et l'équipe enseignante est super sympa. On a 100% de matières informatique, il y a beaucoup de gens intéressant. Les cours sont très théorique, mais on aborde beaucoup plus en profondeur le sujet, et les enseignants maitrisent vraiment bien leur sujet.
[^] # Re: Niveau de l'enseignement
Posté par chimrod (site web personnel) . Évalué à 10.
Et t'as eu les réponses à tes questions ?
[^] # Re: Niveau de l'enseignement
Posté par lolop (site web personnel) . Évalué à 3.
C'est ce qu'on fait en TP pour des cours de bases d'info/algo avec des élèves IUT en… mesures physique.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# CommitStrip
Posté par Axone . Évalué à 10.
Une petite Nimage pour illustrer le journal.
# Salaire
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
Pour le salaire, c'est très simple. Le salaire n'est jamais fonction des compétences techniques mais uniquement fonction de la compétence de négociation de la personne.
Un bon négociateur rentrera dans le même poste que toi au début de sa carrière avec un salaire facilement 10 à 15% supérieur au tien.
Et puis, chaque année, il négociera une augmentation. En pourcentage.
Toi, tu oublieras parfois de la demander. Et quand tu la négocieras tu obtiendras 3% là où lui aura 5%.
Après quelques années à ce rythme, ça commence à chiffrer sévèrement.
Ce système est maintenu par l'absurdité qui veut que nos salaires soient secrets. Pour les employés, c'est une catastrophe de garder les salaires secrets. Pour les entreprises, c'est une aubaine. À telle point que certaines entreprises interdisent aux employés de divulguer leur salaire.
Autre facteur aggravant : le salaire se négocie généralement avec des RH ou des directeurs qui n'ont aucune idée des compétences techniques. Ils ont certes le rapport du manager de l'équipe mais celui-ci n'a ni le temps ni les compétences pour décider si un code est bon ou pas. Ce qu'il voit c'est qu'il y en a un qui est sûr de lui, qui s'attribue beaucoup de succès de l'équipe. Et en plus, il doit être vachement bon car, en temps que manager, il a eu accès aux fiches de paie et le mec est mieux payé que les autres. Du coup, celui-là est bon.
Tu mets tout cela ensemble et tu découvres que plus on est médiocre, plus on est bien payé.
Mais cela s'oublie vite car, pour la société, la qualité de ton travail est proportionnelle à ton salaire. Si tu es bien payé, c'est que tu es bon. Au final, on se retrouve avec des incapables avec des salaires mirobolants mais que tout le monde trouve géniaux. Car, si on les paie ce prix là, c'est qu'ils les valent, non ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Salaire
Posté par Larry Cow . Évalué à 6.
Pour certains employés (i.e. les mauvais négociateurs) seulement. Les bons négociateurs, ça les arrange que toute la boîte ne sachent pas à combien ils appointent.
[^] # Re: Salaire
Posté par palm123 (site web personnel) . Évalué à 2.
Sur le même thème, Valérie Henson Aurora explique pourquoi les femmes sont souvent moins bien payées que les hommes. Parce qu'elles demandent moins, négocient moins.
http://valerieaurora.org/howto_salary/x40.html
ウィズコロナ
[^] # Re: Salaire
Posté par liberforce (site web personnel) . Évalué à 10.
J'ajoute que je viens de changer de taf et qu'on m'a quand même balancé après 11 ans d'expérience que j'étais hors grille par rapport à mon école d'ingé… Ce manque considération pour ce que les gens peuvent apprendre dans le cadre de leur métier m'afflige.
[^] # Re: Salaire
Posté par lolop (site web personnel) . Évalué à 5.
Je ne sais plus quel américain se marrait de voir mis en avant, sur les CVs des ingés français ayant déjà vingt ou trente ans de carrière, l'école d'où ils étaient sortis…
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Choisis le plus sympa.
Posté par datz . Évalué à 10.
3H de test!
Franchement, je l'aurais même pas fait ton test. Ton entreprise, c'est quoi? la NASA? Même pas payé en plus.
Bien sur que le développeur grouillot de base est nullos. C'est pour ça qu'ils aspirent à devenir chef de projet.
Laisse tomber les compétences techniques. Ce qui compte, c'est les rapports humains.
Choisis le plus sympa.
[^] # Re: Choisis le plus sympa.
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Je confirme que 3h de test c'est long, surtout si le "test" c'est du pissage de code et pas un échange (et encore plus pour un poste de "lead developer").
Je confirme que les rapports humains c'est ce qui compte le plus. Les rapports humains ça prend aussi en compte la personnalité. Surtout pour un poste de "lead developer"
Et puis faut aussi prendre en compte ta boîte : si le mec il faut qu'il soit bon techniquement, qu'il soit plutôt sympa (c'est toujours plus facile d'être leader quand tu es un peu sympa), mais que ta boîte paie pas, laisse tomber : tu ne trouveras pas. Faut être lucide sur ce que tu as à offrir.
[^] # Re: Choisis le plus sympa.
Posté par pasBill pasGates . Évalué à 1.
3h c'est rien.
Ici la plupart des boites d'info font passer une journee entiere d'interviews, pour la plupart techniques. Tu peux compter jusqu'a 7 interviews d'une heure dont au moins 5-6 seront techniques si c'est pour un poste non-manager.
[^] # Re: Choisis le plus sympa.
Posté par datz . Évalué à 2.
Pour faire quoi? Du SAP?
Pour travailler ou? Chez Accenture?
C'est gens la ne s'intéressent pas à toi, ils te mettent juste dans des boites. Quand on recrute comme ça, on n'a rien d'interessant.
De toute façon, les "bons", on les connait. Surtout dans le logiciel libre. On va les chercher.
C'est que de la souffrance pour ceux qui acceptent ces processus.
Ca a été mon cas.
[^] # Re: Choisis le plus sympa.
Posté par totof2000 . Évalué à 2.
Bien souvent c'est plus ou moins pour "pousser des cartons" : si tu vas jusqu'au bout du processus, c'est que tu es suffisamment soumis pour faire ce qu'on te demande sans broncher.
[^] # Re: Choisis le plus sympa.
Posté par datz . Évalué à 2.
Ou psychopathe.
http://www.slate.fr/lien/43137/psychopathe-dirigeant-entreprise-un-sur-25
[^] # Re: Choisis le plus sympa.
Posté par ckyl . Évalué à 3.
Tu veux dire que PbPg pousse des cartons ? En comparaison il doit être vachement intéressant ton job…
[^] # Re: Choisis le plus sympa.
Posté par totof2000 . Évalué à 3.
PbPg bosse aux US ou la façon de faire est totalement différente.
Je parle de ce que j'ai déjà vu en France dans certains millieux (bancaire par exemple, pour ne pas le citer) ou on demande des ingés surqualifiés pour faire du taf de "grouillot de base" (pardonnez l'expression, mais je n'en trouve pas d'autre).
[^] # Re: Choisis le plus sympa.
Posté par pasBill pasGates . Évalué à 1.
Je pense qu'il faut separer les 2 mondes :
Le 2eme groupe est celui dans lequel il faut etre, meme en France ils mettent une valeur preponderante sur leurs devs, le 1er est a eviter.
[^] # Re: Choisis le plus sympa.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Les plus gros salaire de dev sont pourtant dans la banque et assurance (en java, en tout cas, il y a quelques années). Le problème des boites qui vivent du soft est que le dev fait parti de la grosse masse de salaire, alors qu'un dev en banque fait parti d'un pool beaucoup plus petit en proportion, il coute donc moins chère à la banque de faire plaisir à ses dev.
"La première sécurité est la liberté"
[^] # Re: Choisis le plus sympa.
Posté par ckyl . Évalué à 5.
Ca me parait très rationnel d'un côté de se plaindre qu'il n'y a que des taffs de merde et qu'on est très mal payé, et de l'autre côté de chier sur les boîtes qui s'investissent dans leur processus de recrutement et à traiter correctement leurs employés pour ce qu'ils offrent.
Tu trouves pas ça un peu ridicule ton message en parlant d'une boîte qui fait ses recrutement consciencieusement et professionnellement, qui te rembourse billets d'avions, hôtel et tous tes frais, qui fait des entretiens intéressants (que tu les rates où non), qui investi dans ses employés et qui paye 2-4x plus que ce que les gens se plaignent d'avoir…
Non par ce que les méthodes de recrutement que tu critiques, c'est juste grosso modo celles qu'appliquent toutes les boîtes qui sélectionnent précieusement leur employés, et qui donc leur offre un boulot sympa pour un salaire sympa pour ce qu'ils savent la valeur de leur équipe. Des mastodontes MS/Google/Amazon aux petites startup qui se créées consciencieusement leur petite équipe technique pour tout gérer à 10.
Tu veux pas passer une journée qui ne te coûte rien à échanger avec des gens et essayer de leur montrer qui tu es, comment tu te comportes et montrer ce que tu sais faire ? C'est ton choix… T'es pas capable de faire la distinction entre un marchant de viande et une boite correcte ? Dommage…
[^] # Re: Choisis le plus sympa.
Posté par datz . Évalué à 0.
De qui tu parles?
Tu dois mélanger les commentaires.
Plus aucune boite n'investit sur ses employés. C'est fini le capitalisme industriel à la Papa avec des innovations sociales comme les logement social.
Les entreprises que tu cites sont juste en pleine croissance et leur stratégie de séduction est transitoire.
Ce n'est pas parce que ton entreprise est "humaine" que c'est le cas pour la plupart.
En tant qu'employé, ma meilleure expérience a été dans le monde industriel et scientifique.
[^] # Re: Choisis le plus sympa.
Posté par Yann Hodique (site web personnel) . Évalué à 6.
oui et non…
3h dans l'absolu, pour évaluer la compétence de quelqu'un, c'est rien en effet. Par contre 3h pour une seule unité d'interview (ou de code ici) je trouve ça énorme.
Je n'ai jamais postulé chez MS, mais mon expérience des interviews aux US c'est généralement entre 5 et 10 slots d'1h, avec des gens différents, des sujets différents: de l'interview HR de base pour vérifier que tu rentres un minimum dans les cases, à la discussion informelle pour évaluer tes compétences en communication et ton capital sympathie, aux sujets techniques qui peuvent évoluer en discussion sur ton projet open-source dont le mec en face est utilisateur/contributeur (vécu :)).
En gros, on n'a pas le temps de s'ennuyer (y compris pour la journée d'entretiens de Google, qui te laisse avec du charbon fumant à la place du cerveau). Et si une interview particulière ne se passe pas trop bien (ce qui arrive souvent), il n'y a pas trop longtemps à attendre pour en être débarassé.
Par contre un "TP" plus ou moins bidon de 3h où je vais m'ennuyer comme un rat mort tout en n'étant pas certain de ce qui va satisfaire le type en face… personnellement si je sais à l'avance que c'est au programme je n'y vais pas (si je trouve la méthode de recrutement fondamentalement foireuse, il y a des chances que je n'aie pas envie de bosser avec les gens qui l'ont mise en place de toute façon).
Je ne cherche pas à tirer de conclusion, mais il est clair que la stratégie de recrutement a un impact direct sur le sous-ensemble de personnes qui vont accepter de suivre le processus. Parfois c'est exactement l'impact qu'on veut (je pense que Google/Microsoft/Apple/… sont globalement satisfaits de leurs embauches, quitte à rejeter des gens potentiellement valables), parfois non (ce qui se voit en général au fait que la boîte n'arrive pas à recruter, ou inversement recrute n'importe qui)
Bref je trouve quand même un peu que se plaindre du niveau des candidats, qui est peut-être effectivement faible, évite un peu trop facilement de se demander pourquoi Linus n'a pas postulé :)
[^] # Re: Choisis le plus sympa.
Posté par pasBill pasGates . Évalué à 1.
Ah oui, 3h d'un coup c'est effectivement beaucoup…
Ca me semble aussi contre-productif de faire passer 3h sur 1 seule chose (meme si on essaie de voir plusieurs facettes), parce que ce n'est qu'un seul point de vue (1 seul interviewer) et une seule approche.
[^] # Re: Choisis le plus sympa.
Posté par Jean B . Évalué à 2.
Si 3 heures de code est effectivement le premier contact c'est un peu rude.
Par contre pour un poste ou il y a beaucoup de candidats, je n'ai absolument aucun scrupule à leur faire passer un entretien de 30 minutes via skype (ou autre) où je veux les voir coder un FizzBuzz.
Sur des positions type PHP, ça filtre généralement plus de la moitié des candidats.
[^] # Re: Choisis le plus sympa.
Posté par Julien Jorge (site web personnel) . Évalué à 6.
3 heures c'est déjà long, et j'ai vu pire ! C'était une sorte d'entretien sans fin : un QCM envoyé par courriel, qui m'a pris 45 minutes, puis une série de 4 h d'exercices, encore par courriel. Après ça j'ai pu faire un entretien physique où, après trois heures de route, j'ai eu le droit à encore 45 minutes d'exercices sur papier et deux exercices au tableau.
J'avais beaucoup aimé les exos du QCM et de la première série d'exercices, mais quand ils m'ont refilé leur questionnaire sur place j'ai laissé tomber. Finalement à aucun moment il n'a été question d'équipe, d'organisation du travail, d'humain ou de projet. Ce n'était que de la technique.
[^] # Re: Choisis le plus sympa.
Posté par windu.2b . Évalué à 4.
Perceval
[^] # Re: Choisis le plus sympa.
Posté par datz . Évalué à 3.
# Comment ne pas réussir à recruter quand on "sait"
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 10.
Si ton recrutement ne marche pas, le problème ne vient pas forcément des candidats que tu as rencontrés. Ca "peut" aussi venir, entre autres :
p.s : j'ai 10 années d'expérience, j'ai recruté des profils allant de l'admin système à l'ingé support avant-vente en passant par des développeurs +/- expérimentés, des ingés test, des ingés recherche, des responsables ergonomie, tests… J'ai fait passer des tests techniques où je ne savais pas tout faire moi-même et je le disais directement : 30min de réflexion et 30min de discussion sur les sujets trouvés / pas trouvés. D'ailleurs en général on était 2 pour discuter des sujets techniques - chacun ayant un domaine de compétences. Ce que j'ai le plus aimé durant ces entretiens, c'est le mec qui nous a dit un coup après une dizaine de minutes où on voulait qu'il nous explique comment fonctionnait un bout de code qu'on lui montrait : "si vraiment je tombe sur un bout de code comme ça et qu'il faut le comprendre, je vais chercher sur internet" (c'était sur les fonctions lambda, en python). Il a tout compris, on l'a recruté, c'était pas un "bon développeur" au sens propreté du code, réutilisation, factorisation, mais un excellent développeur "automatisation de tâches", outils internes.
p.p.s : j'ai jamais cherché à recruter "quelqu'un comme moi", j'ai cherché ce qui était positif et négatif dans les gens que je rencontrais. Et bien souvent, il y avait des qualités que je n'avais pas - c'est un sacré avantage de recruter des gens qui sont forts dans les domaines où tu ne l'es pas (et inversement).
# C'est peut-être toi le problème ?
Posté par denxp . Évalué à 7.
Comme dit dans un commentaire plus haut, je trouve qu'il y a un peu de fausse modestie dans ton journal,
et que tu essaies surtout de te vendre (il n'y a rien de mal à ça hein)
D'abord, tu dis que tu as fait, toi-même, cet exercice en 1h40. Bravo à toi !
Mais tu es le seul à juger de ton travail, montre-nous ton code "bien structuré".
Est-ce que tu donnes un énoncé clair ? Si tu veux des objets, une structure flexible : pourquoi ne pas le préciser ?
Certaines personnes ont besoin de directives pour être performant (oui même les leads).
70% du temps (je suis gentil) sur un projet le code est dégueulasse : le client veut un truc qui marche et la boîte veut du pognon.
Ca ne tient pas au PHP, c'est juste qu'en PHP ça se voit bien.
J'ai été (et serai) des deux côtés de la barrière et j'en suis arrivé à la conclusion que les tests de développement ne servent à rien.
En tant que postulant je refuse les entretiens avec ce genre de tests : entre les QCM pompés sur Internet,
les questions totalement foireuses et les énoncés absents, j'ai toujours l'impression qu'il s'agit pour le recruteur de se prouver quelque chose à lui-même,
ou pire qu'il cherche son clone.
Comme recruteur, je préfère discuter avec la personne autour d'une tasse de café. Qu'elle me montre ses réalisations si possible,
lui exposer les problèmes que nous rencontrons et voir ses réactions/propositions.
Recruter n'est pas une tâche facile, mais ne pas se remettre en question dans son processus de recrutement la rend encore plus compliqué.
Je te souhaite bonne chance pour trouver ta pépite ou un autre job.
# merci !
Posté par manatlan (site web personnel) . Évalué à 10.
Merci pour ton post !
Perso, j'ai appris énormément de choses, en lisant divers points de vues de diverses expériences !
ça faisait longtemps que je n'avais pas lu des échanges aussi intéressants/enrichissants sur DLFP (ceci n'est "pas un troll" !)
La bonne personne n'est pas forcément un clone de toi même. La bonne personne est certainement celle qui fera ce que tu lui demandes dans les temps impartis, avec le salaire que tu lui donneras, et qui lui conviendra.
Ton test, tout comme le fizzbuzz : c'est null('able). (cf les posts qui explique pourquoi c'est caduque )
Et oui, le salaire ne dépends pas du niveau du gars (cf ploum ), c'est triste, mais c'est malheureusement comme ça.
Le côté humain est super important (savoir être), presque plus que son level (savoir faire). Le relationnel est extrêmement important ! S'il est "ouvert", il te fera ton test en 1h30 dans 3 mois, à tête reposé au coin café.
# je suis à la recherche d'un dev PHP
Posté par _bingo_ . Évalué à 2.
Salut Snarky
Ton texte m'a beaucoup intéressé, je suis à la recherche d'un dev PHP de très bon niveau.
pour la sélection je fais passer un test de 6 heures (j'ai résolu le même problème en 5h30).
bien sur, si t'as façon de résoudre le problème ne me convient pas, j'écrirais moi aussi un post pour dire à quel point je te suis supérieur.
plus sérieusement, j'ai rencontré un paquet de SII pour des entretiens, parfois elle m'ont fait passer des tests. Bien que j'ai toujours réussi ces tests, je n'ai jamais accepté leurs emplois: pour moi le fait qu'un recruteur ne sache pas juger des capacités d'un candidat par un entretien est révélateur d'un problème de méthode et surtout dans manque de considération pour les employés et donc de problème dans le futur.
[^] # Re: je suis à la recherche d'un dev PHP
Posté par datz . Évalué à -1.
lol
[^] # Re: je suis à la recherche d'un dev PHP
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
tu refuses le test ? C'est pourtant le seul moyen de vérifier le pipo technique du VC, non ?
"La première sécurité est la liberté"
[^] # Re: je suis à la recherche d'un dev PHP
Posté par liberforce (site web personnel) . Évalué à 4.
Perso,je pense qu'un test c'est bien, mais coder pendant 3h, ça me paraît un peu abuser. En général on table plutôt sur 1h30-2h. Les questions de stress et non-familiarité avec l'environnment fourni ne sont en général pas top pour être immédiatement performant. Ensuite il est effectivement connu que beuacoup de gens surestiment leur niveau et son adeptes du pipotron et enfumage:
http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html
Mais les recruteurs cherchent également des moutons à 5 pattes, et ont pas contribué à générer cette situation. De plus un test complexe ne met pas du tout en valeur l'adaptativité du candidat sur la durée. Perso, j'ai plus confiance en quelqu'un qui me dit qu'il ne sait pas, mais qu'il sait où trouver la réponse qu'en quelqu'un qui essaiera de s'en sortir avec un pirouette.
[^] # Re: je suis à la recherche d'un dev PHP
Posté par _bingo_ . Évalué à -2.
je n'ai jamais refusé le test mais ça me donne tellement une mauvaise impression de l'entreprise que J'ai toujours refusé le poste à la sortie et préféré une autre SSII…
On me donne rendez-vous pour "un entretien d'embauche" et au final la première chose que l'on me dit c'est "interro surprise!".
C'est surement pas le cas de l'auteur du post, mais j'ai souvent constaté que les recruteurs qui font passer des tests ne connaissent pas le métier et s'en remettent à un test trouvé sur internet ou fait par un collègue.
[^] # Re: je suis à la recherche d'un dev PHP
Posté par max22 . Évalué à 3.
moi c'est plutôt l'inverse, pondre un petit bout de code ça me fait plaisir, ça change des entretiens où on te demande 3 qualités et 3 défauts, etc, etc…
et les recruteurs qui m'ont fait passer des tests au contraire connaissaient bien leur métier. contrairement à beaucoup de DRH qui font uniquement un "entretien".
[^] # Re: je suis à la recherche d'un dev PHP
Posté par Philippe F (site web personnel) . Évalué à 3.
Si je résume: quand une personne qui fait passer un test de programmation à un candidat et connait bien son métier par ailleurs, ça laisse une bonne impression au candidat. Quand elle n'y connait rien, ça laisse une mauvaise impression. Finalement, cette histoire de test, c'est un peu comme les bons chasseurs…
Perso, j'ai fait passer des tests pour recruter des stagiaires. C'est normalement entre 15 et 30 minutes et ça suffit largement pour se faire une idée des qualités de développeurs du candidat. Par contre, 3h, c'est un truc de malade! Je ferai un truc comme ça en phase 2 ou 3 du recrutement à la rigueur.
Sur un test de 15 minutes on voit immédiatement quelques paramètres objectifs:
Ensuite, on discute de son programme, on identifie ensemble des points faibles ou forts, on réfléchit à la gestion mémoire (c'est à dire, est-ce qu'il connait les concepts en dessous des outils qu'il utilise ?), à la souplesse du programme, etc.
C'est un exercice participatif, constructif et très révélateur du niveau général du candidat.
# Et sinon ?
Posté par windu.2b . Évalué à 4.
Tu voudrais de quelqu'un en télé-travail ? Je corresponds à ce que tu cherches, mais j'habite pas Lille.
(quoi ? J'ai bien le droit de tenter ma chance !)
[^] # Re: Et sinon ?
Posté par Snarky . Évalué à 1.
Ça serait avec joie de bosser avec un mec qui connait réellement le métier, ce genre d'échange et ce qu'il existe de plus formateur à mon goût.
Malheureusement pas possible le télé-travail. C'est un site de vente en ligne, mais la plus grosse partie concerne la logistique, et là, rien de tel qu'être sur place pour comprendre les contraintes. Mais si tu déménage… :p
[^] # Re: Et sinon ?
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Et alors ? Il est obligé d'être toute la semaine sur place pour scruter la logistique et adapter son projet en permanence ? Le téléphone, internet, la vidéoconférence ça n'existe pas ? les déplacements toutes les deux semaines ou tous les mois pour des réunions de synchros en face à face non plus ?
Le télétravail n'est pas prêt de se développer avec des réticences pareilles…
[^] # Re: Et sinon ?
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Pardon pour mon ton inutilement agressif. Je pense que je serai pas embauché :)
C'est parce que le sujet est un peu touchy pour moi.
# Autres métiers
Posté par max22 . Évalué à 3.
Est-ce que ça se limite seulement au métier de développeur ?
# chronomètre à 10 minutes près
Posté par _bingo_ . Évalué à 1.
Franchement, un programmeur qui chronomètre à 10 minutes près le temps qu'il passe à résoudre un problème précis ça existe? (c'est pas 1h30 mais bien 1h40!)
vous en avez déjà rencontré?
[^] # Re: chronomètre à 10 minutes près
Posté par NeoX . Évalué à 3.
git, svn et tous les outils de versionning te chronometre à la minute, voire à la seconde pret.
donc si tu fais un commit à t0, et un commit final à t1 quand ton code fonctionne,
tu peux savoir à la seconde pret le temps que tu as mis sur le projet
NB : en supposant toutefois que tu ais travaillé à 100% du temps sur ce projet, mais en 1H40, il est fort probable que l'utilisateur n'ait fait que cela.
[^] # Re: chronomètre à 10 minutes près
Posté par chimrod (site web personnel) . Évalué à 2.
Pour git pas tant que ça, puisque si tu fais un rebase interactif, tu peux effacer tes commits pour ne garder que celui de la création de la branche.
Au final, tu intègre toutes tes modifs dans un seul commit, et celui-ci est daté de l'heure à laquelle tu as commencé ton boulot, pas l'heure à laquelle tu l'as fini.
[^] # Re: chronomètre à 10 minutes près
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Ouais enfin, on parle d'un test d'entretien hein, pas d'un projet avec plusieurs branches avec pulling request et tout le toutim :)
# php quoi
Posté par CrEv (site web personnel) . Évalué à 10.
(désolé si c'est une redite, j'ai pas l'impression mais bon)
l'un des problèmes aussi c'est de chercher quelqu'un qui fait du php. Le langage je m'en fiche, mais il y a tellement de devs en PHP, tellement de devs de niveaux différents que forcément tu vas avoir beaucoup de personnes de niveau différents. Et comme c'est un langage connoté débutant ben voilà quoi.
Après, j'ai bossé avec des bons en PHP, dont certains sont lead dev aujourd'hui. Mais en général c'est des bons devs, pas des bons devs PHP.
Après mon expérience perso : j'ai déjà passé des tests, un test de 3-4h où le but était d'écrire un parser xml par exemple. Pas mal, intéressant mais au final bof.
J'ai aussi fait passer des tests, des qcm par ex (juste pour avoir une idée) et c'est vrai que voir tout le monde répondre à maxi 50% des questions est flippant. Mais souvent on ne prend pas en compte le contexte (passage d'entretien, gros stress)
j'aime de moins en moins ce genre de pratique, d'autant plus qu'elle a tendance à placer l'entreprise comme étant la meilleure, géniale, toussa, alors que c'est rarement le cas. C'est pas du tout assez symétrique comme pratique.
Si tu veux vraiment tester quelqu'un, intègre le une journée, paye-le évidemment, et là tu verra peut-être ce que ça donne.
D'ailleurs, c'est à se demander si le test est vraiment adapté. Tu dis que tu veux quelqu'un pour lire et critiquer des commits, du code ? Fait simplement du code review avec lui puisque c'est ce que tu lui demandes.
Parfois il y a des gens qui sont très bon pour te dire ce qui n'est pas bien, moins bon pour écrire très bien directement.
Donc commence peut-être par tester ce qui t'intéresse non ?
[^] # Re: php quoi
Posté par Renault (site web personnel) . Évalué à 10.
Personnellement j'aime les entretiens avec un dialogue autour d'un code.
C'est à dire que par exemple il montre un code sale ou foireux et il faut le décortiquer, le critiquer. Cela permet de voir si on comprend le code, qu'on se pose les bonnes questions ou pas puis cela permet d'établir un échange où éventuellement les deux partis peuvent apprendre de l'autre.
J'ai bien plus apprécié les entretiens où j'ai pu apprendre des trucs grâce aux recruteurs ingé que celui où j'ai répondu tout juste à leurs questions.
[^] # Re: php quoi
Posté par CrEv (site web personnel) . Évalué à 4.
Exactement. Surtout que ce qui compte est beaucoup plus la manière de réfléchir, la capacité à apprendre que juste les connaissances à un instant donné car elles évoluent.
Et je dis ça justement pour avoir changé de langage assez souvent. Genre je suis dans une boite où je suis allé parce qu'ils font de l'Ada, finalement je fais du clojure, sachant que je n'avais fait ni l'un ni l'autre avant. Autant dire qu'on aurait pu me poser des questions sur l'un ou l'autre en entretien c'était mort. Enfin tout dépend ce qu'on teste pendant l'entretien.
Et pour en revenir au sujet du post, quelqu'un pourrait être bon pour détecter des comportements idiots dans un code sans pour autant "savoir" le coder immédiatement. Parce qu'il pourrait voir des structures incohérentes, des mauvaises pratiques, etc, quelque soit le langage d'ailleurs.
[^] # Re: php quoi
Posté par Anonyme . Évalué à 0.
j'avais passé un test de QCM dans une grosse boite internationale, les candidats etaient 2 par 2 dans des salles pour y répondre.
je n'avais pas osé proposer a mon concurrent de se filer les réponses dont on n'était sur, afin de cartonner par rapport aux autres :) mais j'y pensais furieusement ! Si cela ce reproduit un jour, je tenterai sans problèmes.
# Condition particulière
Posté par Kyoku57 (site web personnel) . Évalué à 1. Dernière modification le 02 décembre 2013 à 10:18.
Comparer ton temps d’exécution à ceux de candidats qui sont mis en situation de stress n'est pas forcement pertinent. Celui qui fait le test n'est pas toujours objectif sur la durée d’exécution. Mais je fais le même constat : on a tendance à se sur-vendre.
Pourquoi ? Parce qu'on est souvent en compétition pour un poste et que le CV dans beaucoup de boite, doit déjà passé la première étape (celle du tri vers la poubelle). On va mentir pour passer cette première étape, faire un effet Wahouuh et après, on tente sa chance. Et c'est à double tranchant, car si on est mauvais, ça risque de se savoir très vite. Mais c'est le jeu ma pauvre Lucette. Quand tu es traité comme de la merde d'entretien à entretien, faut pas s'attendre à être aussi soigné dans sa présentation de soi.
Sinon, l'autre mode, on ne fait pas recruter sur un CV mais par des réseaux de confiance, des réunions User Group, des échanges github, etc … Peut-être que c'est le CV qui est obsolète et qu'il faut arrêter l'hypocrisie autour de ce document qui ne prouve rien.
La bonne nouvelle, c'est que les mensonges se découvrent assez vite et ton test a permis de faire le ménage.
Bon courage dans la recherche du mouton à cinq pattes.
PS : Je n'ai pas eu à présenter mon CV pour être recruté ;-)
# Comment "monter en compétence" ?
Posté par axel584 . Évalué à 0.
Salut,
Tout d'abord, je dois t'avouer que je trouve ça plus pertinent de tester un mec en lui donnant un vrai "projet" à faire plutôt que des QCM à la con (du style, "on a 5 variables qui ont exactement le même nom, que fait le programme ?" … euh, pour le programme, je sais pas, mais moi je flingue le dev qui est pas foutu de donner un nom intelligent à ses variables)…
D'autre part, je voudrais rebondir sur ce que tu disais sur le fait de "monter en compétence". C'est une question que je me pose beaucoup et je me demandais ce que tu faisais pour monter en compétence.
Pour ma part, je suis des cours du soir au CNAM, je lis des bouquins et j'essaye de bidouiller des petits projets persos quand j'ai besoin d'un truc. Mais je me demande si y'a d'autres pistes à suivre.
Merci pour tes conseils,
Axel
# Et les admins alors ?
Posté par mathias . Évalué à 3.
Salut : )
Ce post n'est pas là pour te rassurer en fait, j'suis admin système à l'origine et comme toi, aimant ça, j'ai avancé.
Ma formation scolaire s'arrête au bac, reprend plus tard avec une "formation qualifiante niveau BTS", en clair j'ai suivi uniquement les cours d'info du BTS info de gestion option admin. Et donc, pas un gros bagage.
Comme déjà dit, je me suis intéressé à la chose, les années ont passé et me voilà bossant au sein d'une équipe d'admins Unix (gérant la partie L2 de la maintenance système d'à peu près tout ce qui est Unix soit 4 à 5000 systèmes).
Là forcément je me sens arrivé dans la cours des grands : )
Le temps continue sont petit bonhomme de chemin, un matin, j'ai du taf (oui, ça m'arrive aussi des fois :p) et impossible de bosser : 3 collègues plus âgés discutent (braillent en fait) à propos d'un système récalcitrant ne supportant plus que le mode "single user". Ils soupçonnent alors un problème réseau.
En ayant marre (j'ai parfois besoin de calme pour réfléchir) je rentre dans la discussion, m'informe, apprends que la machine répond au ping, demande le clavier ayant à la seule console de cette machine et tente de lancer SSH. Si SSH marche, fini le problème réseau et fini le problème d'une seule connexion simultanée. Si ça marche, ils pourront donc bosser chacun de leur poste et avancer, du moins c'est l'idée…
SSH râle. Un problème de droit dans /var pour que SSH crée les fichiers nécessaires (.pid ou autre). Donc, changement de droits, relancement de SSH, qui marche.
Là, il est presque 13h, j'ai faim et ce système ne fait pas partie de mon contrat. Je me sauve acheter à un casse-croûte (j'suis toujours à la bourre, n'ayant pas bossé sur ma propre partie), leur explique que SSH marche, qu'il est temps d'oublier le problème réseau (cette machine répondait pourtant déjà au ping…).
Je rentre, je demande où ils en sont, on me répond qu'ils sont sur un piste prometteuse : sans doute un problème réseau.
Et ça, avec SSH qui marche toujours et une machine qui répond au ping, qui peu en envoyer…
Finalement c'était un vilain "chown -R toto:toto / home" qui avait modifié les droits de tout le système (modulo le ctrl + C possiblement effectué par l'admin ayant fait cette erreur, et là encore, j'suis pas certain que ce gars là se soit inquiété le moins du monde d'un chown qui dure plusieurs minutes sur un répertoire vide).
Pardon pour le pavé, mais effectivement la faune des informaticiens peu parfois surprendre…
# mieux vaut tard que jamais
Posté par abdeslem_ . Évalué à 2.
Bonjour,
Je viens de tomber sut ton poste, et je voulais réagir. je vois que cela date de 2 mois ….. mieux vaut tard que jamais. et puis ça pourrais toujours servir à quelqu'un.
Ayant vécu une situation similaire , voici ce que je peux dire:
1er constat, je dirais que c'est une situation complètement "normale" (pour ma part, je boss en Algérie, mais je pense que les contextes restent similaires). dans la masse de développeurs , beaucoup sont très moyens, certain sont médiocre, et quelque un sont bon voir très bon. Mais la majorité se considèrent comme étant "un bon développeur" :)
Partant de ce constat, on peut être tenté de revoir ses critères de recrutement à la baisse (surtout, si comme pour mon cas, on subit une pression -compréhensive- de la part de la direction pour recruter au plus vite, histoire de se lancer "au plus vite" sur les projets,et de les finaliser -encore une fois- "au plus vite" :)
GROSSIÈRE erreurs ** , **NE BAISSER JAMAIS VOS CRITÈRES, celui qui devra gérer les merde d'un mauvais développeur, c'est celui qui l'a recruté de toute façon :)
La raison est simple, n'étant pas un ouvrier,
un mauvais développeur, aura besoin de beaucoup plus de temps pour corriger sa façon de faire, si au départ , sa compréhension du développement (notamment de la POO) est erroné, PIRE encore, il pensera que ces solutions sont bonnes, et que les autres veulent juste se compliquer la vie à penser générique , réutilisable, maintenable …. c'est pas en 2 jours qu'on change complètement sa façon de penser le DEV.
ALORS que même un ouvrier stupide, peut rapidement corriger sa manière de mettre une pièce dans une machine!!!
cette subtilité échappent parfois à la direction et aux services RH.
Autre chose, en recrutant vite , on aura l'impression, qu'on a plus qu'a se lancer sur le projet, et qu'on a gagner du temps ……………. N'IMPORTE QUOI, les soucis qui seront engendré par un mauvais développeurs cause plus de tor au projet que le fait de ne pas en avoir:
1. Code bugué
2. Intégration difficile , vu la rigidité des solutions
3. Mise à jour et maintenabilité du code complexe, voir Impossible dans certain cas
4. Stresse permanent dû au fait de croire qu'on avance alors qu'on sait pertinemment, que ça sera revue et REFAIT
5. Pour bien Expliquer à un mauvais ce qu'il faut faire et comment le faire, il faut aller dans TOUT LES DéTAILS possible …… franchement , autant le faire soit même
6. Impact négatif pour l'esprit d'équipe. les BON développeurs Aiment bosser avec de BON développeurs…. ils sentirons qu'ils reculent s'il bossent avec des mauvais qui leur apportent rien
7……………………. franchement, je préfère m’arrêter la, car ça me rappel de mauvais souvenirs.
Bref pour résumer, je dis toujours la chose suivante:
"je préfère être sous staffé, que MAl staffé"
Concernant le test de recrutement, j'ai également testé cette façon de faire , qui consiste à donner une travail à faire en 3h (pour ma part aussi, c'était 3 heures) ……….. Mais je dois avouer que ça ne fonctionne pas très bien.
je pense que les raisons sont les suivantes:
- La stress de l'entretien est un facteur qu'on néglige, mais il est extrêmement important. il y a des gens qui gèrent mal le stresse, ça ne fait pas d'eux de mauvais développeurs pour autant.
- Il est difficile de résumer toutes les notions nécessaire au poste dans un seul exercice.
- Franchement, je ne coderais pas de la même façon pour un test sans suite de 3 heures, que dans le cadre d'un projet bien claire et bien structuré …..
ce que je recommande, (que j'ai testé, et qui jusqu’à aujourd’hui fonctionne plutôt bien), c'est de faire un entretien NORMAL (tu parles avec le gars, de ce qu'il veut faire, de sa vie etc….) et par la suite de passer au volet technique avec des petites questions-exercices bien précise (nécessitant au plus 5 minutes de réflexion) chacune relative à un sujet particulier, selon les besoins du poste (POO, SQL, HTML, Conception ….) histoire de faire le tour de la façon de réfléchir du candidat.
le tout, en offrant du papier brouillon et un stylo au candidats, pour les aider à réfléchir … voir à écrire du code.
Ajouter à cela des questions d’intelligence d'ordre général (pas des questions pieges) , nécessitant un cerveau bien huilé (généralement, avec des chiffres et des maths)
ce qui comptera par la suite, ce n'est pas tant, le fait que les réponses soient juste ou pas, Mais surtout la façon de réfléchir et la manière de considérer les problème.
Ah oui, autre chose de trés important,
ce n'est pas parce que tu n'aurais pas fait les chose comme lui l'a fait, que c'est forcement mauvais ;)
voila, bon courage et bonne continuation.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.