tl; dr. Selama beberapa dekade terakhir, cara mewawancarai pemrogram telah berubah beberapa kali, dan masing-masing dari mereka tampak konyol dalam retrospeksi. Entah kami akhirnya menemukan rahasia wawancara yang efektif, atau terbawa oleh tren fesyen berikutnya, yang dalam sepuluh hingga dua puluh tahun akan terasa sama konyolnya.

Ketika saya bertanya kepada orang-orang di perusahaan teknologi besar yang modis mengapa sangat perlu untuk bertanya tentang algoritma pada sebuah wawancara, jawaban yang paling umum adalah sesuatu seperti: "Kami memiliki skala seperti itu, kami tidak dapat membiarkan siapa pun secara tidak sengaja menulis O(n^2) dan mengetuk seluruh sistem " ¹ . Apa yang sangat lucu, akhir-akhir ini saya banyak menerapkan algoritma ini dalam praktik dan memecahkan masalah nyata, tetapi saya tidak bisa melalui wawancara di mana orang bertanya tentang mereka! Apakah Anda pikir saya gagal setengah wawancara atau sesuatu? Tidak, lebih dari setengah. Saya berpartisipasi dalam sekitar 40 wawancara "nyata" dan mungkin melewati satu atau dua wawancara. Atau tidak satu pun ² .

Ketika saya menulis konsep artikel ini, teman-teman saya merasa bosan karena saya gagal terlalu banyak wawancara. Mereka mengatakan bahwa semua kegagalan harus ditabulasikan karena tidak ada yang akan membaca sepuluh halaman teks dengan daftar panjang kegagalan. Tip yang bagus. Sudah bekerja di atas meja.

Mari kita lihat beberapa contoh.

Di satu perusahaan besar tempat saya bekerja, tim menulis perpustakaan dasar dengan penerapan array dinamis sendiri. Jika tidak ada ukuran yang cukup selama operasi, implementasi menambahkan sejumlah baris ke array, dan kemudian menyalin array lama ke array baru dengan ukuran yang sedikit lebih besar. Ini adalah contoh klasik implementasi array dinamis yang tidak tepat, karena ini mengarah pada peningkatan linear dalam waktu alih-alih waktu konstan diamortisasi . Ini adalah contoh klasik yang sering digunakan sebagai kanonik dalam menjelaskan analisis depresiasi.

Di perusahaan IT besar, wawancara telepon umum terbagi dalam tiga kategori:

1. Satu pertanyaan pemrograman / algoritma "sederhana", mungkin pertama dengan pertanyaan pemanasan "sangat sederhana".
   
2. Serangkaian pertanyaan pemrograman / algoritmik "sangat sederhana".
   
3. Banyak fakta terkenal (jarang untuk posisi bagus, tetapi sering untuk posisi level rendah atau non-kreatif).

Masalah implementasi array ini dianggap sangat sederhana sehingga masuk dalam kategori "sangat mudah" dan merupakan pemanasan untuk pertanyaan "nyata" atau dilengkapi dengan banyak pertanyaan sederhana yang sama. Namun, di perusahaan kami, array dinamis seperti itu bertanggung jawab atas sekitar 1% dari total beban pada pengumpul sampah dalam kode JVM (itu adalah sumber alokasi memori terbesar kedua di seluruh kode), serta untuk bagian signifikan dari beban CPU.

Untungnya, implementasi ini tidak digunakan sebagai array dinamis universal, tetapi dibuat hanya dengan bantuan shell semi-khusus, oleh karena itu bertanggung jawab untuk "hanya" 1% dari tekanan pada GC. Jika ditanya dalam wawancara, sebagian besar anggota tim itu akan menjawabnya dengan benar. Tambalan saya membawa majikan lebih banyak uang dalam setahun daripada yang saya dapatkan dalam hidup saya.

Itu adalah sumber alokasi memori terbesar kedua, yang utama adalah konversi sepasang nilai long menjadi array byte dari pangkalan perpustakaan yang sama. Rupanya, seseorang menulis atau menyalin fungsi hash yang mengambil array sebagai input, dan kemudian mengubah kode untuk mengambil dua array dan bekerja dengannya secara berurutan dari fungsi hash lama seperti byte[], byte[] . Untuk memanggil fungsi ini pada dua panjang, mereka menggunakan fungsi konversi long ke byte[] mudah digunakan di pustaka utilitas yang banyak digunakan. Selain menyoroti byte[] dan menempel long sana, fungsi ini juga mengubah urutan byte long (tampaknya, fungsi itu dirancang untuk mengubah nilai-nilai long ke urutan byte jaringan).

Sayangnya, beralih ke fungsi hash yang lebih tepat dianggap sebagai perubahan yang terlalu serius, jadi tambalan saya adalah untuk mengubah antarmuka fungsi hash untuk mengambil sepasang long alih-alih sepasang array byte dan menghapus langkah terpisah untuk mengubah urutan byte (karena fungsi hash sudah berubah dia, langkah terpisah tidak diperlukan). Menghilangkan operasi yang tidak perlu ini memberi majikan lebih banyak uang dalam setahun daripada yang saya dapatkan dalam hidup saya.

Secara teknis, optimasi bukan masalah algoritme, tetapi dalam praktiknya hal itu selalu ditanyakan. Menanggapi pertanyaan tentang algoritma, mereka biasanya bertanya kepada saya: "Bisakah Anda mempercepatnya?" Jawaban untuk pertanyaan seperti itu sering kali mencakup pengoptimalan sederhana, yang mempercepat kode beberapa kali.

Contoh spesifik yang saya ditanyai dua kali dalam wawancara: Anda menyimpan pengidentifikasi sebagai int, tetapi dari konteks berikut bahwa pengidentifikasi dikemas dengan ketat, sehingga mereka dapat disimpan sebagai bidang bit. Tetapi solusi yang ada di dunia nyata jauh dari jawaban yang diharapkan tentang bidang bit sehingga hampir tidak mungkin untuk mencapai akselerasi beberapa kali. Kemungkinan besar, wawancara akan berakhir di sana.

Contoh lain dari pertanyaan sederhana tentang algoritma adalah konfigurasi aktual untuk BitFunnel , indeks pencarian yang digunakan di Bing ³ .

Mendeskripsikan konteks lengkap dari perusahaan khusus ini akan memakan waktu terlalu banyak, tetapi singkatnya, Anda perlu mengonfigurasi satu set filter Bloom. Salah satu caranya adalah dengan menulis fungsi optimisasi sesuai dengan model kotak hitam, yang, dengan menggunakan gradient descent, mencoba menemukan solusi optimal. Mereka melakukannya, tetapi fungsinya menunjukkan beberapa properti aneh, dan konfigurasi output tidak pernah bekerja dengan sempurna. Ini dikoreksi dengan menipiskan filter Bloom, yaitu, mengalokasikan lebih banyak sumber daya (dan, karenanya, uang) untuk masalah tersebut.

Saat menganalisis peluang untuk optimasi, Anda mungkin memperhatikan bahwa operasi mendasar dalam BitFunnel setara dengan mengalikan probabilitas. Oleh karena itu, untuk konfigurasi tertentu, Anda dapat dengan mudah mengalikan beberapa probabilitas - dan menentukan bagaimana konfigurasi akan bekerja. Karena ruang konfigurasi tidak terlalu besar, Anda dapat menggilir semua opsi yang mungkin, dan kemudian memilih yang terbaik. Pada kenyataannya, ini tidak sepenuhnya benar, karena multiplikasi probabilitas menyiratkan beberapa independensi, yang tidak terjadi dalam kenyataan, tetapi metode ini masih berfungsi dengan baik karena alasan yang sama bahwa pemfilteran bayesian naif bekerja dengan cukup baik, yang secara tidak benar mengasumsikan kemungkinan independen terjadi dalam surat tersebut. ada dua kata sembarang. Untuk solusi lengkap, Anda dapat menganalisis saling ketergantungan. Meskipun ini mungkin di luar cakupan wawancara.

Ini hanya tiga contoh yang muncul di benak saya, dan saya terus-menerus menemukan hal-hal serupa dan dapat menghasilkan puluhan contoh, mungkin lebih dari seratus, jika saya duduk dan mencoba mendaftar semua yang saya kerjakan. Dan lebih dari seratus contoh yang dikerjakan orang lain (atau tidak ada). Kedua contoh ini, serta yang saya hilangkan, memiliki properti berikut:

1. Contoh dapat dirumuskan sebagai pertanyaan untuk wawancara.
   
2. Jika pertanyaan dirumuskan, Anda berharap sebagian besar (atau semua) karyawan tim yang relevan akan mengetahui jawaban yang benar.
   
3. Menyimpan uang dari perbaikan ini akan membawa majikan lebih banyak uang dalam setahun daripada yang saya dapatkan dalam hidup saya.
   
4. Masalah dari contoh bertahan cukup lama, jika tidak maka tidak akan diperhatikan.

Pada awal artikel, kami mencatat bahwa perusahaan IT besar mengajukan pertanyaan tentang algoritma, karena inefisiensi dalam skala besar akan sangat merugikan mereka. Pengalaman saya menunjukkan bahwa di setiap perusahaan yang diwawancarai, ada sejuta contoh ketidakefisienan seperti itu. Ternyata pertanyaan tentang algoritma pada wawancara tidak membantu menyelesaikan masalah algoritmik nyata di tempat kerja.

Salah satu alasannya adalah bahwa perusahaan besar berusaha menemukan orang yang dapat memecahkan teka-teki algoritma, tetapi melarang alasan tersebut dalam produksi.

Dari tiga solusi untuk contoh di atas, dua pergi ke prod. Bagi saya, ini adalah persentase normal jika saya hanya diundang ke proyek acak, yang tidak selalu saya ikuti. Orang yang sinis bisa mengatakan bahwa persentasenya bahkan tinggi. Dalam tim acak, hasilnya bisa lebih buruk, karena tidak menguntungkan bagi mereka untuk menerapkan solusi apa pun, bahkan yang efektif. Bagaimanapun, itu mengharuskan mereka untuk menguji, mengintegrasikan, dan menyebarkan perubahan. Risiko baru tercipta. Yaitu, saya meminta tim untuk melakukan beberapa pekerjaan dan mengambil risiko untuk melakukan sesuatu yang bermanfaat bagi perusahaan, tetapi tidak berguna untuk diri mereka sendiri. Terlepas dari semua ini, orang biasanya menerima kode, meskipun mereka tidak terlalu cenderung menghabiskan waktu untuk optimasi (waktu kerja mereka akan dihabiskan untuk hal-hal yang konsisten dengan tujuan tim) ⁴ .

Misalkan sebuah perusahaan menolak untuk menawarkan teka-teki wawancara kepada kandidat, dan mendorong pengembang untuk menggunakan algoritma yang lebih sederhana dan relatif efisien. Kecil kemungkinan bahwa salah satu dari contoh di atas dapat luput dari perhatian selama bertahun-tahun. Masalahnya mungkin akan diperbaiki. Beberapa pengembang hipotetis di sebuah perusahaan dengan profiling kode akan melihat elemen “terpanas” di profil untuk pustaka paling intensif sumber daya.

Dalam dua kasus, solusi praktis bukan semacam keajaiban algoritma, tetapi hanya analisis yang komprehensif. Contoh ketiga kurang jelas karena tidak ada alat standar untuk menganalisis masalah. Anda dapat mencoba menyajikan hasilnya sebagai semacam penguasaan tertinggi, setelah semua, contoh ini didasarkan pada artikel ilmiah, yang menerima penghargaan untuk artikel terbaik di konferensi paling bergengsi di bidangnya, tetapi pada kenyataannya ada matematika sekolah menengah, yaitu, untuk solusi nyata untuk masalah tersebut, Anda hanya perlu untuk mempelajari di mana metode matematika ini berlaku.

Saya benar-benar pernah bekerja di perusahaan yang tidak mengajukan pertanyaan tentang algoritma pada wawancara, tetapi berkonsentrasi pada pertanyaan praktis. Selama saya tinggal di sana, saya hanya menemukan satu peluang pengoptimalan yang hampir memenuhi kriteria di atas (karena ukurannya yang kecil, itu tidak pergi sedikit di sepanjang poin ketiga, yaitu, pada saat itu saya telah memperoleh lebih banyak dalam hidup saya daripada penghematan tahunan dari memperbaiki bug ini).

Mengapa perusahaan ini hampir tidak memiliki masalah dengan colokan kinerja? Saya pikir alasan utamanya adalah karena banyak orang berpikir bahwa memperbaiki perusahaan adalah pekerjaan mereka. Oleh karena itu, sistem awalnya dirancang hampir secara optimal. Dengan pengecualian langka, ada cukup banyak spesialis yang mencoba untuk terus memberi manfaat bagi perusahaan, daripada secara pribadi untuk diri mereka sendiri dan tim mereka (yang sama sekali berbeda dari manfaat global untuk perusahaan). Dengan demikian, selalu ada seseorang yang memecahkan masalah sebelum saya menemukan.

Di perusahaan IT besar, mewawancarai algoritma dengan menguji keterampilan pengkodean biasanya lebih sederhana daripada penyaringan awal melalui telepon. Biasanya, masalah desain sistem tidak dibahas di sini.

Beberapa waktu yang lalu, kami mencoba untuk mengajukan pertanyaan tentang algoritma dalam wawancara tatap muka. Sebuah pertanyaan yang cukup sulit, tetapi dalam kerangka apa yang mungkin Anda temui dengan penyaringan telepon di perusahaan besar (tetapi masih lebih mudah dari yang Anda harapkan dari wawancara pribadi). Kami mengabaikan praktik ini, karena benar-benar semua kandidat gagal pada bagian ini (kami tidak mengajukan pertanyaan kepada para kandidat yang berpengalaman tentang algoritme). Perusahaan kami tidak begitu terkenal untuk mendapatkan pendatang baru yang dapat dengan mudah menjawab pertanyaan-pertanyaan ini, oleh karena itu, filter penyaringan kandidat yang modis ini tidak bekerja untuk kami. Dalam artikel perekrutan modern, apa yang telah kami lakukan sering disebut "menurunkan standar," tetapi saya tidak mengerti mengapa kita harus peduli tentang ketinggian maksimum lompatan kandidat jika karyanya hampir (atau tidak pernah) melibatkan lompatan tinggi. Dan dalam kasus-kasus ketika Anda benar-benar perlu melompat, bar diatur pada ketinggian sekitar lima sentimeter.

Menilai dari kinerja aktualnya, itu adalah perusahaan paling produktif tempat saya bekerja. Saya percaya bahwa alasannya ada dalam budaya, dan mereka terlalu kompleks untuk dibongkar sepenuhnya dalam satu artikel, tetapi mungkin membantu kami bahwa kami tidak menyaring kandidat yang baik menggunakan kuis dengan algoritma. Kami menyarankan agar orang dapat mempelajari materi ini di tempat kerja jika kami memiliki budaya yang tepat dan karyawan melakukan hal yang benar daripada berfokus pada tugas-tugas lokal untuk diri mereka sendiri atau departemen mereka.

Jika perusahaan lain ingin orang menyelesaikan masalah algoritma pada tingkat yang sama dengan yang mereka tanyakan saat wawancara, maka pada dasarnya Anda perlu mendorong orang untuk memecahkan masalah algoritma (bila perlu). Ini dapat dilakukan sebagai tambahan atau bahkan bukannya memilih kandidat untuk masalah teoritis.

Lampiran: bagaimana kita mencapai ini?

Di masa lalu yang baik, pertanyaan "sepele" diajukan pada wawancara. Versi modern dapat terlihat seperti ini:

• Apa itu MSI? MESI? MOESI? MESIF? Apa keunggulan MESIF dibandingkan MOESI?
  
• Apa yang dilakukan seorang destruktor? Dan jika itu C ++ 11? Dan jika Anda memanggil destruktor sub-objek dari destruktor tingkat atas, lalu apa yang akan dieksekusi sub-proyek destruktor lain? Dan selama promosi tumpukan? Dalam keadaan apa Anda dapat menghindari panggilan std::terminate ?

Saya mendengar tentang wawancara sederhana ini di sekolah dan bahkan melihat di beberapa perusahaan “sekolah lama”. Ini terjadi selama kepemimpinan Microsoft, ketika semua orang memandang perusahaan yang sukses dan menyalin Microsoft. Blogger pemrograman yang paling banyak dibaca (Joel Spolsky) mengatakan semua orang perlu merangkul beberapa praktik pengembangan X karena Microsoft melakukannya. Misalnya, di salah satu artikel pemrograman paling berpengaruh di zaman itu, Joel Spolsky memperkenalkan apa yang disebut tes Joel, yang menentukan seberapa banyak Anda dapat bersaing dengan perusahaan seperti Microsoft:

12 poin sangat bagus, 11 poin bisa ditoleransi, tetapi dengan peringkat 10 atau lebih rendah Anda memiliki masalah serius. Yang benar adalah bahwa sebagian besar perangkat lunak bekerja pada level 2-3 poin, dan mereka membutuhkan bantuan serius , karena perusahaan seperti Microsoft bekerja pada level 12 penuh waktu.

Menurut legenda populer pada waktu itu, Microsoft bertanya tentang pertanyaan seperti itu di wawancara (dan saya benar-benar ditanya salah satu tugas ini di sebuah wawancara di Microsoft sekitar tahun 2001, tanpa pertanyaan tentang algoritma atau pemrograman):

• Bagaimana cara keluar dari blender jika tinggi badan Anda 1 cm?
  
• Mengapa manhole cover bulat?
  
• Kamar tanpa jendela memiliki tiga lampu, yang masing-masing dikendalikan oleh saklar dari luar. Anda berada di luar ruangan dan hanya bisa masuk sekali. Bagaimana menentukan sakelar mana yang mengontrol lampu mana?

Karena saya diwawancarai di era perubahan, saya ditanyakan banyak pertanyaan sederhana dan banyak tugas (termasuk semua hal di atas). Pada wawancara waktu itu, pertanyaan Fermi , yang secara teknis bukan teka-teki, masih populer. Tren lain waktu itu adalah wawancara perilaku tanpa masalah teknis tunggal.

Namun, orang-orang mencoba menyalin wawancara gaya Microsoft. Ketika saya menanyakan teka-teki atau pertanyaan Fermi apa yang baik, mereka menjawab saya bahwa dengan cara ini dimungkinkan untuk memeriksa apakah kandidat mampu melakukan refleksi, berlawanan dengan pertanyaan pengetahuan yang hanya mengatakan bahwa seseorang telah mengingat beberapa informasi. Dan kami membutuhkan kandidat yang benar-benar dapat berpikir!

Melihat ke belakang, sekarang menjadi jelas bagi semua orang bahwa ini tidak efisien, dan menyalin setiap trik Microsoft tidak akan membuat perusahaan Anda sesukses itu karena Microsoft menggunakan banyak trik lain - mereka hanya efektif bersama karena efek jaringan. Dengan menyalin wawancara Microsoft, Anda akan menjadi perusahaan yang hanya melakukan wawancara dengan gaya yang sama, tetapi tidak dapat memanfaatkan efek jaringan yang digunakan Microsoft.

Bagi para kandidat, prosedur wawancara pada dasarnya sama dengan algoritma sekarang. Hanya untuk mempersiapkan wawancara, alih-alih “Meretas wawancara pemrograman,” Anda harus membaca “Cara Memindahkan Gunung Fuji.” Artinya, Anda perlu belajar banyak pengetahuan tentang tugas yang tidak akan pernah Anda gunakan di tempat kerja, alih-alih pengetahuan tentang algoritma yang tidak akan pernah Anda gunakan dengan cara yang sama.

Pada masa itu, pewawancara menemukan pertanyaan wawancara dalam buku persiapan untuk wawancara, seperti Bagaimana Memindahkan Gunung Fuji. Pertanyaan-pertanyaan ini diajukan kepada kandidat yang mempelajari jawabannya di buku yang sama. Pemuda modern menemukan ini konyol - jelas bahwa pertanyaan-pertanyaan itu tidak ada hubungannya dengan pekerjaan, dan kemungkinan jawaban yang baik lebih tergantung pada persiapan wawancara daripada pada kompetensi kandidat. Tetapi pendekatan hari ini tidak jauh berbeda.

Selama beberapa dekade terakhir, mode untuk mewawancarai programmer telah berubah beberapa kali, dan masing-masing dari mereka tampak konyol dalam retrospeksi. Entah akhirnya kami menemukan rahasia wawancara yang efektif, atau terbawa oleh tren fesyen berikutnya, yang dalam sepuluh hingga dua puluh tahun akan terasa sama konyolnya.

Tanpa memperhitungkan efisiensi akun, metode wawancara tingkat-meta tidak berubah (dengan pengecualian teknologi tingkat tinggi dari perusahaan paling bergengsi), jadi semuanya sangat mirip dengan hobi modis lainnya, yang tidak berbeda dari praktik konyol sebelumnya. Penelitian empiris atau verifikasi independen atas keefektifan metode yang berbeda dapat menggoyang pendapat saya.

Terinspirasi oleh komentar Wesley Pharmacist-Cassels , baru-baru ini saya secara khusus bertanya kepada perwakilan pengusaha bagaimana mereka memeriksa efektivitas wawancara mereka dan bagaimana mereka berurusan dengan bias. Inilah yang mereka jawab (dalam urutan frekuensi):

• Apa? Tidak ada, mengapa ini?
  
• Kami benar-benar tidak tahu apakah proses kami efektif.
  
• Kami hanya tahu bahwa semuanya berfungsi.
  
• Kami tidak memiliki bias.
  
• Kami akan melihat bias jika ada proses penilaian.
  
• Seseorang telah mempelajari dan / atau melakukan penelitian, tetapi tidak dapat mengatakan sesuatu yang konkret tentang bagaimana hal itu dipelajari dan dengan metodologi apa penelitian itu dilakukan.

Aplikasi: Pelatihan

Seperti kebanyakan masalah nyata, tidak mungkin untuk menemukan satu-satunya alasan mengapa bug bernilai puluhan dan ratusan juta dolar tetap tidak tertutup dalam produksi. Di satu sisi, kita menemukan semacam pertahanan yang mendalam dengan insentif yang tidak cocok. Di sisi lain, belajar sayangnya diremehkan .

Saya telah menyebutkan bahwa di hampir semua perusahaan, sistem tidak mendorong orang untuk menghabiskan waktu untuk meningkatkan efisiensi, bahkan jika perhitungan sederhana menunjukkan bahwa memperbaiki bug dapat dengan mudah menghemat puluhan atau ratusan juta dolar. Dan dengan tidak adanya insentif, pengembang tidak punya tempat untuk mendapatkan pengalaman dalam melakukan pekerjaan seperti itu. Pekerjaan yang tidak dikenal selalu tampak lebih rumit daripada yang sebenarnya. Jadi, bahkan jika satu hari kerja dapat menghasilkan $ 1 juta per tahun dalam bentuk tabungan atau keuntungan (ini cukup umum di perusahaan besar, menurut pengalaman saya), orang tidak mengerti bahwa ini hanya satu hari kerja dan dapat dilakukan tanpa gangguan. dari sisa kasus. Salah satu cara untuk mengatasi masalah terakhir ini adalah melalui pelatihan. Namun, bahkan lebih sulit bagi seorang manajer untuk membenarkannya daripada meningkatkan efisiensi, yang bukan bagian dari tugas utama!

Misalnya, setelah saya menulis panduan kecil (4.500 kata, kurang dari artikel ini, kecuali untuk gambar) tentang menemukan berbagai inefisiensi dalam sistem: cara menggunakan profiler untuk mengalokasikan memori dan waktu CPU, cara mengkonfigurasi GC kami untuk tugas-tugas khusus, cara menggunakan beberapa alat saya untuk secara otomatis menemukan hambatan dalam konfigurasi JVM, wadah, dll. Ini pada dasarnya adalah trik sederhana dan sangat efektif yang mudah dilakukan. Beberapa orang dapat men-debug dan memperbaiki masalah mereka sendiri, dan bekas saya mendengar bahwa orang lain telah meningkatkan efisiensi layanan mereka. Nah, jika 10% insinyur mendapat manfaat dari manual ini, saya harap ini membantu puluhan insinyur, dan mungkin lebih.

Jika, alih-alih panduan, saya menghabiskan seminggu di pekerjaan "nyata", saya akan mendapatkan sesuatu yang spesifik, dengan nilai kuantitatif, yang terlihat indah dalam paket promosi atau tinjauan kinerja. Alih-alih, saya memiliki semacam pencapaian yang samar-samar, yang paling-paling dapat dianggap sebagai "kelebihan". Saya tidak mengeluh - ini persis hasil yang saya harapkan. Tetapi rata-rata, perusahaan mendapatkan apa yang mereka sendiri merangsang karyawan. Jika mereka berharap bahwa pelatihan itu berasal dari pengembang sendiri (tanpa membiayai produksi materi pelatihan), tetapi tidak menghargai sebanyak pekerjaan para pengembang, maka pelatihan akan menjadi langka.

Saya percaya mudah untuk melihat buruknya kualitas bahan ajar umum karena relatif sulitnya memonetisasi pendidikan dan pelatihan. Jika Anda ingin memonetisasi program pelatihan, ada beberapa metode yang baik. Rupanya, monetisasi program video berharga bekerja dengan baik (ratusan atau ribuan dolar untuk kursus singkat). Pelatihan korporat, ketika perusahaan mengundang Anda untuk berbicara dengan 30 orang, dan Anda mengambil $ 3.000 dari masing-masing, juga bekerja dengan cukup baik.

Jika Anda ingin menjangkau (dan berpotensi membantu) sejumlah besar orang, maka penerbitan di Internet efektif, tetapi jangan berharap monetisasi. Adapun topik teknis, tidak mungkin bahwa pemirsa tanpa pemblokir iklan cukup besar untuk memonetisasi konten melalui iklan (sebagai lawan dari akses berbayar).

Misalnya, Julia Evanspenghasilan yang cukup untuk penjualan komik komputer, yang baru-baru ini membawa sekitar $ 100 ribu per tahun. Seorang spesialis pelatihan korporat dapat memperoleh ini dalam satu atau dua hari.

Lampiran: pertahanan mendalam dengan ketidakcocokan insentif, bagian 3

Dari tiga contoh di atas, dalam dua kasus saya menerima dorongan untuk menghemat uang perusahaan. Dalam pengalaman saya, ini jarang terjadi di perusahaan besar, tetapi meskipun demikian, distribusi insentif ternyata agak buruk. Pada titik tertentu, setelah kenaikan gaji dan promosi, saya menghitung rasio kenaikan dan tabungan yang saya bawa ke perusahaan. Rasionya kira-kira 0,03% langsung dalam bentuk uang, tanpa memperhitungkan alat yang dikembangkan oleh saya, yang sulit untuk menghitung nilai tertentu. Mungkin nilai ini sebenarnya lebih dari nilai terukur. Oleh karena itu, kita dapat menyimpulkan bahwa saya menerima secara signifikan kurang dari 0,01% dari jumlah yang dibawa perusahaan. Dan ini adalah penilaian yang terlalu tinggi: pada kenyataannya, saya sangat curiga bahwa sebenarnya pekerjaan yang dilakukan tidak membawa saya apa-apa,dan kenaikan itu tidak ada hubungannya dengan proyek ini, yang menyelamatkan perusahaan puluhan juta dolar. Setelah $ 10 juta pertama per tahun, atau mungkin $ 20 juta per tahun, tidak ada lagi insentif untuk melakukan pekerjaan dalam hal mengevaluasi efektivitas, promosi, peningkatan, dll. Karena tidak ada nilai tambah, tetapi ada beberapa kelemahan (Anda dapat terlibat dalam intrik penyamaran, secara tidak sengaja menjatuhkan situs, dll.), sehingga pengembalian melakukan pekerjaan opsional cenderung menjadi negatif.tetapi ada beberapa kelemahan (Anda bisa terlibat dalam intrik penyamaran, secara tidak sengaja menjatuhkan situs, dll.), sehingga pengembalian melakukan pekerjaan opsional mungkin menjadi negatif.tetapi ada beberapa kelemahan (Anda bisa terlibat dalam intrik penyamaran, secara tidak sengaja menjatuhkan situs, dll.), sehingga pengembalian melakukan pekerjaan opsional mungkin menjadi negatif.

Beberapa perusahaan secara teratur memberikan bonus yang sangat besar, tetapi saya tidak memiliki perusahaan seperti itu, dan pada kenyataannya, majikan tidak dapat mengevaluasi karyawan untuk pekerjaan tambahan, kecuali sebagai peringkat maksimum dalam ulasan kinerja, dan dia mewakili jumlah pekerjaan yang “cukup”. Dalam hal desain mekanisme , perusahaan sebenarnya meminta karyawan untuk berhenti bekerja segera setelah mereka melakukan "cukup."

Jadi, bahkan dalam tim yang relatif profesional ini, sistem penghargaan perusahaan membatasi orang tanpa mendorong mereka untuk memaksimalkan efisiensi.

Itu juga terjadi bahwa manajer diberi anggaran tim untuk meningkatkan gaji, yang terutama tergantung pada jumlah karyawan, dan kemudian didistribusikan di antara karyawan. Pada dasarnya, tim hanya memiliki pengembang yang produktif, sehingga tidak ada yang menonjol di antara yang lain. Pada saat yang sama, ada pergantian staf yang sangat rendah karena programmer suka bekerja dengan kolega yang baik. Untuk mendorong orang pindah ke tim yang kurang efektif, perusahaan menggunakan salah satu tuas paling kuat - kompensasi.

Karena ini adalah skema umum, di beberapa perusahaan, manajer berusaha menjaga karyawan yang tidak berbahaya tetapi tidak efektif untuk menghindari batasan bonus. Jika seseorang secara teoritis bertanya-tanya apakah perusahaan perlu merekrut dan mempertahankan orang yang tidak efektif, jawabannya adalah tidak. Namun dalam praktiknya, skema bonus universal untuk tim secara tidak langsung merangsang ini.

Tautan Terkait

• Kontra dari sekte praktik tren rekrutmen
  
• Normalisasi penyimpangan
  
• Buku Zvi Mousovitsa "Moral Labyrinths" tentang masalah sistemik yang menyebabkan inkonsistensi yang tidak koheren di semua tingkatan korporasi
  
• Randomsong menulis tentang bagaimana Anda bisa mengajarkan pemrograman kepada hampir semua orang. Idenya adalah bahwa pemrograman tidak sesulit banyak programmer ingin percaya.
  
• , — ,
  
• ,
  
• 
  
• HN Google, 10% ,

---

1. Pertama, wawancara Google sering menyalin perusahaan kecil yang argumennya tidak sesuai. Tetapi bahkan tidak ada perusahaan besar yang mengembangkan atau mengimplementasikan algoritma skala besar (Google mungkin telah melakukan ini terakhir sekitar tahun 2003, tetapi di perusahaan IT besar modern tidak ada yang secara khusus berfokus pada pengembangan algoritma). [kembali]

2. "Nyata" ada dalam tanda kutip karena saya pergi melalui beberapa wawancara untuk alasan yang tidak terkait dengan proses wawancara itu sendiri. Mungkin saya punya rekomendasi yang sangat bagus, atau mungkin seseorang membaca blog saya atau bertanya dari mantan rekan kerja, atau melihat proyek open source saya (sejauh yang saya tahu, ini terjadi sekali atau dua kali). Biasanya, setelah kegagalan yang jelas dalam wawancara, saya bertanya mengapa saya ditawari pekerjaan, jadi saya sudah mengumpulkan koleksi alasan seperti itu.

Saya juga menyarankan kemungkinan hasil nol, karena satu-satunya wawancara pemrograman "nyata" adalah di Google, tetapi orang-orang yang salah datang untuk mewawancarai saya. Saya pergi bekerja dengan perangkat keras, dan programmer mewawancarai saya, jadi saya pada dasarnya mendapat wawancara programmer standar, kecuali bahwa satu pewawancara menanyakan beberapa pertanyaan tentang mesin keadaan dan cache coherency (atau sesuatu seperti itu). Kemudian mereka mengatur wawancara telepon dengan insinyur perangkat keras untuk memastikan bahwa saya tidak berbohong tentang bekerja di startup perangkat keras dari 2005 hingga 2013. Mungkin saja saya gagal bagian pemrograman wawancara dan dipekerjakan hanya karena percakapan telepon berikutnya.

Harap dicatat bahwa hasil saya yang lemah hanya merujuk pada wawancara pemrograman, bukan perangkat keras. Saya benar-benar pandai mewawancarai besi, meskipun saya belum lama berlatih dalam pekerjaan ini. Seorang teman saya mengatakan bahwa wawancara dengan perangkat keras sangat baik bagi saya karena jargon tertentu: Saya “berbicara seperti seorang insinyur perangkat keras” dan bahkan kami berbicara bahasa yang sama dengan insinyur elektronik. Di sisi lain, kami mengatakan beberapa hal sedemikian rupa sehingga mereka terdengar sangat bodoh untuk sebagian besar programmer, tetapi masalahnya adalah dengan kosa kata, jargon, dan bukan dengan pengetahuan atau keterampilan yang sebenarnya. [kembali]

3. Ini adalah pertanyaan yang sedikit lebih rumit daripada yang mungkin Anda harapkan melalui telepon, dan pertanyaan seperti itu dapat diharapkan pada wawancara langsung. Meskipun teman saya dalam sebuah wawancara telepon dengan Google pernah mengajukan pertanyaan dari final dunia Google Code Jam , jadi untuk kompleksitas maksimum tidak ada batasan, tergantung pada siapa yang bertanya kepada Anda.

Omong-omong, jika Anda tertarik, teman saya benar-benar tahu jawabannya, karena dia memecahkan masalah ini di Google Code Jam. Di kompetisi, dia tidak menemukan jawaban yang benar, tetapi kemudian mencari kesenangan. Namun, dia tidak menganggap wajar untuk segera menjawab melalui telepon, tetapi meminta pewawancara untuk mengajukan pertanyaan lain. Dia menolak, jadi teman saya gagal wawancara telepon. Meskipun saya ragu bahwa ada lebih dari beberapa ratus orang di dunia yang dapat menjawab pertanyaan semacam itu dengan benar melalui telepon, dan hampir semuanya mungkin akan memahami absurditas situasi. Setelah gagal dalam wawancara, teman saya mencari pekerjaan selama hampir setengah tahun sebelum menjalani wawancara untuk memulai, yang akhirnya ia kembangkan beberapa sistem utama (dalam hal dampak bisnis dan kesulitan teknis). Dia terus bekerja di sana setelah itubagaimana perusahaan melakukan IPO lebih dari satu miliar dolar. Perusahaan memahami betapa sulitnya untuk mengganti orang ini, dan memperlakukannya dengan sangat baik.[kembali]

4. Selain masalah arsitektur yang mencolok yang hanya menyebabkan penurunan layanan, ada hal lain. Tim sering memecahkan masalah kinerja hanya dengan meminta sumber daya komputasi tambahan. Beberapa perusahaan berusaha mengatasi hal ini. Saya mendengar bahwa di Facebook, banyak tim yang bekerja untuk meningkatkan laporan efisiensi ke departemen khusus yang memungkinkan mereka memblokir permintaan untuk ekspansi kapasitas jika mereka melihat adanya ketidakefisienan ekstrem dalam tim yang mereka tolak untuk memperbaikinya. Tetapi secara pribadi, saya tidak menemukan perusahaan seperti itu. Google mencoba menyelesaikan masalah ini dengan sistem yang, antara lain, menghubungkan jumlah karyawan dengan sumber daya komputasi, tetapi saya mendengar bahwa itu akhirnya ditinggalkan demi sistem yang lebih tradisional karena alasan tertentu. [kembali]