ဖြေခဲ့သမျှ အလုပ်အင်တာဗျူးများ — ၃
The dark side of developer interviews
Local မှာတုန်းကတော့ competition နည်းတာရယ်၊ resume ကြည့်တာနဲ့ ဒီလူရဲ့ career ကို အလွယ်တကူခန့်မှန်းလို့ရတာရယ်ကြောင့် အလုပ်လျှောက်ရတာ အရမ်းကြီးမခက်ဘူး။ နောက်ဆုံး ကိုယ့် skill set နဲ့ less than 50% လောက်ပဲ match ဖြစ်တောင် အဆင်ပြေအောင်ဖြေတက်ရင် အလုပ်ရတာပဲ။
အခု နိုင်ငံခြားကိုအလုပ်ထွက်ရှာမှ Interview ပေါင်းစုံကြုံရပြီး အလင်းလည်းတော်တော်ပွင့်သွားတယ်။ Vacancy တစ်ခုပေါ်တာနဲ့ နိုင်ငံစုံပတ်နေတဲ့ အဖြူတွေရော၊ local တွေရော၊ Asian က ကောင်တွေရော စုံပလုံစိပြီး ဝိုင်းလျှောက်ကြတာ competitor တော်တော်များတယ်။
လာလျှောက်တဲ့သူများတော့ သူတို့ interview process တွေကိုလည်း ဒီမှာလိုလျော့တိလျော့ရဲ မဟုတ်ပဲ သေချာပြင်ဆင်ထားတာကိုလည်း သတိထားမိတယ်။ ဒါပေမယ့် တစ်ချို့ process တွေ ကျတော့လည်း create သာလုပ်ပြီး update မလုပ်ဘူးထင်ပါတယ်။ လက်တွေ့မကျတာတွေ၊ candidate ကို မလိုတဲ့ pressure ပိစေတာတွေစသည် အချိုးမပြေတာတွေလည်း ရှိတယ်။
အခု Article မှာက ကိုယ်ကြုံဖူးတဲ့ လွဲချော်နေတဲ့ process တွေအကြောင်းကို ရေးသွားမှာပါ။
1. Early Code Test
Shortlisted candidates တွေကို initial call ပြီးတာနဲ့ code test တန်းပို့တဲ့ အုပ်စုက သက်သက်ကိုရှိတယ်။ HackerRank နဲ့ Codility ဆိုရင်လည်းထားတော့၊ ဖြေရတာပျော်ဖို့တောင် ကောင်းသေးတယ်။ တစ်ချို့လည်း live code test စစ်တာမျိုးရှိတယ်၊ အဲတာလည်းအဆင်ပြေတယ်။ Their focus is on you. If you perform well, you’ll advance to the next round.
အခုဟာက ဖြူလားမဲလားမသိတဲ့ candidate ကို ရက်နဲ့ချီကြာမယ့် code test တွေလာပို့၊ ပြီးတော့ assignment တင်ပြီးတောင် ရေးထားတဲ့ code တွေ သေချာမှဖတ်ရဲ့လား၊ ငါ email မှာပြောထားတဲ့ highlight တွေမှ ကြည့်ရဲ့လားစသည် အစွမ်းကုန်ကြိုးစားထားတောင်မှ ခေါ်မခေါ် မသေချာတဲ့ ကိစ္စကြီးပါ။
အမှန်က interview procss တစ်ခုမှာ face to face အဆင့်တွေအကုန်ပြီးပြီ။ ဒီလူရဲ့career, personality, language & technical skills တွေကို သဘောပေါက်ပြီ။ ကိုယ့် team နဲ့ compatible ဖြစ်နိုင်လားဆိုလည်းသိပြီ။ သူ့တောင်းဆိုတဲ့ demand တွေကိုလည်း ယေဘုယျအားဖြင့် ဖြည့်ပေးနိုင်တယ်၊ နောက်ဆုံး ဒီလူကိုခန့်ဖို့ 70–80% လောက်သေချာနေပြီ။ အဲတော့မှ ဒီလူကတကယ် အရည်အချင်းရှိလားသိအောင် code test ပေးမယ်ဆိုတာမျိုးပဲ ဖြစ်သင့်တယ်။
2. CS မေးခွန်းတွေနဲ့ ပညာပြမယ်
Developer တစ်ယောက်က CS knowledge ရှိသင့်တာမှန်တယ်။ Interviewer က စိတ်ပါရင် မေးခွင့်လည်းရှိတယ်၊ ဒါပေမယ့်တော်ရုံပဲကောင်းတယ်။ ကိုယ်က language အသစ်ထွင်မှာလည်းမဟုတ်၊ data compression algorithm တွေ compiler & interpreter တွေရေးမှာလည်း မဟုတ်၊ လုပ်ငန်းခွင်မှာသုံးမယ့် B2B, B2C, B2G customized software တွေရေးမှာ။
ဥပမာ client ဆီမှာ core system တစ်ခုရှိတယ်၊ အဲမှာ data အကုန်သိမ်းထားတယ်ဆိုပါတော့။ ကိုယ့် system က အဲဒိက data ကို consume လုပ်ပြီး business logic တွေ run မယ်။ ဒါဆိုရင် ကိုယ့်ဆီမှာ table row တစ်ခု update ဖြစ်သွားတိုင်း ဘယ်လိုနည်းလမ်းနဲ့ core system မှာ update သွားလုပ်ကြမလဲပေါ့။
- Database ကို direct access လုပ်ပြီး query run မလား
- Core system မှာ endpoints ရေးပြီး API ခေါ်မလား
- ကိုယ့် system မှာ temp database or cache server ဆောက်ပြီး core database နဲ့ data replication လုပ်မလား
- ပြီးတော့ update ဖြစ်တိုင်း ချက်ခြင်း run မှာလား၊ queue ထဲထည့်ပြီး background script နဲ့ သွားမှာလား၊ cron job သုံးပြီး timer နဲ့ bulk update လုပ်မှာလား
- နောက်ဘယ်လိုနည်းလမ်းတွေနဲ့ update လုပ်လို့ရသေးလည်းပေါ့၊ ဘယ်အခြေမှာ ဘယ်ဟာကအကောင်းဆုံးဖြစ်မလဲ စသည်
Hash Table ဘာလဲ၊ Binary Tree အကြောင်းပြောပြဆိုတာမျိုးထက် အဲလို complex business flow တစ်ခုချပြပြီး candidate ရဲ့ solution ထုတ်ပုံကို အကဲခတ်တာမျိုး ပိုမေးသင့်တယ်။ Backend Developer ဆိုရင်လည်း ERD diagram တစ်ခုထုတ်ပြပြီး လက်ရှိ design ကိုဝေဖန်ခိုင်းတာမျိုး၊ ပိုကောင်းတဲ့ဟာပြောင်းဆွဲခိုင်းတာမျိုးပေါ့။
3. ၁မိနစ် မေးခွန်းများ
တစ်ချို့ကျတော့ ကြိုရေးထားပြီးသား program တွေချပြတယ်။ ဘာရေးထားလဲမေးပြီး ဘာ output ထွက်မလဲဆိုတာ မိနစ်ပိုင်းအတွင်းဖြေခိုင်းတယ်။ Reference လုပ်ခွင့်မရှိဘူး။ အဲတာမျိုးတွေ ၈ — ၁၀ ပုဒ်လောက် ဆက်တိုက်မေးသွားတယ်။
အဲတာမျိုးကျတော့ ကျောင်းက စာမေးပွဲတွေ သွားသတိရတယ်။ ဖတ်စာအုပ်က စာမျက်နှာ ၁၀၀၀ ရှိတယ်၊ ကိုယ်က စာမျက်နှာ ၅၀ ကျက်ထားတယ်။ မေးခွန်းတိုးခဲ့ရင် အောင်မယ်၊ လွဲရင်ကျမယ်။ အခုလည်း language တစ်ခုဆိုတာက အကျယ်ကြီးပဲ၊ ကိုယ်လုပ်ဖူးတာနဲ့တိုးရင် ဖြေနိုင်မယ်၊ မဟုတ်ရင်ဂျောင်းဆိုတဲ့ သဘောမျိုးဖြစ်နေတယ်။ ကိုယ်တိုင်က web platform specialized ဆိုတော့ ပိုဆိုးတယ်၊ နည်းတဲ့ languages, frameworks, CMS, libraries တွေလား။
တကယ့်လုပ်ငန်းခွင်မှာဆို basic for loop လေးတောင် မေ့နေလို့ google ခေါက်ရတာတွေလည်း ခဏခဏပဲ။ ဆိုတော့ interview ဆိုပေမယ့် မလွန်လွန်းဘူးလား။
4. Language မသိလို့ မခန့်ဘူး
Industry ထဲက လေ့လာစရာတွေက သမုဒ္ဒရာတစ်ခုဆိုရင် developer တွေ သိထားတဲ့ knowledge ဆိုတာက အဲပေါ်မှာမျောနေတဲ့ လှေလေးတွေလိုပဲ။ ပြီးတော့ developer အများစုသည် လုပ်ငန်းခွင်ထဲမှာပဲ လုပ်ရင်းလေ့လာရင်းနဲ့ သိလာကြတဲ့သူ အများစု။ အားတဲ့အချိန်မှာ လေ့လာထားတယ်ဆိုတောင် လက်တွေ့ project မရေးကြည့်ပဲနဲ့ language တစ်ခုကို ဘယ်လိုမှ master မဖြစ်နိုင်ဘူး။
တစ်ချို့ကုမ္ပဏီတွေက ဘယ်လိုလဲဆိုတော့ JD အကုန်တူတယ်၊ တစ်ချို့ language or framework လေးပဲ ကိုယ်မရတာပါသွားတယ်။ အဲတော့ ငါတို့ဟာကို မသိလို့ မခန့်နိုင်ပါဘူးလို့ ထလုပ်ရော။ Web design ပဲရတဲ့သူက AI သွားလျှောက်တာမျိုးဆိုလည်း ထားပါတော့၊ အဲလိုမဟုတ်တဲ့ဟာတွေ လိုက်ကြည့်ကြတာလည်း ဆိုးတယ်။
5. Lack of team-based assessments
ဒါကတော့ ဝေဖန်တာထက် ဖြစ်စေချင်တာလို့ပဲပြောရမလား။ Take home code test တွေကို လုံးဝမကြိုက်ဘူး။ အချိန်လဲအရမ်းကုန်သလို ဒီ product တစ်ခုရလာဖို့ ကိုယ်ချဥ်းကပ်ခဲ့တဲ့၊ စဥ်းစားခဲ့ရတဲ့အပိုင်းတွေကို ဘယ်သူမှမမြင်နိုင်လို့။ HackerRank နဲ့ Codility လည်း မကြိုက်ဘူး၊ employer ဘက်က real-world project development နဲ့ puzzle နဲ့ ကွဲဖို့တော့ လိုတာပေါ့။
ဖြစ်သင့်တာက မီတာခတွက်တဲ့ app လေးပဲထားပါတော့၊ အဲဒိမှာ feature အသစ်တွေထည့်မယ်၊ code refractor လုပ်မယ်၊ unit test တွေရေးမယ်။ Candidate နဲ့ tech team ဘက်က developer တွေလာပြီး pair programming ပုံစံမျိုး live code test စစ်မယ်၊ အဲဒါကို decision maker ဖြစ်တဲ့ team lead or PM ကနေ ထိုင်ကြည့်နေမယ်။ အဲဒိမှာဆို candidate ရဲ့ technical & non-technical skill sets တွေအပြင် team compatibility ပါ တစ်ခါတည်း တန်းပေါ်ပြီ။
