Jason Maréchal

algorithme
entretien

Je ne suis pas forcément fan des entretiens techniques dans lesquels on pose des questions d'algorithmiques surtout lorsque celles-ci n'ont aucun rapport avec le poste en question. Malheureusement, c'est une réalité, de plus en plus d'entreprises font passer ce genre d'entretiens aux candidats et ce n'est plus exclusivement réservé aux FAANG. J'ai donc décidé pour cette année de commencer une série d'articles concernant les questions d'algorithmiques les plus fréquemment posées en entretien. C'est également une bonne occasion de (re)découvrir les bases de notre métier qu'est l'algorithmique et la résolution de problème. Pour ce premier article, j'ai décidé de commencer avec les listes chaînées qui sont l’une des structures de données linéaires les moins maîtrisées par les candidats contrairement aux tableaux.

Et vous, avez-vous déjà eu des entretiens dans lesquels des questions d'algorithmiques ont été posées ?


Partagé par Axel Shaita
il y a 21 jours
4

Derniers commentaires :
Anh-Vu Tran il y a 20 jours - modifié il y a 20 jours
Pas tout à fait d'accord, le but n'est pas de réimplémenter mais de comprendre pour savoir quand utiliser les bonnes structures de données.
De là en découle une complexité en temps et ou mémoire.
Cela permet de prévoir et prendre les bonnes décisions quand la volumétrie et/ou le nombre d'utilisateurs augmente.
Et quand ca déborde sur une architecture simple malgré les bonnes optimisations, on repense une archi plus complexe qui puisse répondre aux nouvelles contraintes.
C'est donc la base à maitriser pour aller plus loin.

EDIT: le temps que j'écrive, d'autres réponses ont popé ^^ Je répondais exactement à la même phrase que Benoît "il vaudrait mieux faire gagner du temps à tout le monde et poser des questions pertinentes pour le poste"
Jason Maréchal il y a 20 jours
@Benoit @Anh-Vu
Je partage votre point de vue. Je n'ai rien contre poser une question d'algorithmie, de complexité... si la question sert à un échange. Ce qui me gène plus c'est refuser des candidats sur le seul principe d'échouer à répondre à ces questions.
Bon pour la liste chaînée ayant été formé sur le C je suis biaisé et considère que ça fait parti du minimum culturel pour un dev. Mais mettons que ce ne soit pas le cas. Refuser un candidat parce qu’il ne réussi pas à implémenté une liste chaînée parce qu’il ne sait pas ce que c'est et n'en a jamais vu de telle implémentation c'est dommage. Discuter avec lui, l'aiguiller sur une piste et ce rendre compte qu'en reformulant le problème il arrive à implémenter une solution par liste chaînée, c'est mieux.
Après ça dépend de l'objectif de l'entretien aussi. Si on veut des gens très pointus sur tout ça fait un bon filtre.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
algorithme
entretien

Je ne suis pas forcément fan des entretiens techniques dans lesquels on pose des questions d'algorithmiques surtout lorsque celles-ci n'ont aucun rapport avec le poste en question. Malheureusement, c'est une réalité, de plus en plus d'entreprises font passer ce genre d'entretiens aux candidats et ce n'est plus exclusivement réservé aux FAANG. J'ai donc décidé pour cette année de commencer une série d'articles concernant les questions d'algorithmiques les plus fréquemment posées en entretien. C'est également une bonne occasion de (re)découvrir les bases de notre métier qu'est l'algorithmique et la résolution de problème. Pour ce premier article, j'ai décidé de commencer avec les listes chaînées qui sont l’une des structures de données linéaires les moins maîtrisées par les candidats contrairement aux tableaux.

Et vous, avez-vous déjà eu des entretiens dans lesquels des questions d'algorithmiques ont été posées ?


Partagé par Axel Shaita
il y a 21 jours
4

Derniers commentaires :
Anh-Vu Tran il y a 20 jours - modifié il y a 20 jours
Pas tout à fait d'accord, le but n'est pas de réimplémenter mais de comprendre pour savoir quand utiliser les bonnes structures de données.
De là en découle une complexité en temps et ou mémoire.
Cela permet de prévoir et prendre les bonnes décisions quand la volumétrie et/ou le nombre d'utilisateurs augmente.
Et quand ca déborde sur une architecture simple malgré les bonnes optimisations, on repense une archi plus complexe qui puisse répondre aux nouvelles contraintes.
C'est donc la base à maitriser pour aller plus loin.

EDIT: le temps que j'écrive, d'autres réponses ont popé ^^ Je répondais exactement à la même phrase que Benoît "il vaudrait mieux faire gagner du temps à tout le monde et poser des questions pertinentes pour le poste"
Jason Maréchal il y a 20 jours
@Benoit @Anh-Vu
Je partage votre point de vue. Je n'ai rien contre poser une question d'algorithmie, de complexité... si la question sert à un échange. Ce qui me gène plus c'est refuser des candidats sur le seul principe d'échouer à répondre à ces questions.
Bon pour la liste chaînée ayant été formé sur le C je suis biaisé et considère que ça fait parti du minimum culturel pour un dev. Mais mettons que ce ne soit pas le cas. Refuser un candidat parce qu’il ne réussi pas à implémenté une liste chaînée parce qu’il ne sait pas ce que c'est et n'en a jamais vu de telle implémentation c'est dommage. Discuter avec lui, l'aiguiller sur une piste et ce rendre compte qu'en reformulant le problème il arrive à implémenter une solution par liste chaînée, c'est mieux.
Après ça dépend de l'objectif de l'entretien aussi. Si on veut des gens très pointus sur tout ça fait un bon filtre.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Agilité

Construire une fusée avec les principes de l'agilité ? Il semblerait que SpaceX ait rendu cela possible et que ce soit même plus efficace...

La prochaine fois qu'on vous dira que "L'Agilité c'est bien, mais ça ne peut pas s'appliquer chez nous"... ;-)


Partagé par Vincent Bourdon
il y a 22 jours
3

Derniers commentaires :
Benoit GANTAUME il y a 21 jours
C’est drôle par ce que souvent on parle du critère de la vie humaine en jeu. Comme si l’agilité était réservée aux trucs pas sérieux.
Jason Maréchal il y a 21 jours - modifié il y a 20 jours
Je pense que ça tient à tout le côté réglementaire et documenté des domaines critiques. Dans une de mes expérience ces aspects étaient traités très "waterfall" avec des spécification en entrées de cycle projet et des résultats de tests, vérification et validation (et plein de docs pas toujours utiles) à la fin. Juste au milieu les équipes de dev peinaient à travailler de manière agile.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Coup de gueule
Culture
Télétravail

Pourquoi votre approche de la culture du télétravail le rend inefficace et comment changer votre approche pour y remédier


Partagé par Benoit GANTAUME
il y a 22 jours
5

Derniers commentaires :
Jason Maréchal il y a 21 jours
Mon problème avec cet article (j'ai le même avec certains podcast artisan développeur) c'est "Est-ce que la cible de l'article va le lire" ?
Le fond de l'article est bien résumé par certains commentaire. Les boites (française) tournent souvent très bien sans tous les niveaux hiérarchiques habituels. Les employés ne sont pas des enfants, ils travaillent très bien sans avoir quelqu'un sur le dos pour la plus part
Benoit GANTAUME il y a 21 jours
Non, bien sûr par définition.
Mais cela fait du bien à ceux qui souffrent de la situation et le lisent...
Ca leur permet aussi de se rendre compte que ce n'est pas normal.
Et du coup ça enclenche une réflexion et un début de changement.
Chacun son taff : moi je plante des graines.
A chacun de les faire germer.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques
CI/CD
DevOps

Dernièrement, je constate que la CI (Continuous Integration) est un skill relativement rare chez les développeurs, même pour des profils expérimentés. Sans en être un expert absolu, je voulais en livrer ma vision et quelques…


Partagé par Vincent Guilloux
il y a 3 mois
5

Derniers commentaires :
Jason Maréchal il y a 28 jours
"Relativement rare chez les développeurs", parfois aussi chez les ops.

Le problème est que dans certaines organisations les dev n'ont pas le droit de toucher à la CI. Ensuite même s'ils ont la main, comme c'est souvent quelque chose d'obscure qui s'éloigne du code, loin du langage utilisé pour le produit en tout cas, ce sont souvent les même profils qui prennent les choses en mains. Enfin, la CI ce n'est pas du développement de produit, d'un point de vue projet il faut y passer le moins de temps possible, ce n'est qu'un coût sans RoI. C'est comme ça qu'on évite de former l'équipe au technologie de la CI et à la configuration faites par l'équipe, ou pour l'équipe par le touche à tout de l'équipe.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Artisan Développeur utilise des cookies afin de t'offrir les meilleurs services. En poursuivant ta navigation, tu acceptes l’utilisation de cookies. En savoir plus