Dalam artikel sebelumnya
tentang menerapkan metodologi Agile di startup kami, saya sebagian membahas masalah manajemen personalia. Dalam artikel ini saya akan memberi tahu Anda bagaimana kami merekrut staf ini, klasifikasi apa yang kami gunakan, tes dan metode apa yang kami verifikasi profesionalisme dan kecukupannya.
Model Perekrutan
Seperti di perusahaan muda mana pun, pekerjaan kami di bidang pemilihan personil dimulai dengan pengembangan model perekrutan. Situasinya adalah sebagai berikut: kami sudah memiliki tim karyawan "asli", semuanya terampil dan bekerja di posisi senior. Orang-orang ini harus dibongkar entah bagaimana, yaitu, tidak perlu spesialis pasar untuk mendapatkan kompetensi, oleh karena itu, selama periode ekspansi aktif staf, jumlah kursi kosong yang berlebihan adalah posisi Juni. Sebelum menempatkan lowongan di situs rekrutmen, kami memutuskan untuk menyusun klasifikasi internal kami sesuai dengan tingkat kualifikasi dan sesuai dengan persyaratan untuk berbagai kategori pengembang.
Klasifikasi berikut diturunkan:
Level 0 - pengembang fullzero, seseorang menjalani beberapa kursus, mempelajari konstruksi dasar dan semantik dari bahasa tertentu, membaca beberapa artikel tentang Haber tentang topik-topik hype, sebagai hasilnya, ada stiker maksimum pada laptop dari programmer.
Level 1 - pengembang junior, orang yang menulis kode dengan baik, tahu tumpukan dengan baik, mengetahui tren saat ini, tahu bagaimana menguraikan masalah dan menyelesaikannya sendiri.
Level 2 - pengembang menengah, seseorang memiliki semua kualitas junior di atas, dan juga mampu mengekspresikan pendapat kompetennya tentang masalah yang diselesaikan berdasarkan analisis sumber daya, dan dapat memengaruhi jalannya implementasinya dalam kerangka toolchain yang dipilihnya.
Level 3 - pengembang senior, dia juga seorang pemimpin, dia adalah ayah, ayah, orang yang mengubah dan memproyeksikan tugas-tugas dari pesawat bisnis ke pesawat pengembangan, mendistribusikan tugas-tugas ini pada middles dan Juni, mengendalikan dan membantu pelaksanaannya.
Kriteria ditambahkan ke klasifikasi ini sebagai: pengetahuan tentang rantai alat kami, kecukupan, pengalaman kerja sekitar 1-2 tahun, dan setidaknya satu proyek yang berhasil diimplementasikan, kemampuan untuk mengekspresikan pemikiran dengan jelas, kehadiran keterampilan komunikasi, kemampuan untuk mengakui kesalahan dan kekurangan seseorang (kritik diri yang sehat - ini adalah alat yang ampuh). Prioritas untuk himpunan, sebagaimana disebutkan di atas, ditempatkan pada pengembang junior, karena pengalaman kami dalam berurusan dengan middles menunjukkan bahwa, sebagai suatu peraturan, orang-orang ini sudah dimanjakan oleh beberapa jenis tumpukan teknologi dan pendekatan "unik" dari perusahaan lain. Selain itu, praktik telah menunjukkan bahwa ada sejumlah besar orang di pasar yang terbiasa hidup dalam struktur vertikal yang kaku, di mana mereka mendapatkan ke atas meja bahan aldente dari tugas-tugas yang dikunyah yang hanya dapat diisi dalam bentuk kode, dan tugas para manula adalah mengalahkan kusen dengan tongkat di kepala. . Tetapi masalahnya adalah ketika tindakan terjadi di sebuah startup muda, dan tim hanya memiliki sekitar tiga puluh orang, yang masing-masing dimuat di bawah tangki penuh, maka tidak ada waktu untuk dekomposisi pribadi untuk setiap karyawan, karena ini sama saja dengan menyelesaikan tugas ini. Dalam kondisi seperti itu, ketika menulis kode membutuhkan sekitar sepuluh persen dari total waktu pelaksanaan tugas, perlu untuk memasukkan tidak hanya jari, tetapi juga kepala. Ini persis seperti apa yang tertulis dalam "Alkitab" dari semua programmer - Stephen McConnell "Kode Ideal" alias Redbook (jangan dikacaukan dengan majalah wanita Amerika).
Dan kemudian gelombang menutupi kita ...
Siapa pun yang tidak memasuki kami, mulai dari karakter yang percaya bahwa mereka sedang karena mereka menulis seluruh aplikasi di Android, yang memiliki sebanyak 37 unduhan di Google Play, berakhir dengan orang-orang yang menganggap diri mereka penanda super karena mereka bekerja sebagai pengembang terkemuka di beberapa studio, meskipun pekerjaan mereka, pada umumnya, direduksi menjadi pengalihan tugas dari departemen desain ke departemen pengembangan, yaitu, mereka tidak memiliki pengalaman dalam merancang atau mengelola pengembangan, tetapi hanya ada banyak ambisi dan banyak ambisi . Ada juga orang-orang yang, dengan tujuh bulan pengalaman pemrograman, menganggap diri mereka senior, dan menuntut gaji 240 ribu, sementara bahkan tidak menyelesaikan tugas-tugas dasar untuk junior. Dari sudut pandang kami, orang-orang ini bahkan bukan Joons. Pendekatannya sederhana, jika seseorang memprogram langsung dari hati, ia hanyalah seorang programmer, tetapi jika seseorang melakukan pemrograman yang buruk atau tidak menarik sama sekali, ia bukan seorang junior, ia sama sekali bukan seorang programmer. Di sini kami dibantu oleh peretasan hidup yang hebat untuk menjatuhkan kandidat seperti itu, itu disebut "Hukum Plumbing", yang berbunyi: "Setiap tukang ledeng baru yang tiba di tempat kerja baru menuangkan lumpur ke tukang ledeng lain, mengatakan bahwa ia memiliki lengan pendorong dan bahwa sekarang ia harus melakukan segalanya dengan nol. " Dalam praktiknya, ini bekerja seperti ini: pelamar datang ke posisi junior, mereka memberinya sepotong kode siap pakai, misalnya, sebuah fragmen dari kernel Linux, dan bertanya apa pendapatnya tentang keputusan ini? Jika dia mulai meludah dan mengatakan sesuatu seperti: “Penulis seperti apa yang menulis ini? Semuanya perlu diperbaiki di sini! Beri saya waktu, dan saya akan menulisnya lagi, ”jadi tukang ledeng itu ada di depan Anda, dan prioritas pertamanya adalah memarahi tukang ledeng sebelumnya.
Michelangelo pada kesempatan ini mengatakan: "Saya mengambil batu, memotong semua yang tidak perlu." Master yang hebat itu tidak menulis naskah, tetapi dia mengerti dengan baik bahwa orang yang kompeten mendekati objek kerja dengan keinginan untuk memahaminya dan, jika perlu, mengubahnya, tetapi tidak menghancurkannya dan mengubahnya menjadi debu. Yaitu, jika seseorang menjawab pertanyaan seperti itu: "Jika kode berfungsi dalam produksi dan menjalankan fungsinya, itu bagus, di beberapa tempat saya pikir Anda dapat meningkatkan kode ini, jika perlu, saya dapat menunjukkannya.", Kemudian dengan orang seperti itu Anda dapat dan harus melanjutkan dialog .
Teknik lain untuk mendefinisikan zona keterampilan rendah adalah dengan fokus pada hype dan tumpukan hype. Jika seseorang datang ke sebuah wawancara dan mulai menuangkan pendekatan tren, dan ke pertanyaan yang sah: "Bagaimana Anda sampai pada kesimpulan ini dan apakah Anda menganalisis alat-alat ini?" - meringis pada meringis yang telah mencapai pencerahan senior, dia menjawab: "Anda dapat menulis apa pun di atasnya, Masa Depan ada di belakangnya!" alat dan pendekatan hype.
Sedikit lagi tentang wawancara
Selain hal di atas, saat mempekerjakan seorang programmer, sangat penting untuk mendapatkan posisi terbuka darinya berdasarkan pengetahuannya dalam tumpukan tertentu. Anda memutuskan tumpukan, dan dia memilih bahasa di mana dia "wai wai wai seberapa kuat", katakanlah dia adalah seorang dataran tinggi JavaScript. Ada satu set tugas yang sudah jadi, misalnya, ini:
setTimeout(()=>{console.log('Hello World!')}, 1000); while (true) { let a = false; };
Jika pertanyaan tentang tugas ini adalah: "Kapan Hello World!" Akan ditampilkan ? ", Dia mulai terbata-bata dengan gaya menjawab:" Yah ... eh ... lihat ... setelah menyelesaikan loop sementara yang benar atau setelah satu detik "- ini berarti bahwa dia benar-benar tidak tahu tumpukan, berbohong tentang keahliannya, yang kemungkinan besar dekat dengan ke nol. Faktanya adalah konstruksi sementara akan memuat preprocessor, dan karena JS adalah single-threaded, loop utama tidak akan pernah memancarkan suatu peristiwa dari timer. Yaitu jawaban yang benar tidak pernah.
Jika seseorang tidak siap untuk secara memadai dan jujur mengevaluasi pengetahuannya, tidak mampu membaca kode orang lain, maka pekerjaan seperti apa dalam sebuah tim dapat didiskusikan. Jika seseorang tidak terbukti menjadi "tukang ledeng" dan mengatasi tugas-tugasnya, mengkonfirmasikan pengetahuannya tentang tumpukan, atau konstruktif tentang tugas, kesalahan dan ketidakmampuan parsialnya, maka ada kemungkinan bahwa ia akan menjadi karyawan baru Anda, dan di masa depan akan dapat tumbuh di sisi tingkat klasifikasi yang lebih tinggi.
Ada kalanya seseorang tidak setuju dengan klasifikasi internal perusahaan, dan bereaksi negatif terhadap pernyataan bahwa ia tidak menarik pada pertengahan atau bahkan pada Juni, dan bahwa keputusannya tidak akan berhasil. Dalam hal ini, jika dia terus bersikeras, Anda dapat melanjutkan prinsipnya, dan menjalankan solusinya di lingkungan, secara alami desain ini ternyata tidak berfungsi, yaitu, orang tersebut telah mengacaukannya. Kemudian dia dapat mulai menghancurkan otoritas dari pekerjaan sebelumnya. Sebagai contoh, ada kasus-kasus ketika seseorang setelah kegagalan seperti itu menyatakan bahwa ia adalah karyawan yang sangat berharga dari sebuah bank besar dan sangat dihargai di sana. Tetapi pada kenyataannya ternyata dua belas ribu orang lain seperti dia bekerja di bank ini, dan departemen SDM mengabaikan ketidakmampuannya, dan setelah menghabiskan sekitar satu tahun di sana, dia sekarang menyatakan statusnya sebagai spesialis. Dan di sini, di mana ada tim yang terdiri dari sekitar dua puluh programmer, yang masing-masing berpengalaman dalam bisnisnya sendiri, dia hanya tersesat karena tidak dapat bekerja sesuai dengan skema petugas lama. CEO kami, Ilya Bykonya, mengatakan ini: "Bagi saya, seperti untuk pengembang dan pendiri perusahaan saat ini, satu otoritas adalah keahlian orang tersebut, dan di mana ia bekerja, dan posisi apa yang ia miliki, adalah kepentingan sekunder."
Untuk meringkas
Mungkin ada kelemahan dalam pendekatan kami untuk mengevaluasi pelamar. Dan fakta bahwa kita "menurunkan peringkatnya", mengatakan bahwa dia tidak berada di tengah, tetapi Juni atau lebih buruk, memainkan lelucon kejam dengan kita. Mungkin kita kehilangan Napoleon masa depan, seperti Kekaisaran Rusia pada satu waktu? Siapa tahu ... Tapi dari sudut pandang kami, strategi seperti itu sepenuhnya dibenarkan oleh efektivitasnya, dan pada akhirnya, Napoleon masih kalah perang Kekaisaran Rusia.