Versi dua jam penuh dapat dilihat di saluran YouTube Hexlet .
Daftar Isi:
Produk dan Sejarah Perusahaan
Bagaimana pengembangan produk bekerja
Pemilihan dan evolusi teknologi
- Flash → Kanvas
- Angular → Bereaksi
- Server dan database
- Jawa
- Menguji evolusi
- Beban pertumbuhan dan pemfaktoran ulang
Proses dalam pengembangan
- Solusi teknis dan tinjauan kode
- Review Kinerja
- Bagaimana Mempekerjakan Insinyur Bekerja
- Posisi junior
Produk dan sejarah perusahaan
Miro adalah platform papan tulis kolaboratif online untuk kolaborasi visual. Kata kuncinya adalah kolaborasi, kolaborasi, masing-masing, metrik utama yang digunakan untuk mengukur efektivitas kami adalah jumlah dewan kolaborasi dan sesi kolaboratif yang terjadi dalam produk.
Kami menyebut diri kami sebagai platform karena kami telah melampaui sekadar produk: kami memiliki API terbuka, pasar, kantor pengembang, sehingga perusahaan mana pun dapat mengembangkan produk untuk dirinya sendiri.
Target audiens kami adalah tim produk yang beroperasi dari kantor yang sama atau berbeda. Paling sering, Miro digunakan untuk melakukan lokakarya, sesi strategis, brainstorming, praktik gesit (perencanaan, retrospektif).
Saya memimpin pengembangan di Miro. Saya dibesarkan di Perm dan terus tinggal di sini. Secara historis, perusahaan muncul di Perm, tempat asal pendiri kami. Sebagian besar departemen pengembangan kami sekarang ada di sini, dan pada 2019 kami meluncurkan dan secara aktif mengembangkan kantor teknik kedua di Amsterdam.
Sebelumnya, saya bekerja dalam pengembangan kustom: Saya memulai dengan membangun gudang data analitik sebagai pengembang, lalu saya mendesainnya, dan kemudian memimpin proyek besar. Pada 2016, ia bergabung dengan Miro saat perusahaan mempekerjakan 30 orang. Sejak itu, kami telah berkembang pesat: sekarang kami memiliki lima kantor, 400 orang, 140 di antaranya adalah insinyur.
Perusahaan didirikan pada tahun 2011. Fungsi terbesar kami adalah dan tetap menjadi pengembangan produk, yang saat ini menyumbang sekitar setengah dari perusahaan.
Perubahan nama
Kami berpikir untuk mengubah merek kembali pada tahun 2015, tetapi akhirnya melakukannya pada tahun 2018. Nama kami sebelumnya RealtimeBoard panjang dan rumit. Itu sering salah, disingkat RTB, atau yang paling parah, sama sekali terlupakan. Selain itu tidak emosional, tidak ada cerita di baliknya. Kami ingin membuat nama baru itu pendek, luas, berbicara, mudah diingat.
Alhasil, kami terinspirasi oleh karya seniman Joan Miró dan memilih nama belakangnya sebagai judul. Riset itu sendiri dan pemilihan namanya memakan waktu beberapa bulan, lalu kami meluncurkan merek baru selama beberapa bulan. Mengikuti jejak proyek ini, terdapat serangkaian artikel tentang bagaimana pekerjaan pada proyek tersebut diatur, dan artikel terpisah tentang masalah teknis yang kecil namun tidak sepele untuk migrasi pengguna resmi dari domain lama ke domain baru.
Kami dan pengguna dengan cepat terbiasa dengan nama baru tersebut. Kami berkembang pesat, sehingga beberapa juta pengguna baru bahkan tidak tahu bahwa kami dipanggil secara berbeda. Bonus rebranding yang menyenangkan adalah penghargaan dari European Design Awards untuk identitas, yang kami kembangkan sebagai bagian dari rebranding bersama dengan agensi Eropa Vruchtvlees .
Bagaimana pengembangan produk bekerja di Miro
Seluruh tim pengembangan produk yang terdiri dari 170 orang berlokasi di Perm dan Amsterdam: insinyur, produk, perancang produk, ahli scrum.
Sebelumnya, sulit bagi saya untuk membayangkan begitu banyak orang dapat mengerjakan satu produk. Tapi hari ini, saya tahu ada ribuan insinyur yang mengerjakan produk yang sama di Uber, Slack, dan Atlassian. Kami terus tumbuh dan memahami bahwa kami jelas tidak cukup sekarang, dan target poin berikutnya di kepala saya adalah 300 orang dalam pembangunan, dan kemudian kami akan terus berkembang lebih jauh. Ini bukan hanya angka yang keluar dari kepala Anda. Kami memiliki perencanaan strategis, kami memahami di mana kami ingin berada dalam dua tahun, dalam lima tahun dan apa yang perlu kami lakukan untuk ini.
Dari segi struktur organisasi, ada guild: frontend, backend, QA, dan sebagainya. Untuk mengerjakan proyek, mereka digabungkan menjadi tim lintas fungsi.
Tim didistribusikan di area utama:
- Produk horizontal adalah fungsi produk utama yang dilihat semua pengguna: stiker, teks, bentuk, bingkai, dll.
- Arah sistem - bertanggung jawab atas platform inti dan infrastruktur.
- Pertumbuhan - segala sesuatu tentang pertumbuhan jumlah pengguna: aktivasi, keterlibatan, pengembalian, monetisasi.
- Enterprise — , . -, Miro, . -, SaaS-, . , , .
- — 2019 . API, , marketplace, — , , .
- — , . , , , Miro, : Meetings & Workshops, Ideation & Brainstorming, Research & Design, Agile Workflows, Strategy & Planning, Mapping & Diagramming.
: , , . , . , : - .
Perangkat lunak utama para insinyur: IntelliJ Idea, Jira, Slack, Zoom, Miro, Confluence. Sebagian besar karyawan bekerja di MacBook, sebagian besar teknisi bekerja di MacBook Pro, dan untuk beberapa kami membeli mesin yang lebih canggih saat diperlukan.
Kami menggunakan produk kami sendiri setiap hari: rapat internal, lokakarya, sesi curah pendapat, perencanaan.Ini memungkinkan Anda untuk dengan cepat menguji semua inovasi dalam produk dan sangat menyederhanakan adaptasi dari pengembang baru yang, sejak hari pertama, bekerja dengan produk tidak hanya dalam hal kode, tetapi juga sebagai pengguna. Ini adalah bagian penting dari budaya kita - kita membuat produk yang kita sendiri harus nyaman dan menyenangkan untuk digunakan.
Tumpukan, monolit
Bagian depannya adalah Typecript, React dan AngularJS. Backendnya adalah Java. Database - Redis, Postgres, untuk komunikasi cluster - Hazelcast dan ActiveMQ. Kami menghosting di Amazon, di pusat data yang sama. Ada sekitar 400 server dalam produksi. Server aplikasi yang memproses papan pengguna dapat mencapai 100, semuanya diatur secara otomatis.
Kami menggunakan tumpukan dari Atlassian: Jira, Bitbucket, Bamboo dan skrip kami sendiri yang dibaut ke Bamboo dan memungkinkan semuanya untuk diluncurkan ke server. Sejauh ini, semua rilis adalah rilis depan besar dan rilis belakang besar. Sekarang kami berpikir bagaimana membuat lebih banyak rilis ini.
Aplikasi utama kami adalah monolit modular: ada modul yang bertanggung jawab untuk API, untuk papan, untuk fungsi layanan. Monolit diterapkan dalam modul ke server yang diperlukan, dan tidak dalam satu bagian besar ke semua server dalam satu baris, artinya, kami juga memiliki server dengan peran berbeda.
Di dalam aplikasi, ada banyak integrasi dan layanan tambahan yang langsung kami lakukan secara terpisah dan yang dirilis oleh tim secara terpisah dari bagian depan dan belakang lainnya.
Ketika Anda memiliki perusahaan kecil, jauh lebih mudah untuk memulai dengan monolit dan tidak memagari infrastruktur untuk layanan. Tetapi sekarang kami telah memahami bahwa satu monolit umum tidak memberi kami kemampuan untuk mengukur arah individu (produk horizontal, platform, perusahaan, dll.), Jadi kami mengembangkan pendekatan untuk meninggalkan satu monolit.
Rilis
Perakitan sendiri membutuhkan waktu 15-20 menit, termasuk pelaksanaan unit test. Tes ujung-ke-ujung bisa memakan waktu hingga 40 menit. Seluruh proses membutuhkan satu setengah hingga dua jam untuk membawa master untuk melepaskannya. Ini waktu yang lama, kami masih memiliki pekerjaan yang harus dilakukan di sini.
Mungkin ideal untuk merilisnya setiap lima menit. Tapi untuk ini kami belum memiliki tim yang besar dan penonton harian yang tidak begitu banyak. Audiens yang besar penting untuk sering merilis, karena ini memungkinkan Anda dengan cepat memastikan bahwa semuanya baik-baik saja dengan meluncurkan perubahan kepada sebagian kecil pengguna.
Pemilihan dan evolusi teknologi
Saya percaya bahwa pilihan teknologi harus diperlakukan seperti ini: apa pun yang Anda pilih, Anda tetap harus mengubahnya suatu saat nanti, terutama jika perusahaan dan produknya berkembang. Oleh karena itu, proses perubahan teknologi adalah normal. Teknologi itu penting, tetapi perlu diperlakukan secara berbeda pada berbagai tahap perkembangan perusahaan.
Perusahaan kecil yang baru memulai dan mencari kesesuaian pasar produk berjalan cepat, mengumpulkan MVP dengan cepat, dan membuangnya dengan cepat. Menemukan pasar lebih penting bagi mereka, daripada menciptakan solusi teknis yang kompleks. Tetapi ketika pasar ditemukan, solusi teknis mengemuka, karena mereka memungkinkan Anda menciptakan margin keamanan untuk pertumbuhan dan keamanan.
Kami pertama kali mencoba memahami masalah yang ingin kami selesaikan dengan mengubah teknologi. Kemudian kami melakukan banyak penelitian, mencari alternatif, menguji kinerja. Ini dilakukan dengan solusi teknis apa pun yang akan kami terapkan: "jangan mengambil hal pertama yang pertama kali Anda dengar di pasar, tetapi teliti dan pelajari apa yang paling cocok untuk memecahkan masalah".
Dalam produk dan tim besar, perubahan teknologi adalah keputusan strategis yang penting; hal itu dapat menyebabkan penghentian sebagian atau seluruhnya dalam pengembangan produk, mengalihkan tim ke tugas baru, dan seterusnya. Ini panjang dan mahal, tetapi jika ini tidak dilakukan tepat waktu, masalah yang muncul dapat membawa lebih banyak kesulitan.
Kami mengalami beberapa perubahan teknologi besar, di depan dan di belakang. Berikut ini beberapa contohnya.
Flash → Kanvas
Hingga 2015, seluruh front ada di Flash, lalu Flash mulai mati dan kita beralih ke HTML dan Canvas. Perubahan tumpukan memiliki efek yang baik pada kinerja dan kegunaan produk, dan menyebabkan peningkatan yang nyata dalam jumlah penonton. Transisinya memakan waktu sekitar satu tahun, itu adalah proyek yang besar dan kompleks. Artikel tentang detail proyek ini .
Saat ini kami sedang mempertimbangkan untuk bermigrasi ke WebGL, tetapi belum ada bukti yang jelas bahwa itu sepadan.
Angular → Bereaksi
Selama beberapa tahun terakhir, kami telah secara bertahap berpindah dari Angular JS ke React. Alasan utama:
- React memungkinkan pengetikan yang lebih baik, dan nanti memungkinkan Anda untuk refactor kode Anda lebih baik dan memastikan tidak ada yang jatuh.
- React . «» , Angular . Angular, React, .
- React , Angular JS .
Pada 2015, kami beralih dari server sewaan Hetzner ke hosting Amazon. Selama lebih dari setahun, telah ada proyek untuk memindahkan database utama dari Redis ke PostgreSQL. Kami memiliki artikel tentang ini: manajemen proyek migrasi data , membuat cluster failover .
Kasus kami diperumit oleh fakta bahwa dari Nilai Kunci penyimpanan kami pindah ke database SQL. Ada banyak refactoring. Penting untuk melakukan segalanya agar aplikasi tidak berhenti. Ini seperti mengganti roda mobil yang bergerak, karena database adalah fondasi aplikasi. Untuk konten papan, kami sebenarnya melakukan semuanya tanpa pemeliharaan. Ya, proses transisi ditunda, tetapi pengguna tidak melihat apa pun, produk berfungsi.
Stabilitas produk adalah fokus utama. Pengguna menyimpan banyak konten di Miro. Karenanya, jika pengguna telah menjadwalkan sesi atau rapat, menyiapkan papan konten untuk itu, dan produk tidak tersedia pada saat itu, ini adalah kegagalan, konten tidak dapat digunakan. Meskipun Zoom bersyarat dapat dengan cepat diganti dengan Hangouts, konten tidak dapat diganti dengan cepat. Oleh karena itu, salah satu tugas utama kami adalah memastikan bahwa konten untuk pengguna selalu tersedia.
Jawa
Java sangat membantu kami dalam hal produktivitas dan sumber daya pengembang yang dapat kami temukan. Saya tahu bahwa Booking beralih dari Pearl ke Java karena mereka lelah melatih ulang teknisi mereka.
Insinyur dari C ++ dan .Net mendatangi kami dan beradaptasi secara normal. Jika Anda adalah pengembang yang berpengalaman, telah mencoba berbagai teknologi dan mengetahui bagaimana sistem dibangun, maka tidak terlalu sulit untuk terjun ke bahasa baru. Hal utama adalah bahwa insinyur itu menemukan solusi yang tepat, dan dia pasti akan bisa mengubur dirinya sendiri di lidah, saya percaya ini.
Menguji evolusi
Awalnya, kami hanya melakukan pengujian manual. Rilis diluncurkan setiap dua hingga tiga minggu, persiapan untuk rilis membutuhkan waktu seminggu: Anda melakukan pengujian regresi dalam beberapa hari → menemukan bug penting → mengoreksi → pengujian manual lagi. Ketika ada beberapa tim, itu berhasil, tetapi dengan dua puluh tim tidak mungkin untuk menguji semuanya secara manual.
Jadi kami mulai berpikir tentang otomatisasi. Pertama-tama, kami menulis tes otomatis untuk sepenuhnya menyingkirkan pengujian regresi. Sekarang kami sedang menyiapkan proses manajemen kualitas yang benar di seluruh siklus pengembangan. Semakin awal kita memikirkan kualitas, semakin awal kita akan menemukan kasus edge, memahami cara mengujinya - ini pada akhirnya akan mengurangi biaya dan mempercepat proses pengembangan. Bug yang Anda temukan sedang dijual tidak hanya sepadan dengan waktu dan sumber daya untuk mengembalikan rilis dan memperbaikinya. Bug memengaruhi keseluruhan pengalaman pengguna produk, dan sangat mahal untuk memperbaiki pengalaman itu.
Kami memiliki serikat QA, di mana para insinyur membuat keputusan tentang proses apa yang perlu kami terapkan sekarang, mengembangkan strategi kualitas, dan kemudian setiap insinyur QA membantu timnya mengimplementasikan proses ini di negara mereka sendiri:
- QA- -, . QA , . .
- QA , .
- QA , , .
Rilis kenari juga merupakan cara pengujian, saat kami meluncurkan fitur ke audiens kecil dan memeriksa apakah kami melewatkan sesuatu. Kami meluncurkan fitur baru yang besar melalui kotak centang, diluncurkan ke pengguna beta yang telah menyatakan keinginan untuk berpartisipasi dalam pengujian beta (manajer produk kami akan mempelajarinya selama wawancara penelitian). Jumlah pengguna beta dan alfa harus mencakup tim kami, kami benar-benar meluncurkan semua fungsi baru untuk diri kami sendiri sejak awal.
Penjelasan terperinci tentang semua tahapan proses QA kami .
Beban pertumbuhan dan pemfaktoran ulang
Karena pergeseran besar-besaran ke teleworking pada tahun 2020, basis pengguna kami telah meroket, dan infrastruktur tahunan serta ketahanan aplikasi kami habis dalam beberapa minggu. Pada minggu pertama peningkatan tajam dalam beban, kami menghentikan semua pengembangan produk dan mengarahkan tim untuk bekerja pada toleransi kesalahan dan kinerja.
Margin keamanan diperlukan tidak hanya di bagian belakang, tetapi juga di bagian depan dan klien, karena jumlah pekerjaan sinkron dalam produk meningkat. Jika sebelumnya 20 orang bisa bekerja di satu papan pada waktu yang sama, sekarang menjadi 300 orang. Teknisi front-end kami telah melakukan banyak hal dan terus mengerjakan kinerja beban. Misalnya, kami membuat dasbor dengan daftar papan memuat secara terpisah dari yang lainnya dan melakukannya lebih cepat dari sebelumnya. Dan jika pengguna masuk langsung ke papan, bukan melalui dasbor, maka kode dan konten papan harus dimuat, tanpa yang lainnya.
Kami akan banyak merefaktor sehingga pengguna mendapatkan umpan balik dan konten dari papan lebih cepat, dan kemudian semua fungsi utama - skrip, antarmuka - perlahan naik. Untuk melakukan ini, kami beralih ke membagi kode, menjadi modul "malas". Berkat ini, kami telah berakselerasi sekitar sepertiga, dan bulan depan kami berencana untuk mempercepat dua kali lebih banyak dalam hal pemuatan.
Ini sama dalam hal kinerja di papan - ada perang yang terjadi atas kecepatan dan sumber daya komputer yang digunakan pengguna.Tidak semua orang online dengan mesin yang bagus; seseorang menarik laptop rumah tua berkinerja rendah dari rak. Tetapi produk kami harus berfungsi dengan baik di laptop mana pun. Ini adalah trik besar lainnya yang sedang kami kerjakan saat ini.
Proses dalam pengembangan
Solusi teknis dan tinjauan kode
Setiap tugas dimulai dengan persiapan solusi produk. Solusi produk adalah jawaban atas pertanyaan "Apa yang akan kita lakukan?". Manajer produk berdasarkan strategi produk dan OKR sedang melakukan banyak penelitian untuk mengetahui apa yang saat ini hilang dari pengguna dalam produk kami. Berdasarkan penelitian, produk menjelaskan solusinya. Guild makanan membahas solusinya, merevisinya jika perlu.
Berdasarkan solusi produk, solusi teknis dibentuk yang menjawab pertanyaan "Bagaimana kita akan melakukan ini?" Ini dikembangkan oleh para insinyur tim yang akan mengimplementasikan fungsionalitas tersebut. Solusi teknis melalui beberapa proses tinjauan:
- dengan tim yang memiliki fungsi persimpangan;
- tinjauan keamanan dari komponen yang akan kita bahas dalam arsitektur;
- bagaimana kami akan menyebarkan hasilnya.
Setelah itu, pengembangannya sendiri dimulai. Penting agar tinjauan kode tidak memperlambat pengembangan, jadi baru-baru ini, alih-alih menerima dua tinjauan kode secara wajib, kami memperkenalkan tanggung jawab pribadi pada tingkat komponen. Sekarang, di tingkat kode, kami selalu tahu siapa yang bertanggung jawab atas bagian ini, yang sangat memudahkan komunikasi selama pengembangan. Karenanya, segera setelah Anda membuat perubahan pada kode, peninjau secara otomatis ditetapkan, sebagai pemilik kode ini. Jika kode tersebut milik Anda, maka peninjauan dilakukan oleh anggota tim Anda.
Mengapa kami memperkenalkan tanggung jawab pribadi? Dulu ada beberapa orang, "oldies", yang tahu bagaimana keseluruhan produk bekerja dan dapat memeriksa kode apa pun. Tetapi seiring dengan berkembangnya produk, kemampuan orang-orang ini mulai berkurang, mereka tidak dapat lagi mengetahui tentang segala sesuatu yang terjadi dalam pengembangan tersebut.Proses peninjauan kode mulai memperlambat sisa proses, tidak jelas siapa yang harus dituju untuk peninjauan kode. Kemudian kami mulai membawa semua kompetensi yang diperlukan untuk blok produk tertentu ke tim yang mengerjakannya. Jadi tim dapat melakukan tinjauan kode sendiri. Pada suatu waktu, ini membantu kami mempercepat banyak hal.
Review Kinerja
Perusahaan memiliki nilai, berkat itu kami memahami siapa yang memiliki kompetensi apa, kelas apa yang sesuai dengan mereka, dan yang terpenting, apa yang perlu dilakukan setiap orang untuk melanjutkan. Tinjauan Kinerja dilakukan dua kali setahun, membantu menangkap gambaran di mana setiap orang sekarang, dan mendapatkan umpan balik yang dipersonalisasi.
Berdasarkan gambar ini, pemimpin tim membentuk rencana pengembangan pribadi dengan setiap anggota tim: karyawan itu sendiri mengatakan di mana dia ingin berkembang, dan Tinjauan Kinerja menyoroti kekuatan dan celahnya.
Kemudian secara rutin, setiap satu hingga dua minggu sekali, team lead bersama karyawan mengadakan pertemuan 1: 1, di mana antara lain mereka berdiskusi dan melacak pergerakan ke arah yang direncanakan. Setelah satu setengah tahun, berdasarkan hasil gerakan ini, ada kenaikan pangkat dan gaji.
Semuanya persis sama dengan pemimpin tim, selain itu ada pelatihan eksternal dan pendampingan eksternal untuk mereka.
Sayangnya, orang sering kali tidak tumbuh secepat perusahaan - tidak apa-apa. Kami siap berinvestasi banyak dalam pelatihan, karena pertumbuhan perusahaan secara langsung bergantung pada pertumbuhan karyawan. Kami memiliki kompensasi untuk kursus eksternal, kami telah merekomendasikan kursus dan mentor. Kami mengkompensasi pelatihan wajib 100% (misalnya, bahasa Inggris), kami mencoba untuk mengganti 50 hingga 50 sisanya, sehingga ada tanggung jawab bersama untuk hasilnya.
Kami jarang pergi ke konferensi. Kami mencoba memilih hal-hal yang berbicara tentang teknologi dan kasus yang saat ini relevan bagi kami dan yang kami tidak memiliki cukup pengetahuan.
Bagaimana Mempekerjakan Insinyur Bekerja
Rantai rekrutmen kami adalah standar untuk Rusia dan Eropa. Di Rusia, corong perekrutan sudah sempit, jadi wawancara pertama dapat dilakukan bukan oleh perekrut, tetapi oleh manajer perekrutan (biasanya pemimpin tim dari tim tempat kita mempekerjakan seseorang) setelah perekrut memproses resume dan menyingkirkan lowongan yang tidak sesuai dengan persyaratan.
Saya merasa bahwa di Rusia jauh lebih sedikit insinyur yang secara aktif mencari pekerjaan, dibandingkan dengan Eropa, karena mereka tidak ingin mengambil risiko. Dan ketika banyak perusahaan memasuki zona risiko karena isolasi, orang-orang menjadi semakin tidak tertarik untuk mengambil risiko dan berganti pekerjaan.
Bagaimanapun, rantai perekrutan dimulai dengan wawancara telepon penyaringan dengan kandidat, yang dilakukan oleh perekrut atau manajer perekrutan. Tujuan dari penyaringan adalah untuk memahami dengan cepat bagaimana seorang kandidat memenuhi persyaratan utama dari lowongan tersebut.
Setelah penyaringan, tugas tes, kemudian wawancara teknis, yang mencakup, antara lain, diskusi tentang tugas tes. Kemudian - pertemuan dengan tim tempat kandidat akan bekerja. Bagi kami, ini adalah langkah wajib, karena membantu pertama-tama untuk memahami kesesuaian budaya dari kandidat, dan bukan keterampilan teknisnya.
Setelah semua wawancara, kami mengumpulkan umpan balik dari para peserta, mengajukan penawaran.
Untuk mengevaluasi tugas tes, kami menggunakan sistem poin, lalu kami memberi peringkat pada hasil dan melihat hasil terbaik. Di posisi senior, terkadang kami membatalkan tugas tes jika kandidat memiliki gudang publik yang baik.
Posisi junior
Sebelum pindah ke pekerjaan jarak jauh, kami mulai bekerja dengan spesialis junior: kami mempekerjakan Juns, lulusan, meskipun tidak terlalu aktif. Sekarang kami telah sepenuhnya membekukan cerita ini, karena sangat sulit untuk memasukkannya ke lokasi terpencil, dan kami hanya memiliki sedikit pengalaman sejauh ini. Oleh karena itu, kami fokus pada perusahaan menengah dengan pengalaman minimal 3-4 tahun.
Tetapi bahkan ketika kami bekerja dengan Juniors, penting bagi kami bahwa mereka dapat tumbuh hingga menengah dalam setahun, sehingga mereka dapat belajar dan beradaptasi dengan sangat cepat.
Persyaratan perekrutan tinggi
Ada legenda bahwa sangat sulit bagi kami untuk mendapatkan pekerjaan karena persyaratan yang sangat tinggi. Ini tidak sepenuhnya benar.
Kami sering diwawancarai oleh kandidat dengan posisi Team Lead yang menurut kriteria internal kami menengah. Hal ini terjadi karena, dalam mengejar posisi, mereka mendatangi perusahaan yang siap memberikan posisi di atas kompetensi mereka saat ini dengan beberapa langkah, hanya untuk merekrut seseorang. Akibatnya, akibatnya adalah tindakan merugikan: orang tersebut belum terpompa ke tingkat yang disyaratkan, tetapi dia sudah menempati posisi yang tinggi; maka dia tidak akan bisa meninggalkan perusahaan begitu saja, karena dia tidak akan dipekerjakan untuk posisi yang sama di perusahaan lain.
Pemblokir terbesar dalam perekrutan adalah bahasa Inggris. Sebelumnya, kami dapat merekrut tanpa pengetahuan bahasa Inggris, tetapi sekarang ini tidak mungkin, dan tidak mungkin untuk memompa dalam beberapa bulan: seorang insinyur dari minggu-minggu pertama pekerjaan perlu membaca dokumentasi dalam bahasa Inggris, berkorespondensi dalam bahasa Inggris dengan rekan kerja, menghadiri rapat umum, yang sebagian besar diadakan dalam bahasa Inggris bahasa.
Produk berkembang, tugas baru yang menarik muncul, jadi kami selalu memiliki banyak posisi terbuka di bidang teknik baik di Perm maupun di Amsterdam.