Eine neue und bisher wenig bekannte Programmiersprache in einem kleinen Startup- oder Haustierprojekt mit Freunden zu sehen, ist an der Tagesordnung. Sie werden sich fragen, warum sie es genommen haben. Sie werden sagen, dass Sie es nur aus Neugier gelernt, gemocht und beschlossen haben, zu experimentieren, weil Sie das ewige Java / .Net / JS bei der Arbeit satt haben.
Wenn ein Unternehmen jedoch in Begriffen wie „internationales Geschäft“, „Büros auf der ganzen Welt“, „Produktivitätskult“, „das Ergebnis ist uns wichtig, nicht der Prozess“, „wir brauchen brennende Augen und den Wunsch, sich zu entwickeln“ über sich selbst spricht - normalerweise nicht Warten auf Überraschungen. Einige setzen sogar Stopplisten für neue Technologien, bis sie in der Branche an Gewicht gewinnen. Zu Fragen über die Minuspunkte von Werkzeugen sagen Sie ausweichend: "Die Hauptsache sind Menschen, nicht Sprachen."
Wrike verfolgt mit rund 400 Entwicklern einen anderen Ansatz. Sie haben die Mängel von JavaScript nicht ignoriert und sich nicht einmal für einen Kompromiss wie Flow oder TypeScript entschieden - sondern einen völlig radikalen Weg eingeschlagen. Sie haben die Front in eine Sprache umgeschrieben, die tausend Menschen damals kaum kannten und anscheinend immer noch absolut selbstbewusst sind.
Wrike belegte im Ranking der besten Arbeitgeber in My Circle IT mit einer Durchschnittsbewertung von 4,82 einen ehrenwerten dritten Platz unter den mittelständischen Unternehmen. Zu den am höchsten bewerteten Eigenschaften des Unternehmens gehören: Sozialpaket, komfortable Arbeitsbedingungen, Beziehungen zu Kollegen, angemessenes Gehalt und berufliches Wachstum.
- Wrike wurde 2007 von Andrey Filev in St. Petersburg gegründet. Dann begann er, Geschäfte in Amerika im Silicon Valley aufzubauen. Damals war es eine ganz andere Firma, und jetzt sind wir sehr gewachsen.
Am Anfang hatte Andrey eine Outsourcing-Firma. Sie begannen, nach Software zu suchen, die es ihr ermöglicht, effizienter zu arbeiten - um Zeit und Ressourcen zu verwalten. Zu dieser Zeit gab es kein wirklich cooles Tool, und es kam die Idee, ein eigenes zu erstellen. Dann wurde Wrike geboren.
Wir begannen mit einfachen Dingen, aber allmählich begann das Produkt zu wachsen. Dies war vor 12 Jahren, und wir können sagen, dass wir an der Bildung eines Marktes für solche Arbeitsmanagementsysteme beteiligt waren. Wrike wird mittlerweile von über 18.000 Unternehmen weltweit eingesetzt.
- Gibt es das Outsourcing-Unternehmen noch?Ja, es heißt Murano Software. Aber sie hat nichts mit uns zu tun. Wrike ist ein vollwertiges Einzelproduktunternehmen, das ein Experiment im Rahmen eines Outsourcing-Unternehmens war, aber sehr schnell aufstieg und sich trennte.
"Verwenden sie es dort noch?"Ja immer noch.
Was ist Wrike?
Wrike ist eine Plattform für Projektmanagement und Zusammenarbeit im weitesten Sinne: von einer persönlichen To-Do-Liste bis hin zu einem System, das für große Unternehmen geeignet ist.
Im Inneren können Sie Projekte mit vielen Aufgaben und Unteraufgaben erstellen, Berichte für die Datenerfassung einrichten, Gantt-Diagramme anzeigen, Aufgaben im Kalender verfolgen und sie gleichzeitig mit anderen Teilnehmern bearbeiten. Mit Wrike-Add-Ons können Sie Ihre Arbeitslast in Echtzeit verwalten oder komplexe Multi-Channel-Marketingkampagnen durchführen. Es gibt eine API zur Integration in andere Tools. Es gibt beispielsweise Erweiterungen für Adobe Creative Cloud. Sie können Dateien anzeigen und kommentieren, ohne das System zu verlassen.
Wrike versucht nicht, sich auf eine bestimmte Funktion, Branche oder einen bestimmten Beruf zu konzentrieren. Es ist als universelles Werkzeug für alles positioniert - bis hin zum Ersetzen des Mail-Systems, des Messenger, der Wissensdatenbank, des Bug-Trackers und vielem mehr.
- Defokussierung auf alle und für alles macht einzelne Teile nicht schlimmer?- Wir gehen bewusst nicht in engmaschige Nischen. Zum Beispiel möchten wir nicht ausschließlich Fehlerverfolgungssysteme für Entwickler wie Jira durchführen. Wir wollen keine Software nur für Programmierer oder nur für Designer erstellen. Wir sind daran interessiert, ein universelles Produkt herzustellen. Gleichzeitig verstehen wir, dass es hochspezialisierte Fälle gibt, die wir nicht behandeln.
Dies ist jedoch nicht unser Ziel - alle zufrieden zu stellen oder die IT-Nische voll zu besetzen. Obwohl wir Wrike entwickeln, verwenden wir es als System für Aufgaben und als Bug-Tracker.
- Das heißt, Sie können den Bug-Tracker schneller nehmen, der Messenger ist schneller, aber es werden fünf verschiedene Tools sein und es wird schwierig sein, zwischen ihnen zu synchronisieren.
- Aber dann muss man mit allen konkurrieren. Atlassian einerseits. Schlaff wie ein Bote - auf der anderen Seite.- Ja, jetzt entwickeln nur die Faulen keine Projekt- und Produktmanagementsysteme.
- Tatsächlich gibt es jedoch nicht so viele Unternehmen, die in jeder Hinsicht mit uns konkurrieren würden.
- Ist Atlassian nicht so?- Er konzentriert sich mehr auf den IT-Markt. Zum Beispiel ist Jira für Designer zu kompliziert.
Es ist sehr schwer anzupassen. Es gibt sogar einen Beruf - Jira Setup Manager. Wir versuchen sicherzustellen, dass Sie auf die Website gehen, ein kostenloses Konto erstellen und das ist alles - vom ersten Tag an können Sie es problemlos verwenden.
- Sie sagen aber, dass Sie auch eng mit Kunden und direkten Managern zusammenarbeiten, die Prozesse etablieren.Ja, wir haben ein Team von Kundenerfolgs- und Bereitstellungsmanagern sowie ein ganzes System von Touren, Leitfäden, E-Books und Dokumentationen aller Art. Es gibt Manager, die Ihnen bei der Konfiguration von Wrike für vorgefertigte Prozesse helfen. Manchmal arbeiten sie mit großen Einzelkunden. Manchmal sofort mit vielen (zum Beispiel Webinare aufzeichnen). Selbst wenn eine Person eine Testversion registriert und das Produkt nicht verstanden hat, hat sie die Möglichkeit, live mit einem der Riker zu chatten und zu verstehen, wie das funktioniert.
- Im Allgemeinen ist die
Einführung eines Produkts in einem Unternehmen mit Tausenden von Benutzern eine weitere Aufgabe.
- Es ist passiert, dass es mit einem der großen Kunden sehr schwierig war?Je größer das Unternehmen ist, desto mehr Arbeitsprozesse hat es normalerweise - desto schwieriger ist es zu arbeiten. Wir lagern natürlich nicht aus. Es gibt so etwas wie Geldsäcke nicht und sagt: "Hier ist viel Geld für dich, tu mir so etwas." Unsere Produktmanager bestimmen die Produktentwicklungspfade selbst. Es gibt aber Kunden mit interessanten Anfragen.
Airbnb nutzt die Plattform beispielsweise in sehr ungewöhnlichen Fällen. Jede Wohnung und jede Person, die sie mietet, ist ein separates Projekt in Wrike.
Oder die Autofirma Coil [Name geändert]. Kunden bestellen bei ihnen Ersatzteile. Diesen Leuten falsche Konten zu geben, ist nur eine Idee. Sie werden nicht jeder Eigentümer von Coil sein, der Ihr Konto erstellt. Aber das Unternehmen wollte wirklich eine günstige Gelegenheit, mit Kunden zusammenzuarbeiten.
Natürlich haben wir nicht gesagt, dass wir im Moment eine solche Funktion für sie machen werden. Die Manager erkannten jedoch, dass sie das Produkt insgesamt verbessern würde. So wurden „externe Anfrageformulare“ für Personen angezeigt, die kein Wrike-Konto haben.
- Es stellte sich heraus, dass Sie für Coil [Name geändert] getan haben, aber passte es zu allen anderen?- Nicht wirklich. Wir haben gleichzeitig den Markt analysiert und Hypothesen aufgestellt - diese Aufgabe lag in einer möglichen Roadmap. Wenn es eine Anfrage gäbe, die überhaupt nicht zu uns passt, würden wir sie nicht tun.
Die interne Struktur von Wrike
Wir arbeiten an Scrum. Das Unternehmen ist nach Merkmalen in Teams unterteilt - jeweils etwa 10 Personen. Sie sind unterschiedlich zusammengesetzt, haben jedoch jeweils ein Backend, ein Frontend, einen Scrum-Master, eine Qualitätssicherung, eine Qualitätssicherungsautomatisierung, einen UX-Designer, einen Produktbeobachter und einen Produktanalysten (Analysten kommen manchmal in mehreren Teams zusammen). Eine solche Zusammensetzung ist voll funktionsfähig und kann ein Merkmal von und nach bilden.
Es gibt interne Teams, die Frameworks, Komponenten und Design-Kits erstellen und sich mit dem Übergang von einer Version einer Programmiersprache zu einer anderen befassen.
Einige Teams sind dem gesamten Unternehmen gemeinsam. Dies sind beispielsweise SysOps, die sich mit der Serverinfrastruktur befassen, und DevOps, die sich mit der Bereitstellung und Produktbereitstellung befassen. Wir haben ein- bis dreimal täglich Veröffentlichungen.
Teilweise verwenden wir auch die bekannte Spotify-Struktur bei Gilden. Zum Beispiel das Frontend, bei dem das Frontend aus allen Teams besteht. Es gibt Front-End-Leads, die sich mit Management und Architektur befassen. Und es gibt Gildenleiter.
Wir haben es noch nicht geschafft, sie von den Teams zu isolieren. Aber im Allgemeinen ist es logisch und organisch. Jetzt sind Leute mit hohen technischen Architekturkenntnissen in Infrastrukturteams.
Bei Wrike geht es nicht wirklich um eine bürokratische Struktur. Dies bedeutet jedoch nicht, dass in unserem Land Chaos herrscht. Wenn ein Mensch tut, was er will und es gut macht, hat er Wachstumschancen, unabhängig davon, welche Position er einnimmt.
- Und in welchem Büro wird was gemacht?- In den Büros von St. Petersburg und Woronesch. Wir haben 400 Mitarbeiter in St. Petersburg und 40 in Woronesch. Es gibt Büros in San Jose, San Diego. In diesem Jahr wird ein Büro in Prag eröffnet. Kürzlich erweitertes Büro in Dublin. Im Januar dieses Jahres wurde ein Büro in Melbourne, Australien, eröffnet.
- In amerikanischen Büros haben wir eine Verkaufsabteilung, Marketing, Manager (CSM). Dublin hat auch CSM und Vertrieb. Es gibt auch ein Analystenteam. In St. Petersburg - das größte und einheitlichste Büro. Hier haben wir Kundendienstmanager, Produktmanager, Analysten, Designer, Entwickler und Backoffice.
- Arbeiten alle in Büros oder sind Sie offen für einen entfernten Standort?- Remote-Scrum-Befehle sind sehr schwierig. Wir möchten, dass die Menschen eng und in Kontakt miteinander sind. In Abteilungen, in denen möglicherweise Remote-Arbeiten erforderlich sind (z. B. Kundensupport), schränken wir die Mitarbeiter nicht stark ein.
- Udalenka in Entwicklung - ein strittiger Punkt. Jetzt wird viel darüber geredet, in englischsprachigem Twitter diskutieren wir ständig dieses Thema. Es gibt Vor- und Nachteile. Unserer Meinung nach gibt es mehr „Nachteile“. Als Teammanager wäre es für mich schwierig, Produktivität und einen gemeinsamen Geist sicherzustellen, entfernte Mitarbeiter zu wachsen und zu coachen.
Wir haben einen ziemlich flexiblen Zeitplan, die Leute sitzen nicht streng zwischen zehn und sechs im Büro. Wenn es einen Stand-up gibt, seien Sie bitte freundlich - kommen Sie, und wenn es vorbei ist und wie lange es dauern wird, entscheiden die Teams selbst. Wenn etwas passiert, auch ohne Probleme - schreibt die Person, dass sie von zu Hause aus arbeitet.
- Wenn das Produkt international ist, müssen Entwickler häufig über gute Englischkenntnisse verfügen, um mit Kunden sprechen zu können.- Wir haben keine Kunden, wir sind keine Outsourcer. Das Unternehmen ist international und ein Teil der Kommunikation wird in der Tat auf Englisch geführt, dies gilt jedoch nicht für alle. Für Entwickler in Russland haben wir keine besonderen Anforderungen an Englischkenntnisse.
Einmal im Monat finden Treffen statt, bei denen wir über alle Veränderungen im Unternehmen und die finanzielle Leistung sprechen. Die Kommunikation mit dem Support erfolgt auf Englisch. Tickets mit Kundenfehlern sind natürlich auch in englischer Sprache erhältlich. Für diejenigen, die eine Sprache straffen oder lernen möchten, gibt es eine solche Möglichkeit - wir haben fortlaufende Klassen mit Lehrern, für Mitarbeiter sind sie frei.
Aber meiner Meinung nach kann ein Entwickler, wenn er gestern nicht mit der Entwicklung begonnen hat, Englisch zumindest auf der Ebene der Lesedokumentation. Ohne Zunge kann man gar nichts googeln.
Natürlich haben die Entwickler möglicherweise keinen echten britischen Akzent und es gibt kein Oxford dahinter, aber sie können normalerweise etwas sprechen und lesen.
Warum Dart besser ist als JavaScript und TypeScript
- Jetzt ist das alles ein großes komplexes System. Aber es ist vor langer Zeit aus der internen Entwicklung heraus gewachsen und hat sich seitdem sehr verändert. Aus diesem Grund gab es keine architektonischen Fehleinschätzungen, die jetzt das Leben beeinträchtigen?- Natürlich ist das Projekt groß. Wir haben im Backend entweder eineinhalb oder zwei Millionen Zeilen Java-Code. Das Frontend ist ebenfalls vergleichbar. Aber ich kenne keine einzige Person, die das System fünf Jahre im Voraus entwerfen kann, und es wird sich ohne Umbau entwickeln.
Es kommt vor, dass etwas fällt. Manchmal stellen wir fest, dass vor zwei Jahren dümmer waren. Dies ist jedoch aus Sicht des Ingenieurs selbstverständlich. Wie sonst?
- Daher gibt es interne Teams, die regelmäßig alte Teile neu schreiben.
- Ja, ich sage manchmal, dass wir uns hinsetzen und umgestalten müssen, sonst wird geschossen, damit alles geschossen wird. Wir setzen uns und überarbeiten. Architektur greift ein - wir machen Architektur.
- Was ist dein Stapel?- Im Java-Backend. SQL-Datenbank. Am vorderen Ende eine interessante Sache. Es war einmal JavaScript, aber wir stellten fest, dass es überhaupt nicht skalierbar war und entschieden uns für Dart.
- Was hast du gewählt?- Dart. Ja, das ist eine normale Reaktion. Eine getippte Sprache von Google, die mittlerweile fast sieben Jahre alt ist. Wir sind wahrscheinlich die wichtigsten Evangelisten dieses Stapels in Russland.
- Die wichtigsten oder die einzigen?- Übrigens entwickelt es sich jetzt aktiv. Google hat Flutter gestartet - dies ist ein solches mobiles Framework, das nur auf Dart geschrieben wurde. Es gibt eine
russische Dart-Community , die wir gegründet und unterstützt haben. Es gibt bereits ungefähr anderthalb Tausend Menschen. Nach den Standards von JavaScript ist dies natürlich nicht sehr beeindruckend, aber auch sehr beeindruckend.
Im vergangenen Dezember haben wir
die DartUp-Konferenz organisiert - es gab einen riesigen Saal und viele Leute kamen. Und viele verwenden Dart tatsächlich in der Produktion. Die Sprache entwickelt sich allmählich und ist sehr cool.
"Also sind wir jetzt zu Pferd." "In der Welt" zu sagen ist wahrscheinlich anmaßend, aber tatsächlich ist es das auch. DartUp ist die größte Dart-Konferenz der Welt. Noch mehr als Google.
- An der Konferenz nahmen ungefähr dreihundert Personen teil. Obwohl es vor zwei Jahren so schien, als wären wir allein auf dem Gebiet der Krieger.
- Das ist alles interessant, aber wie man an einem so großen Projekt arbeitet, wenn man keine Leute anstellt, gibt es keine Bibliotheken oder Frameworks.- Das ist ein Irrtum. Kürzlich haben wir einen Mann in das Team aufgenommen, für den Dart im Allgemeinen die erste Programmiersprache war.
- In Dart ist alles da. Dies ist eine Sprache aus der Kategorie C # und Java - alles, was Sie brauchen, ist dort eingebaut. Und es ist im Allgemeinen nicht wahr, dass dort alles leer ist und der Sturz herumrollt. Es ist noch mehr eingebaut als in einigen zwanzig Jahre alten Sprachen. Bibliotheken, Tools, Framework-Unterstützung - Angular ist auch da.
Natürlich gibt es keine Infrastruktur wie bei JS. Das Problem ist jedoch, dass Menschen, die Millionen von Bibliotheken schreiben, Millionen von schlechten Bibliotheken erhalten. Und vielleicht nur hundert normal.
Und wenn die Bibliotheken von Google geschrieben wurden, das Dart in AdWords und AdSense verwendet, ist die durchschnittliche Qualität viel höher.
Das Schöne an der Sprache ist, dass sie einfach und C-artig ist. Das heißt, wir stellen Entwickler in C ++, C #, Java, JavaScript ein - jeden. Wir benötigen keine Dartkenntnisse. Natürlich gibt es keinen Dartentwickler auf der Straße.
In meinem Team gibt es einen Entwickler mit der Erfahrung von C Sharp, der weiß. An der Front hat er noch nie geschrieben. Und in fünf Tagen hat er ein Feature abgewaschen. Weil die Sprache so ist, als hätten Sie Ihr ganzes Leben lang darüber geschrieben.
In guter Weise schreiben Entwicklungsingenieure Geschäftslogik, egal in welcher Sprache.
"Aber die Leute fangen nicht an, in ihrer alten Sprache zu schreiben?" Die gleichen JS-Spitznamen kamen von einer dynamischen zu einer statischen Sprache.- Daher ist unser Auswahlverfahren nicht das einfachste. Aber fair und ehrlich.
- Ok, warum ist die Sprache gut?Ich würde sagen, es ist eines der am stärksten typisierten, das in JS kompiliert wird. Als wir vor vier Jahren am Frontend saßen und ungefähr acht von uns waren - Sie können sich zumindest mit allen möglichen Lintern, Regeln und allem auf der Welt abdecken -, aber er wird immer noch etwas vermissen. Wir brauchten eine statische Eingabe, so streng wie möglich.
Wenn Sie auf Dart etwas falsch schreiben, werden Sie es sofort verstehen. Es hat eine frühere Fehlererkennung, die es auch ohne Testen des Codes ermöglicht, zu verstehen, ob es funktioniert oder nicht.
Es gibt kein Chaos in der eingebauten Bibliothek, wenn eine aktualisiert wird und die andere abfällt. Weil das SDK mit der Sprache geliefert wird, die sicherstellt, dass nach dem Upgrade alles funktioniert. Sie müssen nicht eine Million Bibliotheken verbinden, um Streams und Streams zu erhalten - alles ist bereits vorhanden.
Derzeit gibt es zwei Sprachen, mit denen Sie für alle Plattformen schreiben können - für Mobilgeräte, für Backends, für Desktops und für das Web. Das sind JS und Dart. JS Nachteile wissen, wie viele. Und Dart hat ein großes Plus - Tippen.
Daher gibt es nur eine fest eingegebene Sprache, mit der Sie für alle Plattformen mit normaler Optimierung schreiben können. Viele zitieren Kotlin als Beispiel, aber für das Web ist es nicht sehr.
- Bedauern Sie jetzt nicht, dass beispielsweise TypeScript nicht ausgewählt wurde?- Nicht jetzt, aber im Prinzip bereuen wir es nicht. Ich rate Ihnen, den Bericht von Victor Logov von JetBrains auf der HolyJS-Konferenz zu sehen. [
Der Redner hat den Namen wahrscheinlich verwechselt, und es war ein Bericht von Anton Lobov. ]
Sie unterstützen TypeScript in ihren Produkten und stellen TS dort vernünftigerweise nur in die Regale. Und danach gibt es überhaupt keinen Wunsch mehr, es zu nehmen. Man hat das Gefühl, dass darin Merkmale nach dem Prinzip „Lasst uns das hinzufügen? Komm schon. "
- Damit ich glaube, sag mir, was in Dart schlecht ist? Es kann nicht sein, dass alles perfekt ist.Leicht. Es gibt Probleme, aber nicht mit der Sprache, sondern mit Google. Sie verwenden viele Werkzeuge im Inneren, die nicht herauswühlen. Wir haben jetzt einen direkten Kanal mit Google, wir sind Teil einer Reihe interner Organisationen und diese geben diese Tools langsam weiter.
Dies ist jedoch nur für uns relevant, für eine sehr große Codebasis. Kleine Projekte haben überhaupt keine Probleme.
- Nach der Erfahrung mit Dart wollten Sie Java nicht durch Go ersetzen?- Warum? Wir haben Dart nach bestimmten Parametern ausgewählt. Es war eine ausgewogene Entscheidung.
- Einer unserer Redner sagt, dass es Unternehmen gibt, die alles mit neuen Technologien umschreiben, und es gibt Unternehmen, die Geld verdienen. Das Umschreiben sollte kein Selbstzweck sein. Es gibt Geschäftsaufgaben und Tools, die diese implementieren sollten.
- Wir experimentieren mit verschiedenen Technologien. Wenn wir irgendwann verstehen, dass Go besser funktioniert, werden wir es versuchen.
Am Frontend bewegen wir uns in Richtung unabhängiger Anwendungen. Im Backend befindet sich ein Monorepository. Dies hat viele Vorteile, aber auch bestimmte Nachteile - darüber können Sie lange sprechen. Wir konzentrieren uns auf eine Microservice-Architektur, die auf dem basiert, was in unserer Umgebung nützlich sein wird.
Die Microservice-Architektur funktioniert gut, wenn nur wenige Verbindungen bestehen. Wenn Sie viele Verbindungen haben, werden Microservices zu Schmerzen. Es gibt keine Silberkugel. Zu diesem Zweck haben wir ein ganzes Team, das untersucht, was in unserer Umgebung am besten verwendet wird.
Einstellung von Ingenieuren, keine Sprachexperten
- Was müssen Sie sein, um zu Ihnen zu gelangen?- Wir nehmen Leute mit, die daran interessiert sind, was sie tun. Dies ist ein Klischee - über brennende Augen. Dies ist jedoch wichtig. Selbst wenn Sie ein guter Entwickler sind, es Ihnen aber egal ist, was Sie schneiden sollen, wenn Sie nur von zehn auf sechs arbeiten und Geld erhalten - mit hoher Wahrscheinlichkeit wird dies nicht zu uns passen.
- Wir nehmen Menschen, die lernen, sich entwickeln wollen. Wenn Sie denken, dass bereits alles erreicht wurde und jetzt der König der Welt auch nicht unsere Option ist.
- Da wir einen ziemlich guten Feedback-Kanal vom Entwickler zum Unternehmen und umgekehrt haben, ist der Ansatz „Hier arbeiten“ nicht sehr geeignet. Wir versuchen, Leute einzustellen, die bereit sind, ihre Vision anzubieten, sie haben Meinungen und Fragen.
Dies bringt das Projekt viel schneller voran, als wenn Sie drei Super-Senioren einstellen, die sagen: "Meine Arbeitszeit ist abgelaufen und Sie bezahlen mich im Allgemeinen nicht genug." Sie werden weniger tun als die Person, die das Projekt an einem Tag beim Hackathon schneidet und es in Produktion bringt.
- Wir suchen Menschen, die sich interessieren und daran interessiert sind, vorwärts zu kommen.
- Also bin ich zu dir gekommen und habe gesagt, dass ich alle so zielstrebig bin, ich habe viel von meiner Meinung, meine Augen brennen. Ich stocherte sie immer noch mit etwas zum Leuchten an, sage ich, nimm mich. Also nimm es?- Interviews sind nicht so einfach. Wir schaffen arbeitsnahe Bedingungen und beobachten, wie sich eine Person zeigt. Wenn Sie Entwickler sind, schreiben Sie Code. Wenn eychar - werden Sie interviewen.
- Wird der Entwickler den Code beim Interview schreiben?— , , .
, , . , , , , .
: « React-», — . React, ?
, . . , JS. : « Jira Wrike. ?»
, — Go, . , . , , .
— , , « », ?— . , . . , , . — . . , .
, , . , , ? . , … — , « ».
— . ?— .
Wrike , , . , . , , , .
— ?— . Gantt-. Canvas, . , , Google — , Dart . , .
— , - , ?— . . , -. Wrike, . , - , .
— ? , 400 . ?— . — . , . Cultural fit, , .
— . , ?— -5 . — . , . , , ? , .
— , , ?— , - . , , , .
— , , . . . . , , — .
— , ?- Nein. . - .
— , ?— . , . , , , . .
— . Wrike — safe place. Google , — . , .
, , — .
— , ?- Kritisieren ist nicht ganz das richtige Wort. Stellen Sie sicher, dass Sie Feedback benötigen. Wir sind nicht hier, um die Schuldigen zu suchen - wir sind hier, um die Arbeit effizient zu erledigen.