Crack the Design System interview: tips dari seorang jurutera perisian Twitter

Baru-baru ini saya menulis tentang bagaimana saya mendaratkan tawaran dari pelbagai syarikat teknologi peringkat tinggi. Semasa proses penyediaan temuduga, saya membaca banyak bahan dan menyediakan satu set nota tentang cara menangani masalah reka bentuk sistem. Dalam artikel ini, saya ingin berkongsi petua dengan anda semua.

Jika anda seorang lulusan baru tanpa pengalaman dalam sistem diedarkan berskala besar, atau bahkan seorang jurutera berpengalaman dengan pengalaman bertahun-tahun di bawah tali pinggang anda, artikel ini akan berguna untuk anda.

Kemas kini (3/24/2019): Jika anda ingin menyertai sekumpulan pelajar untuk mengetahui lebih lanjut mengenai reka bentuk sistem, saya akan menganjurkan kelas kecil bersama! Anda boleh pergi ke pautan ini untuk mengetahui lebih lanjut, atau lawati laman web saya: zhiachong.com untuk maklumat lanjut.

Bagaimana Reka Bentuk Sistem: Tips dari jurutera perisian Twitter

Artikel ini dibahagikan kepada empat bahagian berikut:

  • Tanya soalan penjelasan
  • Gunakan latar belakang anda
  • Mengatasi masalah secara sistematik
  • Simpan nota anda sendiri

Tanya soalan penjelasan

Matlamat utamanya bagi temuduga reka bentuk sistem adalah untuk memberi calon peluang untuk menunjukkan pengetahuan mereka.

Tidak ada jawapan yang betul atau salah. Persoalan rekabentuk sistem yang baik biasanya berbunyi sangat samar-samar, dan sebabnya itu sepatutnya memberi anda peluang untuk menunjukkan perkara berikut:

  • Bagaimana anda akan memikirkan ruang masalah
  • Bagaimana anda berfikir tentang kesesakan
  • Apa yang anda boleh lakukan untuk menghapuskan kesesakan ini.
Bagaimana untuk merancang kotak hitam ini

Bayangkan anda diminta membuat reka bentuk kotak hitam. Bagaimana anda menangani masalah ini? Tidak ada arahan yang jelas tentang apa yang perlu anda bina di sini, selain dari kotak yang dapat memegang beberapa item di dalamnya.

Salah satu strategi yang paling berguna yang saya gunakan secara peribadi adalah untuk bertanya soalan penjelasan. Apakah soalan penjelasan yang "baik", anda bertanya?

Soalan penjelasan yang baik membantu anda mencapai satu, atau lebih, beberapa perkara:

  1. Membantu anda menyempitkan ruang lingkup apa yang anda sepatutnya lakukan
  2. Membantu menjelaskan apa yang diharapkan oleh sistem pengguna
  3. Memberikan anda arah ke mana hendak meneruskan
  4. Memaklumkan anda mengenai masalah kesesakan / masalah yang mungkin berlaku

Dalam contoh kotak hitam, anda mungkin bertanya, "dengan baik, apakah kotak yang dipegang? Berapa banyak barang yang dipegangnya? Dan siapa pengguna yang dimaksudkan? "

Untuk itu saya boleh katakan, mari kita buat kotak kuning dengan senyuman di atasnya yang harus memegang paling banyak 1 bola tenis. Walau bagaimanapun, ini bukan bola tenis biasa. Ia akan sekurang-kurangnya 0.5m jejari dan berat kira-kira 1kg. Ia bertujuan untuk dipeluk, tidak dipegang, jadi saya tidak mahu apa-apa mengendalikannya.

Di sana anda pergi, ini adalah kotak.

Kotak ideal saya dengan wajah smiley

Sentiasa bertanya soalan penjelasan. Anda tidak diadili sama ada anda bertanya soalan khusus semasa temu duga, tetapi anda dinilai tentang bagaimana anda memikirkan ruang masalah.

Contohnya, jika saya meminta anda merancang Twitter sekarang, bagaimana anda melakukannya? Ambil masa beberapa minit untuk memikirkannya, dan mungkin juga lakarkannya di sekeping kertas. Pergi dengan mendalam dan meluas seperti yang anda boleh, dan kemudian kembali ke artikel ini. Lebih baik lagi, anda boleh meninggalkan nota anda dalam komen di bawah dan kami boleh berbincang lebih lanjut.

Jika anda belum menyedarinya, keputusan akhir dari latihan di atas akan menghasilkan keputusan yang berbeza. Untuk latar belakang khusus saya, saya mungkin menyelidiki dengan sangat mendalam dalam reka bentuk API dan infrastruktur belakang. Saya mungkin akan meneroka masalah khusus iPhone juga, kerana pengalaman saya. Saya akan bercakap tentang bagaimana pelanggan berinteraksi dengan titik hujung pertengahan, cara kerja pembalakan, bagaimana saya membuat reka bentuk backend untuk memastikan waktu hayat, dan sebagainya.

Ini adalah perbincangan yang agak menarik yang anda boleh buat dengan rakan sekerja, dan itu adalah isyarat yang sangat kuat yang dicari oleh pewawancara.

Gunakan latar belakang anda untuk kelebihan anda

Sering kali saya melihat para jurutera cuba mencari tahu apa yang dituntut pewawancara, dan kemudian memenuhi respons mereka untuk memenuhi jangkaan.

Saya sebenarnya sangat tidak menggalakkan sesiapa sahaja untuk melakukan ini kerana beberapa sebab:

  1. Setiap orang mempunyai latar belakang yang unik. Dalam temu bual reka bentuk sistem, ini merupakan peluang bagi anda untuk menunjukkan kekuatan anda. Jangan buang-buang peluang untuk mencari tahu apa yang orang lain mungkin mengharapkan.
  2. Pewawancara mungkin telah mengangguk untuk jawapan anda, tetapi mereka mungkin tahu bahawa anda hanya mengamuk jalan anda dan tidak benar-benar memikirkan masalahnya.

Pengalaman dan latar belakang anda boleh berbeza-beza dari calon seterusnya. Anda membawa satu set nilai dan kepakaran ke meja yang tidak ada orang lain. Itulah yang membuat anda berharga dan tidak boleh digantikan. Terlepas dari apa bidang anda berada, orang peduli tentang apa yang boleh anda bawa ke meja.

Mengatasi masalah secara sistematik

Sekarang, dengan kepakaran saya dalam fikiran, ada beberapa perkara yang saya fikirkan ketika saya menangani sistem baru. Saya amat mengesyorkan agar anda merangka satu set kriteria atau langkah untuk diri anda juga.

Beberapa perkara dalam fikiran saya ketika saya bekerja pada sistem baru adalah:

  • Apakah matlamat sistem ini?
  • Siapa pengguna sistem?
  • Apakah skala yang kami bekerjasama?
  • Adakah ini sistem baru / lama? Bagaimanakah kita menangani versi?

Dalam kalangan yang lain…

Lihat, kriteria saya akan berbeza daripada set kriteria jurutera depan. Saya menggunakan kriteria ini untuk merangka gambar di kepala saya, dan ini akan membimbing proses membuat keputusan saya.

Berbekalkan jawapan kepada soalan-soalan itu, saya boleh mula mengatasi masalah di tangan dan kemudian secara sistematik memecahnya ke dalam komponen individu.

Senaman yang baik yang saya suka lakukan adalah bagaimana merancang sistem pesanan kopi. Saya fikir ini semasa saya duduk di Starbucks suatu hari, dan menyedari bahawa ia akan menjadi baik jika saya boleh memesan smoothie di telefon saya dan mengambilnya di Starbucks tempatan saya.

Fikiran saya bermula dalam pelbagai arah:

  • Apa yang dilakukan oleh mesin pesanan kopi ini?
  • Jika saya membina satu, bolehkah saya menjualnya kepada Starbucks, atau adakah label putih saya dan menjualnya sebagai perkhidmatan?
  • Berapa banyak pengguna yang saya perlukan untuk menyokong jika saya menjualnya kepada Starbucks?
  • Atau, jika saya label putih, bolehkah saya menjual antara muka untuk perkhidmatan tempahan kopi saya, dan kemudian membantu pelanggan membina backend supaya mereka boleh menyimpan pesanan di mesin tempatan mereka?
Bagaimana untuk mendekati masalah ini

Sebaik sahaja saya mendapat jawapan kepada soalan-soalan ini, saya akhirnya boleh membuat gambaran penuh mengenai perkhidmatan pesanan kopi saya. Inilah versi perkhidmatan khidmat pesanan kopi saya seperti:

Perkhidmatan pesanan kopi saya adalah perisian sebagai perkhidmatan (SAAS). Ia menawarkan antara muka untuk pelbagai rakan untuk disambungkan.

  • Ia mempunyai API, yang dipanggil addCoffeeForMerchant, yang memasukkan nama kopi, harga kopi, dan bahan-bahan kopi.
  • Ia mempunyai API GET, yang dipanggil getCoffeesForMerchant, yang mengembalikan senarai kopi untuk ID saudagar yang diberikan.
  • ID saudagar adalah pengenal unik (UUID) yang dijana menggunakan beberapa mekanisme hashing, yang dapat dijelaskan lebih lanjut dengan pelanggan.
  • Perisian ini dioptimumkan untuk operasi baca-baca, kerana kebanyakan pelanggan saya membuat menu sekali dan membacanya beberapa kali sepanjang hari.
  • Ia mempunyai mekanisme caching yang menggunakan strategi pengusiran Least-Recently-Used (LRU), kerana jika item menu tidak diperintahkan dalam sekejap, pelanggan saya tidak peduli jika ia sedikit perlahan dalam muncul pada menu.
  • Sekiranya salah satu daripada data menyimpan diri, perkhidmatan pesanan kopi saya akan meniru data dalam pelbagai kelompok di seluruh AS dan pantai timur Amerika Syarikat kerana saya hanya menargetkan pasaran AS sekarang.

Sebagai alternatif, sebarang perkhidmatan pesanan kopi lain yang anda boleh fikirkan akan sangat mungkin juga. Ia hanya satu perkara yang anda mengoptimumkan. Saya fikir ini adalah masalah yang sangat menarik, dan ia adalah latihan mental yang hebat untuk menjaga fikiran anda.

Simpan nota anda sendiri

Sebagai jurutera perisian, ia merupakan proses pembelajaran yang tidak pernah berakhir. Saya sangat mengesyorkan bahawa anda menggunakan Evernote atau Moleskin untuk menyimpan nota. Saya sendiri membawa buku nota kecil untuk idea-idea yang cepat yang perlu saya tuliskan, dan saya menyimpan pelbagai perkara lain di Evernote apabila saya boleh.

Saya mempunyai Notebook bernama "Pemrograman" di Evernote saya. Setiap kali saya menghadapi sesuatu yang baru, atau sesuatu yang menarik, saya menuliskannya dalam buku nota saya untuk rujukan selanjutnya.

Saya meneruskan dan menetapkan label kepada nota-nota baru secara bulanan atau suku tahunan untuk memastikan nota-nota tersebut dianjurkan. Sebagai contoh, saya mempunyai label "Rekaan" untuk apa-apa yang berkaitan dengan reka bentuk sistem. Ini boleh jadi seperti pautan ke video YouTube yang saya dapati menarik, atau hujah yang menarik yang dilakukan rakan sekerja saya yang saya tidak fikirkan.

Ini adalah contoh dari mana satu nota saya kelihatan seperti:

Maaf untuk tatabahasa dan kesilapan yang salah: h

Salah satu perkara yang saya pelajari baru-baru ini daripada rakan sekerja adalah bahawa NoSQL hebat untuk prototaip, kerana tidak perlu menjalani perbincangan skema dengan pasukan lain. Sekiranya saya ingin mengubah skema, saya boleh melakukannya dengan cepat dengan pangkalan data NoSQL. Itulah pembelajaran utama dari kerja yang saya masukkan ke dalam buku "Pemrograman" saya.

Saya memecahkan nota saya ke dalam:

  1. Reka bentuk sistem
  2. Temubual (pengalaman + ulasan wawancara yang saya ada pada masa lalu, dikelompokkan oleh nama syarikat)
  3. Ralat secara rawak, CS baik untuk tahu, seperti skrip bash berguna atau helah baris perintah
  4. Bacaan / video YouTube

Semua nota di atas diletakkan di bawah "Pemrograman". Lama kelamaan, saya mendapati bahawa saya mempunyai koleksi perkara-perkara yang saya baca atau diterokai sebelum ini.

Sebagai sesiapa yang mengenal saya pada tahap peribadi, saya bukan orang yang teratur. Oleh itu, saya hanya mengumpul 10 hingga 15% perkara, jadi masih banyak lagi yang perlu dilakukan di sana.

Pengetahuan dan amalan berjalan seiring dengan semakin baik pada reka bentuk sistem. Jika anda merasakan bahawa pekerjaan anda sekarang tidak mampu memberi anda reka bentuk sistem, maka anda harus mencari salah satu yang melakukannya, atau cuba merancang satu bahagian kecil dari arsitektur yang sedia ada seperti itu lebih cepat, lebih murah, lebih teguh, atau mudah diubah suai pada masa akan datang.

Sumber saya cadangkan

Pengenalan kepada: Reka Bentuk Seni Bina dan Sistem - Tutorial Youtube yang hebat dari bekas jurutera Facebook tentang cara mendekati masalah reka bentuk sistem.

Merancang aplikasi intensif data - Satu lagi sumber yang baik untuk belajar bagaimana membuat reka bentuk untuk skala. Ia membincangkan pelbagai perkara yang diperlukan oleh jurutera perisian biasa - bagaimana pangkalan data (mySQL dan noSQL) berfungsi, apabila menggunakan setiap, kebaikan dan keburukan pelbagai teknik untuk mengendalikan skala dan lain-lain. Saya sangat mengesyorkannya

Temubual Mock - Persekitaran simulasi yang meniru temu bual sebenar sangat membantu dalam membuat persediaan untuk temu bual. Jika anda dapat mencari rakan untuk melakukannya untuk anda, maka saya sangat mengesyorkannya. Saya juga mengamalkan temubual, jadi jika anda berminat, sila hubungi saya di zhiachong.com!

Apa yang sepatutnya diketahui setiap jurutera perisian mengenai abstraksi penyatuan data masa nyata - Perbincangan yang sangat panjang dan teknikal mengenai log, trade-offs. Saya belum selesai, tetapi ia sangat disyorkan daripada rakan kerja.

Evernote - Apl pemelihalan nota yang paling baik yang saya gunakan. Terdapat banyak tutorial mengenai cara terbaik menggunakan Evernote. Saya belum melaluinya, semata-mata kerana saya menggunakannya sebagai buku nota. Saya log semua yang saya pelajari di sana, dan kemudian kadang-kadang pergi dan menyusun semula mereka.

Notebook Moleskin - Saya sangat menikmati ini. Kualitinya sangat tinggi. Harga sedikit lebih tinggi, tetapi sejak saya menggunakannya setiap hari, saya menganggapnya sebagai pelaburan yang baik. Memegang buku nota indah di tangan saya setiap hari menjadikan saya lebih teruja untuk menulis lebih banyak nota.

Pilot G2 (Black) - Mudah pena terbaik yang pernah saya gunakan, dan satu-satunya pen yang saya akan gunakan. Saya membelinya secara massal dari Amazon dan menyimpannya di mana sahaja saya pergi. Saya mempunyai satu di ransel saya, satu di pejabat, dan satu di pejabat rumah saya supaya saya sentiasa mempunyai pen. Ia menulis hebat, tinta mengalir dengan lancar, dan saya hanya suka merasakan menulis dengannya. Bersama-sama dengan Moleskin, kadangkala saya hanya mahu mengambil G2 untuk memasukkan perkara rawak di sana kerana kedua-duanya sangat sempurna bersama-sama.

Mengambil Temuduga Rekabentuk Sistem - Ini datang sebagai cadangan daripada rakan-rakan. Ini adalah kursus dalam talian yang mengajar bagaimana untuk merangka sistem teragih secara terperinci. Walau bagaimanapun, kursus $ 79 itu. Terdapat satu harga pasukan. Sekiranya ada minat, saya akan periksa dengan mereka untuk mengetahui sama ada kemungkinan untuk membentuk kumpulan untuk diskaun kumpulan.

Ikut saya di Twitter, Facebook, dan LinkedIn. Mendaftar untuk senarai mel saya di mana saya sering menghantar petua, teknik dan pelajaran industri.

Jika anda menikmati artikel ini, komen di bawah: apakah petua anda untuk membina sebuah sistem yang boleh dipercayai dan boleh dipercayai?