রিমোট জব প্রিপারেশন — পর্ব ১১: টেক-হোম অ্যাসাইনমেন্ট

রিমোট লুপে টেক-হোম সবচেয়ে সাধারণ, আর তোমার জন্য সবচেয়ে বড় সুযোগ — কতটা সময় দেবে, কতটা বানাবে, README-তে কী লিখবে, রিভিউ কলে কীভাবে ডিফেন্ড করবে, আর কোন অ্যাসাইনমেন্ট ভদ্রভাবে ফিরিয়ে দেবে।

---

দুইটা জমা, একই সমস্যা

কাজটা ছিল: একটা CSV থেকে অর্ডার পড়ে সেগুলো একটা API-তে দেখানো, “৩–৪ ঘণ্টার কাজ”।

আল-কিন্দি তিন দিন লাগাল। সে React-এর একটা ফ্রন্টএন্ড বানাল, ডকার কম্পোজে PostgreSQL আর Redis দাঁড় করাল, JWT অথেনটিকেশন যোগ করল, একটা অ্যাডমিন প্যানেল, আর CI পাইপলাইন। README-তে লেখা: “How to run”।

ফাতিমা সাড়ে তিন ঘণ্টা দিল। একটা ছোট সার্ভিস, ইন-মেমরি স্টোর, পরিষ্কার লেয়ারিং, ছয়টা টেস্ট। README-তে তিনটা অনুচ্ছেদ: কী ধরে নিয়েছি, কী ইচ্ছাকৃতভাবে বাদ দিয়েছি (ও কেন), আর প্রোডাকশনে গেলে পরের তিনটা কাজ কী হতো।

রিভিউয়ার আল-কিন্দির জমাটা দেখে বলল — “কাজ করে, কিন্তু আমি জানি না এই লোকটা আমাদের কোডবেসে কী করবে।” ফাতিমারটা দেখে বলল — “এই লোকটা জানে কোথায় থামতে হয়।”

টেক-হোম বানানোর পরীক্ষা না, স্কোপ নিয়ন্ত্রণের পরীক্ষা। পর্ব ১-এর হায়ারিং ম্যানেজারের সবচেয়ে বড় ভয়টা মনে করো: “অপ্রয়োজনে জটিলতা আনবে না তো?” এই একটা জমা সেই ভয়টা হয় দূর করে, নয় নিশ্চিত করে।

---

১. কেন রিমোট লুপে এটা এত সাধারণ — আর কেন এটা তোমার সুবিধা

লাইভ কোডিং রাউন্ডে টাইমজোন একটা বাস্তব সমস্যা: তোমার রাত ১১টায় ৪৫ মিনিটের চাপ। টেক-হোমে সেই সমস্যা নেই — তুমি নিজের সময়ে, নিজের যন্ত্রে, নিজের মতো কাজ করছ।

আর সেখানেই তোমার সুবিধা:

• তোমার ছয় বছরের অভ্যাস দেখানোর জায়গা — টেস্ট, স্ট্রাকচার, নামকরণ, ত্রুটি সামলানো। LeetCode-এ এসব দেখানোর সুযোগ নেই।
• ইংরেজিতে লেখার প্রমাণ — README আর কমিট বার্তা মিলিয়ে (পর্ব ৭-এর ঝুঁকি ২-এর সরাসরি উত্তর)।
• অ্যাকসেন্ট, স্নায়ু বা ইন্টারনেট কোনো ভূমিকা রাখে না।

তাই টেক-হোম পেলে সেটাকে বোঝা না ভেবে সুযোগ ভাবো — কিন্তু সময়ের সীমা মেনে।

---

২. “৪ ঘণ্টা” মানে কী

কোম্পানি সময় বলে দেয় দুটো কারণে: তুলনা করার একটা সমান ভিত্তি, আর তোমার সময়ের প্রতি সম্মান। তুমি যদি তিন দিন দাও, তুমি ওই দুটোই ভাঙলে — আর তুলনায় তোমার জমা অন্যায্যভাবে বড় হয়ে যায়, যেটা রিভিউয়ার প্রায়ই ধরে ফেলে।

কাজের নিয়ম:

• বলা সময়ের ১–১.৫ গুণ দাও, তার বেশি না। ৪ ঘণ্টা বললে ৪–৬ ঘণ্টা।
• সময় শেষ হলে থামো, আর যা বাকি রইল সেটা লিখে দাও। “I stopped at the four-hour mark; the next things I’d add are X, Y, Z” — এই বাক্যটা প্রায় সবসময় ইতিবাচকভাবে পড়া হয়।
• সময়টা সৎভাবে বলো। বাড়িয়ে বা কমিয়ে বলার দরকার নেই; কমিয়ে বললে পরে ধরা পড়ার ঝুঁকি।

---

৩. কী বানাবে, কী বানাবে না

বানাবে — যা স্পষ্টভাবে চাওয়া হয়েছে, ভালোভাবে:

• মূল ব্যবসায়িক যুক্তিটা পরিষ্কার, আলাদা করা, পরীক্ষাযোগ্য
• ইনপুট ভ্যালিডেশন আর বোধগম্য ত্রুটি বার্তা
• কয়েকটা অর্থবহ টেস্ট (নিচে আলাদা করে)
• চালানোর সহজ উপায় — একটা কমান্ড হলে সবচেয়ে ভালো
• README, যেটাই আসল জমা (নিচে আলাদা করে)

বানাবে না — যা চাওয়া হয়নি:

• অথেনটিকেশন, ইউজার ম্যানেজমেন্ট, রোল-ভিত্তিক অনুমতি
• ফ্রন্টএন্ড, যদি না চাওয়া হয়
• ডকার/কুবেরনেটিস সেটআপ, যদি না চাওয়া হয় (একটা docker compose চালানোর সুবিধার জন্য দিলে ঠিক আছে, কিন্তু ওটাই প্রধান কাজ না)
• আসল ডেটাবেস, যদি ইন-মেমরিতেই সমস্যাটা দেখানো যায় — তবে লেয়ারিংটা এমন রাখো যাতে বদলানো সহজ, আর সেটা README-তে বলো
• মাইক্রোসার্ভিস, ইভেন্ট বাস, ক্যাশ — চার ঘণ্টার কাজে এগুলো লাল পতাকা

যা বাদ দিচ্ছ, তা নীরবে বাদ দিয়ো না — README-তে এক লাইনে বলো কেন। বাদ দেওয়ার কারণ লেখাটাই সিনিয়রিটির সংকেত; নীরবতা অজ্ঞতার মতো পড়ায়।

---

৪. README — আসল জমাটা এখানেই

রিভিউয়ার তোমার কোড পড়ার আগে README পড়ে, আর অনেক সময় README পড়েই ঠিক করে ফেলে কতটা মনোযোগ দিয়ে কোড পড়বে।

একটা কাঠামো, পাঁচটা ব্লকে:

What this does — দুই লাইন।

How to run — একটা কমান্ড, আর টেস্ট চালানোর কমান্ড। কোনো অনুমান ছাড়া।

Assumptions — যেসব জায়গায় স্পেসিফিকেশন অস্পষ্ট ছিল, তুমি কী ধরে নিয়েছ। ৩–৫টা বুলেট।

Design decisions & tradeoffs — মূল ২–৩টা সিদ্ধান্ত, প্রতিটার বিকল্প আর কেন এটা বাছলে।

What I left out and why — সীমিত সময়ে কী বাদ দিয়েছ, আর প্রোডাকশনে গেলে পরের তিনটা কাজ কী।

শেষ দুটো ব্লকই তোমাকে বাকিদের থেকে আলাদা করবে, কারণ প্রায় কেউ লেখে না। উদাহরণ:

Assumptions

• Order IDs are unique within a file but may repeat across files, so dedupe is scoped per import run.
• Malformed rows should not abort the whole import — they’re collected and reported at the end.
• Currency is always USD; no FX handling.

Tradeoffs

• In-memory repository behind an interface rather than a database. The import logic is what’s being tested, and swapping in Postgres is a one-file change — I’d rather you read the logic than my migrations.
• No retry/backoff on the outbound call. In production this needs it, but here it would add config and timing complexity without showing anything new.

লক্ষ করো ভাষাটা: সিদ্ধান্ত, কারণ, আর প্রোডাকশনের বাস্তবতার স্বীকৃতি — অজুহাত না।

---

৫. টেস্ট — কতটা যথেষ্ট

শূন্য টেস্ট প্রায় সবসময়ই বাদ পড়ার কারণ। ১০০% কভারেজ সময়ের অপচয়, আর সেটাও একটা খারাপ সংকেত (স্কোপ নিয়ন্ত্রণের অভাব)।

লক্ষ্য: ৫–১০টা টেস্ট যেগুলো সিগন্যাল দেয় —

• মূল সুখী পথ (happy path), একটা
• দুই-তিনটা এজ কেস: খালি ইনপুট, ভাঙা সারি, ডুপ্লিকেট
• একটা ত্রুটির পথ — ভুল ইনপুটে সিস্টেম কী করে
• সীমানার ক্ষেত্রে একটা: শূন্য, ঋণাত্মক, খুব বড় মান

টেস্টের নামগুলো বাক্যের মতো লেখো — rejects_duplicate_order_within_same_import — কারণ নামগুলোই রিভিউয়ারকে বলে দেয় তুমি কোন কোন পরিস্থিতি নিয়ে ভেবেছ। অনেক সময় টেস্টের নামের তালিকাটাই ডকুমেন্টেশনের কাজ করে।

---

৬. ছোট জিনিস যেগুলোর প্রভাব অসম

• কমিট হিস্ট্রি — একটা বিশাল “initial commit” না; ৫–৮টা যৌক্তিক কমিট, বোধগম্য বার্তা সহ। এতে তোমার কাজের ক্রম দেখা যায়, যেটা রিভিউয়ার পছন্দ করে।
• প্রোজেক্ট স্ট্রাকচার — ভাষার প্রচলিত কাঠামো মেনে চলো, নিজের আবিষ্কার করা কাঠামো না।
• নির্ভরতা কম রাখো — প্রতিটা লাইব্রেরির পক্ষে যুক্তি থাকতে হবে। একটা CSV পড়তে পাঁচটা প্যাকেজ খারাপ দেখায়।
• কনফিগ — হার্ডকোড করা পাথ বা পোর্ট না; এনভায়রনমেন্ট ভেরিয়েবল বা একটা কনফিগ ফাইল।
• এক কমান্ডে চলা — রিভিউয়ার তোমার প্রোজেক্ট চালাতে গিয়ে আটকালে সেটাই তোমার প্রথম ছাপ।
• সিক্রেট না থাকা — কোনো API কী, টোকেন বা .env ফাইল রিপোতে না।

---

৭. রিভিউ কল — যেখানে আসল মূল্যায়ন

অনেক কোম্পানি জমার পরে ৩০–৪৫ মিনিটের একটা কল করে। এই কলটাই আসল রাউন্ড; জমাটা ছিল আলোচনার উপাদান।

কী প্রস্তুতি নেবে:

• নিজের কোড আবার পড়ে যাও জমা দেওয়ার পরে — দুই দিন পরে নিজের সিদ্ধান্ত মনে না থাকা খুব সাধারণ, আর খুব খারাপ দেখায়।
• প্রতিটা সিদ্ধান্তের বিকল্পটা মনে রাখো — “কেন এভাবে?” প্রশ্নের সেরা উত্তর হলো “এই তিনটা পথ ছিল, আমি এটা নিয়েছি কারণ…“।
• নিজেই দুর্বলতা বলো, ওদের বলার আগে — “The part I’m least happy with is the error handling in the importer; it works but it’s doing two things at once.” এটা আত্মবিশ্বাসের লক্ষণ, দুর্বলতার না।
• লাইভ পরিবর্তনের জন্য প্রস্তুত থাকো — “এখন যদি নতুন একটা রিকোয়ারমেন্ট আসে, কোথায় বদলাবে?” এই প্রশ্নটা প্রায়ই আসে, আর এটাই তোমার লেয়ারিংয়ের আসল পরীক্ষা।

সমালোচনা এলে তর্ক কোরো না, আবার সাথে সাথে সব মেনেও নিয়ো না। ভালো উত্তর: “That’s fair. I chose it because X, but if the constraint is Y, then your approach is better.” — এতে দেখা যায় তুমি ফিডব্যাক নিতে পারো আর নিজের যুক্তিও ধরে রাখতে পারো।

---

৮. অন্যায্য অ্যাসাইনমেন্ট

সব টেক-হোম সৎ না। এগুলো লাল পতাকা:

• ২০+ ঘণ্টার কাজ, বা “এটা একটা সপ্তাহান্তের প্রোজেক্ট”
• তাদের আসল প্রোডাক্টের একটা ফিচার — বিনা পারিশ্রমিকে কাজ করানো
• লুপের একদম প্রথমে টেক-হোম, কোনো কথা বলার আগেই
• একাধিক টেক-হোম একই প্রক্রিয়ায়

ফিরিয়ে দেওয়া বা আলোচনা করা সম্পূর্ণ পেশাদার:

Thanks for sending this over. Realistically this looks like 15–20 hours rather than the 4 mentioned, which I can’t commit to alongside a full-time job. Two alternatives I’m happy with: I can do a reduced scope — just the import and validation logic, about four hours — and we discuss the rest in a call. Or I can walk you through a similar system I’ve already built, screen-shared, in as much depth as you want.

বেশিরভাগ ভালো কোম্পানি এতে রাজি হয়। যারা হয় না, তারা তোমাকে একটা তথ্য দিল — চাকরিটাতেও সীমানার সম্মান থাকবে না।

---

এই সপ্তাহের কাজ

• একটা টেক-হোম টেমপ্লেট তৈরি করে রাখো — তোমার প্রধান ভাষায় একটা খালি প্রোজেক্ট: লিন্টার, টেস্ট রানার, স্ট্রাকচার, README-র কঙ্কাল। এটা প্রতিবার ৪৫ মিনিট বাঁচাবে।
• ওই README কাঠামোটা (পাঁচ ব্লক) একটা ফাইলে লিখে রাখো।
• পুরোনো কোনো সাইড প্রোজেক্টে এক ঘণ্টায় একটা README লেখার অনুশীলন করো — Assumptions আর Tradeoffs ব্লক দুটোসহ।
• ওই “অন্যায্য অ্যাসাইনমেন্ট” উত্তরটা নিজের ভাষায় লিখে রাখো, যাতে দরকারের সময় ভাবতে না হয়।

পরের পর্ব — বিহেভিয়ারাল রাউন্ড আর স্টোরি ব্যাংক: বারোটা গল্প আগে থেকে তৈরি করে রাখলে “একটা দ্বন্দ্বের কথা বলো” প্রশ্নে আর ফাঁকা লাগে না।