Je suis d'accord avec la solution proposée par le Croco, mais je me demande si le recruteur ne demandait pas implicitement également ça.
Que ce soit dans dans une ToDo, en commentaire, en discussion (s'il y a eu discussion à la suite), en warning, etc.
Cela n'est pas improbable que lorsqu'on dév', on pense à un cas, auquel le client n'a pas pensé, auquel même les specs n'ont pas répondu, etc. Je pense que le signaler aurait permis de mettre en avant que bien qu'on ait codé ce qu'il fallait, on ait démontré un minimum de recul et de s'être projeté un peu en amont.
Maintenant, dans le délai des 20 minutes ? On ne saura sûrement jamais (juste des spéculations) sur les points essentiels qu'attendait le recruteur, mais bon. En tout cas, si on me dit arrête de penser et code, j'suis pas sûr d'être intéressé.
Sinon, merci Geoffrey pour ce p'tit partage, j'trouve ça très intéressant et instructif sur ce que pourrait donner des p'tits entretiens techniques. Je n'ai eu que des questions (à réponses courtes) pour ma part, sur lesquelles je ne me suis pas trop mal démerdé.
Pour les 2 entretiens techniques que j'ai eu, c'était une fois ca (avec des questions avant) et l'autre entretien technique (y'a qqs mois de ca) c'était des questions super pointues sur grand central dispatch.
Juste un éclairage du point de vue du recruteur ...
Je communique toujours à mes candidats le déroulement de l'entretien (durée, mises en situation, exercices, ...), les qualités recherchées ainsi que les sujets techniques qui seront abordés. Suivant le niveau de complexité, je leur communique 3 à 5 jours avant l'entretien afin qu'ils aient un peu de temps pour bachoter, mais pas trop. Parfois je leur donne carrément les liens Internet. Je leur indique également qu'ils peuvent me contacter avant l'entretien s'ils ont des questions.
Cette transparence me permet :
- de (tenter de) les mettre à l'aise ; je veux qu'ils soient le plus détendus possible (si c'est possible) lors des entretiens
- d'évaluer leur niveau de motivation (ceux qui ont préparé, ceux qui n'ont rien foutu)
- de tester leur capacité d'adaptation et d'apprentissage (ce qui est souvent plus important que les connaissances brutes)
J'ai constaté en outre, depuis que je pratique ainsi, que j'ai un taux de défection important (et d'ailleurs certains candidats n'ont même pas la politesse d'indiquer qu'ils ne se présenteront pas). Je pense que c'est de l'auto-sélection ; la plupart de ceux qui ne se sentent pas à la hauteur préfèrent décliner. ça me fait moins de boulot !
Oui jpimbert, j'aime bien ta manière de fonctionner, ça me rappelle la manière de fonctionner de Xebia. Ils donnent un projet à faire avec des tableview, des webservices, des petites vues customs ... et ils m'ont dit "Dès que tu as fini, tu reviens vers nous" et ensuite tu dois expliquer devant une personne technique, les choix que tu as fait, les librairies utilisées et pourquoi ...
Le risque étant dans ce cas que la personne se fasse aider. La avec un exo au dernier moment et un temps court, sauf si la personne n'est pas seul (genre j'aurais ramené Ali devant mon PC), t'es quand meme plus sur que c'est bien l'interviewé qui fait l'exo.
Les commentaires que tu as mis qui ne sont pas pertinents ( // First we remove empty space,...)
Je ne dirais pas forcément que dans le cas d'un test ce genre de commentaires ne soit pas pertinents.
Certes, c'est obvious vu la ligne, mais cela peut appuyer le fait que tu aies vu tel truc. Si tu n'as pas d'entretien oral par la suite expliquant tes choix, je trouve cela intéressant.
Que ce soit dans dans une ToDo, en commentaire, en discussion (s'il y a eu discussion à la suite), en warning, etc.
S'il n'y a pas de discussion, c'est dommage.
J'ai fait passé des tests quand je faisais un peu de recrutement, la correction et la discussion qui suit le test est aussi riche que le test lui-même.
C'est important de ne pas être trop nul dans le test mais ce qui est encore plus important c'est le comportement dans la discussion qui suit.
Est-ce que la personne comprend les suggestions de corrections, et rebondit en proposant d'autres améliorations, est-elle cooperative ou aggressive, accepte-t-elle les critiques sur sa solution, reconnait-elle ses erreurs, a-t-elle une logique "saine", etc
C'est surtout un prétexe à tester une petite séance de travail avec la personne.
Dans ce cas c'est assez dommage voire débile de leur part. La justification du candidat sur ses choix et comprendre comment il raisonne est aussi voire plus intéressant que le test lui même.
Pour ma part je fais passer pas mal d'entretiens techniques et je fais souvent faire un exercice au candidat, soit immédiatement après l'entretien soit bien plus souvent je lui demande de me fournir son code quelques jours après (ainsi il a moins la situation de stress et le temps de faire les choses bien). Croyez-moi, bien qu'ils aient le temps pour produire leur code ça veut pas toujours dire qu'ils produisent du bon code propre... donc ça permet tout autant de faire une sélection. Et du coup j'en rediscute généralement avec eux lors de l'entretien d'après.
Rien mais crois moi ça se voit comme le nez au milieu de la figure quand c'est le cas. Il est incapable de reexpliquer son code et même s'il y arrive ça ne correspond pas à son discours lors des entretiens donc ça se sent tout de suite.
@ali : du coup qu'est ce qui empêche le candidat de demander de l'aide ?
Aucune.
Mais je vais partir de ma petite expérience. Je consulte régulièrement StackOverFlow/CocoaCafe et consorts.
Souvent, pour trouver quels type d'objets pourrait faire ce que je veux. Il m'arrive de copier/coller leur snippets, mais à moins qu'il ne soit simple (2 lignes basiques), je le bidouille, et regarde la doc. Si je ne l'ai pas compris, en général je ne l'utilise pas.
Maintenant, rien n'empêche @Ali de demander ce que le candidat a vraiment voulu faire, pourquoi faire ça, etc. Si je n'ai pas compris les lignes de code que j'ai c/c, ça ne sert à rien de mon point de vu personnel/expérience.
Non mais imaginons que j'ai un exo, je demande à un collègue plus expérimenter de bosser avec moi, on fait le truc niquel et on le commente comme il faut. 99% de chance que j'enfume la personne en face de moi.
Après j'imagine que faire ca c'est déjà faire montre de motivation !
J'ai passé un entretien me demandant de faire un ensemble de fonctionnalités d'une application simple et j'avais tout le week-end pour le faire.
En gros dans le test :
Plusieurs requêtes http...
Gestion d'un cache...
Proposition de l'ergonomie de l'application.
....
Ne pas utiliser de librairies externes
Mettre les les meilleurs pratiques de l'Objective C/Cocoa.
Tests unitaires.
....
Ensuite il faut remettre son travail et en cas ou ils estiment que tu as bien fait le travail demandé, il t'appellent pour l'entretien technique et la suite.
Pourquoi je trouve ça le meilleur moyen de recruter ?
1. On te laisse le temps sans te stresser à fournir le meilleur de toi même dans des bonnes conditions.
2. Tu ne peux pas tricher, parce que y a peu de gens qui vont t'aider à réaliser un travail d'une journée ou deux.
3. Tu dois défendre ton travail à la fin.
4. ça va monter ta réelle motivation à intégrer leur équipe en passant deux jours rien que à passer le test.
Bon j'ai échoué parce que j'avait la flemme de le faire tout un week-end, mais je pense que c'est le meilleur test que j'ai vu pour l'instant parce que il est complet de point de vue technique.
C'est pas mal oui, après le test "en 20 minutes" permet aussi de tester ta capacité à travailler dans le stress.
Après c'était pour un taf en Suisse, pour une boite qui a les moyens et qui a fait tourner l'annonce sur pas mal de site pointus, donc j'imagine qu'ils cherchaient du lourd.
Il y a des choses que tu ne sais pas trop si il faut vraiment approfondir ou pas lors de traitement de l'exercice par écrit. Par exemple l'immutabilité de la classe Iban. Si on prend la solution d'@Aligator pour ce point avec une property readWrite, la classe reste toujours mutable vu le dynamisme du langage Objective C.
Oups je viens de muter la classe Iban . Donc tout ça se sont des choses qu'on peut dire à l'entretien qui ne sont pas forcément bonnes à mettre par écrit.
Réponses
Pour info, voila ce que j'avais pondu (j'ai pas fait le 2- et le 3-, m'aurait manqué 10mn)
J'ai pas pensé à overidder description (c'est très fin
)
En y regardant à nouveau, il me manquait beaucoup
Je vais rejoindre un peu FKDEV.
Je suis d'accord avec la solution proposée par le Croco, mais je me demande si le recruteur ne demandait pas implicitement également ça.
Que ce soit dans dans une ToDo, en commentaire, en discussion (s'il y a eu discussion à la suite), en warning, etc.
Cela n'est pas improbable que lorsqu'on dév', on pense à un cas, auquel le client n'a pas pensé, auquel même les specs n'ont pas répondu, etc. Je pense que le signaler aurait permis de mettre en avant que bien qu'on ait codé ce qu'il fallait, on ait démontré un minimum de recul et de s'être projeté un peu en amont.
Maintenant, dans le délai des 20 minutes ? On ne saura sûrement jamais (juste des spéculations) sur les points essentiels qu'attendait le recruteur, mais bon. En tout cas, si on me dit arrête de penser et code, j'suis pas sûr d'être intéressé.
Sinon, merci Geoffrey pour ce p'tit partage, j'trouve ça très intéressant et instructif sur ce que pourrait donner des p'tits entretiens techniques. Je n'ai eu que des questions (à réponses courtes) pour ma part, sur lesquelles je ne me suis pas trop mal démerdé.
Pour les 2 entretiens techniques que j'ai eu, c'était une fois ca (avec des questions avant) et l'autre entretien technique (y'a qqs mois de ca) c'était des questions super pointues sur grand central dispatch.
Juste un éclairage du point de vue du recruteur ...
Je communique toujours à mes candidats le déroulement de l'entretien (durée, mises en situation, exercices, ...), les qualités recherchées ainsi que les sujets techniques qui seront abordés. Suivant le niveau de complexité, je leur communique 3 à 5 jours avant l'entretien afin qu'ils aient un peu de temps pour bachoter, mais pas trop. Parfois je leur donne carrément les liens Internet. Je leur indique également qu'ils peuvent me contacter avant l'entretien s'ils ont des questions.
Cette transparence me permet :
- de (tenter de) les mettre à l'aise ; je veux qu'ils soient le plus détendus possible (si c'est possible) lors des entretiens
- d'évaluer leur niveau de motivation (ceux qui ont préparé, ceux qui n'ont rien foutu)
- de tester leur capacité d'adaptation et d'apprentissage (ce qui est souvent plus important que les connaissances brutes)
J'ai constaté en outre, depuis que je pratique ainsi, que j'ai un taux de défection important (et d'ailleurs certains candidats n'ont même pas la politesse d'indiquer qu'ils ne se présenteront pas). Je pense que c'est de l'auto-sélection ; la plupart de ceux qui ne se sentent pas à la hauteur préfèrent décliner. ça me fait moins de boulot !
Oui jpimbert, j'aime bien ta manière de fonctionner, ça me rappelle la manière de fonctionner de Xebia. Ils donnent un projet à faire avec des tableview, des webservices, des petites vues customs ... et ils m'ont dit "Dès que tu as fini, tu reviens vers nous" et ensuite tu dois expliquer devant une personne technique, les choix que tu as fait, les librairies utilisées et pourquoi ...
J'ai beaucoup aimé cette manière de faire.
Le risque étant dans ce cas que la personne se fasse aider. La avec un exo au dernier moment et un temps court, sauf si la personne n'est pas seul (genre j'aurais ramené Ali devant mon PC), t'es quand meme plus sur que c'est bien l'interviewé qui fait l'exo.
T'avais le droit à la doc des APIs ou pas ?
Tu connais par coeur la syntaxe de [NSString getCharacters: ...] ?!
J'étais sur mon MBP, donc j'avais tout, mais pas sur xCode (donc l'autocompletion oublie) et 20mn ca passe vite
Aller, balance....
Quelle boite ?
@Geoffrey :
C'est vrai que 20 minutes c'est peu dans un entretien d'embauche avec le stress... mais il falaise faire correctement ce que tu as commencé.
Par exemple accéder au property dans le init peu être impardonnable pour un certain niveaux.
L'immutabilité...
Les commentaires que tu as mis qui ne sont pas pertinents ( // First we remove empty space,...)
Moi j'aurais fais pire que toi vu mon stress aux entretiens
Bon courage.
Je ne dirais pas forcément que dans le cas d'un test ce genre de commentaires ne soit pas pertinents.
Certes, c'est obvious vu la ligne, mais cela peut appuyer le fait que tu aies vu tel truc. Si tu n'as pas d'entretien oral par la suite expliquant tes choix, je trouve cela intéressant.
j'ai bien prit conscience de mes faiblesses ^^
moi ça fait 3 jours que je veux comprendre les anchorPoint de CALayer et j'arrive toujours pas ^^
S'il n'y a pas de discussion, c'est dommage.
J'ai fait passé des tests quand je faisais un peu de recrutement, la correction et la discussion qui suit le test est aussi riche que le test lui-même.
C'est important de ne pas être trop nul dans le test mais ce qui est encore plus important c'est le comportement dans la discussion qui suit.
Est-ce que la personne comprend les suggestions de corrections, et rebondit en proposant d'autres améliorations, est-elle cooperative ou aggressive, accepte-t-elle les critiques sur sa solution, reconnait-elle ses erreurs, a-t-elle une logique "saine", etc
C'est surtout un prétexe à tester une petite séance de travail avec la personne.
Pas de discussion
Pour ma part je fais passer pas mal d'entretiens techniques et je fais souvent faire un exercice au candidat, soit immédiatement après l'entretien soit bien plus souvent je lui demande de me fournir son code quelques jours après (ainsi il a moins la situation de stress et le temps de faire les choses bien). Croyez-moi, bien qu'ils aient le temps pour produire leur code ça veut pas toujours dire qu'ils produisent du bon code propre... donc ça permet tout autant de faire une sélection. Et du coup j'en rediscute généralement avec eux lors de l'entretien d'après.
@ali : du coup qu'est ce qui empêche le candidat de demander de l'aide ?
Ok, en tout cas j'aurais appris plein de trucs
Aucune.
Mais je vais partir de ma petite expérience. Je consulte régulièrement StackOverFlow/CocoaCafe et consorts.
Souvent, pour trouver quels type d'objets pourrait faire ce que je veux. Il m'arrive de copier/coller leur snippets, mais à moins qu'il ne soit simple (2 lignes basiques), je le bidouille, et regarde la doc. Si je ne l'ai pas compris, en général je ne l'utilise pas.
Maintenant, rien n'empêche @Ali de demander ce que le candidat a vraiment voulu faire, pourquoi faire ça, etc. Si je n'ai pas compris les lignes de code que j'ai c/c, ça ne sert à rien de mon point de vu personnel/expérience.
Non mais imaginons que j'ai un exo, je demande à un collègue plus expérimenter de bosser avec moi, on fait le truc niquel et on le commente comme il faut. 99% de chance que j'enfume la personne en face de moi.
Après j'imagine que faire ca c'est déjà faire montre de motivation !
J'ai passé un entretien me demandant de faire un ensemble de fonctionnalités d'une application simple et j'avais tout le week-end pour le faire.
En gros dans le test :
Plusieurs requêtes http...
Gestion d'un cache...
Proposition de l'ergonomie de l'application.
....
Ne pas utiliser de librairies externes
Mettre les les meilleurs pratiques de l'Objective C/Cocoa.
Tests unitaires.
....
Ensuite il faut remettre son travail et en cas ou ils estiment que tu as bien fait le travail demandé, il t'appellent pour l'entretien technique et la suite.
Pourquoi je trouve ça le meilleur moyen de recruter ?
1. On te laisse le temps sans te stresser à fournir le meilleur de toi même dans des bonnes conditions.
2. Tu ne peux pas tricher, parce que y a peu de gens qui vont t'aider à réaliser un travail d'une journée ou deux.
3. Tu dois défendre ton travail à la fin.
4. ça va monter ta réelle motivation à intégrer leur équipe en passant deux jours rien que à passer le test.
Bon j'ai échoué parce que j'avait la flemme de le faire tout un week-end, mais je pense que c'est le meilleur test que j'ai vu pour l'instant parce que il est complet de point de vue technique.
C'est pas mal oui, après le test "en 20 minutes" permet aussi de tester ta capacité à travailler dans le stress.
Après c'était pour un taf en Suisse, pour une boite qui a les moyens et qui a fait tourner l'annonce sur pas mal de site pointus, donc j'imagine qu'ils cherchaient du lourd.
Ah, enfin. Boite en Suisse qui te demande de chopper des IBAN...
Ca doit très certainement être .... une banque !
Une sorte de Linxo/Banking (appli : numbr, pas dispo en france)
Ce n'est professionnel de leur part.
Il y a des choses que tu ne sais pas trop si il faut vraiment approfondir ou pas lors de traitement de l'exercice par écrit. Par exemple l'immutabilité de la classe Iban. Si on prend la solution d'@Aligator pour ce point avec une property readWrite, la classe reste toujours mutable vu le dynamisme du langage Objective C.
Oups je viens de muter la classe Iban
. Donc tout ça se sont des choses qu'on peut dire à l'entretien qui ne sont pas forcément bonnes à mettre par écrit.