kartu kredit fraud (lagi)

Yup selasa kemaren, wake up call pagi hari gua adalah dari amex fraud service bla bla… langsung gua tutup sebelum dialihkan ke operator karena gua masih ngantuk. Intinya gua langsung tau, kartu kredit gua dipake tanpa seijin gua. Ini kedua kalinya kartu kredit gua kena (padahal belum ada 2 tahun disini). Yang dulu pertama kali kena capitalone, dimana kartunya dipake di kota lain sekitar sini. Kali ini yang kena amex, dipake di New Jersey. Setelah satu jam mengumpulkan nyawa sambil main clash of clan, fb, path, dll, baru gua buka website amex dan request buat di call. Untungnya urus ginian di US gampang, tinggal telepon dan bilang yang mana yang bukan transaksi yang lo lakuin, dan semuanya bakal di cancel dan langsung dikirim kartu yang baru.

Gua enggak inget yang dulu capitalone berapa hari baru kartunya dateng. Amex kemaren cukup mengejutkan, kartunya sampe kurang dari 24jam abis ditelepon. Pantesan orang pada bilang kalo customer servicenya amex ok punya.

Kemarin ada sekitar 3 transaksi yang fraud. Dua pertama udah dilakukan beberapa hari sebelumnya, dan nilainya kecil banget, cuma sekitar 1$. Karena gua ga buka statementnya tiap hari jadinya enggak notice sama sekali. Sebenernya ini cara pinter juga, tes dulu kartunya bisa dipake atau enggak. Begitu jelas bisa dipakai, transaksi ketiga nilainya sekitar 100$. Dan gua dibangunin pagi pagi gara gara ginian. Well, jam 8 menurut standar gua adalah pagi, no complaint please.

FYI, meskipun transaksi kartu kredit di US nilainya gede banget, tapi security kartu kredit disini masih cupu abis. Ketinggalan jaman. Worldwide kebanyakan udah pake EMV chip + pin. Kartu kredit secured yang paling basic waktu gua dapet di Canada pun udah pake chip + pin. Di US, masih magnetic stripe doank. Primitif abis, masih kayak indo beberapa tahun lalu. Alhasil turis US kalau ke eropa, denger denger kartu kredit magnetic stripenya suka di reject😛. Solusinya adalah pake cash atau prepaid credit card yang ada chipnya. Untungnya meskipun security nya primitif, kalo ada fraud gampang urusannya. Di US baru ada beberapa kartu kredit high end yang pake chip, kabarnya tahun ini mulai migrasi ke EMV, dan total biayanya mencapai beberapa billion US$.

By marcadian Posted in Story

Liburan!!

Arrival

Baru balik dari 2 minggu liburan di jakarta. Timing liburannya sebenernya agak agak kurang tepat karena lagi musim banjir. Terus kenapa balik di musim banjir? Ya karena dapet subsidi tiket dalem bentuk amplop merah😉. Untungnya selama gua di jakarta, ga sampe banjir parah banget. Gua berangkat dari SFO hari kamis tanggal 23 malem. Biar hemat waktu tidurnya di pesawat aja. Pulang kerja langsung mandi dan nungguin shuttle buat ke bandara. Tadinya gua pikir bakal macet, ato jemput orang banyak, ternyata gua adalah yang terakhir dijemput. Sampe ke bandara, counter check in masih kosong. Kelar check in dan security, flight gua masih kira kira 3 jam lagi. Gate gua pun deket banget ma security. Karena ga ada kerjaan, gua jalan sampe gate di ujung, balik lagi, dan akhirnya bengong di gate 2 jam lebih.

Flight dari SFO – HKIA banyak banget orang asia, dan carry on mereka ukurannya sadis. Gua yang tadinya mau bawa koper carry-on, cukup bersyukur bawa backpack aja, karena backpack gua aja masukinnya susah banget, ga ada space lagi. Bagian paling parah adalah, banyak penumpang yang ngambil snack ato minuman sendiri di kitchen, mungkin udah dianggep rumah sendiri🙂 dan entah kenapa gua risih liatnya. Kalo kata temen gua yang flight attendant

“Lahh emank mesti na ngambil sendiri tauk! Jadi gausa pencet call light. Lain x jgn ngerepotin pramugari na ya”

Enggak tau lagi mau bilang apa…. Trus mba pramugarinya buat apa donk?

Sampe di jakarta, nunggu bagasi sekitar 30 menit. Koper gua sendiri cuma satu, ukuran 28″ dan ga penuh, enteng banget karena udah ga tau mau bawa apa. Di Jakarta gua dijemput sama temen gua, langsung ke TA buat makan siang karena gua laper. Meskipun gua makan sebanyak 5x selama 20 jam terakhir, tapi porsi makanan di pesawat kan kecil, yang porsinya ok cuma sarapan di HKIA doank. Waktu di TA, terjadi percakapan kira kira gini:

gua: laper nih
temen: emang lo makan berapa kali?
gua: *ngitung* 5x (2x meal SFO – HKIA + 1 noddle cup + 1 sarapan di HKIA + 1 meal HKIA – CGK)
temen: tuh lu udah makan banyak gitu masa masih laper? gua: *bener juga* loh tapi porsinya kecil
temen: emang lu makannya banyak
gua: oh gua lagi sleep deprivation nih, kan kalo sleep deprivation jadi laper terus
temen: boong!

FYI gua ga boong tentang kurang tidur bikin laper http://www.webmd.com/sleep-disorders/excessive-sleepiness-10/10-results-sleep-loss?page=2

8. Losing Sleep Can Make You Gain Weight

When it comes to body weight, it may be that if you snooze, you lose. Lack of sleep seems to be related to an increase in hunger and appetite, and possibly to obesity. According to a 2004 study, people who sleep less than six hours a day were almost 30 percent more likely to become obese than those who slept seven to nine hours. Recent research has focused on the link between sleep and the peptides that regulate appetite. “Ghrelin stimulates hunger and leptin signals satiety to the brain and suppresses appetite,” says Siebern. “Shortened sleep time is associated with decreases in leptin and elevations in ghrelin.” Not only does sleep loss appear to stimulate appetite. It also stimulates cravings for high-fat, high-carbohydrate foods. Ongoing studies are considering whether adequate sleep should be a standard part of weight loss programs.

Dan pada saat itu gua beneran lagi sleep deprivation, 3 – 4 malem terakhir sebelom berangkat gua cuma tidur sekitar 4 – 6 jam tiap harinya dan di pesawat cuma total sekitar 4 – 5 jam. Sampe di Jakarta mata gua merah @.@

By marcadian Posted in Story

The departure

Blog udah lama banget ga di update, mau tulis apa juga bingung. Akhirnya diputuskan cerita saat mau berangkat kira kira 6 bulan lalu, mumpung masih inget🙂

Jadi ceritanya, H1B tahun kemaren itu telat banget, mestinya cuma sekitar 4 minggu, punya gua udah masuk dari juni, ampe september awal belum keluar juga. Padahal oktober 1 itu mestinya start kerja. Karena H1B belum ada kejelasan, otomatis urusan lain seperti apply visa, cari tempat tinggal, cari tiket, dll belum bisa diurus. Akhirnya sekitar sekitar september pertengahan, processing H1B nya di upgrade ke premium processing, yang artinya dalam waktu 2 minggu pasti ada jawaban. 2 minggu kemudian, tanggal 24 September H1B gua udah di approve dan form I-797 bakal segera dikirim pake fedex, butuh 3 business days. Sebenernya kalo itung pas 3 business days, hari jumat mestinya paketnya udah sampe. Kalo nunggu form nya dateng dulu baru book appointment visa bakal lama. Dengan agak nekad, book lah appointment visa untuk hari selasa tanggal 2 oktober. Untuk H1B visanya butuh kira kira 2 – 3 business days untuk dapet paspornya balik. Jadi kalo plannya perfect sekitar hari jumat udah bisa dapet balik tuh paspor dan di weekend udah bisa cabut.

Akhirnya, paket I797 nya dateng tepat di senin sore🙂 besoknya langsung cabut ke US embassy. Gila US embassy jakarta rame banget, gua pernah apply visa US di konjen toronto, jauh lebih sepi. Wajar sih, secara canadian cuma perlu paspor buat ke US, dan di indo, semua butuh visa buat ke US. Jadilah gua ngantri mulai jam 6 pagi (padahal gua booknya yang jam 7 pagi). Yes jam 6 pagi sodara sodara, ga salah tulis (untung bisa bangun).  Kelar interview langsung tau visanya di approve ato enggak, dan H1B jauh lebih gampang di approve dibanding turis visa, karena udah melalui background check pas apply H1B melalui USCIS.

Pulang dari embassy, masih mikir kapan berangkatnya, sambil mulai pencarian tiket pesawat dan juga tempat tinggal. Akhirnya diputusin berangkat tanggal 10. Cari tempat tinggal cukup repot sebenernya, karena cuma bisa liat ads di internet doank tanpa bisa liat tempat sebenernya. Even worse, ga bakal bisa dapet tempat yang permanen dari craiglist. Karena banyaknya scam dari foreign yang pura pura mau book, craiglist naro warning di websitenya, deal hanya dengan orang yang bisa lo temuin. Setelah pusing cari cari tempat, akhirnya ketemu temporary place yang lumayan dari airbnb. Masalah berikut: payment. Airbnb terima credit card, dan credit card TD gua yang dari canada udah gua turunin limitnya (karena itu secured card, dan gua mo duit gua balik). Untungnya gua pernah link debit card TD dengan paypal, dan airbnb terima paypal🙂 Masalah minor berikutnya adalah, saldo nya enggak banyak jadi gua cuma bisa book untuk sekitar 10 hari. Well, masih better lah daripada jadi homeless. Satu urusan kelar, pas sampe dipastikan ga tidur beralaskan bumi, beratapkan langit dan berselimutkan bintang.

Hari jumat tanggal 5, paspor gua balik dari embassy. Nah mulai lebih serius cari tiket pesawat, karena mostly bakal diminta visanya, jadi buat book bakal perlu visa di paspor. Hari sabtu gua mulai cari cari online via expedia, dan beberapa website. Hasilnya sih cuma satu airlines yang lumayan, china airlines. Gua ga langsung book, tapi cari ke travel agent lokal, ngecek beberapa tempat dan minta quote. Hari sabtu gua sempet ke TA dan juga ke senayan city buat ngecek tiket. Setelah cek di beberapa tempat, diputuskan beli dari travel agent yang di TA, one way ticket🙂 Untungnya harga tiketnya ga sampe gila gilaan, malah termasuk murah. Berbanding terbalik sama waktu ke toronto, dimana gua book 30 hari sebelomnya dan harganya udah mahal. Satu urusan lagi kelar.

Proses kali ini luar biasa ekspres, dari gua terima form I797 (2 okt) 8 hari kemudian dah berangkat (10 okt). 8 hari itu include apply visa, cari tiket, cari tempat tinggal, packing >.<

Anyway, china airlinesnya gua dapet seat yang menarik, first row. Biasanya orang mau di first row mesti nambah duit. Dan gua di first row sendirian🙂 Happy dengan china airlines, makanan dll juga oke, ga kalah dari cathay pacific. Waktu itu gua mikir wah oke juga nih china airlines, next time naek ini lagi boleh.Sampai di bulan januari gua nemu berita ini dan sepertinya mesti consider airline lain😛

By marcadian Posted in Story

The Interview!

Jadi ceritanya, setelah apply lewat interviewstreet, dikontak lah oleh recruiter dari PG. Intinya bilang PG tertarik untuk talk, dan diminta beberapa baris ngemeng, kenapa tertarik di PG. Setelah bla bla bla, selanjutnya jadwalin untuk interview. Jadwalin jamnya agak susah karena perbedaan waktu 14 jam, dan diminta di jam kerja engineernya. Alhasil kebanyakan interview dilakukan tengah malem😐

Interview pertama jam 1 pagi, ato jam 11 siang waktu SiEngineer. Dari jam 9 semangat udah berkobar, bercampur deg – degan juga, maklum interviewnya sama company di “Sillicon Valley”. Waktu menunggu saat interview, mampir sebentar ke ranjang buat rebahan, selanjutnya ketiduran. Untungnya gua udah nyalain skype, dan volume suara di laptop udah di set maximal, jadi gua terbangun oleh suara call skype. Bangun dengan mata masih 1/2 merem, klik accept call. Sambil say hi dan bilang hold on hold on, mata ngantuk cari cari headset. Headset terpasang, dan mulailah interview dilakukan. Pertama interviewernya ngenalin diri dulu, selanjutnya mulailah pertanyaan, dan jawabannya berupa coding. Codingnya live di stypi, enggak terima ketik dulu di editor baru copy paste, jadi ketelitian penting disini. Pertanyaan pertama cukup mudah, namun diminta untuk solusi yang lebih baik. Sebenernya, emang solusi yang lebih baik itu ga susah, tapi maklum udah karatan, jadinya yang keluar duluan adalah solusi yang butut😛. Interviewer pertama ini merespon dengan baik, jadi kalo bener ato dia merasa jawaban udah jelas dia bakal respon seperti “yeah, that’s right”, “i agree with that”, etc. Responnya ini merupakan lampu ijo🙂 dan dalam beberapa hari datanglah invitation untuk interview kedua. Interviewer pertama ini adalah mobile engineer.

Interview kedua dilakukan jam 1 siang PDT, alias jam 3 pagi WIB. Interview kedua ini gua di telepon lewat HP, katanya karena cuma itu kontak yang dikasih, padahal gua udah kasih tau skype. No problem, nyalain aja speaker phone, kalo ga gimana koding satu tangan mesti pegangin HP. Interview kedua ini mayan susah, yang susah bukan jawaban kodingnya, tapi pertanyaan yang menyusul yaitu “convince me this works”, “buktikan ga ad ilegal memory akses”😐 Penjelasan gua berantakan untuk ini, dan interviewer kedua ini poker face abis, ga ada responnya sama sekali. Setelah selesai interview, agak desperate sendiri karena kepikir gimana kalo ga lolos, padahal soalnya bisa dijawab semua. Untungnya beberapa hari kemudian datenglah email untuk interview ke – 3! Yipee!! Interviewer yang ini juga mobile engineer.

Interview ketiga ini dilakukan pagi hari waktu indo alias malam PDT. Loh emang ga kerja? Waktu itu hari kejepit, yang ke kantor juga pada nongolnya siang. Interview kali ini dilakukan oleh head mobile engineering. Soal pertama obvious untuk dikoding, gua udah koding kira kira 70% dan stop untuk mikirin solusi yang berupa kombinatorik. Setelah lama layar stypi ga berubah, interviewer nya nanya apakah ada kesulitan. Dan gua bilang lagi mikirin solusi kombinatorik yang lebih efisien. Respon dia selanjutnya cukup surprising, ga usah begitu lanjutin aja yang udah di koding. Langsung semangat 45 dan hajar koding, ada sedikit yang kurang dan ditanya oleh interviewernya, selanjutnya diminta jelasin solusinya, dan ditanya tentang upper bound yang mungkin. Kali ini perlu mikir beneran, coret coret di kertas dikit, dia cukup puas dan lanjut ke pertanyaan berikutnya. Nah soal berikutnya ini secara “level” adalah soal yang paling susah dari interview pertama sampai saat ini. Begitu denger soalnya, langsung inget kalo dulu pernah ngerjain yang mirip banget sama ini, excited banget. Langsung berusaha calm down, jangan sampe terlalu seneng malah buyar jawabannya. Setelah coret coret bentar, koding dan jelasin solusinya. Dapet response bagus, dan selesailah interviewnya. Anyway, interview ini adalah interview terbaik! Kalo di interview sebelumnya gua mesti tunggu beberapa hari untuk dapet invitation interview berikutnya, kali ini next day gua langsung dapet invitationnya! Yey!

Setelah selesai interview ketiga ini, recruiter yang kontak gua, ngeadd di linkedin. Uniknya message yang dikirim adalah “orang yang have done business with”. Saat itu pikiran gua ada 2, interview ketiga adalah interview teknikal terakhir dan tinggal ngomong sama HR, atau akan ada interview ke-empat yang merupakan interview terakhir. Ternyata ada interview ke-empat yang merupakan interview terakhir!

Interview keempat, kali ini dilakukan malem lagi. Yang menarik dari interview ini adalah pertanyaannya lebih cenderung ke arah analisis kompleksitas. Soalnya gampang, setelah terjawab, dia kasih solusi punya dia dan diminta analisis kompleksitasnya. Bukan sekedar big O yang batas atas, tapi diminta running time yang lebih precise. Menarik, sempet panik sedikit dengan banyaknya log yang ada dan gimana simplify persamaannya. So far, jawaban gua ga terlalu buruk, tapi entah bagus banget ato enggak, karena interviewernya enggak begitu kasih respon. Interviewer kali ini unik, karena dia backend engineer! Perspektif rolenya dan tantangan yang dihadapi sehari hari tentu beda dengan mobile engineer.

Dari setiap interview, setelah interview selesai akan dikasih kesempatan untuk tanya apapun ke interviewernya, umumnya yang gua tanya adalah seputar, kerjaan mereka ngapain aja, challenge apa yang dihadapi sehari hari, dan seputar suasana ditempat kerja. Dari sini banyak informasi yang bisa didapet tentang suasana kerja. Gua cukup suka dengerin jawaban mereka, menurut gua, dengan para interviewer cerita cerita experience , itu lebih bikin tertarik dan bisa tau apakah perusahaan sesuai dengan ekspektasi. Dari semua interview, jawaban interviewer paling panjang adalah interviewer ketiga, dia cerita banyak banget dan mendetil banget, tapi tentunya enggak membocorkan rahasia perusahaan. Setiap interview yang dilakukan biasanya sekitar 45 menit untuk interviewer bertanya, setelah itu tergantung berapa banyak pertanyaan yang diajukan untuk interviewer, di interview ketiga, interviewernya cerita panjang banget, sekitar 45 menit lagi. Jadi interview paling lama adalah yang ke – 3, sekitar 1.5 jam.

Well, tentang interview questionsnya apa aja, ga bakal gua post disini, sepertinya kurang baik kalo gua memberi tahu pertanyaan interview dimana gua bekerja, dengan identitas gua di internet. TAPI jangan berkecil hati, kebanyakan dari pertanyaannya dapat dilihat di Glassdoor. Sekalian bisa liat juga kira kira gimana perspektif orang laen yang pernah di interview.

Lanjut ceritanya, jadi beberapa hari setelah interview terakhir, gua dapet telp dari HR, dia kasih tau kabar menggembirakan yaitu mereka mau kasih offer, dan juga mereka tanya tentang status, dan surat – surat untuk urusan visa. Kalo ga salah inget, malemnya gua udah dimintain jawaban karena mau segera di proses. Jawabannya iya, dan mereka langsung kasih surat untuk di tandatangan dan scan untuk dikirim balik + scan beberapa dokumen untuk kelengkapan apply visa, yaitu degree dan transkrip nilai (untuk di assess oleh semacam education counselor dan dinyatakan setara dengan bachelor di US) dan juga scan paspor. Untungnya degree + transkrip nilai gua udah 2 bahasa, jadi enggak perlu di translate segala. Di telepon untuk offer hari rabu, dan langsung di proses instan, hari senin petisi untuk ijin kerja udah dimasukin ke USCIS oleh lawyer. Untungnya (lagi) karena semua di proses secara cepat, petisi gua dapat tanda terima tanggal 5 juni 2012, dan pada tanggal 12 juni 2012 cap visa H1B untuk tahun fiskal 2013 udah penuh terisi🙂

waktu cari kerja

Beberapa hari lalu gua bersihin inbox email, dan nemu bejibun email notification waktu mencari kerja di awal tahun. Waktu diitung ternyata gua pernah apply ke banyak banget perusahaan. Jadi inget beberapa minggu lalu, ada yang bilang kalo gua gampang buat nyari kerja, dan bikin gua berpikir, kayaknya enggak deh, dulu gua apply banyaaaak banget, yang respon aja dikit.

Kembali ke awal tahun 2012, ketika gua mulai untuk mencari cari kerjaan. Jadi, gua mulai dengan menginterogasi teman teman yang sudah bekerja, tanya kerjaannya ngapain, enak ga di perusahaannya, range gaji berapaan, dll. Setelah merevisi resume, mulailah register di jobsdb dan submit resume kesana. Selanjutnya memantau job job yang ada di jobstreet, dan apply. Seinget gua kebanyakan yang gua apply berlokasi di singapore, tapi entah, udah kurang inget juga apply kemana aja. Entah udah berapa kumpeni yang gua apply pada saat itu, rasanya sih puluhan udah nyampe. Hasil? Ga ada satu respon pun T__T

Selain lewat jobsdb gua juga post resume di robertwalters, monster, dan juga apply langsung ke website beberapa company. Next step, menggunakan networking, gua nitip resume ke 2 kumpeni, satu dipanggil dan dikasih offer, satu lagi dikacangin.

Setelah bekerja sekitar sebulan, gua mengetahui kalo seorang temen gua baru lolos interview di salah satu startup di sillicon valley, dan dia bakalan internship disana. Dia nulisin pengalaman interviewnya di blognya, beserta beberapa pertanyaan yang ditemuinya ketika di interview. Surprise (or not?), gua bisa jawab pertanyaan-pertanyaannya. Terinspirasi lah untuk ikutan apply disana. Langkah pertama mengasah kemampuan yang sudah karatan, dan tempat yang tepat adalah interviewstreet.

#Apa itu interviewstreet?  Singkatnya mereka adalah startup yang membantu perusahaan nyari talent, dan juga membantu orang cari kerjaan. Disana intinya adalah ngerjain soal soal programming, dan setelah solve sejumlah tertentu, bisa apply posisi di perusahaan yang bekerja sama dengan interviewstreet.

Back to topic, setelah memulai interviewstreet dengan berdarah darah selama sekitar sebulanan, gua berhasil solve belasan soal dan bisa apply job melalui interviewstreet. Gua apply banyak perusahaan, dan ada satu yang merespon (yipii!!!) yaitu startup dimana temen gua bakal internship. Selama proses interview yang berlangsung 4x dan memakan waktu total berminggu minggu, gua masih juga sibuk ikutan codesprint, yaitu kontes dari interviewstreet dan umumnya di sponsori beberapa perusahaan. Sialnya, ini codesprint memakai jam north america, intinya gua koding dari sekitar jam 2 AM – 6 AM hari minggu, indahnya koding diiringi terbitnya matahari.. dan ini berlangsung bukan cuma sekali. Life is hard dude…

Kembali ke abis bersih bersih inbox. Setelah diingat ingat, berikut daftar perusahaan yang pernah gua apply

Apply langsung ke web

  • zynga
  • amazon
  • shopify
  • ibm canada lab
  • pocketgems
  • apple
  • RIM singapore
  • HP Singapore
  • accenture singapore < saya ditolak
  • microsoft

Minta refer / ditawarin karena kenal

  • accenture indo
  • ibm indo
  • phasedev
  • facebook
  • binus

kirim CV

  • jobsDB (apply banyak company di sing, ga ad respon satupun)
  • monster
  • robertwalters

via interviewstreet

  • factual
  • twitch.tv
  • pocketgems
  • facebook
  • 500px
  • zynga
  • palantir
  • eventbrite
  • evernote
  • quora
  • twitter
  • uken games
  • shopify

Banyak kumpeni bener bener enggak kasih respon sama sekali, tapi cuma digantungin. Alhasil jadi ga tau apakah in progress, atau emang bener bener dicuekin. Bahkan ada yang udah minta jadwalin interview 2x dan enggak pernah kejadian tuh interviewnya. Maklum, mungkin terlalu banyak orang yang apply.

Anyway, dari sekiaaan banyaaak yang pernah gua apply, menurut gua ga gampang juga buat nyari kerjaan. Dalam kasus gua, untuk dikontak aja chancenya kecil, cuma beberapa kumpeni yang respon, apalagi kasih offer.  Kalo lagi nyari kerjaan, hajar aja apply sebanyak banyaknya!🙂

FAQ : Mana pertanyaan interviewnya?

Answer : Di post lain, entah kapan🙂

Working at I**

Yak, setelah berbulan bulan menganggur, dan banyak orang yang suka tanya “kerjaan lo disana ngapain?”, mari ditulis aja. Sebenernya udah agak lama pengen nulis tentang ini, tapi terkadang mikir juga gimana nulisnya karena tentu ada term term yang ga boleh disebut karena merupakan confidential information.

Kerjaan

Kerjaan gua disana adalah sebagai Functional Verification Tester (FVT) untuk produk DB2, buat yang enggak tau, DB2 adalah DBMS untuk versi enterprise, saingan beratnya si “peramal”. Biasanya kalo gua bilang tester ke orang indo, mereka agak bingung, sepertinya memang kerjaan sebagai quality assurance agak kurang di indo, yang paling banyak adalah programmer dengan kualifikasi segudang, yang ngerjain dari desain, coding, testing, ampe dokumentasi🙂  Sebenernya kerjaan quality assurance sangat penting, untuk memastikan quality dari suatu software. Lebih baik ketemu defect sebelom dirilis, dari pada ada customer yang komplain ada defect.

Sesuai namanya, FVT bertugas ngetes fungsionalitas, hal yang dites tentunya tergantung kepada item apa yang dikerjakan. Tes fungsionalitas berarti lu harus memastikan bahwa behaviour program yang dibuat oleh developer adalah sesuai dengan design yang dibuat sebelumnya. Untuk itu harus mempertimbangkan banyak hal, terutama adalah corner case, gimana handling error, dll.

Penting untuk memastikan “coverage” ato lingkup dari suatu test, tentunya tidak memungkinkan untuk mencoba semua possible scenario, maka umumnya developer sebagai pembuat akan memberikan informasi tentang hal hal yang harus dipertimbangkan. Coverage harus dipastikan tidak terlalu besar, namun cukup baik untuk mengetes bagian besar dari suatu code. Dari sebuah desain yang dibuat oleh developer, FVT akan membuat test plan, dan memastikan coverage dari test plan dengan developer. Setelah semua pihak pihak terkait setuju dengan coverage dari test plan, baru testcase akan mulai dibuat. Tester memiliki kebebasan untuk mengimplementasikan test plan, tentunya dari sebuah definisi scenario pada testplan, tester harus membuat berbagai variasi. Sebagai contoh pada aspek tipe data, meskipun sebuah test plan tidak menulis secara eksplisit tentang tipe data yang akan digunakan, tentunya akan merupakan hal baik jika test case yang dihasilkan memiliki berbagai variasi tipe data.

Kerjaan sebagai tester, meliputi bikin test plan, bikin test case, maintain test case lama (tambah ato modify testunit), execute test case, dan laporin defect ke developer. Umumnya kalo anak intern baru bakalan kebagian dari bikin test case, karena bikin test plan itu lebih susah. Test case yang dibuat umumnya adalah tipe automatic self checking testcase, dengan menggunakan bahasa cryptic, yaitu PERL. Automatic self checking testcase artinya setelah dieksekusi, testcase tersebut dapat mengecek dan melaporkan apakah sukses atau gagal, dan juga testunit mana saja yang gagal. Untuk yang belum tau, testcase itu adalah file yang berisi testunit testunit, dan testunit adalah skenario testing. Sebagai contoh : testcase A berisi skenario skenario untuk mengetes berbagai tipe data. Di dalamnya terdapat berbagai testunit, testunit 1 mengetes tipe data int, testunit 2 mengetes tipe data double, testunit 3 mengetes tipe data string, dst.

Selama 16 bulan disana, gua paling banyak ngerjain tentang query, gua kerja di proyek yang bertujuan mempercepat eksekusi query selama 11 bulan. Selama di proyek ini gua ikut ngerjain 4 item (read:subproyek) dari total sekitar 8 atau 9 item di dalam proyek ini, 2 item gua cuma implementasi semua testcase, 1 item gua kerjain beberapa testcase, dan 1 item lagi gua buat testplan sekaligus buat testcase. Karena latar belakang dari kompetisi pemrograman, selama bekerja di area ini gua sangat excited, karena selama disini, banyak desain yang berkaitan secara langsung atau tidak langsung teknik algoritma, misalnya bagaimana manfaat hashing secara real world. Hal lain yang dipelajari adalah proses yang terjadi ketika sebuah query di run, ternyata, query itu dicompile terlebih dahulu jadi executeable. Secara kasar prosesnya kira kira  Query -> Rewrite -> optimization ->  compile.  Dalam beberapa kasus gua harus ngebohongin optimization🙂 so far, selalu berhasil. Kalo ga salah inget, skor terakhir 2 – 0 untuk kemenangan gua. Gimana cara bohongin optimization? gampang, maenin berbagai aspek yang digunakan oleh optimizer untuk melakukan estimasi cost. Faktor umum yang terkait yaitu resources (CPU speed, berbagai memory size mis : sortheap, network speed, dll) dan statistik (jumlah row, ukuran column, dllllll)!! Note : ketika melakukan optimisasi, ada 2 pilihan yang dapat dilakukan oleh optimizer, greedy atau dynamic programming, hal ini ditentukan oleh optimization level pada database configuration.

Dua hal tersulit yang pernah gua kerjakan menyangkut masalah memory error  dan costing. Pada memory error, intinya gua haru membuat sebuah operator di disable pada saat runtime dikarenakan ukuran SORTHEAP yang tidak mencukupi. Orang umumnya akan berpikir “oh gampang, kecilin aja SORTHEAP nya terus run sebuah query yang row nya banyak!!” YAK selamat, jawaban anda salah total, dengan cara demikian sampai jaman komputasi udah di galaksi (bukan awan lagi) tidak akan pernah terjadi. Kenapa bisa?? Karena pada proses optimization, optimizer akan melihat bahwa memang tidak ada memory yang mencukupi, maka optimizer tidak akan memilih plan yang mengandung operator tersebut🙂 Intinya yang harus dilakukan adalah, membuat optimizer (pada saat planning) berpikir ada memory yang cukup sehingga access plan dengan operator tersebut akan dipilih, tetapi ketika di eksekusi ternyata tidak ada cukup memory🙂

Hal lain yang sulit adalah ketika gua mengerjakan testcase mengenai costing. Gua ga nyangka bakal kena testcase ginian, karena ini susah. Di item pertama yang gua kerjain, bagian costing dikerjain oleh coworker gua yang merupakan regular employee. Dalam testcase yang gua kerjain, intinya adalah gua harus membuat berbagai macam kasus JOIN dan memastikan suatu low level operator dijalankan dengan lancar. Tipe join disini yang gua maksud disini misalnya inner join, inner join with early out, right outer join, right early out, dll. Dan karena tujuannya adalah mengetes perhitungan optimizer, gua tidak diijinkan, menggunakan join guideline, melainkan harus murni berdasarkan perhitungan optimizer. Alhasil harus menipu compiler dengan mengatakan “hoi ini table ada 1 juta row loh!!”, padahal isinya cuma 10 row ato “oi, kolom ini unik bisa untuk early out”🙂 nah bagian nipu nipu ini yang susah, karena dalam beberapa kasus cara optimizer menghitung tidak diketahui secara detil, jadi, coba lagi dan coba lagi. Seriusan, kasus tersusahnya adalah membuat right outer join (secara runtime). Mungkin ada yang berpikir “loh kan tinggal tulis select … from a right outer join b” sayangnya cara ini likely bakalan gagal. Kenapa? karena si optimizer bilang bakalan lebih untung jadi b left outer join a, maka plan yang didapat akan jadi b left outer join a, smart eh?

Intinya query yang lu tulis, lom tentu persis sama dengan yang dieksekusi, untuk melihatnya dapat dilakukan dengan explain facility untuk melihat access plan. Sebagian besar query lambat, dapat diatasi dengan jalanin runstat untuk mengupdate statistik. Sebenernya update statistik bisa diset otomatis dengan autorunstat, namun akan lebih berat ketika terjadi perubahan data karena harus update statistik.

Kutu kutu yang gua temukan cukup beragam, dari yang sangat silly (cuma create schema dan crash, muka manager langsung mengkerut begitu denger ini), manggil fungsi untuk alokasi dan kurang tanda &, alhasil null mulu dan crash, hasil yang tidak konsisten, dll. Ketemu kutu merupakan sebuah prestasi bagi seorang tester (we found a way to blame developer!), semua kutu sekecil apapun harus di track keberadaannya. Namun belum tentu akan langsung di fix. Kutu yang severity nya high atau impactnya besar merupakan prioritas utama. Sedangkan kutu kecil kalo ga keburu diberesin sebelum release, biasanya akan di fix di service pack.

By marcadian Posted in Story

2011 in review

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 5,200 times in 2011. If it were a NYC subway train, it would take about 4 trips to carry that many people.

Click here to see the complete report.

Behind the scene INC 2011

Tahun ini gua berpartisipasi dalam INC 2011, bukan sebagai peserta lagi, tapi sebagai judge/problem setter.

Karena ketua juri lagi di negeri seberang, mengaku menutut ilmu, gua kebagian in charge untuk babak penyisihan. Juri sedikit kewalahan untuk babak penyisihan dikarenakan banyaknya submission. Buat yang belom tau, cara judging saat penyisihan itu. Peserta submit lewat web, “submitter” download dari web, submit ke pc2, juri judge pake pc2🙂 makanya lama, soalnya jumlah kliknya banyak banget sebelom ampe ke tempat juri, perlu disubmit oleh submitter. Submitter untuk babak penyisihan sendiri sekitar 10 orang, dan juri, cukup sekitar 4 orang karena judging dengan pc2 sangat cepat.

H-2 Menjelang Final

Hari senin sehabis penyisihan, gua memutuskan mudik ke kampung di pulau seberang karena tidak tahan dengan kerasnya kehidupan Ibukota Jakarta😦 dan gua baru kembali ke Jakarta jumat malam. Ketika online di YM, bos juri yang rese minta gua ke binus buat test time limit, geez. Gua juga males kalo mesti sore ke binus, su beralasan ga bisa ke binus untuk ngetes karena lab software dipake pada saat siang hari, dan sore hari dia mo pergi.  Gua langsung kontak panitia di binus melalui email, kasih tau kalo besok mau ngecek time limit, dan langsung tidur karena masih cape.

H-1

Bangun pagi dan ga ada balesan atas email gua. Akhirnya berinisiatif menculik winardi untuk ngomong ke SiapapunDiLab agar diijinkan masuk. Ketika gua, winardi dan albet jalan ke Binus, tampak seseorang yang “Katanya Ga Bisa Ke Binus Karena Mau Pergi” sedang menyebrang jalan -.-  *hiaattttt keluarin tendangan tanpa bayangan

Final

Gua dateng pagi ke binus, sedikit terheran kenapa macet. Ternyata di binus sedang ada beberapa acara lain di samping INC. Parkiran motor yang biasanya gratis kalo hari minggu ga ad acara, hari ini mesti bayar sesuai tarif hari biasa. Untung saya masih punya kartu mahasiswa, jadi cukup 1000 / hari🙂

Dateng ke ruang juri, gua mulai bagiin soal untuk practice session karena lom ada lagi yang bisa dilakukan saat ini. Sekalian foto foto sedikit, hari ini saya bertekad jadi tukang poto aja  :-) Kelar bagiin soal practice, terdengar kabar bahwa soal ketinggalan di ruang jurusan di syahdan dan lagi diambil ama Muhsin. Beberapa menit kemudian terdengar kabar, pintu jurusan ga bisa dibuka karena ga ada orang, dan building management (BM) syahdan lagi enggak ada *jeger*. Gua ikut Su yang udah mau ngeprint semua soal lagi, ampe basement Su coba ke BM anggrek dan ternyata lagi dikunci, orangnya keluar semua. Untungnya bisa ditelp dan katanya pintu jurusan udah berhasil dibuka *fiuh*

*terima kasih kepada saudara Muhsin atas perjuangannya, kontes ini tak akan berlangsung tanpa engkau..

Kembali ke lantai 8 dan mulai technical briefing, ngomongin macem macem tentang kontesnya dari sisi teknis. Disini gua sempet jadi pajangan di depan, enggak jelas buat apa -.- Kelar briefing langsung ke ruangan peserta untuk cek tim notebook. Cuma ada 1 tim yang notebooknya bermasalah, dan yang gua ga expect, itu tim binus >.<

Practice session dimulai, gua ga ikutan judging ama sekali. Gua mondar mandir di ruang peserta, liat liat ada yang bermasalah ato enggak, ngobrol ngobrol dikit sama tim yang kenal, jawabin pertanyaan peserta, dll. Ada yang tanya, kok applet javanya ga keluar? *bingung* karena ini mestinya bagian sistem, karena saya baik hati, saya coba jawab. tapi ternyata solusi gua ga membantu LOL **kabur**. Sampai ke salah satu ruangan, ga ada pertanyaan, ketika gua udah mau pindah ke ruang laen, SiBajuIjoAnehDanTidakGanteng angkat tangan mau tanya, sebelom dia keluarin pertanyaan, gua kacangin kabur ke ruang sebelah😀

Countdown final kontes mulai berjalan, gua masih mondar mandir di ruang peserta. Kira kira tinggal 5 menit, su masuk ruangan, kontes dipending ada masalah. Ternyata, server pc^2 crash **jeger** padahal lom dipake sama sekali, baru upload testcase dan login juri. Kesalahan ditimpakan kepada testcase problem setter yang sinting, total input output untuk semua soal mencapai 50mb (karena ukuran output file yang besar, *salah satunya soal gua, apa cuma soal gua ya?*, maka diputuskan pake pc^2 9.2 beta yang bisa atur output limit) dan juga ukuran RAM pada server yang hanya 2gb (desktop gua aja 4gb).

Setelah berhasil direstart dan tambah max memory untuk jvm,  semua peserta diminta login ke sistem, hasilnya memory jvm bengkak jadi 1.2 gb, padahal udah di set maximum 1.5gb. Juri yakin, akan matot lagi ini pc^2 kalo dipake. Surya cek memory dan server, gua mikir kenapa ini terjadi, dan suhendry ngomel ngomel. Akhirnya diputuskan, deploy 1 pc^2 lagi untuk judging soal yang input nya gede yaitu A,C,D,E. Ketika gua selesai deploy 1 pc^2 lagi (sebut server 2) dan suhendry udah beresin di server 1, kontes langsung start karena udah molor cukup lama dari jadwal. Jadi, untuk soal A,C,D,E yang disubmit peserta ke server 1, akan di re-submit ke server 2 baru di judge🙂 **ini termasuk distributed computing ga ya? :p* *

kanan : server 2 dengan task manager untuk memantau memory JVM| kiri : judge server 1 dan judge server 2

Akhirnya kontes bisa berjalan. Kontes kali ini berjalan cukup pelan, rasanya total submission ratenya ga sampe 2 / menit. Biasanya juri diserbu saat awal dengan submission untuk soal easy / bonus, tapi kali ini submission tetep lambat. Juri udah bosen, suhendry udah tidur, ada yang maen maen, ada yang browsing, ngobrol ngobrol. dan gua kembali ke ruang peserta moto – moto🙂

Tim dongskar attack soal E di saat awal, padahal ini bukan soal yang mudah. Hal ini sepertinya membuat beberapa tim laen mengikuti jejaknya -.-

Pelajaran hari ini : ga semua tim perlu diikutin, terutama yang ga waras macam ini

Pertandingan cukup sadis ketika rank 1 udah solve 6, padahal rank 2 baru solve 3, 2x lipat. Gimana tim tuan rumah? Tim no 1 tuan rumah sempat terdepak ke posisi 4. Saat di posisi 4, bos lab computing udah stres, dia masuk ruangan juri dan bilang “mati dah, dicincang gua”. Untungnya mereka mengamuk di saat freeze, langsung accepted 3 soal🙂 awesome guys!!

tarian kemenangan dari artis jurusan

Ditengah pertandingan yang berjalan lambat, Su kembali tidur, di berbagai tempat dan dengan berbagai gaya.

submission ga di judge

pindah tempat dan ganti gaya

Gua berusaha motoin semua tim yang sedang bertanding. Tapi apa daya beberapa tim berada di tempat yang susah untuk difoto karena terlalu jauh dan gua ga mau ganggu peserta lain cuma karena untuk foto. Jadi yang fotonya ga ada di album, sori anda berada di posisi yang kurang baik.

Di akhir pertandingan, peserta mem-“bom” juri dengan submission. Beberapa submission sih tergolong spam. Ada tim yang ngespam dengan submit 1 source code ke semua soal. Beberapa submission pertama sih gua run, berikutnya cuma view source, langsung reply Wrong answer >:)

spammer!

Btw gua penasaran, butuh berapa menit untuk bikin pattern diatas?

Random Facts

  • Balon bewarna biru tua cuma ada 1 buah, di assign ke soal paling susah, untung ga ada yang solve
Balon keramat yang cuma ada 1 
  •  Solusi soal E awalnya dibuat 1/2 oleh Suhendry, dan 1/2 lagi oleh gua🙂 Tepatnya gua buat bagian suffix arraynya, sisanya Su yang beresin. Gua ga tau dia buat apa, dan dia ga tau gua buat apa. This is what we called teamwork *high five Su*
  • Ada panitia yang komplain ke gua, katanya SiBajuIjoAnehDanTidakGanteng nyolot waktu dikasih tau. LOL

Anyway, congratz buat yang menang🙂 dan buat yang lom menang, selamat berlatih dan coba lagi taon depan.

Foto – Foto

Final Ranklist

Feedback Penyisihan INC 2011

belasan juri dan submitter,  ratusan submission, ribuan klik, diiringi oleh cucuran keringat para juri yang kepanasan, akhirnya kontes selesai….

Hari ini berlangsung penyisihan INC 2011. Ini pertandingan paling panas yang pernah saya liat, juri sampat berkeringat dikarenakan oleh AC yang enggak bener🙂

Tulisan ini saya buat untuk menghilangkan kebingungan peserta (terutama yang baru ikut serta pada kontes pemrograman) terhadap hasil penilaian juri. Banyak peserta mendapatkan run time error dan compile error yang seharusnya bisa dihindari dengan mudah.

Dari banyak submission oleh peserta, banyak yang melakukan kesalahan kesalahan, bahkan beberapa melakukan kesalahan yang telah ditulis di halaman depan web competition (saat akan login), hayoo pada ga baca ya? :p  Biar enggak penasaran, saya akan bahas kesalahan kesalahan yang saya temukan saat pertandingan. Tentu saja saya enggak membaca submission semuanya, hanya kebetulan beberapa yang ketemu aja.

  • C++: gunakan int main(), bukan void main(), perhatikan compiler yang digunakan.
    Compiler yang digunakan adalah mingw (g++) dan tidak menggunakan gcc bahkan untuk file dengan  berextension .c. Jika menggunakan extension file .c dan menggunakan void main akan mendapat compile error. Lucunya, jika keyword “void” dibuang sehingga fungsi utama hanya main() (tanpa tipe kembalian), tidak akan menyebabkan compile error🙂
  • Java: jangan menggunakan package, perhatikan command run di bawah.
    Program dicompile secara otomatis dari current directory dan langsung dieksekusi sesuai perintah yang telah disebutkan. jika menggunakan package akan menyebabkan error, karena file diharapkan berada dalam struktur folder
  • (C/C++) Penggunaan getch()
    getch() yang digunakan di akhir program bisa menyebabkan program tidak berhenti (masih menunggu input dari keyboard), akibatnya program bisa mendapat Time Limit Exceed.
  • (Java) Penggunaan GUI (JPanel, dsb)
    Program harus membaca input dari standard input (stdin) dan mengoutput ke standard output (stdout) yang keduanya ada di console (bukan GUI). Penggunaan GUI bisa menyebabkan program tersebut Time Limit Exceed (juri tidak memberikan input ke GUI yang ditampilkan sehingga program terus menunggu).
    • Penggunaan format string %lld pada integer 64-bit
      Format string yang digunakan untuk tipe data long long atau __int64 (integer 64-bit) di DevC++ adalah %I64d, bukan %lld (DJGPP).

      int main()
       {
       __int64 x;
       scanf( "%I64d", &x );
       printf( "%I64d", x );
       return 0;
       }

      Kesalahan ini tidak menyebabkan program tidak bisa dikompile, namun output yang dicetak oleh program akan tidak sesuai dengan apa yang diinginkan (integer 64 bit).

  • Runtime error pada beberapa program Java
    Hari ini gua nemu beberapa runtime error pada program java, ada yang sampai menelepon mempertanyakan hal ini, padahal di komputernya baik baik saja, kenapa mendapat hasil run time error. Setelah dilakukan penelitian asal asalan yang tidak komprehensif, ditemukan bahwa peserta melakukan beberapa kesalahan seperti :
    • menggunakan fungsi dari class Scanner, yaitu nextInt() padahal dalam inputan disebutkan bahwa inputan dapat mencapai bilangan 64bit, ketika membaca angka yang sangat besar (misal 1000000000000), akan menyebabkan exception.
    • membaca line yang tidak ada
      Salah satu source code peserta yang saya temukan, menggunakan perintah seperti ini
      if (scan.nextLine()!="")

      yang mungkin dimaksudkan untuk mengecek apakah inputan sudah habis, namun ini akan berakibat fatal, yaitu ketika sudah sampai line terakhir dan memanggil perintah diatas, akan menyebabkan runtime error. Solusi yang benar adalah menggunakan fungsi seperti hasNextLine, hasNext, hasNextInt, dsb untuk mengecek apakah masih ada inputan

  • Konstanta terlalu besar untuk suatu tipe data
    Saya menemukan ada yang mengassign tipe data long long pada C++ seperti ini long long x=1000000000000;  Akan mengakibatkan error konstanta terlalu besar, solusinya adalah dengan menambahkan LL di akhir, 1000000000000LL. Jika tidak ditambahkan LL maka akan dianggap sebagai int, karena itu compiler akan mengembalikan pesan error
  • Array index out of bound (c/c++,java)
    kesalahan klasik, mendeklarasikan 100 elemen pada array, namun mengakses elemen di luar indeks 0..99
  • Memanggil fungsi tanpa meng-include header
    Menggunakan fungsi tanpa include header yang tepat, misalnya abs tanpa include stdlib.h. Mungkin peserta menggunakan IDE semacam dev-C++ yang terkadang agak “bego”. Sebagai contoh hanya menginclude iostream dan menggunakan fungsi abs tidak akan menyebabkan compile error jika compile dilakukan dari dalam IDE Dev-C++ namun jika dilakukan dari command line akan menyebabkan compilation error. Rule of thumb : jika bisa dicompile dari cmd, akan bisa dicompile di tempat juri, karena begitulah cara juri melakukan compilation🙂
  • Mengakses variable di luar scope
    Saya menemukan ada peserta yang melakukan hal semacam ini
    for(int j =0;j<n;j++) {
    .....
    }
    if (j .... ) {}
     

    pada code diatas, variable j hanya di deklarasikan dalam scope for, namun diakses di luar for. Compiler c/c++ yang benar akan memberikan compile error untuk kasus seperti ini. Namun sepengetahuan saya, pada compiler visual c++ 6.0 kode diatas adalah legal. Pada visual c++ 6.0 jika dibuat satu lagi block for dan deklarasi variable j di scope for, justru akan memberikan compile error. Dulu saya memakai visual c++ 6.0, ketika submit ke UVA online judge mendapat compile error terus menerus. Setelah mengetahui penyebabnya, saya langsung ganti compiler dan kurang tau lagi dengan visual c++ versi .net

Dari banyak kesalahan yang terjadi pada pengguna bahasa C/C++, kebanyakan disebabkan oleh compiler aneh yang digunakan yang bahasanya tidak standard, seperti borland C++ dengan void main, dan visual C++ 6.0 dengan scoping anehnya. Untuk kontes seperti ini saya sarankan menggunakan compiler mingw. IDE yang dapat digunakan misalnya Dev-C++ atau Code blocks. dev-C++ sudah lama terhenti developmentnya sehingga compiler yang disertakan sudah obsolete yaitu gcc versi 3. Namun bisa saja menggunakan dev-C++ dengan mingw versi terbaru.

Demikian kesalahan yang saya temukan pada kontes kali ini, kalo ada yang ga jelas, feel free to ask🙂 Semoga apa yang saya tulis diatas bisa menghilangkan rasa penasaran kenapa dapet compile error / run time error. Dan juga mencegah peserta maki maki juri karena juri dianggep ga jelas🙂 (cth makian : wah ditempat saya jalan, kok submit error, juri brengsek!).

Buat peserta yang baru pertama kali ikut dan belum berhasil, silahkan berlatih dan mencoba lagi tahun depan🙂 Goodluck buat yang ke final, sampai ketemu!.

Note : kalo ada yang mau complain soalnya susah susah, silahkan hubungin saudara Suhendry Effendy, selaku orang yang bertanggung jawab.

Kontes Pemrograman

Sejak tahun 2007, gua mulai terlibat sebagai problem setter dan juga juri untuk lomba pemrograman tingkat SMA yang setiap tahun rutin diselenggarakan kampus gua. Dari sini gua belajar, problem setter itu work as a team.

Setiap soal yang diperlombakan harus memiliki deskripsi dan batasan yang jelas. Tentu saja testdata yang digunakan juri untuk menilai juga harus menyentuh batasan ini. Tidak masuk akal jika di soal ditulis N <= 1000 tetapi testdata hanya mengetes sampai 10, tentu saja akan ada algoritma yang berbeda untuk batasan yang berbeda. Tidak perlu memikirkan algoritma yang lebih efisien jika ada algoritma yang lebih sederhana untuk menyelesaikan suatu masalah. Testdata juga harus mengetes kasus kasus khusus, kasus sangat kecil dan juga kasus sangat besar. Intinya disamping testdata untuk mengetes kecepatan algoritma yang digunakan oleh peserta, harus juga mengetes dengan testdata yang memiliki karakteristik “berbeda”.

Selain masalah teknis seperti komputer, sistem grader, dll, tingkat kesulitan soal merupakan suatu hal penting dalam suatu kontes. Dengan asumsi bahwa sistem berjalan lancar dan semua prosedur diketahui peserta dengan baik, tingkat kesulitan soal menjadi penentu bagaimana “asik” nya suatu kontes bagi para peserta. Untuk melihat distribusi kesulitan soal, tidak cuma diliat per soal, tapi keseluruhan set soal yang diperlombakan. Soal yang diperlombakan sebaiknya memiliki tingkat kesulitan yang baik dan juga tidak condong ke suatu teknik algoritma tertentu, melainkan mencakup berbagai macam algoritma.

Beberapa orang cenderung ngebuat soal yang susah untuk peserta, hal ini bagus, tapi jangan terlalu berlebihan. Tingkat kesulitan soal yang diperlombakan kira kira baiknya memiliki kurva distribusi normal. Dari pertama gua mulai jadi problem setter, Suhendry pernah bilang kira kira gini, “kontes yang baik itu :

  • tiap peserta solve minimal 1 soal
  • tidak ada peserta yang solve semua soal
  • semua soal di solve minimal oleh 1 tim

Enggak tau dia belajar dari mana, tapi kata – katanya make sense. Selama gua bantu arrange kontes di Binus, judge selalu mikirin tingkat kesulitannya, biasanya Suhendry bakal jadi penyeimbang kalo terlalu banyak soal yang susah, dia bakal bikin soal gampang atau malah soal bonus. Meskipun dalam setiap kontes ga selalu ketiga guideline diatas bisa dipenuhi, intinya adalah harus seimbang tingkat kesulitan soal – soal yang diperlombakan, jangan sampai semua soal terlalu susah sehingga ga ada yang solve dan juga jangan terlalu gampang.

Mengeluarkan set soal yang terlalu sulit semua sehingga peserta tidak bisa solve, tidak akan membuat anda merasa keren, melainkan akan menuai makian dari peserta. Selain itu membuat soal yang terlalu sulit semua rasanya tidak akan memicu peserta untuk menyelesaikan soal itu setelah perlombaan berakhir. Pengalaman mengatakan, soal yang terlalu sulit atau terlalu mudah tidak akan mengajarkan apapun. Shahriar Manzoor, seorang judge World Final ACM ICPC pernah berkomentar tentang hasil suatu kontes regional. Soal di kontes itu tidak jelas deskripsi dan batasannya, namun ada yang menyebut itu “decent” kontes.

Ahem!

A decent problemset do not have some ranges unspecified, or ranges not specified in the input specification (rather than hidden in the problem statement).

A decent problemset and the easiest problems not solved? then how can it be decent?

I have respect to all the teams that has done well in this problemset but don’t call a problemset decent just because u have done well. Many other teams might have ruined their contest on those easy problems (assuming that D and E was not solved).

Meskipun selalu berpegang pada guideline diatas, pernah juga terjadi kontes yang menurut gua kurang baik. Misalnya ada peserta solve semua soal sebelum waktu kelar, terlalu banyak soal menggunakan sorting dalam satu set soal. Hal ini pernah terjadi sebelumnya, dan kita belajar untuk tidak mengulangi hal ini lagi.

Dalam beberapa tahun terakhir ini, makin banyak kontes pemrograman di Indonesia yang umumnya diselenggarakan oleh institusi perguruan tinggi. Hal ini bagus, membuat popularitas kompetisi pemrograman meningkat dan juga membuat iklim kompetisi yang semakin kompetitif. Berita buruknya beberapa kontes masih kurang baik kualitasnya, dan tidak ada peningkatan setelah beberapa tahun.

Salah satu yang cukup banyak terjadi adalah “recycle soal”, yaitu mengambil soal dari internet dan dipakai sebagai soal di kontes pemrograman. Selama gua jadi problem setter hal ini sebisa mungkin dihindari. Namun terkadang soal yang memang orisinil dari pembuatnya, secara tidak sengaja bisa ditemukan di online judge. Gua pernah buat soal untuk BNPC-HS, dan setelah soal approved, gua secara ga sengaja menemukan soal yang sama di lebih dari 1 online judge. Tapi tetep, itu soal masih buatan gua, kebetulan aja sama.