Interview Review: সাধারণ ভুল ও মূল্যায়নের মানদণ্ড
Common Mistakes and Evaluation Rubric
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Self-review rubric দিয়ে evidence দেখা
- Communication ও correctness আলাদা assess করা
- পরের practice-এর ছোট improvement লক্ষ্য রাখা
সমস্যা দিয়ে শুরু
Mock শেষে candidate মনে করেন সব technology বলেছেন, তাই ভালো হয়েছে। Listener request flow বুঝতেই পারেননি। আরেক candidate কম box এঁকেও race এবং recovery পরিষ্কার করেছেন। Self-review-এ confidence বা buzzword count নয়, observable evidence দরকার। নিচের rubric এই guide-এর learning exercise; কোনো কোম্পানির official hiring threshold বা guaranteed outcome নয়।
সহজ করে বুঝি
ছয় dimension নিন: requirement clarity, grounded estimates, coherent HLD, data/API correctness, failure/trade-off reasoning এবং communication। প্রতিটিতে weak, developing, solid evidence লিখুন; score থাকলে পাশে example রাখুন। Good diagram-এর প্রতিটি important arrow explain হয়। Correctness-এ ownership, unique constraints, concurrency এবং unknown side effect outcome অন্তর্ভুক্ত। Weak area-তে next practice targeted করুন, পুরো syllabus একসঙ্গে আবার পড়া নয়।
পরিচিত একটি উপমা
সাঁতার শেখার feedback শুধু ভালো ছিল নয়; breathing, stroke এবং turn আলাদা দেখে coach অনুশীলন দেন। একইভাবে system design practice-এর specific evidence progress দেখায়। সুন্দর handwriting ভুল stroke ঠিক করে না।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR M[Recorded mock response] --> E[Collect observable evidence] E --> R[Review six dimensions] R --> G[Choose one or two gaps] G --> P[Targeted practice] P --> N[Repeat comparable mock] N --> C[Compare improvement]
Recording বা notes থেকে quote ও diagram decision সংগ্রহ করুন। Rubric dimension-এ evidence বসান। Critical invariant ভুল হলে polish-এর score দিয়ে compensate করবেন না। এক বা দুই gap বেছে ছোট exercise দিন। Comparable second mock-এ improvement দেখুন। Different prompt-এর difficulty ভিন্ন, তাই raw total score-কে scientific benchmark ভাববেন না।
PHP ও Laravel-এ প্রয়োগ
PHP self-review aggregation fragment; input integers ০–২ scale-এর subjective learning notes। এটি website quiz grading বা hiring score নয়। Evidence text আলাদা document-এ লিখবেন। Minimum-এর dimension আগে practice বেছে নিতে পারে; equal weighted sum critical security error আড়াল করতে পারে বলে total score-এ ভরসা করা হয়নি।
$review = [
'requirements' => 2,
'estimates' => 1,
'architecture' => 2,
'correctness' => 0,
'failure_reasoning' => 1,
'communication' => 2,
];
$lowest = min($review);
$practiceNext = array_keys($review, $lowest, true);সুবিধা, সীমাবদ্ধতা ও trade-off
Rubric consistent feedback দেয়, কিন্তু false precision তৈরি করতে পারে। Same score ভিন্ন weakness লুকায়। Peer reviewer নিজের preferred technology-কে universal মানদণ্ড বানাতে পারেন; requirement-based evidence চাইুন। Communication fluency technical correctness-এর বিকল্প নয়, আবার correct design unspoken থাকলেও listener assess করতে পারেন না। Both dimensions explicit রাখুন।
সাধারণ ভুল
- Buzzword সংখ্যা দিয়ে design quality মাপা।
- Feedback-এ নির্দিষ্ট example না রাখা।
- এক mock-এর score দিয়ে interview outcome predict করা।
আরও একটু গভীরে
Critical red flags যেমন unauthorized data path, double charge বা impossible durability claim আগে fix করুন। Then coherence: actor থেকে response পর্যন্ত flow, data ownership এবং recovery। Calculation error unitসহ correct করুন। Feedback receiving-এ defensiveness কমিয়ে assumption কোথায় আলাদা ছিল জিজ্ঞেস করুন। Practice log-এ date, prompt, constraints ও targeted gap রাখলে repeated weakness দেখা যায়।
মনে রাখুন
Self-review evidence-ভিত্তিক হলে useful; requirement, invariant, failure reasoning ও communication আলাদাভাবে উন্নত করুন।
নিজে চেষ্টা করুন
একটি পুরোনো mock শুনে ছয় dimension-এ একটি evidence দিন। সর্বনিম্ন area-এর জন্য ১৫ মিনিটের exercise লিখুন। আবার mock নিয়ে specific change হয়েছে কি না তুলনা করুন; শুধু total score বাড়ল কি না নয়।
নিজের বোঝা যাচাই করুন
1. Rubric official hiring score?
না। এটি original learning tool। Employer criteria ও conversation context ভিন্ন হতে পারে।
2. Score-এর সঙ্গে evidence কেন?
Subjective number কী বোঝায় স্পষ্ট হয়। Concrete mistake এবং correction অনুশীলনযোগ্য হয়।
3. Security flaw total-এ ঢাকব?
না। Critical invariant violation আলাদা priority। Average polish correctness breach সমাধান করে না।
4. কম technology মানেই দুর্বল?
না। Requirements পূরণে simple coherent design ভালো হতে পারে। Complexity justified কি না দেখুন।
5. Next practice কীভাবে?
এক বা দুই concrete gap বেছে measurable exercise করুন। Comparable mock-এ improvement evidence নিন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।