Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Question entretien C++ - doutes.

95 réponses
Avatar
David Fleury
Bonjour,

voici une des questions que je pose pour lors de mes entretiens pour des
développeurs avec expérience orienté C++

"Ecrire une fonction qui renverse une chaine (ex: ABC -> CBA, AE -> EA, ...)

Après avoir posé la question deux ou trois fois déjà, je suis surpris
des réponses (souvent fausses). Je laisse volontairement le choix au
candidat d'utiliser (char* ou std::string) et/ou une fonction modifiant
la chaine entrée ou retournant une nouvelle chaine, et l'utilisation de
la STL est autorisé.

A votre avis, est-ce que la question n'est pas trop mauvaise ?

David.

PS : Dans le même genre, il y a la fonction EstPalindrome qui semble
bloquer.

10 réponses

1 2 3 4 5
Avatar
Jean-Marc Bourguet
Sylvain SF writes:

Alex a écrit :
> "Michael DOUBEZ" wrote in message
> news:49063279$0$30095$
>
>> Alors c'est peut être le fait de poser la question, tout le monde ne
>> demande pas de faire du code à un entretien.
> Oui, à la limite aux débutants, et encore.
> Quand tu as > ans d'expérience, tu ne codes plus "à la main" : tout se
> fait en copier-coller.

"à la main" ou "avec les pieds" tout se rencontre.

avec un débutant, on peux vouloir tester s'il ne commet pas des
erreurs graves, de compréhension, de sens comme de syntaxe
(et un bout de code peut montrer tout cela).



Je ne regarde pas du tout la syntaxe -- une interview et sans ordi en prime
n'est pas le lieu pour cela. C'est le raisonnement et les connaissances
que je regarde -- et la correspondance entre ce qu'on pretent savoir et ce
qu'on sait reellement. Une fois optenue une solution, j'aime bien faire
explorer les variantes les faire comparer.

après 10 ans d'expérience, on s'attend à une bonne maitrise de
l'algorithmie classique, et donc qu'il puisse raconter (pas
nécessairement coder) via quels basiques il retournerait la
chaine.



Avec 10 ans d'experience, je pose surtout des questions sur ce qui a ete
fait apres avoir verifie que ce n'est pas quelqu'un qui a vecu sur les
apparences sans avoir le fond.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Jean-Marc Bourguet
(Marc Espie) writes:

Un vrai exemple pour moi, ca serait plus un fragment de vrai code avec un
joli bug bien visible, pour voir si le candidat le detecte.



J'utilise quelques exemples artificiels de ce genre de temps en temps.
Mais pas du vrai code -- trop dans le contexte serait inconnu du candidat
pour esperer avoir une reponse dans un temps raisonnable.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Michael DOUBEZ
Marc Espie a écrit :
In article <490626b8$0$12768$,
David Fleury wrote:
voici une des questions que je pose pour lors de mes entretiens pour des
développeurs avec expérience orienté C++

"Ecrire une fonction qui renverse une chaine (ex: ABC -> CBA, AE -> EA, ...)
[snip]
A votre avis, est-ce que la question n'est pas trop mauvaise ?



Moi je sais pas, tu me poserais ce type de question en entretien,
je commencerais par demander ce que tu as comme chaines, [snip]



C'est vrai qu'avec des chaînes encodée en utf8, la question prend une
autre tournure.

je n'ecris que rarement du code a partir de rien. Un vrai exemple pour moi,
ca serait plus un fragment de vrai code avec un joli bug bien visible,
pour voir si le candidat le detecte.



Ou tout simplement présenter du code et demander une rapide revue de
code, comment il refactorerait ... Un peu comme ce que fait ACCU à la
fin de CVu.

--
Michael
Avatar
Sylvain SF
Jean-Marc Bourguet a écrit :

avec un débutant, []


Je ne regarde pas du tout la syntaxe []

après 10 ans d'expérience, []


je pose surtout des questions sur ce qui a ete fait []



j'espère bien que l'entretien ne se limite pas à une seule
question: comment écrire telle fonction, mais le PO parlait
bien de cela, non ?

Sylvain.
Avatar
Jean-Marc Bourguet
Sylvain SF writes:

Jean-Marc Bourguet a écrit :
>>
>> avec un débutant, []
> Je ne regarde pas du tout la syntaxe []
>
>> après 10 ans d'expérience, []
> je pose surtout des questions sur ce qui a ete fait []

j'espère bien que l'entretien ne se limite pas à une seule
question: comment écrire telle fonction, mais le PO parlait
bien de cela, non ?



Meme cette question n'est pour moi qu'un pretexte a la discussion qui suit.
(Et meme pour cette question la syntaxe n'a pas d'importance).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Sylvain SF
Jean-Marc Bourguet a écrit :

Meme cette question n'est pour moi qu'un pretexte a la discussion qui suit.
(Et meme pour cette question la syntaxe n'a pas d'importance).



ok, ok, ma liste à la Prévert était très mauvaise, tu as bien
raison, ..., enfin par syntaxe j'entendais des trucs comme:
"pt étant un pointeur sur tableau, puis-je écrire pt++"
(merci pour l'exemple), ça doit porter un meilleur nom...

Sylvain.
Avatar
Mickaël Wolff
Jean-Marc Bourguet a écrit :

Est-ce que tu as deja fait passe des interviews?



Non. Je n'ai jamais décroché de job de développeur en C++. Il faut
dire qu'en raison de mon cursus, ma candidature n'est jamais prise au
sérieux. Alors encore avoir un poste où j'ai la responsabilité de
choisir mes collaborateurs...

Malheureusement.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Avatar
David Fleury
Michael DOUBEZ a écrit :

Après avoir posé la question deux ou trois fois déjà, je suis surpris
des réponses (souvent fausses).



Par fausses, tu veux dire que la réponse ne réalise pas la fonction
demandée ?



Oui aussi. Erreur dans la logique.


AMA, comme le répète ad nauseum Joel Spolsky, l'important est les
processus mis en oeuvre pour résoudre la question plutôt que la réponse
produite.



Je ne connais ce monsieur mais c'est aussi le but de la question.
discuter des choix, et le processus de production du code.


PS : Dans le même genre, il y a la fonction EstPalindrome qui semble
bloquer.



Alors c'est peut être le fait de poser la question, tout le monde ne
demande pas de faire du code à un entretien.




Je me suis demandé aussi.
Mais je pose la question pour savoir si ça gêne ou pas de demander du code.
Avatar
David Fleury
Jean-Marc Bourguet a écrit :
(Marc Espie) writes:

Un vrai exemple pour moi, ca serait plus un fragment de vrai code avec un
joli bug bien visible, pour voir si le candidat le detecte.





Ca peut arriver mais sur un court entretien un vrai code peut être
plus long à analyser, j'ai cru remarquer que les candidats ont encore
plus de mal en voyant beaucoup qu'ils n'ont pas produit.


J'utilise quelques exemples artificiels de ce genre de temps en temps.
Mais pas du vrai code -- trop dans le contexte serait inconnu du candidat
pour esperer avoir une reponse dans un temps raisonnable.

A+




Je pense que cette fonction doit se coder rapidement, en effet.
C'est aussi la cause de la simplicité de la question (enfin normalement)
Avatar
David Fleury
Mickaël Wolff a écrit :
David Fleury a écrit :
Après avoir posé la question deux ou trois fois déjà, je suis surpris
des réponses (souvent fausses).



On peut avoir des exemples ? J'ai du mal à croire qu'on peut répondre
quelque chose de faux à ça !

D'ailleurs, est-ce que ceci est une réponse acceptable pour toi :

#include <iostream>
#include <algorithm>

int main()
{
std::string s("Ceci est une chaine !") ;
std::string rs(s.rbegin(), s.rend()) ;
std::cout << rs << std::endl ;
}

Ou attendrais-tu plutôt un usage de std::reverse ou std::reverse_copy ?




A part une fonction au lieu de main, ça fait ce que ça demande.
Je ne m'attends souvent à rien, c'est le candidat qui m'apporte sa
solution et comment il l'a construit. Et la discussion peut être
plus intéressante comme bonne (ou mauvaise) réponse.
1 2 3 4 5