---
# System prepended metadata

title: Những kinh nghiệm trong phòng thi Tin học

---

---
title

Những kinh nghiệm trong phòng thi Tin học
---

Những kinh nghiệm trong phòng thi Tin học
=== 

---

###### ✍️ Author: 2School Guideline 
###### 📋 Content:
[TOC]

---

# Những lỗi phổ biến
- Về những lỗi phổ biến thường gặp, bọn mình đã viết một bài vô cùng chi tiết về nó. Các bạn có thể đọc tại link sau: [Những lỗi sai thường gặp trong lập trình thi đấu và cách khắc phục](https://hackmd.io/@2SchoolGuideline/SJs7S5baT)

# Chiến thuật làm bài

**Lưu ý:** Các chiến thuật làm bài mà tụi mình đề cập dưới đây chỉ có thể áp dụng được những cuộc thi có dạng **OI** (đúng bao nhiêu test ăn bấy nhiêu điểm, hoặc đúng subtask nào ăn subtask nấy)

## 1. Đọc trước qua tất cả các bài
- Khi cầm một tờ đề, ở những phút đầu, hãy đọc lướt qua tất cả các bài và sắp xếp các bài theo độ khó. Ngoài ra, thông thường ở các kì thi, bài đầu sẽ là một bài **"cho điểm"**. Tuy nhiên lại có nhiều trường hợp đáng tiếc xảy ra vì không kiểm tra chắc chắn mọi trường hợp có thể khiến bài mất điểm. Vì thế tuy là "cho điểm", nhưng hãy kiểm tra thật cẩn thận lại để tránh việc mất điểm đáng tiếc.

## 2. Duyệt trâu
- Khi ở trong phòng thi, đôi khi chúng ta sẽ không thể nghĩ ra một thuật tối ưu để đúng hết toàn bộ mọi test. Thay vì bỏ hết toàn bộ bài đó, ta hãy cố duyệt trâu để vét được nhiều điểm nhất có thể.
- Duyệt trâu (brute force), đúng như cái tên của nó, chúng ta sẽ duyệt hết mọi trường hợp có thể của đề bài và chọn cái tốt nhất. Hay đôi khi nó còn là **đề nói gì làm đó**.
- Ngoài ra, duyệt trâu còn giúp ta kiểm tra những thuật tối ưu khác mà ta nghĩ ra. Phần này sẽ được bọn mình để cập ở bên dưới.
- Một chiến thuật làm bài đối với các bài 2, 3, ... (thường những bài này sẽ là những bài đòi hỏi đưa ra các nhận xét để tối ưu bài toán): Dành ra 10 - 15 phút để nghĩ ra một thuật tối ưu cho bài này. Nếu không tìm được hãy chuyển sàng duyệt trâu vét từng subtask. Sau đó nếu còn dư thời gian **đủ nhiều**, hãy quay lại và tìm cách giải subtask cuối (nếu được) (subtask 100%). 

## 3. Chia subtask
- Thông thường, trong nhiều cuộc thi, các bài toán lớn sẽ được chia thành các bài toán nhỏ hơn hay thường được gọi là các **subtask** (**Ví dụ:** Subtask 1 $(30\%)$: $n \le 1000$). Chính vì vậy, thay vì cài một thuật cho nguyên bài, hãy chia ra làm nhiều thuật để giải cho từng subtask, tránh việc mất điểm khi mình không biết cách giải toàn bộ bài, hoặc giải được nhưng lại vì một lí do không mong muốn lại khiến toàn bộ thuật cài bị sai và mất hết điểm toàn bộ bài.
- Việc giải từng subtask cũng cho chúng ta một hướng đi nhất định để làm các subtask sau.

# Kỹ năng thi cử

Kỹ năng thi cử trong phòng thi vô cùng quan trọng để chúng ta xử lý những tình huống bug, lỗi, và hướng giải quyết tốt nhất để tránh các trường hợp đáng tiếc. Trong kỹ năng thi cử sẽ gồm kỹ năng xử lý debug, kiểm tra độ chính xác của thuật toán.

## Debug

Debug luôn là vấn đề của rất nhiều dân CP, trong đó dù code bao nhiêu năm hay mới tập code luôn sẽ bị debug cản trở rất nhiều. Mỗi người đều sẽ có những cách tiếp cận, xử lý bug và fix bug nên tụi mình chỉ sẽ đề cập một số cách, nếu muốn code chắc tay hơn thì tất nhiên việc làm nhiều bài code dài sẽ là một lựa chọn thích hợp để tự luyện kỹ năng và tư duy. Sau đây tụi mình sẽ gửi đến các bạn một số cách hiệu quả.

Ở đây tụi mình sẽ nói đến những trường hợp **Compile được nhưng trả về Runtime Error**. Thì những cách xử lý trường hợp này theo kinh nghiệm của tụi mình là :

- **Kết thúc hàm / chương trình tại tại nhiều vị trí** : khi dính bug, mọi người tìm chỗ bị bug bằng cách với mỗi hàm, vòng for, ... thì kết thúc thuật toán bằng cách thêm hàm `return`, xem là compile xong có bị RTE tiếp hay không, nếu còn thì debug và fix và nếu không thì bỏ lệnh `return` cho tới khi nào hết thì thôi.
- **Output các giá trị ra màn hình** : khi mà mọi người cảm thấy có những sai số về biến, hằng thì mọi người hãy output, kiểm tra xem là những giá trị có đúng với những tính toán trước hay không rồi sửa từ từ trên những sai số đó.

## Kiểm tra độ chính xác

Tiếp theo là đến với **độ chính xác của thuật toán**, thì tụi mình sẽ có những hướng giải quyết để kiểm tra thuật toán có chính xác hay không : 

- **Sinh test** : sinh test ở đây có nghĩa là tự tạo những input khác với đề bài và thử, kiểm tra kết quả tính trước với output có giống nhau hay không, thường thì do "test tay" nên sẽ có rất ít thời gian để xử lý những trường hợp input số lớn, nên mọi người nên sinh những test nhỏ nhỏ, vừa đủ để tính trước tránh làm mất thời gian
- **Viết trình chấm** : Đây là một kỹ thuật khá khó mà chỉ thường áp dụng cho những kỳ thi lớn như HSGQG, Olympic của cấp 3, đại học vì tính cài đặt dài của nó, nhưng tụi mình vẫn sẽ giới thiệu sơ nét về kỹ thuật này. Nếu mọi người có muốn sử dụng thì nên cân nhắc thời gian dùng, vì đây là kỹ thuật có thể đòi hỏi gấp 2, 3 lần thời gian code thuật cần stress. Stress test bao gồm **3 code gồm code thuật cần stress, code thuật chắc chắn chính xác, code sinh test**. Tụi mình sẽ mô tả như sau : 
    + **Thuật cần stress** : đây là thuật mọi người muốn kiểm tra tính chính xác của thuật
    + **Thuật chắc chắn chính xác** : đây là thuật **vét**, nên độ phức tạp sẽ cao và input xử lý sẽ thấp hơn input chuẩn nhưng đổi lại chúng ta có thể biết chính xác sự đúng đắn trong code này, và thuật này phải **đảm bảo chính xác** cho bài toán nhỏ.
    + **Thuật sinh test** : đây là thuật sinh những test thỏa mãn yêu cầu đề bài và đủ thời gian cho thuật chắc chắn chính xác chạy.

  Sau khi code xong 3 thuật toán, giờ chúng ta với bước sử dụng file, cần 1 file input và 2 file output, file input sẽ là input cho hai thuật toán cần stress và chắc chắn chính xác chạy, 2 file output là kết quả của 2 thuật đó. Sau mỗi test thì chúng ta so sánh lại kết quả nhận được giữa 2 file output có khớp hay không, nếu không khớp thì tức là thuật cần stress có vấn đề.

- Chi tiết hơn về code của những thao tác, tụi mình sẽ để lại phần tự đọc để mọi người có thể nắm rõ hơn về thao tác này : 
    + [Viết trình chấm của VNOI Wiki](https://wiki.vnoi.info/algo/skill/viet-trinh-cham)
    + [Viết trình chấm của YugiHacker](https://www.youtube.com/watch?v=UTIZpSs9BsQ)
    + [Viết trình chấm của anh Phạm Văn Hạnh](https://www.youtube.com/watch?v=jrm8gU-7B4o)

# Tổng kết

Ngoài debug ra còn có những kỹ năng khác để tránh những vấn đề lỗi, bug. Nhưng chung quy lại thì mỗi kỹ năng đều có mặt tốt và mặt xấu, khi làm bài cần xử lý tốt thông qua code nhiều bài khó. Ưu tiên hàng đầu vẫn là tránh bị các lỗi lặt vặt. Sau đây tụi mình sẽ gửi đến mọi người một số bài viết khác về kỹ năng thi cử : 
    - [Kinh nghiệm tuyển sinh 10 của anh Võ Khắc Triệu](https://hackmd.io/@DeMen100ms/SyRDbZCr3?fbclid=IwZXh0bgNhZW0CMTAAAR3vakerOcM1jm4LAiv3Js4MWKy-gE6h68GEGihri12akRzMY5BcWU5c6Qo_aem_AaBFDq7WNjg3TxnjxElXN4Oh1sMkJtIyuCICDPmapx0r9MPh5Q4c5AWfo9Al8gbDWwasjdk_LIDQN2T2PXB7rjca)
    - [Kinh nghiệm thi cử của VNOI Wiki](https://wiki.vnoi.info/algo/skill/Ki-nang-thi-cu)
    - [Kinh nghiệm thi VOI của VNOI Wiki](https://wiki.vnoi.info/algo/skill/Kinh-nghiem-thi-VOI)
    
Hai bài viết cuối có thể sử dụng nhiều hơn kỹ năng cần thiết cho Tuyển sinh 10, nhưng mọi người có thể đọc và tham khảo, chọn lọc những kỹ năng cần thiết.
    
Cuối cùng đây là lời kết của bài viết, dù là kỹ năng hay kinh nghiệm gì thì trước mắt mọi người nên chuẩn bị thời gian ôn tập đầy đủ cho các môn thi và không được lãng phí thời gian học những kỹ năng, kiến thức khó, ngoài lề khỏi chương trình thi. Ban Tin học của 2SG tụi mình chúc mọi người ôn tập tốt, thuận lợi, sức khỏe ổn định cho kỳ thi bước vào cấp 3 nhé !!
