Pertanyaan terkait desain OO dalam wawancara teknis [tertutup]

Saya telah menghadiri beberapa wawancara baru-baru ini dan telah diminta oleh perusahaan untuk menjawab pertanyaan "desain model [masukkan]" lebih dari beberapa kali.

1. Apakah ini normal di industri saat ini? Saya telah berkecimpung di dunia perangkat lunak selama lebih dari dua dekade dan telah menghadiri bagian wawancara saya, tetapi saya melihat pola wawancara ini baru muncul belakangan ini.
2. Saya merasa pertanyaannya sangat terbuka berakhir. Sebagai contoh: Saya diminta untuk menggambar diagram kelas untuk "Desain tempat parkir". Saya tidak yakin level detail apa yang diharapkan pewawancara. Ini adalah tes online di mana saya diharapkan untuk melampirkan diagram visio, jadi saya tidak bisa bertanya kepada mereka apa harapan mereka.
3. Apakah Anda menggunakan pertanyaan semacam ini dalam proses wawancara Anda? Apakah mereka terkait dengan diagram kelas saja atau apakah Anda juga menanyakan urutan, diagram alur, dan ERD (ofcourse berdasarkan sifat posisi) Apakah mereka efektif dalam proses perekrutan Anda?

* Edit untuk tanggapan Kevin *

Misalnya: Pertanyaan lengkap dapat berupa "Merancang sistem manajemen tempat parkir yang dapat digunakan untuk menemukan slot kosong"

Saya bisa selesai dengan 2 kelas, ParkingLotdan Slotatau saya bisa menambahkan IVehicledan Vehicledan Cardan Motorcyclekelas. Di mana saya menggambar garis?

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

1. Untuk tingkat tertentu, ya. Siapa pun dapat membaca sintaks atau menyalin / menempelkan jalan mereka melalui solusi. Kami ingin merekrut orang yang bisa menyelesaikan masalah.

2. Mereka mengharapkan Anda untuk mendokumentasikan desain dengan cukup sehingga mereka dapat memahaminya (dan tidak lebih dari itu).

3. Saya bertanya kepada orang-orang bagaimana mereka akan menyelesaikan masalah XYZ, ya. Biasanya mereka hanya menggambarkannya secara lisan. Saya ingin melihat apakah mereka mengajukan pertanyaan untuk menjelaskan persyaratan. Saya ingin melihat bagaimana mereka berkomunikasi dengan programmer lain. Saya ingin melihat apakah mereka dapat berpikir.

Ini sangat membantu saya. Saya tidak ingin kode monyet, saya ingin insinyur perangkat lunak.

Saya menemukan pertanyaan-pertanyaan ini agak konyol. Jawaban yang benar adalah "apa kasus penggunaannya?" Tanpa use case, tidak perlu desain apa pun. Misalnya, berikut adalah jawaban yang masuk akal untuk pertanyaan tempat parkir:

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

Ini memenuhi satu kasus penggunaan yang jelas.

Anda benar-benar menunjukkan satu penggunaan pertanyaan ini dalam edit Anda, di mana Anda gagal merancang model yang bisa diterapkan.

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

Anda juga menyebutkan membuat Cardan Motorcyclekelas, yang tidak masuk akal tanpa pertimbangan lebih lanjut. Desain Anda tidak akan mendapat manfaat dari memiliki subclass Vehicle. Jika Anda memperkenalkan Motorcycletanpa perbedaan perilaku Vehicle, saya akan menganggapnya gagal.

Jika Anda tidak menemukan satu Vehiclemasalah, maka kami akan melakukan banyak wawancara langsung. Jika Anda memperbaiki itu (mungkin dengan membuat itu List<IVehicle>), saya akan menggunakan ini sebagai titik awal untuk melihat evolusi desain Anda. Ada alasan mengapa persyaratannya mendasar, dan tidak ada kasus penggunaan yang terdefinisi dengan baik - itulah cara dunia bekerja.

Saya mungkin melemparkan persyaratan baru kepada Anda bahwa "dua sepeda motor dapat parkir dalam satu slot" untuk melihat bagaimana Anda mengembangkan desain Anda untuk menanganinya. Maka mungkin kita memiliki percakapan seputar konkurensi (Bagaimana jika kita memiliki dua pintu masuk, dan dua mobil berhenti secara bersamaan - akankah desainmu gagal? Bagaimana? Apa yang bisa kita lakukan untuk memperbaikinya?). Jalan lain yang mungkin untuk dijelajahi adalah bagaimana menerapkan parkir yang ditetapkan, membebankan biaya parkir, tarif per baris (mungkin baris yang lebih dekat harus membayar lebih), waktu parkir terbatas dan bagaimana menemukan pelanggar, dll., Dll.

Saya juga akan mempertimbangkan proses berpikir Anda di sekitar tempat parkir sebagai indikasi kemampuan umum Anda untuk menganalisis masalah secara cerdas. Jika Anda harus bertanya kepada saya untuk kasus penggunaan dasar dan / atau membuat yang aneh (seperti 2 untuk 1 spesial di parkir), saya mulai khawatir bahwa Anda tidak pernah benar-benar menggunakan tempat parkir sebelumnya dan bahwa kami akan mengalami kesulitan berkomunikasi pada sesuatu yang sedikit rumit.

Saya biasa bertanya ini - kembali ketika kami membuat diagram kelas untuk pembuatan kode. Saya masih melakukannya kadang-kadang, tetapi tidak secara rutin. Saya suka pertanyaan itu karena membuat saya melihat orang itu berpikir.

Ini dimaksudkan agar terbuka. Tidak apa-apa. Tidak ada satu jawaban yang benar. Saya tidak memiliki jawaban dalam pikiran saya; Saya ingin melihat kemana arahnya. Saya pikir ini pertanyaan yang lebih baik untuk ditanyakan secara langsung, bukan "email sebagai jawaban." Ini tentang komunikasi, asumsi, dan interaksi; bukan hanya jawaban!

1. Saya telah melihat jenis wawancara ini setidaknya 12 tahun yang lalu. Ini adalah pendekatan yang saya gunakan selama 6 tahun terakhir. Pengalaman menunjukkan bahwa ia memilih kandidat yang lebih baik untuk pekerjaan daripada mengajukan 20 pertanyaan dan memberi mereka skor dari 20 pendekatan.

2. Sekali lagi, saya akan membuatnya sangat terbuka juga. Tujuannya adalah untuk memberikan ruang bagi kandidat untuk menunjukkan kemampuan. Memiliki kandidat yang mengajukan pertanyaan yang relevan pada tahap ini akan menjadi nilai tambah. Seperti halnya seorang kandidat membuat asumsi yang baik, tetapi menunjukkan bahwa itu adalah asumsi, dan perlu ditinjau sebelum implementasi.

3. Saya meminta semua karyawan potensial untuk menunjukkan keterampilan yang mereka butuhkan untuk pekerjaan saat wawancara. Untuk programmer, mereka perlu mengimplementasikan beberapa kode, dan berbicara tentang desain mereka untuk itu. Ini sangat efektif untuk mencegah perekrutan yang buruk, tetapi bersiaplah untuk tingkat kegagalan 90% saat wawancara.

Merancang sistem kecil sebenarnya adalah latihan yang sangat relevan untuk ditanyakan dalam sebuah wawancara. Ini menunjukkan keahlian Anda dalam menghasilkan solusi perangkat lunak yang baik untuk masalah domain.

Namun, saya merasa aneh hanya meminta untuk memposting diagram kelas online tanpa interaksi manusia:

• Mereka akan kehilangan esensi - alasan di balik diagram dan apa yang membuat Anda merancang hal-hal seperti itu.
• Tidak ada "tembok pembatas" untuk menghentikan pelamar dari bertindak terlalu jauh. Jika Anda mencerminkan implementasi akhir dalam diagram, Anda mungkin akan memiliki banyak kelas dan skema yang tidak dapat dibaca.
• Mampu menggambar diagram kelas UML sebenarnya bukan keterampilan yang penting, itu hanya satu notasi OO antara lain. Kemampuan untuk membuat desain yang solid adalah.

Dalam wawancara langsung, langkah-langkah ideal yang saya harapkan akan dilakukan seorang kandidat adalah:

• Bicarakan masalah dengan perekrut dan mulailah mengekspresikan solusi dasar secara lisan, ajukan pertanyaan dan sesuaikan karena perekrut memberikan kebutuhan yang lebih tepat.
• Berdiri dan buat sketsa pandangan keseluruhan sistem dan bagaimana komponen dapat berinteraksi bersama. Mungkin gaya paling murni dari UML, mungkin hanya kotak dan lingkaran.
• Tulis tes, baik tes penerimaan tingkat tinggi atau tes unit untuk salah satu komponen / kelas.
• Mulailah menulis implementasi yang sesuai.

Mudah-mudahan di beberapa titik perekrut akan mengumpulkan informasi yang cukup tentang keterampilan kandidat dan menyebutnya sehari. Tujuannya bukan untuk mengimplementasikan solusi kerja penuh (kecuali itu salah satu layanan yang tidak dibayar ini dalam wawancara menyamar).

Pertanyaan-pertanyaan OOP bersifat terbuka. Tidak ada jawaban benar atau salah, tetapi ada beberapa prinsip yang ingin dilihat pewawancara (seperti menggunakan konstruktor untuk menginisialisasi variabel, menjaga metode Anda kecil, menggunakan enkapsulasi / komposisi / polimorfisme / warisan ketika berlaku, dll).

Selalu mengharapkan struktur data, OOP, dan pertanyaan terkait database dalam wawancara, mereka sangat umum. Buku-buku seperti "cracking the coding interview" dan "programming programming exposed" dapat membantu Anda mempersiapkan.

Saya telah diminta untuk mengeluarkan desain untuk tempat parkir belum lama ini. Saya tidak diberi case use di tempat pertama, tetapi disebutkan beberapa kemudian. Saya percaya desain saya tidak sesuai dengan apa yang ada di pikiran pewawancara. Saya setuju bahwa desain perangkat lunak apa pun hanya valid untuk use case yang diberikan. Kembali ke pertanyaan wawancara ini, saya percaya bahwa pewawancara saya tidak memiliki pengalaman desain dunia nyata. Orang-orang itu percaya bahwa mereka tahu apa yang mereka minta. Ini adalah cerita lain apakah itu memang benar atau tidak.