Préparation aux entrevues
Duplicata possible:
Comment vous préparer à la programmation des questions d'entrevue?
Quelqu'un pourrait-il me donner des conseils sur la façon de préparer un entretien technique? En tant que diplômé CS, je suppose que l'on doit approfondir les sujets suivants:
Structures de données: Tableau, liste liée, pile, files d'attente, tas, table de hachage, arbre binaire, arbre de recherche binaire, arbre binaire à équilibrage automatique (AVL, rouge Arbre noir), B-Tree, Tries/Suffix Tree
Algorithmes: Tri (tri à bulles, tri par insertion, tri par sélection, tri par coques, tri rapide, tri par fusion, tri externe), recherche (temps linéaire et logarithmique recherche), théorie des graphes (liste d'adjacence, matrice adjacente, DFS, BFS, tri topologique), programmation dynamique, algorithmes gourmands, diviser et conquérir.
Algorithmes ad hoc: Sélectionnez l'algorithme, la carte Fisher Yates Shuffle, l'échantillonnage du réservoir et la liste est infinie.
Bases de données: Requêtes SQL
Programmation et conception: C, C++, Java, langages de script (Perl, Python), (bases OOPS, fonctions virtuelles, copie profonde et superficielle, constructeur de copie , opérateur d'affectation, STL, gestion de la mémoire, pointeurs/référence, interface, classes abstraites
Systèmes d'exploitation: Synchronisation des threads (Mutex, variables conditionnelles, sémaphores, blocages), gestion de la mémoire (segmentation, pagination, TLB, mécanismes de mise en cache)
Il serait également formidable que nous puissions tous compiler les ressources disponibles sur Internet pour approfondir ces sujets. J'ajouterai certains d'entre eux:
Liste liée et arbres: http://cslibrary.stanford.edu/103/
S'il vous plaît, aidez-moi à trouver des ressources utiles pour préparer ces sujets, j'apprécierais également si vous pouviez ajouter à ces sujets.
Cela dépend vraiment du type d'emploi que vous postulez. J'ai vécu quelques interviews et j'en ai mené encore plus. Voici quelques conseils.
- Tout ce que vous avez listé tombe dans la catégorie "anecdotes techniques". Il est important de savoir - cela aide à établir que vous avez une bonne profondeur et une vaste étendue de connaissances techniques. La réalité est qu'il est souvent très difficile d'étudier - soit vous le savez, soit vous ne le savez pas. Pas si dire que se rafraîchir les choses est une mauvaise idée.
- Résolution de problèmes et pensée critique est également très important. Des questions comme "combien de trous d'homme à Manhattan" sont courantes - ils ne recherchent pas une bonne réponse, ils veulent voir comment vous résolvez les problèmes. Expliquez votre processus - si vous découvrez que vous avez fait une erreur, expliquez pourquoi et comment vous pouvez l'améliorer. Ne jetez pas vos mains en l'air et abandonnez. Soyez tenace et disposé à être créatif - pour la question du trou d'homme, vous pouvez suggérer d'interviewer des chauffeurs de taxi.
- Soyez prêt à défendre vos points. Je ne dis pas pour être argumentatif, mais si on vous demande quelle technologie ou méthodologie vous utiliseriez dans une situation particulière, soyez prêt à défendre ce point. S'ils vous demandent si vous souhaitez créer une application Web ou une application cliente pour résoudre un problème spécifique (tout le monde dit toujours qu'ils demanderaient au client, mais ce n'est généralement pas suffisant), soyez prêt à dire pourquoi vous choisissez cette technologie. Habituellement, "c'est tout ce que je sais" n'est pas la bonne réponse. Les raisons du choix sont plus intéressants que le choix. Nous avons interviewé un gars une fois (que nous avons embauché) et lui avons demandé s'il choisirait des solutions Web ou clientes pour différents problèmes, il a dit Web et expliqué pourquoi, mais a ensuite dit à moins que ce ne soit pour l'Afrique (il a immigré de là) parce que leur L'infrastructure Internet était terrible!
- Ne pas BS - si vous ne connaissez pas la réponse, soyez franc - mais expliquez ensuite comment vous tenteriez de trouver la réponse, ou ce que vous feriez en fonction de ce que vous savez. J'ai posé des questions pour lesquelles je sais qu'il n'y a pas de réponse réelle avant juste pour prouver que quelqu'un me bousculait.
- Etudiez l'entreprise vous interviewez. Vous pouvez en apprendre beaucoup sur eux à partir de la liste des emplois et d'autres listes qu'ils ont. Assurez-vous de rechercher toutes les technologies dans votre offre d'emploi et de connaître les autres technologies utilisées dans l'entreprise (sur la base d'autres listes). Cela m'a déjà permis de travailler.
- Prévoyez questions réfléchies. Particulièrement inspiré par vos recherches sur l'entreprise et ses technologies.
- Créez un portfolio d'échantillons de code, conceptions d'interface utilisateur, articles de blog, articles, brevets, projets open source, réponses Stack Overflow, problèmes intéressants que vous avez résolus (même s'ils sont expliqués sur papier), etc. peut pointer pour montrer certaines de vos compétences, expériences, etc. Assurez-vous que vous avez des droits sur tout ce que vous partagez. Un jour, un candidat m'a envoyé par e-mail les informations de connexion à une application qu'il avait conçue pour un ancien employé. Les choses que vous avez faites pendant votre temps libre (ou à l'école) sont essentielles - en plus, cela montre votre passion.
J'espère que cela pourra aider. Bonne chance!
Ce livre m'a été très utile dans le passé. Surtout quand je sortais de l'école.
EDIT: Il s'appelle "Programmation des entrevues exposées: les secrets pour décrocher votre prochain emploi, 2e édition (programmeur à programmeur)"
Il est bon de connaître autant d'éléments de votre liste que possible, mais lorsque j'aide à l'entrevue, nous passons rapidement en revue si vous connaissez les éléments. Nous sommes intéressés, et plus vous en savez, mieux c'est, mais c'est encore mieux si vous en savez assez pour répondre à la raison pour laquelle vous choisiriez une structure de données plutôt qu'une autre dans un problème donné, ou à quelle heure vous utiliseriez des sémaphores plutôt que des mutex, etc.
En plus de cela, les personnes qui apportent des échantillons de travaux antérieurs sont très appréciées. Si vous faites cela, assurez-vous de bien le savoir; c'est-à-dire, n'apportez pas quelque chose que vous avez fait en "équipe", où la majorité du code a été écrit par quelqu'un d'autre, à moins que vous ne le compreniez vraiment. Soyez prêt à expliquer pourquoi vous avez choisi les algorithmes que vous avez choisis, sous quelles contraintes vous travailliez et des choses comme ça.
La plupart de ce que vous avez énuméré n'apparaîtra pas directement dans une interview; on supposera que vous en connaissez la plupart en fonction de vos antécédents. Ce que vous devrez montrer, ce sont les compétences, plutôt que les connaissances, qui font le travail. Des choses comme:
- Solides compétences en communication, écrite et verbale. L'ensemble du processus de candidature et d'entrevue, y compris votre CV et votre lettre de motivation, sont vos opportunités de le montrer.
- Apprentissage rapide et bonnes compétences en recherche: la capacité d'admettre ce que vous ne savez pas et de ne pas vous en empêcher. Soyez prêt à dire "je ne sais pas" et suffisamment confiant pour ajouter "encore". On vous posera peut-être une ou deux questions que personne ne connaît du haut de leur tête; c'est pour prouver que vous ne vous fâchez pas ou que vous n'inventez rien, que vous pouvez tranquillement et rapidement aller chercher ce que vous devez savoir.
- Pensée analytique: il peut vous être présenté différentes sortes d'énigmes pour prouver que vous pouvez résoudre votre problème et trouver une solution; ce qui importera le plus, c'est votre processus, pas votre réponse finale. Souvent, la personne qui demande ne sait pas (ou ne se soucie pas) si votre réponse finale est écrite ou fausse. Ils veulent voir comment vous y arrivez.
- Démonstration technique: c'est vrai, la partie amusante. Une bonne entreprise vous présentera une tâche de programmation à effectuer et examinera votre solution. Il n'y a pas de préparation à cela autre que l'expérience, bien que les problèmes soient généralement relativement simples. Ils veulent juste la preuve que vos antécédents contribuent à une véritable capacité de mise en œuvre.
Aucune de ces choses ne peut vraiment être "étudiée", seulement pratiquée. Plus il y a de pratique, mieux c'est, mais rappelez-vous toujours que ce n'est pas "la pratique rend parfait", mais "la pratique parfaite rend parfait". Entrainez-vous toujours à bien le faire, pas seulement à le faire du tout.
Bonne chance!!