یک مسابقه‌ی المپیاد معمولاً شامل سه سؤال الگوریتمی است که باید در مدت‌زمان ۵ ساعت حل شوند. یکی از عوامل اصلی موفقیت در هر آزمون، داشتن برنامه و استراتژی مشخص و پایبند بودن به آن در زمان آزمون است.

برخی از سؤال‌هایی که باید قبل از آزمون به آن‌ها فکر کرده باشید و برایشان پاسخ مشخصی داشته باشید، از این قرارند:

• چگونه شروع کنم؟
• آیا بهتر نیست در ابتدای مسابقه به حل تئوری مسائل بپردازم و بعد به کدنویسی؟
• برای حل هر مسئله، از ابتدای خواندن سؤال تا انتهای کار، چه فرایندی را طی کنم؟
• اگر به باگ برخورد کردم، برای رفع آن چه میزان وقت بگذارم؟
• در ساعت پایانی مسابقه، اگر بیش از یک مسئله‌ی حل‌نشده داشته باشم، چه کار کنم؟
• چه زمانی به‌جای حل مسئله‌ی اصلی، به سراغ زیرمسئله‌های ساده‌تر آن بروم؟
• در زمان آزمون، اگر موضوعی غیرمرتبط، مثل سرفه کردن دیگران، اذیتم کرد، چه کار باید بکنم؟
• اگر در روز آزمون بیمار بودم، چه کار باید بکنم؟
• و سؤال کلی‌تر: در هر ساعت از آزمون چه کارهایی باید انجام بدهم؟

شما باید سعی کنید در آزمون‌های تمرینی، جواب سؤال‌های بالا و سؤال‌های مشابه را پیدا کنید. یعنی در هر آزمون تمرینی، یک استراتژی خاص را تجربه کنید و در نهایت ۲ یا ۳ استراتژی را که متناسب با روحیه و شخصیت شما هستند و در آزمون‌های تمرینی نتیجه‌ی خوبی داده‌اند، انتخاب کنید و در آزمون‌های اصلی به آن استراتژی و برنامه‌ها پایبند باشید.

بی‌برنامه بودن در حین آزمون، تقریباً به‌طور قطع می‌تواند منجر به شکست‌های بزرگی شود. در ادامه، توصیه‌هایی برای کمک به طراحی استراتژی آزمون ارائه شده است.

• خواب کافی: اگر قبل از مسابقه به‌اندازه‌ی کافی نخوابیده باشید، ناخواسته سرعت و دقت ذهن‌تان پایین می‌آید. در صورت غیرمتعارف بودن زمان مسابقه یا تغییر time-zone، اهمیت این موضوع بیشتر می‌شود. برای آزمون‌های مهم، سعی کنید زودتر از ساعات عادی برای خواب اقدام کنید تا در صورت دیرتر به خواب رفتن، دچار مشکل نشوید. از طرف دیگر، حداقل دو ساعت قبل از آزمون از خواب بیدار شوید تا در طول آزمون از هوشیاری کامل برخوردار باشید.
• عادات غذایی: به عادت‌های غذایی خود قبل و حین مسابقه توجه داشته باشید. اگر وجود خوراکی خاصی را حین مسابقه لازم می‌دانید، از فراهم بودن آن مطمئن باشید؛ ولی شرایط فراهم نشدن آن به هر دلیلی را هم در نظر بگیرید. سعی کنید وابستگی خود به خوراکی یا نوشیدنی خاصی را کم کنید. در آزمون‌های طولانی، اگر به مصرف خوراکی در طول آزمون عادت دارید، بهتر است از قبل مشخص کنید چه زمانی و چه چیزی مصرف خواهید کرد و در آزمون‌های تمرینی نیز همین برنامه را امتحان کنید.
• قدرت تایپ سریع: برنامه‌نویسان خوب برای تایپ به صفحه‌کلید نگاه نمی‌کنند و از همه‌ی انگشتان برای تایپ استفاده می‌کنند. سایت‌ها و نرم‌افزارهای زیادی برای آموزش تایپ انگلیسی ده‌انگشتی وجود دارد. سرعت بالای تایپ، بدون نیاز به توجه به صفحه‌کلید، باعث می‌شود بتوانید تمرکز بیشتری روی محتوای برنامه‌ای که می‌نویسید داشته باشید.
• صفحه‌کلید: تایپ سریع و بدون نیاز به نگاه کردن به صفحه‌کلید، مستلزم استفاده از صفحه‌کلیدی استاندارد و آشناست. با انتخاب یک صفحه‌کلید استاندارد مناسب خود، در همه‌ی آزمون‌ها (آزمایشی و اصلی) از همان صفحه‌کلید استفاده کنید. خوش‌بختانه در بسیاری از مسابقات مطرح برنامه‌نویسی، امکان استفاده از صفحه‌کلید شخصی به مسابقه‌دهندگان داده می‌شود. در تصویر زیر، چینش استاندارد صفحه‌کلید را مشاهده می‌کنید.
• ماوس: با توجه به این‌که در مسابقات رسمی ماوس در اختیارتان هست ولی touch-pad نیست، سعی کنید حین برنامه‌نویسی از touch-pad استفاده نکنید تا به آن عادت نکنید. این مشکل بیشتر در افرادی ظاهر می‌شود که با لپ‌تاپ کار می‌کنند. اگر عادت به استفاده از touch-pad دارید، در زمان برنامه‌نویسی و مسابقه دادن آن را غیرفعال کنید.
• محیط کار: در آزمون‌های تمرینی تا حد امکان شرایطی شبیه آزمون اصلی ایجاد کنید. استفاده از ابزارهایی که در آزمون اصلی در دسترس نخواهند بود یا عادت کردن به محیطی کاملاً متفاوت، ممکن است در روز مسابقه برایتان مشکل ایجاد کند.

• مجموعه‌کارهایی را که در آغاز هر مسابقه باید روی یک کامپیوتر تازه انجام دهید، از قبل مشخص کنید. مواردی از این قبیل:

• نوشتن اسکریپت‌های کمکی و Makefile
• تنظیمات سیستم‌عامل
• تنظیمات IDE
• شاخه‌بندی برای نوشتن برنامه‌ها
• یک قالب (template) کد برای خود طراحی کنید تا برای هر کد جدید لازم نباشد از صفر شروع کنید.
• قالب کد برای زمینه‌های مختلف می‌تواند متفاوت باشد. مثلاً قالب کد برای برنامه‌های هندسی می‌تواند توابع پایه‌ای هندسی را نیز شامل شود.
• باید در نوشتن قالب کد خود کاملاً روان باشید، به‌طوری که از درستی آن اطمینان داشته باشید.
• می‌توان قالب کد را در ابتدا یک‌بار به‌طور کامل نوشت. همچنین می‌توان به‌شکل افزایشی آن را کامل کرد؛ یعنی در ابتدای هر برنامه‌ی جدید، موارد لازم آن برنامه را به قالب اضافه کرد.
• در آزمون اصلی، زمان زیادی را صرف شخصی‌سازی محیط نکنید. هر کاری که می‌توانید از قبل آماده کنید، بهتر است در آزمون‌های تمرینی انجام دهید.

• در ابتدای کار بهتر است همه‌ی سؤال‌ها را روی کاغذ (نه روی صفحه‌نمایش) بخوانید.
• در خواندن دقیق سؤال‌ها کوتاهی نکنید، چرا که بعضاً دیده شده است که به‌خاطر ناقص خواندن سؤال‌ها، یک شخص یک یا دو ساعت از وقت آزمون را از دست داده است. مواردی وجود داشته که یک سؤال به‌خاطر درست خوانده نشدن، بسیار ساده‌تر و در مواردی بسیار پیچیده‌تر از نسخه‌ی اصلی سؤال درک شده است. در حالت اول، مسابقه‌دهنده وقت خود را صرف راه‌حلی درست برای سؤال خودش کرده و از قابل قبول نبودن آن در مسابقه متعجب شده است. در حالت دوم، مسابقه‌دهنده از حل سؤال درمانده شده یا درگیر راه‌حلی پیچیده گشته است.
• بعضی‌ها عادت دارند زیر نکات مهم سؤال خط بکشند یا با مارکرهای رنگی آن‌ها را highlight کنند. این کار می‌تواند مفید باشد، ولی مواظب باشید نکات highlight نشده از قلم نیفتند.
• سعی کنید با توجه به تجربه و دانش خود، مسائل را به لحاظ مرتبه‌ی سختی مرتب کنید. هرچه در حل مسئله تجربه‌ی بیشتری داشته باشید، ترتیب شما به واقعیت نزدیک‌تر خواهد بود.
• محدودیت‌ها، تعداد زیرمسائل، نوع خروجی، محدودیت زمان و حافظه و تمام جزئیاتی را که ممکن است روی الگوریتم تأثیر بگذارند، هنگام خواندن سؤال مشخص کنید.
• بعد از خواندن سؤال، قبل از ورود به جزئیات پیاده‌سازی، سعی کنید در ذهن خود تصویری کلی از مسئله و دشواری احتمالی آن داشته باشید. این کار کمک می‌کند زمان خود را آگاهانه‌تر بین مسائل تقسیم کنید.

• معمولاً اولین قدم در حل مسائل المپیاد کامپیوتر، مدل‌سازی مسئله به فرم ریاضی و حذف زوائد آن است. هزینه‌ی اشتباه در این قدم کمتر از اشتباه در خواندن صورت سؤال نیست. کافی است یکی از شرط‌های صورت سؤال در مدل جدید دیده نشود.
• یکی از روش‌های حل مسئله، حذف جزئیات بی‌مورد و تبدیل آن به مسائل ساده‌تر است که به آن کاهش (Reduction) نیز گفته می‌شود. بسیاری از مسائلی که در ابتدا پیچیده به نظر می‌رسند، با چند مرحله ساده‌سازی به مسائلی آسان تبدیل می‌شوند. ولی این ساده‌سازی‌ها خطرات خودشان را هم دارند. کافی است گزاره یا شرط خاصی از مسئله‌ی اولیه را در مسئله‌ی ثانویه لحاظ نکنیم یا فرض اضافه‌ای را در مسئله‌ی ثانویه در نظر بگیریم تا دیگر کاهش ما به‌کلی نادرست باشد. به‌اصطلاح، مسئله‌ی ثانویه‌ی انتخابی باید حداقل به اندازه‌ی مسئله‌ی اولیه دشوار باشد؛ یعنی حل مسئله‌ی ثانویه باید واقعاً شما را به حل مسئله‌ی اولیه برساند.
• ولی گاهی در رعایت این نکته، خطر افتادن از طرف دیگر بام وجود دارد و مسئله‌ی ثانویه‌ی انتخابی چنان تعمیم‌یافته و پیچیده‌تر از مسئله‌ی اولیه می‌شود که دیگر به‌راحتی قابل حل نیست. مثلاً مسئله‌ی اولیه «شناسایی بلندترین مسیر در DAG» بوده (که الگوریتم چندجمله‌ای ساده‌ای دارد)، و مسئله‌ی ثانویه «شناسایی بلندترین مسیر در گراف جهت‌دار دلخواه» شده (که مسئله‌ای NP-Complete است). گاهی با حل یک مسئله‌ی واسط مناسب یا بررسی دقیق رابطه‌ی بین مسئله‌ی اصلی و مسئله‌ی ساده‌شده می‌توان از چنین اشتباهی جلوگیری کرد.
• با نگاه به پارامترهای ورودی زیرمسائل یک مسئله، سعی کنید زمان اجرایی را که برای هر زیرمسئله مدنظر است پیدا کنید. به‌عنوان مثال، اگر مسئله فقط یک پارامتر ورودی به نام $n$ دارد و دارای دو زیرمسئله است که در زیرمسئله‌ی اول $n \leq 10^4$ است و در زیرمسئله‌ی دوم $n \leq 10^8$ است (با این فرض که کامپیوتر شما حدوداً $10^8$ عمل در ثانیه انجام می‌دهد)، احتمالاً در زیرمسئله‌ی اول باید به دنبال راه‌حلی با زمان اجرای $O(n^2)$ باشید و برای زیرمسئله‌ی دوم، راه‌حلی با زمان اجرای $O(n\log^c n)$ مناسب است ($0 \leq c$). البته باید توجه کرد که این مرتبه‌های زمان اجرا تنها یک تخمین کلی از حد بالای قابل قبول هستند و ممکن است مسئله راه‌حل‌های ساده با زمان اجراهای بهتر یا بدتر، بسته به عملیات الگوریتم، داشته باشد.
• با ساده‌ترین زیرمسئله شروع کنید و برای آن راه‌حلی پیدا کنید. معمولاً در چند دقیقه می‌توان راه‌حل تئوری برای ساده‌ترین زیرمسئله پیدا کرد. این کار به شما کمک می‌کند درک درستی نسبت به مسئله پیدا کنید و از بیراهه رفتن شما جلوگیری می‌کند.
• بعد از به‌دست آوردن درک درست از مسئله، به دنبال بهترین راه‌حل برای آن باشید. اگر چندین راه‌حل به ذهن شما رسید، آن راه‌حلی را انتخاب کنید که پیاده‌سازی ساده‌تر و احتمال خطای کمتری داشته باشد.
• حتماً درستی الگوریتم خود را بررسی کنید و آن را روی ورودی‌های کوچک و ساده تست کنید.
• اگر راه‌حلی که در ذهن دارید حریصانه است، با دیده‌ی شک به آن نگاه کنید و کمی به دنبال مثال نقض برای آن بگردید. در بسیاری از موارد برای الگوریتم‌های حریصانه‌ای که به ذهن می‌آیند، می‌توان به‌سادگی مثال نقض پیدا کرد.
• حالت‌های tricky را سعی کنید پیدا کنید و بر اساس آن‌ها الگوریتم خود را به قسمت‌های مختلف بشکنید.
• پس از طراحی الگوریتم، ترجیحاً قبل از شروع به کدنویسی، یک دور دیگر صورت سؤال را بخوانید تا مطمئن شوید راه‌حل‌تان برای سؤال درست است و چیزی از قلم نیفتاده است. اگر صورت سؤال بلند و دارای جزئیات است، با توجه به بالا بودن خطر فراموش شدن نکته‌ای، مرور مجدد صورت سؤال ارزشش را دارد. و اگر صورت سؤال کوتاه بود، هزینه‌ی این کار کم است!
• تا نسبت به الگوریتم خود مطمئن نشده‌اید، کدنویسی را شروع نکنید. وقتی کدنویسی را شروع کردید، دیگر نباید به‌طور هم‌زمان درگیر تغییر اساسی ایده‌ی الگوریتم باشید.
• قبل از شروع کدنویسی، یک بار پیچیدگی زمانی و حافظه‌ی الگوریتم را با محدودیت‌های سؤال مقایسه کنید. ممکن است یک ایده از نظر منطقی درست باشد، ولی با محدودیت‌های مسئله قابل اجرا نباشد.
• اگر راه‌حل کامل مسئله را پیدا نکرده‌اید، ولی یک زیرمسئله‌ی ساده را می‌توانید حل کنید، ارزش نمره‌ی آن را در نظر بگیرید. در مسابقه، گرفتن نمره‌ی قطعی بهتر از صرف زمان طولانی برای ایده‌ای است که هنوز از درستی آن مطمئن نیستید.

• هدف از کدنویسی صرفاً سریع کد زدن نیست. هدف آن است که در انتها یک کد صحیح و تمیز داشته باشید. صرف وقت برای نوشتن کد صحیح و تمیز، شما را از مواجهه با باگ نجات می‌دهد؛ مخصوصاً باگ‌هایی که در دقایق پایانی به آن‌ها پی می‌برید و دیگر فرصتی برای رفعشان ندارید.
• قبل از شروع کد، حتماً ساختار کلی آن را در ذهن خود و در موارد پیچیده، حتماً روی کاغذ، مرور کنید. به سؤال‌هایی از این دست باید پاسخ‌های مشخصی داشته باشید:
• هر قسمت از برنامه چه چیزهایی را (به‌عنوان ورودی و داده‌های کمکی) نیاز دارد و چه چیزهایی را (به‌عنوان خروجی) فراهم می‌کند؟
• متغیرهای سراسری برنامه کدام‌ها خواهند بود و چه چیزهایی تنها در یک قسمت خاص برنامه کاربرد دارد؟
• گلوگاه‌های زمان اجرا و حافظه‌ی برنامه کجاها خواهند بود؟
• اگر لازم شود زمان اجرای برنامه را بهبود دهیم، کجاهای برنامه تغییر می‌کنند و این تغییرات چقدر در بخش‌های دیگر برنامه تأثیر می‌گذارند؟
• قسمت‌های پیچیده‌تر برنامه و جاهایی که احتمال باگ زدن در آن‌ها بیشتر است، کدام‌اند؟
• هر قسمت از کد را که می‌نویسید، همان قسمت را تست کنید تا از درستی آن مطمئن شوید. تست کردن قسمت‌های کوچک برنامه خیلی ساده‌تر از تست کردن یک برنامه‌ی بزرگ چندقسمتی است. هرچه در برنامه‌ی خود از بلوک‌هایی استفاده کنید که قبلاً تست شده‌اند، بیشتر می‌توانید توجه و تمرکز خود را صرف بخش‌های دیگر برنامه کنید.
• اگر به‌ترتیب روند اجرای برنامه کدتان را بنویسید، می‌توانید از داده‌های ورودی نمونه که در اختیارتان گذاشته شده است برای تست هر قسمت جدیدی که می‌نویسید استفاده کنید.
• برای قسمت‌هایی که احساس می‌کنید به خاطر سپردن آن‌ها سخت است، حتماً کامنت بگذارید؛ چرا که بعضی وقت‌ها بعد از مدت طولانی به آن قسمت برمی‌گردید و اگر کامنتی ننوشته باشید، فهم آن قسمت از کد زمان زیادی از شما خواهد گرفت.
• هرگاه قرار است بخشی از کدتان را با کد جدیدی جایگزین کنید (مثلاً وقتی باید یک قسمت از کد خود را بهینه کنید)، حتماً یک کپی از کد فعلی خود را در یک فایل دیگر ذخیره کنید. فایل اصلی خود را که در حال نوشتن در آن هستید، هیچ‌گاه تغییر نام ندهید و تنها نسخه‌های پشتیبان را با نام‌های مشخص بسازید. مثلاً اگر در حال نوشتن در book.cpp هستید، همیشه برنامه‌ی اصلی خود را که در حال ویرایش و تست و نهایتاً submit کردن آن هستید، در همین فایل بگذارید و نسخه‌های پشتیبان را با نام‌هایی مانند book0.cpp یا book-n2.cpp ذخیره کنید. این قرارداد باعث می‌شود از خطاهای رایج جابه‌جا گرفتن فایل‌ها در زمان اجرا، تست و ارسال برنامه‌ها جلوگیری شود.
• اگر در هر قسمتی از کد، نکته‌ای از جای دیگر کد به ذهن‌تان خطور کرد، حتماً در جایی یادداشت کنید. استفاده از حافظه در این موارد اصلاً توصیه نمی‌شود. داشتن یک TODO-List برای هر سؤال مفید است.
• به قوانین مهندسی نرم‌افزار در زمینه‌ی کدنویسی حتماً در طول زمان اصلی کدنویسی پایبند باشید. فقط در فاز نهایی و رفع باگ، اجازه‌ی شکستن قواعد را به خود بدهید.
• نام‌گذاری مناسب متغیرها و توابع را جدی بگیرید. در یک برنامه‌ی طولانی، چند دقیقه‌ای که برای نام‌گذاری مناسب صرف می‌کنید، ممکن است در زمان رفع باگ چندین برابر به شما کمک کند.
• تا حد امکان از تغییر هم‌زمان چند قسمت برنامه خودداری کنید. اگر یک تغییر کوچک انجام داده‌اید، ابتدا همان تغییر را تست کنید و سپس سراغ تغییر بعدی بروید.

• هیچ‌گاه برای دادن تست‌ها به برنامه‌تان از تایپ با صفحه‌کلید یا copy-paste در کنسول استفاده نکنید. هر تست را در یک فایل متنی ذخیره کنید و با redirection آن را به برنامه‌ی خود بدهید. با این کار ممکن است هزینه‌ی اجرای هر تست برای بار اول کمی بیشتر از حالت عادی باشد، ولی امکان اجرای سریع تست‌ها در دفعات بعدی، این هزینه‌ی زمانی را به‌سرعت جبران می‌کند. معمولاً در شروع تست برنامه، یک احساس نادرست می‌گوید دفعه‌ی بعدی‌ای در کار نیست و در نتیجه رعایت این قاعده لازم نیست. ولی کافی است به تجربه‌ی خود مراجعه کنید تا ببینید احتمال این‌که برنامه‌تان در اولین اجرا همه‌ی تست‌ها را به‌درستی جواب دهد و دیگر نیاز به تغییر و تست مجدد نداشته باشد، چقدر کم است. علاوه بر آن، تست‌های ذخیره‌شده هستند که تست بلوک‌به‌بلوک برنامه را امکان‌پذیر می‌کنند.
• حتماً وقت مناسبی، در حد نیم ساعت در یک آزمون ۵ ساعته، برای تست برنامه‌ی خود بگذارید.
• اگر فرصت دارید، یک راه‌حل صحیح و ساده (هرچند کند) برای مسئله بنویسید و در ضمن یک تولیدکننده‌ی تست‌دیتا نیز آماده کنید.
• خروجی برنامه‌ی اصلی و برنامه‌ی کندی را که آماده کرده‌اید، روی تست‌دیتاهایی که آماده کرده‌اید مقایسه کنید. برای انجام این مقایسه نیز کافی است یک برنامه‌ی کوچک بنویسید یا از دستورهای موجود در سیستم‌عامل استفاده کنید.
• تست حالت‌های خاص را فراموش نکنید. باگ‌ها بیشتر در گوشه‌وکنارها دیده می‌شوند!
• در یک مجموعه تست خوب، هر خط و هر عبارت برنامه حداقل در یک تست اجرا می‌شود.
• حتماً روی چند تست نمونه‌ی بزرگ برنامه‌ی خود را تست کنید تا مثلاً به‌خاطر overflow برنامه‌ی شما اشتباه کار نکند، یا اگر به‌خاطر اشتباه، زمان اجرا یا حافظه‌ی برنامه‌تان از حد مجاز خارج می‌شد، متوجه این موضوع شوید.
• در کنار تست‌های تصادفی، تست‌های هدفمند نیز طراحی کنید؛ یعنی تستی بسازید که دقیقاً یک فرض یا قسمت حساس الگوریتم شما را به چالش بکشد.
• اگر برای مسئله راه‌حل ساده و کندی نوشته‌اید، تست‌های تصادفی کوچک یکی از بهترین ابزارها برای پیدا کردن مثال نقض در الگوریتم اصلی هستند.
• اساساً تست یک برنامه توسط سازنده‌اش خلاف فطرت اوست! هرچه احساس گریز بیشتری نسبت به تست برنامه‌تان دارید، احتمال داشتن باگ در آن برنامه بیشتر است!

• اگر نمی‌خواهید زیاد با باگ مواجه شوید، حتماً در حین کدنویسی اجزای برنامه‌ی خودتان را تست کنید.
• اگر وقت زیادی را صرف رفع باگ کردید، حتماً به زمان نیم‌نگاهی داشته باشید تا ببینید ادامه‌ی این روند مفیدتر است یا سراغ سؤال دیگری رفتن.
• بعضی وقت‌ها دوباره کدنویسی کردن یک جزء از برنامه، زمان کم‌تری نسبت به پیدا کردن و رفع باگ آن می‌گیرد.
• شما می‌توانید از ابزارهای موجود مثل gdb برای پیدا کردن محل خطای حافظه استفاده کنید.
• می‌توانید با گذاشتن دستورهایی در لابه‌لای کد، مقدار پارامترها را بررسی کنید تا شاید از این طریق بتوانید باگ را پیدا کنید.
• اگر بعد از مدت مشخصی نتوانستید باگ را برطرف کنید، سراغ مسئله‌ی دیگری بروید و بعد از حل آن، با انگیزه و انرژی بیشتر مجدداً به رفع باگ مسئله‌ی اول برگردید.
• هنگام رفع باگ، سعی کنید ابتدا یک ورودی کوچک پیدا کنید که باگ در آن رخ می‌دهد. سپس اجرای برنامه را روی همان ورودی مرحله‌به‌مرحله بررسی کنید. پیدا کردن کوچک‌ترین ورودی‌ای که باگ را نشان می‌دهد، معمولاً فرایند رفع باگ را بسیار ساده‌تر می‌کند.
• اگر مطمئن نیستید باگ از الگوریتم است یا از پیاده‌سازی، ابتدا الگوریتم را روی یک مثال کوچک دستی اجرا کنید. این کار کمک می‌کند این دو نوع خطا را از یکدیگر جدا کنید.

• اگر فرایند درست و مشخصی داشته باشید، در ارسال فایل برنامه‌ی خود اشتباه نمی‌کنید.
• قبل از ارسال راه‌حل، حتماً یک‌بار دیگر برنامه را کامپایل و تست کنید.
• قبل از submit کردن، مطمئن شوید فایل درست را انتخاب کرده‌اید و نسخه‌ای که ارسال می‌کنید همان نسخه‌ای است که آخرین بار تست کرده‌اید.
• اگر سامانه‌ی مسابقه محدودیت یا فرمت خاصی برای ارسال دارد، آن را از قبل در آزمون‌های تمرینی امتحان کنید.
• داشتن یک چک‌لیست برای زمان ارسال راه‌حل، شامل باگ‌ها و خطاهای رایج احتمالی و کارهای لازم پیش از ارسال، توصیه می‌شود.

• زمان مسابقه را از ابتدا تا انتها در ذهن داشته باشید. اگر برای یک مسئله بیش از زمانی که در استراتژی خود تعیین کرده‌اید پیشرفت نکرده‌اید، احتمالاً باید تصمیم بگیرید که مدتی آن را رها کرده و سراغ مسئله‌ی دیگری بروید.
• هر بار که از یک مسئله به مسئله‌ی دیگر می‌روید، دلیل مشخصی برای این کار داشته باشید. جابه‌جایی مداوم بین مسائل بدون دلیل مشخص، یکی از راه‌های هدر دادن زمان است.
• در نیمه‌ی مسابقه یک ارزیابی مجدد انجام دهید: چه نمره‌ای گرفته‌اید؟ چه مسئله‌ای هنوز امیدبخش است؟ کدام ایده‌ها ارزش ادامه دادن ندارند؟ این ارزیابی را بر اساس وضعیت واقعی مسابقه انجام دهید، نه بر اساس زمانی که قبلاً برای هر مسئله صرف کرده‌اید.
• اگر یک زیرمسئله‌ی ساده‌ی یک مسئله قابل حل است، آن را جدی بگیرید. از نمره‌های قابل دستیابی به‌خاطر اصرار بر حل نسخه‌ی سخت مسئله نگذرید.
• در ساعت پایانی مسابقه، اولویت با تبدیل تلاش‌های نزدیک به نتیجه به نمره‌ی قطعی است. در این زمان معمولاً شروع یک ایده‌ی کاملاً جدید ریسک بالایی دارد؛ مگر این‌که شواهد خوبی برای موفقیت آن داشته باشید.
• نزدیک پایان مسابقه، زمانی را برای کامپایل نهایی، تست، بررسی فایل و ارسال در نظر بگیرید. ارسال را به آخرین دقیقه موکول نکنید.

• در آزمون‌های تمرینی حتماً یک لاگ از کارها و زمانی که برای آن‌ها صرف کرده‌اید نگه دارید. این کار به شما کمک می‌کند استراتژی خود را بعد از آزمون ارزیابی کرده و احتمالاً آن را بهبود دهید.
• حفظ آرامش در آزمون، حتی در بدترین شرایط، نتیجه‌ی بهتری برای شما رقم خواهد زد.
• از تصمیم‌گیری احساسی بپرهیزید و از switch سریع بین مسائل خودداری کنید.
• اگر زیرمسائل سخت یک مسئله قابل حل نیست، حتماً به سراغ زیرمسائل ساده‌تر بروید و به هیچ‌وجه از نمرات بدیهی که می‌توانید در آزمون کسب کنید نگذرید.
• آزمون‌های اصلی محل امتحان کردن ابزارهای برنامه‌نویسی، کتابخانه‌ها و الگوریتم‌هایی نیست که جدیداً یاد گرفته‌اید و بر آن‌ها مسلط نیستید.
• اصرار بی‌جا بر حل یک مسئله و رها کردن بقیه‌ی مسائل در حین آزمون اصلی شدیداً نهی می‌شود. قرار نیست روی یک مسئله یا یک زیرمسئله را حتماً کامل کنید!
• در آزمون‌های تمرینی فقط نتیجه‌ی نهایی را بررسی نکنید. بررسی کنید کجا زمان از دست داده‌اید، کجا تصمیم اشتباه گرفته‌اید و کدام باگ‌ها قابل پیشگیری بوده‌اند. هدف آزمون تمرینی، بهتر شدن برای آزمون بعدی است، نه فقط گرفتن یک نمره‌ی خوب در همان آزمون.
• مهم‌تر از همه، استراتژی مسابقه چیزی نیست که یک‌بار برای همیشه انتخاب شود. آن را در آزمون‌های تمرینی امتحان کنید، نقاط ضعفش را پیدا کنید و به‌تدریج استراتژی‌ای بسازید که با توانایی‌ها، روحیه و سبک حل مسئله‌ی خودتان بیشترین سازگاری را داشته باشد.