Die vollständige zweistündige Version kann auf dem Hexlet YouTube-Kanal angesehen werden .
Inhaltsverzeichnis:
Produkt- und Firmengeschichte
Wie die Produktentwicklung funktioniert
Technologieauswahl und -entwicklung
- Flash → Leinwand
- Winkel → Reagieren
- Server und Datenbanken
- Java
- Evolution testen
- Lastwachstum und Refactoring
Prozesse in der Entwicklung
- Technische Lösung und Codeüberprüfung
- Leistungsbeurteilung
- Wie die Einstellung von Ingenieuren funktioniert
- Junior Positionen
Produkt- und Firmengeschichte
Miro ist eine kollaborative Online-Whiteboard-Plattform für die visuelle Zusammenarbeit. Das Schlüsselwort ist Zusammenarbeit bzw. Zusammenarbeit. Die Schlüsselkennzahlen, an denen wir unsere Effektivität messen, sind die Anzahl der Kollaborations-Boards und Kollaborationssitzungen, die im Produkt stattfinden.
Wir nennen uns eine Plattform, weil wir bereits über ein Produkt hinausgegangen sind: Wir haben eine offene API, einen Marktplatz, ein Entwicklerbüro, damit jedes Unternehmen das Produkt für sich selbst erweitern kann.
Unsere Zielgruppe sind Produktteams, die von denselben oder verschiedenen Büros aus arbeiten. Am häufigsten wird Miro für die Durchführung von Workshops, strategischen Sitzungen, Brainstorming und agilen Praktiken (Planung, Rückblicke) verwendet.
Ich leite die Entwicklung bei Miro. Ich bin in Perm aufgewachsen und lebe weiterhin hier. Historisch gesehen erschien das Unternehmen in Perm, wo unsere Gründer herkommen. Der größte Teil unserer Entwicklungsabteilung ist jetzt hier, und 2019 haben wir ein zweites Ingenieurbüro in Amsterdam eröffnet und entwickeln es aktiv.
Zuvor arbeitete ich in der kundenspezifischen Entwicklung, indem ich als Entwickler analytische Data Warehouses aufbaute, diese entwarf und dann große Projekte leitete. 2016 wechselte er zu Miro, als das Unternehmen 30 Mitarbeiter beschäftigte. Seitdem sind wir stark gewachsen: Jetzt haben wir fünf Büros mit 400 Mitarbeitern, von denen 140 Ingenieure sind.
Das Unternehmen wurde 2011 gegründet. Unsere größte Funktion war und ist die Produktentwicklung, auf die heute etwa die Hälfte des Unternehmens entfällt.
Namensänderung
Wir haben 2015 über ein Rebranding nachgedacht, dies aber 2018 getan. Unser früherer Name RealtimeBoard ist lang und komplex. Es wurde oft falsch verstanden, mit RTB abgekürzt oder, was am schlimmsten ist, ganz vergessen. Außerdem ist es emotionslos, es steckt keine Geschichte dahinter. Wir wollten den neuen Namen kurz, geräumig, sprechend und unvergesslich machen.
Infolgedessen haben wir uns von den Werken des Künstlers Joan Miró inspirieren lassen und seinen Nachnamen als Titel gewählt. Die Recherche selbst und die Wahl des Namens dauerten mehrere Monate, und dann, einige weitere Monate, haben wir eine neue Marke eingeführt. Im Anschluss an dieses Projekt gibt es eine Reihe von Artikeln über die Anordnung der Projektarbeit und einen separaten Artikel über eine kleine, aber nicht triviale technische Aufgabe für die nahtlose Migration autorisierter Benutzer von der alten in die neue Domäne.
Sowohl wir als auch die Benutzer haben sich schnell an den neuen Namen gewöhnt. Wir wachsen schnell, so dass mehrere Millionen neue Benutzer nicht einmal wissen, dass wir anders genannt wurden. Ein angenehmer Rebranding-Bonus waren die Auszeichnungen der European Design Awards für die Identität, die wir im Rahmen des Rebrandings zusammen mit der europäischen Agentur Vruchtvlees entwickelt haben .
Wie die Produktentwicklung in Miro funktioniert
Das gesamte Produktentwicklungsteam von 170 Mitarbeitern befindet sich in Perm und Amsterdam: Ingenieure, Produkte, Produktdesigner, Scrum-Master.
Früher war es für mich schwer vorstellbar, dass so viele Menschen an einem Produkt arbeiten können. Aber heute weiß ich, dass bei Uber, Slack und Atlassian Tausende von Ingenieuren an demselben Produkt arbeiten. Wir wachsen weiter und verstehen, dass wir jetzt eindeutig nicht genug sind, und der nächste Zielpunkt in meinem Kopf sind 300 Menschen in der Entwicklung, und dann werden wir weiter wachsen. Es ist nicht nur eine Zahl aus deinem Kopf. Wir haben strategische Planung, wir verstehen, wo wir in zwei, in fünf Jahren sein wollen und was wir dafür tun müssen.
In Bezug auf die Organisationsstruktur gibt es Gilden: Frontend, Backend, QA und so weiter. Um an Projekten zu arbeiten, werden sie zu funktionsübergreifenden Teams zusammengefasst.
Die Teams sind in Schlüsselbereichen verteilt:
- Ein horizontales Produkt ist die Hauptproduktfunktionalität, die alle Benutzer sehen: Aufkleber, Text, Formen, Rahmen usw.
- Systemrichtung - verantwortlich für die Kernplattform und Infrastruktur.
- Beim Wachstum geht es darum, die Anzahl der Benutzer zu erhöhen: Aktivierung, Engagement, Rendite, Monetarisierung.
- Enterprise — , . -, Miro, . -, SaaS-, . , , .
- — 2019 . API, , marketplace, — , , .
- — , . , , , Miro, : Meetings & Workshops, Ideation & Brainstorming, Research & Design, Agile Workflows, Strategy & Planning, Mapping & Diagramming.
: , , . , . , : - .
Die Hauptsoftware der Ingenieure: IntelliJ Idea, Jira, Slack, Zoom, Miro, Confluence. Die meisten Mitarbeiter arbeiten an MacBooks, die meisten Ingenieure arbeiten an MacBook Pros, und für einige kaufen wir bei Bedarf leistungsstärkere Maschinen.
Wir verwenden jeden Tag unser eigenes Produkt: interne Besprechungen, Workshops, Brainstorming-Sitzungen, Planung.Auf diese Weise können Sie alle Innovationen des Produkts schnell testen und die Anpassung neuer Entwickler, die vom ersten Tag an nicht nur hinsichtlich des Codes, sondern auch als Benutzer mit dem Produkt arbeiten, erheblich vereinfachen. Dies ist ein wichtiger Teil unserer Kultur - wir stellen ein Produkt her, das wir selbst bequem und angenehm verwenden sollten.
Stapel, Monolith
Die Vorderseite ist Typescript, React und AngularJS. Das Backend ist Java. Datenbanken - Redis, Postgres, für die Clusterkommunikation - Hazelcast und ActiveMQ. Wir hosten in Amazon im selben Rechenzentrum. Es sind ungefähr 400 Server in Produktion. Anwendungsserver, die Benutzerplatinen verarbeiten, können bis zu 100 sein. Alles wird automatisch orchestriert.
Wir verwenden einen Stapel von Atlassian: Jira, Bitbucket, Bamboo und unsere eigenen Skripte, die mit Bamboo verschraubt sind und die Bereitstellung von allem auf Servern ermöglichen. Bisher sind alle Releases ein Big Front Release und ein Big Back Release. Jetzt überlegen wir, wie wir mehr aus diesen Veröffentlichungen machen können.
Unsere Hauptanwendung ist ein modularer Monolith: Es gibt ein Modul, das für die API, die Karte und die Servicefunktion verantwortlich ist. Der Monolith wird in Modulen auf den erforderlichen Servern bereitgestellt und nicht in einem großen Teil auf allen Servern in einer Reihe, dh wir haben auch Server mit unterschiedlichen Rollen.
Innerhalb der Anwendung gibt es viele Integrationen und zusätzliche Services, die wir sofort separat durchgeführt haben und die die Teams unabhängig vom Rest der Vorder- und Rückseite freigeben.
Wenn Sie ein kleines Unternehmen haben, ist es viel einfacher, mit einem Monolithen zu beginnen und die Infrastruktur für Dienstleistungen nicht einzuschränken. Jetzt haben wir jedoch verstanden, dass ein gemeinsamer Monolith uns nicht die Möglichkeit gibt, einzelne Richtungen (horizontales Produkt, Plattform, Unternehmen usw.) zu skalieren. Daher entwickeln wir einen Ansatz, um einen einzelnen Monolithen zu belassen.
Veröffentlichungen
Die Montage selbst dauert 15 bis 20 Minuten, einschließlich der Durchführung von Komponententests. End-to-End-Tests können bis zu 40 Minuten dauern. Der gesamte Vorgang dauert anderthalb bis zwei Stunden, bis der Master freigegeben ist. Dies ist eine lange Zeit, wir haben hier noch etwas zu arbeiten.
Es ist wahrscheinlich ideal, alle fünf Minuten zu veröffentlichen. Aber dafür haben wir noch kein so großes Team und kein so großes tägliches Publikum. Ein großes Publikum ist wichtig für häufige Veröffentlichungen, da Sie so schnell sicherstellen können, dass alles in Ordnung ist, indem Sie Änderungen an einen kleinen Teil der Benutzer weitergeben.
Technologieauswahl und -entwicklung
Ich bin der Meinung, dass die Wahl der Technologie so behandelt werden sollte: Egal, für was Sie sich entscheiden, Sie müssen sie eines Tages ändern, insbesondere wenn das Unternehmen und das Produkt wachsen. Daher ist der Prozess des Technologiewechsels normal. Technologie ist wichtig, muss jedoch in verschiedenen Phasen der Unternehmensentwicklung unterschiedlich behandelt werden.
Kleine Unternehmen, die gerade erst anfangen und nach einem geeigneten Produktmarkt suchen, laufen schnell, bauen MVPs schnell auf und werfen sie schnell weg. Für sie ist es wichtiger, einen Markt zu finden, als komplexe technische Lösungen zu schaffen. Wenn der Markt gefunden ist, treten technische Lösungen in den Vordergrund, da Sie damit einen Sicherheitsspielraum für Wachstum und Sicherheit schaffen können.
Wir versuchen zunächst, das Problem zu verstehen, das wir durch den Wechsel von Technologien lösen möchten. Dann recherchieren wir viel, suchen nach Alternativen und testen die Leistung. Dies geschieht mit allen technischen Lösungen, die wir implementieren werden: "Nehmen Sie nicht das erste, was Sie zuerst auf dem Markt gehört haben, sondern recherchieren und untersuchen Sie, was zur Lösung des Problems am besten geeignet ist."
In einem großen Produkt und einem Team ist ein Technologiewechsel eine wichtige strategische Entscheidung, die zu einem teilweisen oder vollständigen Stillstand der Produktentwicklung, einem Wechsel der Teams zu neuen Aufgaben usw. führen kann. Es ist lang und teuer, aber wenn dies nicht rechtzeitig erledigt wird, können die auftretenden Probleme viel mehr Schwierigkeiten mit sich bringen.
Wir hatten einige große technologische Veränderungen vorne und hinten. Hier sind einige Beispiele.
Flash → Leinwand
Bis 2015 war die gesamte Front auf Flash, dann begann Flash zu sterben und wir wechselten zu HTML und Canvas. Der Stapelwechsel hatte einen guten Einfluss auf die Leistung und Benutzerfreundlichkeit des Produkts und führte zu einer spürbaren Steigerung des Publikums. Der Übergang dauerte ungefähr ein Jahr, es war ein großes und komplexes Projekt. Ein Artikel über die Details dieses Projekts .
Wir erwägen derzeit eine Migration zu WebGL, aber es gibt noch keine eindeutigen Beweise dafür, dass es sich lohnt.
Winkel → Reagieren
In den letzten Jahren sind wir schrittweise von Angular JS zu React übergegangen. Hauptgründe:
- React ermöglicht eine bessere Eingabe und später können Sie Ihren Code besser umgestalten und sicherstellen, dass nichts abfällt.
- React . «» , Angular . Angular, React, .
- React , Angular JS .
2015 haben wir von Hetzner-Mietservern auf Amazon-Hosting umgestellt. Seit mehr als einem Jahr gibt es ein Projekt zur Migration der Hauptdatenbank von Redis nach PostgreSQL. Wir haben Artikel dazu: Projektmanagement der Datenmigration , Erstellen eines Failoverclusters .
Unser Fall wird durch die Tatsache kompliziert, dass wir vom Schlüsselwert des Speichers in eine SQL-Datenbank wechseln. Es gibt viel Refactoring. Es ist wichtig, alles zu tun, damit die Anwendung nicht gestoppt wird. Es ist wie das Rad eines fahrenden Autos zu wechseln, denn die Datenbank ist das Fundament, auf dem die Anwendung steht. Für den Inhalt der Boards haben wir eigentlich alles ohne Wartung gemacht. Ja, der Übergangsprozess hat sich verzögert, aber die Benutzer haben nichts bemerkt, das Produkt hat funktioniert.
Produktstabilität ist ein zentraler Punkt. Benutzer speichern viele Inhalte in Miro. Wenn ein Benutzer eine Sitzung oder ein Meeting geplant, ein Content Board dafür vorbereitet hat und das Produkt zu diesem Zeitpunkt nicht verfügbar ist, ist dies ein Fehler. Der Inhalt kann nicht verwendet werden. Während der bedingte Zoom schnell durch Hangouts ersetzt werden kann, kann der Inhalt nicht schnell ersetzt werden. Daher besteht eine unserer Hauptaufgaben darin, sicherzustellen, dass Inhalte für Benutzer immer verfügbar sind.
Java
Java hilft uns enorm in Bezug auf Produktivität und Entwicklerressourcen, die wir finden können. Ich weiß, dass Booking von Pearl zu Java wechselt, weil sie es satt haben, ihre Ingenieure umzuschulen.
Ingenieure aus C ++ und .Net kommen zu uns und passen sich normal an. Wenn Sie ein erfahrener Entwickler sind, verschiedene Technologien ausprobiert haben und wissen, wie das System aufgebaut ist, ist es nicht so schwierig, in eine neue Sprache einzutauchen. Die Hauptsache ist, dass der Ingenieur die richtigen Lösungen findet und er sich definitiv in der Sprache begraben kann, ich glaube daran.
Evolution testen
Anfangs hatten wir nur manuelle Tests. Die Veröffentlichungen wurden alle zwei bis drei Wochen eingeführt, die Vorbereitung für die Veröffentlichung dauerte eine Woche: Sie führen Regressionstests in wenigen Tagen durch → finden kritische Fehler → korrigieren → manuelle Tests erneut. Wenn es mehrere Teams gab, hat es funktioniert, aber mit zwanzig Teams ist es unmöglich, alles manuell zu testen.
Also haben wir über Automatisierung nachgedacht. Zunächst haben wir Autotests geschrieben, um Regressionstests vollständig zu vermeiden. Jetzt arbeiten wir daran, während des gesamten Entwicklungszyklus die richtigen Qualitätsmanagementprozesse einzurichten. Je früher wir über Qualität nachdenken, desto eher finden wir Randfälle und verstehen, wie man sie testet - dies reduziert letztendlich die Kosten und beschleunigt den Entwicklungsprozess. Ein Fehler, den Sie im Verkauf finden, ist nicht nur die Zeit und die Ressourcen wert, um die Version zurückzusetzen und zu beheben. Der Fehler wirkt sich auf die allgemeine Benutzererfahrung des Produkts aus, und es ist sehr teuer, diese Erfahrung zu beheben.
Wir haben eine QS-Gilde, in der Ingenieure Entscheidungen darüber treffen, welche Prozesse wir jetzt implementieren müssen, eine Qualitätsstrategie entwickeln und dann jeder QS-Ingenieur seinen Teams hilft, diese Prozesse in sich selbst zu implementieren:
- QA- -, . QA , . .
- QA , .
- QA , , .
Kanarische Veröffentlichungen sind auch eine Möglichkeit zum Testen, wenn wir ein Feature für ein kleines Publikum bereitstellen und prüfen, ob wir etwas verpasst haben. Wir starten große neue Funktionen über Kontrollkästchen und stellen sie Beta-Benutzern zur Verfügung, die den Wunsch geäußert haben, an Betatests teilzunehmen (unsere Produktmanager werden dies in Forschungsinterviews erfahren). Die Anzahl der Beta- und Alpha-Benutzer umfasst notwendigerweise unsere Teams. Wir stellen uns zunächst alle neuen Funktionen zur Verfügung.
Eine detaillierte Beschreibung aller Phasen unseres QS-Prozesses .
Lastwachstum und Refactoring
Aufgrund der massiven Verlagerung auf Telearbeit im Jahr 2020 ist unsere Benutzerbasis sprunghaft angestiegen, und unsere jährliche Ausfallsicherheit für Infrastruktur und Anwendungen ist in wenigen Wochen erschöpft. In der ersten Woche eines starken Lastanstiegs haben wir die gesamte Produktentwicklung gestoppt und die Teams neu ausgerichtet, um an Fehlertoleranz und Leistung zu arbeiten.
Die Sicherheitsmarge wurde nicht nur im Backend, sondern auch im Frontend und beim Client benötigt, da die Anzahl der synchronen Jobs im Produkt zunahm. Wenn früher 20 Personen gleichzeitig an einem Board arbeiten konnten, sind es jetzt 300 Personen. Unsere Front-End-Ingenieure haben viel getan und setzen sich weiterhin mit der Lastleistung auseinander. Zum Beispiel machen wir das Dashboard mit der Liste der Boards getrennt von allem anderen und machen es schneller als zuvor. Und wenn der Benutzer direkt zum Board geht, nicht über das Dashboard, sollten der Code und der Inhalt des Boards ohne alles andere geladen werden.
Wir werden viel umgestalten, damit der Benutzer schneller Feedback und Inhalte vom Board erhält und dann alle Hauptfunktionen - Skripte, die Benutzeroberfläche - langsam hochfahren. Zu diesem Zweck haben wir den Code in „faule“ Module unterteilt. Dank dessen haben wir um etwa ein Drittel beschleunigt und planen, im nächsten Monat die Geschwindigkeit beim Laden zu verdoppeln.
In Bezug auf die Leistung auf dem Board ist es dasselbe - es herrscht ein Krieg um die Geschwindigkeit und die Ressourcen des Computers, auf dem der Benutzer läuft.Nicht jeder ging mit guten Maschinen online, jemand zog einen alten, leistungsschwachen Heim-Laptop aus dem Regal. Unser Produkt sollte jedoch auf jedem Laptop gut funktionieren. Dies ist ein weiterer großer Trick, an dem wir gerade viel arbeiten.
Prozesse in der Entwicklung
Technische Lösung und Codeüberprüfung
Jede Aufgabe beginnt mit der Vorbereitung einer Produktlösung. Eine Produktlösung ist eine Antwort auf die Frage „Was machen wir jetzt?“. Ein Produktmanager, der auf Produktstrategie und OKRs basiert, recherchiert viel, um herauszufinden, welche Benutzer derzeit in unserem Produkt fehlen. Basierend auf der Forschung beschreibt das Produkt die Lösung. Die Lebensmittelgilde bespricht die Lösung und überarbeitet sie gegebenenfalls.
Auf der Grundlage einer Produktlösung wird eine technische Lösung gebildet, die die Frage "Wie machen wir das?" Beantwortet. Es wird von den Ingenieuren des Teams entwickelt, die die Funktionalität implementieren. Die technische Lösung durchläuft mehrere Überprüfungsprozesse:
- mit Teams, mit denen es Schnittstellen in der Funktionalität gibt;
- Sicherheitsüberprüfung der Komponenten, die wir in der Architektur ansprechen werden;
- wie wir das Ergebnis bereitstellen werden.
Danach beginnt die Entwicklung selbst. Es ist wichtig, dass die Codeüberprüfung die Entwicklung nicht verlangsamt. Daher haben wir kürzlich anstelle des obligatorischen Eingangs von zwei Codeüberprüfungen die persönliche Verantwortung auf Komponentenebene eingeführt. Jetzt wissen wir auf Codeebene immer, wer für dieses Teil verantwortlich ist, was die Kommunikation während der Entwicklung erheblich erleichtert. Dementsprechend wird dem Prüfer automatisch der Eigentümer dieses Codes zugewiesen, sobald Sie Änderungen am Code vorgenommen haben. Wenn der Code Ihnen gehört, wird die Überprüfung von einem Mitglied Ihres Teams durchgeführt.
Warum haben wir persönliche Verantwortung eingeführt? Zuvor gab es mehrere Leute, „Oldies“, die wussten, wie das gesamte Produkt funktionierte und jeden Code überprüfen konnten. Aber als das Produkt wuchs, fehlten die Fähigkeiten dieser Leute, sie konnten nicht mehr über alles Bescheid wissen, was in der Entwicklung geschah.Der Codeüberprüfungsprozess verlangsamte den Rest des Prozesses. Es war nicht klar, an wen man sich für die Codeüberprüfung wenden sollte. Dann haben wir begonnen, alle erforderlichen Kompetenzen für bestimmte Produktblöcke in das Team einzubringen, das daran arbeitet. So konnten die Teams selbst Code-Reviews durchführen. Dies hat uns einmal geholfen, viel schneller zu werden.
Leistungsbeurteilung
Das Unternehmen hat Noten, dank derer wir verstehen, wer welche Kompetenzen hat, welcher Note sie entsprechen und vor allem, was jeder tun muss, um weiterzumachen. Die Leistungsüberprüfung findet zweimal im Jahr statt, um ein Bild davon zu erhalten, wo sich jede Person gerade befindet, und um personalisiertes Feedback zu erhalten.
Basierend auf diesem Bild erstellt der Teamleiter mit jedem Teammitglied persönliche Entwicklungspläne: Der Mitarbeiter selbst sagt, wo er sich entwickeln möchte, und die Leistungsbeurteilung hebt seine Stärken und Lücken hervor.
Anschließend hält der Teamleiter mit dem Mitarbeiter regelmäßig alle ein bis zwei Wochen 1: 1-Besprechungen ab, in denen unter anderem die Bewegung in die geplante Richtung besprochen und verfolgt wird. Nach anderthalb Jahren, basierend auf den Ergebnissen dieser Bewegung, steigt die Besoldungsgruppe und das Gehalt.
Bei den Teamleitern ist alles genau gleich, außerdem gibt es externes Training und externes Mentoring für sie.
Leider wachsen die Leute oft nicht so schnell wie das Unternehmen - das ist okay. Wir sind bereit, viel in Schulungen zu investieren, da das Wachstum eines Unternehmens direkt vom Wachstum der Mitarbeiter abhängt. Wir haben eine Entschädigung für externe Kurse, wir haben Kurse und Mentoren empfohlen. Wir kompensieren die Schulpflicht zu 100% (z. B. Englisch), wir versuchen, die restlichen 50 bis 50 zu kompensieren, damit die gegenseitige Verantwortung für die Ergebnisse besteht.
Wir gehen selten zu Konferenzen. Wir versuchen, diejenigen auszuwählen, die über Technologien und Fälle sprechen, die für uns derzeit relevant sind und für die wir nicht genügend Wissen haben.
Wie die Einstellung von Ingenieuren funktioniert
Unsere Rekrutierungskette ist Standard für Russland und Europa. In Russland ist der Einstellungs-Trichter bereits eng, sodass das erste Interview nicht von einem Personalvermittler, sondern von einem Personalchef (normalerweise dem Teamleiter des Teams, für das wir eine Person einstellen) geführt werden kann, nachdem der Personalvermittler den Lebenslauf bearbeitet und offene Stellen ausgesondert hat, die nicht den Anforderungen entsprechen.
Ich habe das Gefühl, dass in Russland im Vergleich zu Europa viel weniger Ingenieure aktiv nach Arbeit suchen, weil sie kein Risiko eingehen wollen. Und als viele Unternehmen aufgrund von Isolation in die Risikozone eintraten, neigten die Menschen noch weniger dazu, Risiken einzugehen und den Arbeitsplatz zu wechseln.
In jedem Fall beginnt die Einstellungskette mit einem telefonischen Screening-Interview mit einem Kandidaten, das von einem Personalvermittler oder Einstellungsmanager durchgeführt wird. Der Zweck des Screenings besteht darin, schnell zu verstehen, wie ein Kandidat die wichtigsten Anforderungen der offenen Stelle erfüllt.
Nach dem Screening eine Testaufgabe, dann ein technisches Interview, das unter anderem eine Diskussion der Testaufgabe beinhaltet. Dann - ein Treffen mit dem Team, in dem der Kandidat arbeiten wird. Für uns ist dies ein obligatorischer Schritt, da es in erster Linie hilft, die kulturelle Passform des Kandidaten und nicht seine technischen Fähigkeiten zu verstehen.
Nach all den Interviews sammeln wir Feedback von den Teilnehmern, machen ein Angebot.
Um die Testaufgaben zu bewerten, verwenden wir ein Punktesystem, ordnen die Ergebnisse und sehen so die besten Ergebnisse. In leitenden Positionen brechen wir manchmal eine Testaufgabe ab, wenn der Kandidat über ein gutes öffentliches Repository verfügt.
Junior Positionen
Bevor wir zur Fernarbeit übergingen, begannen wir mit Junior-Spezialisten zu arbeiten: Wir stellten Juns ein, Absolventen, wenn auch nicht sehr aktiv. Jetzt haben wir diese Geschichte komplett eingefroren, weil es sehr schwierig ist, sie an einem entfernten Ort an Bord zu bringen, und wir haben bisher nur sehr wenig Erfahrung damit. Daher konzentrieren wir uns auf Mitten mit mindestens 3-4 Jahren Erfahrung.
Aber selbst wenn wir mit Junioren zusammengearbeitet haben, war es uns wichtig, dass sie in einem Jahr bis zur Mitte aufwachsen können, damit sie sehr schnell lernen und sich anpassen können.
Hohe Einstellungsanforderungen
Es gibt eine Legende, dass es für uns aufgrund der sehr hohen Anforderungen sehr schwierig ist, einen Job zu finden. Dies ist nicht ganz richtig.
Wir werden oft von Kandidaten mit der Position eines Teamleiters interviewt, die nach unseren internen Kriterien in der Mitte liegen. Dies geschieht, weil sie bei der Verfolgung von Positionen zu Unternehmen kommen, die bereit sind, Positionen in mehreren Schritten über ihre derzeitigen Kompetenzen hinaus zu vergeben, nur um eine Person einzustellen. Infolgedessen ist das Ergebnis ein schlechter Dienst: Die Person hat noch nicht auf das erforderliche Niveau gepumpt, nimmt jedoch bereits eine hohe Position ein; dann wird er kaum in der Lage sein, das Unternehmen einfach zu verlassen, weil er nicht für die gleiche Position in anderen Unternehmen eingestellt wird.
Der größte Blocker bei der Einstellung ist Englisch. Früher konnten wir ohne Englischkenntnisse einstellen, aber jetzt ist dies unmöglich und es ist unmöglich, es in wenigen Monaten zu pumpen: Ein Ingenieur aus den ersten Arbeitswochen muss die Dokumentation auf Englisch lesen, auf Englisch mit Kollegen korrespondieren, an Hauptversammlungen teilnehmen, von denen die meisten auf Englisch stattfinden Sprache.
Das Produkt wächst, es erscheinen neue interessante Aufgaben, so dass wir sowohl in Perm als auch in Amsterdam immer viele offene Stellen im Ingenieurwesen haben.