৪৫ মিনিটের System Design Interview Framework
45-Minute Design Framework
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Timebox ব্যবহার করে coherent design বলা
- HLD এবং deep dive-এর সময় balance করা
- শেষে limitation ও validation summarize করা
সমস্যা দিয়ে শুরু
Candidate database indexing নিয়ে বিশ মিনিট বললেন, কিন্তু request কোথা থেকে কোথায় যায় তা আঁকা হয়নি। আরেক candidate সব box আঁকলেন, কোনো bottleneck বোঝালেন না। সীমিত interview time-এ breadth ও depth-এর ভারসাম্য দরকার। এই ৪৫ মিনিটের framework একটি flexible rehearsal tool, universal interview rule নয়। Interviewer-এর প্রশ্ন ও problem complexity অনুযায়ী সময় বদলাতে হবে।
সহজ করে বুঝি
প্রস্তাবিত rehearsal: প্রথম পাঁচ মিনিট clarification, পরের পাঁচ estimate ও invariants, দশ মিনিট API/data/HLD, পনের মিনিট এক বা দুই deep dive, শেষ দশ failure/security/recap। কিছু ধাপ overlap করে। প্রতিটি transition-এ এখন কী সিদ্ধান্ত হলো এবং পরের unknown কী বলুন। Timebox goal coherent reasoning; stopwatch-এর জন্য গুরুত্বপূর্ণ correctness প্রশ্ন কাটবেন না।
পরিচিত একটি উপমা
ভ্রমণের itinerary-তে প্রধান destination এবং return time থাকে। Traffic বদলালে ছোট stop বাদ যায়, কিন্তু destination-এর নাম না জানিয়ে সারাদিন একটি দোকানে থাকা ঠিক নয়। Interview structureও পথ দেখায়, conversation থামায় না।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR C[Clarify] --> E[Estimate and invariants] E --> H[API data and HLD] H --> D[Targeted deep dive] D --> F[Failure and security] F --> R[Recap decisions and limits] D -.-> H
Clarification requirements বেঁধে দেয়। Estimate scale-sensitive অংশ চিহ্নিত করে। HLD একটি end-to-end flow দেখায়। Deep dive সেই flow-এর high-risk অংশে যায়। Failure আলোচনা নতুন box যোগ করার বদলে existing arrow ভেঙে দেখে। Recap current choices ও unresolved trade-off প্রকাশ করে। নতুন information এলে HLD-তে ফিরে design বদলানো স্বাভাবিক।
PHP ও Laravel-এ প্রয়োগ
PHP rehearsal timer-এর illustrative fragment; এটি website feature নয়, নিজের অনুশীলনের allocation হিসাব। Actual interview-এ framework follow করার অনুমতি ও সময় interviewer-এর নির্দেশে হবে। Laravel console command-এ একই associative array ব্যবহার করে section elapsed time লিখে রাখতে পারেন; কোনো employer performance benchmark নয়।
$minutes = [
'clarify' => 5,
'estimate' => 5,
'high_level' => 10,
'deep_dive' => 15,
'failure_and_recap' => 10,
];
$total = array_sum($minutes);
if ($total !== 45) {
throw new \LogicException('Practice allocation must total 45 minutes');
}সুবিধা, সীমাবদ্ধতা ও trade-off
Structure anxiety কমাতে পারে, কিন্তু rigid script follow করলে interviewer-এর hint উপেক্ষা হতে পারে। Numbers-এর arithmetic খুব দীর্ঘ করলে design আলোচনা কমে। Broad HLD quickly trust তৈরি করে; deep dive correctness দেখায়। Resume-এ পরিচিত technology টেনে আনার বদলে problem অনুযায়ী unfamiliar alternative-এর trade-off language-neutralভাবে বলতেও পারা দরকার।
সাধারণ ভুল
- প্রতিটি box-এর internal detail একসঙ্গে খুলে ফেলা।
- সময় শেষ হওয়ার আগে failure এবং recap-এর জন্য কিছু না রাখা।
- Interviewer direction বদলালেও memorized script চালানো।
আরও একটু গভীরে
একটি decision ledger নিন: requirement, selected approach, rejected alternative ও failure behavior। এটি recap-এ সাহায্য করে। Pause নিয়ে diagram-এর arrow explain করুন; silent drawing conversation কঠিন করে। অনুমান correction পেলে error acknowledge করে downstream calculation বদলান। শেষের limitation statement design incomplete ঢাকার জন্য নয়; deliberate boundary এবং next validation step স্পষ্ট করার জন্য।
মনে রাখুন
Flexible timebox breadth, concrete deep dive এবং honest recap নিশ্চিত করতে সাহায্য করে; reasoning conversation-এর কেন্দ্রেই থাকবে।
নিজে চেষ্টা করুন
URL shortener নিয়ে ৪৫ মিনিট mock করুন। প্রতিটি section আসলে কত সময় নিল লিখুন। HLD না বোঝা friend-কে recording দেখিয়ে জিজ্ঞেস করুন main request flow তারা বলতে পারেন কি না; feedback অনুযায়ী second attempt বদলান।
নিজের বোঝা যাচাই করুন
1. Framework মুখস্থ বলব?
Flow মনে রাখতে পারেন, কিন্তু answer problem-specific হবে। Interviewer-এর নতুন requirement অনুযায়ী adapt করুন।
2. Estimate পাঁচ মিনিটই?
এটি rehearsal suggestion। Problem-এ capacity central হলে বেশি সময়, অন্য ক্ষেত্রে কম লাগতে পারে।
3. Deep dive কয়টি?
সময় ও scope অনুযায়ী এক বা দুই high-risk area যথেষ্ট হতে পারে। বহু superficial detail-এর চেয়ে grounded analysis ভালো।
4. Recap কী বলবে?
Core choices, কেন, strongest invariant, প্রধান limitation এবং next validation। পুরো conversation পুনরাবৃত্তি নয়।
5. ভুল calculation হলে?
সংশোধন করে dependent conclusion update করুন। Assumption ও unit স্পষ্ট থাকলে correction সহজ হয়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।