Pertanyaan terkait desain OO dalam wawancara teknis [tertutup]


14

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; }
}

"Desain apa pun " masalah kembali dekade.
Blrfl

Selalu tanya - Apakah Anda menginginkan jawaban spesifik dan sederhana untuk masalah ini? Atau Anda ingin jawaban yang lebih kuat untuk masalah umum?
Chris Cudmore

Jawaban:


10
  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 tidak dapat mengajukan pertanyaan untuk menjelaskan persyaratan karena saya ditanyai ini sebagai bagian dari tes online. Saya mengerti menilai kemampuan komunikasi mereka mungkin sebagian menjadi motif di balik pertanyaan semacam itu. Tetapi apakah itu benar-benar membantu memahami keterampilan analitis dan desain mereka?
Nick

1
@nick - tak tahu. Tes online adalah manfaat yang dipertanyakan di tempat pertama. Secara pribadi, ini memberikan beberapa wawasan untuk keterampilan desain.
Telastyn

6

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.


Apakah Anda menyarankan bahwa pertanyaan-pertanyaan ini hanya memiliki nilai ketika ada kasus penggunaan yang terkait dengannya? Jika ada kasus penggunaan, bagaimana Anda masih menentukan kedalaman apa yang diharapkan pewawancara. Silakan lihat edit **
Nick

2
Saya menyarankan agar sebelum merancang apa pun saya akan setuju pada kasus penggunaan dengan pewawancara.
kevin cline

1
Itu tidak membuatnya menjadi pertanyaan konyol. Sebaliknya, akan membantu untuk mengetahui apakah seorang kandidat mampu mengklarifikasi persyaratan yang tidak jelas. Itu keterampilan yang penting.
Cameron Skinner

1
Tidaklah konyol jika pewawancara tahu bahwa tidak ada cukup informasi untuk mulai mendesain sesuatu.
kevin cline

Saya setuju dengan jawaban Anda & komentar Anda di atas. Selalu ada kemungkinan dengan pertanyaan semacam ini bahwa pewawancara hanya mengambilnya karena dia "menyukainya" tanpa benar-benar menyadari untuk apa itu (menilai kemampuan kandidat untuk menuntut rincian hak / wajib untuk masalah yang tidak lengkap / kabur / umum). Hal ini pada gilirannya dapat menyebabkan pewawancara memperlakukan segala jenis pertanyaan / klarifikasi tindak lanjut sebagai "pendekatan buruk" untuk masalah tersebut.
Shivan Dragon

5

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.


3

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!


"Saya suka pertanyaan itu karena itu membuat saya melihat orang itu berpikir" -> Apa sebenarnya yang Anda cari ketika Anda mengevaluasi keterampilan berpikir orang itu? Apakah kecepatan mereka memecahkan masalah? Apakah ini solusi terakhir? Apakah ini seberapa dalam mereka menciptakan kelas, antarmuka? Apakah ini cara mereka menunjukkan seberapa banyak mereka tahu konsep OOP (pewarisan, polimorfisme, dll)?
Nick

Apakah ini metodis? Apakah mereka memikirkan apa yang salah? Apakah mereka memikirkan alternatif? Apakah mereka menyatakan kekalahan dengan pertanyaan aneh dengan cepat? (Saya biasanya meminta sesuatu seperti telepon, bukan objek yang dirancang kebanyakan orang sebelumnya?). Saya tidak mencari kecepatan (kecuali seseorang butuh 15 menit sebelum bahkan mulai mengatakan sesuatu!)
Jeanne Boyarsky

3
  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.


Menjadikan pertanyaan terbuka berakhir baik-baik saja selama saya dapat menanyakan kepada pewawancara secara cerdas untuk informasi spesifik. Ketika saya diminta untuk melakukan ini secara online, yang bisa saya lakukan hanyalah menebak solusinya. Apakah Anda biasanya mengajukan pertanyaan desain ketika Anda melakukan wawancara tatap muka?
Nick

Saya cenderung melakukan keduanya. Tantangan pemrograman teknis, yang mereka kirimkan melalui email sebelum diundang ke wawancara, serta berbagai latihan tatap muka.
Michael Shaw

Tantangan terbuka ini tidak memiliki satu jawaban yang benar, dan ada hal lain yang salah. Tujuan mereka adalah untuk mengidentifikasi orang-orang yang memiliki proses pemikiran yang baik, membuat keputusan yang masuk akal dan untuk menilai berapa banyak dukungan yang mereka perlukan untuk melakukan tugas-tugas pekerjaan.
Michael Shaw

2

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).


0

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.


-1

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.


1
bagaimana ini menjawab pertanyaan yang diajukan?
nyamuk
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.