Insinyur Senior dalam mencari pekerjaan. Tentang tugas di wawancara teknis dan pertanyaan teoritis

Kami terus berbicara tentang wawancara teknis (jika Anda belum membaca, lihat artikel sebelumnya dalam seri ini - tentang wawancara dengan SDM dan teknis ). Kali ini akan ada pengalaman yang lebih subyektif, minimal tips, serta sedikit tentang tugas ujian dan pertanyaan teoritis. Ayo pergi.

Penafian: penulis bukan pengembang turbo, tetapi kera web biasa tanpa keluhan. Oleh karena itu, tugas dan solusi di atas dapat menyebabkan Anda tersenyum, pantat-dan-keinginan dan keinginan untuk menunjukkan kepada penulis ketidakmampuannya. Saya berharap dapat melihat Anda di komentar! :)

Diskusi soal-soal tes yang diselesaikan

Pada bagian terakhir, saya menjelaskan bagaimana saya melakukan dua tugas pengujian: yang pertama di DevOps Engineer, yang kedua di Ruby Developer. Saya akan memberi tahu Anda apa yang terjadi selanjutnya.

Wawancara di Ruby Developer - pewawancara bahkan tidak melihat tes saya, tidak mengajukan pertanyaan kepadanya, tidak memberikan pujian (saya menyelesaikan tugas lebih baik daripada semua kandidat sebelumnya, setidaknya, perekrut menyanjung saya). Sepertinya dia bahkan tidak tahu tentang dia. Ini sedikit membuatku kesal, karena kemudian mereka mulai bertanya padaku teorinya, dan, sebagai akibatnya, mereka menolak melalui teorinya.

Wawancara tentang DevOps Engineer - pewawancara melihat tugas, memberikan pujian (mengatakan bahwa saya telah menyelesaikannya secara kualitatif) dan mengajukan beberapa pertanyaan kontrol pada solusi: mengapa baris ini ada di sini? jika Anda mengganti kondisinya dengan ini, di file mana Anda perlu melakukan ini? mengapa pendekatan ini digunakan di sini? dan sebagainya. Seperti yang dikatakan oleh perekrut kepada saya, beberapa kandidat tidak melakukan tugasnya sendiri, dan tidak dapat menjawab pertanyaan seperti itu. Karena itu, di sini saya berhasil tanpa masalah.

Dalam kasus pertama, saya tidak bertanya kepada orang yang diwawancarai apakah dia telah menyaksikan tugas pengujian saya sama sekali dan apa pendapatnya tentang ini. Tapi itu perlu! Jika Anda memiliki situasi seperti itu, maka pastikan untuk memberi tahu orang yang Anda wawancarai tentang hal ini.

Tugas Wawancara

Kami melanjutkan topik tugas pengujian dari bagian sebelumnya dan mempertimbangkan tugas pengkodean saat wawancara.

Mungkin ada beberapa jenis tugas: menerapkan algoritma, menulis solusi dalam pseudo-code, refactor sesuatu, dan sebagainya. Teknisi kami paling menyukai masalah algoritmik.

Banyak orang, termasuk saya, percaya bahwa tugas-tugas ini hanya menunjukkan kemampuan kandidat untuk menyelesaikan masalah seperti itu saja, dan tidak menunjukkan sama sekali bagaimana ia akan mengatasi tugas kerja nyata, yang, sebagai suatu peraturan, adalah tingkat yang lebih tinggi. Mengapa mereka masih memberi mereka? Saya pikir alasannya sederhana: pewawancara tidak dapat menemukan sesuatu yang lebih baik. Dan karena kita tidak dapat menghasilkan sesuatu yang lebih baik, mari kita ambil inversi garis lama yang bagus, menyortir, menyeimbangkan pohon, dan banyak lagi.

Sebagai alat yang digunakan untuk solusi, editor kode + repl + kemungkinan kolaborasi paling cocok. Dari semua opsi yang ada di pasaran, saya paling suka CoderPad . Sebuah ruangan dibuat dimana Anda dan pewawancara terhubung, Anda dapat mengedit, mengeksekusi kode bersama dan melihat hasil eksekusi. Sangat nyaman Jika tidak ada uang untuk codepad, maka repl.it masuk ke pertempuran dan berbagi layar pada dasarnya sama, hanya tanpa kemungkinan kolaborasi.

Pembaruan: ketika artikel sedang diterjemahkan, repl.it menambahkan Mode Multiplayer, yang memungkinkan jumlah peserta yang tidak terbatas untuk bekerja secara bersamaan dengan kode. Benar-benar gratis! CoderPad tidak lagi dibutuhkan, tepuk tangan!

Saya memiliki wawancara dengan perusahaan untuk posisi Pengembang Java . Perusahaan melakukan sesuatu seperti CRM dan menulis banyak integrasi. Saya menghubungi spesialis teknis Zoom dan dia berkata: "Mari kita mulai dengan masalah algoritmik." Saya menjawab: "Oke, saya akan melakukan tugas itu, tetapi saya punya pertanyaan: apakah Anda membutuhkan pengetahuan ini dalam pekerjaan Anda, apakah Anda perlu menyelesaikan hal-hal serupa?" Untuk itu saya mendapatkan jawaban yang fenomenal: "Kami menulis titik akhir dan mendorong json-chiki bolak-balik, tetapi tidak menarik untuk membicarakannya , jadi mari kita selesaikan masalahnya." Artinya, pewawancara sendiri mengakui ketidakmampuannya. Saya tidak tahu siapa caranya, tetapi sejak saat itu saya menyadari bahwa saya tidak punya apa-apa untuk ditangkap di sana. Namun, karena minat olahraga, percakapan berlanjut.

Kami membuka blok kode dan melanjutkan ke tugas, dengan syarat saya disuarakan secara lisan: "Temukan urutan karakter unik terpanjang dalam string yang diberikan." Setelah itu, pewawancara mengatakan bahwa "seseorang dapat memberikan tugas untuk pemrograman dinamis , tetapi kami akan membatasi diri pada pilihan yang lebih sederhana." Saya ingin melihat orang yang akan memberikan tugas pemrograman dinamis pada wawancara, dengan serius.

Saya mengulangi persyaratan tugas kepada pewawancara untuk memastikan saya memahaminya dengan benar, yang saya terima dengan tegas dan mulai bekerja. Setelah 5 menit ternyata saya mengerti masalah semua sama salah, karena itu perlu untuk menemukan bukan substring, tetapi panjangnya (ini lebih mudah). Namun, saya menjawab, "Yah, sejak mereka mulai, maka mari kita selesaikan masalah dengan tanda bintang, dan bukan yang sederhana." Pewawancara agak bingung, karena dia telah menyiapkan tes khusus untuk kondisinya, tetapi saya sudah memutuskan bahwa saya tidak akan memberikan yang kembali dan akan mencoba untuk melakukan apa adanya. Saya bertanya berapa banyak waktu yang saya miliki (sekitar 40 menit) dan mulai coding. Saya perhatikan bahwa, meskipun saya tahu bahwa mereka akan memberikan tugas, saya tidak mempersiapkannya secara khusus.

Jadi, saya langsung menulis tes dan mulai perdukunan dengan indeks i, j dan k :) Loop dalam loop, dan sebagainya. Setelah 15-20 menit saya memiliki solusi setengah bekerja, tetapi kasus batas yang diberikan pewawancara tidak melewati. 20 menit kemudian, pada akhirnya, saya masih menyelesaikan tugas dengan benar. Pewawancara tampak puas, dan kemudian mulai bertanya kepada saya tentang struktur data. Ternyata untuk menyelesaikan masalah yang ingin dia berikan pada awalnya, mungkin saja menggunakan hash, atau sesuatu seperti itu, dan dia mengharapkan solusi seperti itu, tetapi saya hancurkan semuanya.

Kemudian kami berbicara sedikit tentang proyek (formulir dan tumpukan). Dan kemudian dia berkata: “Setelah itu akan ada wawancara tentang desain sistem. Secara umum, saya tidak melihat alasan untuk melaksanakannya, karena kami tidak melakukan ini di sini dan kami tidak membutuhkan pengetahuan seperti itu, tetapi pesanan adalah pesanan, jadi langkah selanjutnya adalah ini. " Nah, Anda mengerti - dua (!) Wawancara dilakukan untuk memahami apakah kandidat dapat melakukan hal-hal yang tidak diperlukan dalam pekerjaan sehari-hari di perusahaan ini. Kemudian saya membiarkan diri saya berbicara sedikit tentang tidak ada artinya wawancara tersebut. Pewawancara setuju dengan saya, tetapi lagi-lagi termasuk pelimpahan tanggung jawab dan berkata: "Bukan saya yang memutuskan seperti apa prosesnya, jadi kami melakukan apa yang kami lakukan." Saya akan menambahkan bahwa saya telah melalui wawancara kedua (tentang desain sistem) dan itu sama tidak berartinya dengan yang pertama.

Apa kesalahan yang dibuat pewawancara - dia tidak memperbaiki kondisi tugas dalam teks. Ketika saya melakukan wawancara seperti itu, saya hanya menyalin kondisi tugas ke dalam editor kode sehingga kandidat tidak akan memiliki pertanyaan.

Kesalahan apa yang saya buat - Saya langsung bergegas untuk menulis kode, tanpa menentukan tiga kali apakah saya memahami kondisinya dengan benar. Jika Anda akan diberikan tugas seperti itu di wawancara, segera lepaskan sambungan dari obrolan dan temukan pelajaran yang lebih menarik bagi diri Anda, periksa beberapa kali jika Anda memahami kondisinya dengan benar, tulis tes di editor dan dapatkan konfirmasi dari pewawancara bahwa semuanya sudah benar.

Saya juga punya wawancara untuk posisi Ruby Developer . Setelah bertemu dan membuat pertanyaan, saya diberi tugas untuk menulis metode Each_slice. Bagi mereka yang tidak tahu, ini adalah hal yang hits array sub-ukuran dengan ukuran tertentu dan mengeksekusi masing-masing dari mereka sebuah blok yang kita lewati ke metode, atau mengembalikan iterator atas sub-array ini. Saya duduk untuk menulis, dan kemudian saya menyalakan tuping. Masalahnya adalah bahwa pada Ruby, untuk beberapa waktu saya berhasil hanya terlibat dalam macing web, dan, sebagai daftar putih referensi, tidak tahu beberapa konstruksi bahasa dasar. Yaitu - Saya tidak tahu bahwa indeks dalam for loop tidak dapat diubah (tidak seperti, misalnya, Java).

Saya menulis metode itu sendiri kurang lebih cepat, tetapi tidak berhasil, dan saya tidak mengerti mengapa. Saya mulai panik sedikit, menghapus semuanya dan menulis lagi, tetapi kode saya lagi tidak berfungsi sebagaimana mestinya.
"Itu tidak berjalan," pikir saya, dan mengatakan kepada teman bicara saya: "Kawan, Anda tahu, saya pandai hosting web dan melakukan proyek, tetapi saya tidak berhasil dengan tugas bodoh Anda. Saya mengerti bahwa ini adalah tugas yang sederhana dan seseorang dengan 10 tahun pengalaman wajib melakukannya dengan cepat. Jadi jangan biarkan saya menunda Anda lagi, dan kami akan bubar. " Orang-orang setuju, dan berpisah.

Saya dibom dengan serius karena saya tidak terbiasa kalah dengan mudah. Untuk entah bagaimana masuk ke plus eksistensial, saya menulis kepada seorang perekrut bahwa saya telah dipecah pada tugas yang tidak terkait dengan pekerjaan nyata. Lalu dia tenang, duduk, dengan cepat menguji bagaimana indeks bekerja dalam siklus. Saya menyadari bahwa saya membuat kesalahan junior, membuat ulang indeks dan mendapatkan solusi yang sudah jadi. Bahkan, kesalahan yang saya miliki adalah pada baris yang sama. Saya memberi tahu HR tentang hal ini dan menyarankan agar dia memberikan tautan ke solusi kepada mereka jika mereka tertarik, karena saya masih menyelesaikan masalahnya. Tetapi dia menjawab: "Kamu tidak melangkah lebih jauh karena kamu tidak menyelesaikan masalah, selamat tinggal ." Saya masih mengerti sedikit tentang proses wawancara yang rusak untuk entah bagaimana membenarkan diri kita sendiri dan kita berpisah.

Setelah itu, saya memikirkan kembali sikap saya terhadap tugas-tugas semacam itu. Biasanya tidak pernah masalah bagi saya untuk kode sesuatu di bawah pengawasan, tetapi beberapa faktor bekerja di sini: aplikasi saya untuk posisi yang serius, kurangnya pemahaman tentang konstruksi dasar bahasa (meskipun saya tidak pernah membutuhkannya, dan jika saya membutuhkannya, saya bisa mencari solusinya) dalam 5 detik) dan efek pengamat. Tentu saja, saya membaca bahwa banyak orang tidak dapat memecahkan masalah ketika mereka melihat mereka, tetapi bagi saya sepertinya selalu ada alasan untuk ketidakamanan dan ketidakmampuan saya sendiri, sampai saya sendiri menemukan orang-orang kasar ini dengan setiap kesalahan.

Saya juga punya wawancara untuk posisi Pengembang Java. Kali ini diadakan dalam format yang sedikit berbeda. Kami menghubungi oleh Zoom dan pewawancara berkata: "Katakan padaku email Anda, saya akan mengirim Anda tugas, membacanya, beri tahu saya jika semuanya jelas. Anda akan memiliki dua jam, saya akan bisu dan saya tidak akan menonton apa yang Anda lakukan di sana (kami tidak bermain dengan layar). Dua jam kemudian, kami menghubungi, meraba-raba layar dan melihat apa yang Anda lakukan di sana. Anda bisa menggunakan apa saja. " Saya membaca kondisi tugas, berbicara lagi dengan pewawancara, mematikan video (karena pengkodean aliran memakan CPU) dan menjadi bingung. Membuka IDE dan memulai.

Tugas itu terkait dengan I / O - perlu membuat API untuk menulis data ke file pada disk, sehingga semuanya aman dan cepat, dan juga menulis unit test yang akan memeriksa ini (termasuk keamanan utas). Saya belum pernah bekerja dengan concurrency dan I / O untuk waktu yang lama, jadi saya harus cepat-cepat pergi ke dermaga dan mengingat apa yang terjadi. Saya menulis solusi di dahi, memeriksa apakah aman, dan sebagainya. Segala sesuatu tentang semuanya membutuhkan waktu sekitar satu setengah jam. Saya ping pewawancara saya, mengatakan bahwa saya sudah siap, tetapi hanya ada satu hal kecil untuk dipoles, akankah kita melihatnya? Terhadap hal ini dia menjawab: "Mari kita duduk setengah jam lagi dan selesaikan semua yang belum selesai." Ok, saya duduk dan mengingat semua hal kecil dan kasar, saya menyelesaikan javadki, sekali lagi saya membaca semua yang saya bisa tentang I / O dan berpikir apa yang bisa menjadi kerugian dari solusi saya.

Setelah setengah jam, kami menghubungi, saya berbagi layar, menunjukkan kode, menjalankan tes, dan sebagainya. Setengah jam berikutnya, kami berbicara tentang pemecahan masalah dan kemungkinan opsi untuk modifikasi ketika mengubah kondisi tertentu. Saya ingin menarik perhatian pada kenyataan bahwa dalam wawancara-wawancara sebelumnya (dan dalam wawancara-wawancara berikutnya juga) tidak ada yang menyiapkan dasar untuk percakapan dengan tugas-tugas, itu selalu hanya semacam karya abstrak, yang memberi 0/1 pada output, dan kami melanjutkan ke pertanyaan berikutnya. Dan di sini tugasnya cukup sederhana sehingga bisa dilakukan dalam beberapa jam, tetapi pada saat yang sama cukup teliti untuk menambahkan kondisi dan mendiskusikan dengan kandidat bagaimana dia akan menyelesaikan keputusan.

Saya sangat menyukai wawancara ini. Saya dapat menunjukkan bahwa tidak hanya desis desis dapat menyelesaikan, tetapi juga memahami sesuatu dalam arsitektur. Pewawancara yakin bahwa dia tidak duduk di bulan Juni, tetapi seorang spesialis yang menembak sesuatu dalam pekerjaannya. Itu adalah wawancara teknis terbaik yang pernah saya miliki. Saya pikir Anda sudah menebak bahwa pewawancara itu bukan salah satu dari kami :) Saya juga akan menambahkan bahwa saya berhasil melewatinya, kemudian dua tahap lagi dan akhirnya menerima tawaran. Tapi itu cerita lain.

Apa yang baik tentang tugas ini?

• Kedekatan dengan pekerjaan nyata, dengan apa yang mereka lakukan di perusahaan itu.
• Batas waktu.
• Kurang observasi.
• Kemampuan untuk menggunakan apa saja dan bukan pemeriksaan memori.
• Menciptakan dasar untuk percakapan lebih lanjut.
• Menguji keterampilan kandidat untuk kode, menggunakan IDE dan berpikir secara umum.

Sayangnya, dari semua wawancara, saya hanya punya tiga tugas seperti itu, jadi pilihannya kecil. Mungkin ada beberapa tes / tugas yang lebih rumit, tetapi saya tidak mendapatkannya.

Kekurangan Khas Tugas Wawancara

1. Tugas itu tidak ada hubungannya dengan pekerjaan nyata. Itu paling mengganggu saya. Algoritma diizinkan untuk diselesaikan, meskipun pada kenyataannya tumpukan itu memukau. Mari tugas yang relevan, saya akan melakukan Anda kasar! Mengapa Anda membutuhkan orang yang tahu cara mencari substring dalam string?
2. Organisasi - seringkali tidak ada alat normal untuk solusi. Begitu mereka menunjukkan saya kode di google docs, setelah saya meraba-raba layar di repl.it, dulu adalah CoderPad.
3. Tugas tidak menciptakan konteks untuk percakapan lebih lanjut - ini adalah konsekuensi dari paragraf pertama. Mengapa memberi tugas jika kita tidak membahasnya nanti?
4. Tidak semua orang bisa mengatasi tugas di bawah pengawasan. Dengan demikian, kandidat yang baik dapat dihilangkan pada tahap ini.

Pertanyaan teoritis

Ini bagian favorit saya. Semua orang suka bertanya teori, mari kita bahas ini sedikit.

Untuk beberapa alasan, kebetulan bahwa sebagian besar dari saya ditanya teori di posisi Ruby Engineer. Saya tahu yang terburuk dari semuanya, jadi saya terus mengisi wawancara dan terlihat seperti sebuah guci sampai saya menyadari bahwa tidak lagi cocok untuk melanjutkan seperti ini. Saya duduk dan membaca buku teks pada bahasa tersebut, yang memungkinkan saya untuk berbicara lebih baik dan tanpa merengek, “Kawan, mengapa Anda menanyakan hal ini kepada saya? Saya adalah pengembang yang baik, apa bedanya, bagaimana urutan metode pencarian suatu objek? Siapa yang butuh ini? "

Wawancara pertama yang saya lakukan sebagai Pengembang Ruby adalah persis di mana tugas pengujian harus dilakukan, namun, ternyata, tidak ada yang tertarik. Timlid, yang seharusnya berkomunikasi dengan saya, tidak datang (dia macet atau macet), jadi mereka memberi saya satu lagi. Setelah bertemu, ia berkata, "Saya punya peraturan - saya melakukan semua wawancara dalam bahasa Inggris, jadi kami beralih ke bahasa Inggris." Dan kemudian telingaku dipelintir menjadi nanotube graphene, karena pewawancara memiliki aksen yang sangat kuat. Ini agak membuat saya gelisah (sangat sulit bagi saya untuk berkomunikasi dengan rekan saya dalam bahasa Inggris).

Selanjutnya muncul pertanyaan: apa itu modul, apa itu blok, apa yang dihasilkan, dan saya mulai mengajukan. Alih-alih mendefinisikan "seperti dalam buku teks," saya mulai mengoceh: "Yah, saya tidak tahu definisi yang tepat, tetapi mungkin ini hal seperti itu, saya menggunakannya seperti itu." Pewawancara tidak bahagia, saya mulai merasakannya dan kemudian berpikir bahwa semua orang telah tiba.

Lalu ada pertanyaan tentang metode khusus, yaitu: "Apa nama metode yang menyaring semua nol dalam koleksi?" Lalu saya menyalakan troll dan menjawab: "Jika Anda memeriksa ingatan saya untuk mengetahui metode ini, maka saya tidak dapat memberi tahu Anda apa pun tentang apa yang belum saya gunakan baru-baru ini. Saya menulis dalam banyak bahasa dan platform dan tidak ingat semua metode SDK. " Ini tidak memuaskan pewawancara, dan pertanyaan berikutnya adalah sesuatu seperti: “Apa itu Enumerable? Metode apa yang ada dan siapa yang akan memperluasnya. " "Paman, apakah kamu tidak mengerti?", Saya berpikir dalam hati, tetapi berkata dengan keras, "Saya tidak tahu pasti, saya pikir ada beberapa metode seperti peta / pengurangan / iris dan sebagainya." Itu juga tidak cocok untuknya.

Lalu dia menanyakan pertanyaan standar tentang di mana harus meletakkan logika di MVC. Saya menjawab itu dalam model, dan jika tidak sesuai dengan model, maka di beberapa kelas lainnya. Ternyata yang disebut Service Objects adalah jawaban yang benar (apakah sampah ini juga ada di sini?). Saya menggumamkan sesuatu sebagai tanggapan, seperti, yah, Anda bisa menyebutnya begitu, tetapi saya tidak menyukainya.

Lalu dia menanyakan pertanyaan standar tentang SQL, yang sudah bisa saya jawab dengan benar, lalu bertanya tentang RSpec, yang tidak saya gunakan, itu saja. Di Rails (dan mereka hanya punya rails) saya tidak menerima satu pertanyaan pun. Juga, saya belum menerima satu pertanyaan tentang pengalaman saya sebelumnya.

Setelah itu, dia bertanya apa pendapat saya tentang stand-up harian. Kemudian saya memutuskan untuk tidak memberikan jawaban yang diharapkan secara sosial (gudang dibakar - bakar dan pondok!), Dan segera mengatakan bahwa itu adalah buang-buang waktu dan dipraktikkan dalam tim di mana manajer tidak dapat memastikan transparansi dan kemudahan melaporkan kemajuan. Dan dia menambahkan bahwa Scrum adalah sampah dalam minyak nabati, dan tidak ada yang biasanya bekerja sesuai dengan scrum, tetapi semua orang hanya berpura-pura. Jelas, saya masih meraih kontra.

Lebih jauh, ia menyarankan untuk mengajukan pertanyaan kepadanya (tampaknya karena kesopanan), dan saya sendiri bertanya tentang proses, arsitektur, dan sebagainya. Apa yang saya dengar, saya tidak suka, karena mereka melakukan banyak bersepeda untuk tugas-tugas khas. Saya ingin menjelaskan kepada orang itu bahwa saya bukan hanya seorang pengembang, tetapi saya bisa melakukan sedikit lagi, tetapi semuanya sia-sia, dan segera dia berkata bahwa sudah waktunya baginya untuk bersatu dan berlayar.

Keesokan harinya, seorang perekrut menulis surat kepada saya dan memberi tahu saya tentang penolakan tersebut. "Dan terima kasih Tuhan," pikirku, tetapi masih sedikit terbakar. Saya mendapat kesan bahwa pewawancara memiliki beberapa prasangka sejak awal, saya tidak tahu. Ngomong-ngomong, ini adalah kantor yang sama yang menyeret satu bulan dari kontak pertama ke wawancara teknis.

Jadi, mereka menolak saya karena saya tidak tahu dasar-dasar bahasa (Ruby). Ok, mari kita lanjutkan.

Wawancara lain di Ruby Debeloper , sudah dua pewawancara . Ada baiknya bahwa setidaknya satu diucapkan dalam bahasa Rusia, yang kedua - dalam bahasa Ukraina, jadi saya tidak perlu mematahkan otak saya. Yang mengejutkan saya, cerita yang sama dimulai: apa itu modul, apa itu blok. Saya belum membaca buku pelajaran, jadi saya berenang lagi dalam jawabannya. Selanjutnya ditanya tentang jenis-jenis asosiasi di Rails. «- -», — , . ( ), , : « ». , — each_slice. , , . : « , - Rack middleware?». , . , , ( Java Servlets, middleware - Laravel/Express), . , .

, , . . , , rack middleware, , .

. — . , , , , …

Ruby Developer. , . , , . Proc, , :) : « , , , - ». 100% , - , . .

: « require». Rails Grape, , , . « , ». , . - -, « , ?». ActiveRecord — , .

concurrency ( ). , concurrency Ruby — . , , . , MRI — JVM , volatile synchronized , . , , ( !) concurrency . ? ?

, - SOLID. , « — », . , . , . - , . , « ». .

? . , , , . , ! ( ). , , Cracking Ruby Interview, . , - «» , , , :)

.

Fullstack Java Developer. — . , . , , Java.

, , , - . , , , , . , , .

. . , , , undefined null, var. JS WAT-. : «, WAT . , , , ». , -. «JavaScript: The Good Parts», .

, , . (?) , ( , ) , . . , :)

- , , . jQuery, . :)

DevOps Engineer , . : « ?». - :) , , — . , . , , , . . ( )?

( MVC). (-) 5-10 . ( GoF) . . Ruby-, , — , , ( MVC ActiveRecord ). Java- .

SOLID , , : Ruby-, — Java. DRY :)

?

1. , .
2. , .
3. , .
4. , .

, , :

• / . , . : « -AOP AspectJ Spring?» :) , , .
• LeetCode , .

, , . , , « » , .

( , ), , !