🏦 💱 🤴🏼 Apa yang saya dalam ACID atau perspektif yang berbeda 🕞 💛 🗣️

Setelah membaca posting ini ditulis oleh farwayer , pada awalnya saya hanya ingin meninggalkan komentar, tetapi setelah berpikir beberapa lusin menit, saya memutuskan bahwa topiknya mendalam, dan saya memiliki sesuatu untuk dikatakan untuk seluruh posting. Semua sama, di satu sisi, saya adalah salah satu dari mereka yang tidak melihat kode pada wawancara dan yang kecewa dengan kurangnya pengetahuan tentang kompleksitas pencarian indeks dalam DBMS relasional, di sisi lain, saya percaya bahwa saya dapat memberikan pemahaman tentang bagaimana sekelompok pewawancara yang cukup besar berpikir, mengapa mereka melakukan (pada pandangan pertama) tidak logis dan destruktif, dan masalah apa yang mereka sendiri ingin selesaikan. Diharapkan bahwa memahami gambar "musuh" dunia akan dengan sendirinya menjawab banyak pertanyaan.

Untuk memulai, saya akan memberi tahu Anda tentang diri saya. Semoga ini bisa membantu Anda lebih memahami apa yang dijelaskan di bawah ini. Dalam pengembangan perangkat lunak selama 9 tahun, untuk beberapa waktu ia bekerja untuk dirinya sendiri (menciptakan robot pertukaran dan berdagang dengan uangnya sendiri), sebagian besar waktu ia adalah pengembang yang disewa (termasuk pengembang utama). Baru-baru ini saya berada di posisi grosir. Mengumpulkan 2 tim tingkat senior. Dia melakukan beberapa lusinan (walaupun kurang dari 100) wawancara teknis di posisi menengah, senior, senior. Saya ~~tidak bekerja~~ dalam outsourcing selama ~~sehari~~ selama hidup saya menghabiskan 18 hari. Oleh karena itu, saya dapat mengatakan bahwa semua pengalaman dikaitkan dengan produk (milik sendiri atau majikan), dan semua wawancara dilakukan dengan motivasi “untuk menemukan orang yang akan membawa manfaat maksimal bagi produk”. Saya akui bahwa pengalaman penulis artikel asli lebih besar dari saya, tetapi tujuannya bukan untuk memberi tahu Anda bagaimana melakukannya dengan benar, atau memberi nasihat tentang cara bertindak, tetapi untuk memberi tahu bagaimana Anda dapat melihat hal-hal yang sama dari yang lain, alternatif, dan bukan fakta bahwa itu benar sudut pandang.

Mari kita lanjutkan poin (nama diambil dari posting asli).

Tidak ada yang peduli dengan kode Anda

Pertama-tama, pertanyaannya adalah, apa kode yang baik dan apa harapan dari kode yang dihasilkan oleh programmer yang berpengalaman. Bagi saya, kode yang baik adalah fungsi dari tugas, kondisi di mana tugas ini ditetapkan, pedoman yang diadopsi dalam tim (perusahaan), harapan manajer teknis (arsitek), manajer produk, pimpinan QA. Misalnya, pertimbangkan beberapa tugas:

Untuk mengembangkan API untuk penerbitan berikutnya kepada semua lima ratus pelanggan B2B perusahaan untuk mengintegrasikan produk ke dalam solusi mereka - solusi yang dipikirkan dengan baik dan terdokumentasi dengan baik diharapkan dengan struktur yang paling dapat dipahami, kepatuhan dengan standar yang diterima di pasar, validasi data yang paling ketat, cakupan pengujian penuh, cakupan uji yang luas, ekstensibilitas, pencatatan logging, kepatuhan dengan semua persyaratan keamanan, skalabilitas dalam kinerja, ketahanan terhadap setidaknya DoS primitif dan contoh DDoS ;
Untuk menerapkan kepatuhan produk dengan persyaratan regulator, yang mulai berlaku dalam sebulan, dan dapat menyebabkan penutupan seluruh bisnis - solusi yang andal diharapkan dengan penekanan pada pengujian ;
Memperbaiki bug pada prod terkait caching, yang dikenal satu jam sebelum Black Friday, diharapkan solusinya akan ditulis dan disebarkan pada prod dalam 30 menit dan tidak akan merusak apa pun. Persyaratan lain berlaku di pinggir jalan ;
Uji hipotesis yang Anda perlu parsing 250 halaman situs pesaing satu kali, dan kemudian bentuk dokumen google spreadsheet untuk analis bisnis - diharapkan programmer tidak akan melakukan terlalu banyak pekerjaan dan menulis kode hanya menulis tanpa menghabiskan banyak untuk itu waktu ;
Untuk memeriksa kinerja Aerospike pada tugas yang PostgreSQL secara tradisional digunakan di perusahaan, dan ada masalah kinerja, diharapkan bahwa nuansa algoritmik dan profil pemuatan akan diperhitungkan, tetapi semua kode akan dibuang terlepas dari hasil eksperimen .

Setuju bahwa salah untuk mengevaluasi kode yang menutup semua tugas ini pada pola yang sama. Tetapi bagaimanapun juga, seorang programmer yang baik dalam pengembangan produk sering diharapkan untuk secara efektif menyelesaikan semua masalah di atas. Praktek menunjukkan bahwa efektivitas programmer dalam semua kasus ini lebih mudah ditentukan oleh pertanyaan kasus dan diskusi pengalaman daripada dengan memeriksa kode yang ditulis dengan variabel yang tidak diketahui pewawancara. Plus, kode yang ingin ditunjukkan oleh orang yang diwawancarai! = Kode yang dia tulis sambil menyelesaikan masalah bisnis.

Kemenangan pengetahuan yang tidak berharga

Pemahaman yang sangat baik tentang kemarahan yang terkait dengan

Dan fakta bahwa pencarian pada indeks B-tree di PostgreSQL memiliki kompleksitas logaritmik? Saya tahu kemarin, dan sekarang Anda

Tapi apa yang terjadi? Bug yang terkait dengan kompleksitas algoritmik adalah beberapa yang paling tidak menyenangkan untuk bisnis. Mereka tidak tercakup oleh tes unit (O (N ^ 2) selama uji coba, di mana N = 10, ini sangat cepat), mereka tidak dicakup oleh tes otomatis, integrasi, regresi dan manual untuk alasan yang sama. Mereka tidak muncul di dbe, uat, sit (setelah semua, untuk N = 1000 masih cepat). Mereka dapat menunggu bertahun-tahun untuk waktu mereka, tidak mengingatkan diri mereka sendiri, sampai satu pembeli menambahkan 250 produk ke keranjang mereka, atau sampai klien dari perusahaan broker muncul yang memutuskan untuk merakit robot HFT di lututnya. Tetapi, ketika mereka muncul, seluruh bisnis mungkin jatuh sakit.

Penyimpangan liris tentang Pengujian Kinerja

Mengantisipasi komentar tentang perlunya Pengujian Kinerja, saya akan segera menjawab bahwa itu jauh dari selalu jelas di mana tepatnya N yang terkenal perlu dinaikkan ke surga. Dan, mengingat upaya jahat untuk mengatur DoS tingkat Aplikasi, menjadi hampir mustahil untuk meramalkan semua opsi. Oleh karena itu, ya, saya juga untuk Pengujian Kinerja, tetapi ini tidak membatalkan harapan saya dari pengembang bahwa ia harus memahami secara intuitif di mana penilaian kompleksitas menjadi kritis dan berbahaya bagi bisnis.

Ini juga mencakup pertanyaan tentang ACID. Bug yang terkait dengan pemblokiran dalam DBMS, kondisi ras, transaksi dalam DBMS - ini juga merupakan bubur kertas untuk bisnis. Mereka, seperti halnya bug yang berkaitan dengan kompleksitas algoritmik, dapat duduk diam selama bertahun-tahun dan memukul dengan sangat menyakitkan. Ketika DBMS operasional utama sebuah perusahaan, ditempatkan pada server raksasa dengan redundansi maksimum untuk semuanya, hanya berhenti dengan nol beban pada CPU dan IO pada saat aktivitas klien maksimum, percayalah, ini sangat tidak menyenangkan dan, ya, itu bisa membebani gaji tahunan tim pemrogram. Oleh karena itu, Anda tidak perlu mengetahui setiap huruf ACID dengan hati (setidaknya saya tidak pernah meminta pengetahuan tentang menguraikan singkatan dan saya sendiri tidak mengingatnya,), tetapi ketidaktahuan tentang esensi setiap huruf sudah merupakan aplikasi serius untuk memasukkan bug seperti itu ke dalam kode. Jika ada dua programmer dengan ketidaktahuan seperti itu dalam tim, maka review kode juga tidak akan menyembuhkan.

Penyimpangan liris tentang warisan dan NoSQL

Mungkin contohnya tidak masuk akal (walaupun ini nyata bagi pengalaman saya), dan sebagian besar hanya relevan untuk sistem kuno dan sistem dua tautan, tetapi arsitektur NoSQL modern dengan layanan mikro memiliki lelucon sendiri dengan data tidak sinkron dan skema data yang tidak cocok pada node yang berbeda, dalam versi yang berbeda data. Saya tidak melihat alasan untuk menyelidiki hal itu sekarang.

Hancurkan kamu

Dan ini dia. Dan orang-orang tampaknya cukup. Ara mengerti. Dan kemudian Anda melihat bahwa lowongan dibuka setengah tahun. Baik, baik.

Fakta bahwa lowongan tersedia di situs web perusahaan (atau di agregator pekerjaan) tidak berarti bahwa perusahaan mencari satu orang dalam satu tim. Realitas perusahaan makanan selama pertumbuhan adalah aksi mogok makan yang abadi. Atau Anda mengukur, menangkap pasar, menyingkirkan pesaing, atau mati. Dan manajer produk memiliki sakit kepala yang kekal - "apa yang harus dibuang". Bukan “mengapa Anda memikirkan yang keren sehingga 100 programmer dapat mengunduh selama sebulan, sehingga Anda tidak bosan”, tetapi Anda harus membuang pelanggan yang keren, perlu, terencana dan diharapkan (dan berjanji) dari rencana agar tidak menunda rilis berikutnya selama setahun. Oleh karena itu, tidak ada tangan tambahan, dan fakta bahwa lowongan telah menggantung selama enam bulan tidak membatalkan kenyataan bahwa 10 orang telah menemukan dan menyewa untuk itu, dan mereka akan menerima hal yang sama dengan senang hati. Sekali lagi, tidak di mana-mana dan tidak selalu, tetapi situasi yang saya jelaskan adalah normal dan dapat diterima untuk pengembangan produk.

Pikiran ekspansi yang luas

Praktek menunjukkan bahwa perluasan luas sumber daya pemrogram jarang efektif dan sering merusak. Namun terlepas dari ini, kondisi pasar saat ini membutuhkan ini dari bisnis makanan. Memang, sementara tingkat pertumbuhan bisnis dinilai lebih dari laba operasi (saya tidak melihat alasan untuk membahas di sini apakah ini benar), para pendiri menerima tantangan ini, dan (kadang-kadang) menang. Pilihan "mari kita tumbuh secara organik tanpa kehilangan efisiensi" juga berfungsi, tetapi, sebagai suatu peraturan, keefektifan dari setiap strategi pertumbuhan tergantung pada situasi di pasar, dan diskusi mengenai hal ini akan menarik pemikiran dan fakta ke posisi yang sangat besar.

Saya tidak peduli dengan proyek sebelumnya

Saya selalu bertanya. Jadi, di sini saya sepenuhnya setuju dengan penulis. Tetapi sudut pandang beberapa orang yang tidak bertanya juga jelas bagi saya. Orang-orang ini sering tidak mengerti bagaimana membandingkan pengalaman yang berbeda dari calon yang berbeda satu sama lain. Jawaban untuk pertanyaan tertutup lebih mudah bagi mereka untuk membandingkan.

Pada membandingkan kandidat di antara mereka sendiri

Sayangnya, SDM dan penulis buku pintar , duduk di arus yang tak ada habisnya di sinior dan arsitek yang dipilih ingin masuk ke perusahaan impian di semua biaya, suka membangun berbagai sistem perbandingan yang memungkinkan Anda untuk peringkat puluhan dan ratusan kandidat di antara mereka sendiri dan memilih yang terbaik. Kemudian pendekatan-pendekatan ini dikenakan pada pewawancara teknis, dan, sebagai hasilnya, muncul kuesioner standar yang memberikan cara tuhan pada wawancara selama pemberhentian. Tetapi masalah sebenarnya bukan ini, tetapi bahwa, sebagai perbandingan, pewawancara menarik keluar proses, tunggu sampai basis komparatif dikumpulkan, dan pada saat yang sama menciptakan masalah dengan kecepatan merekrut pemilik bisnis dan menempatkan pelamar dalam posisi yang tidak menyenangkan, memaksa mereka menunggu minggu untuk jawaban. Mereka juga memaksa perekrut untuk terus-menerus berbohong sebagai bonus, karena jawaban "Anda tampaknya baik, tetapi kami akan memiliki lima lebih untuk perbandingan" tidak menggulung, dan Anda harus datang dengan sesuatu dari kategori "nenek moyang kami meninggal dengan techlide kami, jadi dia akan kembali dalam seminggu dan itu sesuatu akan memutuskan. " Saya memutuskan sendiri bahwa perbandingan itu jahat. Ini cocok - memberikan penawaran (meskipun% dari penawaran untuk saya jauh lebih rendah daripada rekan pembanding).

Pengembang yang Berpengalaman

Ada poin penting. Itu, ya, pengembang yang berpengalaman dan cerdas dengan cepat menyelidiki ke dalamnya. Tetapi jika seseorang mengklaim bahwa dia banyak bekerja dengan OAuth bersyarat pada beberapa proyek (itu penting, hanya seperti itu, dan tidak "menggunakannya sekali dalam prototipe"), dan pewawancara juga bekerja dengan OAuth, lalu mengapa tidak bertanya-tanya? Kedalaman jawaban akan menunjukkan seberapa besar seseorang akan mempelajari secara mendalam teknologi-teknologi baru yang dijumpai di jalan, apakah dia memahami prinsip-prinsip ruang engine, atau salinan dengan SO, apakah dia mencoba mengantisipasi garu.

Beberapa pemikiran lagi

Tapi di sini Anda bisa keluar, memberikan tes kecil selama satu atau dua jam (tidak ada di tempat: bagi banyak orang, wawancara masih stres).

Mungkin ada pemikiran berbeda tentang hal ini, tetapi secara pribadi, saya menemukan tugas tes menyinggung bahkan untuk tingkat menengah. Semua sama, tugas tes adalah disproporsi yang sangat kuat dalam waktu yang dihabiskan oleh perusahaan dan pelamar. Secara kondisional, pemohon menghabiskan 3 jam menulis kode + 5 lebih banyak tentang menjilat dan mencari praktik terbaik di Google, dan perwakilan perusahaan memberikan vonis dalam 1 menit. Untuk ini, pelamar perlu motivasi. Oleh karena itu, praktik yang baik, tetapi tidak untuk evaluasi programmer berpengalaman dan dicari yang siap untuk mengambil tanpa tes satu.

Dan pemikiran tentang komentar menarik dari loppi

Dan jika ada masalah yang saya tidak tahu solusinya segera - Anda selalu dapat mempelajari masalah ini dan menemukan solusi ini.

Penting bagi pewawancara tidak hanya fakta bahwa pelamar akan mempelajari masalah ini dan menemukan solusinya. Adalah penting bagaimana dia akan melakukan ini - apakah dia akan mempertimbangkan semua opsi, atau menemukan yang pertama yang muncul, bagaimana dia akan bereaksi terhadap tabrakan dengan fakta bahwa solusi yang dipilih tidak valid, dan kita perlu mencari yang baru, dan seterusnya. Mungkin ada harapan yang berbeda untuk keadaan yang berbeda.

Hanya satu wawancara yang secara radikal menonjol dari kerumunan, percakapan itu bertatap muka langsung dengan direktur teknis, ia bertanya teknologi apa yang saya gunakan, dan kemudian kami berbicara tentang berbagai masalah pada proyek mereka dan pada proyek-proyek saya di masa lalu, dan bagaimana masalah ini diselesaikan atau dapat untuk memutuskan.

Ya, cara yang bagus untuk wawancara (saya pikir dan menggunakannya sendiri), yang melengkapi masalah lain dengan baik. Dan, anehnya, ada% pengembang senior besar yang mengetahui teori ini dengan sangat baik dan memiliki pengalaman nyata bertahun-tahun, tetapi pada saat yang sama mereka menunjukkan diri mereka dengan sangat buruk ketika mencoba menyelesaikan masalah dengan sejumlah besar derajat kebebasan. Dari kekurangan metode wawancara ini, yang memerlukan persiapan panjang (Anda perlu mengekstrak esensi dari kasus nyata, menghilangkan detail yang tidak perlu dan meringkas) dan dapat menjadi tidak efektif jika tantangan utama dari pelamar dan pewawancara itu spesifik.