Was ist ich in ACID oder einer anderen Perspektive

Nachdem ich diesen Beitrag von farwayer gelesen hatte , wollte ich zunächst nur einen Kommentar hinterlassen, aber nachdem ich ein paar Dutzend Minuten nachgedacht hatte, entschied ich, dass das Thema tiefgründig ist, und ich habe etwas für den gesamten Beitrag zu sagen. Einerseits bin ich einer von denen, die sich den Code bei Interviews nicht ansehen und die enttäuscht sind über die mangelnde Kenntnis der Komplexität der Indexsuche in relationalen DBMS. Andererseits glaube ich, dass ich ein Verständnis dafür vermitteln kann, wie ein ziemlich großer Cluster von Interviewern denkt, warum sie (auf den ersten Blick) unlogisch und destruktiv sind und welche Probleme sie selbst lösen wollen. Es bleibt zu hoffen, dass das Verständnis des Weltbildes vom „Feind“ selbst viele Fragen beantworten wird.

Zunächst erzähle ich Ihnen etwas über mich. Ich hoffe, dies hilft Ihnen dabei, die folgenden Informationen besser zu verstehen. In der Softwareentwicklung arbeitete er 9 Jahre lang für sich selbst (erstellte Börsenroboter und handelte mit seinem eigenen Geld), die meiste Zeit war er ein angestellter Entwickler (einschließlich leitender Entwickler). Vor kurzem war ich im Supermarkt. Sammelte 2 hochrangige Teams. Er führte mehrere Dutzend (wenn auch weniger als 100) technische Interviews auf den Positionen von middle2s Senior, Senior, Lead. Ich habe 18 Tage lang keinen Tag in meinem Leben im Outsourcing gearbeitet. Daher kann ich sagen, dass alle Erfahrungen mit dem Produkt verbunden sind (das eigene oder das des Arbeitgebers), und alle Interviews wurden mit der Motivation durchgeführt, „die Person zu finden, die den maximalen Nutzen für das Produkt bringt“. Ich gebe zu, dass die Erfahrung des Autors mit dem Originalartikel mehr als meine ist, aber das Ziel ist es nicht, Ihnen zu sagen, wie Sie es richtig machen oder wie Sie handeln sollen, sondern zu sagen, wie Sie dieselben Dinge von einer anderen Alternative aus betrachten können und nicht, dass sie richtig sind. Sicht.

Gehen wir zu den Punkten über (die Namen stammen aus dem ursprünglichen Beitrag).

Niemand kümmert sich um Ihren Code

Zunächst stellt sich die Frage, was guter Code ist und welche Erwartungen ein erfahrener Programmierer an den Code stellt. Ein guter Code ist für mich eine Funktion der Aufgabe, der Bedingungen, unter denen diese Aufgabe gestellt ist, der im Team (Unternehmen) verabschiedeten Richtlinien, der Erwartungen des technischen Managers (Architekten), des Produktmanagers, des QS-Leiters. Betrachten Sie beispielsweise mehrere Aufgaben:

1. Um eine API für die spätere Ausgabe an alle fünfhundert B2B-Kunden des Unternehmens zu entwickeln, um das Produkt in ihre Lösungen zu integrieren, wird eine durchdachte und gut dokumentierte Lösung mit der verständlichsten Struktur, Einhaltung der auf dem Markt akzeptierten Standards, strengster Datenvalidierung, vollständiger Testabdeckung, Erweiterbarkeit, durchdachter Protokollierung, Einhaltung aller Sicherheitsanforderungen, Skalierbarkeit der Leistung, Beständigkeit gegenüber mindestens einfachen DoS- und DDoS-Beispielen ;
2. Um die Konformität des Produkts mit den Anforderungen der Aufsichtsbehörde umzusetzen, die in einem Monat wirksam wird und zur Schließung des gesamten Geschäfts führen kann, wird eine zuverlässige Lösung mit Schwerpunkt auf Tests erwartet .
3. Beheben Sie einen Fehler im Zusammenhang mit Caching, der eine Stunde vor Black Friday bekannt wurde. Es wird erwartet, dass die Lösung in 30 Minuten auf dem Produkt geschrieben und bereitgestellt wird und nichts kaputt macht. Andere Anforderungen bleiben auf der Strecke ;
4. Testen Sie die Hypothese, für die ein einmaliger Sparring von 250 Seiten der Website eines Konkurrenten erforderlich ist, und erstellen Sie dann basierend auf diesen Informationen ein Dokument für eine Google-Tabelle für einen Geschäftsanalysten. Es wird erwartet, dass der Programmierer nicht zu viel Arbeit leistet und nur schreibbaren Code schreibt , ohne viel dafür auszugeben Zeit ;
5. Um die Leistung von Aerospike für eine Aufgabe zu überprüfen, für die PostgreSQL traditionell im Unternehmen verwendet wird, und um Leistungsprobleme zu vermeiden, wird erwartet, dass die algorithmischen Nuancen und das Lastprofil berücksichtigt werden, der gesamte Code wird jedoch unabhängig von den experimentellen Ergebnissen verworfen .

Stimmen Sie zu, dass es falsch ist, den Code zu bewerten, der alle diese Tasks nach denselben Mustern abschließt. Schließlich wird oft erwartet, dass ein guter Programmierer in der Produktentwicklung alle oben genannten Probleme effektiv löst. Die Praxis zeigt, dass die Effektivität eines Programmierers in all diesen Fällen durch Fallfragen und Erfahrungsdiskussionen leichter zu bestimmen ist als durch die Prüfung von Code, der mit Variablen geschrieben wurde, die dem Interviewer unbekannt sind. Plus, der Code, den der Befragte zeigen möchte! = Der Code, den er beim Lösen von geschäftlichen Problemen schreibt.

Der Triumph wertlosen Wissens

Ausgezeichnetes Verständnis der Empörung, die damit verbunden ist

Und die Tatsache, dass die Suche in B-Tree-Indizes in PostgreSQL logarithmisch komplex ist? Ich habe es gestern herausgefunden und jetzt bist du es

Aber was ist auf der anderen Seite? Fehler, die sich auf die algorithmische Komplexität beziehen, gehören zu den unangenehmsten für ein Unternehmen. Sie werden aus dem gleichen Grund nicht durch Unit-Tests (O (N ^ 2) während eines Testlaufs, wobei N = 10 ist, dies ist sehr schnell) abgedeckt. Sie werden nicht durch automatische, Integrations-, Regressions- und manuelle Tests abgedeckt. Sie tauchen nicht auf, sitzen, sitzen (immerhin ist es für N = 1000 immer noch schnell). Sie können Jahre auf ihre Zeit warten, ohne sich zu erinnern, bis ein Kunde 250 Produkte in den Warenkorb legt oder bis ein Kunde eines Maklerunternehmens auftaucht, der sich entscheidet, einen HFT-Roboter auf sein Knie zu montieren. Aber wenn sie auftauchen, kann das ganze Geschäft krank werden.


Dies schließt auch Fragen zu ACID ein. Fehler im Zusammenhang mit Blockierung im DBMS, Race Condition, Transaktionen im DBMS - das ist auch der Brei für das Geschäft. Sie können, genau wie Fehler im Zusammenhang mit der algorithmischen Komplexität, jahrelang still sitzen und sehr schmerzhaft schlagen. Wenn das Hauptbetriebs-DBMS eines Unternehmens, das auf einem monströsen Server mit maximaler Redundanz für alles bereitgestellt wird, bei maximaler Client-Aktivität ohne CPU- und E / A-Belastung stoppt, ist dies äußerst unangenehm und kann das Jahresgehalt eines Teams von Programmierern kosten. Daher müssen Sie nicht jeden ACID-Buchstaben auswendig kennen (zumindest frage ich nie nach Kenntnissen über die Entzifferung von Abkürzungen und erinnere mich nicht auswendig an diese), aber die Unkenntnis des Wesens jedes Buchstabens ist eine ernsthafte Anwendung, um solche Fehler in den Code einzufügen. Wenn es zwei Programmierer mit derartiger Ignoranz im Team gibt, ist die Codeüberprüfung ebenfalls kein Heilmittel.

Schlage dich nieder

Und hier ist es. Und die Jungs scheinen angemessen zu sein. Feigen verstehen. Und dann sehen Sie, dass die Stelle ein halbes Jahr offen ist. Na ja

Die Tatsache, dass eine freie Stelle auf der Website des Unternehmens (oder im Jobaggregator) verfügbar ist, bedeutet nicht, dass das Unternehmen eine Person in einem Team sucht. Die Realität der Lebensmittelunternehmen während des Wachstums ist ein ewiger Hungerstreik. Oder Sie skalieren, erobern den Markt, verdrängen Konkurrenten oder sterben. Und der Produktmanager hat ewige Kopfschmerzen - „was rausschmeißen“. Nicht "warum sollten Sie sich so ein cooles ausdenken, damit 100 Programmierer einen Monat lang herunterladen können, damit Sie sich nicht langweilen", sondern dass Sie die coolen, notwendigen, geplanten und erwarteten (und versprochenen) Kunden aus ihren Plänen werfen sollten, um die nächste Veröffentlichung nicht um ein Jahr zu verzögern. Daher gibt es keine zusätzlichen Hände, und die Tatsache, dass die Stelle seit sechs Monaten nicht mehr besetzt ist, hebt die Tatsache nicht auf, dass bereits 10 Personen dafür gesucht und eingestellt haben, und sie werden diese gerne annehmen. Auch hier nicht überall und nicht immer, aber die von mir beschriebene Situation ist normal und für die Produktentwicklung akzeptabel.

Vergangene Projekte interessieren mich nicht

Ich frage immer. Hier stimme ich dem Autor voll und ganz zu. Aber die Sichtweise einiger, die nicht fragen, ist mir auch klar. Diese Menschen verstehen es oft nicht, die unterschiedlichen Erfahrungen verschiedener Kandidaten miteinander zu vergleichen. Antworten auf geschlossene Fragen lassen sich leichter vergleichen.

Erfahrene Entwickler

Es gibt einen wichtigen Punkt. Das, ja, ein erfahrener und schlagfertiger Entwickler vertieft sich schnell. Aber wenn jemand behauptet, er habe viel mit bedingtem OAuth an mehreren Projekten gearbeitet (es ist wichtig, einfach so und nicht "einmal im Prototyp verwendet"), und der Interviewer auch mit OAuth gearbeitet hat, warum dann nicht nachfragen? Die Tiefe der Antworten zeigt, wie tief ein Mensch in neue Technologien eintauchen wird, ob er die Prinzipien des Motorraums versteht oder mit SO kopiert, ob er versucht, einen Schwader zu antizipieren.

Noch ein paar Gedanken

Aber hier können Sie aussteigen und ein oder zwei Stunden lang einen kleinen Test machen (nur nicht an Ort und Stelle: Für viele ist das Interview immer noch Stress).

Es mag unterschiedliche Gedanken zu diesem Thema geben, aber ich persönlich finde die Testaufgabe selbst für die mittlere Ebene beleidigend. Trotzdem ist die Testaufgabe ein sehr starkes Missverhältnis in der Zeit, die das Unternehmen und der Antragsteller verbringen. Unter der Bedingung, dass der Bewerber 3 Stunden lang einen Code + 5 Stunden mehr für das Lecken und Suchen nach Best Practices in Google schreibt, gibt ein Unternehmensvertreter in 1 Minute ein Urteil ab. Dafür braucht der Bewerber Motivation. Daher gute Praxis, aber nicht für die Bewertung von erfahrenen und gefragten Programmierern, die bereit sind, ohne einen Test zu nehmen.

Und Gedanken zu einem interessanten Kommentar von loppi

Und wenn es ein Problem gibt, für das ich die Lösung nicht sofort kenne, können Sie das Problem jederzeit untersuchen und diese Lösung finden.

Für den Interviewer ist es nicht nur wichtig, dass der Antragsteller das Problem untersucht und eine Lösung findet. Es ist wichtig, wie er dies tun wird - ob er alle Optionen in Betracht zieht oder die erste findet, die auftaucht, wie er auf die Kollision mit der Tatsache reagiert, dass die gewählte Lösung nicht gültig ist, und wir müssen nach einer neuen suchen und so weiter. Es kann unterschiedliche Erwartungen für unterschiedliche Umstände geben.

Nur ein Interview stach radikal aus der Masse heraus, das Gespräch wurde direkt mit dem technischen Direktor geführt, er fragte, mit welchen Technologien ich gearbeitet habe, und dann sprachen wir über verschiedene Probleme bei ihrem Projekt und meinen vergangenen Projekten und wie diese Probleme gelöst wurden oder können zu entscheiden.

Ja, eine großartige Art zu interviewen (ich denke und benutze sie selbst), die andere Themen gut ergänzt. Und seltsamerweise gibt es sehr viele hochrangige Entwickler, die die Theorie sehr gut kennen und über viele Jahre echte Erfahrung verfügen, sich aber gleichzeitig sehr schlecht zeigen, wenn sie versuchen, ein Problem mit einer großen Anzahl von Freiheitsgraden zu lösen. Die Nachteile dieser Befragungsmethode bestehen darin, dass sie langwierig vorbereitet werden muss (Sie müssen das Wesentliche aus realen Fällen extrahieren, unnötige Details weglassen und zusammenfassen) und ineffektiv sein können, wenn die zentralen Herausforderungen sowohl des Antragstellers als auch des Interviewers spezifisch waren.