Bingkai dari film "Harry Potter and the Prisoner of Azkaban"Masalah dunia ini adalah bahwa orang-orang berpendidikan penuh dengan keraguan, dan para idiot penuh dengan kepercayaan diri
Charles Bukowski
Baru-baru ini, saya mengadakan pelajaran pemrograman satu-ke-satu. Tidak seperti kelas biasa, topiknya bukan konstruksi bahasa dan bukan masalah dalam memecahkan masalah. Siswa berbagi keprihatinannya tentang pekerjaan di masa depan. Mahasiswa itu sendiri cukup pintar. Salah satu dari mereka yang datang ke kursus melewati seluruh program lebih cepat dari siapa pun dan dengan solusi asli, tetapi selalu dengan tulus meremehkan dirinya sendiri. Menurut pendapat saya, keraguan semacam itu hanya muncul dari kurangnya informasi. Saya mencoba mengisi celah ini secara mendadak selama pelajaran.
Pertanyaannya kira-kira seperti ini:
- Setiap tahun, banyak siswa lulus dari universitas dan mereka semua pergi mencari kerja. Ini banyak orang. Mereka mungkin akan mengambil yang terbaik, tetapi saya tidak akan mendapatkan tempat.
- Bagaimana jika saya gagal dan langsung dipecat?
- Bagaimana jika dalam proses kerja mereka menyadari bahwa saya bodoh dan diusir?
Siswa ini bukan orang pertama yang saya jawab pertanyaan serupa. Banyak orang memilikinya, dan biasanya harus bicara tanpa persiapan. Kali ini saya memutuskan untuk menulis monolog saya di buku catatan. Saya pikir itu akan menghasilkan beberapa paragraf, tetapi saya mengetik seluruh artikel.
Artikel ini menjelaskan pandangan dari sudut pandang saya dan berdasarkan pengalaman saya. Namun, dunia kita sangat beragam dan hal-hal menakjubkan terjadi di dalamnya. Jika Anda tidak setuju dengan sesuatu atau pengalaman Anda entah bagaimana berbeda, silakan tulis komentar.
Artikel ini ditulis dari pengembang ke pengembang. Namun, jika Anda berencana untuk melakukan pengujian, administrasi, atau apa pun di TI, maka beberapa tips akan berguna bagi Anda juga.
Mereka tidak akan mempekerjakan sama sekali
Ketika Anda membayangkan bahwa ratusan siswa lulus dari banyak universitas setiap tahun, itu menjadi tidak nyaman. Bagaimana cara bersaing dengan orang banyak?
Sayangnya, tidak semua lulusan memiliki pelatihan teknis yang memadai. Cobalah tanyakan kepada beberapa mahasiswa, Anda tahu: bagaimana orang-orang dalam kelompoknya dapat diterima di ujian dalam disiplin ilmu seperti "database" atau "dasar-dasar algoritmaisasi dan pemrograman"? Dalam kelompok yang terdiri dari 30 orang, ada 3-5 orang "maju" yang benar-benar melakukan semuanya sendiri. Sisanya hanya menulis dari mereka, bison jawaban atas pertanyaan dan lulus.
Saat itulah saya belajar sendiri. Namun, pengalaman saya bisa tidak representatif. Karena itu, saya mengajukan pertanyaan ini kepada beberapa siswa yang berbeda. Jawabannya hampir sama. Responden berasal dari berbagai universitas dan perguruan tinggi. Saya akan meninggalkan diskusi tentang alasan di luar ruang lingkup artikel ini. Saya tidak cukup untuk studi penuh, jadi saya akan menarik kesimpulan dari fakta yang tersedia.
Di antara ratusan lulusan, hanya beberapa lusin yang menarik bagi pengusaha
Beberapa lulusan dapat membuat kompetisi nyata untuk siswa yang cakap dengan persiapan yang baik. Namun, bahkan jika Anda belajar dengan itikad baik, maka setelah wawancara pertama Anda kemungkinan besar tidak akan dipekerjakan. Setelah yang kedua, mungkin juga. Semuanya bisa berjalan dengan baik, tetapi lebih baik tidak mencari penyerangan, tetapi untuk mengepung. Upaya gagal untuk menyelesaikan masalah hanyalah alasan untuk memperbaiki bug dan mencoba lagi. Saya tidak akan berbicara tentang persiapan untuk wawancara. Sudah banyak yang ditulis tentang topik ini di Internet. Saya hanya bisa mengatakan bahwa ada nuansa lewat wawancara, yang sepertinya tidak ada waktu yang dialokasikan untuk menjelaskan program pelatihan Anda. Cari informasi ini sendiri, itu dapat mengurangi jumlah upaya.
Kegilaan adalah pengulangan tepat dari tindakan yang sama. Berulang kali, berharap ada perubahan
Albert Einstein
Untuk memastikan bahwa wawancara tidak berubah menjadi kegilaan, setelah setiap upaya baru, Anda harus menjadi lebih baik. Ingat atau tulis pertanyaan yang Anda tanyakan selama wawancara. Setelah kembali ke rumah, telusuri daftar ini dan uji diri Anda menggunakan Internet. Jadi Anda akan mengerti di mana Anda salah, di mana - pewawancara. Ini juga terjadi. Ulangi atau pelajari topik yang Anda jawab dengan buruk dan coba lagi.
Selain itu, ada musiman yang jelas dari pasar tenaga kerja. Perusahaan yang kompeten merencanakan perekrutan berdasarkan tanggal kelulusan dari lembaga pendidikan. Pada musim semi lowongan untuk pemula lebih dari sisa waktu. Namun, persaingan saat ini lebih tinggi.
Bodoh - dipecat
Ketika seseorang dipekerjakan tanpa pengalaman, ada harapan yang sesuai untuknya.
Dari pendatang baru untuk bekerja, harap:
- Pengetahuan tentang basis teknis umum
- Mempelajari fitur-fitur area subjek perusahaan
- Menguasai alat dan praktik yang digunakan
Beberapa organisasi memberikan kursus pelatihan pemula tentang teknologi, alat, dan praktik lokal. Misalnya, aturan bentuk yang baik ketika menggunakan surat perusahaan, prosedur untuk mengubah dokumen pada wiki, fitur lokal bekerja dengan VCS dan pelacak bug.
Masih ada kursus pengantar teknis, tetapi kegunaannya meragukan. Jika menyangkut pekerjaan, maka majikan memastikan bahwa Anda memiliki tingkat pengetahuan yang memadai. Yang terbaik adalah mengambil kursus seperti itu dengan itikad baik, sebagai formalitas kecil. Mungkin mereka benar-benar akan menjadi sesuatu yang bermanfaat.
Ketika Anda mulai bekerja, ingatlah bahwa pemula tidak akan dipercayakan dengan menyelesaikan tugas penting yang mendesak, kompleks dan pada saat yang sama. Kemungkinan besar hanya akan ada satu dari properti ini. Atau sederhana, tetapi mendesak: perbaiki tata letak, kirim seseorang file, buat kembali masalahnya. Atau sulit, tetapi tanpa harapan penyelesaian - agar pemula mengumpulkan lebih banyak rake. Atau penting, tetapi eksperimental. Misalnya, sebuah proyek yang sudah lama diinginkan semua orang, tetapi tidak dapat mengalokasikan waktu untuk implementasi.
Tugas untuk pengembangan alat akan "rumit" dan buatan. Kemungkinan besar itu akan menjadi versi sederhana dari sistem utama. Dalam tugas seperti itu, tumpukan teknologi yang sama dan istilah domain yang sama digunakan seperti dalam keseluruhan proyek. Dalam hal ini, hasil eksekusi tidak akan diberikan kepada pengguna akhir. Ini mungkin mendemotivasi, tetapi lebih baik untuk menahan mood ini. Tugas artifisial harus dilakukan dengan itikad baik, seolah nasib proyek tergantung padanya.
Hasil dari penyelesaian tugas pertama Anda akan menjadi kesan pertama tentang Anda dari rekan kerja yang tidak berada di wawancara.
Versi lain dari tugas untuk menguasai toolkit ini adalah “menjalankan proyek di lingkungan mesin / pengujian lokal”. Terkadang proses ini dijelaskan dalam instruksi. Tetapi mereka biasanya sudah tua dan terkadang tidak relevan. Anda dapat membawa manfaat nyata bagi proyek jika Anda menulis instruksi baru dengan klarifikasi tentang masalah yang muncul. Tentunya di universitas saya harus menulis RGR untuk melaporkan beberapa disiplin ilmu. Hampir sama di sini. Dokumen harus mencerminkan tindakan yang harus dilakukan untuk dijalankan.
Biasanya, langkah-langkah untuk meluncurkan produk pada lingkungan pengujian kira-kira sebagai berikut:
- mengkloning repositori, beralih ke beberapa cabang atau tag
- membuat beberapa file konfigurasi
- menyiapkan struktur basis data
- isi dengan data uji
- Bangun atau kompilasi proyek
- jalankan serangkaian skrip konsol dalam urutan tertentu
Dalam proses memulai sistem, masalah yang tidak terduga akan terjadi secara lokal.
Solusi yang ditemukan untuk masalah perlu ditambahkan ke instruksi penempatan. Maka pada saat Anda mengikuti instruksi selanjutnya, masalah ini tidak akan muncul lagi. Saat mengisi file konfigurasi dan skrip panggilan, Anda perlu memperhatikan nilai apa yang digunakan di mana, dan dengan apa yang harus sesuai. Misalnya, jika proyek dibangun menggunakan sistem CI dan kemudian diluncurkan oleh skrip, penting untuk memahami di mana harus menulis nama cabang atau nomor komit. Kebetulan bahwa skrip melibatkan transfer alamat IP atau nama DNS dari database, nama pengguna dan kata sandinya. Dalam hal ini, Anda harus tahu alamat mana yang akan digunakan untuk lingkungan pengujian, login mana yang ada dan kata sandi apa yang Anda butuhkan untuk menentukannya.
Beberapa tugas mungkin terlihat sederhana untuk pengembang berpengalaman dan menyebabkan kesulitan peserta pelatihan. Ini adalah kejadian normal.
Pengembang harus menyelesaikan masalah teknis setiap hari. Karyawan yang berpengalaman telah memecahkan banyak masalah sebelumnya, dan pendatang baru belum mengatasinya. Taktik terbaik adalah menuliskan semua kesalahan yang ditemukan dalam dokumen "Memecahkan masalah dengan $ {nama tugas}". Untuk setiap masalah, Anda perlu merumuskan hipotesis tentang penyebabnya, menemukan solusi di Internet dan mencobanya secara bergantian. Hasil dari setiap upaya juga perlu dicatat.
Membuat penelitian Anda dalam bentuk dokumen akan memungkinkan:
- lepaskan komponen kecil dari kepala Anda. Misalnya, parameter konfigurasi, alamat DNS / IP, perintah konsol, dan kueri SQL.
- ingat "apa yang saya lakukan kemarin" ketika tugas diregangkan selama beberapa hari
- Jangan berkeliaran di sekitar. Anda selalu dapat membaca apa yang Anda lakukan sebelumnya dan memahami bahwa Anda kembali ke masalah semula.
- jelas menjawab pertanyaan: "apa yang kamu lakukan hari ini?" bahkan jika belum ada solusi siap pakai.
Anda harus bisa memberi tahu status tugas Anda kepada kolega
Dari waktu ke waktu, kolega akan tertarik pada kesuksesan Anda dan membagikan kesuksesan Anda. Sedikit waktu yang diberikan untuk ini setiap hari atau setiap minggu.
Jika Anda tidak melacak masalah yang ditemui dan diselesaikan, maka uraian keberhasilan Anda akan terlihat seperti: "Saya mencoba melakukan tugas itu, tetapi saya tidak bisa. Saya mencari solusi sejauh ini. " Dari cerita semacam itu, tidak jelas apakah peserta pelatihan melakukan sesuatu atau hanya duduk membaca. Apakah dia butuh bantuan? Apakah situasinya sudah berubah sejak kemarin?
Jika Anda menyimpan dokumen dengan mencari solusi, Anda dapat mengatakan, “Saya mencoba melakukan tugas ini. Saya punya kesalahan seperti itu. Jadi saya memutuskan seperti ini. Saya belum mengelola ini. Ada hipotesis dan solusi semacam itu. Sekarang saya memeriksanya. "
Jika tugas dapat diukur setidaknya entah bagaimana, maka angka-angka tersebut akan terdengar dalam status. Misalnya, untuk tugas "menulis tes unit untuk modul", kita dapat mengatakan "Saya berencana melakukan 20 tes, sekarang saya menulis 10".
Semakin banyak detail yang Anda berikan, semakin baik rekan kerja Anda akan mengerti apa yang Anda lakukan. Ini akan membentuk sikap positif terhadap rekan kerja dan membuat mereka mengerti apakah Anda membutuhkan bantuan atau tidak.
Jangan ragu untuk meminta bantuan.
Saya menulis di atas bahwa ketika masalah muncul, Anda perlu merumuskan hipotesis tentang penyebab dan solusinya. Namun, ternyata hipotesis tidak dibenarkan, dan solusi yang ditemukan secara independen untuk masalah tersebut tidak berfungsi. Dalam hal ini, lebih baik meminta bantuan. Agar tidak menyalahgunakan perhatian rekan kerja, Anda harus duduk sendiri di setiap masalah. Jika dalam beberapa jam tidak mungkin menemukan solusi, saatnya mencari nasihat dari kawan yang lebih berpengalaman.
Yang terbaik adalah memulai dengan pertanyaan: "adakah yang pernah mengalami masalah sebelumnya?" dengan deskripsi singkat tentang masalahnya. Dianjurkan untuk melampirkan sepotong pesan kesalahan atau tangkapan layar. Ini adalah pertama kalinya lebih baik mengirimnya ke obrolan umum untuk bekerja. Jadi, Anda tidak mengganggu pekerjaan mereka yang benar-benar sibuk. Pada saat yang sama, kolega gratis akan melihat pesan Anda dan akan dapat membantu.
Jika tidak ada yang membantu setelah pesan dalam obrolan umum, cobalah untuk menangkap seorang rekan yang berpengalaman selama istirahat: makan siang, teh / kopi, permainan tenis atau istirahat merokok. Jika ini tidak berhasil, maka laporkan kesulitan Anda dengan cepat atau berdiri.
Saat memecahkan masalah yang diketahui, ini mungkin berakhir. Jika masalahnya baru, maka penyelidikan akan dimulai, di mana akan diperlukan untuk bertindak sesuai dengan keadaan.
Tugas "penting" untuk pemula yang dibutuhkan pengguna akhir akan membosankan dan kecil. Misalnya, "tambahkan kolom tambahan ke laporan" atau "koreksi salah ketik dalam bentuk cetakan" atau "terapkan metode model untuk memuat atribut klien dari DBMS". Tujuan dari tugas-tugas tersebut adalah agar pemula menjadi terbiasa dengan bidang subjek dan mengintegrasikan ke dalam pekerjaan sehari-hari.
Penting tidak hanya untuk memecahkan masalah secara teknis, tetapi juga untuk memperluas pengetahuan tentang bidang subjek.
Dalam deskripsi tugas, dalam obrolan dan percakapan, istilah akan ditemukan. Mereka mungkin terlihat seperti kata benda yang sudah lama dikenal. Namun, dalam kerangka sistem informasi, mereka memiliki makna khusus yang lebih tepat. Arti istilah yang terdeteksi sebaiknya ditulis dalam dokumen khusus - glosarium istilah. Saat menambahkan ke kamus, cukup menulis pemahaman Anda tentang kata itu, dan untuk transkrip nyata lebih baik menghubungi analis. Jika dia absen, maka untuk orang-orang tua dari proyek. Mempertahankan glosarium istilah adalah salah satu cara paling sederhana untuk membiasakan diri dengan bidang subjek proyek.
Segera setelah Anda menemukan bahasa yang sama dengan kolega Anda, mereka akan mulai melihat pada Anda bukan seorang siswa pemula, tetapi seorang spesialis yang setara.
Ada tugas-tugas khusus, misalnya, "menulis unit test untuk sebuah modul." Ini hampir tidak bisa macet untuk waktu yang lama dengan mencari solusi. Selain itu, dia cukup serius dan tidak hanya diberikan untuk melatih peserta pelatihan. Tes tertulis meningkatkan stabilitas proyek dengan mengurangi bug dalam aplikasi dan mengurangi waktu untuk pengujian oleh orang-orang. Dalam dunia yang ideal, tes unit ditulis segera selama pengembangan, tetapi kenyataannya berbeda seperti biasa. Kebetulan pengembang modul benar-benar memegangnya di kepalanya dan tidak melihat kebutuhan untuk menulisnya. "Semuanya jelas, apa yang harus diuji?" Kadang-kadang modul ditulis dalam mode darurat dan tidak ada waktu tersisa untuk pengujian unit. Jadi di dunia nyata, unit test mungkin tidak. Karena itu, tugas menulis unit test dipercayakan kepada seorang pemula. Jadi peserta pelatihan akan dapat dengan cepat terbiasa dengan proyek, dan proyek akan menghemat waktu dari spesialis yang dibayar lebih tinggi.
Itu terjadi bahwa peserta magang dan pemula ditugaskan peran penguji penuh. Biasanya, sebelum ini, Anda perlu menggunakan produk secara lokal dan membaca persyaratan. Sebagai hasil dari karyawan baru diharapkan:
- pertanyaan seperti "jika Anda suka ini, maka akan menjadi seperti ini. Ini tidak diperlukan dalam persyaratan. Bagaimana seharusnya? "
- tugas dalam pelacak bug "dalam persyaratan yang ditulis seperti ini, tetapi kenyataannya berbeda."
Pengujian adalah bidang kegiatan yang terlalu luas untuk artikel ini. Jika Anda diberi tugas serupa, cari di internet cara terbaik untuk mencapainya.
Nakosyachite - dipecat
Dalam organisasi normal, jika tiba-tiba terjadi bahwa seorang karyawan yang tidak berpengalaman mendapatkan akses ke sesuatu yang kritis dan merusak sesuatu, maka orang yang melakukan ini akan disalahkan. Karena pemula secara default tidak memiliki akses ke infrastruktur kritis. Dengan bimbingan yang memadai, semua anjing tidak akan dikecewakan oleh peserta pelatihan yang tidak berpengalaman.
Jika sesuatu terjadi tiba-tiba, mereka tidak akan dipecat karena satu insiden. Orang belajar dari kesalahan. Peserta pelatihan yang sedang berjalan menerima pelajaran yang berharga dan ini sangat berbeda dari peserta pelatihan lainnya. Jika Anda membubarkan slammer, maka orang lain akan datang di tempatnya dan memotong dengan cara yang sama.
Yang utama adalah belajar dari kesalahan dan tidak mengulanginya lagi.
Jika seseorang tidak menarik kesimpulan dari kesalahannya, maka mereka akan mencoba untuk mengucapkan selamat tinggal padanya. Namun, dunia ini beragam. Dalam beberapa organisasi gangster, mereka dapat segera membuang kesalahan yang pertama. Tetapi lebih baik untuk menghindari perusahaan seperti itu, yang harus Anda tanyakan terlebih dahulu atau cari tahu lebih banyak selama wawancara.
Insiden sebaiknya dihindari
Bahkan jika Anda tidak dipecat secara pribadi untuk kusen, insiden seperti itu akan menyebabkan masalah yang tidak diinginkan untuk tim Anda dan proyek secara keseluruhan. Oleh karena itu, berhati-hatilah dengan operasi menghapus atau membuat tabel dalam database, file, instance layanan, dan dokumen dalam basis pengetahuan proyek. Jika Anda memenuhi alamat koneksi baru, tanyakan setidaknya pada dua orang berbeda apa yang dapat Anda lakukan di sana. Periksa hak Anda pada lingkungan bukan dengan coba-coba, tetapi dengan perintah yang sesuai. Misalnya, hak untuk menghapus file menggunakan perintah `ls`, hak untuk bekerja dengan tabel di mysql menggunakan perintah` SHOW GRANTS FOR 'user' @ 'host'; `,`, dan sejenisnya. Di hampir semua instrumen Anda akan memiliki kesempatan yang sama.
Saat mengedit file, untuk berjaga-jaga, simpan sendiri salinan aslinya.
Beberapa hambatan dibangun antara pengguna magang dan pengguna akhir.
Jika Anda bisa segera memberikan produk Anda kepada konsumen, Anda tidak akan bisa mendapatkan pekerjaan, tetapi memulai "berenang bebas". Tetapi sementara Anda tidak memiliki kesempatan seperti itu (dan pada saat yang sama tanggung jawab), Anda perlu melewati beberapa tahap kontrol pada proyek.
Yang pertama adalah cek mentor. Dia mengevaluasi solusi pemula dari sudut pandang teknis. Jika seorang mentor belum ditunjuk, maka Anda harus menemukannya. Untuk melakukan ini, Anda perlu memilih seseorang dari orang-orang yang sudah lama bekerja di proyek dan pada saat istirahat memintanya untuk melihat solusinya: apakah masalahnya diselesaikan dengan benar? Jika Anda mulai mencari dan menjawab, maka seorang mentor ditemukan. Jika Anda mengabaikannya, maka Anda harus bertanya kepada orang lain.
Tahap selanjutnya adalah Jaminan Kualitas. Di Rusia - penguji. Di Soviet - kontrol standar dan kontrol kualitas. Mereka harus memastikan bahwa hasil pekerjaan magang sesuai dengan tugas yang diberikan kepadanya. Mereka jarang akan dibaca ke dalam kode. Paling sering, penguji akan memeriksa proyek rakitan, yang disimpan pengembang dalam sistem kontrol versi.
Tahap ketiga adalah manajer rilis. Mungkin tidak ada seorang individu untuk tugas ini, tetapi seseorang masih memainkan peran.
Dia memeriksa bahwa penguji telah mengkonfirmasi bahwa proyek tersebut dapat dirilis. Setelah itu, ia melakukan tindakan pengiriman produk ke pengguna akhir.Dalam organisasi kecil, hambatan ini mungkin tidak ada karena berbagai alasan. Namun, mereka tidak akan mengatur tugas bagi pemula untuk mengubah sesuatu yang penting. Karena tidak ada yang membutuhkan risiko ini.Anda harus terlebih dahulu terlibat dalam pertempuran, dan di sana akan terlihat.
Napoleon Bonaparte
Saya harap artikel ini membantu Anda mengatasi rasa tidak aman Anda dan mengirimkan resume pertama Anda. Tentu saja, Anda harus terlebih dahulu bersiap. Tapi jangan terlalu kencang. Anda kemungkinan besar sudah belajar selama beberapa tahun di universitas atau perguruan tinggi. Di mana menarik lebih jauh? Pada akhirnya, lebih baik mendengar "tidak" sekali dari spesialis dan mengerjakan kesalahan, daripada mengatakan "tidak" kepada diri sendiri setiap hari dan berhenti dalam pertumbuhan profesional.Setelah bekerja, Anda perlu berkonsentrasi untuk tumbuh dari magang menjadi anggota penuh tim. Pertumbuhan seperti itu biasanya dibarengi dengan kenaikan gaji Anda.Saya berharap Anda bersabar dan gigih.