Article original : How to prepare for a technical interview - tips and tricks to help you perform your best

Par John Mosesman

Ah, l'entretien de codage.

"Redoutez-le. Fuyez-le. Le destin arrive quand même." - Thanos 2018

D'accord, peut-être que c'est un peu dramatique, mais je ne connais personne qui soit ravi de passer par le processus d'entretien. La recherche d'emploi/le processus d'entretien est épuisant au mieux et bien d'autres choses au pire.

Beaucoup de gens étudient des trucs et des tactiques pour un entretien (et je vous en donnerai aussi quelques-uns), mais la plupart des gens ne pensent pas à leur état d'esprit en entrant dans l'entretien.

Votre état d'esprit donne le ton de la façon dont vous allez voir et façonner votre situation. Entrez avec le bon état d'esprit et vous serez en mesure de comprendre et de naviguer dans tout ce qui vous est lancé. Entrez avec un esprit dispersé ou timide et vous vous retrouverez ballotté et battu.

Vous êtes aussi l'interviewer

Une chose que la plupart des gens oublient souvent, c'est que vous êtes aussi l'interviewer.

Oui, vous êtes interviewé dans cette entreprise, mais vous interviewez aussi l'entreprise pour voir si elle est un bon choix pour vous.

Quelles sont les valeurs de cette entreprise ? À quoi ressemble leur éthique de travail ? Que valorisent les gens ?

Réussir l'entretien est important, mais voulez-vous travailler dans cette entreprise si vous réussissez ?

Parfois, nous avons juste besoin d'un emploi—n'importe quel emploi—et donc je ne veux pas minimiser le fait de simplement obtenir l'emploi. Mais si vous le pouvez, prenez du recul et réfléchissez à la manière dont cet emploi affectera votre carrière à long terme. Dire oui à un emploi, c'est dire non à une douzaine d'autres—vous payez un coût d'opportunité élevé en disant oui.

Donc, voici la première chose à retenir : ce n'est pas une dynamique de pouvoir à sens unique. Cela peut sembler le cas parfois, mais vous avez un certain contrôle ici, et vous avez des options. C'est puissant.

Types d'entretiens

D'accord, alors nous évaluons aussi l'entreprise en fonction des personnes avec lesquelles nous interagissons dans le processus d'entretien, alors que faisons-nous avec ces informations ?

Eh bien, il existe quelques types différents d'entretiens techniques. Ces types d'entretiens nous en disent beaucoup sur l'état d'esprit de l'entreprise et sur ce que c'est que de travailler là-bas. Je décompose les différents types comme suit :

  • Tableau blanc
  • Défi de code (questions de science informatique ou algorithmes)
  • Défi de code (problème de codage raisonnable)
  • Projet à faire à la maison

Le redouté tableau blanc

Certains des premiers exercices d'entretien que l'industrie technologique a adoptés étaient les exercices de tableau blanc. On vous donnait une tâche et on vous demandait d'écrire le code sur le tableau blanc. Généralement, cette approche est mal vue et est en train de disparaître dans l'industrie technologique aujourd'hui, mais il y a encore de nombreuses entreprises qui utilisent cette pratique.

Ce n'est pas que coder sur un tableau blanc soit mauvais en soi—mais qu'un tableau blanc est si éloigné du travail que nous faisons réellement en tant que programmeurs qui travaillent sur des ordinateurs tous les jours. Le tableau blanc est maladroit à écrire, à éditer, et il ne vous donne aucun retour—il n'y a pas de complétion automatique, pas de coloration syntaxique, et vous ne pouvez pas sauter sur Google pour chercher les références de la bibliothèque standard.

En plus de cela, de nombreux endroits qui utilisent l'entretien sur tableau blanc posent également un certain ensemble de questions d'entretien qui, franchement, sont sans valeur pour 99 % des emplois de programmation qui existent. Ce sont les redoutés algorithmes de science informatique : inverser un arbre binaire, trouver le chemin le plus court dans un graphe, etc.

Le problème avec ces questions est qu'elles ne se posent tout simplement pas dans la vie réelle en tant que programmeur. Si vous passez un entretien chez Amazon ou Facebook, peut-être qu'elles ont une certaine valeur là-bas, mais la majorité des gens ne seront jamais confrontés à ce problème dans leur carrière. Et s'ils le sont, ils utiliseront simplement un package ou une bibliothèque qui a déjà implémenté cette fonctionnalité.

Alors, que pouvons-nous faire à propos des tableaux blancs ? Eh bien, voici ce que je ferais : faites de votre mieux, utilisez les conseils et astuces décrits ci-dessous, et évaluez sérieusement si cette pratique d'entretien est le symptôme d'un problème de mentalité plus large au sein de l'entreprise.

Défis de code

Si vous avez la chance d'éviter le tableau blanc, la plupart des endroits vous demanderont (et devraient probablement) de faire un type de défi de code. Encore une fois, cela peut sembler être une dynamique de pouvoir à sens unique, mais ce défi de code est en fait bon pour vous. C'est là que vous pouvez briller et montrer votre compétence technique, et selon mon expérience, cela affecte considérablement votre pouvoir de négociation en matière de rang et de salaire.

Avant de nous lancer dans les conseils spécifiques, nous devons également être conscients que le fait d'avoir évité le tableau blanc ne signifie pas que vous n'aurez pas encore la question de l'algorithme de science informatique ici—juste sur un ordinateur. Si c'est le cas, prenez une profonde inspiration et utilisez les conseils et astuces ci-dessous. Vous allez y arriver.

Si vous avez la chance d'éviter le tableau blanc et la question de science informatique, vous avez probablement été présenté avec un défi de codage raisonnable. Pour moi, ce sont des questions comme :

Écrivez une fonction qui prend un nombre de centimes (USD) sous forme d'entier inférieur ou égal à 100, et imprime le nombre minimal de pièces nécessaires pour le représenter.
50 => 2 quarters
11 => 1 dime et 1 penny
7 => 1 nickel et 2 pennies

J'ai également reçu des questions qui semblent être des questions de science informatique mais qui ne sont pas si mauvaises. Par exemple, "implémenter une liste doublement chaînée." À première vue, cela semble être un problème de science informatique en raison de la partie "liste doublement chaînée", mais ce que l'interviewer voulait vraiment, c'était du code qui implémentait le même comportement qu'une liste doublement chaînée—je n'utilisais pas de pointeurs et je n'adressais pas d'objets en mémoire—juste en imitant le même comportement. Dans ce cas, cela s'est avéré être un défi assez simple.

Et cela m'amène à mon premier conseil :

Conseil #1 : Posez des questions de clarification

Dans le défi de la liste doublement chaînée, on m'a donné un fichier Ruby vide (je passais un entretien pour un poste Ruby), et une suite de tests vide. Quelque chose comme ceci :

class DoublyLinkedList
end

(Si vous n'êtes pas familier avec Ruby—ne vous inquiétez pas. Le code ici sera simple à comprendre. Il est juste là pour illustrer les points généraux.)

Donc, une liste doublement chaînée, hein ? Peut-être que vous savez ce que c'est, ou peut-être que non. Si vous ne savez pas : posez des questions. C'est le premier piège à éviter. Si vous ne comprenez pas le problème ou ce qu'ils demandent, continuez à poser des questions jusqu'à ce que vous compreniez.

J'ai vu des candidats à un entretien s'engager dans la mauvaise voie et l'interviewer les laisser faire—tout en les faisant échouer silencieusement. Bien que je ne sois pas d'accord avec cette pratique, assurez-vous que vous travaillez sur le bon problème.

Je viens d'un milieu de science informatique, donc je savais qu'une liste doublement chaînée signifie une liste qui a un pointeur vers un nœud head et un nœud tail—où chaque nœud pointe également vers son nœud next et previous.

Maintenant, même si je savais cela, qu'ai-je fait ? J'ai dit cela à voix haute et j'ai demandé si c'était correct. Même si je pensais savoir quoi faire, j'en ai été absolument sûr.

Une fois que vous pensez comprendre le problème, reformulez votre compréhension à l'interviewer afin qu'il puisse vous corriger ou vous guider.

La chose suivante que j'ai faite a été de poser une autre question : "Puis-je utiliser un tableau pour les nœuds ?" Et j'ai tapé quelque chose comme ceci :

class DoublyLinkedList
  def initialize
    @nodes = []
  end
end

(Si vous n'êtes pas familier avec Ruby, ce n'est qu'un initialiseur ou constructeur où je crée une nouvelle variable appelée @nodes définie sur un tableau vide.)

Mais, l'interviewer m'a dit, non, je ne pouvais pas faire cela—ce qui est logique. Si j'avais utilisé un tableau, cela aurait vaincu tout le but de l'exercice qui est de construire les "pointeurs" fictifs entre les nœuds.

Et je suis content d'avoir demandé. Je ne voulais pas prendre le risque que l'interviewer me laisse utiliser le tableau, et puis m'échoue.

Donc, pas de tableau—eh bien, que fais-je maintenant ? Voici le conseil #2 :

Conseil #2 : Codé en dur -> Bête -> Meilleur

Lorsque vous êtes confronté à un défi de codage, travaillez le problème dans l'ordre suivant : codé en dur -> bête -> meilleur -> encore meilleur (si le temps le permet).

Selon mon expérience d'interviewé et d'interviewer d'autres développeurs, je trouve que la plupart des gens essaient de faire trop d'un coup.

Lorsque vous faites trop d'un coup, il est facile de faire des erreurs (que vous ne remarquerez pas à cause du InterviewBrain™). Alors commencez simplement—le plus simplement possible en fait—codé en dur—et travaillez votre chemin vers le haut.

Donc, j'ai une classe Ruby vide, comment puis-je coder en dur quelque chose pour progresser ? J'ai regardé ma suite de tests vide et j'ai vu qu'il y avait une fonction appelée head qui retournait le premier nœud de la liste, alors essayons cela :

class DoublyLinkedList
  def head
    'A'
  end
end

J'ai créé une fonction head, et j'ai codé en dur la lettre majuscule "A" en tant que chaîne, et j'ai exécuté ce test. Il a réussi.

Est-ce super simple ? Est-ce trop évident ? Oui ! Mais ce code fait deux choses très importantes :

  • Il me permet d'exécuter les tests et de tester que ma configuration fonctionne (éliminant toute erreur stupide ou de syntaxe)
  • Il me donne une victoire rapide—ce qui booste ma confiance

Il y a d'innombrables entretiens que j'ai vus où quelqu'un fait une petite erreur dès le début, se trouble, et passe ensuite la majorité de l'entretien à essayer de se rattraper et de corriger ce qui ne va pas.

Ne sous-estimez pas la valeur des victoires rapides pour votre confiance. Accumuler de petites victoires vous propulsera à travers l'entretien.

D'accord, nous avons une chaîne codée en dur 'A'. Maintenant, comment faire pour en faire une solution "bête" ? Eh bien, comment faire pour transformer cette lettre "A" en un hash (ou map) ?

class DoublyLinkedList
  def head
    { value: 'A' }
  end
end

C'est un peu mieux. Maintenant, au lieu d'une chaîne de caractères d'un seul caractère, notre "nœud" est représenté comme un hash avec une propriété value. Nous sommes passés de codé en dur à bête. Maintenant, comment pouvons-nous le rendre meilleur ? Eh bien, comment introduire notre pointeur head dans la liste ?

class DoublyLinkedList
  def initialize
    @head = { value: 'A' }
  end

  def head
    @head
  end
end

Qu'avons-nous changé ici ? Ici, nous avons ajouté notre initialiseur et créé une nouvelle variable appelée @head, et nous utilisons cette nouvelle variable dans notre fonction head. Cela commence à ressembler à du vrai code.

Maintenant, cette approche peut sembler vraiment stupide, mais je vous promets, ça marche. Chacun de ces changements est fait en quelques secondes de codage itératif, et ils s'accumulent pour produire une implémentation fonctionnelle en peu de temps.

Si vous pensez que cette approche semblera étrange à un potentiel interviewé, voici le prochain conseil, et celui-ci est très important :

Conseil #3 : Parlez. À voix haute.

Pendant tout le temps où vous faites un défi de codage, vous devriez parler—à voix haute.

Dites tout ce que vous pensez—tout.

(Enfin, tout ce qui est lié à la programmation.)

Voici le truc : arriver à une solution correcte est important oui, mais tout aussi important, si ce n'est plus, est de montrer votre processus de pensée. L'interviewer veut savoir comment vous pensez—comment vous résolvez les problèmes. Vous pouvez faire cela en partageant tout ce que vous pensez à voix haute.

Chaque interviewé a déjà été un candidat—ils savent ce qu'est le InterviewBrain™ et que même des choses simples peuvent devenir difficiles lors d'un entretien. Les bons interviewers ne se soucient pas que vous obteniez la solution à 100 % correcte—ils veulent juste savoir que vous possédez de bonnes capacités de pensée critique. La seule façon de rendre ces pensées internes visibles est de les dire à voix haute.

Si vous ne l'avez jamais fait auparavant, vous voudrez peut-être vous entraîner car c'est vital pour réussir l'entretien.

Pour vous donner quelques exemples pratiques, voici quelques choses que je dis à chaque fois que je suis interviewé :

"D'accord, codons simplement cette valeur en dur et assurons-nous que notre configuration fonctionne."

"Faisons une version bête de cela fonctionner d'abord et améliorons-la."

"Je vais le faire comme ça pour l'instant, et si nous avons le temps, nous reviendrons et ferons ."

"D'accord, donc nous avons besoin d'une fonction qui prend un tableau, fait X, et retourne ."

Dans certains scénarios, ces entretiens peuvent commencer à ressembler à des sessions de programmation en binôme.

D'accord, donc nous disons des choses à voix haute. Mais parfois nous faisons une erreur ou nous sommes bloqués. Nous avons exprimé notre processus de pensée à voix haute, mais maintenant nous devons peut-être changer et enquêter sur un problème ou une erreur potentiel.

Voici un conseil important pour cela :

Conseil #4 : Restez dans un flux logique

Maintenant, je l'admets : cela peut être difficile parfois.

Si vous êtes dans un entretien et qu'il y a un problème ou une erreur avec votre code, votre cerveau veut désespérément comprendre ce qui ne va pas—mais ne soyez pas trop désespéré au point de commencer à malmener votre code ou votre processus de pensée.

Vous voyez, tout comme l'interviewer veut voir comment vous décomposez un problème, il veut aussi voir comment vous déboguez un problème. Cela est tout aussi important que d'expliquer votre processus de pensée. Essayez de rester dans un flux logique et évitez de malmener le code ou vos idées.

Si tout se passe bien

Donc, le défi se passe bien, et vous résolvez le problème et toutes les choses faciles.

Que faire maintenant ? Comment passer de réussi à écrasé ?

C'est une partie extrêmement importante de l'entretien, car c'est là que vous obtenez la majorité de votre levier pour la négociation du niveau de poste et de la rémunération. Et le conseil est :

Conseil #5 : Montrez ce que vous savez

Vous travaillez sur le défi, vous parlez à voix haute, et vous vous en sortez bien. La prochaine chose que vous devez rechercher, ce sont des opportunités pour montrer vos connaissances et votre expertise.

Est-ce l'endroit dans le code où vous pourriez envoyer un email ? Mentionnez qu'il devrait être fait dans un worker en arrière-plan à la place (vous n'aurez probablement même pas à l'implémenter).

Travailliez-vous sur la logique de validation dans un modèle ? Parlez de la façon dont vous ajouteriez également des contraintes de base de données pour assurer l'intégrité des données. Quels index ajouteriez-vous ? Comment déploieriez-vous les migrations pour éviter les temps d'arrêt ?

Une fois que vous avez votre solution codée en dur -> bête -> meilleure, parlez de la façon dont vous la refactoriseriez si vous aviez plus de temps. Créeriez-vous un module pour cela ? Et un objet de service ? Et si vous mettiez une partie de cette logique dans un job en arrière-plan ? Discutez des compromis.

Maintenant, pourquoi est-ce si important ?

La plupart des questions d'entretien visent le dénominateur commun le plus bas—c'est-à-dire les exigences de base du poste. Le défi ou les questions eux-mêmes ne sont généralement pas conçus pour tester le haut de gamme des compétences de quelqu'un. L'entretien ne va probablement pas extraire l'information de vous, donc c'est à vous de fournir cette information.

Alors, pendant que vous parlez de votre processus de pensée, mentionnez toutes les choses que vous incorporeriez dans une application ou une base de code réelle et discutez-en.

Sac de trucs et astuces supplémentaires

Donc, c'est ainsi que vous devriez aborder votre entretien et relever le défi qui vous est donné.

Voici quelques trucs supplémentaires qui peuvent parfois être utilisés pour de légers avantages.

Astuce #1 : Connaître les problèmes courants

Il y a quelques problèmes courants qui apparaissent souvent lors des entretiens (surtout sur les tableaux blancs). Vous devriez être familier avec ces problèmes car ils sont un peu comme des questions que vous savez être sur le test.

Deux des principaux sont FizzBuzz et la résolution de la suite de Fibonacci (assurez-vous de connaître ceux-ci).

Maintenant, un mot d'avertissement : vous ne voulez jamais poser une solution mémorisée lors d'un entretien. Cela ne peut que mal se passer (et j'en ai été témoin). Vous voulez cependant être familier avec la solution—et être capable de la recréer à partir de zéro.

Donc, utilisez vos livres de préparation aux questions d'entretien, oui, mais assurez-vous de comprendre la solution, de pouvoir l'expliquer et de la recréer à partir de zéro. Une réponse mémorisée ne vous mènera nulle part ici.

Astuce #2 : C'est généralement acceptable de regarder la documentation

Dans tous les entretiens auxquels j'ai participé ou fait partie, personne ne s'est soucé si je regardais la documentation de la bibliothèque standard ou des packages. Les interviewers ne sont pas d'accord pour que vous cherchiez la réponse (donc j'éviterais StackOverflow), mais consulter les références est généralement permis. En cas de doute, voir le Conseil #1 et demander des clarifications.

Astuce #3 : Surveillez les indices visuels

C'est probablement mon conseil/astuce préféré. Ce n'est pas le plus utile, mais c'est un peu amusant. Lors de l'un de mes entretiens que j'ai fait à distance, nous utilisions un programme de partage d'écran et je pouvais voir le visage de l'interviewer dans le coin supérieur droit de mon écran.

J'ai remarqué du coin de l'œil en codant que l'interviewer hochait la tête. Ah ha ! Un petit indice visuel pour savoir que j'étais sur la bonne voie.

Encore une fois, ce n'est pas grand-chose, mais cela pourrait être utile. :)

Astuce #4 : Si à distance, avoir une bonne configuration

En parlant d'être à distance, si vous êtes à distance, essayez d'avoir la meilleure configuration possible. Cela signifie caméra allumée (si possible, configuration où vous regardez droit dedans), bonne connexion internet, ordinateur branché sur secteur, une pièce calme, un verre d'eau à proximité, etc.

Ces choses ne devraient pas affecter le résultat de votre entretien, mais il n'y a pas besoin d'énerver l'interviewer ou de vous donner du stress supplémentaire à cause de problèmes d'internet ou de bruit.

Astuce #5 : Soyez sociable !

Mon dernier conseil pour vous est d'être sociable.

Lors de votre entretien, soyez quelqu'un avec qui vous aimeriez travailler. Montrez-leur votre meilleur côté.

Les entretiens peuvent être intimidants, et les développeurs sont généralement des personnes plus calmes et réservées, mais vous devez montrer aux personnes avec lesquelles vous interagissez, "Hey, je suis une personne amusante et agréable avec qui travailler."

Je ne vous demande pas d'être quelqu'un que vous n'êtes pas. Mais vous ne voulez pas être, selon l'un de mes proches amis qui interviewe des gens tout le temps, une "créature marine".

Astuce bonus #6 : Faites toute l'autre préparation à l'entretien (si vous le souhaitez)

Si vous vous sentez sous-préparé, ou si c'est votre premier entretien technique, faites un travail de préparation jusqu'à ce que vous vous sentiez à l'aise.

Lisez des livres comme Cracking the Coding Interview ou pratiquez des algorithmes et des énigmes sur HackerRank.

Lisez les autres excellents articles sur Developer News sur les entretiens.

Si vous passez un entretien pour un rôle full-stack, soyez prêt à configurer un nouveau projet ou un fichier de test avec une suite de tests à partir de zéro.

Recherchez l'entreprise, soyez prêt avec de grandes questions sur l'entreprise ou le travail quotidien, etc., etc.

En fin de compte : ce n'est qu'un entretien.

En fin de compte, c'est ce que c'est.

Vous allez performer comme vous performez.

Vous allez être interviewé par la personne qui va vous interviewer.

Leur processus d'entretien sera leur processus d'entretien.

Peut-être que vous avez eu une mauvaise journée—peut-être que l'interviewer a eu une mauvaise journée.

Ensuite, si vous vous sentez embarrassé, vaincu, ou autre chose—prenez une profonde inspiration et laissez tomber ! Ne laissez pas votre Cerveau Reptilien vous alourdir. Un mauvais entretien n'est pas la fin du monde. Votre carrière n'est pas ruinée, votre réputation n'est pas ruinée, et votre vie n'est pas ruinée.

Ce n'est qu'un entretien. Apprenez-en, adaptez-vous, et soyez meilleur la prochaine fois.

C'est normal d'être nerveux

La plupart des gens (moi y compris) deviennent nerveux avant des choses comme les entretiens, les discours ou les présentations.

Je pensais autrefois que la nervosité était une mauvaise chose—une chose que je ne voulais pas. Et peu importe combien de fois je me disais "ne sois pas nerveux"—devinez quoi : cela me rendait encore plus nerveux !

J'ai appris à repenser la façon dont je vois la nervosité. La nervosité est la préparation de mon corps pour un combat—cette réponse primitive de combat ou de fuite.

Mais comme nous l'avons dit avant : ce n'est qu'un entretien. Il n'y a pas de tigre qui se faufile sur moi dans la salle d'entretien. Cette réponse primitive n'est pas nécessaire.

J'ai commencé à me rééduquer pour voir la nervosité comme une bonne chose. Cela signifie que mon corps et mes sens s'aiguisent pour que je puisse livrer la meilleure performance possible.

Alors, embrassez la nervosité. Elle vous prépare simplement à donner le meilleur de vous-même.

L'entretien est une compétence

En fin de compte, l'entretien est une compétence. Cela prend un peu d'étude et beaucoup de pratique pour la maîtriser.

Alors, ne vous en voulez pas si vous ne performez pas comme vous l'auriez espéré. Continuez à apprendre, et continuez à pratiquer—vous y arriverez !

Si vous avez des questions ou des commentaires, n'hésitez pas à me contacter sur Twitter, et si vous voulez plus d'informations sur la façon de vous préparer à une carrière de développeur, j'écris des choses comme ça sur mon blog.

Merci d'avoir lu !

John