Qu'est-ce qui fait la différence entre «embaucher» et un «presque» honnête pour les dernières entrevues sur place? [fermé]

J'ai donc récemment eu des entretiens sur place avec Google et Amazon et reçu des lettres de rejet polies me faisant savoir que j'étais proche, mais pas tout à fait correct pour les compétences qu'ils recherchaient.

J'ai atteint le tour final pour toutes les interviews que j'ai faites (à l'exception de certaines offres de petits postes inintéressants que j'ai interviewés pour la pratique), mais jusqu'à présent, avoir 5-8 interviews en une journée me donne suffisamment de temps pour mes erreurs s'additionnent juste assez pour me mettre hors course.

Je sais que j'ai bien réussi là-bas au moins sur les questions de codage et d'autres questions techniques générales, apparemment je suis mal à concevoir des choses OOP comme les jeux de cartes ou les garages de stationnement (j'ai plongé trop profondément dans un objet et utilisé tout mon temps à la place d'être plus large) et mes réponses de codage bien qu'elles fonctionnent globalement n'avaient pas tout à fait quelques bogues / cas marginaux que j'ai manqués (comme un cas où un nœud d'entrée pourrait en fait être la réponse plutôt que d'avoir besoin d'être distinct). Et je n'ai aucun problème à dire "je ne sais pas", mais peut-être que je divague un peu et que je dois le dire pour des questions auxquelles je pense pouvoir répondre, mais je ne peux pas donner une réponse précise à ...

Alors, quelles sont les choses qui vous poussent à être bon, mais pas tout à fait à "embaucher"?

Avez-vous des conseils sur ce que vous recherchez ou sur quelque chose que vous savez qui vous a donné ce petit coup de pouce supplémentaire?

Tout d'abord, je vous suggère de contacter le représentant RH des deux sociétés et de leur demander si elles peuvent vous donner des détails sur le «pourquoi». Il est très probable qu'ils seront en mesure de vous donner des indices sur les erreurs que vous avez commises ou sur les choses sur lesquelles vous devriez travailler.

Deuxièmement, n'abandonnez pas! Si vous voulez vraiment travailler pour l'une de ces entreprises, attendez quelques mois, peut-être un an et postulez pour un autre emploi. Il se pourrait que vous n'ayez pas «gelé» avec un intervieweur en particulier et si vous avez un entretien avec quelqu'un d'autre, ils diront «embaucher».

Enfin, si vous pensez que vous avez bien fait en termes de réponses techniques, alors un aspect important qu'ils recherchent est de savoir si vous êtes ou non un candidat «culturel». C'est-à-dire, si vous allez vous intégrer au reste de l'équipe et si votre personnalité est un bon match. Faites des recherches sur la culture de l'entreprise et décidez si c'est quelque chose que vous pensez pouvoir intégrer et assurez-vous de le démontrer également lors de l'entretien.

Bonne chance et n'abandonnez pas!

Comme l'a dit Dean, vous êtes évalué sur plusieurs attributs, et ceux-ci sont généralement:

• Compétences techniques
• Que vous fassiez partie de l'équipe
• Processus de pensée
• etc.

Les compétences techniques requises pour le poste varieront en fonction de l'équipe avec laquelle vous interviewez.Par conséquent, si cela ne fonctionne pas avec une équipe, vous pouvez (en fonction de l'entreprise) postuler à nouveau et trouver un meilleur ajustement avec une autre équipe. Alors ne perdez pas espoir!

La majorité des compétences techniques sont généralement testées avec des problèmes de codage. Vous avez mentionné que vous aviez occasionnellement manqué un cas de frontière et que quelques bogues se sont glissés (comme ils le font inévitablement lorsqu'on leur a demandé de coder sur un tableau blanc). Une bonne approche pour répondre à ces questions de codage consiste à procéder comme suit:

• Comprendre ce qui est demandé (demander de répéter certaines parties si nécessaire)
• Poser des questions de clarification (itérativement / récursivement, existe-t-il des contraintes spécifiques?, Quelle langue?, Etc.)
• Identifier les structures de données, les algorithmes et les modèles de conception appropriés qui peuvent être utilisés (les entrevues de programmation exposées et les perles de programmation sont utiles pour cela)
• Écrivez le code, tout en expliquant à haute voix à l'entretien quel est votre processus de réflexion . Si l'enquêteur sait ce que vous pensez, il pourra peut-être identifier tôt les problèmes de votre approche et vous guider vers une meilleure solution.
• Avant de dire à l'intervieweur que vous avez terminé, réfléchissez et expliquez à l'intervieweur comment vous testeriez le logiciel que vous venez d'écrire. Pensez aux cas simples, aux cas de frontière, à la simultanéité, si l'approche a du sens pour d'autres cultures, aux implications pour la sécurité, aux tests de résistance, etc.

Enfin, admettre que vous ne savez pas quelque chose est (à mon humble avis) préférable de trébucher en essayant de le truquer. Certes, l'entrevue vous demande de résoudre un problème, mais si vous ne savez pas par où commencer, je vous recommanderais de parler des approches valides et d'essayer de restreindre une approche correcte qui résout les contraintes données. Si vous ne savez pas par où commencer, il est peut-être temps de l'expliquer (cela dépend également de la façon dont vous vous situez dans l'équipe. Je dirais qu'il vaut mieux demander une direction tôt). Donc, je ne pense pas que dire que vous ne savez pas est une mauvaise chose (en supposant que ce n'est pas tout ce qui est dit =])

Il n'y a pas grand-chose que vous puissiez faire sur la forme, comme cela revient souvent à une opinion personnelle de l'enquêteur, mais converser avec l'enquêteur sur ce que vous pensez / faites est préférable au codage en silence pendant 15 minutes, puis à déclarer "J'ai terminé".

Gardez à l'esprit que ces choses sont généralement des entretiens à double sens . Ils ne vous interviewent pas seulement, vous les interviewez également. N'hésitez pas à poser des questions sur l'emploi / l'équipe / l'entreprise.

Enfin, les recruteurs Microsoft publient une quantité assez importante d'informations sur ce qu'ils recherchent lors d'un écran / d'une interview téléphonique.Je vous recommande donc de les lire. De plus, GlassDoor a beaucoup d'informations sur les processus d'entrevue pour les entreprises (mais les réponses soumises par l'utilisateur ne sont pas toujours correctes). Une recherche Google pour les questions d'entrevue MS / Google / Amazon / Apple / etc donnera également des résultats.

Bonne chance.

Cela peut sembler élitiste, mais la vérité brutale est qu'il n'y a peut-être rien que vous auriez pu faire pour être embauché. Ils recherchent une certaine quantité de talent et tout le monde ne l'a pas. Nous acceptons ce fait dur dans les arts de la scène - peu importe combien de personnes pratiquent, elles ne pourront pas être embauchées au New York Philharmonic. Un doctorat. en anglais ne vous permettra pas d'écrire un grand roman. Cela est également vrai pour les équipes de logiciels d'élite. Ils n'interviewent pas pour trouver des gens qui connaissent une technologie spécifique. Ils interviewent pour trouver des personnes qui s'intégreront: des personnes ayant une vision approfondie de la programmation, qui peuvent suivre l'équipe, suivre des discussions techniques rapides, choisir de nouveaux langages, apporter de nouvelles idées, créer de nouvelles technologies.

==== 3/7/2014 ====

Cette entrevue avec Laszlo Bock semble d'accord. Google ne se soucie pas des diplômes, des notes ou des résultats des tests:

L'une des choses que nous avons vues de toutes nos données croisées est que les GPA ne valent pas comme critère d'embauche, et les scores aux tests ne valent rien - aucune corrélation du tout, sauf pour les nouveaux diplômés des collèges, où il y a une légère corrélation. Google avait l'habitude de demander à tout le monde une transcription et des notes de GPA et de test, mais nous ne le faisons plus, sauf si vous n'êtes que quelques années hors de l'école. Nous avons constaté qu'ils ne prédisent rien. ... Nous avons cinq attributs d'embauche dans toute l'entreprise. S'il s'agit d'un rôle technique, nous évaluons votre capacité de codage et la moitié des rôles dans l'entreprise sont des rôles techniques. Pour chaque travail, cependant, la chose n ° 1 que nous recherchons est la capacité cognitive générale, et ce n'est pas le QI, c'est la capacité d'apprentissage. C'est la capacité de traiter à la volée. C'est la capacité de rassembler des informations disparates. Nous évaluons cela en utilisant des entretiens comportementaux structurés que nous validons pour nous assurer qu'ils sont prédictifs.

Il semble que vous ayez déjà identifié vous-même certains domaines dans lesquels vous pouvez vous améliorer.

En combinant ces aspects avec votre question précédente , sans rien savoir de vous, je recommanderais un effort du côté de l' ingénierie , en étant capable de concevoir un logiciel pratique et de communiquer clairement cette conception. Plutôt que d'apprendre plus de théorie CS, lisez quelques livres comme Programming Pearls , Refactoring , C ++ Coding Standards et Code Complete . Si l'un des emplois "inintéressants" vous donne la responsabilité de concevoir de vrais logiciels, prenez le travail et rendez- le intéressant. Dans le monde réel, vous vous sentez souvent comme ce gars, mais il peut toujours être très satisfaisant de savoir que vous avez abordé un problème difficile, même s'il peut être dans une application banale.

Ok, juste pour apporter une expérience pratique ici.

Je travaille pour l'une de ces sociétés de logiciels d'élite et je ne trouve pas que nos politiques d'embauche visent à «ne pas manquer» de grands talents mais à «ne pas embaucher» des talents médiocres. J'ai vu que certaines de ces entreprises veulent vraiment embaucher des gens formidables, mais elles le font en interviewant de nombreux développeurs (sur papier) de très belle apparence, puis en éliminant celles dont elles ne veulent pas. Une fois que quelqu'un est embauché, il est très difficile de s'en débarrasser, il est donc avantageux de refuser un candidat qui, selon vous, peut être un bon choix, mais que l'un des enquêteurs a vu des signaux d'alarme.

Dans l'entreprise pour laquelle je travaille actuellement, j'ai été refusée parce qu'un et un seul des enquêteurs (le plus important) m'a donné un coup de pouce. Cet intervieweur m'a posé une question très spécifique au domaine et ne parlait pas couramment l'anglais. Ils ne m'ont pas embauché, mais l'équipe a pensé que l'entreprise allait rater une location potentiellement bonne. Ils m'ont envoyé à une autre série d'entretiens avec une autre équipe la semaine prochaine et j'ai obtenu le poste (avec des notes de "forte embauche", je pourrais ajouter).

Mon conseil est que si vous croyez vraiment que vous avez ce qu'il faut, continuez à interviewer cette entreprise et apprenez de chaque expérience jusqu'à ce que vous décrochiez le poste. La plupart de ces entreprises tiennent un registre de toutes les personnes qu'elles interrogent et inscrivent sur la liste noire les candidats pauvres (afin de ne jamais obtenir une autre photo). Cependant, les candidats qui étaient de bons candidats mais qui n'ont tout simplement pas bien performé ce jour-là ou qui ne cadraient pas bien avec l'équipe resteront dans le bassin d'embauche. Vous saurez immédiatement si vous avez été mis sur liste noire lorsque les appels téléphoniques du recruteur s'arrêtent un jour et que tout contact futur semble faire la sourde oreille. Si vous recevez de futures demandes de renseignements de la part de l'entreprise, vous savez que tout va bien. Il n'y a absolument aucun mal à organiser plus d'entretiens après votre premier refus tant que vous n'êtes pas sur la liste noire. En réalité, Je recommanderais fortement d'interviewer plusieurs équipes à la fois. Les enquêteurs vont vous rejeter au premier signe de trouble perçu, qu'il s'agisse ou non d'un réel trouble. Ils sont prudents et ne veulent pas faire beaucoup plus de mauvaises embauches qu'ils ne veulent en faire de bonnes.

Quelques réflexions supplémentaires:

- Aucune de ces sociétés ne vous fera part de vos commentaires. C'est une responsabilité légale. Ça craint que ce soit comme ça, mais je peux vous promettre que ça n'arrivera pas.

- J'ai personnellement parlé à un ingénieur brillant lorsque j'ai interviewé Microsoft qui m'a dit qu'il lui avait fallu plus de 5 essais avant d'être finalement embauché. Ce gars était un SDE de niveau supérieur, donc MSFT a évidemment validé qu'il était un bon employé en le promouvant.

Quelques conseils:

Connaissez vos structures de données et algorithmes en arrière et en avant. Vous devez tout savoir jusqu'à la traversée des graphiques.

Connaître l'architecture, en particulier les systèmes distribués et les problèmes d'échelle

Ayez une liste des projets que vous avez menés à mémoriser. Gardez en mémoire une liste d'exemples de principes de leadership que vous avez exposés dans votre travail. Ce sont les questions les plus difficiles à répondre lors de l'entretien (entretiens comportementaux). Vous pouvez être parfait dans le côté technique et si vous ne survivez pas à l'entretien comportemental, vous ne serez pas embauché.

Ne vous inquiétez pas des langages de programmation qu'ils recherchent. Connaître un langage orienté objet en arrière et en avant et coder en cela. L'intervieweur ne se soucie généralement pas de la langue dans laquelle vous codez et ne vous juge pas en fonction de cela.

Enfin, veuillez m'envoyer votre CV par e-mail. ; =)

Pas nécessairement raté en se trompant

Peut-être que vous n'avez rien fait de mal, mais quelqu'un d'autre a fait mieux. Peut-être en termes de personnalité, de compétences en communication, d'interrelation, d'expérience similaire de projet, etc.

Vous avez peut-être été très bien embauché, mais ce n'était pas seulement vous sur la liste. Je ne m'inquiéterais pas trop. Tout arrive dans un but.