Entièrement d'accord avec ce constat global. D'autant que souvent les tests techniques demandent du par cœur (parfois dans des points où ce n'est même pas pertinent) alors qu'un test ouvert sur l'échange est plus appréciable.
Il est plus intéressant, je trouve, de trouver quelqu'un qui s'adapte et apprend correctement notamment seul qu'une encyclopédie rigide sur patte. Cela peut se voir en test technique sans prendre beaucoup de temps.
J'en ai déjà eu, et j'ai trouvé que c'était très enrichissant : tu ressors en apprenant des trucs. Par exemple on peut discuter autour de l'architecture d'un programme fictif (pour identifier les points faibles et forts du dispositif pour la fonction donnée), comment améliorer la lisibilité / robustesse d'un code d'exemple, discuter du processus de développement d'un projet...
Car ce sont ces éléments là qui sont réellement utiles et difficiles à apprendre / comprendre, certains ont du mal après 40 ans de carrière... Connaître par cœur un point obscur du langage, une définition à la virgule près ou autre n'est pas très pertinent, d'autant plus que la réponse est souvent accessible rapidement sur la machine.
[^] # Re: Technique avant tout ?
Posté par Renault (site web personnel) . En réponse au message Candidature et recrutement sur des postes/profils python. Évalué à 5.
Entièrement d'accord avec ce constat global. D'autant que souvent les tests techniques demandent du par cœur (parfois dans des points où ce n'est même pas pertinent) alors qu'un test ouvert sur l'échange est plus appréciable.
Il est plus intéressant, je trouve, de trouver quelqu'un qui s'adapte et apprend correctement notamment seul qu'une encyclopédie rigide sur patte. Cela peut se voir en test technique sans prendre beaucoup de temps.
J'en ai déjà eu, et j'ai trouvé que c'était très enrichissant : tu ressors en apprenant des trucs. Par exemple on peut discuter autour de l'architecture d'un programme fictif (pour identifier les points faibles et forts du dispositif pour la fonction donnée), comment améliorer la lisibilité / robustesse d'un code d'exemple, discuter du processus de développement d'un projet...
Car ce sont ces éléments là qui sont réellement utiles et difficiles à apprendre / comprendre, certains ont du mal après 40 ans de carrière... Connaître par cœur un point obscur du langage, une définition à la virgule près ou autre n'est pas très pertinent, d'autant plus que la réponse est souvent accessible rapidement sur la machine.