Ca sert surtout à donner du boulot au RH, s'autosatisfaire des tests qu'ils ont conçus, etc...
Version imprimable
Bonjour à tous,
Je me souviens en 2010, lorsque je passais mon tout premier entretien d'embauche en tant que développeur PHP. J'avais subi le même stress, je n'avais jamais développé réellement en PHP sauf de petits programme de connexion à une base de données, de petits sites de présentation d'images. En fait la chance que j'avais eu est que j'avais été briefé par un ami qui travaillait dans cette entreprise sur le type de questions.
Sans être trop sceptique, je n'ai vraiment pas trop apprécié cette suite de question technique sur le PHP et à la fin l'interviewer me demande d’écrire un code PHP pour se connecter à une base de données sur un tableau a marqueur.
Moi à cette époque j'étais très attiré par le JAVA, j'étais plus attirée par le JAVA et heureusement deux semaines après j'ai été appelé et malheureusement pour eux, j'avais déjà trouvé un job en JAVA.
Cool, c'était juste pour partager mon expérience. Je partage l'avis de Jon Evans. Allez bonne journée...........
En fait, on a un problème avec pas mal de gens qui postule...
Des mecs qui t'envoies un CV qui dit qu'ils savent utiliser power point et qui postule pour un poste de développeur... Ce genre de CV, les RH les trie direct.
Après, pour répondre aux questions... non, on n'interroge pas sur une techno que les gens ne connaissent pas.
C'est a ca que nous sert la fiche d'auto évaluation.
Et oui, on a le temps de développer a coté, même si ca prends du temps, on préfère bien sélectionner et garder les gens, plutôt que de prendre n'importe qui et d'avoir une équipe bancale(qui sur le long terme demande plus de recrutements)
Par contre, pour les fan du projet technique, j'ai comme un soucis...
déjà, ca prend un max de temps... en plus, l'important n'est pas juste de livrer un code de qualité, mais de la faire dans le temps imparti. Voir un projet vitrine fait en 10 fois plus de temps que ce que je pourrais payer... bof
En plus, il va forcement y avoir pas mal de monde qui fera ce projet, et le gardera sous le coude pour 6 mois ou 1 ans... voir 5... pas super intéressant.
Pour les projets réels, c'est bien joli quand le projet est public, mais ca n'a jamais été mon cas... le projet a toujours été mis en place et inaccessible depuis le net. Et c'est toujours difficile d'estimer la part qu'a fait un développeur...
Mon idée du CRUD en 30-45 minutes n'est pas une mauvaise idée ;)
Avec un pc sans internet, un serveur web, mysql (avec la base de créé), et la doc php en mode hors ligne :)
CRUD: Create Read Update Delete, (tableau de listage des enregistrements, formulaire d'ajout/modification/affichage)
Note: ce qui est important:
1. est-ce que le candidat estime avoir le temps de faire l'exercice, si non quel partie il pense avoir le temps de faire dans le temps imparti
2. l'application fonctionne t'elle à la fin ?
3. qualité du code (commentaire, nomenclature des fonctions/variables)
4. discussion au sujet du code fourni (ce qu'il améliorerait si il avait plus de temps...)
Je trouve que l'auteur se tire un peu une balle dans le pied avec ce titre "The Technical Interview Is Dead".
De loin on peut penser que poser des questions techniques c'est mal, et pourtant quand on regarde point par point ce qu'il propose, il y a de la technique à l'étape 1 et 5 du processus de recrutement, et même beaucoup de technique. Je ne vois pas trop en quoi faire du pair programming avec des éventuels futurs collègues sur un projet pendant une semaine n'est pas aussi une forme de "passer sur le grill d'un test technique", au moins au début.
Et dire "l'entretien technique est mort" quand on affirme d'autre part que les brainteasers (tests de logique générale) ne servent qu'à recruter des gens qui ne savent pas coder... mouais :roll:
Ben si tu regardes bien l'étape 1 qui est éliminatoire, c'est exactement ça, pas derrière une table mais "ideally online".
Je suis 100% d'accord avec le fait de tester un candidat dans des conditions proches de la réalité, mais c'est le titre qui me chiffonne. J'interprète peut être mal mais il me semble que le recruteur qui ne prendra pas la peine de lire tout l'article se dira "ah ouais, il vaut mieux ne faire que des tests non-techniques"...
Oui : "Hire them on a paid basis"
Je ne suis pas d'accord sur cette partie là. Une StartUp, c'est une entreprise qui vient de naître, sans expérience, non cotée en bourse, plus orientée projet que business.
Stock Options => tu rêves
Tu trouves beaucoup de sociétés qui te donnent un pourcentage sur les ventes à une nouvelle recrue ?
Le "Sévérence Pack", c'est pareil. Une StartUp a déja du mal à trouver des financements au début. Ils te payent ton salaire, puis éventuellement une indemnité à la fin si le projet bat de l'aile, mais c'est loin d'être une obligation. Mais y a toujours des arrangements dans ce cas.
Ce que j'ai le temps de faire en 45 min : ranger mes affaires et me barrer. Car en si peu de temps, je ne peux produire que de la merde. 45 min c'est le temps qu'il me faut pour coder proprement le calcul de la suite de Fibonacci.Citation:
Mon idée du CRUD en 30-45 minutes n'est pas une mauvaise idée
Avec un pc sans internet, un serveur web, mysql (avec la base de créé), et la doc php en mode hors ligne
CRUD: Create Read Update Delete, (tableau de listage des enregistrements, formulaire d'ajout/modification/affichage)
Note: ce qui est important:
1. est-ce que le candidat estime avoir le temps de faire l'exercice, si non quel partie il pense avoir le temps de faire dans le temps imparti
2. l'application fonctionne t'elle à la fin ?
3. qualité du code (commentaire, nomenclature des fonctions/variables)
4. discussion au sujet du code fourni (ce qu'il améliorerait si il avait plus de temps...)
Quant à ne pas avoir accès à Internet, c'est encore plus crétin. En 2013, une boite qui n'a pas le Web, faut qu'elle se pose des questions. Je travaille connecté en permanence et je double check tout.
Après si vous voulez juste recruter un pisseur de code bidon, bah autant économiser mes 45 min, pour les passer avec mes enfants, et aller voir ailleurs où on fait de la qualité...
Mouais...Quand tu dis que tu as bossé sur des projets en .NET 3.5 et 4.0, on te sert des trucs sur du .NET 1.0, complètement has been, que tu n'as jamais touché (car pas assez vieux) et dont les mécanismes sont assez différents.
Encore faut-il que le temps imparti ne soit pas taillé à la serpe, t'obligeant à faire à l'arrache une bidouille qui va créer d'autres problèmes par la suite...
Honnêtement c'est ça qui m'a fait arrêter les SSII. Tu peux très bien faire du code de qualité dans le temps imparti. Sauf que dans les boîtes où tu travailles pour une entreprise et non un utilisateur final, on te force à faire de la merde ! Tu leur signale des erreurs corrigeable en 15 minutes, ils t'envoient chier parce que personne ne s'est plaint...jusqu'à ce qu'ils se plaignent et où à ce moment les 15 minutes on les a pas forcément. Et évidemment, t'as souvent droit à l'"historique", fait de façon pourrie, ne satisfaisant pas les utilisateurs (performances, bidouilles à faire, bugs récurrents mais c'est comme ça...) et difficile à maintenir. Bref, quand un "client" décide à la place de ses utilisateurs, et ce avec une simple logique business, l'ambiance est pas top.
Je me souviens d'une fois où on nous a refusé une livraison : Pourquoi ? Parce qu'on avait multiplié par 3 les performances de l'appli et que ça n'avait pas été demandé...
Je l'ai fait d'une SSII (qui devait quand même s'occuper de la gestion de la signalisation d'une ville !)
Un nouveau projet en .NET en 2013.
- En quoi allez vous le faire ? => C#, .NET 3.5, Winforms
- Pourquoi ne le faites vous pas en WPF (remplaçant des Winforms) ? => Parce qu'on n'a pas les compétences.
- Heu... WPF ça date de 2008 quand même et on est en 2013, d'autant que les Winforms ne sont plus supportés par Microsoft => "mouche qui volent..."
J'ai pour ma part eu les 2 cas :
- en SSII ou chez un client, il m'est arrivé de répondre à des questionnaires techniques, ça peut être intéressant tout de même pour le recruteur pour se faire une idée des compétences du candidat, en tout cas ça permet de détecter des gens dont le CV est super mais qui sont un peu "bidon"
- Avant d'entrer dans ma boîte actuelle j'ai eu droit à un questionnaire technique + un petit projet à implémenter en 30-45 min, rien d'utilisable pour la boîte je précise il s'agit juste de voir comment le candidat se sert de l'IDE et architecture un mini-projet (par exemple s'il met tout le code dans une seule classe, c'est embêtant ..)
Personellement que ce soit un questionnaire technique ou un mini-projet, je ne trouve pas ça insupportable à condition que ce ne soit pas trop long, mais ça doit être un complément à l'entretien plus axé sur les expériences et les souhaits du candidat...
On est parfaitement d'accord.
Au cas où tu ne l'aurais pas remarqué, les questions sont rhétoriques. (*) :mrgreen:
On sait parfaitement qu'en travaillant pour ce genre de société :
- le travail sera exigeant
- le salaire sera en dessous de tout
- si on contribue au succès de l'entreprise, on n'en retirera aucun bénéfice (à moins d'avoir des parts dans la société)
Et je comprends parfaitement ta réaction ("mais tu rêves !") car c'est la réaction attendue... :mrgreen:
En effet, j'ai remarqué une chose : quand quelqu'un essaye de te faire passer des vessies pour des lanternes (par exemple : te proposer un boulot soi-disant "exceptionnel"), ça ne sert à rien de dire "non", car ils ont une fâcheuse tendance à revenir à la charge (surtout si c'est un commercial :roll:).
À la place, je trouve beaucoup plus efficace de mettre la barre extrêmement haut en ce qui concerne tes conditions. La réponse ne se fait généralement pas attendre (un truc du genre : "mais vous êtes complètement fou !"), ce à quoi tu réponds innocemment : "ah ben ça fait une heure que vous me baratinez et vous ne m'avez toujours rien proposé. Moi je vous ai fait une proposition, maintenant c'est pas de ma faute si vous la refusez... (:whistle:)".
Je sais, c'est mesquin, mais il faut arrêter de prendre les gens pour des cons... :aie:
(*) "Une question rhétorique (ou question oratoire) est une figure de style qui consiste à poser une question n'attendant pas de réponse, cette dernière étant connue par celui qui la pose" [wikipedia]
Pour plussoyer Pcaboche, en SSII, on m'a proposé un poste à Lille. 2 heures de transport depuis Paris, ou, éventuellement, l'hotel. Le poste étant pile dans mes compétences, j'aurais pu dire "Non", ça aurait été mal perçu. Donc, manoeuvres dilatoires :
"Euh, j'habite en grande banlieue, et ma femme ne conduit pas[jusque là tout est vrai], donc idéalement, je serais en télétravail le mercredi, avec hotel le lundi et le jeudi soir".
"Bon, bon, je te rappelle avec le feedback du client"[il n'a jamais rappelé, comme c'est étrange].
Ce que veut dire Pcaboche, je l'élargirais ainsi : quand tu fais face à des gens qui veulent te couilloner, et savent le faire avec élégance, la defense "contre-attaque, c'est moi qui vais te couilloner" est d'une grande efficacité.
Aucun risque : au pire, ça marche, et j'ai mon mercredi à la maison(ou Pcaboche ses stock-options). Mais le cas normal(au moins 99% du temps), c'est que ça finit enterré. Et c'est déjà bien(on évite la couillonade).
Après, pour revenir au sujet, je dirais que juger de la valeur d'un dev(ou d'un homologateur), c'est diablement compliqué, et que je n'ai pas vu de méthode applicable sans souci. La plus efficace, à mon gout, c'est la période d'essai, mais si on s'est gourré, on a pris un mois dans la vue.
En 45 minutes vous n'avez pas le temps au moins de faire le R du CRUD ? à savoir un tableau listant les enregistrements d'une base avec un bouton pour afficher en detail ?
De plus dans mon point 1 je demande au candidat:
L'accès internet c'est pour éviter qu'il aille chercher du code à copier coller ailleurs, on veut voir ce que le candidat sait faire de lui-meme avec la documentation nécessaire.Citation:
1. est-ce que le candidat estime avoir le temps de faire l'exercice, si non quel partie il pense avoir le temps de faire dans le temps imparti
Avec l'expérience de certains mauvais profil recruté sans tests technique, je peux dire que ces 45 minutes investi lors du recrutement éviteront de perdre une semaine en recrutant le mauvais candidat (une semaine pour se rendre compte de son niveau)
J'ai connu sur des projets, ou l'on s'était aperçu trop tard que la personne codait beaucoup trop lentement, voir n'arrivait pas a se débugé elle-même sur des problèmes simple :( obligé de gardé le profil 3 mois de plus (plus le temps de faire des recrutements/former un nouvel arrivant
Avec ce genre de tests on aurait vu tout de suite le problème...
Faut se méfier, des fois les réponses ne sont pas celles attendues.
"el_slapper, tu vas nous faire ce traitement en COBOL/MVS"
"C'est ballot, les données sont sous UNIX, les référentiels sont sous UNIX, nous fournissons le fichier final sous UNIX, et les transferts entre UNIX et MVS ne marchent jamais, ici. Ca va couter bonbon en maintenance. Et on a plein de gens comme Christine qui rêvent de faire du JAVA - et qui savent faire."
"Oui, mais le développement COBOL coute deux fois moins cher que le développement JAVA. La maintenance, c'est pas notre budget, c'est le votre, alors on s'en fout."
"Pauvre Christine...et pauvre budget maintenance."
2 ans plus tard, les transferts plantaient toujours régulièrement. Plus tard, en cours de management, on m'a appris que la MOA était une aberration purement française, parceque c'est donner bien trop de pouvoir au client. J'avais un exemple en tête tout trouvé pour illustrer.
Et, pour revenir au sujet, Christine avait été recruté suite à un test technique en Java. Pour, au final, faire du cobol. Et, contrairement à moi, elle n'aimait pas le cobol.
Pauvre Christine...:aie:
pour ma part je me souviens avoir fait un test très poussé chez un client.
c'était pour un poste orienté optimisation et perf sur de la volumétrie.
1) il demande de me donner une note sur 5 points sur : php, js, html, SQL, shell.
je me donne respectivement qq chose comme 5,3,4,5,3.
On me pose tout un tas de question sur les performances de PHP, CLI, le fonctionnement interne de PHP. Comment je résoudrais tel ou tel problème. Comment je gérerai tel type de problème de performance. etc..
On me sort un test bidon en PHP sur un problème qu'ils ont eu, où j'ai eu une démarche qui est différente de la leur et plus performante au final.
Même topo pour SQL, et MySQL cluster, en commençant pars des questions simple du style comment démarrer un noeud. Après des questions sur comment je ferais un moteur de recherche. Comment j'ajouterai tel ou tel fonctionnalité.
Système je répond en 2 ou 3 mouvements à toute leur question :
- qu'est ce que fait le commande diff
- qu'est que fait la commande cmp
- la difference entre cmp et diff
- qu'est ce qu'un vhost ...
Js me rappelle pas avoir eu des questions dessus
et Là on arrive au html :
comment ferait vous un texte centrer avec une image de fond sur un bouton pour valider un formulaire et qui s'affiche identique quelques soit le navigateur ... (sans css et sans js)
j'ai pas su répondre ... (sachant que input + type submit était pas la solution)
Verdict après l'entretien :
très bon niveau en perf / optim / volumétrie (retour à chaud de la part des clients comme des commerciaux)
Retour une semaine après :
On a juger que j'étais pas assez modeste et que j'aurais pas du me mettre des notes aussi hautes. et que le tekos déjà sur place (qui était bon aussi ne serais pas mis une note supérieur à 3). Et que j'avais une expérience trop succincte en SEO (même en ayant répondu à toutes les questions)...
Exactement ! :ccool:
(+1 pour toi aussi ;))
C'est tout à fait ça ! On fait une proposition en se disant que ça ne passera jamais, mais au moins on aura la paix.
(par contre, si jamais un jour ça passe, c'est la fête ! http://estrip.org/content/users/paul...banana1655.gif)
Bon, ok, on a un peu dévié du sujet original. Cependant je trouve ça intéressant de pouvoir parler de ces choses là sur un forum public, parce qu'on n'a pas encore de tuto "apprendre à négocier avec des commerciaux véreux". :aie:
Désolé j'avais pas vu l'aspect réthorique de la chose. Donc je ne peux que plussoyer si je m'aperçois qu'on essaie de me couilloner (ça arrive souvent).
Non parce qu'en général (de mon expérience), en StartUp, on n'a pas encore l'art de la langue de bois et le caractère faux cul qui va avec.