Bagaimana cara merancang sistem arbitrer dalam wawancara? [Tutup]


36

Pertanyaan umum dalam Wawancara Teknologi adalah merancang sistem tertentu, biasanya produk perusahaan yang sudah ada. Misalnya, "Desain Google Documents".

Apa jawaban yang diharapkan untuk pertanyaan seperti itu? Maksud saya, sistem seperti itu pasti memiliki desain yang rumit yang berada di luar cakupan wawancara apa pun. Apa yang diharapkan pewawancara dalam waktu sesingkat itu?


4
+1 Seorang teman saya baru saja ditanya ini beberapa hari yang lalu. Saya mengatakan hal yang sama. Saya berusaha keras untuk mengajukan pertanyaan wawancara terbuka. Tanyakan kepada orang yang diwawancarai tentang proyek mereka dan bagaimana / mengapa desain mereka. Dengan cara ini mereka dapat memberi tahu saya tentang sesuatu yang sudah mereka ketahui dan lakukan. Alih-alih tersandung melalui desain papan tulis bertanya-tanya apakah akan memulai pada persyaratan atau membuat banyak asumsi karena batas waktu yang jelas ...
P.Brian.Mackey

6
Jika ini adalah produk yang sudah ada, saya akan menjawab, "Apa yang Anda temukan kekurangan dalam desain Anda yang sudah ada?"
Blrfl

5
"Baiklah .. langkah 1 akan menghubungi pengacara untuk melihat apakah kita melanggar merek dagang atau hak cipta"
Steven Evers

12
"Keberatan kalau aku melihat dokumen persyaratan?"
Joel Etherton

4
"Tidak pernah menggunakannya. Apa fitur utamanya?"
Steven A. Lowe

Jawaban:


22

Wawasan bagaimana otak Anda melihat masalah ini. Berikut adalah beberapa poin awal yang dapat saya lihat bagaimana seseorang dapat mencoba melakukan percakapan ini:

  • Top-down - Melihat ke bawah dari tingkat yang sangat tinggi membangun desain dan menyempurnakan desain sebagai berbagai komponen dilakukan dan di sini ada beberapa komponen yang bisa saya lihat ....

  • Bottom-up - Melihat dari bawah ke atas, berikut ini adalah potongan-potongan yang bisa dibangun untuk mencoba disatukan ....

  • Klarifikasi persyaratan - Mengajukan pertanyaan tentang skala yang diproyeksikan, ukuran, anggaran, dan tim yang digunakan untuk desain ini. Anda dapat mencoba membuat kode orang pengolah kata yang sangat disederhanakan atau Anda dapat merencanakan untuk menghabiskan ratusan juta dolar untuk membuat sistem manajemen dokumen utama yang Anda yakini adalah bagaimana Anda Google Doc mengambil ekstrem. Juga di sini adalah kemampuan untuk menanyakan sesuatu seperti, "Apa yang Anda maksud dengan Google Doc? Berapa banyak fungsi yang ingin Anda tiru?" pertanyaan juga.

Kuncinya adalah seberapa baik Anda bisa mengomunikasikan pikiran dan pendekatan Anda dalam mengatasi masalah seperti ini karena Anda mungkin mendapatkan pengguna mendekati Anda dan bertanya, "Psst, bisakah Anda membuat sesuatu seperti ini dalam 2 minggu?" itu sebenarnya bisa terjadi. Jadi, bagaimana Anda memberikan jawaban itu lebih penting daripada apa jawabannya.


Pendapat pribadi saya adalah bahwa proyek masa lalu bukan ide yang baik di sini. Apa yang seseorang coba temukan adalah kreativitas dan kemampuan komunikasi seperti apa di bidang baru daripada sekadar mengingat bagaimana sesuatu dilakukan di masa lalu. Kemungkinannya adalah bahwa sementara sesuatu yang terjadi di posisi baru mungkin mirip dengan sesuatu dari masa lalu, mungkin ada perbedaan yang cukup bahwa solusi lama tidak layak. Inilah sebabnya mengapa sementara apa yang dibangun mirip dengan aplikasi yang ada, mungkin ada berbagai penyesuaian yang membuat solusi sangat berbeda dari contoh awal.

Wawancara adalah jalan dua arah. Manajer dan pengembang lain jarang ahli dalam wawancara, jadi saya tidak yakin saya melihat nilai dalam mencoba untuk menyatakan bahwa mereka harus menjadi ahli dalam wawancara pekerjaan. Perekrut yang saya lihat berharap untuk tahu bagaimana melakukan wawancara, tetapi ada banyak perekrut miskin yang dapat digunakan sebagai contoh mengapa ini tidak selalu merupakan ide yang baik.


2
Lebih baik untuk bertanya kepada orang yang diwawancarai tentang proyek yang mereka kenal. Dengan cara ini Anda dapat melihat bagaimana pikiran mereka bekerja selama proses kerja mereka yang sebenarnya. Anda dapat menghentikan mereka dan meminta klarifikasi detail untuk melihat seberapa dalam pengetahuan mereka tentang domain mereka. "Mengapa kamu tidak menggunakan antarmuka sebagai parameter untuk metode ini?" Kemudian, terserah Anda sebagai pewawancara untuk mengajukan pertanyaan yang tepat. Ini tepat karena orang yang diwawancarai berada di domain Anda ... bukan milik mereka.
P.Brian.Mackey

2
+1 jika saya bisa: "Kuncinya adalah seberapa baik Anda bisa mengomunikasikan pikiran Anda" ... sayangnya, saya percaya bahwa sebagian besar pewawancara dan kandidat kurang dalam bidang ini.
Anon

2
"Lebih baik untuk bertanya kepada orang yang diwawancarai tentang proyek yang mereka kenal. Dengan cara ini Anda dapat melihat bagaimana pikiran mereka bekerja selama proses kerja mereka yang sebenarnya." Sebenarnya semua yang akan dilakukan adalah menguji daya ingat mereka terhadap pekerjaan desain yang telah mereka lakukan. Pewawancara kebanyakan mencari untuk melihat bagaimana mereka akan menyerang masalah baru.
DJClayworth

16

Khusus untuk pengembang senior, saya pikir pertanyaan ini bisa sangat bagus. Mereka menunjukkan bahwa pengembang mampu bergerak dari deskripsi yang besar dan rumit menuju implementasi yang realistis. Bahkan dengan sistem yang sama sekali tidak dikenal, Anda harus dapat melakukan sejumlah kegiatan menarik untuk pewawancara:

  • Kumpulkan persyaratan untuk menjawab pertanyaan (mis. Ruang lingkup)
  • Pecahkan masalah menjadi beberapa bagian yang lebih mudah dikelola; mungkin mengidentifikasi antarmuka atau objek yang mungkin diperlukan, atau memecah logika menjadi front-end, back-end, DB, dll.
  • Tunjukkan keakraban dengan struktur dan konsep di balik sistem jenis itu, misalnya, aplikasi web dalam kasus Google Documents
  • Tunjukkan apa yang Anda cenderung fokuskan ketika disajikan dengan masalah desain (Desain objek? Tabel SQL? Pola desain?)
  • Tunjukkan kepada bos pratinjau seperti apa rasanya mengembangkan sistem baru bersama Anda, di mana bos masuk dengan sebuah spek dan berkata, "Apa yang diperlukan untuk membangun ini?"

Pertanyaan ini hanyalah versi tingkat tinggi dari "Jelaskan hierarki objek yang akan Anda gunakan untuk ini ..." "Jelaskan antarmuka yang akan Anda desain untuk ini ..." "Rancang satu set tabel DB relasional untuk data ini ...", dll. Yang akan diberikan kepada pengembang tingkat menengah ke bawah. Pada pengembang tingkat bawah, pewawancara mungkin mengevaluasi potensi jangka panjang seseorang untuk pertumbuhan di perusahaan, atau hanya melihat apa yang mereka lakukan ketika dihadapkan dengan masalah besar yang mungkin bisa sangat besar.


2
Jadi jawaban yang diharapkan untuk pertanyaan itu adalah beberapa diagram UML, paling tidak disederhanakan?
Shamim Hafiz

3
Saya pikir UML yang disederhanakan akan menjadi bagian umum dari jawabannya. Diagram server juga bisa muncul. Kuncinya adalah untuk menunjukkan bahwa Anda tidak terhalang oleh ukuran masalah dan bahwa Anda dapat bergerak dengan lancar dari konsep yang tidak jelas ke arsitektur nyata (dengan masalah yang konkret - bukan kabur - yang harus dipecahkan). Dan kemudian komunikasikan arsitektur itu. Pewawancara juga mungkin mendengarkan apakah Anda mencari praktik terbaik saat ini atau menuju solusi yang ketinggalan zaman.
Ethel Evans

11

Ini tentang melihat proses berpikir Anda dalam tindakan; mereka tidak tertarik pada solusi, tetapi bagaimana Anda akan mendekati menyelesaikan masalah, pertanyaan apa yang akan Anda tanyakan, masalah apa yang akan Anda identifikasi, dll.

Mengingat contoh Google Documents, masalah yang jelas muncul dalam pikiran adalah hal-hal seperti penyimpanan, keamanan, skalabilitas, ketersediaan, desain antarmuka klien, kompatibilitas browser, dll. Bagaimana Anda membagi tanggung jawab antara server dan klien? Bagaimana Anda menangani cadangan? Apa yang terjadi ketika server mati? Apa yang akan Anda lakukan dengan dokumen "terbengkalai" (hal-hal yang belum diakses atau dimodifikasi dalam jangka waktu yang lama)?

Sekali lagi, intinya bukan untuk menyelesaikan masalah-masalah itu, tetapi untuk mengidentifikasi mereka, membicarakannya, bertukar pikiran sedikit tentang bagaimana cara mengatasinya, dll.


9

Saya salah satu pihak yang bersalah yang sering mengajukan pertanyaan jenis ini dalam wawancara. (Sebagai catatan, saya juga mengajukan pertanyaan serupa tentang "proyek favorit mereka.") Alasan saya bertanya adalah bahwa itu adalah sesuatu yang sering kita lakukan di sekitar sini. Kami mendapatkan insinyur desain dari semua sisi antarmuka, seseorang dari rekayasa sistem, seseorang dari pengujian, dan seseorang yang memiliki pengetahuan tentang kasus penggunaan pelanggan untuk fitur tersebut. Kami berdiri di sekitar papan tulis dan berkata, "Oke, bagaimana kita akan membangun benda ini?" Seringkali Anda hanya tahu sedikit tentang fitur baru pada saat itu dan hanya ada karena keahlian Anda di bagian sistem, tetapi Anda tetap diharapkan berkontribusi secara produktif. Ini bukan hanya latihan akademis hipotetis.

Sejauh apa jawaban yang saya harapkan, ambil contoh, merancang sistem untuk mengunduh firmware baru dari server, melalui 20 kartu garis tertanam di kantor pusat untuk memutakhirkan 5.000 set top box di lapangan sekaligus. Asumsikan ada sedikit kapasitas cadangan pada tautan antara server dan kartu garis.

Jawaban salah:

Um, saya mungkin akan menggunakan ethernet atau sesuatu seperti itu.

Jawaban yang bagus:

Seberapa besar gambar yang kita bicarakan? [Sekitar 7 MB.] Ya, Anda ingin memastikan layanan tidak terpengaruh selama unduhan. Anda perlu flash atau RAM tambahan untuk menyimpan dua gambar sekaligus. Anda mungkin ingin men-cache gambar pada kartu garis Anda untuk menghindari mengunduh gambar yang sama berulang-ulang dari server. Karena tertanam, kartu lini Anda mungkin memiliki CPU sendiri yang terbatas, jadi Anda mungkin perlu membuat serial unduhan untuk memberikan kapasitas yang cukup untuk layanan. Anda ingin beberapa cara memverifikasi gambar itu baik dan kembali ke versi lama jika tidak berhasil. Anda perlu beberapa cara untuk mencoba lagi beberapa kali dan melaporkan kesalahan kepada manusia jika pemutakhiran gagal. Jika Anda memiliki merek set top box yang berbeda, Anda perlu semacam cara untuk mengidentifikasi gambar mana yang perlu Anda kirimkan.

Itu adalah transkripsi kata demi kata dari dua kandidat yang berbeda. Sebagian besar kandidat berada di antara keduanya, tetapi biasanya sampai di sana pada akhirnya dengan sedikit dorongan, yang tidak apa-apa. Kami tidak mencari Einstein berikutnya di sini, hanya sebuah indikasi bahwa Anda dapat benar-benar beralasan dengan cerdas tentang jenis masalah yang kami tangani setiap hari.


1
Di mana Anda bekerja dan apakah Anda membutuhkan karyawan baru? : D
Maggie

1
Sementara semua contoh untuk apa yang Anda sebut "jawaban yang baik" mungkin relevan. Pertanyaannya adalah untuk "Merancang sistem yang ....". Mempertimbangkan bahwa ini adalah situasi wawancara sehingga orang hanya berharap memiliki 5 hingga 10 menit paling banyak untuk menjawab, sebagian besar dari apa yang Anda identifikasi tampaknya tidak cocok untuk solusi wawancara. Di mana solusi aktual dalam "jawaban bagus" Anda? Setelah orang tersebut memiliki solusi "hari bahagia" maka mereka dapat mulai mempertimbangkan "bagaimana-jika" yang Anda maksudkan dalam "jawaban yang baik". Tetapi pada saat itu, saya akan berpikir waktu telah habis.
Dunk

5

Saya juga mengajukan pertanyaan semacam ini, dan saya setuju dengan sebagian besar jawaban lainnya. Mungkin akan membantu orang yang diwawancarai untuk memahami MENGAPA jenis pertanyaan ini penting? Misalkan kita memiliki keputusan bisnis yang penting untuk dibuat, dan untuk melakukannya, kita perlu membangun sistem baru. Jika seseorang berlari menghampiri Anda dan bertanya apa yang diperlukan untuk membangun sistem yang berfungsi X, dapatkah Anda memberi mereka jawaban mendalam yang memprediksi tantangan dan sumber daya utama yang diperlukan?

Seorang programmer junior tidak tahu harus mulai dari mana. Mereka tidak siap untuk mulai berbicara tanpa spesifikasi terperinci. Seorang programmer senior akan langsung melihat bahwa ada banyak sisi dari masalah ini, dan akan berusaha untuk mengasah tantangan. Anda tidak harus merancang setiap aspek, cukup mengidentifikasi tantangan arsitektur dan kemudian mencari tahu bagaimana mengatasinya.

Pertimbangkan masalah Google Documents:

Satu hal yang menarik adalah skala geser permintaan yang akan datang. Anda tidak bisa hanya mendapatkan satu server dan menggunakan kode Anda untuk itu - ini adalah usaha yang lebih besar. Orang yang diwawancarai yang berhasil mungkin membidik tentang hal ini dan akan menggambarkan jenis sumber daya yang akan dibutuhkan, dan beberapa tantangan teknis dalam mengimplementasikan pada skala itu, dengan aplikasi yang tidak hanya memiliki keadaan, ia berbagi keadaan di beberapa pengguna.

Hal lain yang menarik tentang Google Documents adalah banyak orang dapat mengedit secara bersamaan. Orang yang diwawancarai yang berhasil akan dapat membahas mekanisme untuk memastikan dokumen yang dihasilkan bukan sampah, dan kandidat yang benar-benar hebat akan menyadari bahwa berbagai metode sinkronisasi atau penggabungan suntingan akan berdampak besar pada kinerja dan UX. Bahkan mungkin membahas variasi: Editor dokumen bersama untuk menulis kode mungkin harus menggunakan metode penyelesaian konflik yang berbeda dari Google Doc pada umumnya, karena ada konsekuensi yang berbeda terhadap hal-hal yang terjadi dalam urutan berbeda atau memiliki struktur yang sedikit berbeda.

Tidak ada satu pun cara yang tepat untuk membuat aplikasi seperti Google Documents, Anda tidak perlu mengidentifikasi apa yang akan Anda lakukan untuk setiap trade-off, tetapi sangat bagus untuk menemukan area yang memiliki masalah menarik, dan menjelaskan dengan jelas apa yang dilakukan perdagangan tersebut. -off mungkin.

-t.


Saya terangkat karena Anda adalah satu-satunya jawaban yang mengarahkan jawaban mereka pada solusi desain "arsitektur". Karena itu adalah yang terbaik yang dapat Anda lakukan dalam konteks wawancara untuk masalah lingkup yang diberikan. Seorang yang diwawancarai yang memahami bahwa solusi arsitektur adalah semua yang dapat dicapai, menunjukkan bahwa mereka tahu apa yang mereka lakukan.
Dunk

2

Saya menduga apa yang ingin didengar oleh pewawancara adalah:

Google Doc adalah antarmuka web untuk pengolah kata. Dokumen pengguna diketik dan disimpan, dan dapat diambil kembali oleh pengguna di komputer yang sama atau berbeda.

Apa yang ingin Anda diskusikan lebih lanjut?

Kemudian, bola ada di pengadilan pewawancara. Jika dia ingin lebih detail, dia bisa bertanya. Yang dicari pewawancara adalah, dapatkah Anda melihat masalah atau produk, dan mengekstrak desainnya?


1
Jawabannya bagus, tetapi jangan berpikir Pewawancara akan puas dengannya. Membaca pada posting sejauh ini, sepertinya pertanyaan seperti itu tidak populer di kalangan yang diwawancarai.
Shamim Hafiz

-1 @Gilbert Le Blanc - Waktu "ramp up" yang ditentukan oleh hukum Brook dalam The Mythical Man Month menjadikan pertanyaan ini konyol. Jika kita tahu dibutuhkan sekitar 6 bulan untuk belajar menambahkan nilai pada proyek perangkat lunak, apa yang bisa diharapkan dari "ekstraksi desain" hanya dalam 6 jam? en.wikipedia.org/wiki/Brooks%27s_law
P.Brian.Mackey

1
@Shamim Hafiz: Berdasarkan pertanyaan dan komentar Anda, menurut saya pertanyaan ini tidak populer karena Anda dan orang lain kesulitan mempersempit ruang lingkup pertanyaan. Jawaban JB King lebih lengkap dari pada saya. Poin-poinnya adalah semua cara yang valid untuk mempersempit ruang lingkup pertanyaan, meskipun saya sebagian ke atas-bawah terlebih dahulu, kemudian klarifikasi persyaratan. Dalam bahasa Inggris yang lebih jelas, gambar analoginya dulu, kemudian sorot perbedaannya.
Gilbert Le Blanc

4
Jika saya mewawancarai saya tidak akan senang dengan jawaban itu. Jawabannya di sini hanya memberi tahu saya apa itu google docs, sesuatu yang sudah saya ketahui.
whatsisname

1
@whatisname - Saya pikir pewawancara ingin mengetahui jawaban atas pertanyaan (atau stadion baseball) dalam konteks wawancara.
Morgan Herlocker

2

Bagi saya, jika orang tersebut tidak memulai dengan mengidentifikasi kasus penggunaan utama / cerita maka itu akan cukup untuk mengetahui mereka tidak siap untuk suatu posisi yang membutuhkan keterampilan khusus ini.

Setelah itu, mereka harus dapat menemukan solusi arsitektur berdasarkan kasus-kasus utama / cerita. Mudah-mudahan mereka menggunakan beberapa proses sistematis untuk mengidentifikasi modul selain menarik mereka dari .... Saya tidak akan berharap lebih banyak dari situasi wawancara untuk solusinya.

Namun, saya mungkin memilih salah satu modul arsitektur dan meminta desain yang lebih rinci, hanya untuk melihat apakah mereka memiliki beberapa keterampilan desain. Akan lebih baik melihat bahwa mereka mempertimbangkan kasus kegagalan / masalah kinerja. Tapi saya curiga pada titik ini, kita akan menabrak tembok waktu. Jadi, saya benar-benar tidak bisa menghukum mereka karena tidak mempertimbangkan masalah ini karena hanya ada begitu banyak waktu dan saya pikir masuk akal bagi mereka untuk menganggap bahwa mempertimbangkan setiap skenario yang mungkin tidak diharapkan dari situasi wawancara yang terbatas waktu.


1

Saya memiliki wawancara baru-baru ini di mana saya diminta untuk merancang sistem kontrol lift. Pada dasarnya mereka ingin melihat pendekatan Anda terhadap tugas tersebut. Jika Anda ditanya pertanyaan ini, mereka mungkin memiliki pekerjaan tingkat tinggi dalam pikiran Anda. Selamat.


1

Kuncinya adalah bagaimana Anda menyelesaikan masalah versus manfaat dari solusi yang Anda berikan, dan jika Anda mampu menangani masalah gambaran besar.

Saya pikir satu hal penting yang harus dilakukan adalah mengajukan pertanyaan tentang persyaratan. Jangan hanya membuat asumsi yang akan memungkinkan solusi hewan peliharaan Anda bekerja. Misalnya, Anda mungkin mengetahui beberapa metode yang sangat bagus untuk mencetak dokumen yang Anda mungkin tergoda untuk langsung menjelaskan. Tetapi Google Documents tidak mencetak secara langsung; menghasilkan PDF yang kemudian dicetak oleh klien. Jadi, jika Anda mulai dengan itu, Anda akan menghabiskan setengah waktu Anda menyelesaikan masalah yang bukan bagian dari masalah, dan telah menunjukkan bahwa Anda lebih tertarik menggunakan teknologi panas Anda daripada menyelesaikan masalah pelanggan.


0

Untuk menangani pertanyaan wawancara jenis ini, Anda harus memiliki minat umum dalam memahami "bagaimana hal-hal bekerja", tidak hanya dalam proyek-proyek yang Anda minati tetapi juga proyek-proyek yang Anda rasa terlalu jauh dari pengalaman Anda.

Ini berarti membaca blog, artikel, http://www.infoq.com , Berita Peretas, dll. Bahkan perangkat kerasnya menggertak dari Coding Horror.

Terlepas dari kenyataan bahwa Anda akan melupakan sebagian besar dari apa yang telah Anda baca (karena informasi tersebut tidak terhubung dengan pekerjaan Anda secara pribadi), mungkin ada beberapa informasi tersembunyi yang merupakan "benih imajinasi", dan sebagian kecil dari benih tersebut akan berkecambah ketika Anda menemukan masalah serupa di masa depan yang sangat jauh.

Jadi, pewawancara mungkin tertarik dengan kebiasaan membaca Anda (sebagai bagian dari hobi Anda) dan melihat apakah Anda memiliki kebiasaan rutin untuk mengumpulkan benih ide dari tempat-tempat acak.


Eh, saya tidak tahu tentang Anda, tetapi saya melihat lebih baik pada pengembang yang merumuskan desain berdasarkan fakta dan pengalaman daripada hal-hal yang mereka baca di blog sekali.
Aaronaught

@Aaronaught: tentu saja pengalaman nyata dari proyek serupa jauh lebih berharga daripada ide yang didengar. Tetapi ketika Anda ditugaskan dengan proyek di daerah di mana Anda tidak memiliki pengalaman, apakah Anda menyerah begitu saja? (Anggap saja Anda memberi tahu majikan bahwa Anda tidak memiliki pengalaman yang relevan dan majikan setuju dengan itu) Jika Anda memutuskan untuk mengambilnya, lalu bagaimana Anda memulainya? Anda mulai dengan pelajaran dari orang lain, perusahaan lain dan sebagainya. Anda tidak dapat memulai dari mana pun. Mungkin Anda benar memilih saya karena OP tampaknya mewawancarai untuk posisi senior, tetapi
rwong

(lanjutan) tolong jangan meremehkan pentingnya pelajaran dari sumber lain.
rwong

Cukup adil, mungkin downvote itu tidak layak (walaupun saya tidak bisa menghapusnya pada tahap ini). Namun, saya benar-benar tidak berpikir bahwa pewawancara akan mengajukan pertanyaan seperti ini untuk mempelajari apa yang Anda baca; jika ya, mereka hanya akan bertanya apa yang Anda baca. Yang penting adalah untuk mengajukan pertanyaan yang tepat sehingga Anda belajar bagaimana seharusnya bekerja, tidak pergi setengah terkungkung berdasarkan bit informasi yang tersebar yang mungkin atau mungkin tidak terkait.
Aaronaught

0

Poin di balik mengajukan pertanyaan semacam ini adalah untuk mendapatkan wawasan tentang pikiran Anda. Pertanyaan umum yang saya gunakan adalah meminta pemrogram untuk merancang sistem yang dapat mensimulasikan PacMan.

Dan ya, saya mencari kasus penggunaan terlebih dahulu, itu menunjukkan kepada saya bahwa orang tersebut sedang berpikir. Kemudian, untuk multithreading, pertimbangan struktur data terlebih dahulu (yang dapat digunakan untuk masalah, kemudian yang lebih sesuai atau spesifik dengan mengapa keputusan).

Ini dianggap sebagai keharusan untuk posisi pengembangan senior. Baik konyol dan tidak ada gunanya bagi orang untuk duduk dan menjawab pertanyaan tentang implementasi semacam pada tingkat pengalaman pengembang ini. Desain sistem adalah apa yang saya harapkan pada level ini.

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.