Discussion :

[LSMetag]

L'évolution dans ce secteur c'est toujours un problème. Soit tu prends la voie "Manager" et tu quittes le dev (que tu aimes, dans certains cas), soit tu prends la voie "Expert", et là tu dois te spécialiser. Une fois spécialisé, les missions sont moins variées, et tu as peu de marges de manoeuvre pour bosser sur les technos émergentes ou d'autres très en vogue. Bref, tu gagnes plein de sous, tu finis par te faire chier, et tu régresses dans la globalité car tu es coincé dans ta case.

L'idéal serait une 3ème voie d'Architecte, mais il faut passer "Expert" d'abord... Il faut 10 ans d'expériences apparemment alors que j'ai connu certains Bac+2 (passionnés) avec 2/3 ans d'expérience professionnelle (beaucoup plus si on compte le personnel) qui en étaient capables.
Mais non, ils vont peut-être rester simples développeurs sous-payés pendant 15 ans, alors qu'ils sont les meilleurs de l'équipe, et corrigent les bugs d'architecture...

La culture de la case, du papier, de l'expérience pro,... c'est ce qui me dégoute. Dans les pays anglo-saxons c'est la compétence pure qui compte.

[yento]

L'idéal serait une 3ème voie d'Architecte, mais il faut passer "Expert" d'abord... Il faut 10 ans d'expériences apparemment alors que j'ai connu certains Bac+2 (passionnés) avec 2/3 ans d'expérience professionnelle (beaucoup plus si on compte le personnel) qui en étaient capables.
Mais non, ils vont peut-être rester simples développeurs sous-payés pendant 15 ans, alors qu'ils sont les meilleurs de l'équipe, et corrigent les bugs d'architecture...

Been there... done that.

J'ai découvert par accident les postes de "Solutions Architect" pendant un de mes stages. A mi chemin technique et pre-sales, qui doit définir les besoins clients et les réponses possibles en début/avant appels d'offres, puis architecture, choix des solutions, proof-of-concept, MVP, tests de faisabilité tests de performances. C'est vachement intéressant de voir les projets des gros clients et les projets gouvernementaux depuis l'inception, qui demande X millions d'utilisateurs en moyennes.
Enfin voilà, le poste existe et est meconnu, mais c'est difficile de rentrer là dedans avec la paie adéquat quand la RH et le manager te donne 20 ans en voyant ton visage et ton shirt.

(et même dans les pays anglo saxons ça peut être difficile... enfin disons que les recruteurs/manager filtrent parfois les mauvais candidats ^^)

[Uncharted]

La grosse différence entre les US et la France dans le domaine technique c'est que la bas on est considéré comme "Software Engineer" ie ingénieur logiciel
c'est a dire qu'on est embauché pour trouver des solutions, résoudre des problèmes algorithmique / techniques et non pour connaître un langage ou les APIS
On veut le développeur qui créera le prochain facebook, algo de compression etc

D'ailleurs ça se reflète dans les tests : la bas c'est des problèmes algorithmique et de logique , ici c'est des questions techniques sur le langage / API , base de données etc

ma petite contribution sur la spécialisation:
dans mon cas j'ai choisi de ne pas me spécialiser, j'ai alterné mission java et .net depuis que j'ai commencé à bosser alors que la bataille entre sun / microsoft (et les clans) faisait rage.
Cela m'a bien servi jusqu’aujourd'hui, les avantages :
- plus de choix dans mes missions
- pas d'intercontrat
- dans les missions où les 2 technos sont présentes ou lorsqu'il faut faire une migration de java a .net ou inversement : je suis forcément mis en avant par rapport à ceux qui ont fait le choix d'une techno
- plus de responsabilités : lorsqu'il faut faire le bridge entre 2 équipes ou au sein d'une même équipe utilisant des technos hétérogène
- couverture de 30-45% des propositions de jobs sur le marché de l'emploi si je me souviens bien des dernières stats sur developpez.com

aujourd'hui j'apprends et je bosses sur d'autres langages et technos pour ne pas me laisser enfermer et couvrir 10-15% de plus des offres de postes :p

la seule chose que j'ai décidé de ne pas faire c'est tout ce qui est front end, je suis plutôt spécialisé serveur et cela me demanderait vraiment trop d'effort.
mais cela ne m'empêche pas de m'autoformer et de suivre ce qui se fait histoire de ne pas me faire largué et de savoir de quoi on parle

en parlant des pays dans les erreurs je pensais également à :

- ne pas être mobile géographiquement : en France on est dans notre petite zone de confort alors qu'il y a des tas d'opportunités dans d'autres pays

[floriann]

La grosse différence entre les US et la France dans le domaine technique c'est que la bas on est considéré comme "Software Engineer" ie ingénieur logiciel
c'est a dire qu'on est embauché pour trouver des solutions, résoudre des problèmes algorithmique / techniques et non pour connaître un langage ou les APIS
On veut le développeur qui créera le prochain facebook, algo de compression etc

D'ailleurs ça se reflète dans les tests : la bas c'est des problèmes algorithmique et de logique , ici c'est des questions techniques sur le langage / API , base de données etc

ma petite contribution sur la spécialisation:
dans mon cas j'ai choisi de ne pas me spécialiser, j'ai alterné mission java et .net depuis que j'ai commencé à bosser alors que la bataille entre sun / microsoft (et les clans) faisait rage.
Cela m'a bien servi jusqu’aujourd'hui, les avantages :
- plus de choix dans mes missions
- pas d'intercontrat
- dans les missions où les 2 technos sont présentes ou lorsqu'il faut faire une migration de java a .net ou inversement : je suis forcément mis en avant par rapport à ceux qui ont fait le choix d'une techno
- plus de responsabilités : lorsqu'il faut faire le bridge entre 2 équipes ou au sein d'une même équipe utilisant des technos hétérogène
- couverture de 30-45% des propositions de jobs sur le marché de l'emploi si je me souviens bien des dernières stats sur developpez.com

aujourd'hui j'apprends et je bosses sur d'autres langages et technos pour ne pas me laisser enfermer et couvrir 10-15% de plus des offres de postes :p

la seule chose que j'ai décidé de ne pas faire c'est tout ce qui est front end, je suis plutôt spécialisé serveur et cela me demanderait vraiment trop d'effort.
mais cela ne m'empêche pas de m'autoformer et de suivre ce qui se fait histoire de ne pas me faire largué et de savoir de quoi on parle

en parlant des pays dans les erreurs je pensais également à :

- ne pas être mobile géographiquement : en France on est dans notre petite zone de confort alors qu'il y a des tas d'opportunités dans d'autres pays

Et on ne te reproche pas, justement, le fait de ne pas t'être spécialisé dans un domaine ?

[Uncharted]

on ne m'a jamais reproché ce choix
du temps de la guerre sun vs microsoft c'était plus des débats animés du style il fallait absolument choisir son camp : .net c'est propriétaire c'est le mal absolu blabla , t'es pas productif en java blabla
d'ailleurs dans les anecdotes j'avais connu des dev qui faisait du java et qui me tenaient ce genre de discours et qui sont passé du "coté obscur" et qui ne jure que par .net maintenant comme quoi

pour un job ou pour une mission le recruteur regarde la partie qui l'intéresse si c'est un profil .net il va regarder les missions .net et inversement + les connaissances fonctionnelles
au final je passes les même entretiens techniques et je fais le même taf que ceux qui sont spécialisé et personne ne s'en est plaint jusqu'ici

[yento]

D'ailleurs ça se reflète dans les tests : la bas c'est des problèmes algorithmique et de logique , ici c'est des questions techniques sur le langage / API , base de données etc

Il n'y a que les SSII qui font des entretiens en carton.

Les quelques éditeurs que j'ai pu identifier quand j'étais encore en France, et tout ceux chez qui j'ai passé des entretiens. Ils sont au gout du jour sur les interviews classiques au tableau/papier: Listes chainées, pointeurs, multiples programmes à réaliser, debugging, exercices divers et parfois épreuve de design.

Il reste une différence cependant, les éditeurs internationaux font systématiquement des entretiens on-site 4*1h de plus en plus dur, alors que les PME françaises ont seulement 1-3 heures de tests, un peu plus faciles et avec moins d'interviewers différents.

[Glutinus]

Moyennement d'accord, tous les éditeurs ne font pas que des entretiens bons et les SSII en carton-pâte.

J'ai bossé pour un éditeur qui s'en fichait, il voulait de toute manière qu'on fasse de la merde, du secrétariat et avoir des cochons sur qui taper - c'était pareil sur les internes. Donc l'entretien était minable, mais il prenait tout ce qui avait dix doigts. Et d'autres exemples pareil : de toute manière, si tu laisses l'entretien à un mec qu'est pas technique, ça part toujours en vrille.

Mais dans les statistiques tu vas tomber plus souvent sur des bons entretiens chez des éditeurs, start-ups - face à un interlocuteur technique - web-agency...

[ustensile]

Avoir choisi développement plutôt que système et réseau à la sortie de l'école d'ingénieurs

[Glutinus]

Approfondis, s'il te plait.

[dev14]

J'ai mis "pas d'avis" car je ne vois pas d'erreur fatale hormis bien sûr l'erreur qui t'arrive et pour laquelle tu ne trouves plus la sauvegarde pour revenir en arrière.

Peut-être aussi parce que je suis à mon compte après être passé par 3 sociétés, et que c'est 1000 fois plus épanouissant que de travailler pour une entreprise !

[Grogro]

Il n'y a que les SSII qui font des entretiens en carton.

Les quelques éditeurs que j'ai pu identifier quand j'étais encore en France, et tout ceux chez qui j'ai passé des entretiens. Ils sont au gout du jour sur les interviews classiques au tableau/papier: Listes chainées, pointeurs, multiples programmes à réaliser, debugging, exercices divers et parfois épreuve de design.

Il reste une différence cependant, les éditeurs internationaux font systématiquement des entretiens on-site 4*1h de plus en plus dur, alors que les PME françaises ont seulement 1-3 heures de tests, un peu plus faciles et avec moins d'interviewers différents.

Concrètement, comment on se prépare à ce genre de véritables entretiens techniques ?

[EPITECH42]

La première erreur : entrer dans une SSII classique avec ses managers, ses commerciaux, ses clients, ses partenaires, ses comptes, ses syndicats,...
La seconde erreur : arrêter d'écrire du code parce que tu te retrouves dans un parc applicatif composé de clickodromes
La dernière erreur : de ne pas avoir une spécialisation plus profonde que les autres dans le domaine de l'informatique.

Concernant ma première erreur, je recommanderai de ne pas passer par les SSII.
Je trouve leur fonctionnement consternant (limité en autonomie d'actions et structure hiérarchique écrasante) et les rémunérations ridicules (grilles plafonnées + réductions des coûts salariaux donc de la marge sur tes ressources financières directes).

Ma seconde erreur est plus personnelle.
Dès que tu te retrouves dans un environnement de travail où tu n'ouvres pas un éditeur quelconque pour écrire des scripts/programmes/... inquiète toi !
Si tu envoies plus d'emails que de commits, tu es en train de devenir un manager et donc te t'éloigner de ton métier (sauf si c'est voulu en premier lieu).

Je pense que ma dernière erreur est la plus significative.
C'est bien d'être un couteau suisse informatique, ça te permet d'avoir des vues globales du fonctionnement d'un système informatisé (connaissance matériel, réseaux, systèmes d'exploitation, langages de programmation, ...) et c'est la plupart du temps cette connaissance du système global qui donne un avantage au salarié en poste.
Le revers de la médaille : beaucoup de personnes te sont semblables donc ta rémunération se fera en fonction de tes capacités à négocier et de ton savoir-être plutôt que de ton savoir-faire.

Tout cela reste mon avis et je pense que des contre-exemples existent aussi

[el_slapper]

Concrètement, comment on se prépare à ce genre de véritables entretiens techniques ?

Ben, il y a des questions qui reviennent souvent. Il faut un peut fouiller les blogs et/ou les forums, à une époque, c'était surtout de la liste chainée et de la regex. donc, tu te fades quelques regex rigolotes, tu t'entraines à faire des listes chainées dans une douzaine de langages différents, et tu est prêt. Évidemment, encore faut-il que la question soir réellement là-dessus(c'est peut-être passé de mode).

J'ai personnellement passé un test où on invente sous tes yeux un nouveau langage de programmation, et à chaque question, on rajoute une règle, et on te pose une question. La seule préparation possible, c'est arriver reposé, frais, dispos, et motivé.

[Glutinus]

C'est rigolo, el_slapper, ma copine a trouvé un job en tant que développeur web. Son premier jour, elle a reparlé de son entretien de recrutement avec son patron, et celui-ci disait que des fois il fait le test du fizz-buzz (il ne lui a pas fait, il a eu le feeling de suite et est passé à d'autres questions) et qu'il a un retour consternant d'échecs.

[RyzenOC]

il fait le test du fizz-buzz (il ne lui a pas fait, il a eu le feeling de suite et est passé à d'autres questions) et qu'il a un retour consternant d'échecs.

Je dirais pas que c'est consternant.

Je vien de voir ce que c'était (sa fait 6 minutes), c'est tres facile oui, d’âpres ce que j'ai compris faut faire un truc comme sa (en python)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
for i in range(0,100):
   if (i%3 and i%5):
      print("fizzbuzz")
   elif (i%3):
      print("fizz")
   elif (i%5):
      print("buzz")

Alors c'est trop facile, la j'suis devant mon pc tranquille avec 2 heures d'échauffement.
Mais en entretien d'embauche, je ne sais pas si j'aurais réussie, le stress est un facteur important, pendant un entretient sans vouloir exagérer tu joue ton avenir.

Donc c'est pas aberrant d'échouer à ce test, tous le monde n'a pas suivie une formation d'astronaute ou de pilote de chasse.

[el_slapper]

(.../...)Alors c'est trop facile, la j'suis devant mon pc tranquille avec 2 heures d'échauffement.
Mais en entretien d'embauche, je ne sais pas si j'aurais réussie, le stress est un facteur important, pendant un entretient sans vouloir exagérer tu joue ton avenir.

Donc c'est pas aberrant d'échouer à ce test, tous le monde n'a pas suivie une formation d'astronaute ou de pilote de chasse.

en COBOL, c'est un peu plus verbeux(187 lignes pour la version finale), surtout pour le frappé qui veut mettre toutes les clochettes habituelles.

Mais pas mal de postes en informatique sont des postes de maintenance à chaud. En quoi le fait d'être testé sous stress est-il scandaleux? Pour un poste ou on peut avoir 4 incidents majeurs à gérer en même temps, être capable de torcher un fizzbuzz en situation de stress majeur me semble important, au contraire. Ou on peut avoir des développements à faire en urgence. J'ai eu à cracher 4 programmes(jetables) en une matinée pour corriger en urgence des données de prod, avec une rupture sur clef partielle des deux cotés, et juste du COBOL à me mettre sous la dent(pas d'objet, pas de relationnel, que du procédural). Faut pas craquer sous la pression.

[Glutinus]

@sazearte : et encore, il demande des fois meme du pseudo-code...

Moi ma première rencontre avec le fizzbuzz, c'était mon premier jeu à boire autant dire que je m'en souviendrai toute ma vie, de l'algo...

[yento]

C'est rigolo, el_slapper, ma copine a trouvé un job en tant que développeur web. Son premier jour, elle a reparlé de son entretien de recrutement avec son patron, et celui-ci disait que des fois il fait le test du fizz-buzz (il ne lui a pas fait, il a eu le feeling de suite et est passé à d'autres questions) et qu'il a un retour consternant d'échecs.

Le dernier senior (> 10 ans d'expérience) je lui ai passé des questions encore plus facile que ça, en C puis en assembleur. C'était magnifique.

[yento]

Concrètement, comment on se prépare à ce genre de véritables entretiens techniques ?

L'idéal c'est d'être bon (voir très bon) dans plusieurs domaines et plusieurs langages afin d'être capable d'improviser en toutes circonstances.

Les indispensables:
1) connaitre toutes les bases typiquement vues en cours (structure de données, tris, complexités, algo courants, programmation dynamique, graphes...)
2) gérer son stress
3) poser les bonnes questions pour bien comprendre ce qui est demandé et attendu

L'entrainement:
1) le livre ULTIME Cracking the Code Interview.
2) rechercher sur google plein de questions d'interviews, et encore d'autres, et encore de nouvelles.
3) apprendre toutes les questions pieges et impossibles à trouver par soi même
Bonus) Mémoire photographique recommandée, mais pas suffisante a elle seule

Avec tout ça, tu peux t'en sortir pour les entretiens juniors et les entretiens plus durs où -en fait- c'est que des questions réchauffées.

Il existe un niveau supérieur d'entretiens, avec des questions difficiles ET bien faites ET qui n'existe pas sur Google. Là le seul remède pour s'en sortir c'est talent + expérience + compétences.

[Grogro]

L'idéal c'est d'être bon (voir très bon) dans plusieurs domaines et plusieurs langages afin d'être capable d'improviser en toutes circonstances.

Les indispensables:
1) connaitre toutes les bases typiquement vues en cours (structure de données, tris, complexités, algo courants, programmation dynamique, graphes...)
2) gérer son stress
3) poser les bonnes questions pour bien comprendre ce qui est demandé et attendu

L'entrainement:
1) le livre ULTIME Cracking the Code Interview.
2) rechercher sur google plein de questions d'interviews, et encore d'autres, et encore de nouvelles.
3) apprendre toutes les questions pieges et impossibles à trouver par soi même
Bonus) Mémoire photographique recommandée, mais pas suffisante a elle seule

Avec tout ça, tu peux t'en sortir pour les entretiens juniors et les entretiens plus durs où -en fait- c'est que des questions réchauffées.

Il existe un niveau supérieur d'entretiens, avec des questions difficiles ET bien faites ET qui n'existe pas sur Google. Là le seul remède pour s'en sortir c'est talent + expérience + compétences.

Merci.

Etant physicien de formation, ces bases typiquement vues en cours, moi je les ai jamais vues. Il me faut donc bosser un bouquin d'algo.