← রিমোট জব প্রিপারেশন · Part 4 / 17 · Aug 20, 2026 ·22 min read

রিমোট জব প্রিপারেশন — পর্ব ৪: পাবলিক প্রমাণ — লেখা, ওপেন সোর্স, পোর্টফোলিও

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

#career#remote work#writing#open source#bangla

যে সমস্যাটার এটা একমাত্র সস্তা সমাধান

পর্ব ১-এ দেখেছি: তোমার কোম্পানির নাম বিদেশি একজন পাঠকের কাছে একটা অজানা পরিমাণ। তোমার ছয় বছর ভালো না মাঝারি — সে জানার কোনো উপায় পায় না, তাই ঝুঁকি না নিয়ে পরের রেজিউমেতে চলে যায়।

এই সমস্যার তিনটা সমাধান আছে:

একটা চেনা কোম্পানিতে ঢোকা — কার্যকর, কিন্তু সেটাই তো আমরা করার চেষ্টা করছি।
রেফারেল — কার্যকর, তবে সম্পর্ক লাগে (পর্ব ৬)।
পাবলিক প্রমাণ — একমাত্র পথ যেটা তুমি আজ, একা, কারও অনুমতি ছাড়া শুরু করতে পারো।

আর এর একটা দ্বিতীয় সুবিধা আছে যেটা প্রায়ই বড়: ইংরেজিতে টেকনিক্যাল লেখা মানে তুমি একই সাথে ঝুঁকি ২-এর (অ্যাসিঙ্ক কমিউনিকেশন) উত্তরও দিয়ে দিচ্ছ। একটা লেখা দুটো প্রশ্নের উত্তর দেয়।

মাপকাঠিটা “ভাইরাল হওয়া” না। মাপকাঠি হলো — একজন হায়ারিং ম্যানেজার তোমার একটা লেখা পড়ে যেন ভাবে: “এই মানুষটা পরিষ্কার চিন্তা করে, আর সত্যিকারের কঠিন জিনিস সামলেছে।” দশজন পাঠকের মধ্যে একজন যদি সেই মানুষটা হয়, লেখাটা তার কাজ করেছে।

১. কী লিখবে — আর কী লিখবে না

লিখবে না: “How to build a REST API with Node.js”। “১০টা VS Code এক্সটেনশন”। ডকুমেন্টেশনের অনুবাদ। এগুলোর হাজারটা কপি আছে, আর এগুলো তোমার সম্পর্কে কিছুই বলে না।

লিখবে: এমন কিছু যেটা তুমি নিজে ভুগেছ এবং সমাধান করেছ। একটা কাজ করা লেখার তিনটা উৎস আছে:

একটা ইনসিডেন্ট। “রাত ২টায় চেকআউট বন্ধ হয়ে গেল, কারণটা যা ভেবেছিলাম তা ছিল না” — ডিবাগিংয়ের পথ, ভুল অনুমান, আসল কারণ, আর পরে কী বদলেছ।
একটা সিদ্ধান্ত। “আমরা Kafka আনিনি, কেন” — বিকল্পগুলো, হিসাব, শর্ত যেগুলোর বদলে সিদ্ধান্ত উল্টে যেত।
একটা মাইগ্রেশন। “৯ মাসে মনোলিথ থেকে দুটো সার্ভিস, শূন্য ডাউনটাইমে” — ধাপ, ফাঁদ, যা আবার করলে অন্যভাবে করতে।

তিনটাতেই সাধারণ ব্যাপারটা হলো: এগুলো টিউটোরিয়াল না, এগুলো অভিজ্ঞতা। আর অভিজ্ঞতা কেউ কপি করতে পারে না।

একটা লেখার কাঠামো

লেখার সময় নষ্ট হয় কাঠামো খুঁজতে গিয়ে। একটা রেখে দাও, প্রতিবার ব্যবহার করো:

অংশ	কী থাকবে	কত
প্রসঙ্গ	সিস্টেমটা কী, স্কেল কত, দল কত বড়	২–৩ প্যারা
সমস্যা	কী ভাঙল বা কী চাপ তৈরি হলো, সংখ্যাসহ	২ প্যারা
যা চেষ্টা করেছ	ব্যর্থ চেষ্টাগুলোও — এগুলোই বিশ্বাসযোগ্যতা তৈরি করে	৩–৪ প্যারা
সিদ্ধান্ত	কী বেছে নিলে, আর কী ছেড়ে দিলে	২–৩ প্যারা
ফল	সংখ্যা, আগে-পরে	১ প্যারা
যা শিখেছ	আবার করলে কী অন্যভাবে করতে	১ প্যারা

“যা চেষ্টা করেছ” অংশটা বাদ দেওয়ার লোভ হবে — দিয়ো না। ব্যর্থ চেষ্টার বর্ণনাই একটা লেখাকে “এই লোক সত্যিই এটা করেছে” বানায়, আর সেটাই তো পুরো উদ্দেশ্য।

২. রুটিন — মাসে একটা, বছরে বারোটা

সপ্তাহে একটা লেখার পরিকল্পনা প্রায় সবসময় তিন সপ্তাহে ভেঙে পড়ে। মাসে একটা টেকসই, আর এক বছরে বারোটা লেখা যেকোনো রেজিউমের চেয়ে জোরে কথা বলে।

বিষয় ফুরিয়ে যাওয়ার সমস্যাটা আসলে স্মৃতির সমস্যা। সমাধান: একটা ideas.md ফাইল খোলো, আর অফিসে যখনই এই তিনটার কোনোটা ঘটে, এক লাইন লিখে রাখো —

কোনো কিছু ভাঙল আর কারণটা অপ্রত্যাশিত ছিল
কোনো সিদ্ধান্তে টিমে তর্ক হলো
তুমি এমন কিছু শিখলে যেটা তিন মাস আগে জানলে সময় বাঁচত

তিন মাসেই তালিকাটা লেখার চেয়ে দ্রুত বাড়বে।

কোথায় প্রকাশ করবে: নিজের সাইটে (নিয়ন্ত্রণ তোমার হাতে) — সেটাই সেরা, আর লিংকটা রেজিউমে-LinkedIn-এ যায়। পাশাপাশি dev.to বা Medium-এ ক্রস-পোস্ট করা যায় পাঠকের জন্য, তবে মূল কপিটা নিজের জায়গায় রাখো।

ভাষা: বিদেশি হায়ারিং ম্যানেজারের জন্য লিখলে ইংরেজিতেই লিখতে হবে — সেটাই তো প্রমাণের অর্ধেক। বাংলায় লেখারও আলাদা মূল্য আছে (দেশের কমিউনিটিতে পরিচিতি, নিজের বোঝাপড়া পরিষ্কার হওয়া), কিন্তু চাকরির প্রমাণ হিসেবে ইংরেজি লেখাটাই কাজ করে।

ইংরেজি নিয়ে আটকে গেলে: প্রথমে বাংলায় ভেবে নাও কী বলতে চাও, তারপর সহজ ইংরেজিতে লেখো। ছোট বাক্য, সরল শব্দ — টেকনিক্যাল লেখায় এটাই ভালো ইংরেজি। জটিল বাক্য বানানোর চেষ্টাই বেশিরভাগ খারাপ লেখার কারণ। মনে রেখো, তোমার পাঠকদের অনেকেরই ইংরেজি মাতৃভাষা না।

৩. ওপেন সোর্স — কোন কাজটা আসলে ওজন পায়

ওপেন সোর্স নিয়ে দুটো ভুল ধারণা: “বড় প্রোজেক্টে কন্ট্রিবিউট না করলে মূল্য নেই”, আর “নিজের রিপোর সংখ্যা যত বেশি তত ভালো”। দুটোই ভুল।

ওজনের ক্রম, বাস্তবে:

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

README কেন কোডের চেয়ে বেশি পড়া হয়

একজন হায়ারিং ম্যানেজার তোমার কোড লাইন ধরে পড়বে না — সময় নেই। সে README পড়ে সিদ্ধান্ত নেবে যে কোডটা খোলার মতো কি না।

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

৪. পোর্টফোলিও: পাঁচটার চেয়ে একটা

পাঁচটা টিউটোরিয়াল প্রোজেক্ট (টুডু অ্যাপ, ই-কমার্স ক্লোন, চ্যাট অ্যাপ) — এগুলো সবাই বানিয়েছে, তাই এগুলো কিছুই আলাদা করে না। এর চেয়ে একটা জিনিস ভালো যেটা:

তোমার নিজের বা তোমার চেনা কারও একটা সত্যিকারের সমস্যা সমাধান করে,
কেউ ব্যবহার করে (কয়েকজন হলেও),
আর যার README-তে “কেন এভাবে” লেখা আছে।

উদাহরণ: একটা CLI যেটা তোমার টিমের রিলিজ নোট বানায়। একটা ছোট সার্ভিস যেটা তোমার ব্যক্তিগত খরচ ট্র্যাক করে আর তুমি সত্যিই চালাও। একটা লাইব্রেরি যেটা তোমার ভাষায় একটা বিরক্তিকর কাজ সহজ করে।

গুরুত্বপূর্ণ: প্রোজেক্টটা তোমার পজিশনিংয়ের সাথে মিলুক। পেমেন্টের লোক হলে idempotency বা reconciliation নিয়ে একটা ছোট টুল একটা টুডু অ্যাপের চেয়ে দশ গুণ বেশি কাজ করে।

৫. কনফারেন্স, মিটআপ, কমিউনিটি

কম খরচের দৃশ্যমানতা, আর অনেকে অবহেলা করে:

স্থানীয় মিটআপে একটা টক — স্লাইড পাবলিক করে রাখো, রেকর্ডিং থাকলে আরও ভালো। এটা “এই লোক জনসমক্ষে ব্যাখ্যা করতে পারে” — এর প্রমাণ।
অনলাইন কমিউনিটিতে সাহায্য করা (Discord, Slack, GitHub Discussions) — এখান থেকে রেফারেলও আসে, যেটা পর্ব ৬-এর বিষয়।
কনফারেন্সের CFP — আঞ্চলিক কনফারেন্সে (দুবাই, ইস্তানবুল, ইউরোপের ছোট কনফারেন্স) সিনিয়র প্র্যাকটিশনারের বাস্তব অভিজ্ঞতার টক গ্রহণযোগ্য হওয়ার সম্ভাবনা অনেকে যতটা ভাবে তার চেয়ে বেশি।

৬. যেসব জিনিস উল্টো ক্ষতি করে

অসমাপ্ত রিপোর ভিড় — বার্তা: শুরু করি, শেষ করি না।
কপি করা বা AI দিয়ে লেখা জেনেরিক পোস্ট — অভিজ্ঞ পাঠক তিন লাইনে ধরে ফেলে, আর তখন সব লেখার বিশ্বাসযোগ্যতা যায়।
অতিরঞ্জিত দাবি (“বিলিয়ন রিকোয়েস্ট স্কেল করেছি”) — ইন্টারভিউয়ে ভাঙবে।
কর্মস্থলের গোপন তথ্য ফাঁস — কোড, ক্লায়েন্টের নাম, ভেতরের সংখ্যা যা প্রকাশযোগ্য না। সন্দেহ হলে সংখ্যাগুলো আপেক্ষিক করে লেখো (“লেটেন্সি ৭৭% কমেছে”), আর কোম্পানির নাম না নিয়ে “একটি বড় মার্কেটপ্লেসে” লেখো।
শেষ পোস্ট তিন বছর আগে — একটা মৃত ব্লগ কোনো ব্লগ না থাকার চেয়ে খারাপ সংকেত দেয়। তাই কম প্রতিশ্রুতি দাও, কিন্তু চালিয়ে যাও।

এই মাসের কাজ

ideas.md খুলে পাঁচটা সম্ভাব্য বিষয় লিখে ফেলো — গত এক বছরের ইনসিডেন্ট, সিদ্ধান্ত আর মাইগ্রেশন থেকে।
এর মধ্যে সবচেয়ে সহজটা বেছে একটা লেখা শেষ করো, উপরের কাঠামো ধরে। নিখুঁত করার চেষ্টা কোরো না — প্রকাশ করাটাই শেখার অংশ।
GitHub প্রোফাইলটা পরিষ্কার করো: যা অসমাপ্ত তা আর্কাইভ করো, ৩–৬টা পিন করো, প্রতিটার README-তে “কেন” যোগ করো।
লেখাটার লিংক LinkedIn হেডলাইনের নিচে, About-এ আর রেজিউমের “নির্বাচিত কাজ”-এ বসাও।

পরের পর্ব — বাজার: অগ্রাধিকারের ক্রমে উপসাগরীয় দেশ, তুরস্ক, ইউরোপ/UK আর তারপর US — কোথায় সত্যিকারের রিমোট রোল আছে, কীভাবে ৩০ সেকেন্ডে ফিল্টার করবে, আর টার্গেট কোম্পানির তালিকা কীভাবে বানাবে।