Wie ich zu ThoughtWorks kam oder ein Musterinterview

Finden Sie es nicht seltsam, dass, wenn Sie einen Jobwechsel in Erwägung ziehen und ein Vorstellungsgespräch ansteht, Sie zuerst denken: „Ich muss mich auf das Interview vorbereiten.“ Aufgaben auf HackerRank durchgehen, "Crack the Coding Interview" lesen, sich einprägen, wie ein ArrayList funktioniert und wie sie sich von einer LinkedList unterscheidet. Ach ja, und sie könnten auch nach Sortierungen fragen; es wäre eindeutig unprofessionell zu sagen, dass Quick Sort wahrscheinlich die beste Wahl sein wird.
Aber warten Sie, Sie programmieren doch 8 Stunden am Tag, lösen interessante und anspruchsvolle Aufgaben und werden an Ihrem neuen Arbeitsplatz mehr oder weniger dasselbe tun. Dennoch ist es notwendig, sich auf das Interview zusätzlich vorzubereiten, nicht nur um tägliche Fähigkeiten zu verfeinern, sondern auch um etwas zu lernen, was Ihnen an Ihrem aktuellen Arbeitsplatz nicht nützlich war und wahrscheinlich auch am nächsten nicht benötigt wird. Auf Ihre Einwände, dass Computerwissenschaften in unserem Blut liegen und dass wir, selbst wenn wir mitten in der Nacht geweckt werden, im Halbschlaf in der Lage sind, den Breitensuche-Algorithmus auf ein Kopfkissen zu schreiben, werde ich sagen: Wenn ich in einen Zirkus gehen würde und mein Haupttrick genau das wäre— dann würde ich zustimmen. Man sollte diese Fähigkeit testen.

Aber warum sollten irrelevante Fähigkeiten für die aktuelle Arbeit getestet werden? Nur weil das in Mode gekommen ist? Weil Google es so macht? Oder weil Ihr zukünftiger Teamleiter alle Sortiermethoden lernen musste, um das Interview zu bestehen, und jetzt glaubt, dass "jeder gute Programmierer die Implementierung zur Ermittlung von Palindromen in einem String auswendig wissen sollte."

Es ist zwar so, dass Sie nicht Google sind. Was sich Google leisten kann, ist für normale Unternehmen nicht möglich. Google hat anhand der Daten seiner Mitarbeiter festgestellt, dass gerade Ingenieure mit olympischem Hintergrund gut für bestimmte Aufgaben geeignet sind. Zudem können sie im Auswahlprozess das Risiko eingehen, dass sie möglicherweise einige gute Ingenieure nicht einstellen, weil diese nicht so leicht mathematische Probleme lösen können. Aber das ist für sie kein großes Problem, denn es gibt viele, die bei Google arbeiten wollen; die Position wird schnell besetzt.
Schauen wir jetzt aus dem Fenster: Wenn vor Ihrem Büro noch keine Ingenieure, die für Sie arbeiten möchten, ein Lager aufgeschlagen haben und Ihre Entwickler eher nach einer weiteren Spring-Annotation auf Stack Overflow suchen als nach den Feinheiten von Ranking-Algorithmen, dann sollten Sie ernsthaft überlegen, ob es sinnvoll ist, Google nachzuahmen.

Was tun, wenn Google diesmal nicht geholfen hat und keine Antwort gegeben hat? Überprüfen Sie genau das, was der Entwickler bei der Arbeit tun wird. Was schätzen Sie an Entwicklern?
Definieren Sie die Kriterien, wen Sie einstellen möchten, und erstellen Sie Tests, die genau diese Fähigkeiten überprüfen.

ThoughtWorks

Was hat ThoughtWorks damit zu tun? Genau hier habe ich ein Beispiel für ein vorbildliches Vorstellungsgespräch gefunden. Wer sind die ThoughtWorks? Kurz gesagt, es handelt sich um ein High-End-Beratungsunternehmen mit Büros weltweit, von China und Singapur bis hin zu den amerikanischen Kontinenten, das seit etwa 25 Jahren in der Softwareentwicklung konsultiert, mit einer eigenen Wissenschaftsabteilung, die von Martin Fowler geleitet wird. Wenn Sie eine Liste der 10 Bücher suchen, die jeder Software Engineer gelesen haben muss, werden wohl 2-3 davon von den Leuten von ThoughtWorks geschrieben, wie zum Beispiel "Refactoring" von Martin Fowler und "Building Microservices: Designing Fine-Grained Systems" von Sam Newman oder "Building Evolutionary Architectures".
von Patrick Kua, Rebecca Parsons, Neal Ford.

Das Geschäftsmodell des Unternehmens basiert auf der Erbringung recht kostspieliger Dienstleistungen, aber der Kunde bezahlt für die phänomenale Qualität, die sich aus Fachkenntnissen, internen Standards und natürlich Menschen zusammensetzt. Daher ist es hier von entscheidender Bedeutung, die richtigen Leute einzustellen.
Welche Menschen sind die richtigen? Natürlich hat jeder seine eigenen. ThoughtWorks hat festgestellt, dass für ihr Geschäftsmodell die wichtigsten Kriterien für Entwickler sind:

• Die Fähigkeit zur Paarentwicklung. Es ist die Fähigkeit, nicht die Erfahrung oder das Können. Niemand erwartet, dass Menschen kommen, die seit fünf Jahren Pair Programming praktizieren. Aber offen für die Meinungen anderer zu sein und zuzuhören – das ist eine notwendige Fähigkeit.
• Die Fähigkeit, Tests zu schreiben, idealerweise TDD zu praktizieren.
• SOLID und OOP zu verstehen und anwenden zu können.
• Seine Meinung zu präsentieren. Ein Berater muss mit den Entwicklern des Auftraggebers und anderen Beratern zusammenarbeiten. Es bringt nicht viel, wenn jemand etwas gut kann, aber völlig unfähig ist, dies den anderen Teammitgliedern zu vermitteln.

Jetzt ist es wichtig, genau diese Fähigkeiten bei den Kandidaten zu bewerten. Und hier möchte ich von meiner Erfahrung mit dem Vorstellungsgespräch bei ThoughtWorks berichten. Ich möchte gleich sagen, dass ich in Singapur war und es bestanden habe, aber der Rekrutierungsprozess ist einheitlich und wird von Land zu Land nicht stark abweichen.

Phase 0. HR

Wie so oft gab es ein 20-minütiges Gespräch mit der Personalabteilung. Dabei möchte ich nicht verweilen, nur so viel: Ich habe noch nie einen HR-Mitarbeiter getroffen, der 15 Minuten lang über die Entwicklungskultur im Unternehmen sprechen konnte, warum sie TDD anwenden und warum Pair Programming. Normalerweise langweilen sich HRs bei dieser Frage und erzählen, dass ihr Prozess ganz normal ist: Entwickler entwickeln, Tester testen, Manager treiben das Ganze voran.

Schritt 1. Wie gut bist du in OOP, TDD?

1,5 Stunden vor Beginn des Interviews erhielt ich die Aufgabe, einen Mars Rover Simulator zu erstellen.

Aufgabe Mars RoverEin Team von robotischen Rovern soll von NASA auf einem Plateau auf dem Mars landen. Dieses Plateau, das merkwürdigerweise rechteckig ist, muss von den Rovern navigiert werden, damit ihre Onboard-Kameras eine vollständige Sicht auf die umliegende Landschaft erhalten, um sie zur Erde zu senden. Die Position und Lage eines Rovers wird durch eine Kombination aus x- und y-Koordinaten sowie einem Buchstaben dargestellt, der einen der vier Himmelsrichtungen repräsentiert. Das Plateau ist in ein Raster unterteilt, um die Navigation zu erleichtern. Eine Beispielposition könnte 0, 0, N sein, was bedeutet, dass der Rover in der unteren linken Ecke steht und nach Norden schaut. Um einen Rover zu steuern, sendet NASA eine einfache Zeichenkette. Die möglichen Buchstaben sind 'L', 'R' und 'M'. 'L' und 'R' lassen den Rover jeweils um 90 Grad nach links oder rechts drehen, ohne sich von seinem aktuellen Standort zu bewegen. 'M' bedeutet, dass er sich einen Rasterpunkt vorwärts bewegt und die gleiche Richtung beibehält.
Nehmen Sie an, dass das Quadrat direkt nördlich von (x, y) (x, y+1) ist.
EINGABE:
Die erste Eingabezeile sind die oberen rechten Koordinaten des Plateaus, die unteren linken Koordinaten werden auf 0,0 angenommen.
Der restliche Input enthält Informationen zu den bereitgestellten Rovern. Jeder Rover hat zwei Eingabezeilen. Die erste Zeile gibt die Position des Rovers an, und die zweite Zeile ist eine Reihe von Anweisungen, die dem Rover sagen, wie er das Plateau erkunden soll. Die Position besteht aus zwei Ganzzahlen und einem Buchstaben, die durch Leerzeichen getrennt sind, entsprechend den x- und y-Koordinaten sowie der Ausrichtung des Rovers.
Jeder Rover wird nacheinander fertiggestellt, was bedeutet, dass der zweite Rover sich nicht bewegt, bis der erste Rover mit der Bewegung fertig ist.
AUSGABE:
Die Ausgabe für jeden Rover sollte seine finalen Koordinaten und die Himmelsrichtung sein.
ANMERKUNGEN:
Setzen Sie einfach die oben genannten Anforderungen um und beweisen Sie, dass ein Staubsauger funktioniert, indem Sie Unit-Tests dafür schreiben.
Die Erstellung irgendeiner Form von Benutzeroberfläche ist ausgeschlossen.
Es wird bevorzugt, das Problem nach einem TDD-Ansatz (Testgetriebene Entwicklung) zu lösen.
In der kurzen zur Verfügung stehenden Zeit sind wir mehr an Qualität als an Vollständigkeit interessiert.
*Ich kann die Aufgabe, die mir zugesandt wurde, nicht hochladen; es handelt sich um eine alte Aufgabe, die vor mehreren Jahren gestellt wurde. Aber glauben Sie mir, prinzipiell ist alles gleich geblieben.

Besonders möchte ich auf die Bewertungskriterien hinweisen. Wie oft sind Sie bereits in die Situation gekommen, dass für den Kandidaten wichtige Aspekte bei der Überprüfung völlig unwichtig sind und umgekehrt? Nicht alle denken gleich wie Sie, aber viele können Ihre Werte annehmen und diesen folgen, wenn sie klar formuliert sind. Aus den Bewertungskriterien geht bereits hervor, dass die wichtigsten Fähigkeiten in dieser Phase sind

• TDD;
• Fähigkeit, OOP zu nutzen und wartbaren Code zu schreiben;
• Fähigkeiten im Pair Programming

Ich wurde gewarnt, diese 1,5 Stunden damit zu verbringen, darüber nachzudenken, wie ich die Aufgabe angehen werde, statt Code zu schreiben. Den Code werden wir gemeinsam schreiben.

Als wir uns telefonisch austauschten, erzählten die Jungs kurz, wer sie sind und was sie machen, und schlugen vor, mit der Entwicklung zu beginnen.

Während des gesamten Interviews hatte ich nie das Gefühl, dass ich mich in einem Bewerbungsgespräch befinde. Es fühlte sich an, als würde man im Team Code entwickeln. Wenn man irgendwo feststeckt, helfen sie einem, geben Ratschläge, diskutieren und streiten sogar darüber, wie man es am besten machen kann. In dem Interview habe ich vergessen, wie man in JUnit 5 überprüft, dass eine Methode eine Exception wirft – sie schlugen vor, das Testen fortzusetzen, während einer von ihnen googelte, wie man das macht.

Nur einige Stunden nach dem Interview erhielt ich konstruktives Feedback – was gut war und was nicht. In meinem Fall wurde ich für die Verwendung von Sealed Klassen als Alternative zu null gelobt; dafür, dass ich vor dem Schreiben von Code einen Pseudocode erstellt habe, um zu zeigen, wie ich den Rover steuern möchte, und somit eine Skizze der Klassen erhalten habe, zumindest derjenigen, die im API des Roboters verwendet werden.

Phase 2. Erzähl uns

Eine Woche vor dem Interview wurde ich gebeten, eine Präsentation zu einem beliebigen Thema, das mich interessiert, vorzubereiten. Das Format ist einfach und vertraut: 15 Minuten Präsentation, 15 Minuten Fragen und Antworten.
Ich wählte Clean Architecture von Uncle Bob. Und wieder interviewten mich ein paar Personen. Das war meine erste Erfahrung mit einer Präsentation auf Englisch, und ich denke, ich hätte in einer stressigen Situation nicht standgehalten. Aber dennoch hatte ich nie das Gefühl, dass es ein Vorstellungsgespräch ist. Es war wie gewohnt — ich erzähle, sie hören aufmerksam zu. Sogar die traditionelle Frage-Antwort-Runde fühlte sich nicht wie ein Interview an; man sah, dass die Fragen nicht gestellt wurden, um mich „unter Druck zu setzen“, sondern weil sie wirklich an meiner Präsentation interessiert waren.

Ein paar Stunden nach dem Interview erhielt ich Feedback — die Präsentation war sehr hilfreich und sie hatten aufrichtig Freude am Zuhören.

Phase 3. Produktionsqualität Code

Nachdem ich gewarnt wurde, dass dies die letzte Phase der technischen Interviews ist, wurde ich gebeten, den Code zu Hause in einen produktionsreifen Zustand zu bringen, bevor ich ihn zur Überprüfung einreiche und Interviews ansetze, bei denen die Anforderungen an die Aufgabe geändert werden und der Code Modifikationen benötigt. Um vorzugreifen, kann ich sagen, dass die Code-Überprüfung blind erfolgt; die Prüfer kennen weder die Position, für die der Kandidat sich bewirbt, noch sehen sie seinen Lebenslauf oder sogar seinen Namen.

Ein Gespräch, und wieder sind da ein paar Leute auf der anderen Seite des Bildschirms. Alles wie beim ersten Interview: Wichtig ist, nicht das TDD zu vergessen und zu erklären, was man tut und warum. Wenn Sie TDD bisher nicht praktiziert haben, empfehle ich Ihnen, sofort damit zu beginnen, nicht weil es in Firmen notwendig ist, sondern weil es Ihr Leben erheblich vereinfacht und den Stresslevel senkt, wenn Sie so möchten. Erinnern Sie sich, wie Sie früher verzweifelt nach dem Debugger gesucht haben, um einen Fehler zu finden, der nur im Browser reproduzierbar ist, weil Sie ihn mit Tests nicht reproduzieren konnten? Stellen Sie sich nun vor, Sie müssten einen solchen Fehler während des Interviews finden – da sind ein paar graue Haare für Sie garantiert. Was bieten uns TDD? Sie haben den Code geändert und stellen unerwartet fest, dass jetzt die Tests rot sind, aber Sie können beim ersten Mal nicht verstehen, worin der Fehler liegt? Okay, wir sagen den Interviewern „Ups“, drücken Ctrl-Z und beginnen, kleine Schritte nach vorne zu machen. Und ja, die Fähigkeit, mit TDD zu entwickeln, ist eine Fähigkeit, die Sie sich aneignen müssen. Es erfordert, dass Sie darauf hinarbeiten, Ihr Ziel zu erreichen, sodass Ihre Tests permanent grün sind und nicht den halben Tag rot bleiben, weil „Sie eine große Refaktorisierung haben“. Das ist genau so eine Fähigkeit wie das Schreiben von wartbarem oder leistungsfähigem Code.

Wie gut Ihr Code änderbar ist, hängt davon ab, welches Design Sie ursprünglich implementiert haben, wie einfach es ist und wie gut Ihre Tests sind.

Nach dem Interview erhielt ich innerhalb weniger Stunden Feedback. In diesem Moment wurde mir klar, dass ich praktisch bestanden hatte und es nur noch wenig bis zum "Treffen mit Fowler" war.

Schritt 4. Finale. Ausreichend technische Fragen. Wir möchten wissen, wer Sie sind!

Ehrlich gesagt hat mich diese Fragestellung etwas verwirrt. Wie kann man innerhalb einer Stunde herausfinden, was für ein Mensch ich bin? Und wie kann man das erst recht verstehen, wenn ich in einer Sprache spreche, die nicht meine Muttersprache ist, und, um ehrlich zu sein, ziemlich schlecht und holprig? Bei den vorherigen Interviews fiel es mir persönlich leichter, zu erzählen, als auf Fragen zu antworten, und das liegt alles am Akzent. Zumindest einer der Interviewer war Asiater — und deren Akzent ist, sagen wir mal, für ein europäisches Ohr etwas eigenartig. Daher habe ich beschlossen, einen proaktiven Ansatz zu wählen — eine Präsentation über mich vorzubereiten und zu Beginn des Interviews vorzuschlagen, mit dieser Präsentation über mich zu sprechen. Wenn sie einverstanden sind, wird es zumindest weniger Fragen an mich geben, und wenn sie das Angebot ablehnen — na ja, drei Stunden meines Lebens, die ich für die Präsentation aufgewendet habe, sind kein zu hoher Preis. Aber was sollte ich in die Präsentation schreiben? Meine Biografie — Ich wurde dort und dann geboren, bin zur Schule gegangen, habe die Universität abgeschlossen — wem interessiert das schon?

Wenn man ein wenig über die Kultur von Thoughtworks googelt, findet man einen Artikel von Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], in dem die 3 Säulen beschrieben werden: Nachhaltiges Geschäft, Software-Exzellenz und soziale Gerechtigkeit.

Angenommen, ich habe die Software-Exzellenz bereits überprüft. Es bleibt, nachhaltiges Geschäft und soziale Gerechtigkeit zu zeigen.

Dabei habe ich mich entschieden, einen Schwerpunkt auf Letzteres zu legen.

Zunächst habe ich erklärt, warum ThoughtWorks — ich habe bereits im Studium den Blog von Martin Fowler gelesen, daher die Liebe zu Clean Code.

Projekte können auch aus verschiedenen Perspektiven präsentiert werden. Ich habe Software für das Gesundheitswesen entwickelt, die das Leben der Patienten erleichtert hat und sogar, so hört man, ein Leben gerettet hat. Ich habe auch Software für Banken entwickelt, was ebenfalls eine Art der Erleichterung für die Bürger ist. Besonders wenn 70 % der Bevölkerung eines Landes diese Bank nutzt. Es geht nicht um Sberbank und auch nicht um Russland.

Möchten Sie mehr über mich erfahren? Okay. Mein Hobby ist Fotografie, ich halte seit etwa 10 Jahren eine Kamera in der Hand und habe Fotos, die ich nicht zu schämen brauche. Außerdem habe ich eine Zeit lang einem Katzenheim geholfen: Ich habe Katzen fotografiert, die ein dauerhaftes Zuhause brauchen. Mit guten Fotos ist es viel einfacher, eine Katze zu vermitteln. Ich habe wahrscheinlich an die hundert Katzen fotografiert 🙂

Letztendlich waren 80 % meiner Präsentation mit Katzen gefüllt.

Unmittelbar nach der Präsentation schrieb mir die Personalabteilung, dass sie die Ergebnisse des Interviews noch nicht kennt, aber das ganze Büro von den Katzen beeindruckt ist.

Schließlich erhielt ich das Feedback — ich konnte alle als Person zufriedenstellen.

Aber die Personalabteilung erklärte mir im abschließenden Gespräch taktvoll, dass soziale Gerechtigkeit sehr wichtig und notwendig ist, aber nicht alle Projekte so sind. Und sie fragte, ob mich das nicht erschrecke. Insgesamt habe ich es mit der sozialen Gerechtigkeit ein wenig übertrieben, passiert 🙂

Zusammenfassung

Insgesamt arbeite ich jetzt seit mehreren Monaten in Singapur bei Thoughtworks und sehe, dass viele Unternehmen hier die "besten Interviewpraktiken" von Google übernehmen, indem sie Zettel und Whiteboards für das Programmieren verwenden, obwohl weiterführende Kenntnisse über Spring, Symfony, RubyOnRails (zu betonen) bei der Arbeit nicht erforderlich sind. Ingenieure nehmen sich eine Woche Urlaub vor dem Interview, um sich "vorzubereiten".

Bei Thoughtworks stehen neben angemessenen Anforderungen an die Kandidaten folgende Prinzipien im Vordergrund:
Freude am Interviewprozess. Dabei gilt das für beide Seiten. Tatsächlich, wenn Sie die besten Talente gewinnen möchten (und wer möchte das nicht?), ist ein Vorstellungsgespräch kein Markt für Sklaven, sondern ein Treffen, bei dem sowohl Arbeitgeber als auch Kandidat einander beurteilen. Und wenn der Kandidat positive Emotionen mit dem Unternehmen verbindet, ist es durchaus wahrscheinlich, dass er sich für genau dieses Unternehmen entscheidet.

Mehrere Interviewer zur Minderung von Vorurteilen. Bei Thoughtworks ist Pair Programming der De-Facto-Standard. Und wenn diese Praxis auch in anderen Bereichen anwendbar ist, versucht TW, dies umzusetzen. In jeder Phase des Vorstellungsgesprächs führen zwei Personen das Interview. So wird jede Person von mindestens 8 Personen bewertet, und TW bemüht sich, Interviewer mit unterschiedlichem Hintergrund, aus verschiedenen Fachrichtungen (nicht nur Techniker) und Geschlechts auszuwählen.

Letztendlich wird die Entscheidung über die Einstellung auf der Grundlage der Meinungen von mindestens 8 Personen getroffen, und niemand hat das Recht auf ein Vetorecht.

Attributbasiertes Einstellen Anstatt Entscheidungen basierend auf dem „Gefällt mir - Gefällt mir nicht“ des Kandidaten zu treffen, wurde für jede Rolle und jede Phase ein Formular erstellt, das die bewertbaren Attribute umfasst. Dabei wird empfohlen, nicht die Erfahrung in einer bestimmten Fähigkeit zu bewerten, sondern die Fähigkeit, diese anzuwenden. Wenn ein Kandidat also keine Gelegenheit hatte, bestimmte Fähigkeiten wie TDD anzuwenden, jedoch trotzdem versucht, diese zu nutzen und Ratschläge zur korrekten Anwendung befolgt, hat er alle Chancen, das Interview zu bestehen.

Bildungszertifikate sind nicht erforderlich TW verlangt von den Kandidaten keine verbindlichen Zertifikate oder einen Abschluss in Informatik. Es werden nur die Fähigkeiten bewertet.

Dies ist das erste Interview, für das ich mich bei ausländischen Unternehmen nicht vorbereiten musste. Nach jeder Phase fühlte ich mich nicht wie eine ausgepresste Zitrone, sondern im Gegenteil, ich war froh, dass ich die besten Praktiken anwenden kann, dass die Menschen auf der anderen Seite des Bildschirms dies schätzen und sie ebenfalls täglich anwenden.

Nach ein paar Monaten kann ich sagen, dass die Erwartungen vollständig erfüllt wurden. Was unterscheidet ThoughtWorks von einem gewöhnlichen Unternehmen? In einem gewöhnlichen Unternehmen findet man gute Entwickler und angenehme Menschen, aber bei TW ist ihre Konzentration außergewöhnlich hoch.

Wenn Sie zu ThoughtWorks stoßen möchten, können Sie die offenen Stellenangebote einsehen hier
Ich empfehle auch, einen Blick auf interessante Stellenangebote zu werfen:
Lead Software Engineer: Deutschland, London, Madrid, Singapur
Senior Software Engineer: Sydney, Deutschland, Manchester, Bangkok
Software Engineer: Sydney, Barcelona, Mailand
Senior Data Engineer: Mailand
Quality Analyst: Deutschland China
Infrastruktur: Deutschland, London, Chile
(Ich möchte ehrlich warnen, dass der Link ein Empfehlungslink ist. Wenn Sie bei TW erfolgreich sind, erhalte ich eine angenehme Prämie). Wählen Sie das Büro, das Ihnen gefällt. Sie müssen sich nicht nur auf Europa beschränken. Schließlich ist es Teil der Politik von ThoughtWorks, dass Sie alle zwei Jahre in ein anderes Land umziehen können, wodurch sich die Kultur verbreitet und harmonisiert.

Scheuen Sie sich nicht, Fragen in den Kommentaren zu stellen oder mich zu bitten, Sie zu empfehlen.
Wenn das Thema interessant erscheint, schreibe ich darüber, wie es sich bei ThoughtWorks arbeitet und wie das Leben in Singapur ist.

Quelle: habr.com