1. Évaluez les talents dont l'entreprise et l'équipe ont besoin

Le recrutement nécessite une compréhension claire de l'intention initiale, une stratégie claire pour examiner les candidats ingénieurs logiciels et un plan clair en tête pour « gagner d'abord, puis se battre ».

De quels types de talents techniques l’entreprise et l’équipe ont-elles besoin ? C'est le point d'interrogation le plus fondamental lorsque nous établissons l'ensemble du système d'évaluation des entretiens.

(1) Idées communes :

1. Ceux qui peuvent travailler et faire des heures supplémentaires

Cette intention initiale est compréhensible, mais elle est très difficile à mettre en œuvre. C'est peut-être vrai dans certains secteurs, mais dans le monde du génie logiciel, c'est exactement le contraire.

Les personnes qui partagent ce point de vue divisent le comportement complexe du génie logiciel en utilisant une simple division du travail. Dans l’histoire, ce n’est pas que personne n’ait essayé cette approche, mais la plupart des tentatives ont échoué, ou les coûts des autres liaisons sont finalement devenus si élevés qu’on en perd le sens.

Par exemple, nous pouvons simplement diviser le processus de génie logiciel en plusieurs étapes : exigences, conception, mise en œuvre, tests et maintenance. Lorsque nous réduisons les besoins en personnel dans le maillon « mise en œuvre » et réduisons en conséquence les exigences de qualité, nous devrons alors investir davantage de main-d'œuvre dans d'autres maillons pour équilibrer le tout. En fin de compte, le coût de R&D n'a pas été considérablement amélioré, mais a été Le processus de mise en œuvre recèle des dangers cachés, tels qu'une mauvaise conception du code qui crée des pièges pour la maintenance et l'expansion futures.

Un tel équilibre peut consister à consacrer plus de temps à la réalisation de documents de conception plus détaillés, à ajouter davantage de personnel de test et à effectuer des tests plus complets, à consacrer plus de temps à l'exécution de versions d'essai et à des corrections de bogues, ou à recruter davantage de personnes dédiées. aux managers de veiller au strict respect du processus par ces programmeurs.

Même si je n'ai pas recruté avec cette idée en tête, pour des raisons objectives, le recrutement s'est plutôt porté sur un grand nombre de novices. Et le vétéran n'a pas la capacité d'enseigner, donc forcer le débutant à enseigner contaminera les mauvaises habitudes du vétéran. L'équipe est également confrontée à ce dilemme. Il existe une énorme différence de difficulté entre développer une personne et développer une équipe. C'est pourquoi je veux consacrer plus d'énergie, c'est-à-dire plus de coûts de gestion et de formation, aux novices.

Pour parler franchement, cela signifie travailler davantage sur d’autres aspects de l’ingénierie logicielle, puis payer pour les mauvais aspects de la mise en œuvre.

2. « L’algorithme est bon »

Ce qui a commencé comme un entretien avec un ingénieur logiciel s'est transformé en une réunion de questions-réponses pour vérifier vos résultats.

La raison est très simple : pour la résumer en quatre mots, il s'agit de « généraliser d'une partie à l'autre ».

Le génie logiciel est un comportement multidimensionnel et complexe, dont la mise en œuvre du code n'est qu'une partie ; et les algorithmes ne sont qu'une partie de la mise en œuvre du code. En fait, il existe encore un énorme écart entre être un simple expert en algorithmes et un véritable ingénieur logiciel.

3. « Génial »

Si l'on entend par « personnes talentueuses » des « personnes possédant des compétences techniques exceptionnelles », l'équipe a-t-elle vraiment besoin de toutes sortes de personnes talentueuses ? Je ne pense pas : par rapport aux « gens formidables », l’équipe a davantage besoin des « bonnes personnes ».

Commençons par un point de vue technique. Une équipe idéale doit être techniquement complémentaire dans une certaine mesure. Par exemple, dans une équipe full-stack, certains membres sont bons au niveau de la couche inférieure du système, d'autres sont bons dans les applications Web ; certains ont une pensée système rigoureuse et d'autres ont une intuition aiguë du produit. Ensuite, que ce soit dans la conception de systèmes ou Localisation du problème, la prise de décision de l'équipe peut atteindre un certain équilibre en apprenant des forces de chacun .

Regardons-le d'un point de vue non technique. Même si le candidat est impeccable sur le plan technique, nous avons encore de nombreux facteurs non techniques à prendre en compte ; même si le candidat est impeccable sur le plan personnel non technique, nous devons toujours considérer l'adéquation entre le candidat et le style de l'équipe. . Par exemple, certaines personnes particulièrement compétentes en technologie ont des personnalités plus distinctives ou sont difficiles à vivre. Faut-il dire oui ou non à un tel candidat ?

Cela implique la culture d’une entreprise et l’acceptation de l’équipe. Il est évident que si une équipe est pleine de « têtes épineuses » et qu'il y a de violents conflits d'opinions, ce sera certainement une mauvaise situation. Il est probable que le manager sera occupé chaque jour à régler les conflits ; et si une équipe est pleine des « têtes épineuses », « Bon vieux » n'a que des éloges et une reconnaissance des opinions. C'est en fait une situation inquiétante, car le manque d'opinions signifie souvent le manque de pouvoir de décision.

4. Intelligent et potentiel »

Qu’il s’agisse d’une entreprise ou d’une équipe, il doit y avoir un certain équilibre dans la composition des ingénieurs expérimentés et des ingénieurs potentiels.

Certaines équipes sont relativement matures en termes de technologie, ont une structure stable et des processus solides. Les ingénieurs expérimentés peuvent disposer d'un certain temps pour guider et aider les nouveaux arrivants à grandir, et l'équipe peut cultiver sa propre colonne vertébrale. On peut alors dire que de tels candidats sois le meilleur.

A l'inverse, certaines équipes sont à l'inverse, notamment certaines équipes entrepreneuriales ou équipes de start-up de produits. Chacun doit jouer un rôle de premier plan, et même tout le monde est occupé à éteindre les incendies. Dans ce cas, il est particulièrement nécessaire d'avoir Forte capacité d'autogestion, qualité globale et expérience.Anciens combattants, ces candidats ne conviennent pas pour le moment.

L'équipe de développement de notre entreprise appartient à la deuxième catégorie et doit changer cette situation de toute urgence.

(2) Angle d'enquête

De quels types de talents techniques l’entreprise et l’équipe ont-elles besoin ? Autrement dit, comme le reflète l’entretien, sous quel angle doit-on examiner et sélectionner les talents ? Comment appréhender les dimensions de la sélection des candidats ingénieurs logiciels d’un point de vue macro ?

1. Angles couramment utilisés

La perspective couramment utilisée est une compréhension commune et objective d’un excellent ingénieur logiciel.

(1) Niveau technique

Sur le plan technique, nous devons examiner les compétences de base des ingénieurs logiciels. Y compris : capacité pratique de résolution de problèmes, capacité de conception et de mise en œuvre de code, capacité d'analyse et de conception de systèmes, capacité de test et de vérification .

a. Capacité pratique à résoudre des problèmes

Je ne suis pas d'accord avec l'utilisation de questions plus simples sur l'algorithme et la structure des données dans les entretiens. Ce n’est pas qu’il ne s’agit pas d’une enquête, mais que sa couverture est trop étroite. Plus précisément, la solution à un problème pratique typique doit inclure deux parties :

1. Résumer des problèmes spécifiques en plusieurs problèmes logiciels résolubles ;
2. Utiliser les connaissances et compétences en génie logiciel pour résoudre ces problèmes.

Les problèmes d'algorithme pur et de structure de données peuvent non seulement résoudre le deuxième des deux points ci-dessus, mais ce deuxième point doit également être un problème qui relève du niveau de codage ou même du niveau mathématique, ce qui montre sa couverture étroite. Quant à savoir quel genre de question est une bonne question d’entretien.

B. Capacités de conception et de mise en œuvre du code

Il s'agit d'une compétence de base pour les ingénieurs logiciels. Elle couvre un champ beaucoup plus large que les simples algorithmes et structures de données. Par exemple, les compétences orientées objet que certaines entreprises aiment particulièrement examiner entrent dans cette catégorie.

C. Capacités d'analyse et de conception du système

Y compris si une estimation raisonnable du système, une conception d'architecture, etc. peuvent être données pour le problème. Cette partie est étroitement liée à l’expérience.

D’une manière générale, une riche expérience professionnelle devrait signifier certaines capacités d’analyse et de conception de systèmes. Nous pouvons simplement y penser de cette façon :

Le « système » mentionné ici fait généralement référence à un « système logiciel » plutôt qu'à un « système distribué ».

La vague Internet actuelle a également eu des effets défavorables sur les techniciens, comme la recherche excessive de mots brûlants tels que « distribué ». Il semble que lorsqu'il s'agit de systèmes, cela signifie big data, volume massif et débit élevé. Certains systèmes simples ne sont pas méprisés. Je pense que c'est très inapproprié.

Pour comprendre le système, tout comme le fondement des mathématiques est l’arithmétique élémentaire, nous devons encore poser des bases solides.

d.Autres capacités d'ingénierie complètes

Tels que les capacités de test et de vérification, etc. Ce n’est pas qu’ils soient sans importance, ni que nous ne les examinions pas, mais que nous devrions nous concentrer sur l’examen technique des ingénieurs logiciels lors des entretiens. Par exemple, on peut simplement accepter de consacrer seulement 20 % du temps du contrôle technique à cette partie.

Où est le test de connaissances informatiques de base ? En fait, cela figure dans les éléments d’inspection mentionnés ci-dessus.

Par exemple, pour concevoir un système de site Web, vous devez avoir une compréhension de base des protocoles réseau, en particulier le protocole HTTP, une connaissance de base des middlewares et des conteneurs, ainsi qu'une compréhension de base des bases de données.

(2) Niveau non technique

Nous nous concentrons sur le caractère de base des ingénieurs, leur capacité à travailler en équipe, leur capacité d’apprentissage, leur capacité à communiquer, leur capacité à gérer les tâches, etc.

Par exemple, lors d'un entretien, si vous constatez qu'il y a un gros problème de communication avec le candidat, vous ne pouvez pas vous empêcher de le remarquer, et il n'est pas nécessaire de poser spécifiquement une question qui teste « spécifiquement » les compétences en communication.

En résumé, pour les candidats ingénieurs logiciels, les séries d'entretiens doivent garantir que la plupart d'entre eux sont couverts sous forme d'entretiens techniques, tandis qu'un petit nombre est autorisé à être couvert sous forme d'entretiens non techniques (par exemple, 4 séries d'entretiens) . entretiens techniques sur 5 tours, 1 tour d'entretiens non techniques). Cependant, les données obtenues à partir de chaque série d’entretiens techniques doivent couvrir les deux.

Pour les ingénieurs qui viennent d'entrer sur le marché du travail, ils devraient accorder plus d'attention aux qualités liées au potentiel, comme s'ils peuvent écouter les suggestions et y réfléchir, et s'ils ont de l'intérêt et de l'enthousiasme, car c'est quelque chose qui ne s'apprend pas .

Pour les ingénieurs possédant une riche expérience, une plus grande attention doit être accordée à la vision, à la profondeur de la compréhension technique et au professionnalisme.

2.Autres angles

Il fait référence à différentes équipes et postes subdivisés, qui ont des exigences différentes pour les candidats ingénieurs logiciels.

Au niveau technique, par exemple, certains postes nécessitent des compétences frontales, certains postes nécessitent une formation en IA et certaines équipes nécessitent une expérience professionnelle dans le cloud computing.

Au niveau non technique, de nombreuses grandes entreprises établiront plusieurs principes directeurs spécifiques. Ces principes sont comme un programme pour guider le processus d'évaluation des parties non techniques des candidats. Par exemple, les principes de leadership d’Amazon ont été discutés par de nombreuses personnes ces dernières années et chaque entretien chez Amazon doit en aborder un ou deux.

Même si un poste segmenté spécifique comporte des exigences de compétences plus détaillées et plus claires, nous pouvons néanmoins constater que pour les entretiens avec les grandes entreprises, la proportion d'angles communs est souvent plus importante.

Il est évident que plus le poste est subdivisé et plus les exigences sont spécifiques, plus il est probable que l'adéquation des candidats soit améliorée, mais cela réduit également l'universalité de la sélection des talents et rend le recrutement extrêmement difficile. Par conséquent, ces grandes entreprises fournissent des normes de recrutement vagues et choisissent de les former davantage après les avoir recrutés. C’est à la fois délibéré et impuissant.

Un ingénieur logiciel qui réussit bien dans la partie « angles communs » de l'entretien a plus de chances d'être un excellent ingénieur logiciel au sens général. Même s'il ne possède pas immédiatement une certaine compétence pour un poste spécifique, après une courte période d'apprentissage étudier et s'intégrer, il est également susceptible de pouvoir remplir le rôle rapidement.

Pour toute entreprise ou équipe, il ne s'agit pas de recruter des « bonnes personnes », mais des « personnes appropriées ». Notre objectif principal est de gagner avec les candidats, plutôt que de simplement gagner en termes de rentabilité.

2. Élaborez un plan d'entretien

(1) Analyse du plan

Tout d’abord, comprenez les besoins et les contraintes de votre équipe et fixez des attentes raisonnables. Nous ne voulons certainement pas embaucher les mauvaises personnes, mais nous ne voulons pas non plus passer à côté de bonnes personnes.

Ce que nous devons préciser, c'est qu'un investissement adéquat en termes de temps et de coûts de main-d'œuvre, ainsi qu'une couverture raisonnable des angles d'inspection, sont deux choses complètement différentes et essentielles. L'effet que nous espérons obtenir est qu'avec un investissement suffisant, l'équipe d'entretien obtienne des données plus complètes qui peuvent aider à évaluer les candidats, mais sans répéter excessivement la couverture d'un certain angle.

Si le processus est correct et que les données sont suffisantes, les résultats seront raisonnables.

Troisièmement, l'angle d'inspection, l'orientation de l'inspection et le contenu de l'inspection doivent également respecter le principe de cohérence.

Enfin, les tournées d’inspection doivent être progressives.

Lorsque nous comprenons les besoins de l'équipe et la perspective de l'enquête, et que nous trions les candidats et les plans, même si la véritable série d'entretiens n'a pas officiellement commencé, la bataille est déjà à moitié terminée.

(2) Entretien téléphonique et entretien sur place

Le rôle le plus important des entretiens téléphoniques est de « filtrer » ceux qui ne sont manifestement pas fiables, à un coût relativement faible.

Dans le plan, il y a généralement moins de séries d'entretiens téléphoniques (1 à 2 tours), par conséquent, les entretiens téléphoniques devraient pouvoir couvrir le contenu qui nous préoccupe le plus. La prise de décision lors des entretiens téléphoniques est généralement très rapide. Les enquêteurs de l'entretien téléphonique se rencontrent. Si l'entretien réussit et que le responsable du recrutement estime qu'il n'y a pas de gros problème, vous pouvez alors passer à l'entretien sur place.

Si vous hésitez à réussir l'entretien téléphonique, alors : Pensez-vous que le candidat peut réussir au moins un entretien sur place ? Si possible, passez un entretien téléphonique.

D'un point de vue non technique, nous devons nous concentrer sur la question de savoir si l'autre partie a des exigences claires et si elles correspondent à ce que l'équipe peut fournir . Par exemple, si ce poste nécessite de voyager à l'étranger et que le candidat ne peut pas l'accepter, alors cela doit être communiqué clairement avant l'entretien téléphonique ou à l'avance pour faire gagner du temps à chacun.

(3) Nouveaux diplômés et vétérans

Les nouveaux diplômés et les vétérans sont deux types de candidats complètement opposés, et l'objectif de notre examen est différent.

Pour les ingénieurs peu expérimentés, nous valorisons davantage le potentiel ;

Pour les ingénieurs expérimentés, ce que nous valorisons davantage, c'est la capacité, comme en témoignent les exigences en matière de capacités de conception de systèmes.

1. Entretien pour les nouveaux diplômés :

D'une manière générale, pour les nouveaux diplômés ou le recrutement sur le campus, notre investissement en temps peut être réduit de manière appropriée.
L’architecture et la conception du système ne devraient pas constituer le contenu principal de l’examen. Comprendre le système est un processus qui nécessite du temps et de l’expérience pour s’accumuler progressivement.
Réduire l’examen de compréhension en ingénierie. Si vous examinez la compréhension qu'ont les nouveaux diplômés de la gestion de projets et de tâches, leur compréhension du génie logiciel n'a souvent que peu d'importance, pour la même raison que ci-dessus.
Augmenter la proportion de « qualités potentielles » telles que l'intérêt, l'enthousiasme, la capacité d'apprentissage et la capacité d'accepter les opinions . En un mot, pensez-vous qu'il puisse grandir rapidement avec l'aide de l'équipe et être rapidement promu ingénieur senior ?
Selon la perspective de l'enquête, une demande relativement claire et précise peut être formulée.

2. Entretien de recrutement social :

L'architecture et la conception du système peuvent faire l'objet d'une enquête
Les questions peuvent être vagues pour tester la réflexion et savoir si les idées sont riches

3. Conception du problème

(1) Mauvais problèmes techniques

1. Questions basées sur les connaissances , testant les connaissances et la mémoire, plutôt que toute compétence de base d'un ingénieur. Ne convient pas pour passer beaucoup de temps à enquêter. Parce que d’un côté ce n’est pas universel, de l’autre c’est trop aléatoire.

Le manque d'universalité signifie que les candidats doivent comprendre des cadres ou des bibliothèques spécifiques. Étant donné que les excellents candidats ont des connaissances différentes, cette exigence est trop arbitraire ;

Un caractère aléatoire trop fort fait référence au fait que le candidat connaît ce point de connaissance. Le caractère aléatoire est trop fort et ne reflète pas le niveau de compétence du candidat.

Certains problèmes se limitent à des langages de programmation, des frameworks et des bibliothèques spécifiques. L'un d'eux est le problème.

"Veuillez implémenter l'algorithme atoi en C++."

Cette question convient si l'équipe exige que les candidats possèdent des compétences en C++ ; mais pour la plupart des équipes, ce n'est pas le cas, cette question est donc injuste pour les candidats qui utilisent généralement Java comme langage de programmation principal. C'est pourquoi de nombreuses grandes entreprises ont un principe directeur en matière de formation aux processus d'entretien : ne pas limiter le langage de programmation utilisé par les candidats .

2. Des questions trop courantes

Les questions trop souvent utilisées risquent d’avoir été préparées par les candidats, ce qui réduit considérablement l’authenticité de l’enquête. Les candidats honnêtes vous diront que j'ai répondu à cette question, mais vous ne pouvez pas vous attendre à ce que tous les candidats le fassent.

Au contraire, nous souhaitons justement examiner les « anciennes » capacités du candidat à travers de « nouvelles » questions. C’est pourquoi nous disons que les problèmes évoluent constamment, mais que les routines sont éternelles.

3. Le problème des règles trop complexes

L'approche de simplification des problèmes complexes est étroitement liée aux éléments d'inspection.

Et il est loin des problèmes réels que nous voulons résoudre et de nos scénarios de travail, il n'a ni couverture commerciale ni couverture technique, et sa valeur dans les entretiens techniques est en fait très faible. Par exemple, quelques casse-tête.

(2) Principes de conception pour les problèmes techniques

1. Soyez cohérent avec l’angle et la mise au point de l’inspection

En nous concentrant sur le plan d'entretien et les objectifs de l'entretien, nous pouvons obtenir des données d'enquête efficaces afin de pouvoir prendre des décisions après l'entretien.

Par exemple, un enquêteur souhaite mener des entretiens avec des candidats, en se concentrant sur « la résolution de problèmes pratiques et la compréhension du système ». Par conséquent, il a décidé d'utiliser une question sur la « conception d'un système de covoiturage en ligne » comme question principale et d'en discuter avec les candidats lors de l'entretien. Ainsi, à partir de là, nous pouvons voir en gros que l’intervieweur doit saisir ces deux points clés :

Résoudre des problèmes pratiques : l'intervieweur a l'intention de poser des problèmes pratiques et de faire attention à savoir si le candidat peut progressivement acquérir les compétences d'un ingénieur et résoudre les principaux problèmes pratiques de ce « covoiturage en ligne » (comme Didi Taxi, qui est un véritable système), simplifiées et résumées en problèmes logiciels et résolues.
Compréhension du système : Après avoir discuté des exigences avec le candidat, l'intervieweur envisage de demander au candidat de concevoir un système logiciel pour le mettre en œuvre. Au cours de ce processus, l'accent sera mis sur la question de savoir si le candidat possède des compétences en conception de systèmes et s'il peut résoudre résoudre le problème en fonction de ses caractéristiques et faire les choix technologiques appropriés.

2. Du flou au clair, du pratique à l'abstrait

Il est compréhensible de passer du flou à la clarté, mais que signifie passer du réel à l’abstraction ? Ne devrait-il pas passer de l'abstrait au pratique ? Cela ne peut être réalisé que si cela est mis en pratique !

Les ingénieurs logiciels sont censés faire de l’ingénierie, et l’ingénierie consiste essentiellement à résoudre des problèmes pratiques.

Du flou à la clarté, et de la réalité à l’abstraction, il semble y avoir deux processus, mais en réalité ce sont exactement les mêmes :

Les problèmes réels sont souvent vagues : ils peuvent provenir d’une plainte d’un client, d’une suggestion d’un utilisateur ou d’un problème peu clair ;

Les problèmes qui peuvent être résolus par des approches logicielles doivent être clairs et simples. Si même les concepteurs du logiciel eux-mêmes ne peuvent pas expliquer clairement les exigences et la logique, la mise en œuvre sera impossible. Puisqu'ils peuvent expliquer clairement, cette description doit avoir été simplifiée. et abstraction, en supprimant les détails et en ne conservant que le cœur du problème.

Par conséquent, seules certaines parties essentielles d’un problème spécifique peuvent être résolues par un logiciel, et la plupart des autres ne peuvent être utilisées que comme une feuille de route. Ce principe parle en fait de « profondeur » .

L'intervieweur a posé au candidat des questions techniques comme celles-ci :

“请你设计一个网约车系统。”

Une fois que certains candidats auront compris le problème, ils seront perdus : " Oh mon Dieu, par où dois-je commencer ? " Oui, ce problème semble très important, mais c'est aussi un problème pratique que les ingénieurs doivent résoudre, souvent des problèmes pratiques vagues. .

Nous espérons travailler avec les candidats pour créer un tel processus de transformation du flou au clair, du pratique à l'abstrait. Prenons l'exemple du parcours d'inspection de la conception du système :

Sur la base de cette affirmation vague, quel est le problème principal que nous voulons résoudre ? Le système de covoiturage en ligne est si vaste : parmi les problèmes à résoudre, quel type de problèmes nous préoccupe le plus ?
Sur la base des questions les plus préoccupantes que nous avons identifiées, les exigences fonctionnelles et les exigences non fonctionnelles pertinentes sont répertoriées . Les exigences peuvent être nombreuses et notre objectif est d’identifier celles qui comptent lors de l’entretien.
Concevez le système en fonction des besoins, y compris toutes les couches depuis le client, le réseau, le service jusqu'au stockage, etc. Après avoir eu un plan approximatif, notre objectif est de sélectionner une petite partie de celui-ci qui nous préoccupe le plus pour en discuter.
Si vous souhaitez toujours examiner le niveau de code, sélectionnez un certain composant ou mécanisme dans la conception ci-dessus pour discuter de la conception au niveau du code.
Selon la conception au niveau du code, vous pouvez choisir de l'implémenter.Par exemple, vous pouvez exiger l'implémentation d'une logique de base, d'une structure de données de base, etc.

Comme vous pouvez le voir, l’idée générale est la suivante :

Problème > Exigences > Conception du système > Conception du code > Implémentation du code

Dans un souci d'opérabilité, chaque avancée permettra de réduire le champ d'application et d'examiner en profondeur les compétences des candidats à différents niveaux. Plus d’un angle d’investigation, plus d’une solution.

« Plus d'un angle d'enquête » fait référence à la même description vague au début, qui peut être progressivement guidée vers un angle d'enquête spécifique selon les dispositions du plan d'entretien. Ce principe parle en fait de « largeur » .

Si l'objectif de l'inspection nous oblige à examiner les structures de données et les algorithmes , cela est également possible, comme un simple algorithme de recherche de chemin du point de départ au point final, et à l'implémenter dans le code ; nous pouvons également prendre le chemin de l'inspection de la conception orientée objet et des cas d'utilisation clés de la conception. Les classes impliquées, y compris leurs structures et leurs relations, etc.

« Plus d'une solution » signifie qu'à un niveau inférieur, après avoir affiné les questions spécifiques mentionnées ci-dessus, la réponse ne doit pas être unique, mais il doit y avoir plusieurs méthodes différentes. Par exemple, pour les problèmes d’algorithme de recherche de chemin, nous pouvons parfois utiliser le retour en arrière par force brute pour les résoudre, parfois nous pouvons utiliser des méthodes de programmation dynamique optimisées pour les résoudre, et ainsi de suite.

Plus le candidat est expérimenté en logiciel , plus on peut lui confier une problématique plus vague et essayer de le laisser diriger le processus de décomposition et de raffinement ;

Pour la scolarisation , nous pouvons formuler une demande relativement claire et précise. Bien entendu, dans ce processus,

S'il s'avère que la difficulté est trop élevée, nous pouvons activement lui donner des conseils ou l'aider à terminer une partie du processus, ce qui se situe dans une fourchette raisonnable.

(3) Compétences en conception pour les problèmes techniques

1. Concevoir des problèmes à partir de domaines familiers

Sur quel type de problème vous sentez-vous toujours en contrôle, même lorsque vous en discutez de manière divergente ? Cela doit être quelque chose que vous connaissez.

2. De superficiel à profond, développez en couches

"Veuillez concevoir un système de covoiturage en ligne."

Une fois la question posée, certains candidats peuvent communiquer plus calmement et clarifier le problème, tandis que d'autres candidats ont besoin de conseils étape par étape de la part de l'intervieweur - « Que comprend spécifiquement cette question ? » Oui, il s'agit exactement d'une analyse et d'une analyse. Le processus d'affinement des exigences nécessite une discussion entre le candidat et l'intervieweur.

Nous pouvons réfléchir du point de vue des cas d'utilisation principaux, réfléchir aux rôles existants et aux fonctions qui peuvent être accomplies via le système, par exemple :

Les passagers peuvent demander un trajet à tout moment et n'importe où ;
Le système recherche les chauffeurs à proximité et transmet la demande. S'il ne peut pas accepter la commande, il continue d'élargir la portée de la recherche ;
Les conducteurs peuvent prendre des courses, c'est-à-dire accepter ou rejeter les demandes de course ;
Les deux parties peuvent actualiser leurs positions sur la carte et visualiser les positions actuelles de chacune ;
Pendant la période d'attente, les deux parties peuvent consulter les informations de chacun ;
Les deux parties peuvent vérifier leurs notes respectives et s'évaluer mutuellement une fois le trajet terminé ;
……

Nous pouvons donc choisir une ou quelques fonctions parmi les plus essentielles pour continuer à discuter avec les candidats. Après tout, le temps d’entretien est limité et nous ne pouvons pas mordre plus que ce que nous pouvons mâcher.

Une fois les exigences fonctionnelles claires, nous devons également discuter et déterminer plusieurs exigences non fonctionnelles importantes avant d’entrer dans l’étape de conception. Par exemple, combien d’utilisateurs y a-t-il, combien de demandes y a-t-il chaque jour, etc. Ces valeurs n'ont pas besoin d'être précises, mais l'ordre de grandeur des valeurs affectera la conception du système.

Le candidat et l'intervieweur résolvent ensemble le problème couche par couche, transformant un problème vague en un problème commercial simplifié, ne laissant qu'un nombre limité de points de demande à réaliser.

L'étape suivante consiste à réfléchir à la manière de la mettre en œuvre d'un point de vue technique en fonction des points de demande précédemment sélectionnés ; quant à la mise en œuvre technique, nous devons toujours adhérer aux mêmes principes, du flou à la clarté, et affiner progressivement :

En regardant l’ensemble du système, quels sont les composants ou les services ? (Appels de composants et dépendances)
En associant les composants du système et les rôles des utilisateurs, comment les passagers et les conducteurs interagissent-ils avec le système ? (Relation temporelle d'interaction)
Quelles sont les responsabilités de chaque service et quelle technologie est utilisée pour le stockage des données dans le système ? (conception de la couche de stockage)

Après avoir défini une conception de système généralement réalisable, sélectionnez une couche, un composant ou un mécanisme pour l'affiner et l'étendre davantage.

Par exemple, en termes de stockage, si le candidat propose d'utiliser des données relationnelles pour stocker les informations de localisation des passagers et des conducteurs, alors on peut le développer à travers cette idée :

Quelle structure de table envisagez-vous de concevoir pour stocker de telles informations ?
Y a-t-il des dangers cachés dans une telle solution ? Quels problèmes peuvent survenir après le lancement du produit ?
Comment comptez-vous résoudre un tel problème ?

3. Définissez le niveau de difficulté le plus élevé pouvant être atteint sur la pointe des pieds

Différents candidats ont des capacités différentes et les progrès qu’ils peuvent réaliser sur le même problème sont également différents. La profondeur du problème doit être hiérarchique, en affinant progressivement le problème, en décollant le cocon et enfin en le mettant en œuvre dans une mise en œuvre partielle qui peut être achevée en peu de temps.

S'il s'avère que la question est difficile pour le candidat, l'intervieweur doit procéder à des ajustements dynamiques pour réduire la difficulté. Cela peut se faire en donnant des conseils sur les questions, en réduisant de manière proactive la portée de la question, en affaiblissant les exigences de la question, ou même directement. promouvoir l’analyse des problèmes.

Et si le problème est trop simple pour le candidat, alors le temps alloué au processus doit être réduit et plus de temps doit être consacré aux discussions de « suivi » pour de nouvelles améliorations une fois le problème résolu.

Si un problème algorithmique consiste à implémenter le parcours pré-ordre et post-ordre d'un arbre binaire à l'aide d'un algorithme non récursif, et que le candidat semble n'avoir aucune idée, alors nous pouvons :

Posez une question : "Quel type de structure de données est un arbre binaire ? Quelles sont les définitions du parcours pré-ordre et post-ordre ?";
Réduisez la portée du problème : "Implémentons d'abord le parcours de précommande !";
La question affaiblie demande : "Et si nous pouvions faire cela en utilisant la récursivité ?" ;
Analyse avancée du problème : introduisez directement l'idée de parcours de précommande ou de post-commande et utilisez une implémentation non récursive.

Que ce soit à travers des indices ou des suggestions explicites, nous continuerons à approfondir et à surmonter les défis de chaque niveau de difficulté croissante. L' effet le plus idéal est d'atteindre la difficulté la plus élevée de ce mini-projet, qui est exactement la difficulté que le candidat peut "atteindre". sur la pointe des pieds", ni trop simple ni trop difficile à réaliser.

C'est trop simple et ennuyeux, et les candidats auront également l'impression que l'entreprise et l'équipe ne sont pas très bonnes ;

Si c'est trop difficile, cela peut avoir un impact important sur le candidat ou l'empêcher de terminer l'ensemble du processus de résolution de problèmes.

Nous pouvons utiliser les quatre méthodes ci-dessus pour guider les candidats afin qu'ils clarifient leurs idées jusqu'à ce qu'ils puissent commencer à coder.

Ce processus d'ajustement dynamique nécessite l'accumulation d'expériences afin de pouvoir le contrôler librement. Mais nous pouvons nous fixer un tel objectif dès le début : nous espérons que les candidats de différents niveaux pourront être « heureux lorsqu'ils arrivent et ne peuvent s'empêcher d'y penser lorsqu'ils partent ».

4. Collectez continuellement des données et ajustez vos questions

« Continuez à collecter des données et affinez vos questions. » Tout comme la façon de bien faire n'importe quelle chose complexe, elle doit être tempérée. Une fois le problème conçu, nous devons l'utiliser à plusieurs reprises dans la pratique.

D'une part, les données peuvent être obtenues en continu. Ces données peuvent vous aider à établir votre propre "système de référence de coordonnées" . Lors de l'évaluation d'un nouveau candidat, nous savons où il se trouve approximativement; d'autre part, les problèmes peuvent être ajustés, améliorés, voire remplacé en fonction des résultats, notamment en augmentant ou en réduisant l'ampleur du problème de manière appropriée en fonction de la situation, etc.

Utiliser un problème de votre propre conception apportera également une certaine "fraîcheur" aux candidats. Réalisez ce mini projet et résolvez un problème nouveau et intéressant au lieu d'en chercher beaucoup sur Internet. C'était comme si c'était quelque chose qui venait facilement, mais ce qu'il ne savait pas, c'est que cette question avait été soigneusement préparée par l'intervieweur et tempérée dans la pratique.

5. Élargissez la portée et configurez des extensions multi-angles pour le problème

“如果你所在的团队拥有一个重要的 service，它的平均请求响应时间为 1 秒，有一天你部署
了软件新版本后，留意到它的平均请求响应时间异常地增大到了 10 秒，你该怎么做？”

Extension 1 - Examiner la compréhension de l'expérience utilisateur et de l'ingénierie : Que devons-nous faire en premier lieu pour minimiser l'impact sur les utilisateurs ? Nous pourrions parler de rollback, puis nous pourrons parler d'Ops. Comment éviter ce problème à l’avenir ? Cela nous permet de discuter du processus d'ingénierie logicielle, de l'assurance qualité, du CI/CD, de la version en niveaux de gris, etc. Cette extension peut examiner des aspects du processus de génie logiciel et des aspects de l'excellence en ingénierie.

Extension 2 - Examiner la conception des systèmes de surveillance et d'alarme : Comment savoir le plus rapidement possible qu'il y a un problème avec notre système ? Cela peut parler de surveillance et d'alerte logicielles. De quel type de données avons-nous besoin pour surveiller et alerter ? Comment collecter des données, comment envoyer des données, c'est-à-dire comment concevoir un système d'alarme ? Cette extension peut être affinée jusqu'à un problème de conception de système de surveillance ou une inspection au niveau du code.

Extension 3 - Examiner les idées de résolution de problèmes et la compréhension systématique : Comment devrions-nous localiser le problème et à quel niveau le problème peut-il survenir ? Par exemple, il se peut que le service fonctionne correctement, mais qu'il y ait un problème avec le client, ou qu'il y ait un problème avec le réseau, ou encore qu'il y ait un problème avec le service. Quant aux problèmes de service, quelles en sont les causes possibles ? Quelles stratégies adopter pour localiser le problème couche par couche de haut en bas ? Cette extension peut continuer à examiner la compréhension du système par le candidat, notamment à travers un processus de requête et de réponse, pour examiner sa compréhension de la pile complète du système.

Extension 4 - Se concentrer sur une certaine couche du système : En affinant jusqu'à une certaine couche pour élargir davantage, il y a de nombreuses idées dans cette partie. Nous pouvons choisir plusieurs points d'entrée communs en fonction des besoins. Par exemple, si le problème est dû à des instructions trop lentes dans une base de données relationnelle, nous pouvons nous concentrer davantage ici et discuter des causes de certains problèmes courants de performances des bases de données relationnelles et des solutions correspondantes. S'il s'agit d'un problème au niveau de l'application, tel qu'une mémoire insuffisante dans l'application, vous pouvez alors développer davantage dans cette perspective.

Extension 5 - Concentrez-vous sur le problème de limitation de courant du système : Si le problème est dû au fait qu'un certain client envoie trop de requêtes sur une courte période à ce moment-là et que le système est incapable de les traiter à temps, alors nous peut commencer par le contrôle du débit. Le problème du contrôle de flux est également l’un des problèmes système classiques, qui peut être examiné du point de vue de la conception du système ou de la conception du code.

Vous voyez, un vague problème pratique peut être étendu dans de nombreuses directions, et ces extensions sont étroitement liées. Nous pouvons choisir l’un des angles étendus à étudier pendant l’entretien selon les besoins.

6. Équilibrer la profondeur et l’étendue de l’enquête

Si nous pouvons toujours étudier la technologie, en commençant par un problème pratique simple et vague, en l'approfondissant progressivement et en terminant finalement par un processus complet de résolution de problème, alors on peut presque dire que nous avons atteint à la fois la profondeur et l'ampleur.

Pourquoi est-ce que je ne recommande pas d’utiliser des questions algorithmiques simples et grossières lors des entretiens ? En dernière analyse, il s'agit d'une question d'investigation. Le simple examen de questions algorithmiques est un exemple d'investigation suffisamment approfondie, mais il est facile de perdre l'ampleur de l'investigation.

Il existe un style d'entretien qui demande au candidat de parler d'un projet qu'il connaît le mieux ou dont il est le plus fier, puis en extrait certains points et continue à creuser plus profondément. Cela semble en soi être une très bonne idée pour l’enquête, car c’est exactement le contraire de l’idée de l’intervieweur consistant à préparer les questions dont nous avons parlé plus tôt : le candidat dirige le processus.

Mais en réalité, je ne recommande généralement pas la méthode ci-dessus aux intervieweurs peu expérimentés, car en pratique, cette méthode nécessite une très grande qualité des intervieweurs : si le projet ou le système dont parle le candidat, l'entretien Si le l'intervieweur connaît l'intervieweur, alors tout est facile à expliquer.Cependant, si l'intervieweur ne le connaît pas, il sera difficile pour l'intervieweur de saisir les points clés ici, et il est facile pour l'intervieweur d'être dirigé par Peut-être que le candidat lors de cette série d'entretiens a parlé en termes généraux, parlant de Il y a de nombreux aspects, mais l'intervieweur ne peut pas poser de questions pointues.

Entretien technique (2) Comment se préparer à l'entretien