Je peux vous dire qu'une telle approche serait très courageuse, et par courageuse, je l'entends dans le sens où courir dans les bois pour combattre un ours sans armes ni protection serait courageux et donnerait des résultats similaires.

Si vous participiez à une entrevue pour un poste de chef, vous ne voudriez pas franchir la porte et leur dire tout ce qui ne va pas avec leur menu, ce que vous feriez en fait. Ce serait mieux si vous pouviez signaler les bogues dans le travail de leur CONCURRENT.

Cela montre que vous pouvez repérer les bogues sans rien dire de mal à votre futur employeur potentiel. Si vous DEVEZ parler de leur version bêta, indiquez ce qu'ils ont bien fait et comment vous SAVEZ que c'est bien fait. Si vous êtes pressé pour des points négatifs, commencez de manière positive.

Eh bien, j'ai remarqué que le jeu est très fluide et que l'IA fonctionne très bien. Si je devais choisir quelque chose à changer, je pourrais soit choisir une couleur différente pour les noms, soit faire changer la couleur des noms s'ils se déplacent vers une zone où les couleurs correspondent.

Remarquez comment Je n'ai pas dit que c'était un mauvais choix, mais quelque chose qui pourrait être amélioré, et COMMENT? C'est l'approche que vous souhaitez adopter lors d'une interview.

Si vous postulez à un rôle de type QA, il y a beaucoup de valeur à signaler les bogues dans une version bêta. Vous démontrez instantanément votre sens aigu du détail et vous pouvez montrer votre style de rapports de bogues. N'hésitez pas à montrer ce que vous considérez comme des défauts du jeu, mais apportez vos justifications.

Cependant, si vous postulez pour un rôle de développeur, ralentissez. Les développeurs ont toujours des bugs exceptionnels qu'ils n'ont pas encore résolus. Si vous harcelez un intervieweur avec l'un de ses propres bugs exceptionnels (et le faites de manière insensible), cela pourrait le faire vous détester et vous pouvez dire au revoir au travail. Il est possible de signaler un bogue à un intervieweur dont il s'agit, mais n'oubliez pas de marcher légèrement. Ce n'est pas une bonne idée de dire à votre intervieweur qu'il a fait du mauvais travail, même par accident.

MODIFIER - Ajouter plus de conseils ....

Les développeurs de jeux adorent faire ajouter des œufs de Pâques et du charme à leur jeu. Par exemple, dans le dernier jeu Animal Crossing, le piranha a un cycle de nage par défaut autour de son réservoir dans l'aquarium. Cependant, si vous vous tenez debout contre le verre, il vous en grogne. C'est complètement sans conséquence pour le gameplay, mais vous pouvez dire aux gens qui l'ont mis en œuvre l'ont fait avec amour. Parcourez la démo et essayez de trouver des choses comme celle-ci que vous aimez vraiment dans la démo et évoquez-les plutôt que des bugs. Cela montre toujours de l'initiative et de l'intérêt pour le produit, mais vous êtes plus susceptible de susciter une forte réponse positive de la part d'un intervieweur lorsque vous discutez de choses que vous aimez plutôt que de choses que vous avez trouvées erronées.

Supposons qu'ils connaissent déjà tous les bogues que vous avez trouvés.

Leur application est en version bêta. Ils ont des testeurs QA. Ils connaissent les bogues, et probablement plus que vous n'avez pas trouvés. Ils ne devraient pas utiliser les entretiens avec les candidats comme moyen de tester leur propre application, et il est fort probable qu'ils ne le soient pas.

Donc, si vous décidez de signaler un bogue, faites-le en gardant cela à l'esprit. N'oubliez pas que vous leur dites ce qu'ils savent déjà et qu'ils connaissent certainement beaucoup mieux leur application que vous. Le point de leur dire devient une démonstration de votre propre capacité à remarquer les détails, et vous pouvez le faire en soulignant également les trous dans d'autres applications, celles qui n'ont aucun rapport avec la leur. Je ne vous suggère pas de signaler un bogue à moins qu'ils ne le demandent.

Si vous souhaitez leur parler des bogues que vous avez trouvés, utilisez le système de journalisation des bogues qu'ils suggèrent (généralement avec une version bêta, ils publieront des conseils sur la marche à suivre si vous trouvez un bogue. Suivez-le).

J'ai travaillé dans les jeux vidéo pendant plusieurs années. Je me souviens d'avoir obtenu la première version, de l'avoir jouée et d'avoir immédiatement discuté avec mon responsable technique de certaines choses que je considérais comme des bugs. Ce n'était pas une pré-entrevue; c'était au cours de la première semaine de mon entrée en fonction. Mon lead était totalement ouvert à la conversation, mais tout n'a pas été accepté comme un vrai bug.

Je dirais que 10 éléments séparés, c'est définitivement trop; ne vous attendez pas à les exposer tous. Au plus , ayez 3 points de ce type prêts à discuter.

Mais surtout, concentrez-vous sur les compétences que le poste attend de vous. Le repérage et le dépôt de rapports de bogues peuvent ou non être une activité professionnelle majeure. (Là où j'étais, il y avait un service Q / R dédié qui a pris plus de leadership à ce sujet.) Les compétences de base que vous devrez apporter en tant qu'ingénieur sont la capacité de corriger les bogues et de développer de nouvelles fonctionnalités. Si vous avez des exemples de code que vous avez développés ou sur lesquels vous avez travaillé, ou des questions de codage des enquêteurs, celles-ci seront beaucoup plus importantes.

N'hésitez pas à avoir 3 de ces éléments pour éventuellement montrer votre attention et votre intérêt dans le produit. Vous pouvez regarder pour voir si cela apparaît de manière semi-naturelle dans l'entrevue. Mais ne forcez pas et concentrez-vous sur les problèmes les plus prioritaires comme vos compétences en développement.

Si vous voulez le poste, vous devriez vous concentrer sur le fait que l'autre personne se sente bien de vous embaucher, donc évoquer des bogues par vous-même est sur la glace très mince.

Si on vous le demande, comment vous les compétences aident cette équipe / ce jeu / cette entreprise, alors vous pouvez en parler; mais ne l'appelez pas bug ou erreur de conception évidente. Améliorez votre capacité à terminer des éléments actuellement en version alpha / bêta et votre capacité à peaufiner.

Dites quelque chose comme:

J'ai repéré plusieurs domaines qui pourraient bénéficier d'un polissage, par exemple "insérez X ici" .Si vous évoquez les noms noirs, reconnaissez que c'est mineur.

Cela a probablement déjà été repéré et priorisé en bas. Comme cela n'est pas pertinent pour le gameplay de base, cela se fera probablement tard dans le projet.

La chose principale que vous devriez transmettre est que vous croyez en ce jeu et que vous pouvez contribuer à l'améliorer. L'engagement est une bonne chose chez les employés. La pensée critique est une compétence fondamentale pour un développeur. Beaucoup de managers ne sont pas des développeurs, donc vous bénéficierez grandement de la transmission de vos critiques d'une manière plus positive.

Il est également très important d'apprendre que les produits inachevés sont exactement cela: Inachevé. Vous ne les critiquez pas pour des détails mineurs. Ces petits détails seront (espérons-le) corrigés.

Je pense que c'est une bonne idée. C'est certainement une approche peu orthodoxe. Personnellement, j'attendrais qu'il décrive l'entreprise et son produit actuel.

Donc, si la conversation était comme ça:

.... Interviewer (I): "Avez-vous fait des recherches sur notre entreprise ou sur ce que nous faisons? "

Vous:" Oui, je remarque que vous avez actuellement un jeu appelé X disponible sur Y. Je suis allé de l'avant et l'ai téléchargé et essayé moi-même. "

I: "Oh ouais, qu'avez-vous pensé du produit?"

Vous: "Il est très bien et j'aime ça. Cependant, j'ai remarqué quelques bugs sur celui-ci surtout dans le zone de X, Y et Z. Si j'étais développeur, j'essaierais de regarder dans A, B, C et j'essaierais de faire D, E et F. "

Cela pourrait fonctionner. Je pense qu'ils vous regardent du point de vue d'un développeur / testeur et non d'un consommateur qui laisse une critique de produit. Donc, en tant que programmeur, je pense que connaître les bogues et ce qu'ils pourraient être est une bonne approche. Si c'est open source, peut-être même entrer avec du code pourrait être un bon bonus.

Maintenant, juste vous dire que "j'ai réparé la partie cassante" est une mauvaise idée. Je me souviens il y a quelque temps de l'histoire d'un adolescent qui souhaitait travailler pour Apple. Donc, ce qu'il a fait a été piraté dans le serveur et il a téléchargé quelque chose ou changé quelque chose. Apple n'a pas du tout été amusé par cela et il a eu de gros problèmes, mais étant donné son âge, il a reçu un laissez-passer.

Ensuite, il y a l'histoire du plombier sans travail. Apparemment, sa rue avait une sorte de problème et il a pris sur lui de le réparer. Il a en fait déchiré un tuyau de gaz naturel et a été tué sur le coup.

À l'époque pionnière des années 80 et 90, lorsque tout était nouveau, les entreprises recrutaient souvent des pirates informatiques ou des personnes qui cassaient leurs produits. Ils ne recherchent pas quelqu'un qui vient de changer un peu, mais plutôt des personnes qui ont une compréhension approfondie de l'exploit sous-jacent et comment l'utiliser. Je ne pense plus que cette approche soit un bon moyen. Je ne pense même pas que les gens pendant cette période cherchaient à être embauchés de cette façon, mais ils étaient simplement curieux ou ne se rendaient pas compte que leurs actes feraient tant de mal.

Donc, dans l'ensemble, je pense le "J'ai réparé votre produit cassé" est une approche honnête, mais risquée. C'est risqué parce que vous essayez de les impressionner en réparant un objet cassé et cela peut causer de la confusion ou même de la colère dans une certaine mesure, selon la façon dont vous le réparez. Il est préférable de simplement dire que vous l'avez téléchargé, et de donner quelques idées plutôt que d'essayer de le réparer en faisant quelque chose de mal comme le reverse engineering ou le piratage de leurs contenus.

La plupart des autres réponses sont beaucoup trop négatives, c'est une excellente idée mais cela doit être fait correctement. Il serait facile de croire que "vous êtes un groupe de bozos et je pourrais faire un meilleur travail", vous voulez montrer de l'empathie et de l'intérêt .

Alors vous dites quelque chose comme "J'ai téléchargé la démo de XYZ, c'est super, j'ai vraiment apprécié de l'utiliser, en particulier ABC, j'apprécie que ce soit les débuts et vous les avez probablement dans votre système de suivi des bogues, mais j'ai remarqué (problème a) et (question b). " De préférence, ce ne sont pas des bogues ou des problèmes graphiques manifestement évidents (souvent la dernière chose à être triée), mais quelque chose qui montre que vous avez pris du temps et de l'intérêt pour tout tester.

Dans la plupart des cas, je suis d'accord avec tous les autres commentaires selon lesquels vous voulez laisser un sentiment positif lors d'une interview, donc faire des critiques est au mieux risqué. De plus, l'intervieweur n'est probablement même pas la bonne personne avec qui partager de telles choses, donc cela ne fonctionnerait même pas s'il y était ouvert.

MAIS, une alternative que je pourrais voir fonctionner est que s'ils demandent des commentaires de la communauté pour le moment - ce que font certains, mais pas tous les jeux en pré-version ¹ - d'envoyer ce que vous avez collecté et pendant l'entretien, essayez de trouver un endroit pour vous mentionner avec désinvolture l'a fait. Dans le meilleur des cas, une belle situation se présente et cela laisse une bonne impression, dans le pire des cas, vous ne la mentionnerez pas ou ils s'en moquent.

^{1 La raison ils pourraient ne pas être intéressés du tout, c'est qu'ils ont déjà un arriéré de problèmes connus et ils ne commenceront à recueillir des commentaires qu'une fois qu'ils auront atteint un stade RC.}

Le plus proche que j'arrive à mentionner des problèmes dans une interview est de souligner que vous avez joué au jeu, mais suffisamment pour avoir réfléchi à leurs décisions de conception. Peut-être qu'à partir de là, vous pourriez marcher légèrement sur des choses que vous aimeriez être différentes. Ces commentaires doivent être soigneusement enveloppés d'énergie positive. Vous voulez dire que vous seriez ravi d'apprendre des développeurs pourquoi ils ont fait des choses, pas que vous vous sentiez qualifié pour les remettre en question.

Faire apparaître des bugs flagrants dans une interview est un suicide d'entreprise. Tirer, signaler des bugs est très sensible, même pour les employés seniors. Chaque fois que vous travaillez avec d'autres personnes et que vous soulevez un problème, vous devez considérer que a) la personne à qui vous parlez le sait déjà, b) elle a essayé de trouver des ressources pour résoudre le problème, et c) elle ' vous êtes énervé contre quelqu'un que le problème est là. Je suis considéré comme un jeu de tir très direct et j'ai vu des gens perdre la raison de colère quand je les ai confrontés à ce qui s'est avéré être un problème bien connu dans leur logiciel. Apprendre à aborder ces conversations est une compétence professionnelle sérieuse.