Je Suis Un Ingénieur Logiciel Expérimenté Depuis 5 Ans Et J’ai Pour Objectif De Décrocher Un Entretien Pour Des Entreprises Comme Google, Facebook, LinkedIn, Etc. Comment Dois-je Procéder Pour Ma Préparation (ressources, Papiers, Etc.) ?

Posted on by Jean-Christophe Bourgeois

Il y a quatre choses qui jouent un rôle clé dans l’obtention d’un emploi/stage dans une grande entreprise.

1. Votre préparation à l’entretien. La plupart des grandes entreprises recherchent votre capacité à résoudre de nouveaux problèmes. Les algorithmes et la structure des données sont des outils qui seront utilisés dans ce processus.

une. Vous pouvez trouver de nouveaux problèmes sur topcoder, codechef, déchiffrer l’entretien de codage, leet code, geeksforgeeks, glassdoor, carrière cup, etc. Résoudre de nouveaux problèmes peut vraiment vous aider à améliorer votre processus de réflexion, votre capacité de codage et votre confiance.

b. Pratiquez autant que vous le pouvez sur un tableau blanc. Je pense personnellement que c’est t

Continuer la lecture

Il y a quatre choses qui jouent un rôle clé dans l’obtention d’un emploi/stage dans une grande entreprise.

1. Votre préparation à l’entretien. La plupart des grandes entreprises recherchent votre capacité à résoudre de nouveaux problèmes. Les algorithmes et la structure des données sont des outils qui seront utilisés dans ce processus.

une. Vous pouvez trouver de nouveaux problèmes sur topcoder, codechef, déchiffrer l’entretien de codage, leet code, geeksforgeeks, glassdoor, carrière cup, etc. Résoudre de nouveaux problèmes peut vraiment vous aider à améliorer votre processus de réflexion, votre capacité de codage et votre confiance.

b. Pratiquez autant que vous le pouvez sur un tableau blanc. Personnellement, je pense que c’est la partie la plus importante de la préparation.

c. Pratiquez des entretiens fictifs avec des amis. Chronométrez vos performances puisque vous résoudrez des problèmes en 45 minutes.

N’oubliez pas que connaître une langue ne fait pas nécessairement de vous un bon poète ou un bon écrivain.

2. Quelque chose de différent : si vous avez quelque chose d’unique qui se démarque des autres, alors cela aide vraiment à se faire remarquer.

3. Obtenir un entretien : Pour cela, vous devez essayer toutes les options possibles.

une. Postulez sur le site de l’entreprise.

b. Contactez les RH sur LinkedIn.

c. Si vous connaissez quelqu’un dans l’entreprise, demandez-lui une référence.

4. Chance : après avoir été complètement préparé et avoir obtenu un entretien, votre performance le jour de l’entretien dépend en grande partie de votre chance. Puisque vous n’avez aucun contrôle sur votre état d’esprit, la personne qui vous interroge, etc.

Bonne chance!

Vous devriez consulter ce livre : Cracking the Coding Interview (livre 2011) par Gayle Laakmann McDowell. C’est un livre génial avec d’excellentes questions de codage, je l’ai acheté il y a quelques jours (via Amazon) et j’ai commencé à résoudre les questions. Je prépare également les entretiens d’embauche (dernière année B.Tech CSE).

Fin 2017, j’ai passé un entretien chez Google. Dans les mois qui ont précédé les entretiens, j’ai beaucoup préparé. J’aimerais partager comment je pense qu’il faut se préparer à une telle interview et donner quelques conseils.

Les opinions sont les miennes.

Comment préparer

J’aime séparer la préparation en trois parties :

  • Théorie
  • Problèmes de codage
  • Questions sur l’architecture du système

Théorie

Cela inclut tout ce que vous êtes censé savoir en tant qu’ingénieur logiciel. Des choses comme : l’analyse de la complexité, les structures de données, les algorithmes, la manipulation de bits, les systèmes d’exploitation, le multi-threading, l’architecture du système, les nombres, le fonctionnement du matériel et la mise en réseau, pour n’en nommer que quelques-uns. Les

Continuer la lecture

Fin 2017, j’ai passé un entretien chez Google. Dans les mois qui ont précédé les entretiens, j’ai beaucoup préparé. J’aimerais partager comment je pense qu’il faut se préparer à une telle interview et donner quelques conseils.

Les opinions sont les miennes.

Comment préparer

J’aime séparer la préparation en trois parties :

  • Théorie
  • Problèmes de codage
  • Questions sur l’architecture du système

Théorie

Cela inclut tout ce que vous êtes censé savoir en tant qu’ingénieur logiciel. Des choses comme : l’analyse de la complexité, les structures de données, les algorithmes, la manipulation de bits, les systèmes d’exploitation, le multi-threading, l’architecture du système, les nombres, le fonctionnement du matériel et la mise en réseau, pour n’en nommer que quelques-uns. Il s’agit d’un mélange de choses que vous apprendrez à l’école, par l’expérience professionnelle et en lisant des livres/blogs/recherche/etc.

Vous pouvez retrouver toutes mes notes ici :

  • https://github.com/orrsella/soft-eng-interview-prep

Problèmes de codage

La plupart de ce que vous ferez au cours d’un entretien est d’écrire du code pour résoudre divers problèmes (d’autres choses seront des discussions techniques, des questions sur l’architecture du système et vos propres questions). Ils nécessiteront généralement au plus quelques dizaines de lignes (il est difficile d’en faire beaucoup plus que cela sur un tableau blanc en 40 minutes environ). La meilleure façon de s’y préparer est de simplement s’entraîner et d’en résoudre autant que possible.

Les meilleures ressources que j’ai utilisées pour pratiquer les questions de codage sont :

  • Décryptage de l’entretien de codage, 6e édition
  • Éléments de programmation des entrevues

Ma recommandation serait d’obtenir au moins un de ces livres et de le résoudre d’un bout à l’autre. Il existe de nombreux autres outils en ligne comme LeetCode et diverses banques de questions. Une fois que vous vous sentez à l’aise avec la résolution de ce type de questions, parcourez quelques questions réelles qui ont été récemment posées lors d’entretiens dans l’entreprise pour laquelle vous interviewez, en effectuant une recherche sur Glassdoor.

Questions sur l’architecture du système

Ce sont une bête complètement différente des questions de codage. Ils sont beaucoup plus nuancés et impliquent beaucoup plus de discussions/d’explications et presque aucun code réel. Les préparer est plus difficile et moins simple, surtout si vous n’avez jamais travaillé sur des systèmes distribués auparavant.

À faire et à ne pas faire

Quelques conseils, sans ordre particulier :

  • Écrivez du code réel qui fonctionne, pas du pseudo-code
  • Optez pour un langage de programmation grand public (Java, C/C++, Python, JavaScript)5
  • Entraînez-vous à coder sur un tableau blanc6
  • Entraînez-vous à coder sur papier (de préférence vierge, sans lignes)
  • Écrivez un code propre : Utilisez de bons noms (classes/fonctions/variables) Faites preuve d’une bonne modularité (classes/fonctions)Laissez du temps pour la vérification des erreurs et les cas limites, c’est encore mieux pour commencer avec eux (ou ajoutez des TODOs pour vous-même)Si vous faites des économies dites-le à voix haute et dites ce que vous feriez si vous aviez plus de temps (par exemple, en Java : j’utilise des champs publics par souci de concision ici, mais j’utiliserais autrement des getters/setters)
  • Utilisez des algorithmes et des structures de données appropriés et assurez-vous d’indiquer Big-O pour chacun d’eux
  • Lorsque vous abordez un problème pour la première fois : assurez-vous de bien comprendre la tâche. Répétez-le pour le montrer à vous-même et à l’intervieweur. Ne commencez pas par écrire le code immédiatement ! Posez des questions sur la tâche, les entrées, les hypothèses, les formats ; la plupart des questions sont sous-spécifiées à dessein. Ne supposez rien ! Ou déclarez que vous le faites Réfléchissez à haute voix, partagez ce que vous pensez (réfléchissez) Essayez de montrer comment vous pensez à travers le problème Le silence n’est pas bon, les longs sont mauvais Assurez-vous que l’intervieweur a une idée claire de la façon dont vous vous débrouillez (pour qu’ils puissent vous aider !) Commencez par un exemple simple, ajoutez plus tard des exemples détaillés Clarifiez la signature de fonction du problème dès le début. Cela vous aidera à concentrer vos pensées et éventuellement à inviter des conseils subtils de la part de votre interlocuteur. Commencez par une solution simple et inefficace (simple ! = facile)
  • Les questions sont approfondies, n’ont généralement pas de solution facile (cela peut être simple)
  • Pensez à la validation des entrées, aux contraintes
  • Pensez aux cas de test, parcourez-les pour vous assurer que le code est correct (mais ne supposez pas qu’il est correct, vérifiez vraiment comme si quelqu’un d’autre l’avait écrit)
  • Si l’intervieweur a donné des exemples/indices, utilisez-les
  • Une fois terminé, demandez si vous pouvez affiner le code, améliorer les noms de variables, extraire d’autres méthodes, etc.
  • Laissez de côté les parties triviales comme des fonctions que vous devez implémenter et ne revenez à celles-ci que si vous avez le temps
  • À la fin de la première solution, essayez de l’améliorer ou essayez de trouver une solution différente qui soit meilleure (par exemple: récursivité vs code impératif)
  • Les hypothèses peuvent maintenant changer, et la solution doit donc être adaptée
  • Passer en revue les API standard si vous n’êtes pas sûr que cela va, assurez-vous de l’indiquer et de donner une API raisonnable avec laquelle travailler
  1. Ceci, et beaucoup d’autres choses de cet article, s’appliquent également à d’autres entreprises technologiques – YMMV.
  2. Je reconnais que le processus d’embauche de ces entreprises est controversé et que beaucoup de gens ne pensent pas qu’il évalue vraiment votre expertise en tant qu’ingénieur logiciel. J’ignore délibérément cela, et je suppose que c’est ce que vous voulez. Si vous souhaitez obtenir une offre de ces entreprises, c’est le « jeu » auquel vous devrez jouer.
  3. Je pense à cela du point de vue d’un ingénieur avec 3 à 10 ans d’expérience. Je suppose que si vous êtes un nouveau diplômé, les attentes sont un peu différentes.
  4. Vous seriez surpris de voir à quel point cela pourrait être pratique.
  5. Vous pouvez très probablement programmer dans la langue de votre choix, mais il vaut mieux que votre interlocuteur connaisse la langue de votre choix et puisse vous aider si vous êtes bloqué. Ces choix augmentent les chances de cela. ??
  6. Sérieusement, achetez un tableau blanc pour vous entraîner à la maison. Vous vous sentirez beaucoup plus à l’aise avec et vous apprendrez à mieux gérer l’espace qui s’y trouve.

J’ai passé trois semaines à préparer l’entretien téléphonique et deux semaines supplémentaires à l’entretien sur place. J’ai essentiellement arrêté d’utiliser l’ordinateur pour coder et je l’ai fait uniquement sur un tableau blanc (vous pouvez en obtenir un pour 5 €) ou sur un morceau de papier.

J’ai passé 2,5 heures à préparer chaque jour en semaine et 8 heures par jour le week-end. La première chose que j’ai faite a été de créer un programme des choses que je voulais faire chaque jour, des choses comme : Résoudre deux problèmes d’algorithmes, un problème de conception, implémenter A*, implémenter un arbre rouge-noir, etc. Je l’ai fait parce que le premier jour j’ai paniqué en essayant d’apprendre un peu de veille

Continuer la lecture

J’ai passé trois semaines à préparer l’entretien téléphonique et deux semaines supplémentaires à l’entretien sur place. J’ai essentiellement arrêté d’utiliser l’ordinateur pour coder et je l’ai fait uniquement sur un tableau blanc (vous pouvez en obtenir un pour 5 €) ou sur un morceau de papier.

J’ai passé 2,5 heures à préparer chaque jour en semaine et 8 heures par jour le week-end. La première chose que j’ai faite a été de créer un programme des choses que je voulais faire chaque jour, des choses comme : Résoudre deux problèmes d’algorithmes, un problème de conception, implémenter A*, implémenter un arbre rouge-noir, etc. Je l’ai fait parce que le premier jour, j’ai paniqué en essayant d’apprendre un peu de tout en même temps, tout en pensant que j’avais besoin de tout savoir tout de suite. Créer un plan m’a aidé à me concentrer sur quelques sujets par jour en sachant que j’aurais le temps d’étudier tout ce que je voulais préparer. Le week-end, j’ai également pris du temps, 1 à 1,5 heures, pour revoir ce que j’avais étudié pendant le reste de la semaine.

La dernière partie, mais non la moins importante de ma préparation, consistait à faire en sorte que les amis qui ont suivi le processus d’interview de Google fassent une simulation d’interview avec moi. J’ai eu presque une fausse interview chaque week-end (parfois deux). Les commentaires reçus lors de ces entrevues ont été inestimables. Cela m’a aidé à corriger mes erreurs de communication à temps. Ils m’ont également aidé à concevoir une série d’étapes que j’utiliserais pour résoudre chaque type de problèmes (essentiellement une pour les problèmes d’algorithmes et une autre pour les problèmes de conception).

J’ai également arrêté tous les préparatifs de codage et de résolution d’algorithmes un ou deux jours avant l’entretien proprement dit. C’est une politique que j’ai développée pendant que j’étudiais pour mes examens à l’université. Le raisonnement est le suivant : si vous vous êtes suffisamment bien préparé, résoudre ce problème supplémentaire un jour avant n’aidera pas beaucoup vos compétences globales, mais si vous ne pouvez pas le résoudre, vous paniquerez vraiment, penserez que vous n’êtes pas prêt et c’est certainement le dernière chose dont vous avez besoin. À ce stade, je me suis concentré sur la préparation des questions de compétences générales. Des choses comme : quel était votre plus gros défi, le bug le plus difficile, etc. Vous aurez 5 entretiens par jour, au moins un gars va vous poser une question sur les compétences générales et vous feriez mieux d’être prêt pour cela (en fait, on m’en a demandé une lors de ma dernière interview quand j’étais épuisé).

Pour préparer j’ai utilisé les livres suivants :

  1. Décrypter l’entretien de codage : de loin la meilleure ressource sur l’entretien. La seule chose que je voudrais ajouter au livre est : n’écrivez pas de code lorsque vous résolvez les questions de conception. Pensez aux cases représentant les modules et leurs relations. On ne m’a pas demandé d’écrire du code lors de l’entretien de conception et je pense que l’écriture de code peut vous obliger à simplifier à l’excès les problèmes de conception. En fait, on m’a posé deux problèmes tirés directement de ce livre.
  2. Introduction aux algorithmes : j’ai utilisé celui-ci pour revoir les structures de données et me souvenir de leur fonctionnement. Je n’ai pas pris la peine de résoudre leurs problèmes puisqu’il s’agit principalement de prouver des choses. Bien que je ne sois pas contre les manifestations, ce n’est pas le sujet de l’interview.
  3. Probabilités et statistiques par Morris H. DeGroot. Les recruteurs ont mentionné qu’il pourrait y avoir des problèmes de combinatronique lors de l’entretien, et les premiers chapitres de ce livre l’expliquent parfaitement. Le livre contient de nombreux problèmes pratiques sur le sujet, ce qui est parfait car les problèmes de combinatronique sur la plupart des livres de mathématiques discrètes concernent principalement des démonstrations. J’ai suivi jusqu’à la première moitié du chapitre sur les distributions de probabilité (vraiment, juste jusqu’à ce que j’aie la bonne distribution binomiale).
  4. Head First Design Patterns : Le design était mon point faible, et j’ai donc consacré beaucoup d’efforts à l’améliorer. J’ai essayé plusieurs fois avec le livre “Design Patterns: Elements of Reusable Object Oriented Software”, mais je ne l’ai jamais complètement compris. Head First est un excellent livre sur le design en général. Ce que j’ai appris en lisant m’aidera certainement beaucoup dans ma vraie vie. Il est préférable de se préparer aux problèmes de conception si vous avez un programmeur ou un architecte vraiment expérimenté pour vous aider. Malheureusement, ceux que je connais sont des collègues à moi et je ne pouvais pas compter sur eux, j’ai donc dû trouver un processus pour résoudre ce genre de problèmes.
  5. Hackers Delight : Au cours du processus, il est presque certain qu’au moins un problème sera de jouer avec des bits (j’en ai un à ce sujet). C’est de loin le meilleur livre sur le sujet.
  6. J’ai également lu les articles de Google sur GFS et MapReduce, et on m’a en fait posé des questions qui pourraient être résolues très facilement en les utilisant. Les enquêteurs peuvent ne pas autoriser l’utilisation de GFS ou de MapReduce dans votre solution, mais mentionner comment vous résoudriez votre problème avec eux vous apportera certainement un plus. Lisez-les !

Malgré la suggestion des recruteurs, je n’ai personnellement pas trouvé « Perles de programmation » ou « Interviews de programmation exposées » particulièrement utiles. Les deux premiers chapitres ou Programming Pearls sont OK, mais vous ne manquerez pas grand-chose sans les lire. Le reste des perles concerne principalement des problèmes pertinents dans les années 70 ou 80, c’est-à-dire quand il a commencé à parler de l’utilité d’utiliser des tableaux au lieu de nommer vos variables a1, a2, etc. J’ai réalisé qu’il avait été écrit pour les programmeurs B et je me suis arrêté En le lisant. Le deuxième livre a une bonne introduction au processus d’entretien, mais rien qui n’est pas dans l’entretien Cracking the Coding, et les problèmes sont si faciles qu’ils ne sont pas un défi à résoudre et donc pas très bons à préparer. Si vous voulez dépenser votre argent judicieusement, achetez Craking the Coding Interview.

Les autres ressources que j’ai utilisées étaient :

  1. Wikipedia : J’ai basé mes implémentations des algorithmes Dijkstra, A* et Knuth-Morris-Pratt sur celles de wikipedia. J’ai également vérifié d’autres éléments ici, car je pense que c’est plus facile à comprendre que le livre trop technique de Cormen.
  2. CareerCup est un excellent site pour trouver des questions. Je dois dire cependant que les questions marquées comme Google ont tendance à être pleines d’étudiants qui essaient de vous faire résoudre leurs devoirs, donc parfois les questions sont vraiment étranges. Vérifiez ceux marqués amazon, ils ont tendance à être excellents.
  3. Le projet Euler a beaucoup ou de beaux problèmes. J’ai résolu les 50 premiers d’entre eux. Ce ne sont pas le genre de questions que l’on va vous poser, mais elles mettent votre esprit en mode résolution de problèmes.
  4. J’ai découvert que l’un des meilleurs moyens d’en savoir plus sur de nombreux algorithmes est de vérifier comment ils sont implémentés dans la bibliothèque standard C++. Ou du moins pour réfléchir à la façon dont vous les implémenterez si vous écriviez la STL. Par exemple, je ne me suis jamais demandé comment implémenter un algorithme pour générer toutes les permutations d’un ensemble jusqu’à ce que je le vérifie dans la STL.
  5. Beaucoup de gens recommanderont d’utiliser le codeur supérieur. Malgré tous mes efforts, je n’ai jamais réussi à le faire fonctionner sur mon ordinateur donc j’ai dû m’en passer. Je suppose que si vous n’avez pas accès au livre Cormen, ses tutoriels sont parmi les meilleurs sur Internet.
  6. OverTheWire – Wargames propose des liens vers certains des meilleurs tutoriels sur Internet sur de nombreux sujets. Je l’ai utilisé il y a longtemps, pas pour cette interview, mais j’en ai beaucoup appris. En particulier, je n’ai vraiment compris comment un programme est mappé en mémoire que grâce à ses tutoriels.

Pour conclure, je dois dire que tout l’intérêt de la préparation est simplement de mettre votre cerveau dans le bon état d’esprit. Après toute cette formation, il était surprenant de voir qu’une fois que j’ai vu un problème, je savais tout de suite quelle structure de données utiliser et à quoi ressemblerait l’algorithme. C’est le point que vous voulez atteindre. Les problèmes eux-mêmes ne sont pas pertinents, mais la bonne mentalité de résolution de problèmes est tout.

Ai-je reçu une offre ? Eh bien, je ne sais toujours pas. Je suis assez confiant pour les entretiens 2-5. J’ai résolu les problèmes sans difficultés majeures. Mais j’étais tellement nerveux que je pense que j’ai foiré le premier, donc je ne sais pas. Je dirai quand j’aurai une réponse.

Pas trop dramatique, mais beaucoup de sang, de sueur et de larmes. Surtout ce dernier.

Voici les étapes que j’ai suivies, principalement dans l’ordre :

  1. J’avais, à mon avis, bien sûr, une base assez solide d’algorithmes et de structures de données grâce aux cours que j’ai suivis au premier cycle. Cela m’a énormément aidé. Dans cette veine, je recommande fortement Introduction to Algorithms by CLRS.
    Le livre contient de nombreuses preuves mathématiquement rigoureuses dont vous n’aurez probablement pas besoin, mais il couvre tous les algorithmes et structures de données que vous pourriez éventuellement rencontrer lors d’un entretien technique.
  2. En dehors des bases, vous devez savoir e

Continuer la lecture

Pas trop dramatique, mais beaucoup de sang, de sueur et de larmes. Surtout ce dernier.

Voici les étapes que j’ai suivies, principalement dans l’ordre :

  1. J’avais, à mon avis, bien sûr, une base assez solide d’algorithmes et de structures de données grâce aux cours que j’ai suivis au premier cycle. Cela m’a énormément aidé. Dans cette veine, je recommande fortement Introduction to Algorithms by CLRS.
    Le livre contient de nombreuses preuves mathématiquement rigoureuses dont vous n’aurez probablement pas besoin, mais il couvre tous les algorithmes et structures de données que vous pourriez éventuellement rencontrer lors d’un entretien technique.
  2. En dehors des bases, vous devez savoir à quoi ressemble un entretien technique et à quoi vous attendre. Je suis sûr qu’il y a 100 autres réponses sur Quora seul qui mentionnent Cracking the Coding Interview, mais je vais le faire une fois de plus parce que c’est tellement bon. La stratégie de préparation et l’explication du fonctionnement des entretiens sont très précieuses dans mon expérience.
  3. À ce stade, tout ce dont j’avais vraiment besoin, c’était de la pratique et j’ai appris cela à la dure. À l’automne 2017, j’ai été rejeté par Google, Facebook, Amazon et la plupart des autres entreprises technologiques dont vous avez probablement entendu parler, pour un stage d’été.
    J’ai passé l’été à améliorer mes compétences techniques en entretien, alias Leetcode. J’admets que ce n’est pas pour tout le monde et que vous n’avez vraiment besoin de résoudre que plusieurs types de questions pour couvrir la plupart des entretiens.
    Personnellement, j’aime la programmation compétitive et la résolution de problèmes, j’ai donc résolu plus de 250 problèmes, ce qui m’a donné la confiance nécessaire pour répondre à la plupart des questions qui me sont posées.
  4. Heureusement, il me restait suffisamment de temps pendant l’été pour travailler sur un projet parallèle plutôt cool et je recommanderais à toute personne postulant à un poste d’ingénieur logiciel de faire de même. Des points bonus si vous le mettez sur votre Github pour que les recruteurs/intervieweurs puissent les consulter.
  5. Les entretiens techniques sont évidemment très importants. Cependant, l’adéquation à la culture est quelque chose qui est souvent négligé. Vous aurez probablement au moins un entretien adapté à la culture au cours duquel ils vous poseront des questions sur les expériences précédentes, les projets sur lesquels vous avez travaillé et les personnes avec lesquelles vous avez collaboré. J’ai formulé des réponses à des questions relatives à mes expériences et je pense que cela a fait beaucoup de chemin.
    C’est aussi un bon moment pour poser vos propres questions sur l’entreprise et son fonctionnement. De vraies questions, faites vos recherches au préalable. Les questions génériques peuvent donner l’impression que vous n’êtes pas particulièrement intéressé à y travailler.
  6. Enfin, tu dois juste sortir et faire de ton mieux. Je déteste l’admettre (parce que cela ressemble à une dérobade) que la chance est un facteur assez important lors d’un entretien. Parfois, ce n’est tout simplement pas votre journée et ce n’est pas grave. Apprenez ce que vous pouvez de l’expérience et continuez d’avancer.
    Vous n’avez pas besoin d’avoir de la chance à chaque fois, vous avez juste besoin d’avoir de la chance une fois.

J’ai eu de la chance en août 2018 après un an d’échec, lors d’un entretien avec Facebook pour un poste d’ingénieur logiciel à temps plein.

“Être humble. Avoir faim. Et soyez toujours le travailleur le plus acharné de la pièce. – Dwayne Johnson

(Ma citation préférée, allez comprendre)

J’ai réussi des entretiens d’ingénieurs logiciels dans des entreprises de premier plan et je mène également des entretiens pour embaucher des ingénieurs logiciels de niveau senior/junior dans mon entreprise actuelle.

Voici quelques-uns des signaux d’alarme qui indiquent que le candidat ne réussira probablement pas.

  1. Le candidat émet des hypothèses : en tant qu’intervieweur, je donne généralement un problème ambigu pour sonder le candidat et lui poser des questions plus claires. Si le candidat passe directement à la résolution du problème, je le marquerai très probablement comme un drapeau rouge. La plupart des candidats sautent directement dans la solution pour se rendre compte que le problème est très différent

Continuer la lecture

J’ai réussi des entretiens d’ingénieurs logiciels dans des entreprises de premier plan et je mène également des entretiens pour embaucher des ingénieurs logiciels de niveau senior/junior dans mon entreprise actuelle.

Voici quelques-uns des signaux d’alarme qui indiquent que le candidat ne réussira probablement pas.

  1. Le candidat émet des hypothèses : en tant qu’intervieweur, je donne généralement un problème ambigu pour sonder le candidat et lui poser des questions plus claires. Si le candidat passe directement à la résolution du problème, je le marquerai très probablement comme un drapeau rouge. La plupart des candidats sautent directement dans la solution pour se rendre compte que le problème est très différent de ce qu’ils pensaient.
  2. Problème de désherbeur : je commence généralement l’entretien en posant au candidat une simple question de désherbeur, similaire à ce que les réponses précédentes à cette question ont mentionné. (Indice : généralement niveau moyen/facile de leetcode)
  3. Valeurs nulles/cas extrêmes : la plupart des candidats sont bien préparés pour les entretiens d’ingénierie logicielle. Cependant, chaque fois qu’ils rencontrent un problème qu’ils ont vu avant, ils se contentent de cracher la solution sur le tableau blanc. Il est très important que le candidat vérifie/clarifie avec l’intervieweur si une vérification nulle ou une entrée valide doit être testée.
  4. Complexités temps/espace : En tant que candidat, il est très important de savoir quelles sont les complexités temps/espace-temps d’exécution de la solution que vous essayez de proposer. Si un candidat ne peut pas proposer cela, je le marque comme un drapeau rouge. Les erreurs habituelles ici sont de ne pas savoir que Arrays.sort() prend un temps O(nlogn), de ne pas connaître les temps d’exécution des principaux algorithmes de tri/recherche.
  5. Code de mauvaise qualité : l’un des aspects les plus importants lors de l’évaluation d’un candidat est de vérifier s’il est capable d’écrire un code propre et maintenable. Bien que cela joue un moindre poids lors de l’évaluation d’un ingénieur junior/nouveau diplômé. Les erreurs les plus courantes commises par les candidats ici sont liées à l’encapsulation (publique/privée/protégée), à ​​l’utilisation de == pour comparer deux chaînes, etc.
  6. Mauvaise compréhension des systèmes (principalement pour les ingénieurs principaux) : la performance d’un candidat est très importante dans un cycle de conception de système. Le candidat doit être capable de bien expliquer la conception et les hypothèses à l’intervieweur et de gérer divers scénarios liés à l’évolutivité, la latence et la disponibilité. Les erreurs les plus courantes commises par les candidats sont incapables de justifier les avantages et les inconvénients de leur approche/technologie qu’ils utilisent dans leur conception, tirant des conclusions sur le système sans obtenir suffisamment de données de l’intervieweur.
  7. Compétences comportementales/de leadership médiocres : bien que la pondération varie d’une entreprise à l’autre. Il est essentiel que le candidat soit capable de répondre à des questions comportementales basées sur l’expérience de travail précédente avec des exemples appropriés (également appelés format STAR). Des entreprises comme Amazon accordent beaucoup d’importance à de telles rondes.

Sûrement pas. Si je devais recommencer le processus, voici ce que je ferais, au cours d’un mois :

Lisez d’un bout à l’autre de l’interview Cracking the Coding, en particulier chaque section concernant tout ce qui concerne les structures de données et les algorithmes. C’est-à-dire les graphiques, les arbres, la programmation dynamique, la récursivité, les piles, les files d’attente, les tableaux et les tables de hachage. Connaître tous les algorithmes de tri et de recherche courants tels que la recherche binaire, la recherche en largeur d’abord et la recherche en profondeur d’abord pour les graphiques et les arbres, le tri par compartiment, le tri par fusion et le tri rapide. Faites chaque problème sur ces sujets et assurez-vous de comprendre

Continuer la lecture

Sûrement pas. Si je devais recommencer le processus, voici ce que je ferais, au cours d’un mois :

Lisez d’un bout à l’autre de l’interview Cracking the Coding, en particulier chaque section concernant tout ce qui concerne les structures de données et les algorithmes. C’est-à-dire les graphiques, les arbres, la programmation dynamique, la récursivité, les piles, les files d’attente, les tableaux et les tables de hachage. Connaître tous les algorithmes de tri et de recherche courants tels que la recherche binaire, la recherche en largeur d’abord et la recherche en profondeur d’abord pour les graphiques et les arbres, le tri par compartiment, le tri par fusion et le tri rapide. Faites chaque problème sur ces sujets et assurez-vous de les comprendre. La vérité est que la plupart des problèmes d’entrevue sont généralement l’un des problèmes fondamentaux déguisés. Votre kilométrage peut varier, mais cela devrait être d’environ deux à quatre heures par jour.

De plus, je recommande fortement de comprendre chaque solution sur Interviewcake.com. J’ai trouvé que les problèmes couvraient une grande majorité de problèmes courants et j’ai trouvé cela incroyablement précieux. Ils ne sont pas gratuits mais je ne saurais trop les recommander.

Leetcode et Hackerrank sont d’excellentes sources de problèmes de pratique, mais ne vous attardez pas trop sur le fait que vous pourriez être en train de tâtonner certains d’entre eux, en particulier les problèmes les plus difficiles si vous êtes un ingénieur junior de niveau intermédiaire.

Aussi important qu’il soit de comprendre la composante informatique du processus d’entretien, il est tout aussi important de comprendre comment réaliser un entretien du point de vue des compétences non techniques. Si vous le pouvez, je vous recommande de trouver quelqu’un qui a déjà traversé le processus d’entretien afin qu’il puisse vous donner quelques problèmes sur un tableau blanc. Le processus de résolution des problèmes de tableau blanc peut être délicat si vous ne le connaissez pas. Assurez-vous également que vous communiquez TOUJOURS ce que vous faites à l’intervieweur. Il n’est pas rare qu’un intervieweur vous donne quelques conseils pour arriver à la solution du problème et il lui est difficile de savoir ce que vous pensez si vous ne communiquez pas ! Assurez-vous de poser également des questions et de bien comprendre le problème avant de commencer. Souvent, les intervieweurs laissent intentionnellement des questions ambiguës pour voir si vous demandez réellement plus d’informations (ce que vous devriez toujours faire). Une stratégie qui a très bien fonctionné pour moi consistait à répéter la question à l’intervieweur et à lui demander de confirmer que c’était ce qu’il voulait que je fasse.

Une bonne stratégie consiste également à passer des entretiens en continu dans d’autres entreprises, même si elles ne semblent pas être l’entreprise/le rôle de vos rêves. Vous gagnerez une expérience précieuse et qui sait, vous trouverez peut-être quelque chose qui vous plaira !

Cela peut sembler beaucoup, mais cela ne devrait en aucun cas vous prendre 1000 heures. La sur-préparation est une chose et vous finirez par oublier des choses au profit de nouvelles choses, ce qui vous mènera à un gain d’informations net zéro.

Bonne chance!

Voici une feuille de route de 2 mois sur la préparation de l’interview Google :

Semaine 1 :
Révisez les bases du langage de programmation que vous avez choisi. Des choses comme:

  • Comment lire/écrire depuis/vers des fichiers
  • Comment lire l’entrée de la console
  • Comment diviser des chaînes
  • La longueur de la chaîne est-elle une fonction ou une propriété (réponse : cela n’a pas d’importance, mais cela se reflète toujours mal sur vous)
  • Comment déclarer et utiliser des tableaux 2D
  • En C/C++, comment gérer les chaînes à zéro terminal

Il est maintenant temps de commencer à écrire du code (en particulier sur un tableau blanc) et de discuter de votre processus de réflexion.

Semaine 2 :
Revisiter les structures de données et les algorithmes

Revoyez des sujets comme :

  • Complexité

Continuer la lecture

Voici une feuille de route de 2 mois sur la préparation de l’interview Google :

Semaine 1 :
Révisez les bases du langage de programmation que vous avez choisi. Des choses comme:

  • Comment lire/écrire depuis/vers des fichiers
  • Comment lire l’entrée de la console
  • Comment diviser des chaînes
  • La longueur de la chaîne est-elle une fonction ou une propriété (réponse : cela n’a pas d’importance, mais cela se reflète toujours mal sur vous)
  • Comment déclarer et utiliser des tableaux 2D
  • En C/C++, comment gérer les chaînes à zéro terminal

Il est maintenant temps de commencer à écrire du code (en particulier sur un tableau blanc) et de discuter de votre processus de réflexion.

Semaine 2 :
Revisiter les structures de données et les algorithmes

Revoyez des sujets comme :

  • Analyse de complexité (alias BigO)
  • Tableaux
  • Piles
  • Files d’attente
  • Liste liée
  • Des arbres
  • Essais (Ce sont effectivement des arbres, mais il est toujours bon de les appeler séparément).
  • Graphiques (BFS et DFS)
  • Tables de hachage
  • Des tas
  • Tri
  • Recherche

Semaines 3 à 4 :
Entraînez-vous à des questions de codage simples et complexes.

Améliorez vos compétences en matière de tableaux avec des questions telles que :

  • Supprimer les entiers pairs du tableau
  • Fusionner deux tableaux triés
  • Premier entier non répétitif d’un tableau
  • Trouver la deuxième valeur maximale dans un tableau

Améliorez vos concepts de liste chaînée avec des questions telles que :

  • Trouver la longueur de la liste chaînée
  • Rechercher dans la liste à chaînage simple
  • Inverser une liste chaînée
  • Trouver la valeur moyenne de la liste chaînée

Améliorez vos compétences en pile/file d’attente avec des questions telles que :

  • Trier les valeurs dans la pile
  • Créer une pile où min () renvoie la valeur minimale dans O (1)
  • Implémenter deux piles en utilisant un seul tableau

Voici quelques problèmes plus complexes à considérer :

  • Implémenter la recherche binaire
  • Trouver le point d’intersection de deux listes chaînées
  • Inverser les mots dans une phrase
  • Vérifier si deux arbres binaires sont identiques
  • Cloner (copier en profondeur) un graphe orienté
  • Trouver des solutions à un jeu Boggle
  • Déterminez s’il existe trois nombres entiers dans un tableau dont la somme est égale à la valeur donnée.

Voici quelques directives à garder à l’esprit lorsque vous résolvez ces problèmes :

1. Il est maintenant temps de commencer à vous chronométrer. Idéalement, vous ne devriez pas passer plus de 20 à 30 minutes à résoudre un problème donné. (Ce ne sera probablement pas possible pour toutes les questions tout de suite.)

2. Ne vous découragez pas si vous n’êtes pas en mesure de résoudre un problème dans le temps imparti. Résolvez-le même si cela vous prend quelques heures, sans regarder la solution. Cela vous aidera à renforcer la confiance que vous pouvez résoudre, puis vous pourrez vous concentrer sur les résoudre plus rapidement plus tard.

3. Commencez à réfléchir à la complexité d’exécution et de mémoire de chaque solution. Vous devrez articuler clairement les complexités de l’entretien, il est donc préférable de commencer maintenant.

Semaines 5-6 :
Conception du système (généralement pour les niveaux supérieurs)

Dans le cadre de vos entretiens de conception de système, il vous est demandé de concevoir un service « à l’échelle du Web ». Les intervieweurs souhaitent évaluer votre capacité à décrire les différentes parties d’un service évolutif, telles que :

  • Comment les serveurs Web sont-ils équilibrés en charge ?
  • Comment les bases de données sont-elles partagées ?
  • Comment les fichiers volumineux sont-ils stockés ?
  • Comment le réseau est-il configuré pour la redondance et le débit maximal ?

Vous voudrez vous exercer à des questions telles que :

  • Concevoir Instagram
  • Concevoir le fil d’actualité Facebook
  • Conception Uber

Semaine 7 :
 OS et concurrence

Revoyez les concepts de système d’exploitation et de concurrence comme le multithreading, la sécurité des threads, etc.

Semaine 8 :
Conception orientée objet

Certaines questions courantes incluent :

  • Concevoir un guichet automatique
  • Concevoir un ascenseur
  • Concevoir un système de stationnement

Dans les questions de conception orientée objet, les intervieweurs recherchent votre compréhension des modèles de conception de logiciels et votre capacité à transformer les exigences en classes compréhensibles. Vous passez la plupart de votre temps à expliquer les différents composants, leurs interfaces et comment les différents composants interagissent les uns avec les autres à l’aide des interfaces.

Cela devrait vous donner une bonne idée de la façon de répartir votre temps. Je vous recommande fortement de consulter Coding Interview Preparation | CodingInterview.com pour plus de détails sur la façon de se préparer et à quoi ressemble l’interview Google, du premier contact à l’offre.

Vous n’avez pas besoin de connaître tous les algorithmes et les structures de données. Tout ce qu’ils attendent est assez rudimentaire, mais nécessite un peu de réflexion intelligente pour optimiser ou terminer les détails et les cas d’angle. J’ai fait plus de 60 entretiens pendant mon séjour chez Google. Lors des entretiens avec des candidats de niveau débutant qui sortent de l’université, il faut s’attendre à 4 types de questions. Avant cela, il y a une évaluation sur la vérification de ce que vous avez écrit dans votre CV. Certains intervieweurs, en particulier moi, s’attendent à ce que vous en sachiez plus sur votre projet de recherche que je ne me souviens 10 ans après avoir quitté l’université. Mais ce n’est pas grave

Continuer la lecture

You don’t have to know all of algorithms and data structures. All they expect is pretty rudimentary, but requires a bit of smart thinking to optimize or finish the details and corner cases. I have done over 60 interviews during my time in Google. When interviewing entry level candidates who are out college there are 4 type of questions to be expected. Before these there is some assessment on checking what you have written in your resume. Some interviewers especially me expect you to know more about your research project than I remember 10 years after I left college. But it doesn’t matter that much if interviewer is convinced you have worked in detail on those topics.

For freshers you may get more of (1) and (2).

  1. Algorithm and Data structures. Mostly a simple dynamic programming problem that can be optimized several times over. Like starting from O(n^4) all the way to O(n). Some problems just reduce to binary search if you know what to look for hence O(log(n)). Some people give bonus points if you can further reduce using matrix exponentiations. I prefer problems that have several solutions and varying levels. The problems are usually well graded because an interviewer repeats the problem quite often and knows what a good candidate is expected to know.You can score well if you done lot of exercises rather than learning lot of algorithms. Reduction to simpler algorithms is more important than knowing advanced algorithms.
  2. A problem involving coding. This is actual work, have to get details right. I usually just share my laptop for candidates to code. problem is usually a bit messy but nothing that requires too much thought process. Because objective here is just to check if you can get thoughts into action and not get lost in details.
  3. Design oriented. A rather large system is presented and asked to discuss what components would one choose and why. How each of them talk to each other etc. for a fresher we don’t expect much out of this round. The better you do, higher the chance of getting selected. As long as you don’t blunder at this stage (if you are a fresher) like not knowing what to talk you will be fine.
  4. Open ended discussion. Make sure you keep talking and expressing ideas on how to solve a hard problem. This is like how would you build a train ticket booking system. We like to know how much you know, how opinionated you are. What kind of strengths you bring to the team etc.

Apply 3 Ps – Patience, Practice, Perseverance.

Patience:

  1. It’s a slow process if you haven’t used Data Structures / Algorithms in a while. Before you start looking at any preparation resources, brush up on Data Structures and Algorithms. If you are rusty, interview problems would seem more difficult to you than they actually are – just because you would spend a lot of effort trying to recall basics data structures and algorithms.
    1. Mastering Data Structures: An interview refresher
    2. Algorithms and Complexity Analysis: An interview refresher
  2. C’est un processus lent et vous ne pourrez pas résoudre/pratiquer plus

Continuer la lecture

Appliquer 3 P – Patience, Pratique, Persévérance.

Patience:

  1. C’est un processus lent si vous n’avez pas utilisé de structures de données / algorithmes depuis un certain temps. Avant de commencer à regarder des ressources de préparation, rafraîchissez-vous sur les structures de données et les algorithmes. Si vous êtes rouillé, les problèmes d’entretien vous sembleront plus difficiles qu’ils ne le sont en réalité – simplement parce que vous consacreriez beaucoup d’efforts à essayer de vous rappeler les structures de données et les algorithmes de base.
    1. Maîtriser les structures de données : un rappel d’entretien
    2. Algorithmes et analyse de complexité : un rappel d’entretien
  2. C’est un processus lent et vous ne pourrez pas résoudre/pratiquer plus de quelques problèmes par jour. Cela le rend frustrant, donc la patience est la clé.
  3. Consider finding a guide to preparing for an interview and adapting it to your already busy schedule. Check out Coding Interview Preparation | CodingInterview.com to get a sense of what you’ll need to work on. It may take longer than suggested.

Practice:

  1. Once you are confident that you know the DS/Algo stuff, start looking at interview preparation resources. I’d recommend Grokking the Coding Interview: Patterns for Coding Questions.
  2. Use the visual explanations of the given problems to internalize the concepts and solutions. This way, when you are solving an unknown problem, you can still apply the same methodology and visualize the problem in your head.
  3. Instead of blindly start coding whatever problem you find first, learn in a more methodical manner e.g. solve Linked List problems first.

    It’s better to use resources that help you visually learn the concepts and work through the step by step solutions. By working through solutions in a methodical manner, each problem that you solve will enable to you solve many more problems and you’ll build confidence that you are getting better in a particular topic.

  4. In addition to coding problems, practice System Design problems by going through a resource like Grokking the System Design Interview. Almost all big tech companies now ask System Design questions so definitely spend time on this.

Perseverance:

  1. There is always a chance that you will fail at the interviews at first. If this happens, don’t beat yourself up. Try again.
  2. Most companies will let you re-interview after 6–12 months.
  3. Many programmers failed these programming interviews and still went onto to great things e.g. He Wanted A Job; Facebook Said ‘No’ — In A $3 Billion Mistake :).

For more information on how to prepare and what kind of interview questions are asked during tech interviews, look at my answer Fahim ul Haq’s answer to What is the best way to learn algorithms? I want to prepare for a Google interview and I am willing to spend all of my free time learning.

For Microsoft and Amazon – Cracking the Coding Interview

For Google – Elements of Programming Interviews (EPI)

I highly recommend reading both if you have the time. And don’t just read – work out the problems in detail.

Here’s my answer about how EPI helped me crack the Google interview:

Harsh Goel’s answer to Googlers who got the job after multiple attempts: how did you face rejection and what did you do differently next time to secure the job (SWE role)?

If I was in your shoes the first thing I would do is thoroughly research on both companies and look at their central ideas and projects they have delivered, whilst also looking at the job role duties and making sure you know all about this. Most likely the questions asked in the interview could be what previous experience did u have in this field of work and also what do u know about the company. So it’s best to revise the common interview job questions, which u can find if you type that into Google.

Most asked Question related to I am a 5 years experienced software engineer and aim to crack an interview for companies like Google, Facebook, LinkedIn, etc. How should I go about my preparation (resources, papers, etc.)? :

  • Can-the-government-make-voting-day-a-national-holiday?
  • What-jobs-pay-relatively-well-and-allow-you-to-work-from-anywhere-or-travel-internationally?
  • What-is-the-hardest-part-about-the-job-search?
  • As-a-babysitter-what-was-your-Okay-thats-the-last-time-I-babysit-for-this-family-moment-you-had-during-a-childcare-job?
  • What-can-be-done-to-create-jobs-for-the-future?
  • How-well-does-English-play-the-role-of-lingua-franca-in-Nigeria?
  • Is-it-worth-doing-an-MBA-an-MA-or-a-BA-in-political-science-in-India?
  • How-do-I-begin-my-career-as-a-freelance-writer?
  • What-are-railway-jobs?
  • How-much-does-it-cost-to-repaint-a-car-in-California?
  • What-is-it-like-to-switch-careers?
  • What-is-the-starting-salary-of-a-company-secretary-with-an-LLB-degree?
  • Which-is-highest-paid-job-without-much-stress-in-India?
  • I-keep-getting-rejected-after-final-round-interviews-Should-I-give-up?
  • Where-could-I-get-a-part-time-job-in-Bangalore?
  • What-are-fun-jobs-to-have-as-a-college-student?
  • I-am-doing-a-government-job-but-I-am-not-full-satisfied-so-what-should-I-do?
  • Can-you-share-a-picture-of-your-office-desk-after-being-selected-through-the-SSC-MTS?
  • What-are-the-best-careers-for-someone-with-a-very-high-IQ-but-low-emotional-intelligence?
  • Can-I-still-get-a-visa-without-a-degree-for-the-USA?
  • Are-Indian-CA-recognized-in-Canada?
  • What-is-the-easiest-and-legit-way-to-make-money-without-working-a-9-5?
  • What-are-some-red-flags-or-signs-that-you-shouldnt-accept-a-job-offer?
  • How-do-you-find-a-job-with-Fox-Traveller-Discovery-or-TLC?
  • What-is-the-maximum-and-minimum-salary-one-can-get-in-BPO-sector-as-a-fresher-in-Chennai?
  • What-are-the-working-hours-for-the-SSC-MTS-and-what-type-of-job-do-they-do?
  • What-are-the-best-opportunities-after-doing-a-CA?
  • If-you-think-that-sex-work-is-just-a-job-do-you-agree-that-killing-people-for-money-is-just-a-job-too-ethically-speaking?
  • What-is-the-best-way-to-find-a-job-immediately?
  • What-is-a-landing-page-and-how-would-I-use-it?