প্রকল্পের সংক্ষিপ্ত বিবরণ
এই রিপোজিটরিতে বাস্তব নিয়োগ প্রক্রিয়া থেকে নেওয়া তিনটি AI Coding প্রকল্পের প্রশ্ন সংকলন করা হয়েছে এবং নির্ধারিত সময়ের টেক-হোম পরীক্ষা, Take-home Assignment ও সরাসরি জোড়ায় কোডিংয়ের জন্য প্রযোজ্য একটি সাধারণ পদ্ধতি তুলে ধরা হয়েছে। প্রশ্নগুলো বেনামিকরণ ও কাঠামোবদ্ধভাবে পুনর্লিখিত; এতে কোনো কোম্পানি, ইন্টারভিউয়ার, নিয়োগকর্মী বা গ্রাহকের নাম নেই।
রিপোজিটরিতে মূলত প্রশ্নের পর্যালোচনা ও পদ্ধতিতত্ত্ব সংরক্ষিত আছে। তিনটি প্রকল্পের ব্যক্তিগত সমাধান পৃথক রিপোজিটরিতে রয়েছে, যেখানে সোর্স কোড, ডিজাইন ডকুমেন্ট, টেস্ট এবং বাস্তব ডেলিভারি রেকর্ড অন্তর্ভুক্ত।
এই প্রকল্পগুলোতে কেবল কোডের পরিমাণ নয়, বরং চাহিদা বোঝা, আর্কিটেকচারের সীমা, প্রক্রিয়া নিয়ন্ত্রণ, গ্রহণযোগ্যতার প্রমাণ এবং ট্রেড-অফ করার সক্ষমতা যাচাই করা হয়।
তিনটি প্রকল্পে কী যাচাই করা হয়
01: Computer Use Agent Dashboard
প্রথম প্রশ্নে Web, Agent ও বিচ্ছিন্ন ডেস্কটপ সমন্বিত একটি সিস্টেম তৈরি করতে বলা হয়। এতে Computer Use, tool-calling loop, সেশন বিচ্ছিন্নতা, পর্যবেক্ষণযোগ্যতা এবং রানটাইম নির্ভরযোগ্যতার ওপর গুরুত্ব দেওয়া হয়।
- প্রশ্নের পর্যালোচনা: Computer Use Agent Dashboard
- ব্যক্তিগত বাস্তবায়ন: ai-agent-dashboard
এ ধরনের প্রকল্পে শুধু model API কল ও ইন্টারফেস দেখালেই হয় না। Agent কীভাবে tool ব্যবহার করে, বিভিন্ন সেশন কীভাবে বিচ্ছিন্ন থাকে এবং ব্যর্থতার অবস্থা পর্যবেক্ষণ ও পুনরুদ্ধার করা যায় কি না, সেদিকেও নজর দিতে হয়।
02: React Native স্ক্রিনশট অ্যাকশন Agent
দ্বিতীয় প্রশ্নটি 48 ঘণ্টার একটি React Native／iOS প্রকল্প। এতে ইনপুট হিসেবে স্ক্রিনশট ব্যবহার করে multimodal বোঝাপড়া, কাঠামোবদ্ধ Action, Human-in-the-loop, native tool এবং Memory যাচাই করা হয়।
- প্রশ্নের পর্যালোচনা: React Native স্ক্রিনশট অ্যাকশন Agent
- ব্যক্তিগত বাস্তবায়ন: ContactFlow
এ ধরনের প্রশ্নের মূল বিষয় হলো সম্পূর্ণ একটি চক্র তৈরি করা: স্ক্রিনশট বোঝা, কাঠামোবদ্ধ Action তৈরি, ব্যবহারকারীকে নিশ্চিত করার সুযোগ দেওয়া এবং উপযুক্ত native capability দিয়ে তা কার্যকর করা। শুধু প্রাকৃতিক ভাষায় পরামর্শ দেওয়া যথেষ্ট নয়।
03: Jira-ধাঁচের টাস্ক ম্যানেজমেন্ট সিস্টেম
তৃতীয় প্রশ্নে এক দিনের মধ্যে একটি Web MVP তৈরি করতে বলা হয়। এতে মূলত চাহিদার অগ্রাধিকার নির্ধারণ, CRUD, কানবান drag-and-drop, স্থানীয় persistence, timeline এবং সামগ্রিক ডেলিভারি মান যাচাই করা হয়।
- প্রশ্নের পর্যালোচনা: Jira-ধাঁচের টাস্ক ম্যানেজমেন্ট সিস্টেম
- ব্যক্তিগত বাস্তবায়ন: ForceTrack
এই প্রকল্পে PRD থেকে Repo Wiki পর্যন্ত 24টি বাস্তব AI Coding কথোপকথনের পর্বও রাখা হয়েছে। এর মাধ্যমে চাহিদা, বাস্তবায়ন ও ডকুমেন্টেশন কীভাবে ধাপে ধাপে এগিয়েছে তা দেখা যায়।
ForceTrack-এর 24টি বাস্তব কথোপকথনের পর্ব দেখুন
মূল পদ্ধতি: ছয় ধাপে AI Coding প্রকল্প সম্পন্ন করা
AI Coding প্রকল্পের সাধারণ সমাধানপদ্ধতি-তে পুরো প্রক্রিয়াকে ছয়টি ধাপে ভাগ করা হয়েছে। প্রশ্নটি Agent, mobile বা CRUD system যাই হোক, এই ক্রম অনুসরণ করা যায়।
প্রথম ধাপ: চাহিদা স্পষ্ট করে পরিধি নির্ধারণ
প্রথমে অস্পষ্ট বিবরণকে যাচাইযোগ্য P0 পরিধিতে রূপান্তর করুন। কী অবশ্যই করতে হবে, কী পরে করা যেতে পারে এবং কী স্পষ্টভাবে করা হবে না, তা আলাদা করুন। এতে নির্ধারিত সময়ের প্রকল্পে চাহিদা ক্রমাগত বাড়তে থাকে না।
প্রথমে একটি সরল চাহিদা ম্যাট্রিক্স তৈরি করা যায়:
চাহিদা: ব্যবহারকারী কী কাজ সম্পন্ন করতে পারবেন?
গ্রহণযোগ্যতা: কাজটি সফল হয়েছে কীভাবে প্রমাণ করবেন?
অগ্রাধিকার: এটি কি P0-এর অন্তর্ভুক্ত?
অবস্থা: শুরু হয়নি, চলছে, নাকি যাচাই হয়েছে?
ঝুঁকি: নির্ভরতা, অনুমতি, ব্যর্থতার পথ বা সময়ের খরচ কী?ম্যাট্রিক্সের গুরুত্ব তার বিন্যাসে নয়; বরং প্রতিটি কাজের সঙ্গে স্পষ্ট গ্রহণযোগ্যতার প্রমাণ যুক্ত করায়।
দ্বিতীয় ধাপ: Starter বা বিদ্যমান রিপোজিটরি অডিট
ইন্টারভিউ পক্ষ Starter দিলে সঙ্গে সঙ্গে পুনর্লিখন করবেন না। আগে বিদ্যমান ডিরেক্টরি, dependency, build পদ্ধতি, data model ও পুনর্ব্যবহারযোগ্য component পরীক্ষা করুন। এরপর কোন অংশ রাখা, সম্প্রসারণ বা প্রতিস্থাপন করা হবে তা নির্ধারণ করুন।
- প্রকল্পটি সঠিকভাবে install, build ও run হয় কি না নিশ্চিত করুন।
- বিদ্যমান state management, persistence ও test পদ্ধতি শনাক্ত করুন।
- platform, permission ও runtime সীমাবদ্ধতা পরীক্ষা করুন।
- বাধাগুলো নথিবদ্ধ করুন, যাতে AI ভুল অনুমানের ভিত্তিতে কোড তৈরি করতে না থাকে।
তৃতীয় ধাপ: ডেটা, স্টেট, টুল ও রানটাইম ডিজাইন
বিভিন্ন প্রশ্নে বিভিন্ন সীমার ওপর গুরুত্ব থাকে: Agent প্রকল্পে tool loop, session isolation ও failure recovery বিবেচনা করতে হয়; mobile প্রকল্পে structured Action, user confirmation ও native tool; আর task system-এ CRUD, drag-and-drop state, local persistence ও timeline গুরুত্বপূর্ণ।
ডিজাইনের সময় স্বাভাবিক অবস্থা, loading অবস্থা, failure অবস্থা এবং recovery পদ্ধতি স্পষ্ট করুন। শুধু মূল পথ রেখে boundary condition বাদ দিলে সাধারণত সম্পূর্ণ deliverable তৈরি হয় না।
চতুর্থ ধাপ: vertical slice দিয়ে AI task ভাগ করা
একবারে পুরো system তৈরি করতে AI-কে বলবেন না। আরও নির্ভরযোগ্য পদ্ধতি হলো vertical slice অনুযায়ী এগোনো, যাতে প্রতিটি slice-এ প্রয়োজনীয় data, logic, interface ও validation থাকে।
AI-এর জন্য task contract-এ অন্তত নিচের বিষয়গুলো স্পষ্ট লিখুন:
লক্ষ্য: এই পর্বে সম্পন্ন করতে হবে এমন দৃশ্যমান ফলাফল
পরিধি: কোন module পরিবর্তন করা যাবে
সীমাবদ্ধতা: technology stack, সময় ও compatibility-এর প্রয়োজন
গ্রহণযোগ্যতা: কোন operation বা check অবশ্যই পাস করতে হবে
নিষিদ্ধ বিষয়: এই পর্বে কোন feature সম্প্রসারণ করা যাবে নাএভাবে ভাগ করলে context drift কমে এবং প্রতিটি পর্ব মানুষ দিয়ে পর্যালোচনা করা সহজ হয়।
পঞ্চম ধাপ: মানবিক Review ও automated validation
AI বাস্তবায়নের গতি বাড়াতে পারে, কিন্তু technical judgment-এর দায়িত্ব developer-এর। প্রতিটি পরিবর্তনের পর কোড চাহিদা মেনে চলছে কি না, বিদ্যমান আচরণ নষ্ট হয়েছে কি না এবং failure path সামলানো হয়েছে কি না পরীক্ষা করা উচিত।
- বিদ্যমান test ও build process চালান।
- মূল user path হাতে-কলমে যাচাই করুন।
- state, permission, persistence ও boundary condition পরীক্ষা করুন।
- interface-এর প্রদর্শন বাস্তব run-এর ফলাফলের সঙ্গে মিলছে কি না নিশ্চিত করুন।
- শুধু “কোড তৈরি হয়েছে” লিখে থেমে না থেকে acceptance result নথিবদ্ধ করুন।
ষষ্ঠ ধাপ: সময়সীমার মধ্যে অগ্রাধিকার, ডেমো ও চূড়ান্ত ডেলিভারি
সময় কম থাকলে কম-মূল্যের পরিধি স্বেচ্ছায় বাদ দিন এবং P0-এর সম্পূর্ণ চক্র নিশ্চিত করুন। চূড়ান্ত ডেলিভারিতে শুধু source code নয়, build result, test, demo ও documentation-এর মাধ্যমে প্রকল্পটি সত্যিই চালানো যায় তা প্রমাণ করতে হবে।
একটি সংক্ষিপ্ত delivery checklist এমন হতে পারে:
মূল workflow কি সম্পূর্ণ?
প্রকল্পটি কি build ও start করা যায়?
গুরুত্বপূর্ণ failure path কি সামলানো হয়েছে?
ডেটা বা state কি প্রয়োজন অনুযায়ী সংরক্ষিত হচ্ছে?
ডেমোর ধাপগুলো কি স্থিতিশীল ও পুনরুৎপাদনযোগ্য?
ডকুমেন্টেশনে কি পরিধি, trade-off ও জানা সীমাবদ্ধতা ব্যাখ্যা করা হয়েছে?এই রিপোজিটরি কীভাবে ব্যবহার শুরু করবেন
এটি প্রশ্নের পর্যালোচনা ও পদ্ধতিতত্ত্বের রিপোজিটরি, এমন কোনো application নয় যার জন্য একসঙ্গে dependency install করে start করতে হবে। তাই প্রস্তুতির মূল কাজ হলো উপকরণ পড়া, template কপি করা এবং নির্দিষ্ট প্রশ্ন অনুযায়ী নিজের execution plan তৈরি করা।
- GitHub page থেকে বর্তমান রিপোজিটরি clone বা download করুন।
- তিনটি প্রকল্পের প্রশ্ন ধারাবাহিকভাবে পড়ে বিভিন্ন ধরনের engineering লক্ষ্য ও acceptance priority বুঝুন।
- সাধারণ সমাধানপদ্ধতি পড়ে requirement matrix, task contract ও delivery checklist কপি করুন।
- একটি প্রশ্ন বেছে নিয়ে চাহিদাকে নির্ধারিত সময়ে সম্পন্নযোগ্য P0 পরিধিতে সংকুচিত করুন।
- বাস্তবায়নের বিস্তারিত জানতে চাইলে সংশ্লিষ্ট ব্যক্তিগত solution repository-তে গিয়ে source code, design document ও test দেখুন।
README-তে প্রস্তাবিত ক্রম হলো আগে তিনটি প্রশ্ন পড়ুন, তারপর সাধারণ সমাধানপদ্ধতি পড়ুন। বাস্তবে কাজ করার সময় সব template হুবহু অনুসরণ করার প্রয়োজন নেই; প্রকল্পের আকার ও সময়সীমা অনুযায়ী সংক্ষিপ্ত করুন।
মৌলিক অনুশীলনের উদাহরণ
ধরা যাক আপনি Jira-ধাঁচের task management system অনুশীলন করছেন। প্রথমে এক দিনের লক্ষ্যকে যাচাইযোগ্য মূল চক্রে সীমাবদ্ধ করুন: CRUD, kanban drag-and-drop, local persistence ও timeline ঘিরে implementation ও acceptance পরিকল্পনা করুন। প্রতিটি অংশ শেষ হওয়ার সঙ্গে সঙ্গে state update ও persistence result যাচাই করুন; সব page শেষ হওয়ার পর একসঙ্গে test করার জন্য অপেক্ষা করবেন না।
স্ক্রিনশট action Agent অনুশীলন করলে “স্ক্রিনশট input, multimodal বোঝাপড়া, structured Action, user confirmation, native tool” ঘিরে vertical slice সাজাতে পারেন। প্রতিটি ধাপে human confirmation ও validation রাখুন, যাতে model output-কে সরাসরি নির্ভরযোগ্য execution result ধরে না নেওয়া হয়।
Computer Use Agent Dashboard-এর ক্ষেত্রে tool loop, session isolation, observability ও runtime reliability আগে যাচাই করুন। interface system-এর একটি অংশ মাত্র; execution process trace করা যায় কি না এবং failure-এর পর কীভাবে handle করা হয়, সেগুলোও acceptance-এর অন্তর্ভুক্ত।
উন্নত কৌশল
Feature-এর সংখ্যার আগে acceptance evidence রাখুন
সময়সীমার প্রকল্পে test ও demo করা তিনটি সম্পূর্ণ feature সাধারণত স্থিতিশীলভাবে চালানো যায় না এমন দশটি page-এর চেয়ে বেশি বিশ্বাসযোগ্য। প্রতিটি P0 feature operation, test, build result বা documentation-এর মাধ্যমে প্রমাণযোগ্য হওয়া উচিত।
AI-কে implementation ত্বরান্বিত করতে দিন, সিদ্ধান্তের বিকল্প হিসেবে নয়
AI স্পষ্ট সীমার কাজ সামলাতে উপযোগী, কিন্তু scope ভাগ করা, architecture trade-off, risk assessment ও final Review developer-এর নিয়ন্ত্রণেই থাকা উচিত। task যত অস্পষ্ট হবে, একবারে বিপুল কোড তৈরি করার rework risk তত বাড়বে।
State ও recovery path আগে পরীক্ষা করুন
তিনটি প্রশ্নের ধরন আলাদা হলেও সবগুলোতেই state, failure, recovery, permission, persistence বা boundary condition জড়িত। ডেমোর আগে abnormal input, tool failure, state transition এবং application-এ পুনরায় প্রবেশের পরের আচরণ সক্রিয়ভাবে পরীক্ষা করুন।
বাস্তব কথোপকথনের ইতিহাস দিয়ে collaboration পদ্ধতি পর্যালোচনা করুন
ForceTrack-এর 24টি বাস্তব কথোপকথনের পর্ব AI Coding-এর process control বিশ্লেষণে উপযোগী। পড়ার সময় প্রতিটি পর্বের লক্ষ্য কীভাবে নির্দিষ্ট হয়েছে, task কীভাবে ভাগ হয়েছে এবং ফলাফল কীভাবে PRD থেকে ধাপে ধাপে Repo Wiki-তে রূপ নিয়েছে, সেদিকে নজর দিন।
উপসংহার
এই উপকরণগুলোর মূল্য শুধু তিনটি অনুশীলনের প্রশ্ন দেওয়ায় নয়; বরং পুনর্ব্যবহারযোগ্য AI Coding delivery পদ্ধতি দেখানোয়: প্রথমে চাহিদা বোঝা ও scope freeze করা, তারপর environment audit, boundary design, task decomposition ও human review, এবং শেষে test, build, demo ও documentation দিয়ে acceptance সম্পন্ন করা।
বাস্তব নিয়োগ প্রক্রিয়ায় প্রশ্ন, সময়সীমা ও confidentiality requirement ভিন্ন হতে পারে। এসব পদ্ধতি ব্যবহারের সময় সবসময় প্রাপ্ত official material-কে অগ্রাধিকার দিন এবং সময় অনুযায়ী কম-মূল্যের scope বাদ দিন।