Qu'est-ce que je dans ACID ou une perspective différente

Après avoir lu ce post écrit par Farwayer , au début, je voulais juste laisser un commentaire, mais après avoir réfléchi quelques dizaines de minutes, j'ai décidé que le sujet était profond, et j'ai quelque chose à dire pour tout le post. Tout de même, d'une part, je suis de ceux qui ne regardent pas le code lors des entretiens et qui sont déçus par le manque de connaissance de la complexité de la recherche d'index dans les SGBD relationnels, d'autre part, je crois que je peux donner une idée de la façon dont un groupe assez important d'intervieweurs pense, pourquoi ils le font (à première vue) illogiques et destructeurs, et quels problèmes ils veulent résoudre eux-mêmes. Il est à espérer que la compréhension de l’image de l’ennemi dans le monde répondra elle-même à de nombreuses questions.

Pour commencer, je vais vous parler de moi. J'espère que cela vous aidera à mieux comprendre ce qui est décrit ci-dessous. Dans le développement de logiciels pendant 9 ans, pendant un certain temps, il a travaillé pour lui-même (créé des robots d'échange et échangé avec son propre argent), la plupart du temps il était un développeur embauché (y compris le développeur principal). Récemment, j'ai été en épicerie. A réuni 2 équipes de niveau supérieur. Il a mené plusieurs dizaines (quoique moins de 100) d'entretiens techniques aux postes de middle2s senior, senior, lead. Je n'ai pas travaillé dans l'externalisation pendant une journée dans ma vie, j'ai passé 18 jours. Par conséquent, je peux dire que toute expérience est associée au produit (propre ou à l'employeur) et que tous les entretiens ont été menés avec la motivation «de trouver la personne qui apportera le maximum d'avantages au produit». J'admets que l'expérience de l'auteur de l'article original est plus grande que la mienne, mais le but n'est pas de vous dire comment le faire correctement, ou de donner des conseils sur la façon d'agir, mais de dire comment vous pouvez regarder les mêmes choses d'un autre, un autre, et non le fait qu'il soit correct, point de vue.

Allons sur les points (les noms sont tirés du post d'origine).

Personne ne se soucie de votre code

Tout d'abord, la question est de savoir quel est le bon code et quelles sont les attentes du code produit par un programmeur expérimenté. Pour moi, un bon code est fonction de la tâche, des conditions dans lesquelles cette tâche se déroule, des directives adoptées dans l'équipe (entreprise), des attentes du responsable technique (architecte), chef de produit, responsable QA. Par exemple, envisagez plusieurs tâches:

1. Développer une API pour sa publication ultérieure aux cinq cents clients B2B de l'entreprise afin d'intégrer le produit dans leurs solutions - une solution bien pensée et bien documentée est attendue avec la structure la plus compréhensible, la conformité aux normes acceptées sur le marché, la validation des données la plus rigoureuse, la couverture complète des tests, l'extensibilité, la journalisation réfléchie, conformité à toutes les exigences de sécurité, évolutivité des performances, résistance aux exemples au moins primitifs DoS et DDoS ;
2. Pour mettre en œuvre la conformité du produit aux exigences du régulateur, qui prend effet dans un mois, et peut conduire à la fermeture de l'ensemble de l'entreprise - une solution fiable est attendue en mettant l'accent sur les tests ;
3. Correction d'un bug sur la prod lié à la mise en cache, qui est devenu connu une heure avant le Black Friday, il est prévu que la solution soit écrite et déployée sur la prod en 30 minutes et ne cassera rien. D'autres exigences sont laissées pour compte ;
4. Testez l'hypothèse pour laquelle vous devez analyser 250 pages du site d'un concurrent une seule fois, puis formez un document de feuille de calcul google pour l'analyste commercial - il est prévu que le programmeur ne fera pas trop de travail et n'écrira pas de code en écriture seule sans y dépenser beaucoup. le temps ;
5. Pour vérifier les performances d'Aerospike sur une tâche pour laquelle PostgreSQL est traditionnellement utilisé dans l'entreprise, et il y a des problèmes de performances, il est prévu que les nuances algorithmiques et le profil de charge seront pris en compte, mais tout le code sera ignoré quels que soient les résultats expérimentaux .

Convenez qu'il est faux d'évaluer le code qui ferme toutes ces tâches sur les mêmes modèles. Mais après tout, un bon programmeur dans le développement de produits devrait souvent résoudre efficacement tous les problèmes ci-dessus. La pratique montre que l'efficacité d'un programmeur dans tous ces cas est plus facile à déterminer par des questions de cas et une discussion de l'expérience qu'en examinant du code écrit avec des variables inconnues de l'intervieweur. De plus, le code que l'interviewé veut montrer! = Le code qu'il écrit tout en résolvant les problèmes de l'entreprise.

Le triomphe d'une connaissance sans valeur

Excellente compréhension de l'indignation associée à

Et le fait que la recherche d'index B-tree dans PostgreSQL ait une complexité logarithmique? J'ai découvert hier, et maintenant vous êtes

Mais quoi d'autre? Les bugs liés à la complexité algorithmique sont parmi les plus désagréables pour une entreprise. Ils ne sont pas couverts par les tests unitaires (O (N ^ 2) lors d'un test, où N = 10, c'est vraiment rapide), ils ne sont pas couverts par les tests automatiques, d'intégration, de régression et manuels pour la même raison. Ils n'apparaissent pas sur dbe, uat, sit (après tout, pour N = 1000 c'est toujours rapide). Ils peuvent attendre des années, sans se souvenir, jusqu'à ce qu'un client ajoute 250 produits à son panier, ou jusqu'à ce qu'un client d'une société de courtage apparaisse qui décide d'assembler un robot HFT sur son genou. Mais, lorsqu'ils apparaissent, toute l'entreprise peut tomber malade.


Cela comprend également des questions sur ACID. Bugs liés au blocage dans le SGBD, à la condition de concurrence, aux transactions dans le SGBD - c'est aussi la pâte à papier pour les entreprises. Ils, tout comme les bugs liés à la complexité algorithmique, peuvent rester silencieux pendant des années et frapper très douloureusement. Lorsque le principal SGBD opérationnel d'une entreprise, déployé sur un serveur monstrueux avec la redondance maximale pour tout, s'arrête simplement avec une charge nulle sur le processeur et les E / S au moment de l'activité maximale du client, croyez-moi, c'est extrêmement désagréable et, oui, cela peut coûter le salaire annuel d'une équipe de programmeurs. Par conséquent, vous n'avez pas besoin de connaître chaque lettre ACID par cœur (au moins, je ne demande jamais de connaître les abréviations de déchiffrement et je ne m'en souviens pas par cœur moi-même), mais l'ignorance de l'essence de chaque lettre est déjà une application sérieuse pour introduire de tels bogues dans le code. S'il y a deux programmeurs avec une telle ignorance dans l'équipe, la révision du code ne sera pas non plus un remède.

Te renverser

Et voilà. Et les gars semblent convenir. Fig comprendre. Et puis vous voyez que la vacance est ouverte six mois. Et bien.

Le fait qu'une offre d'emploi soit disponible sur le site Web de l'entreprise (ou sur l'agrégateur d'emplois) ne signifie pas que l'entreprise recherche une personne dans une équipe. La réalité des entreprises alimentaires pendant la croissance est une grève de la faim éternelle. Ou vous évoluez, conquérir le marché, évincer les concurrents ou mourir. Et le chef de produit a un mal de tête éternel - «que jeter». Non pas «pourquoi pensez-vous à un logiciel sympa pour que 100 programmeurs puissent télécharger pendant un mois, afin que vous ne vous ennuyiez pas», mais que vous devez éliminer les clients sympas, nécessaires, planifiés et attendus (et promis) des plans afin de ne pas retarder la prochaine version d'un an. Par conséquent, il n'y a pas de mains supplémentaires, et le fait que le poste soit suspendu depuis six mois n'annule pas le fait que 10 personnes ont déjà trouvé et embauché pour cela, et ils prendront la même chose avec plaisir. Encore une fois, pas partout et pas toujours, mais la situation que j'ai décrite est normale et acceptable pour le développement de produits.

Je me fiche des projets passés

Je demande toujours. Donc, ici, je suis entièrement d'accord avec l'auteur. Mais le point de vue de certains qui ne demandent pas est clair pour moi aussi. Ces personnes ne comprennent souvent pas comment comparer les différentes expériences des différents candidats entre elles. Les réponses aux questions fermées sont plus faciles à comparer.

Développeurs expérimentés

Il y a un point important. Cela, oui, un développeur expérimenté et vif s'y plonge rapidement. Mais si une personne prétend avoir beaucoup travaillé avec OAuth conditionnel sur plusieurs projets (c'est important, juste comme ça, et pas "utilisé une fois dans le prototype"), et l'intervieweur a également travaillé avec OAuth, alors pourquoi ne pas demander autour de vous? La profondeur des réponses montrera à quel point une personne se plongera profondément dans les nouvelles technologies rencontrées sur le chemin, qu'elle comprenne les principes du compartiment moteur, ou copie avec SO, qu'elle essaie d'anticiper un rake.

Quelques réflexions supplémentaires

Mais ici, vous pouvez sortir, donner un petit test pendant une heure ou deux (tout simplement pas en place: pour beaucoup, l'entretien est encore stressant).

Il peut y avoir différentes pensées à ce sujet, mais personnellement, je trouve la tâche de test offensante même pour le niveau intermédiaire. La tâche de test est tout de même une très forte disproportion du temps passé par l'entreprise et le demandeur. Conditionnellement, le demandeur passe 3 heures à écrire un code + 5 de plus à lécher et à rechercher les meilleures pratiques dans Google, et un représentant de l'entreprise rend un verdict en 1 minute. Pour cela, le demandeur a besoin de motivation. Par conséquent, une bonne pratique, mais pas pour l'évaluation de programmeurs expérimentés et recherchés qui sont prêts à suivre sans test.

Et des réflexions sur un commentaire intéressant de loppi

Et s'il y a un problème pour lequel je ne connais pas la solution tout de suite - vous pouvez toujours étudier le problème et trouver cette solution.

Il est important pour l'intervieweur non seulement le fait que le demandeur étudiera le problème et trouvera une solution. Il est important de savoir comment il procédera - s'il considérera toutes les options ou trouvera la première qui se présente, comment il réagira à la collision avec le fait que la solution choisie n'est pas valide, et nous devons en chercher une nouvelle, etc. Il peut y avoir des attentes différentes selon les circonstances.

Une seule entrevue s'est démarquée radicalement de la foule, la conversation s'est déroulée en face à face avec le directeur technique, il a demandé avec quelles technologies je travaillais, puis nous avons parlé de divers problèmes sur leur projet et sur mes projets passés, et comment ces problèmes ont été résolus ou peuvent être résolus décider.

Oui, une excellente façon d'interviewer (je pense et l'utilise moi-même), qui complète bien d'autres questions. Et, étrangement, il y a un énorme% de développeurs seniors qui connaissent très bien la théorie et ont de nombreuses années d'expérience réelle, mais en même temps, ils se montrent très mal lorsqu'ils essaient de résoudre un problème avec un grand nombre de degrés de liberté. Parmi les inconvénients de cette méthode d'entrevue, celle-ci nécessite une longue préparation (vous devez extraire l'essence des cas réels, en omettant les détails inutiles et en résumant) et peut être inefficace si les principaux défis du demandeur et de l'intervieweur étaient spécifiques.