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.
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 ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. É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.