Baru-baru ini, karena pekerjaan saya, saya kebetulan memilih pekerja magang di perusahaan kami. Setiap orang yang ingat bagaimana menjadi magang / junior harus ingat betapa sulitnya terjebak di tempat yang lebih atau kurang normal tanpa pengalaman, di mana mereka akan menghabiskan sumber daya untuk pelatihan Anda. Karena fakta bahwa arus pengembang pemula sangat besar, pemberi kerja memiliki kesempatan untuk memilih dari aliran ini jika bukan yang terbaik, maka paling tidak orang-orang yang cerdas dan menjanjikan yang layak menghabiskan waktu untuk pelatihan untuk kemudian mempekerjakan mereka.
Setiap perusahaan memiliki metodologi sendiri untuk menemukan kandidat tersebut. Hari ini, kami mematuhi yang berikut: kami memberikan tugas uji kecil (sekitar satu jam kerja, untuk pengembang yang berpengalaman), yang pengetahuan inti-java sudah cukup dan meminta untuk meletakkannya di github. Kami tidak membatasi waktu eksekusi. Kemudian, memenuhi tugas secara kualitatif, pelamar diundang untuk wawancara.
Tugas biasanya berisi implementasi metode CRUD ke file melalui
menu konsol dengan satu atau dua entitas plus validasi beberapa bidang. Sebagai contoh, saya akan memberikan situasi klasik dengan pengguna yang perlu menerapkan email dan validasi telepon sesuai dengan templat yang diberikan dan untuk ini dapat masuk dari 1 hingga 3 ponsel. Ada banyak tanggapan, dan ada sangat sedikit tempat - sehingga, pemilihannya cukup sulit.
Mulai memeriksa semua tugas secara berurutan, ternyata butuh sekitar 30 menit untuk menguji kinerja dengan meluncurkan dan umpan balik dari setiap tugas, saya harus merevisi metodologi verifikasi dan mendapatkan kriteria untuk dengan cepat menyaring kode berkualitas tinggi yang tidak mencukupi. Sebagai contoh, membuka solusi pada github, saya melihat bahwa semua kode terkonsentrasi di beberapa kelas dan bahkan ditumpuk dalam satu paket - kegagalan cepat (bagaimana dengan prinsip-prinsip OOP?).
Banyak yang mungkin menganggap pendekatan ini tidak adil, untuk mengatakan bahwa masalahnya selesai, kodenya berhasil, tetapi kehidupan intern dan junior itu keras dan tanpa ampun.
Dalam hal ini, saya menawarkan daftar rekomendasi saya untuk menyelesaikan tugas tes
- Keputusan Anda harus bekerja sesuai dengan Kerangka Acuan
Ikuti dengan cermat persyaratan yang ditetapkan dalam kondisi untuk menyelesaikan masalah. Jangan memikirkan bidang Anda dalam entitas, jangan mengubah kondisi validasi, dll. dan sebagainya. Ini menunjukkan betapa perhatian Anda pada detail, yang sangat penting bagi pengembang. - Hati-hati memeriksa tugas yang selesai
Selesai tugas - periksa kinerja. Pertama, fungsi utama yang dijelaskan dalam Kerangka Acuan, kemudian tambahan. Cobalah untuk "memecah" aplikasi Anda: periksa atau masukkan aplikasi secara memadai untuk tugas tersebut, jika Anda memasukkan data yang tidak valid, datanya semirip mungkin. Ingatlah untuk memperbaiki semua yang Anda temukan. - Pengkodean
Semua file harus dalam pengkodean yang sama, menurut pendapat saya di UTF-8. Konfigurasikan IDE Anda untuk ini. Ingat, jika Anda memiliki Windows, maka resensi mungkin memiliki Linux, dan squat tambahan dengan pengkodean adalah buang-buang waktu untuk resensi. - Jangan komit dalam satu komit
Anda harus berkomitmen ketika Anda menyelesaikan masalah Anda, tambahkan deskripsi yang jelas ke komitmen. Jika Anda tahu bahasa Inggris, itu lebih baik dalam bahasa Inggris. Ini secara tidak langsung menunjukkan bahwa Anda tidak hanya menggabungkan solusi orang lain dari git, tetapi juga menulis kode sendiri. - Cobalah untuk tidak menggabungkan keputusan orang lain
Mengingat Anda mengklaim maksimum untuk bulan Juni, paling sering Anda masih belum memiliki cukup pengalaman untuk menggunakan kode orang lain. Kondisi tugas mungkin sedikit berbeda, dan ketika Anda cukup menyalin solusi orang lain, itu mungkin sudah sedikit tidak konsisten dengan tugas saat ini. Dan tugas harus diselesaikan tepat dengan tugas (lihat P1). - Tambahkan file readme
Tambahkan file readme.md ke root proyek. Jelaskan secara singkat aplikasi Anda, berikan penjelasan tambahan untuk peluncuran, jika perlu. Jika Anda sudah menyelesaikan tugas lain, tambahkan readme di sana juga. Misalnya, jika saya tertarik pada seorang kandidat, saya dapat melihat kode lainnya. Dan jika Anda tidak pergi ke sini, Anda juga dapat melampirkan kode ini ke resume Anda. - Buat menu yang nyaman
Aplikasi harus ramah pengguna. Ingatlah bahwa waktu untuk pengecekan seringkali terbatas, jadi preload aplikasi dengan data, tambahkan metode untuk menunjukkan semua entitas (yang ada dalam kondisi). Navigasi menu harus nyaman, misalnya menggunakan angka. Dan kadang-kadang mereka menerapkannya sedemikian rupa sehingga untuk menghapus suatu entitas Anda perlu memasukkan "Hapus" di konsol. Namun, seseorang tidak bisa berlebihan dan melampaui ruang lingkup TK. - Lakukan yang terbaik sesuai keahlian Anda.
Karena Anda telah memutuskan untuk melaksanakan tugas tes, dekati solusinya dengan pengembalian maksimum. Sekalipun tugas itu tampak sepele dan sederhana, Anda tidak perlu mendekati solusinya secara formal dan menulis kode pada lutut Anda. Dan jika Anda tidak pergi ke perusahaan ini, maka Anda akan memiliki solusi lengkap pada github, yang merupakan praktik. - Jangan lupakan prinsip-prinsip OOP
Tampaknya bagi Anda bahwa tugas kecil, jangan lupa - tugas adalah ujian, dan java terutama merupakan bahasa berorientasi objek. Dan mereka akan melihat tidak hanya pada operabilitas aplikasi, tetapi juga pada kode. Kualitas kode adalah bagian yang sangat penting dari solusi . Jangan menulis kode spageti. Masukkan semuanya ke dalam kelas, paket. Buat antarmuka jika perlu, lakukan transfer ke ENUM , jika perlu. - Coba gunakan pola desain
Aplikasi yang sukses dari setidaknya satu pola desain akan menunjukkan bahwa Anda memiliki konsep tentang pola desain (atau Anda tidak). Tepat sebelum menerapkan pola ini atau itu - cari tahu apa idenya, bagaimana cara kerjanya dan mengapa ia diciptakan. Jika saya melihat pola dalam kode, maka pada saat wawancara saya dapat mengajukan pertanyaan tentang pola yang diterapkan. - Gunakan sumber daya
Semua pesan yang ditampilkan kepada pengguna sebaiknya diambil ke sumber daya dan diambil dari sana. Ini akan menunjukkan kepada pengulas bahwa Anda tahu cara bekerja dengan sumber daya dan memahami untuk apa mereka digunakan. Pesan paling baik ditampilkan dalam bahasa Inggris. - Ingatlah untuk mendefinisikan kembali di mana sama dengan & kode hash
- Gunakan fitur java8 + seperti ekspresi lambda, stream
Jangan lupa bahwa koleksi lebih sering lebih nyaman daripada array. Jika pilihan telah jatuh ke dalam koleksi, kemudian gunakan koleksi yang benar. Anda harus siap pada saat wawancara untuk membenarkan pilihan Anda yang mendukung koleksi atau array tertentu. - Tes
Jika Anda bisa, tulis tes, tetapi ini sudah lima dengan beberapa plus. Seringkali, dipahami bahwa kode yang baik biasanya tercakup dalam tes. Meskipun untuk tugas yang diberikan dalam contoh, tidak adanya tes tidak akan menjadi minus, karena ini adalah aplikasi konsol sederhana untuk mengetahui inti java.
Ringkasan
Sebagian besar pelamar mengirimkan solusi untuk masalah tanpa kesalahan, dan kode yang solid - unit yang melewati seleksi alam dan jatuh ke babak berikutnya. Semua pemain menerima umpan balik. Mereka yang menulis kode solid yang datang untuk meluncurkan - umpan balik pribadi, mereka yang mengirim spageti yang ditulis berlutut - lebih digeneralisasi.
PS: Saya harap saran saya akan membantu Anda, pelamar yang terhormat untuk melakukan tugas tes Anda dengan lebih baik, dan lebih jarang menangis oleh penguji. Semoga berhasil dalam pencarian Anda dan tempat awal yang bagus!