Est-ce une mauvaise étiquette de demander à un employeur potentiel quel est son score au test de Joël? [fermé]

Les entretiens avec les développeurs sont différents de la plupart des autres lieux, car non seulement vous vous inquiétez des personnes avec lesquelles vous travaillez, des avantages sociaux, de la description de poste, etc., mais vous avez également à vous soucier de surcroît après avoir obtenu le poste. Écrire deux applications avec des exigences précises peut être très différent si vous travaillez dans un environnement bruyant ou silencieux, en utilisant VS2003 / .NET 2.0 vs VS210 / .NET 4.0., En utilisant SVN vs VSS.

Est-il acceptable de soumettre le test Joel à l’employeur potentiel? J'essaie de poser autant de questions pour obtenir le type d'environnement dans lequel je travaillerai, ce qui est extrêmement important à mes yeux, mais quel est le meilleur moyen de mettre fin à la chasse et de simplement poser les questions difficiles (comme on vous l'a demandé lors du même entretien).

REMARQUE: Par "test Joel", je veux dire une liste spécifique de choses qui sont importantes pour vous (pas nécessairement Joel), mais vous n’avez peut-être pas le temps de vous en servir en vous posant la question , vous décidez donc d'envoyer un courrier électronique ou de planifier une autre réunion, ou de demander à d'autres personnes, etc.

Un entretien d'embauche va dans les deux sens: une entreprise vous interroge et vous interrogez l'entreprise. Je ne sortirais pas littéralement avec un "Quel est votre score au test Joel?", Mais je poserais les questions individuelles qui ont été décisives pour moi dans un environnement de travail.

Il n'a pas besoin d'une énorme accumulation. C'est un bon moment pour poser ces questions à la partie technique du processus d'entrevue, lorsqu'elles disent "Avez-vous des questions pour nous?". Vous pouvez commencer avec quelque chose du genre "pouvez-vous décrire une journée type de travail ici?" et aller de là.

Est-ce que Joel Testez votre appareil pour évaluer le potentiel d'un employeur potentiel?

Je suis allé pour un entretien d'embauche et le bureau était ouvert, donc bruyant, avec beaucoup de systèmes disparates, un arriéré de bogues, ils n'utilisaient pas beaucoup d'outils commerciaux, il n'y avait pas de testeurs, nous n'avons écrit aucun code pendant l'entretien et aucune facilité d'utilisation dans les couloirs .

..mais vous pouvez emmener votre chien au bureau, vous avez un jour par semaine pour travailler sur vos propres projets, il y avait de la nourriture 24 heures sur 24, 7 jours sur 7 avec de superbes sushis, des zones de détente, un toboggan pour descendre les escaliers, un coca / café gratuit / JO, et ils font certains des logiciels les plus étonnants sur la terre.

Autant que je sache, le test de Joel a eu des résultats médiocres, mais refuseriez-vous de travailler pour cet employeur # sur cette base?

Si c'est bruyant, vous pouvez mettre des écouteurs. S'il n'y a pas de test, testez l'unité et / ou les tests automatisés. S'il n'y a pas de construction nocturne, écrivez une tâche cron ou installez CI quelque part.

Bien sûr, utilisez le test Joel comme guide pour les questions que vous voudrez peut-être poser, mais il existe de nombreux autres paramètres, dont certains peuvent avoir plus d'importance pour vous que d'autres.

(Aucun prix pour deviner qui était l'employeur!)

Je n'ai jamais travaillé dans un endroit où le score de Joel était supérieur à 4. Quand j'y vais, j'ai un petit paquet avec moi qui contient une autre copie de mon CV (j'ai vu des recruteurs mettre mon nom sur le CV de quelqu'un d'autre) ainsi qu'un tas de questions, dont certaines étaient les suivantes: test de joel remué. Personne n'a jamais mentionné avoir reconnu les questions.

Le test Joel m'a inspiré à poser des questions «comme ça». Quel contrôle de version, suivi de bogues, tests, ...

Je pose généralement une tonne de questions à la fin (ou au cours de) l'entretien. Le cas échéant , cela montre que vous êtes intéressé par les meilleures pratiques / l'assurance qualité / ... S'ils ne le font pas déjà, peut-être qu'ils seront intéressés par votre mise en œuvre, par exemple: les tests unitaires.

Meilleur scénario: ils n'ont pas encore pensé à ces choses, mais ils sont étonnés de ce que vous pouvez améliorer dans leur processus de développement.

Dans le pire des cas, ils n'aiment pas le fait que vous posiez autant de questions et n'ont donc aucun intérêt à améliorer leur processus. Dans ce cas, vous ne voulez probablement pas travailler là-bas.

PS: assurez-vous simplement de savoir de quoi vous parlez, pas seulement en marchant inconsciemment sur une liste.

J'ai 3 questions sur l'environnement de développement pour lesquelles une réponse négative à l'une d'elles est un obstacle majeur.

Quel logiciel de contrôle de version utilisez-vous?

Quel traqueur de problème / bug utilisez-vous?

Votre processus de développement ressemble-t-il à Scrum?