Comment éviter d'être employé par des entreprises candidates aux histoires de DailyWTF? [fermé]

Je lis les archives du Daily WTF et surtout ces histoires sur les entreprises liées à l'informatique qui ont une approche complètement fausse du développement de logiciels, du travail d'un développeur, etc.

Certaines histoires sont totalement horribles: une entreprise n'a pas de réseau local pour des raisons de sécurité, une autre a un serveur de contrôle de source accessible uniquement par le manager , etc. Ajoutez à cela toutes ces histoires de managers qui ne connaissent pas rien sur leur travail et prendre des décisions stupides sans écouter personne.

Le fait est que je ne vois pas comment savoir si vous serez employé par une telle entreprise lors d'un entretien. Bien sûr, parfois, un intervieweur raconte des choses étranges qui vous donnent une idée que quelque chose ne va pas très bien avec l'entreprise (dans mon cas, le dernier manager a dit que je devrais travailler 100% de mon temps via Remote Desktop, connecté à un ancien et slooooow machine, car "cela évite à plusieurs personnes de modifier le même code source" ; je devrais peut-être lui expliquer ce qu'est le SVN).

Mais dans la plupart des cas, vous ne pourrez pas obtenir suffisamment d'informations lors de l'entretien pour obtenir l'image exacte d'une entreprise.

Alors, comment éviter d'être employé par ce type d'entreprises?

• J'ai pensé à demander à voir certains documents comme un guide de documentation ou des directives de style de code . Le problème est que je vis en France, et ici, la plupart des entreprises n'ont pas du tout ces documents, et dans les rares cas où ces documents existent, ils sont périmés, mal écrits, jamais utilisés, ou vous obligent à faire des choses qui n'ont aucun sens .

• J'ai aussi pensé à demander comment les programmeurs fonctionnent réellement . Mais voir qu'ils ont deux écrans ou des "meubles de style Artsy-Fartsy tard-modernes" ne signifie pas qu'ils n'ont pas de gens qui prennent des décisions étranges, ce qui rend impossible de travailler là-bas.

Avez-vous été dans de telles situations? Qu'as-tu essayé? Cela at-il fonctionné?

N'oubliez pas que les entretiens sont à double sens. Posez-leur des questions ouvertes qui vous permettent de savoir qu'ils savent ce qu'ils font. Et apprenez à "lire entre les lignes" lors de l'évaluation de leurs réponses. Par exemple:

Comment vous assurez-vous que le logiciel que vous écrivez ne craint pas? (reformulé en quelque chose de plus "approprié" si vous êtes ennuyeux)

Bonne réponse: "Nous utilisons des tests unitaires, avons un service d'assurance qualité et des revues de code."

Ce ne doit pas être ça. La personne que vous interviewez n'a pas non plus besoin d'avoir la même réponse que celle que j'ai donnée. Vous cherchez principalement à vous assurer que l'entreprise valorise le code qu'elle écrit dans une certaine mesure et ne va pas simplement le pousser à la porte avec un abandon téméraire.

Mauvaise réponse: "Eh bien, nous voulions faire plus de ces" tests unitaires ". Nous n'y sommes pas parvenus"

Encore une fois, l'accent est moins mis sur les tests unitaires et plus sur l'attitude de l'intervieweur à l'égard du problème. Généralement, «nous savons que nous en avons besoin, nous ne l'avons tout simplement pas fait» est un drapeau rouge. Cela signifie l'une des nombreuses possibilités:

1. Vos collègues seront paresseux.
2. La direction ne donne pas le temps d'utiliser un processus approprié.
3. Vos collègues ne sont pas assez intelligents pour comprendre les tests unitaires.

Rien de tout cela n'est bon (mais certains sont pires que d'autres).

Décrivez le processus utilisé par votre entreprise pour ajouter une fonctionnalité (de décider si la fonctionnalité est nécessaire à son expédition au client).

Bonne réponse: "Les gens d'affaires décident qu'une fonctionnalité est une bonne idée et consultent les programmeurs pour voir à quel point elle est facilement implémentée. Les programmeurs et le personnel technique décident d'une architecture et l'implémentent. Une équipe de publication la pousse ensuite dans la nature . "

Mauvaise réponse: "Les gens d'affaires disent aux programmeurs quoi faire et ils le font."

Comme pour ce qui précède, la réponse elle-même n'est pas aussi importante que l'attitude. La bonne réponse indique que le côté commercial et le côté technique travaillent ensemble pour créer un produit. La mauvaise réponse indique que la direction considère les programmeurs comme des dactylographes surpayés.

En résumé , n'oubliez pas de poser les bonnes questions lors de l'entretien. Et rappelez-vous que des réponses particulières ne sont pas aussi importantes que l'attitude derrière ces réponses. Enfin, ne vous retenez pas . Poser des questions difficiles indique que vous êtes vraiment intéressé par le travail et que vous pensez que vous êtes assez bon pour être un peu pointilleux sur qui vous emploiera.

Vous pouvez leur donner le test Joel:

1. Utilisez-vous le contrôle de code source?
2. Pouvez-vous créer un build en une seule étape?
3. Faites-vous des builds quotidiens?
4. Avez-vous une base de données de bogues?
5. Corrigez-vous les bugs avant d'écrire un nouveau code?
6. Avez-vous un calendrier à jour?
7. Avez-vous une spécification?
8. Les programmeurs ont-ils des conditions de travail tranquilles?
9. Utilisez-vous les meilleurs outils que l'argent peut acheter?
10. Avez-vous des testeurs?
11. Les nouveaux candidats écrivent-ils du code lors de leur entretien?
12. Faites-vous des tests d'utilisabilité des couloirs?

Gardez votre CV en circulation pendant un mois environ après votre embauche, et si les choses ne sont pas à la hauteur, n'ayez pas peur de saisir une autre opportunité. Les entreprises considèrent souvent votre emploi comme une période d'essai pendant une certaine période car elles veulent s'assurer que vous travaillez aussi bien que vous l'avez interrogé. Il est juste que vous fassiez de même si les choses sont vraiment au niveau WTF quotidien.

Je vais prendre la position pessimiste et non traditionnelle de l'ingénieur à ce sujet.

Tu ne peux pas.

Chaque entreprise, sans exception, est candidate aux histoires Daily WTF. En effet, chaque personne, sans exception, quelle que soit sa profession et quelle que soit son expérience, peut être un imbécile dans certains aspects de la vie professionnelle choisie.

Oui. Cela comprend vous, la personne qui lit ceci. (Si vous ne croyez pas que cela s'applique à vous, je pense que nous venons de trouver l'un de vos domaines d'incompétence ...)

Vous pourriez peut-être essayer de voir les choses différemment.

Être embauché par une entreprise sous les projecteurs du Daily WTF est l'occasion pour vous de montrer comment vous pouvez résoudre les problèmes. D'énormes problèmes.

Vous pouvez voir ces difficultés comme des opportunités .

Au lieu d'utiliser le test Joel pour les avoidentreprises, utilisez-le pour improveelles.

Quoi de plus excitant que ça?

Si vous venez en compagnie avec votre cheval blanc comme Napoléon en leur disant qu'ils ont tous tort, vous serez expulsé très rapidement.

L'occasion est que vous serez en mesure de faire des propositions constructives , appuyées par des faits et des références . Si cela se fait comme décrit dans la phrase précédente, il vous sera proposé de vous en occuper la plupart du temps (c'est l'occasion). Dans très peu de cas, vous serez ignoré.

N'oubliez pas que toute interview est une rue à double sens. L'employeur essaie de déterminer si vous êtes un bon candidat. De même, vous devriez essayer de déterminer si l'entreprise vaut la peine de travailler. Poser beaucoup de questions. Déterminez ce qui est important pour vous et posez des questions à ce sujet. Demandez à vos enquêteurs ce qu'ils aiment et n'aiment pas dans l'entreprise.

Aussi, j'appuie la recommandation de l'autre affiche de leur donner le test Joel .

Même un manager mégalomane psychotique peut diriger une équipe qui réussit le test Joel. Comment réagissent-ils lorsque les délais ne sont pas respectés? Le DSI relève-t-il du PDG ou du directeur financier? Cela peut vous donner une idée de l'importance de l'informatique dans une entreprise non logicielle.

Pourquoi le poste est-il disponible? Ont-ils beaucoup de chiffre d'affaires?

Recherchez des moyens de voir si les programmeurs sont surchargés de travail. Personne n'a eu de vacances depuis plusieurs mois à un an? Vous ne pouvez pas battre une entreprise qui donne du temps de vacances, mais personne ne pense pouvoir le prendre.

Vous pouvez modifier les mauvaises pratiques de test et les systèmes de contrôle de code. Je ne peux pas guérir fou.

Voici ce que je ferais si j'étais vous:

• essayez d'obtenir la possibilité d'interviewer un ou plusieurs programmeurs de l'entreprise et demandez-leur quelle est la journée type de leur travail. Cela peut être difficile de demander s'ils ne le fournissent pas, mais une entreprise qui le fournit est un énorme avantage dans mon livre
• demandez-leur comment une nouvelle fonctionnalité est généralement développée et comment le travail est partagé entre les programmeurs.

Les deux questions finissent par être la même chose, posées différemment à différentes personnes. Les points importants:

• Comment les désaccords sur les problèmes techniques sont-ils résolus dans l'équipe
• Comment le travail est-il partagé entre les développeurs
• Comment les bogues sont-ils attribués aux personnes
• Comment prenez-vous la décision de concevoir en interne, d'externaliser, hors des étagères?
• Comment jugez-vous l'échec / la réussite d'un projet

Ceci en complément du test Joel. Notez qu'il n'y a pas de "bonne" réponse: cela dépend de ce que vous recherchez par vous-même, du type d'entreprise que vous recherchez, du type d'entreprise qui est (par exemple, une startup aura moins de chances de se permettre le meilleurs outils par rapport à une fortune 500). Si la personne ne peut pas répondre à cette question, c'est presque certainement un mauvais signe: très probablement, elle n'a même pas pensé à ces problèmes.

Il y a un certain nombre de choses évidentes et diligentes que vous pouvez faire, comme leur poser des questions sur leur processus, ou essayer de parler à un autre développeur, ou même de travailler brièvement avec lui. Aussi bon soit-il, il est également facilement usurpateur d'identité - même les pires gestionnaires savent souvent les bonnes choses à dire sur leur méthodologie (savoir quoi dire sans comprendre le «pourquoi» est ce qui fait d'eux de mauvais gestionnaires en premier lieu, à droite ?) et la plupart des programmeurs ne voudront pas dénigrer l'entreprise à un éventuel embauche - pourquoi risquer qu'elle revienne à quelqu'un pour l'un des millions de personnes interrogées qui passent par le système? (dans une entreprise malsaine où la critique est .. désapprouvée ... cela peut être un vrai risque)

Cependant, vous pouvez regarder des choses plus subjectives - les gestionnaires semblent-ils pleins de mots à la mode ou honnêtes? Cela ressemble-t-il à un environnement sain?

Quelle est la qualité des questions et la connaissance de vos enquêteurs - c'est le processus que tout le monde avec lequel vous travaillez a traversé, rappelez-vous. Vous posent-ils des questions stupides? Question de type RH? Les questions de codage sont-elles trop faciles?

Comme d'autres l'ont déjà dit, les entretiens sont à double sens ...

Mais il y a un subtil facteur psychologique ici qui, à mon avis, beaucoup de gens ne réussissent pas bien: être intimidé en acceptant un travail de merde. C'est plus un problème pour les juniors, mais nous y sommes tous vulnérables.

Je pense que beaucoup de gens sont d'avis que vous ne pouvez pas vraiment changer le comportement d'entreprise merdique, nous prenons donc beaucoup trop de mauvais sentiments dans notre foulée lorsque nous décidons d'accepter une offre d'emploi. Une partie de la psychologie ici est également la relation de pouvoir entre l'employeur et l'employé - en particulier dans une économie mauvaise ou compétitive - on a l'impression qu'ils doivent donner beaucoup de latitude, même face à des odeurs de travail plutôt mauvaises - comme Joel a échoué lamentablement Tests, etc.

Donc, effectivement, ce que je dis, c'est que beaucoup d'entre nous acceptent des emplois sachant qu'ils seront des emplois DailyWTF. L'astuce consiste à être plus pointilleux, à forer les enquêteurs - et à ne pas accepter les emplois de merde à moins d'être absolument désespéré. Il y a bien sûr un équilibre, mais il vaut vraiment la peine d'examiner vos sentiments lorsque vous décidez si une offre d'emploi sur la table est un WTF ou non. Il est facile de se convaincre que vous êtes simplement "trop ​​exigeant et inflexible", alors qu'en réalité vous ignorez une véritable mauvaise odeur de travail.