Senior Engineer auf der Suche nach Arbeit. Über Aufgaben bei technischen Interviews und theoretischen Fragen

Wir sprechen weiterhin über technische Interviews (wenn Sie nicht gelesen haben, lesen Sie die vorherigen Artikel in der Reihe - über Interviews mit HR und Technik ). Dieses Mal gibt es mehr subjektive Erfahrungen, ein Minimum an Tipps sowie ein wenig über Testaufgaben und theoretische Fragen. Lass uns gehen.

Haftungsausschluss: Der Autor ist kein Turboentwickler, sondern ein normaler Web-Makaken ohne Beschwerden. Daher können die oben genannten Aufgaben und Lösungen dazu führen, dass Sie lächeln, sich anstrengen und dem Autor seine Inkompetenz anzeigen möchten. Ich freue mich darauf, Sie in den Kommentaren zu sehen! :) :)

Diskussion abgeschlossener Testobjekte

Im letzten Teil habe ich beschrieben, wie ich zwei Testaufgaben ausgeführt habe: die erste in DevOps Engineer und die zweite in Ruby Developer. Ich werde Ihnen sagen, was als nächstes passiert ist.

Interview bei Ruby Developer - der Interviewer hat sich meinen Test nicht einmal angesehen, ihm keine Fragen gestellt, kein Kompliment gemacht (ich habe die Aufgabe besser erledigt als alle vorherigen Kandidaten, zumindest hat mir der Personalvermittler geschmeichelt). Es scheint, dass er nicht einmal von ihm wusste. Das hat mich ein wenig verärgert, denn dann haben sie angefangen, mich nach der Theorie zu fragen, und infolgedessen haben sie sich durch die Theorie geweigert.

Interview mit DevOps Engineer - Der Interviewer sah sich die Aufgabe an, machte ein Kompliment (sagte, ich hätte sie qualitativ abgeschlossen) und stellte einige Kontrollfragen zur Lösung: Warum steht diese Zeile hier? Wenn Sie die Bedingung durch diese ersetzen, in welcher Datei müssen Sie dies tun? Warum wird dieser Ansatz hier verwendet? usw. Wie mir der Personalvermittler sagte, haben einige Kandidaten keine eigenen Aufgaben erledigt und konnten solche Fragen nicht beantworten. Deshalb habe ich es hier ohne Probleme geschafft.

Im ersten Fall habe ich den Befragten nicht gefragt, ob er meine Testaufgabe überhaupt gesehen hat und was er darüber denkt. Aber es war notwendig! Wenn Sie eine solche Situation haben, teilen Sie dies Ihren Befragten unbedingt mit.

Interviewaufgaben

Wir setzen das Thema Testaufgaben aus dem vorherigen Teil fort und betrachten die Aufgaben der Codierung bei Interviews.

Es gibt verschiedene Arten von Aufgaben: Implementieren eines Algorithmus, Schreiben einer Lösung in Pseudocode, Refaktorieren von Elementen usw. Unsere Ingenieure lieben algorithmische Probleme am meisten.

Viele Menschen, einschließlich mir, glauben, dass diese Aufgaben nur die Fähigkeit des Bewerbers zeigen, genau solche Probleme zu lösen, und überhaupt nicht zeigen, wie er mit echten Arbeitsaufgaben umgehen wird, die in der Regel auf höherer Ebene liegen. Warum geben sie sie immer noch? Ich denke, der Grund ist einfach: Interviewer können sich einfach nichts Besseres einfallen lassen. Und da wir uns nichts Besseres einfallen lassen können, nehmen wir die guten alten Zeilenumkehrungen, sortieren, balancieren Bäume und vieles mehr.

Als Tools, die für die Lösung verwendet werden, ist der Code-Editor + Repl + die Möglichkeit der Zusammenarbeit am besten geeignet. Von allen Optionen auf dem Markt mag ich CoderPad am meisten . Es wird ein Raum erstellt, in dem Sie und die Interviewer eine Verbindung herstellen. Sie können Code gemeinsam bearbeiten, ausführen und die Ergebnisse der Ausführung anzeigen. Sehr bequem. Wenn es kein Geld für ein Codepad gibt, geht repl.it in den Kampf und die Bildschirmfreigabe ist im Grunde die gleiche, nur ohne die Möglichkeit einer Zusammenarbeit.

Aktualisieren: Während der Übersetzung des Artikels hat repl.it den Mehrspielermodus hinzugefügt, der es einer unbegrenzten Anzahl von Teilnehmern ermöglicht, gleichzeitig mit dem Code zu arbeiten. Völlig kostenlos! CoderPad wird nicht mehr benötigt, Prost!

Ich hatte ein Interview mit dem Unternehmen für die Position des Java-Entwicklers . Das Unternehmen macht so etwas wie CRM und schreibt eine Reihe von Integrationen. Ich habe einen technischen Spezialisten von Zoom kontaktiert und er sagt: "Beginnen wir mit dem algorithmischen Problem." Ich antworte: "Ok, ich werde die Aufgabe erledigen, aber ich habe eine Frage: Benötigen Sie dieses Wissen in Ihrer Arbeit, müssen Sie ähnliche Dinge lösen?" Darauf bekomme ich eine phänomenale Antwort: "Wir schreiben Ruheendpunkte und fahren json-chiki hin und her, aber es ist nicht interessant, darüber zu sprechen , also lassen Sie uns das Problem lösen." Das heißt, der Interviewer selbst gab seine Inkompetenz zu. Ich weiß nicht wer wie, aber von diesem Moment an wurde mir klar, dass ich dort nichts zu fangen hätte. Aus sportlichem Interesse wurde das Gespräch jedoch fortgesetzt.

Wir öffneten den Codierungsblock und gingen zu der Aufgabe über, deren Bedingung ich mündlich geäußert hatte: "Finden Sie die längste Folge eindeutiger Zeichen in einer bestimmten Zeichenfolge." Danach sagte der Interviewer, dass "man eine Aufgabe für die dynamische Programmierung geben könnte , aber wir werden uns auf eine einfachere Option beschränken." Ich möchte die Person, die bei Interviews die Aufgabe der dynamischen Programmierung übernehmen wird, ernsthaft betrachten.

Ich wiederholte dem Interviewer die Bedingungen der Aufgabe, um sicherzustellen, dass ich sie richtig verstand. Darauf erhielt ich eine positive Antwort und begann zu arbeiten. Nach 5 Minuten stellte sich heraus, dass ich das Problem trotzdem falsch verstanden hatte, da nicht ein Teilstring, sondern dessen Länge gefunden werden musste (dies ist einfacher). Ich antwortete jedoch: "Nun, seit sie angefangen haben, lösen wir das Problem mit einem Sternchen und nicht mit einem einfachen." Der Interviewer war ein wenig verwirrt, weil er die Tests speziell für seine Bedingungen vorbereitet hatte, aber ich entschied bereits, dass ich den nicht zurückgeben würde und versuchen würde, es so zu machen, wie es ist. Ich fragte, wie viel Zeit ich habe (ungefähr 40 Minuten) und fing an zu programmieren. Ich stelle fest, dass ich mich trotz der Tatsache, dass ich wusste, dass sie Aufträge vergeben würden, nicht speziell vorbereitet habe.

Also schrieb ich sofort Tests und begann mit i-, j- und k-Indizes zu schamanisieren :) Loops in Loops und so weiter. Nach 15 bis 20 Minuten hatte ich eine halbwegs funktionierende Lösung, aber die Grenzfälle, die der Interviewer gab, gingen nicht durch. Weitere 20 Minuten haben sie gebraucht, am Ende habe ich die Aufgabe immer noch richtig erledigt. Der Interviewer schien zufrieden zu sein und fragte mich dann nach Datenstrukturen. Es stellte sich heraus, dass es zur Lösung des Problems, das er ursprünglich geben wollte, möglich sein würde, einen Hash oder ähnliches zu verwenden, und er erwartete eine solche Lösung, aber ich habe alles gebrochen.

Dann haben wir ein wenig über das Projekt gesprochen (Formen und Stapel). Und dann sagt er: „Danach wird es ein Interview über das Systemdesign geben. Im Allgemeinen sehe ich keinen Grund, dies durchzuführen, da wir dies hier nicht tun und kein solches Wissen benötigen, aber Ordnung ist Ordnung, also ist der nächste Schritt dies. " Nun, Sie verstehen - zwei (!) Interviews werden durchgeführt, um zu verstehen, ob der Kandidat Dinge tun kann, die in der täglichen Arbeit in diesem Unternehmen nicht benötigt werden. Dann erlaubte ich mir, ein wenig über die Sinnlosigkeit solcher Interviews zu sprechen. Der Interviewer stimmte mir zu, schloss aber erneut die Delegation der Verantwortung ein und sagte: "Ich entscheide nicht, wie der Prozess ablaufen soll, also tun wir, was wir tun." Ich werde hinzufügen, dass ich das zweite Interview (über Systemdesign) durchlaufen habe und es genauso bedeutungslos war wie das erste.

Was für ein Fehler der Interviewer gemacht hat - er hat die Bedingungen der Aufgabe im Text nicht festgelegt. Bei solchen Interviews habe ich einfach die Bedingungen der Aufgabe in den Code-Editor kopiert, damit der Kandidat keine Fragen hat.

Welchen Fehler ich gemacht habe - ich beeilte mich sofort, den Code zu schreiben, ohne dreimal anzugeben, ob ich den Zustand richtig verstanden habe. Wenn Sie bei Interviews solche Aufgaben erhalten, trennen Sie sich sofort vom Chat und finden Sie eine interessantere Lektion. Überprüfen Sie mehrmals, ob Sie den Zustand richtig verstanden haben, schreiben Sie einen Test in den Editor und lassen Sie sich vom Interviewer bestätigen, dass alles korrekt ist.

Ich hatte auch ein Interview für die Position von Ruby Developer . Nachdem ich Fragen beantwortet und standardmäßig beantwortet hatte, wurde mir die Aufgabe übertragen, die Methode each_slice zu schreiben. Für diejenigen, die es nicht wissen, ist dies eine Sache, die ein Array von Subarrays einer bestimmten Größe trifft und für jedes von ihnen einen Block ausführt, den wir an die Methode übergeben haben, oder einen Iterator über diese Subarrays zurückgibt. Ich setzte mich zum Schreiben hin und schaltete dann das Tuping ein. Das Problem ist, dass ich unter Ruby einige Zeit erfolgreich nur mit Web-Macing beschäftigt war und als Referenz-Whitelist einige der grundlegenden Sprachkonstrukte nicht kannte. Ich wusste nämlich nicht, dass der Index in der for-Schleife unveränderlich ist (im Gegensatz zu beispielsweise Java).

Ich habe die Methode selbst mehr oder weniger schnell geschrieben, aber sie hat nicht funktioniert, und ich konnte nicht verstehen, warum. Ich geriet etwas in Panik, löschte alles und schrieb erneut, aber mein Code funktionierte wieder nicht so, wie er sollte.
"Es ist nicht gelaufen", dachte ich und sagte zu meinen Gesprächspartnern: "Leute, weißt du, ich bin gut im Webhosting und bei der Durchführung von Projekten, aber ich habe keinen Erfolg mit deinen dummen Aufgaben. Ich verstehe, dass dies eine einfache Aufgabe ist und eine Person mit 10 Jahren Erfahrung einfach verpflichtet ist, sie schnell zu erledigen. Also lass mich dich nicht länger aufhalten, und wir werden uns zerstreuen. “ Die Jungs stimmten zu und trennten sich.

Ich wurde ernsthaft bombardiert, weil ich es nicht gewohnt war, so leicht zu verlieren. Um irgendwie in ein existenzielles Plus zu geraten, schrieb ich an einen Personalvermittler, dass ich eine Aufgabe, die nicht mit wirklicher Arbeit zu tun hat, aufgeschlüsselt hatte. Dann beruhigte er sich, setzte sich und testete schnell, wie Indizes in Zyklen funktionieren. Mir wurde klar, dass ich einen Junior-Fehler gemacht, den Index überarbeitet und eine vorgefertigte Lösung gefunden hatte. Tatsächlich war der Fehler, den ich hatte, in derselben Zeile. Ich erzählte HR davon und schlug vor, dass sie den Link zur Lösung an die Jungs weitergibt, wenn sie interessiert sind, weil ich das Problem immer noch gelöst habe. Aber sie antwortete: "Sie sind nicht weiter gegangen, weil Sie das Problem nicht gelöst haben, auf Wiedersehen ." Ich habe immer noch ein wenig über die unterbrochenen Interviewprozesse verstanden, um uns irgendwie zu rechtfertigen, und wir haben uns getrennt.

Danach überlegte ich mir meine Einstellung zu solchen Aufgaben. Normalerweise war es für mich nie ein Problem, etwas unter Aufsicht zu codieren, aber hier wirkten mehrere Faktoren: meine Bewerbung für eine ernsthafte Position, mangelndes Verständnis der Grundkonstruktionen der Sprache (obwohl ich sie nie brauchte, und wenn ich es wäre, könnte ich die Lösung googeln in 5 Sekunden) und die Wirkung des Beobachters. Natürlich habe ich gelesen, dass viele Leute Probleme nicht lösen können, wenn sie sie anschauen, aber es schien mir immer, dass dies eine Entschuldigung für meine eigene Unsicherheit und Inkompetenz war, bis ich selbst mit jeder Scheibe auf diese harten Typen stieß.

Ich hatte auch ein Interview für die Position des Java-Entwicklers. Diesmal wurde es in einem etwas anderen Format gehalten. Wir wurden von Zoom kontaktiert und der Interviewer sagte: „Sagen Sie mir Ihre E-Mail, ich werde Ihnen eine Aufgabe senden, sie lesen und mir sagen, ob alles klar ist. Sie haben zwei Stunden Zeit, ich bin stumm geschaltet und ich werde nicht sehen, was Sie dort tun (wir spielen nicht mit dem Bildschirm). Zwei Stunden später melden wir uns, fummeln am Bildschirm herum und sehen, was Sie dort gemacht haben. Du kannst alles benutzen. “ Ich las die Bedingungen der Aufgabe, sprach sie erneut mit dem Interviewer, schaltete das Video aus (weil die Codierung des Streams die CPU frisst) und wurde verwirrt. Öffnete die IDE und startete.

Die Aufgabe bezog sich auf E / A - es war erforderlich, eine API zum Schreiben von Daten in eine Datei auf der Festplatte zu erstellen, damit alles threadsicher und schnell war, und auch Komponententests zu schreiben, die dies überprüfen (einschließlich Thread-Sicherheit). Ich habe lange Zeit nicht mehr mit Parallelität und E / A gearbeitet, daher musste ich schnell über die Docks gehen und mich daran erinnern, was passiert war. Ich schrieb eine Lösung in die Stirn, überprüfte, ob sie fadensicher ist und so weiter. Alles an allem dauerte ungefähr anderthalb Stunden. Ich pingte meinen Interviewer an und sagte, ich sei bereit, aber es gab nur eine Kleinigkeit zu polieren. Werden wir schauen? Darauf antwortete er: "Lass uns noch eine halbe Stunde sitzen und alles erledigen, was du noch nicht erledigt hast." Ok, ich setzte mich und erinnerte mich an all die kleinen Dinge und die Rauheit, ich beendete den Javadki, las noch einmal alles, was ich über I / O konnte und dachte, was die Nachteile meiner Lösung sein könnten.

Nach einer halben Stunde meldeten wir uns, ich teilte den Bildschirm, zeigte den Code, führte die Tests durch und so weiter. In der nächsten halben Stunde sprachen wir streng über die Lösung des Problems und mögliche Optionen für seine Änderung, wenn bestimmte Bedingungen geändert wurden. Ich möchte darauf aufmerksam machen, dass in früheren Interviews (und auch in nachfolgenden) niemand die Grundlage für die Konversation nach Aufgaben vorbereitet hat. Es war immer nur eine Art abstraktes Stück, das bei der Ausgabe 0/1 ergab, und wir gingen zur nächsten Frage über. Und hier war die Aufgabe so einfach, dass sie in ein paar Stunden erledigt werden konnte, aber gleichzeitig gründlich genug, um Bedingungen hinzuzufügen und mit dem Kandidaten zu besprechen, wie er die Entscheidung abschließen würde.

Dieses Interview hat mir sehr gut gefallen. Ich konnte zeigen, dass nicht nur Fizz Buzz lösen, sondern auch etwas in Architekturen verstehen kann. Der Interviewer war überzeugt, dass er nicht im Juni saß, sondern ein Spezialist, der etwas in seiner Arbeit fotografiert. Es war das beste technische Interview, das ich je hatte. Ich denke, Sie haben bereits vermutet, dass der Interviewer nicht einer von uns war :) Ich werde auch hinzufügen, dass ich es erfolgreich bestanden habe, dann zwei weitere Stufen und schließlich ein Angebot erhalten habe. Aber das ist eine andere Geschichte.

Was war gut an dieser Aufgabe?

• Nähe zur realen Arbeit, zu dem, was sie in diesem Unternehmen tun.
• Zeitlimit.
• Fehlende Beobachtung.
• Die Fähigkeit, alles zu verwenden und keine Speicherprüfung.
• Grundlage für weitere Gespräche schaffen.
• Testen Sie die Fähigkeiten des Kandidaten zum Codieren, verwenden Sie die IDE und denken Sie allgemein.

Leider hatte ich von allen Interviews nur drei solcher Aufgaben, so dass die Auswahl gering ist. Vielleicht gibt es einige schwierigere Tests / Aufgaben, aber ich habe sie nicht bekommen.

Typische Mängel von Interviewaufgaben

1. Die Aufgabe hat nichts mit echter Arbeit zu tun. Es nervt mich am meisten. Algorithmen dürfen gelöst werden, obwohl die Pfähle in Wirklichkeit nieten. Lassen Sie uns die relevante Aufgabe, ich werde Ihnen eine grobe tun! Warum brauchen Sie eine Person, die weiß, wie man in Strings nach Teilzeichenfolgen sucht?
2. Organisatorisch - oft gibt es kein normales Werkzeug für eine Lösung. Sobald sie mir den Code in Google Docs zeigten, als ich den Bildschirm in repl.it fummelte, war einmal CoderPad.
3. Die Aufgabe schafft keinen Kontext für weitere Gespräche - dies ist eine Folge des ersten Absatzes. Warum eine Aufgabe geben, wenn wir sie später nicht besprechen?
4. Nicht alle Menschen können die Aufgabe unter Aufsicht bewältigen. Dementsprechend kann ein guter Kandidat in dieser Phase eliminiert werden.

Theoretische Fragen

Das ist mein Lieblingsteil. Jeder fragt gerne nach der Theorie, lassen Sie uns dies ein wenig durchgehen.

Aus irgendeinem Grund wurde ich vor allem an den Positionen des Ruby Engineer nach der Theorie gefragt. Ich kannte sie am schlimmsten, also füllte ich die Interviews ständig aus und sah aus wie ein Juni, bis mir klar wurde, dass es nicht mehr geeignet war, so weiterzumachen. Ich setzte mich und las ein Lehrbuch über die Sprache, das es mir ermöglichte, viel besser zu sprechen und ohne zu jammern. „Leute, warum fragst du mich das? Ich bin ein guter Entwickler. Was ist der Unterschied? Wie ist die Reihenfolge der Methodensuche für ein Objekt? Wer braucht das? "

Das erste Interview, zu dem ich als Ruby-Entwickler ging, war genau der Ort, an dem die Testaufgabe durchgeführt werden sollte. Wie sich jedoch herausstellte, war niemand interessiert. Timlid, der mit mir kommunizieren sollte, kam nicht (er steckte im Stau oder so), also gaben sie mir noch einen. Nach dem Treffen sagt er: "Ich habe eine Regel - ich führe alle Interviews auf Englisch, also wechseln wir zu Englisch." Und dann werden meine Ohren zu einer Graphen-Nanoröhre verdreht, weil der Interviewer einen sehr starken Akzent hat. Das hat mich etwas verunsichert (es ist sehr schwierig für mich, mit meinen Landsleuten auf Englisch zu kommunizieren).

Als nächstes kamen die Fragen: Was ist ein Modul, was ist ein Block, was ist Ausbeute, und ich begann zu archivieren. Anstatt "wie in einem Lehrbuch" zu definieren, fing ich an zu plappern: "Nun, ich kenne die genaue Definition nicht, aber wahrscheinlich ist das so, ich habe es so benutzt." Der Interviewer war unglücklich, ich begann es zu fühlen und dachte dann, dass alle angekommen waren.

Dann gab es Fragen zu bestimmten Methoden, nämlich: "Wie heißt die Methode, die alle Nullen in der Sammlung filtert?" Dann schaltete ich den Troll ein und antwortete: "Wenn Sie mein Gedächtnis auf Kenntnisse über diese Methoden überprüfen, kann ich Ihnen nichts darüber sagen, was ich in letzter Zeit nicht verwendet habe. Ich schreibe in vielen Sprachen und Plattformen und erinnere mich nicht an alle SDK-Methoden. " Dies befriedigte den Interviewer nicht und die nächste Frage lautete wie folgt: „Was ist aufzählbar? Welche Methoden gibt es und wer wird sie erweitern? “ "Onkel, hast du nicht verstanden?", Dachte ich mir, sagte aber laut: "Ich weiß es nicht genau, ich denke, es gibt einige Methoden wie Map / Reduce / Slice und so weiter." Es passte auch nicht zu ihm.

Dann stellte er mir eine Standardfrage, wo Logik in MVC platziert werden soll. Ich antwortete, dass im Modell, und wenn es nicht in das Modell passt, dann in einigen anderen Klassen. Es stellte sich heraus, dass die sogenannten Service-Objekte die richtige Antwort waren (ist dieser Müll auch hier?). Ich habe als Antwort etwas gemurmelt, wie man es so nennen kann, aber ich mag es nicht.

Dann stellte er die Standardfrage zu SQL, die ich bereits richtig beantworten konnte, und dann zu RSpec, das ich nicht verwendet habe, das ist alles. Auf Schienen (und sie hatten nur Schienen) erhielt ich keine einzige Frage. Außerdem habe ich keine einzige Frage zu meinen bisherigen Erfahrungen erhalten.

Danach fragte er mich, was ich von täglichen Stand-Ups halte. Dann entschied ich mich, die sozial erwarteten Antworten nicht zu geben (die Scheune brannte nieder - brennen und Hütte!) Und sagte sofort, dass dies Zeitverschwendung sei und in Teams praktiziert wurde, in denen der Manager keine Transparenz und einfache Berichterstattung über den Fortschritt gewährleisten konnte. Und er fügte hinzu, dass Scrum Müll in Pflanzenöl ist und normalerweise niemand nach dem Scrum arbeitet, aber jeder tut nur so. Offensichtlich habe ich immer noch die Nachteile gepackt.

Außerdem schlug er vor, ihm Fragen zu stellen (anscheinend aus Höflichkeit), und ich fragte auf eigene Faust nach dem Prozess, der Architektur und so weiter. Was ich gehört habe, hat mir nicht gefallen, weil sie für typische Aufgaben viel Rad gefahren sind. Ich wollte dem Mann klar machen, dass ich nicht nur ein Entwickler bin, sondern auch ein bisschen mehr, aber alles war vergebens, und bald sagte er, er müsse zur Rallye gehen und die Segel setzen.

Am nächsten Tag schrieb mir ein Personalvermittler und informierte mich über die Ablehnung. "Und Gott sei Dank", dachte ich, aber immer noch ein wenig verbrannt. Ich hatte den Eindruck, dass der Interviewer von Anfang an einige Vorurteile hatte, ich weiß es nicht. Übrigens war dies das gleiche Büro, das sich einen Monat vom ersten Kontakt bis zu einem technischen Interview hinzog.

Also lehnten sie mich ab, weil ich die Grundlagen der Sprache (Ruby) nicht kannte. Ok, lass uns weitermachen.

Ein weiteres Interview bei Ruby Debeloper , bereits zwei Interviewer . Es ist gut, dass mindestens einer auf Russisch gesprochen wird, der zweite auf Ukrainisch, sodass ich mir nicht das Gehirn brechen musste. Zu meiner Überraschung beginnt die gleiche Geschichte: Was sind Module, was sind Blöcke? Ich hatte das Lehrbuch noch nicht gelesen und schwamm erneut in den Antworten. Weiter gefragt nach den Arten von Assoziationen in Rails. «- -», — , . ( ), , : « ». , — each_slice. , , . : « , - Rack middleware?». , . , , ( Java Servlets, middleware - Laravel/Express), . , .

Auch hier interessierte sich weder meine Erfahrung noch mein Wissen beim Erstellen von Lösungen oder in verwandten Bereichen. Ich beschuldige diese Leute nicht. Vielleicht brauchen sie wirklich Programmierer, die gerade wissen, wie man Rack-Middleware schreibt, aber ich denke, dass sie tatsächlich einfach nicht wissen, wie man Interviews durchführt.

Nach zwei Fehlern wurde mir klar, dass dies nicht sein sollte und ich muss die Theorie lesen. Wenn Sie gefragt werden, müssen Sie es wissen. Niemand will glauben, dass ich ein guter Kerl bin und nur normale Aufgaben gebe, also setzte ich mich, las das Lehrbuch und ...

Ruby Developer. , . , , . Proc, , :) : « , , , - ». 100% , - , . .

: « require». Rails Grape, , , . « , ». , . - -, « , ?». ActiveRecord — , .

concurrency ( ). , concurrency Ruby — . , , . , MRI — JVM , volatile synchronized , . , , ( !) concurrency . ? ?

, - SOLID. , « — », . , . , . - , . , « ». .

? . , , , . , ! ( ). , , Cracking Ruby Interview, . , - «» , , , :)

.

Fullstack Java Developer. — . , . , , Java.

, , , - . , , , , . , , .

. . , , , undefined null, var. JS WAT-. : «, WAT . , , , ». , -. «JavaScript: The Good Parts», .

, , . (?) , ( , ) , . . , :)

- , , . jQuery, . :)

DevOps Engineer , . : « ?». - :) , , — . , . , , , . . ( )?

Ich war überrascht, dass sie überhaupt nicht mehr nach Designmustern fragten (mit Ausnahme von MVC). Insgesamt (ha ha) haben sie vor 5-10 Jahren buchstäblich bei jedem Interview das Wissen über Muster überprüft. Seitdem kenne ich fast alle (von GoF) als Andenken und kann sie auch auf einem Blatt Papier umsetzen. Aber dieses Jahr habe ich unter allen Interviews keine einzige Frage zu den Vorlagen erhalten. Ruby-Entwickler können wahrscheinlich immer noch verstanden werden - sie wissen wahrscheinlich nichts über sie (sie haben MVC und ActiveRecord und das ist genug). Aber das Fehlen solcher Fragen in Java-Interviews hat mich wirklich überrascht.

Es scheint, dass sie nur zweimal nach SOLID gefragt haben: einmal für die Ruby-Position, das zweite Mal in Java. Über DRY habe ich nicht gefragt :)

Welche Schlussfolgerungen können daraus gezogen werden?

1. Sie fragen immer noch gerne nach der Theorie, besonders nach unseren Landsleuten.
2. Die Kenntnis der Theorie garantiert keine Kenntnis der Praxis, daher fügen sie der Theorie gerne Aufgaben hinzu.
3. Die Fähigkeit, Fragen zu beantworten oder ein Problem zu lösen, garantiert nicht, dass eine Person programmieren kann.
4. Das Ignorieren einer Theorie oder einer Datei mit Problemlösungen bedeutet nicht, dass Sie einen schlechten Entwickler haben.

Deshalb, egal wie bedeutungslos es ist, aber ich rate Ihnen:

• Studieren Sie vor den Interviews typische Fragensätze für Ihre Sprache / Plattform und merken Sie sie sich gut. Kennen Sie kontroverse Fragen, deren Antworten einfach nicht abgeleitet werden können. Eine meiner Lieblingsfragen lautet: „Was ist der Nachteil der Verwendung von Proxy-AOP im Vergleich zu AspectJ im Frühjahr?“ :) Dies ist notwendig, um Interviews mit Interviewern, die nicht genug Vorstellungskraft für normale Fragen haben, problemlos zu bestehen.
• LeetCode , .

, , . , , « » , .

( , ), , !