ہم نے اربن ٹیک چیلنج ہیکاتھون میں بگ ڈیٹا ٹریک کیسے اور کیوں جیتا؟

میرا نام دمتری ہے۔ اور میں اس بارے میں بات کرنا چاہتا ہوں کہ کس طرح ہماری ٹیم بگ ڈیٹا ٹریک پر اربن ٹیک چیلنج ہیکاتھون کے فائنل میں پہنچی۔ میں فوراً کہوں گا کہ یہ پہلا ہیکاتھون نہیں ہے جس میں میں نے حصہ لیا تھا، اور یہ پہلا نہیں جس میں میں نے انعامات لیے تھے۔ اس سلسلے میں، میں اپنی کہانی میں مجموعی طور پر ہیکاتھون انڈسٹری کے حوالے سے کچھ عمومی مشاہدات اور نتائج اخذ کرنا چاہتا ہوں، اور اربن ٹیک چیلنج (کے لیے مثال یہ).

تو پہلے کچھ عمومی مشاہدات۔

1. یہ حیرت کی بات ہے کہ بہت سے لوگ سادہ لوح سوچتے ہیں کہ ہیکاتھون کھیلوں کا ایک ایسا مقابلہ ہے جہاں بہترین کوڈر جیتتے ہیں۔ یہ غلط ہے. میں ایسے معاملات پر غور نہیں کرتا جب ہیکاتھون کے منتظمین خود نہیں جانتے کہ وہ کیا چاہتے ہیں (میں نے اسے بھی دیکھا ہے)۔ لیکن، ایک اصول کے طور پر، کمپنی جو ہیکاتھون کا اہتمام کرتی ہے وہ اپنے مقاصد کو حاصل کرتی ہے۔ ان کی فہرست مختلف ہو سکتی ہے: یہ کچھ مسائل کا تکنیکی حل، نئے خیالات اور لوگوں کی تلاش وغیرہ ہو سکتی ہے۔ یہ اہداف اکثر ایونٹ کی شکل، اس کا وقت، آن لائن/آف لائن، کاموں کو کس طرح وضع کیا جائے گا (اور کیا وہ بالکل وضع کیے جائیں گے)، کیا ہیکاتھون میں کوڈ کا جائزہ لیا جائے گا، وغیرہ کا تعین کرتے ہیں۔ دونوں ٹیموں اور انہوں نے کیا کیا اس کا اندازہ اسی نقطہ نظر سے کیا جاتا ہے۔ اور وہ ٹیمیں جو کمپنی کو جیتنے کی ضرورت کے مقام پر سب سے بہتر پہنچتی ہیں، اور بہت سے لوگ یہ سوچ کر مکمل طور پر لاشعوری طور پر اور حادثاتی طور پر اس مقام تک پہنچ جاتے ہیں کہ وہ واقعی کھیلوں کے مقابلے میں حصہ لے رہے ہیں۔ میرے مشاہدے سے پتہ چلتا ہے کہ شرکاء کی حوصلہ افزائی کے لیے منتظمین کو کم از کم کھیلوں کا ماحول اور مساوی حالات پیدا کرنے چاہئیں، بصورت دیگر وہ منفی کی لہر حاصل کریں گے، جیسا کہ اوپر کا جائزہ لیا گیا ہے۔ لیکن ہم پیچھے ہٹ جاتے ہیں۔

2. لہذا مندرجہ ذیل نتیجہ. منتظمین ہیکاتھون میں شرکت کرنے والے اپنے کام کے ساتھ آنے میں دلچسپی رکھتے ہیں، بعض اوقات وہ اس مقصد کے لیے خصوصی طور پر آن لائن خط و کتابت کا مرحلہ بھی ترتیب دیتے ہیں۔ یہ مضبوط آؤٹ پٹ حل کی اجازت دیتا ہے۔ "اپنا کام" کا تصور ایک بہت ہی رشتہ دار ہے؛ کوئی بھی تجربہ کار ڈویلپر اپنی پہلی کمٹ میں اپنے پرانے پروجیکٹس سے کوڈ کی ہزاروں لائنیں جمع کر سکتا ہے۔ اور کیا یہ پہلے سے تیار شدہ ترقی ہوگی؟ لیکن کسی بھی صورت میں، اصول لاگو ہوتا ہے، جس کا اظہار میں نے ایک مشہور میم کی شکل میں کیا:

جیتنے کے لیے، آپ کے پاس کچھ، کسی قسم کا مسابقتی فائدہ ہونا ضروری ہے: ایک ایسا ہی پروجیکٹ جو آپ نے ماضی میں کیا، کسی مخصوص موضوع میں علم اور تجربہ، یا ہیکاتھون کے آغاز سے پہلے کیا گیا کوئی ریڈی میڈ کام۔ ہاں، یہ کھیل نہیں ہے۔ ہاں، یہ خرچ کی گئی کوشش کے قابل نہیں ہو سکتا ہے (یہاں، ہر کوئی خود فیصلہ کرتا ہے کہ آیا یہ 3 ہزار کے انعام کے لیے رات کو 100 ہفتوں کے لیے کوڈنگ کرنے کے قابل ہے، جسے پوری ٹیم میں تقسیم کیا گیا ہے، اور نہ ملنے کے خطرے کے باوجود)۔ لیکن، اکثر، یہ آگے بڑھنے کا واحد موقع ہوتا ہے۔

3. ٹیم کا انتخاب۔ جیسا کہ میں نے ہیکاتھون چیٹس میں دیکھا، بہت سے لوگ اس مسئلے سے کافی غیر سنجیدہ ہیں (حالانکہ یہ سب سے اہم فیصلہ ہے جو ہیکاتھون میں آپ کے نتائج کا تعین کرے گا)۔ سرگرمی کے بہت سے شعبوں میں (کھیلوں اور ہیکاتھون دونوں میں) میں نے دیکھا ہے کہ مضبوط لوگ مضبوط کے ساتھ، کمزور کمزوروں کے ساتھ، ہوشیار ہوشیار کے ساتھ، ٹھیک ہے، عام طور پر، آپ کو خیال آتا ہے... چیٹس میں تقریباً ایسا ہی ہوتا ہے: کم مضبوط پروگرامرز وہ فوراً ہی چھین لیے جاتے ہیں، جن لوگوں کے پاس ہیکاتھون کے لیے کوئی قابل قدر مہارت نہیں ہوتی وہ طویل عرصے تک چیٹ میں لٹکتے رہتے ہیں اور اس اصول پر ٹیم کا انتخاب کرتے ہیں کہ اگر کوئی اسے لے گا۔ . کچھ ہیکاتھنز میں، ٹیموں کو بے ترتیب تفویض کی مشق کی جاتی ہے، اور منتظمین کا دعویٰ ہے کہ بے ترتیب ٹیمیں موجودہ ٹیموں سے بدتر کارکردگی کا مظاہرہ نہیں کرتی ہیں۔ لیکن میرے مشاہدے کے مطابق، حوصلہ افزائی کرنے والے، ایک اصول کے طور پر، اپنے طور پر ایک ٹیم تلاش کرتے ہیں؛ اگر کسی کو تفویض کرنا ہے، تو، اکثر، ان میں سے اکثر ہیکاتھون میں نہیں آتے ہیں.

جہاں تک ٹیم کی تشکیل کا تعلق ہے، یہ بہت انفرادی اور کام پر بہت زیادہ منحصر ہے۔ میں کہہ سکتا ہوں کہ کم از کم قابل عمل ٹیم کی ساخت ایک ڈیزائنر ہے - فرنٹ اینڈ یا فرنٹ اینڈ - بیک اینڈ۔ لیکن میں ایسے معاملات کے بارے میں بھی جانتا ہوں جب صرف فرنٹ اینڈرز پر مشتمل ٹیمیں جیتیں، جنہوں نے node.js میں ایک سادہ بیک اینڈ شامل کیا، یا React Native میں موبائل ایپلیکیشن بنائی۔ یا صرف بیکنڈرز سے جنہوں نے سادہ لے آؤٹ کیا۔ عام طور پر، سب کچھ بہت انفرادی ہے اور کام پر منحصر ہے. ہیکاتھون کے لیے ٹیم منتخب کرنے کا میرا منصوبہ کچھ یوں تھا: میں نے ایک ٹیم کو جمع کرنے یا فرنٹ اینڈ - بیک اینڈ - ڈیزائنر جیسی ٹیم میں شامل ہونے کا منصوبہ بنایا (میں خود فرنٹ اینڈ ہوں)۔ اور بہت جلد میں نے ایک ازگر کی پشت پناہی کرنے والے اور ایک ڈیزائنر کے ساتھ بات چیت شروع کر دی جس نے ہمارے ساتھ شامل ہونے کی دعوت قبول کر لی۔ تھوڑی دیر بعد، ایک لڑکی، ایک کاروباری تجزیہ کار، جسے پہلے ہی ہیکاتھون جیتنے کا تجربہ تھا، ہمارے ساتھ شامل ہوئی، اور اس نے اس کے ہمارے ساتھ شامل ہونے کے مسئلے کا فیصلہ کیا۔ ایک مختصر میٹنگ کے بعد، ہم نے اپنے آپ کو U4 (URBAN 4، urban four) کہنے کا فیصلہ کیا جو کہ لاجواب چار سے مشابہت رکھتے ہیں۔ اور یہاں تک کہ انہوں نے ہمارے ٹیلیگرام چینل کے اوتار پر اسی مناسبت سے تصویر لگا دی۔

4. کام کا انتخاب کرنا۔ جیسا کہ میں پہلے ہی کہہ چکا ہوں، آپ کو مسابقتی فائدہ ہونا چاہیے، ہیکاتھون کے لیے کام اسی کی بنیاد پر منتخب کیا جاتا ہے۔ اس کی بنیاد پر، دیکھا جا رہا ہے کاموں کی فہرست اور ان کی پیچیدگی کا اندازہ لگاتے ہوئے، ہم نے دو کام طے کیے: DPiIR سے اختراعی کاروباری اداروں کا کیٹلاگ اور EFKO سے چیٹ بوٹ۔ DPIiR سے کام کا انتخاب بیکنڈر نے کیا تھا، EFKO سے کام کا انتخاب میں نے کیا تھا، کیونکہ node.js اور DialogFlow میں چیٹ بوٹس لکھنے کا تجربہ تھا۔ EFKO کام میں ML بھی شامل تھا؛ میرے پاس ML میں کچھ، بہت وسیع، تجربہ نہیں ہے۔ اور مسئلہ کی شرائط کے مطابق، مجھے ایسا لگتا تھا کہ ایم ایل ٹولز کا استعمال کرتے ہوئے اس کے حل ہونے کا امکان نہیں ہے۔ یہ احساس اس وقت مضبوط ہوا جب میں اربن ٹیک چیلنج میٹ اپ میں گیا، جہاں منتظمین نے مجھے EFKO پر ایک ڈیٹاسیٹ دکھایا، جہاں پروڈکٹ کے لے آؤٹ کی تقریباً 100 تصاویر (مختلف زاویوں سے لی گئی) اور تقریباً 20 کلاسز لے آؤٹ کی خامیاں تھیں۔ اور، ایک ہی وقت میں، جن لوگوں نے کام کا حکم دیا وہ 90% کی درجہ بندی کی کامیابی کی شرح حاصل کرنا چاہتے تھے۔ نتیجے کے طور پر، میں نے ایم ایل کے بغیر حل کی ایک پریزنٹیشن تیار کی، بیکنڈر نے کیٹلاگ کی بنیاد پر ایک پریزنٹیشن تیار کی، اور پریزنٹیشنز کو حتمی شکل دینے کے بعد، ہم نے انہیں اربن ٹیک چیلنج میں بھیج دیا۔ پہلے سے ہی اس مرحلے پر، ہر شریک کی حوصلہ افزائی اور شراکت کی سطح کو ظاہر کیا گیا تھا. ہمارے ڈیزائنر نے بات چیت میں حصہ نہیں لیا، دیر سے جواب دیا، اور یہاں تک کہ آخری لمحے میں پریزنٹیشن میں اپنے بارے میں معلومات بھریں، عام طور پر شکوک و شبہات پیدا ہوئے۔

نتیجے کے طور پر، ہم نے DPiIR سے ٹاسک پاس کیا، اور بالکل بھی پریشان نہیں تھے کہ ہم نے EFKO پاس نہیں کیا، کیونکہ یہ کام ہمارے لیے عجیب سا لگا، اسے ہلکے سے کہنا۔

5. ہیکاتھون کی تیاری۔ جب بالآخر یہ معلوم ہوا کہ ہم نے ہیکاتھون کے لیے کوالیفائی کر لیا ہے تو ہم نے تیاری شروع کر دی۔ اور یہاں میں ہیکاتھون کے آغاز سے ایک ہفتہ پہلے کوڈ لکھنا شروع کرنے کی وکالت نہیں کر رہا ہوں۔ کم از کم، آپ کے پاس ایک بوائلر پلیٹ تیار ہونی چاہیے، جس کے ساتھ آپ فوری طور پر کام شروع کر سکتے ہیں، بغیر ٹولز کو ترتیب دیے، اور کسی ایسے lib کے کیڑے سے ٹکرائے بغیر جنہیں آپ نے ہیکاتھون میں پہلی بار آزمانے کا فیصلہ کیا تھا۔ میں اینگولر انجینئرز کے بارے میں ایک کہانی جانتا ہوں جو ہیکاتھون میں آئے اور پروجیکٹ کی تعمیر کو ترتیب دینے میں 2 دن گزارے، لہذا ہر چیز کو پہلے سے تیار کر لینا چاہیے۔ ہم نے ذمہ داریوں کو مندرجہ ذیل طور پر تقسیم کرنے کا ارادہ کیا: بیکینڈر ایسے کرالر لکھتا ہے جو انٹرنیٹ کو اسکور کرتے ہیں اور تمام جمع کردہ معلومات کو ڈیٹا بیس میں ڈالتے ہیں، جب کہ میں node.js میں ایک API لکھتا ہوں جو اس ڈیٹا بیس سے سوال کرتا ہے اور ڈیٹا کو سامنے بھیجتا ہے۔ اس سلسلے میں، میں نے express.js کا استعمال کرتے ہوئے پیشگی سرور تیار کیا اور ری ایکٹ میں فرنٹ اینڈ تیار کیا۔ میں CRA استعمال نہیں کرتا، میں ہمیشہ اپنے لیے ویب پیک کو اپنی مرضی کے مطابق بناتا ہوں اور میں اچھی طرح جانتا ہوں کہ اس سے کیا خطرات لاحق ہوسکتے ہیں (کوئی ڈویلپرز کی کہانی یاد رکھیں)۔ اس موقع پر، میں نے اپنے ڈیزائنر سے انٹرفیس ٹیمپلیٹس یا کم از کم مک اپس کی درخواست کی تاکہ یہ اندازہ ہو سکے کہ میں کیا پیش کروں گا۔ اصولی طور پر، اسے اپنی تیاری بھی کرنی چاہئے اور ان کو ہمارے ساتھ مربوط کرنا چاہئے، لیکن مجھے کبھی جواب نہیں ملا۔ نتیجے کے طور پر، میں نے اپنے پرانے منصوبوں میں سے ایک سے ڈیزائن ادھار لیا۔ اور اس نے اور بھی تیزی سے کام کرنا شروع کردیا، کیونکہ اس پروجیکٹ کے لیے تمام اسٹائل پہلے ہی لکھے جاچکے تھے۔ لہذا نتیجہ: ایک ڈیزائنر کی ہمیشہ ٹیم میں ضرورت نہیں ہوتی ہے)))۔ ہم ان پیشرفتوں کے ساتھ ہیکاتھون میں آئے۔

6. ہیکاتھون میں کام کریں۔ پہلی بار جب میں نے اپنی ٹیم کو لائیو دیکھا تو صرف سینٹرل ڈسٹری بیوشن سینٹر میں ہیکاتھون کے افتتاح کے موقع پر تھا۔ ہم نے ملاقات کی، مسئلے کے حل اور کام کرنے کے مراحل پر تبادلہ خیال کیا۔ اور اگرچہ افتتاح کے بعد ہمیں ریڈ اکتوبر کے لیے بس سے جانا تھا، لیکن ہم 9.00 بجے تک اس جگہ پہنچنے پر راضی ہو کر سونے کے لیے گھر چلے گئے۔ کیوں؟ منتظمین بظاہر شرکاء سے زیادہ سے زیادہ فائدہ اٹھانا چاہتے تھے، اس لیے انہوں نے ایسا شیڈول ترتیب دیا۔ لیکن، میرے تجربے میں، آپ عام طور پر ایک رات سوئے بغیر کوڈ کر سکتے ہیں۔ جہاں تک دوسرے کا تعلق ہے، مجھے اب یقین نہیں ہے۔ ہیکاتھون ایک میراتھن ہے؛ آپ کو اپنی طاقت کا مناسب حساب اور منصوبہ بندی کرنے کی ضرورت ہے۔ اس کے علاوہ، ہماری تیاری تھی.

اس لیے سونے کے بعد 9.00 بجے ہم ڈیوکریسی کی چھٹی منزل پر بیٹھے تھے۔ پھر ہمارے ڈیزائنر نے غیر متوقع طور پر اعلان کیا کہ اس کے پاس لیپ ٹاپ نہیں ہے اور وہ گھر سے کام کرے گا، اور ہم فون کے ذریعے بات چیت کریں گے۔ یہ آخری تنکا تھا۔ اور اس طرح ہم چار سے تین میں بدل گئے، حالانکہ ہم نے ٹیم کا نام نہیں بدلا۔ ایک بار پھر، یہ ہمارے لیے کوئی بڑا دھچکا نہیں تھا؛ میرے پاس پرانے پروجیکٹ کا ڈیزائن پہلے ہی موجود تھا۔ عام طور پر، سب سے پہلے سب کچھ بہت آسانی سے اور منصوبہ بندی کے مطابق چلا گیا. ہم نے منتظمین کی طرف سے اختراعی کمپنیوں کا ڈیٹا بیس (ہم نے neo4j استعمال کرنے کا فیصلہ کیا) میں لوڈ کیا۔ میں نے ٹائپ سیٹنگ شروع کی، پھر node.js لیا، اور پھر چیزیں غلط ہونے لگیں۔ میں نے پہلے کبھی neo4j کے ساتھ کام نہیں کیا تھا، اور پہلے میں اس ڈیٹا بیس کے لیے کام کرنے والے ڈرائیور کی تلاش میں تھا، پھر میں نے سوچا کہ استفسار کیسے لکھا جائے، اور پھر میں یہ جان کر حیران رہ گیا کہ یہ ڈیٹا بیس، جب استفسار کیا جاتا ہے، تو اس ڈیٹا بیس کو واپس کرتا ہے۔ نوڈ آبجیکٹ اور ان کے کناروں کی ایک صف کی شکل۔ وہ. جب میں نے TIN کے ذریعے ایک تنظیم اور اس پر موجود تمام ڈیٹا کی درخواست کی، ایک تنظیمی آبجیکٹ کے بجائے، مجھے اس تنظیم اور ان کے درمیان تعلقات کے ڈیٹا پر مشتمل اشیاء کی ایک لمبی صف واپس کر دی گئی۔ میں نے ایک میپر لکھا جو پوری صف سے گزرا اور ان کی تنظیم کے مطابق تمام اشیاء کو ایک شے میں چپکا دیا۔ لیکن جنگ میں، جب 8 ہزار تنظیموں کے ڈیٹا بیس کی درخواست کی گئی، تو اسے انتہائی دھیرے دھیرے، تقریباً 20 سے 30 سیکنڈ میں انجام دیا گیا۔ میں نے اصلاح کے بارے میں سوچنا شروع کیا... اور پھر ہم وقت پر رک گئے اور MongoDB پر چلے گئے، اور اس میں ہمیں تقریباً 30 منٹ لگے۔ مجموعی طور پر، neo4j پر تقریباً 5 گھنٹے ضائع ہوئے۔

یاد رکھیں، ٹیکنالوجی کو کبھی بھی ایسے ہیکاتھون میں نہ لے جائیں جس سے آپ واقف نہ ہوں، وہاں حیرانی ہو سکتی ہے۔ لیکن، عام طور پر، اس ناکامی کے علاوہ، سب کچھ منصوبہ بندی کے مطابق ہوا. اور پہلے ہی 9 دسمبر کی صبح، ہمارے پاس مکمل طور پر کام کرنے والی درخواست تھی۔ باقی دن کے لیے ہم نے اس میں اضافی خصوصیات شامل کرنے کا منصوبہ بنایا۔ مستقبل میں، میرے لئے سب کچھ نسبتا آسانی سے چلا گیا، لیکن بیکینڈر کو تلاش کے انجنوں میں اپنے کرالروں پر پابندی کے ساتھ، قانونی اداروں کے جمع کرنے والوں کے اسپام میں بہت ساری پریشانیوں کا سامنا کرنا پڑا، جو درخواست کرتے وقت تلاش کے نتائج میں پہلے نمبر پر آیا۔ ہر مخصوص کمپنی کے لیے۔ لیکن اس کے لیے بہتر ہے کہ وہ خود اس کے بارے میں بتائے۔ پہلی اضافی خصوصیت جو میں نے شامل کی تھی وہ پورے نام سے تلاش تھی۔ VKontakte کے جنرل ڈائریکٹر. اس میں کئی گھنٹے لگے۔

لہذا، ہماری درخواست میں کمپنی کے صفحے پر، جنرل ڈائریکٹر کا ایک اوتار ظاہر ہوا، اس کے VKontakte صفحہ کا لنک اور کچھ دیگر ڈیٹا۔ یہ کیک پر ایک اچھی چیری تھی، حالانکہ اس نے ہمیں جیت نہیں دی ہو گی۔ پھر، میں کچھ تجزیات چلانا چاہتا تھا۔ لیکن اختیارات کی طویل تلاش کے بعد (UI کے ساتھ بہت سی باریکیاں تھیں)، میں نے معاشی سرگرمی کوڈ کے ذریعے تنظیموں کے آسان ترین مجموعہ پر طے کیا۔ شام کو پہلے ہی، آخری گھنٹوں میں، میں اختراعی مصنوعات کی نمائش کے لیے ایک ٹیمپلیٹ تیار کر رہا تھا (ہماری درخواست میں پروڈکٹس اور سروسز کا سیکشن ہونا چاہیے)، حالانکہ بیک اینڈ اس کے لیے تیار نہیں تھا۔ اسی وقت، ڈیٹا بیس تیزی سے بڑھ رہا تھا، کرالرز کام کرتے رہے، بیکینڈر نے NLP کے ساتھ تجربہ کیا تاکہ اختراعی متن کو غیر اختراعی متن سے ممتاز کیا جا سکے۔))۔ لیکن فائنل پریزنٹیشن کا وقت پہلے ہی قریب آ رہا تھا۔

7. پیشکش۔ میرے اپنے تجربے سے، میں کہہ سکتا ہوں کہ آپ کو کسی پریزنٹیشن کی تیاری سے تقریباً 3 سے 4 گھنٹے پہلے اسے تیار کرنا چاہیے۔ خاص طور پر اگر اس میں ویڈیو شامل ہو تو اس کی شوٹنگ اور ایڈیٹنگ میں کافی وقت لگتا ہے۔ ہمارے پاس ایک ویڈیو ہونا تھا۔ اور ہمارے پاس ایک خاص شخص تھا جس نے اس سے نمٹا، اور بہت سے دیگر تنظیمی مسائل کو بھی حل کیا۔ اس سلسلے میں، ہم نے آخری لمحے تک کوڈنگ سے خود کو نہیں ہٹایا۔

8. پچ۔ مجھے یہ پسند نہیں آیا کہ پریزنٹیشنز اور فائنلز الگ الگ ہفتے کے دن (پیر کو) منعقد کیے گئے تھے۔ یہاں، غالباً، شرکاء میں سے زیادہ سے زیادہ نچوڑنے کی منتظمین کی پالیسی جاری رہی۔ میں نے کام سے وقت نکالنے کا ارادہ نہیں کیا تھا، میں صرف فائنل میں آنا چاہتا تھا، حالانکہ میری باقی ٹیم نے دن کی چھٹی لی تھی۔ تاہم، ہیکاتھون میں جذباتی غروب پہلے ہی اتنا زیادہ تھا کہ صبح 8 بجے میں نے اپنی ٹیم (کام کرنے والی ٹیم، ہیکاتھون ٹیم نہیں) کی چیٹ میں لکھا کہ میں اپنے خرچے پر دن لے رہا ہوں، اور سینٹرل چلا گیا۔ پچ کے لئے دفتر. ہمارے مسئلے میں بہت سارے خالص ڈیٹا سائنسدان تھے، اور اس نے مسئلے کو حل کرنے کے نقطہ نظر کو بہت متاثر کیا۔ بہت سے لوگوں کے پاس اچھا DS تھا، لیکن کسی کے پاس بھی کام کرنے والا پروٹو ٹائپ نہیں تھا، بہت سے لوگ سرچ انجنوں میں اپنے کرالر کی پابندیوں کو پورا نہیں کر سکتے تھے۔ ہم واحد ٹیم تھے جس میں کام کرنے والا پروٹو ٹائپ تھا۔ اور ہم جانتے تھے کہ مسئلہ کیسے حل کیا جائے۔ آخر میں، ہم نے ٹریک جیت لیا، حالانکہ ہم بہت خوش قسمت تھے کہ ہم نے کم سے کم مسابقتی کام کا انتخاب کیا۔ دوسرے ٹریکس کی پچوں کو دیکھ کر ہمیں احساس ہوا کہ ہمیں وہاں کوئی موقع نہیں ملے گا۔ میں یہ بھی کہنا چاہتا ہوں کہ ہم جیوری کے ساتھ بہت خوش قسمت تھے؛ انہوں نے احتیاط سے کوڈ کو چیک کیا۔ اور، جائزوں کی طرف سے فیصلہ، یہ تمام پٹریوں میں نہیں ہوا.

9. فائنل۔ کوڈ کے جائزے کے لیے کئی بار جیوری کے پاس بلائے جانے کے بعد، ہم یہ سوچ کر کہ آخر کار ہم نے تمام مسائل حل کر لیے ہیں، برگر کنگ میں لنچ کرنے گئے۔ وہاں منتظمین نے ہمیں دوبارہ بلایا، ہمیں جلدی سے آرڈر پیک کرکے واپس جانا پڑا۔

منتظم نے ہمیں دکھایا کہ ہمیں کس کمرے میں جانا ہے، اور داخل ہونے پر، ہم نے خود کو جیتنے والی ٹیموں کے لیے عوامی تقریر کے تربیتی سیشن میں پایا۔ جن لڑکوں نے سٹیج پر پرفارم کرنا تھا وہ خوب چارج کیے ہوئے تھے، سب اصلی شو مین کی طرح باہر آئے۔

اور مجھے تسلیم کرنا چاہیے، فائنل میں، دوسرے ٹریکس سے مضبوط ترین ٹیموں کے پس منظر میں، ہم پیلے لگ رہے تھے؛ حکومتی گاہک کی نامزدگی میں جیت کافی حد تک رئیل اسٹیٹ ٹیک ٹریک سے ٹیم کو ملی۔ میں سمجھتا ہوں کہ ٹریک پر ہماری فتح میں اہم عوامل نے کردار ادا کیا: ایک ریڈی میڈ خالی جگہ کی دستیابی، جس کی وجہ سے ہم فوری طور پر ایک پروٹو ٹائپ بنانے میں کامیاب ہوئے، پروٹوٹائپ میں "ہائی لائٹس" کی موجودگی (سی ای اوز کی تلاش سوشل نیٹ ورکس پر) اور ہمارے بیکینڈر کی NLP مہارتیں، جس میں جیوری کو بھی بہت دلچسپی تھی۔

اور آخر میں، روایتی طور پر شکریہ ان تمام لوگوں کا جنہوں نے ہماری حمایت کی، ہمارے ٹریک کی جیوری، Evgeniy Evgrafiev (اس مسئلے کا مصنف جسے ہم نے ہیکاتھون میں حل کیا) اور یقیناً ہیکاتھون کے منتظمین کا۔ یہ شاید اب تک کا سب سے بڑا اور بہترین ہیکاتھون تھا جس میں میں نے حصہ لیا ہے، میں صرف یہی خواہش کر سکتا ہوں کہ لڑکوں سے مستقبل میں اس طرح کا اعلیٰ معیار برقرار رہے!

ماخذ: www.habr.com