Est-il sage de poser des questions sur les décisions de conception prises sur un produit lors d'une interview? [fermé]

J'ai récemment réfléchi aux questions d'entrevue et aux mauvaises expériences d'entrevue que j'ai eues dans le passé. Il convient de noter que j’avais demandé à l’intervieweur pourquoi l’équipe avait choisi d’utiliser EJB 3 par rapport à Spring dans son produit. L'interviewer m'a presque arraché le visage en criant: "Parce que Spring n'est pas la solution idéale pour tout le développement de logiciels Java, voulez-vous ce travail ou pas?". En réponse à cela, je lui ai dit que ce n'était probablement pas un travail pour moi et je suis rapidement sorti de l'entretien.

Au début de l'entretien, on m'avait informé que le chiffre d'affaires de la société était élevé, que le produit sur lequel elle travaillait avait été créé initialement dans Modula-3, puis transféré vers Perl et enfin vers Java. On m'a remis un livret de 10 pages de questions techniques sur Java, EJB, SQL et JDBC, et on m'a posé des questions sur les piles de technologies avec lesquelles j'ai travaillé. Quand on m'a demandé de poser des questions, j’ai pensé qu’il était raisonnable de leur poser des questions sur leur technologie et d’obtenir des réponses raisonnables, de ne pas envoyer l’intervieweur au feu.

Question: Est-ce une bonne idée de sonder les choix architecturaux pris lors d'une interview? Sinon pourquoi?

De mon point de vue, une interview est un processus à double sens. Si les enquêteurs me testent sur mes compétences techniques, je suis tout à fait en droit de leur poser les mêmes questions:

1) Déterminez leur état d’esprit et leur attitude à l’égard du développement de logiciels. 2) Déterminez si leur approche est conforme à la manière dont je traiterais les problèmes de ce type.

Il est possible que l'intervieweur qui s'est mis en colère ait de mauvaises compétences en matière d'interview et ait oublié qu'une interview est un échange à double sens. Si on m'avait posé cette question, j'aurais donné une réponse raisonnable, mais je n'aurais certainement pas essayé de mettre une personne interrogée dans un état de capitulation modérée où la tête se balance de haut en bas sans conversation.

Personnellement, je trouve que interviewer des gens est presque aussi épuisant et stressant que d’être interviewé. Mais c’est parce que je conviens avec vous que le processus d’entrevue est un échange à double sens.

Je me fiche de votre qualité, je ne veux pas vous engager si vous ne voulez pas être heureux de travailler là-bas. C'est un jeu coûteux à jouer. Je souhaite donc répondre à vos préoccupations et vous montrer l'équipe et le produit tels quels, afin que vous puissiez prendre une décision éclairée.

Quand je cherche un emploi, je veux travailler avec quelqu'un qui partage cette attitude. Et, même si je suppose que je connais les réponses aux questions, je les demanderai juste pour voir la réaction. L'agression n'est jamais le signe d'une personne à l'aise avec une situation.

Je ne ment pas dans une interview, des deux côtés du bureau, car ils pensent alors qu'ils embauchent quelqu'un de différent / qui va travailler dans un endroit différent. Et j'attends la même chose en retour de la part de la personne de l'autre côté de l'interview.

Malheureusement, cela signifie que je rencontre parfois des entretiens comme celui que vous avez décrit. Sont-ils des expériences horribles? Oui. Est-ce que je sors de là en sachant exactement où l'entrevue s'est mal passée? Oui.

Mais suis-je bien sûr que chaque horrible expérience aurait été bien pire si j'avais eu le travail ou embauché la mauvaise personne? Putain, oui.

Oui, vous pouvez demander si vous êtes vraiment curieux et si la réponse compte. Je pense que poser des questions montre que vous comprenez qu'il y a plus d'une façon de faire les choses, et cela montre que vous êtes intéressé par la façon dont le logiciel a été écrit.

Cela étant dit, vous devez faire très attention à la formulation de la question et encore plus à la poursuite de la conversation. Il est facile de croire que leurs décisions sont contestées. La dernière chose que vous voulez, c'est que l'intervieweur pense que vous pensez être plus intelligent qu'eux. Si vous êtes vraiment curieux, demandez. Si vous pensez qu'ils ont fait un mauvais choix, fermez la bouche.

Si j'avais été dans la situation décrite dans la question, au lieu de partir, j'aurais peut-être dit quelque chose du genre "oh oui, je conviens que le printemps n'est certainement pas la bonne solution pour tout. Merci de m'avoir informé un peu sur votre architecture! Je suis toujours à la recherche de conseils pour choisir les bons outils ". (Cependant, votre question est étrange - vous demandez pourquoi ils ont choisi le printemps et ils l'ont choisi parce que ce n'était pas la fin de tous?)

En tant que personne qui interviewe fréquemment des personnes, je serais personnellement ravi de discuter des raisons pour lesquelles des choix de technologie ou de conception particuliers ont été faits, de ce que nous ferions différemment maintenant si nous avions le luxe de ressources ou si nous commencions un nouveau projet. En général, je le voyais comme une indication de quelqu'un qui se souciait de leur métier et, à moins que leurs dogmes et le leur ne soient pas compatibles, je donnerais probablement à ce candidat une note plus élevée que celui de quelqu'un qui répond simplement à des questions techniques avec compétence.

Je travaille actuellement sur un projet pour un client qui a hérité de décisions architecturales bien intentionnées mais mal mises en œuvre, et les candidats qui expriment leur curiosité pour le monde tel qu'il est et la voie à suivre à notre avis sont généralement les suivants: types de personnes avec lesquelles nous aimerions travailler. Nous voulons des personnes capables de faire preuve de la diligence requise et de la validation des décisions de conception et de mise en œuvre de notre équipe. Nous valorisons généralement les personnes qui apportent à la table quelque chose que nous n’avons pas ou n’en avons pas assez.

Lorsque je suis candidat à une entrevue, je perçois un signe d'hostilité ou de défense lorsque ce type de discussions se passe mal, car une organisation qui n'est pas capable de s'auto-examiner est généralement aussi dans un bourbier technologique et processus qu'elle sont incapables et probablement pas disposés à se sortir de. Si je ne vois pas la motivation pour l'amélioration continue de l'équipe existante, il y a de bonnes chances que je ne serai pas heureux là-bas.

qui a couché une fois avec un vendeur Oracle et a décidé que tous les développements futurs se feraient à l'aide de services Web Java 1.4, d'Oracle ERP et d'une interface Borland C ++ utilisant principalement des composants d'interface graphique tiers abandonnés. Nous préférons dépenser 60 000 USD par mois pour combler les besoins des clients. de sauter d'un navire que de revoir toutes les décisions et d'apporter des améliorations permanentes qui pourraient générer de nouveaux revenus si nous avons de la chance. Ne berce pas le bateau, qu'est-ce qui ne va pas avec toi? "

En supposant que vous soyez dans une région avec d’autres emplois en technologie, ou que vous soyez prêt à déménager, vous avez probablement le luxe du choix. Aucun poste n’est parfait, mais vous souhaitez travailler avec des personnes qui souhaitent travailler avec vous. (Je me soucie plus de cela que des choix technologiques spécifiques la plupart du temps.) Si quelque chose sent mauvais, c'est probablement le cas.

Alors oui, demandez plus loin. Plus la curiosité que nous portons à notre entreprise, à nos processus et à notre conception, plus je serai susceptible de prendre un candidat au sérieux. Mais comme je ne travaille pas dans un magasin Blub, je ne peux donc pas vous dire si cela vous aidera à obtenir un emploi chez Blub. Je peux seulement dire que cela fonctionnerait pour vous si vous voulez travailler avec d'autres personnes qui s'intéressent à leur métier.

Question: Est-ce une bonne idée de sonder les choix architecturaux pris lors d'une interview? Sinon pourquoi?

Absolument bien, je considérerais cela comme un point positif.

Si votre interlocuteur ne peut pas gérer cela, cela en dit long sur lui - pas vous.

Je serais inquiet si un junior n'était pas intéressé par les décisions de conception, cela montrerait un manque de curiosité / d'intérêt pour le sujet, et ne montrerait aucun désir de s'améliorer.

Je suis de l'état d'esprit c'est essentiel . J'ai travaillé dans beaucoup trop d'emplois avec des décisions de conception absurdes, soit parce que personne ne le savait mieux, qu'il ne se souciait pas d'apprendre, ou que la direction avait reçu le mandat d'utiliser ce que le chef de la direction lisait dans un magazine / voyait en ligne / avait quelqu'un lui dire était la "prochaine grande chose" sans aucune considération des alternatives. Ces emplois étaient tous des lieux de travail misérables.

Vous ne devriez pas nécessairement critiquer une décision de conception à moins que quelque chose ne tienne compte du bon sens ou ne sonne comme un discours loufoque, mais il est courant de remettre en question des choses qui semblent "off" pour déterminer s'il existe une raison héritée ou quelque chose qui est arrivé qui facilitait le recours à une approche peu orthodoxe.

Poser de telles questions a également pour effet de jauger l'intérêt de l'entreprise pour l'amélioration et la compétence. Comme quelqu'un d’autre l’a dit plus haut, c’est une chose si vous obtenez une réponse du type (je ne connais pas Java, mais utilise .NET, nous utiliserons donc des exemples .NET). Lorsque nous avons écrit l’application, il n’existait aucun ORM mature. Nous avons donc utilisé des procédures stockées avec une couche de passerelle de données. Nous aimerions passer à Entity Framework dans le futur et une autre chose pour obtenir une réponse telle que Nous utilisons simplement des procédures stockées. Entity Framework a l'air effrayant et peut nécessiter du travail de refactorisation, et nous ne pouvons rien refactifier car le PDG dispose d'une liste exhaustive de nouvelles fonctionnalités sur lesquelles il souhaite que nous travaillions. Si nous passons le temps à regarder Entity Framework, il nous renverra. pour perdre du temps. L’un indique la compréhension et le désir de s’améliorer, l’autre indique un environnement au mieux médiocre où tout le monde fait le strict minimum.

Une entreprise qui s'offusque de vous interroger sur leurs décisions ou de vouloir expliquer pourquoi elle a choisi d'utiliser le produit A au lieu du produit B leur joue du doigt et montre qu'elles ne veulent pas d'un libre penseur mais d'un drone qui ne posera pas de questions, et il est probable que ce n’est pas le genre d’entreprise pour laquelle un développeur compétent veut travailler.

réponse: C'est une bonne idée de poser des questions sur la prise de décision architecturale. Mais vous devez faire attention à la manière dont vous posez de telles questions.

En résumé, vous devriez vous demander " Comment avez-vous choisi la technologie X plutôt que la technologie Y? ".

Vous voulez formuler cela de manière à indiquer que vous êtes généralement intéressé par le processus de prise de décision au sein de l'équipe. Personne ne voudra passer en revue toutes les décisions historiques de la société avec un candidat.

Lorsque vous demandez " Pourquoi avez-vous choisi la technologie X au lieu de la technologie Y? ", Il se peut que vous soyez en désaccord avec leur décision (ce qui est acceptable ... mais peut être considéré comme hostile) ou que vous voulez vous vanter connaître les technologies en question (ce qui serait gênant pour tout le monde), malgré vos bonnes intentions.

J'aime bien demander à un intervieweur de me parler d'une décision de conception ratée qu'ils ont prise et de ce qui a été fait ensuite. Cela vous donne de bonnes informations:

1. Si le patron ne peut admettre aucune erreur de forme ou aucun échec temporaire, vous ne voudrez probablement pas travailler pour lui.
2. Vous pouvez dire comment l'entreprise gère une situation stressante.

Ce n’est peut-être pas populaire, mais j’ai toujours beaucoup de respect pour les gestionnaires qui savent bien qu’un projet va échouer et le tuer pour cesser de gaspiller de l’argent, ou que quelque chose va dans la mauvaise direction et doit être détruit ou redémarré .

En fin de compte, si vous parlez de satisfaction au travail, la technologie (langage / plate-forme / compilateur / peu importe) a moins d’importance que les personnalités impliquées et l’environnement de travail.

Il y a quelques années, j'étais en entrevue et on m'avait posé diverses questions techniques sur un langage de programmation ... sur lequel je n'avais pas bien travaillé (60/40, correct / incorrect). La discussion a porté sur le projet en cours et j'ai commencé à poser des questions sur la conception, puis à souligner quelques problèmes et limitations qu'ils présenteraient.

On m'a offert le travail le lendemain. Malheureusement, j’ai été incapable de le prendre pour des raisons personnelles.

Poser des questions sur le design ne devrait pas être un problème si ce sont des questions intelligentes, surtout si vous pouvez ensuite les associer à leurs activités.

Je n'ai pas beaucoup interviewé, mais d'après votre expérience, je conclurais:

a) C'est bien si vous voulez prendre une décision éclairée quant à savoir si vous voulez l'emploi.

b) Ce n'est pas OK si vous avez déjà décidé que vous voulez le travail.

Les gens peuvent facilement se sentir offensés par des quintes bénignes sur leurs choix. C'est un trait terriblement mauvais, mais commun.

Voici quelques conseils

1. Demander pourquoi ils ont choisi une solution existante peut être une mauvaise question, car l'équipe de développement n'a probablement pas eu la chance de la changer ou de la choisir.
2. De plus, l'équipe sait probablement déjà pourquoi la technologie n'était pas le meilleur choix
3. Mais malheureusement, la dernière chose dont toute équipe de développement a besoin est d'essayer de changer l'architecture ou de remettre en question les choix qui avaient été faits il y a 10 ans. Cela donne l'impression que leur technologie est déjà ancienne et que de tels messages circulent dans l'équipe peuvent rendre les développeurs malheureux. à propos de la situation actuelle
4. Ainsi, lors d’une interview, la dernière chose à faire est de donner l’impression que vous allez vous plaindre tout le temps des choix sur lesquels l’équipe n’a aucun contrôle.