Senior Engineer auf der Suche nach Arbeit. Wie ich 15 technische Interviews durchlaufen habe und was ich darüber denke

Die Fortsetzung der Geschichte, wie ich in verschiedenen Unternehmen für verschiedene Positionen interviewt wurde. Dieses Mal schließen wir einige Fragen und Kommentare zum ersten Teil und sprechen weiter über Testaufgaben und technische Interviews.

Zu meiner Überraschung erregte der vorherige Artikel über Interviews mit Personalvermittlern und der Personalabteilung unerwartetes Interesse: mehr als 100.000 Aufrufe aus allen Quellen. Ich habe eine Menge positiver Rückmeldungen in PM erhalten. Sie haben mir ehemalige Kollegen geschrieben, die ich zuletzt vor ungefähr 5 Jahren gesehen habe. Heldinnen einiger Geschichten; ein Typ, den ich vor einigen Wochen über OLX eine Systemeinheit verkauft habe (analog zu Slando, - ca. per.) ; der Schlagzeuger, mit dem wir letztes Jahr in der Garage Metal gespielt haben, und seltsamerweise einige Personalvermittler, die mich gefragt haben, was ich über bestimmte Aspekte der Interviews und Einstellungen halte. 250 Leute haben mich aus irgendeinem Grund auf LinkedIn hinzugefügt :).

Bevor ich zur Sache komme, werde ich die beliebtesten Fragen sowie persönliche Nachrichten und Kommentare beantworten.

So arrangieren Sie ein Gehalt für ein Vorstellungsgespräch


Viele Kommentare bezogen sich auf Geld. Ich habe dem bewusst nicht viel Aufmerksamkeit geschenkt, da das Bieten ein separates Thema ist, aber die Kommentatoren haben es immer noch angesprochen und auf die Mängel meiner Strategie hingewiesen - zum Beispiel, um den Preis sofort zu benennen. Hier sind zwei gute Artikel, die dieses Problem viel detaillierter und professioneller behandeln:


Ich empfehle zu lesen, bevor Sie nach Arbeit suchen.

Ein paar Gedanken zur Rekrutierung


Auf keinen Fall gebe ich Personalvermittlern Ratschläge, wie sie ihre Arbeit erledigen sollen. Ich bin kein professioneller Personalvermittler und ich weiß nicht, wie ihre innere Küche funktioniert. Wenn ich nach Mitarbeitern suchen musste (nicht nur um technische Interviews durchzuführen, nämlich um zu suchen und einzustellen - ein vollständiger Zyklus), dann waren dies Juniorpositionen, ich hatte keine besonderen Schwierigkeiten.

In privaten Nachrichten fragten sie mich, wie ich die erste Nachricht über das Arbeitsangebot machen sollte, damit es attraktiv aussah und den Spezialisten interessierte, wie ich auf mich aufmerksam machen könnte.

Es scheint mir, dass leider nichts vom Personalvermittler abhängt. Ein Personalvermittler kann lediglich so viele Kontakte von Spezialisten mit dem erforderlichen Profil wie möglich finden und ihnen ein Angebot unterbreiten. Danach müssen Sie warten und hoffen, dass einer von ihnen entweder zögert oder eine aktive Jobsuche durchführt. Das heißt, es gibt 20% der Arbeit mit der Basis und 80% des Glücks. Das Netzwerk verfügt über viele Materialien zur korrekten Erstellung von Stellenangeboten usw. Für mich ist jedoch der Schlüsselfaktor genau der Wunsch des Bewerbers, den Arbeitsplatz zu wechseln.

Rekrutierung ist der Verkauf einer offenen Stelle an einen Kandidaten. Je früher Sie dies verstehen und Ihre Verkäuferfähigkeiten verbessern, desto besser. Oh, ich sagte, dass ich keinen Rat geben werde :)

Ich bin auch davon überzeugt, dass Kandidaten bei der Arbeitssuche alle mehr oder weniger geeigneten Stellen annehmen müssen, da es nur während eines Gesprächs mit technischen Spezialisten möglich ist, herauszufinden, worum es bei der Stelle geht. Bei meinen Recherchen habe ich praktisch nicht darauf geachtet, was in der Stelle geschrieben wurde, und in der Phase eines technischen Interviews die notwendigen Details herausgefunden. Ich glaube, dass diese Methode die richtigste ist, da die Chancen, ein cooles Projekt zu finden, das sich hinter einer grauen Standardbeschreibung verstecken kann, stark erhöht sind. Meine Erfahrung bestätigt diese These nur eindeutig. Nicht ein einziges Mal in der Vakanz wurde speziell geschrieben, was zu tun wäre. Nur allgemeine Ausdrücke wie "Code codieren, Tests testen, Bereitstellung bereitstellen".

Engagieren Sie sich in einem Unternehmen oder Projekt


In unserer Realität - definitiv für ein Projekt.

So wählen Sie einen Titel aus


Ich habe mich als Kandidat auf der Ebene des Senior Software Engineer und höher positioniert - Team / Tech Lead, Principal Engineer, Software Architect, Projektmanager, People / Group Manager und so weiter. Dies ist, was das "oben" mit "+" in "Senior +" bedeutet.

Es scheint mir, dass der Titel nichts bedeutet. Das einzig Wichtige ist, was Sie tatsächlich tun werden, und dies kann nur von der Person herausgefunden werden, mit der Sie arbeiten werden.

Also, meine Damen und Herren, fahren wir mit technischen Interviews fort.

Stufe zwei. Technische Interviews


In diesem Teil wird es mehr von meiner subjektiven Erfahrung und Philosophie als Ratschläge geben. Im Internet gibt es viele Informationen darüber, was bei technischen Interviews gefragt wird und wie man sich darauf vorbereitet.

Haftungsausschluss: Der Autor ist kein Turboengineer-Olympiade, daher können einige Entscheidungen oder Kommentare ein Lächeln, einen Hintern verletzen, den Wunsch hervorrufen, den Autor auf seine Fehler oder geringen Qualifikationen hinzuweisen. Ich freue mich, das Konstrukt zu hören.

Insgesamt habe ich 15 technische Interviews durchlaufen, was für mich nicht so viel ist. Ich hätte viel mehr durchmachen können, aber im Durchschnitt erwartete ich eine Woche vom ersten Kontakt mit einem Personalvermittler bis zu einem Gespräch mit einem technischen Spezialisten. Dies trotz der Tatsache, dass ich praktisch keine Fristen hatte. Nur einmal hatte ich ein Interview für die Zeit geplant, für die ich bereits ein weiteres Interview geplant hatte. Ich stelle auch fest, dass alle Unternehmen oder Personalvermittler selbst zu mir gekommen sind. Ich habe zuerst keine Lebensläufe an ein Unternehmen gesendet. Dies ist die Frage, dass nicht der Seigneur Arbeit sucht, sondern die Arbeit - der Seigneur.

Testaufgaben


Viele Unternehmen geben Testaufgaben, bevor sie zu einem Gespräch übergehen, um irrelevante Kandidaten auszusortieren. Trotz der Tatsache, dass viele ihre Zeit nicht gerne in Testaufgaben investieren, insbesondere wenn sie ziemlich umfangreich sind, denke ich immer noch, dass dies eine gute Praxis ist. Lassen Sie uns überlegen, was Testaufgaben sein können.

"Machen Sie ein Projekt von Grund auf neu (möglicherweise mit einer bestimmten Technologie) und veröffentlichen Sie es auf GitHub" - für mich die schlechteste Option. Sie können viel Zeit auf einem Boilerplate verbringen, auf der Infrastruktur rund um die Lösung, und der Interviewer wird in der Regel an mehreren kleinen Implementierungsdetails interessiert sein, die in den Bedingungen der Aufgabe festgelegt sind. Wenn Sie beispielsweise Projektvorlagen zur Hand haben und den Server in 5 Minuten anheben und schnell herunterladen können, was Sie benötigen. Ansonsten muss man sich an alles erinnern und von vorne anfangen. Es ist auch schlecht, wenn die Aufgabe die Bedingung hat, externe Abhängigkeiten zu verwenden, z. B. eine nicht eingebettete Datenbank.
Positionieren Sie den DevOps-Ingenieur. Sie schickten mir die Aufgabe, Vagrant zu einer Konfiguration mehrerer virtueller Maschinen zu machen, darunter Webserver mit Statik, ein Balancer für sie und Jenkins. All dies musste mit Chef installiert und konfiguriert werden. Stellen Sie sich nun vor, ich habe Vagrant, Chef, nie verwendet und die für die Aufgabe erforderlichen Webserver nicht konfiguriert. Ich verstehe, wie das alles funktioniert, ich habe mich mit ähnlichen Tools befasst, aber ich habe diese nie speziell verwendet.

Ich musste mich über Nacht hinsetzen, alles reparieren, ein paar Rechen sammeln und schließlich die Aufgabe erledigen. Die Hauptschwierigkeit bestand darin, dass ich ein altes MacBook Pro aus dem 15. Jahr hatte, das physisch keine Zeit hatte, die Container neu zu starten, und dass ich keine Erfahrung mit Vagrant hatte.

Die Essenz der Aufgabe - herauszufinden, wie man was installiert - hat wahrscheinlich eine halbe Stunde gedauert. Den Rest der Zeit (7 mit ein paar Stunden) habe ich damit verbracht, alle Tools zu installieren, neu zu starten - neu zu starten, Konfigurationen zu durchsuchen, um zu verstehen, warum es nicht funktioniert, und so weiter.
Ich würde wahrscheinlich die gleiche Aufgabe in Docker Compose in einer Stunde erledigen, vielleicht sogar weniger. Könnten Sie den Kandidaten nicht auf Tools beschränken? Es scheint mir, dass es möglich ist.

War diese Suche für mich hilfreich? Auf jeden Fall ja! Jetzt werde ich wissen, dass du von Vagrant und Chef wegbleiben musst :)

Verbrachte Zeit - 8 Stunden .
Leider habe ich keine Geschichten mehr über diese Art von Aufgabe, da es im Allgemeinen nicht so viele Testaufgaben gab :(

"Hier ist ein Link zur Website mit den Tests - gehen Sie sie durch" ist eine sehr coole Option. Was ist der Punkt? Es gibt SaaS, mit denen Sie eine Reihe praktischer und theoretischer Fragen konfigurieren können. Für die Lösung bieten sie REPL und einen Code-Editor direkt im Browser und bieten die Möglichkeit, Überprüfungstests durchzuführen. Dann gehen Sie einfach zu Aufgaben über, reparieren die vorhandene oder schreiben Ihren eigenen Code, führen ihn aus und sehen die Ergebnisse. Die Tests selbst sind Ihnen verborgen, Sie sehen nur das Ergebnis (bestanden / nicht bestanden) und eine kurze Beschreibung des Tests, die gleichzeitig ein Hinweis sein kann. Warum mag ich diese Option am meisten? Weil es ein eindeutiges Kriterium für die Qualität der Aufgabe gibt und der Kandidat genau weiß, wie viele Punkte er erzielt hat, ob seine Entscheidungen funktionieren und so weiter. Ich persönlich war sogar daran interessiert, diese Aufgaben zu erledigen. Das einzige, was ich nicht in theoretischen Fragen wie "Was passiert, wenn dieser Code ausgeführt wird" sehe - sie sind leicht Google.
Ruby Software Engineer Position. Sie senden mir natürlich einen Link zur TestDome- Website zu einem benutzerdefinierten Test. Ich klicke, gehe in die eigentlichen Tests. Sie geben mir 2,5 Stunden, um den gesamten Satz zu vervollständigen, 5-20 Minuten für jede Frage. Tatsächlich hat es mir sehr gut gefallen, ich habe solche Dinge schon lange nicht mehr durchgemacht. Besonders gut hat mir der TDD-Ansatz gefallen: Ich habe codiert, gestartet, geschaut, was gefallen ist, Sie codieren weiter. Mit großer Freude bestanden.

Die Aufgaben selbst waren recht einfach: Code korrigieren (Ruby / JS / CSS / HTML), Validatoren schreiben (Ruby), Datenstrukturen implementieren (Ruby), nichts Besonderes. Die Tatsache, dass Sie sofort überprüfen können, ob die Lösung funktioniert, hilft jedoch sehr.

Ich habe die Aufgabe für 93/100 Punkte in nur einer Stunde erledigt. Leider hat mir dieses Ergebnis in Zukunft überhaupt nicht geholfen.

TDD hilft bei der Entscheidung, Sie müssen keine Zeit für die Erhöhung der Infrastruktur aufwenden und die Wiedergabe direkt im Browser durchführen - kurz gesagt, sehr cool. Aus diesem Grund konnte ich einen Monat warten - am Ende bekam ich meine Portion Dopamin (hat hervorragende Arbeit geleistet) und Adrenalin (die Uhr tickt, die Zeit läuft ab!).

Zeitaufwand - 1 Stunde.
Der große Vorteil dieser Art von Aufgabe besteht auch darin, dass ihre Überprüfung automatisiert ist. Wir alle wissen, wie sehr Interviewer es lieben, Aufgaben zu überprüfen, und hier erledigt die Maschine alles für sie - es ist sehr praktisch, zumindest, dass Sie den Code nicht herunterladen und sammeln müssen. Vielleicht werde ich diese Methode bei zukünftigen Einstellungen anwenden.

"Hier ist das Repository, es gibt eine Aufgabe, eine Pull-Anfrage mit einer Lösung senden" - Ich bin nicht auf diese Option gestoßen, aber meine Kollegen haben sie verwendet. Ich mag ihn nicht wirklich, weil Sie sehen können, wie andere Kandidaten die Aufgabe ausgeführt haben (wenn sie es waren).

Die Nachteile dieser Methode liegen auf der Hand: Der Tester muss den Code herunterladen, sammeln, beobachten, was da ist, es ist lang und langweilig. Natürlich können Sie den Code im Browser oberflächlich sehen, aber warum brauchten Sie dann eine Aufgabe? Schreiben wir dann auf den Pseudocode.

"Hier ist das Repository, da ist der Code, überarbeiten Sie ihn so weit wie möglich" - eine Variation des vorherigen. Das ist besser, denn hier wird von Anfang an ein Rahmen geschaffen, in dem gearbeitet werden kann. Die Nachteile sind die gleichen: Es ist nicht klar, wann man aufhören soll. Wie Egor Bugaenko sagte , enthält jedes Programm unendlich viele Fehler, und sie können auch auf unbestimmte Zeit behoben werden.

Die Autoren des Auftrags hatten wahrscheinlich etwas im Kopf, als sie ihn erstellten. Wir werden höchstwahrscheinlich nicht wissen, was für sie allein die Hauptsache war. Wenn die Aufgabe ein klares Kriterium hätte, wäre es cool. Beispiel: "Es gibt einen Code, der ein solches Ergebnis bei der Geschwindigkeit auf einer solchen Hardware erzeugt. Refaktorieren Sie ihn so, dass er doppelt so schnell funktioniert." Es ist schwer, ohne Kriterien zu arbeiten. Im wirklichen Leben, in der wirklichen Arbeit haben wir immer einen Rahmen und suchen nach der optimalen Lösung, die sich an diesem Rahmen und dem gesunden Menschenverstand orientiert. Die Hauptaufgabe des Entwicklers besteht darin, dieses Gleichgewicht zu spüren und die geeignete Lösung zu finden.

Zu meinem großen Bedauern gab niemand anderes Testaufgaben, daher ist meine Auswahl sehr klein. Es sei denn, ich kann mich an den Test erinnern, den ich vor vielen Jahren durchgeführt habe. Alle waren vom ersten Typ - es war notwendig, ein Projekt zu machen. Interessanterweise habe ich sie in jenen Tagen durchgeführt, als GitHub noch nicht so beliebt war und es notwendig war, die Lösung per Post im Zip-Archiv zu senden :)

Meine Empfehlungen für Testobjekte?

  1. Mag es nicht - nicht. Wenn die Aufgabe zum Beispiel darin besteht, die gesamte Site zu vervollständigen oder einen Rohstoff zu schreiben, stellen Sie ihn in das Badehaus. Die Aufgaben sollten kurz sein und sich darauf konzentrieren, einen Kontext für die folgende Diskussion zu schaffen, und nicht nur einen Test, wie Sie Gerüste bauen können.
  2. Wenn die Aufgabe vom ersten Typ ist - fügen Sie dem Readme-Repository hinzu, in dem die Anweisungen zum Starten ausführlich beschrieben werden, eine kurze Anmerkung darüber, warum Sie eine solche Entscheidung getroffen haben, welche Mängel sie haben, was Ihnen gefallen hat oder was nicht, wie würden Sie die Aufgabe lösen, wenn Du hattest mehr Zeit und so weiter. Ich weiß nicht, ob dies wirklich hilft, aber als Interviewer würde ich definitiv eine solche Dokumentation der Entscheidung erwähnen.
  3. Schreiben Sie normal, aber Sie sollten nicht viel Zeit damit verbringen, Teile zu lecken. Für mich reicht es aus, einfach alles in Readme aufzulisten, was Sie verbessern würden, wenn es ein Kampfcode wäre.
  4. Überlegen Sie sich, welche Fragen Sie möglicherweise zur Implementierung haben, und lesen Sie die zusätzliche Dokumentation zu der von Ihnen verwendeten API. Angenommen, ich habe lange nicht mehr mit Parallelität gearbeitet. Ich habe das lange nicht mehr geübt, also ging ich nach der Entscheidung schnell alle verwandten Themen durch, erinnerte mich an alle typischen Aufgaben und war bereit für das Gespräch.

Nun, testen Sie einen, ich hoffe, Sie haben ihn erfolgreich abgeschlossen, diese Informationen an den Personalvermittler weitergegeben und nach einer unbestimmten Zeit werden Sie eingeladen, persönlich zu sprechen.

Technisches Interview. Intro


Zunächst werden sie nur noch selten zu Interviews ins Büro eingeladen. Ich wurde nur mehrmals ins Büro gerufen - für ein Interview in den Positionen Solution Architect, Tech Lead und einmal - für eine Führungsposition. Alle anderen Interviews fanden über Skype, Zoom, Hangouts statt. Wie im vorherigen Interview mit dem Personalvermittler sind die Empfehlungen dieselben - eine gute Kamera, ein gutes Headset, gutes Internet. Dazu füge ich noch die Bedingung hinzu, den Bildschirm zu fummeln. Stellen Sie daher sicher, dass Sie keine offenen Arbeitsprojekte (wenn dies wichtig ist) und andere persönliche Dinge haben, die Sie den Menschen an diesem Ende nicht zeigen müssen. Halten Sie einen sauberen Browser ohne Tabs und REPL für die Codierung für alle Fälle bereit (IDE oder repl.it ).

Von allen Kommunikationsmethoden mag ich Zoom am meisten. Eigentlich wurde es am häufigsten verwendet.
Ein wichtiger Tipp für die ordnungsgemäße Kommunikation in Newsgroups: Machen Sie es sich zur Gewohnheit, nicht auf der Tastatur zu sprechen oder zu tippen, wenn eine andere Person spricht, und über das Headset zu sprechen, und beispielsweise nicht über ein externes Laptop-Mikrofon und externe Lautsprecher.

Warum ist das wichtig? Meistens sprechen zwei Personen mit Ihnen, sie verwenden das Headset nicht. Wenn Sie sprechen, enthält die Software auf ihrer Seite einen Geräuschschneider, der verhindert, dass der Rückkopplungseffekt auftritt (Hintergrund, Pfeife, Echo). Wenn der Geräuschunterdrücker eingeschaltet ist, fängt das Mikrofon praktisch nichts auf, sodass Sie nicht hören, was sie Ihnen sagen.

Wenn Sie auf der Tastatur tippen, wird ein Geräusch erzeugt, das auf die andere Seite übertragen wird, und es enthält auch eine Geräuschreduzierung. Infolgedessen brechen Phrasen ab und es entsteht der Eindruck einer schlechten Verbindung. Daher sollten Sie immer warten, bis die Teilnehmer das Gespräch beendet haben. Andernfalls hören Sie einfach nicht, was sie sagen wollten (außer wenn die Gesprächspartner auch das Garntiru verwenden). Seltsamerweise wissen viele Menschen nichts über diese Mechanismen. Es ist auch nützlich, das Mikrofon während des Gesprächs stummzuschalten, damit keine Geräusche aus Ihrem Raum zu Personen gelangen. Ich bin jahrelang in einem Unternehmen aufgewachsen, in dem jeder diese Regeln kennt. Für mich ist das alles offensichtlich, aber ich habe viele Situationen gesehen, in denen Menschen diese Grundregeln nicht befolgt und im schlechten Internet gesündigt haben.
Wenn alles in Ordnung ist, Pings hin und her gegangen sind, beginnt das Gespräch. Oft schlagen die Interviewer selbst einen Gesprächsplan vor. Es kommt vor, dass sie keinen Plan haben, aber mindestens ein Thema wird immer relevant sein: "Erzählen Sie uns von sich und Ihren Erfahrungen . "

Gehen Sie vor dem Vorstellungsgespräch die Stelle noch einmal durch, achten Sie auf die Anforderungen, die für den Kandidaten gelten, und bereiten Sie eine Rede vor. Ich habe Interviews mit Tech Lead, DevOps / SRE, Ruby / Java Software Engineer geführt und in jedem Fall verschiedene Dinge erzählt, von denen ich denke, dass sie für den Interviewer von größerem Interesse sind. Versuchen Sie, nicht auf Details einzugehen, sondern geben Sie die Informationen an, die einen Vektor für die weitere Diskussion bilden. Sie sollten nicht im Detail darüber sprechen, was Sie vor 5 Jahren getan haben (es sei denn, dies war natürlich nichts Außergewöhnliches).

Ich sagte zum Beispiel Folgendes: „Ich habe 8 Jahre lang in einem Unternehmensbüro gearbeitet, hauptsächlich mit Java. Dann ging ich zu einem Startup, dort beschäftigte ich mich mit Infrastruktur. In den letzten zwei Jahren habe ich hauptsächlich auf Rails geschrieben. “ Das war's, die Interviewer haben genug Informationen und sie werden das Gespräch in der Weise abwickeln, die sie interessiert.

Und jetzt eine unerwartete Tatsache.

Niemand liest Ihren Lebenslauf


Ehrlich gesagt war dies eine großartige Entdeckung für mich. Personalvermittler lesen das Profil auf LinkedIn nicht, da es möglicherweise nicht aktualisiert wird. Die Personalabteilung kann Lebensläufe diagonal anzeigen und die Hauptsache für sich selbst hervorheben. Aber Leute, die ein technisches Interview führen, werden Ihren Lebenslauf sicherlich nicht lesen. Nicht einer, betone ich, nicht ein einziges Mal hatte ich nicht das Gefühl, dass die Leute zumindest mit einem Auge auf das schauten, was ich dort schrieb. Ich vermute, dass sie in der Regel einen Tag vor dem eigentlichen Interview herausgefunden haben, dass sie ein technisches Interview führen müssen, und beschlossen, den Lebenslauf 5 Minuten vor dem Anruf zu lesen, und er würde irgendwie schon da sein.
: « , ». , ( , ). , , .

, .

, , 10 . CV, , , .

CV , . , , .
Und wieder werde ich mein Missfallen über diese Haltung zum Ausdruck bringen. Ich und Sie, wenn Sie bereits eine hochrangige Tomate sind, sind Spezialisten von relativ ernstem Niveau auf Ihrem Gebiet (ich erinnere Sie daran, dass ich diese Formverleumdung und Haufen habe). Es gibt nicht sehr viele Leute wie uns auf dem Markt, also zeigen Sie bitte Respekt und machen Sie sich mit dem vertraut, was ich getan habe. Ich habe über Ihr Unternehmen, Ihr Projekt und Ihren Kunden gelesen. Ich erwarte, als Person behandelt zu werden. Warum passiert das Gegenteil?

Niemand braucht dich


Aber das stört mich am meisten. In 80% der Fälle hatte ich es mit wütenden, schläfrigen, müden Introvertierten zu tun, die eindeutig nicht daran interessiert waren, jemanden einzustellen. Sie waren technisch kompetente Leute und gute Spezialisten, aber aus irgendeinem Grund hatten sie nicht den Wunsch, tatsächlich einen Kollegen einzustellen, sie hatten nicht den Wunsch, einen guten Ingenieur zu nehmen, der ihnen hilft.

Ich bin überzeugt, dass dies Menschen waren, an denen sie einfach die Verpflichtung zur Durchführung von Interviews aufgehängt haben. Mehrmals sagten sie mir, dass die richtige Person im Urlaub war oder keine Zeit hatte anzukommen oder beschäftigt war oder etwas anderes. Sie haben bereits eine Menge zu tun, Probleme auf dem Produkt, wir haben keine Zeit zum Sprinten, Kundgebungen mit dem Kunden, und dann geriet der nächste Kandidat wieder in Schwierigkeiten. Was soll ich mit ihm tun? Daraus ergibt sich das Problem: Interviewer betrachten Sie nicht als die Person, mit der sie arbeiten müssen, sondern versuchen einfach zu beurteilen, ob Sie aus ihrer Sicht normal sind oder nicht. Die Situation war ziemlich häufig, als "oh Timlid jetzt beschäftigt ist, also wird eine andere Person interviewen".

Ich hatte nur wenige Gespräche mit den Ingenieuren, die zeigten, dass sie wirklich Leute brauchen, einen guten Spezialisten einstellen wollen, einen Plan für mich haben und so weiter. Und so fahren wir mit dem nächsten Absatz fort.

Sie werden nicht mit Ihrem zukünftigen Chef oder Teamleiter sprechen


Dies ist eine Folge des vorherigen. Ich bin zutiefst davon überzeugt, dass Sie mit denen sprechen müssen, denen Sie dann formell oder informell gehorchen werden. Alle Organisationen haben eine Art Hierarchie, sei es ein Scrum-Team oder ein blutiges Unternehmen. Überall gibt es eine Person, die sich um Sie kümmert (zumindest zu Beginn).

Leider können Sie nichts dagegen tun. Yegor Bugaenko hat diese Situation in seinem Beitrag „Warum ich nicht mit Google Recruiters spreche“ sehr gut beschrieben. Wenn Sie ein Gespräch mit Ihrem zukünftigen Chef verlangen, erhalten Sie einfach kein Interview.

Es scheint mir, dass dies jetzt eines der größten Einstellungsprobleme bei uns ist. Vielleicht wird dies durch die Besonderheiten der Projekte bestimmt - Outsourcing, bei dem die Leute etwas im Stream tun. Vielleicht die allgemein schlechte Kommunikationskultur und eine menschenfeindliche Mentalität kenne ich nicht.
In englischsprachigen Blogs wird häufig geschrieben, dass Einstellungen einer der Schlüsselbereiche für den Aufbau eines erfolgreichen Unternehmens sind. Ich denke, dass unsere Unternehmen viel Zeit brauchen werden, um dies zu erreichen und die richtige Kultur zu entwickeln. In der Zwischenzeit müssen Kunden dies auslagern.
. , CTO CEO. , . , , . , .
, , (, ).
Bisher kam alles, viele Materialien und Gedanken, Longrid wieder heraus, egal wie ich es versuchte. Im nächsten Teil werden wir uns weiterhin mit dem Thema befassen und uns spezifischen Themen und Techniken zuwenden, die in technischen Interviews verwendet werden.

Source: https://habr.com/ru/post/de434864/


All Articles