[CP - Chiến] 2025/12/12 - The 2025 ICPC Asia HCMC Regional Contest (edited)
Mở đầu
Mình có thể không phải là người giỏi nhất (dù cũng từng có thời gian được đánh giá như vậy), nhưng chắc chắn là người có thể tạo ra những kỷ lục vô tiền khoáng hậu. Nếu ở THPT mình đã là người duy nhất tham dự cả 3 mùa HSGQG và THTTQ và đạt cùng một loại giải (you know what it is), thì đây là năm thứ 81 mình từng tham dự một kỳ ICPC (và sẽ cố gắng nâng con số lên thành 10).
Năm nay, đội hình vẫn giữ nguyên. Điều duy nhất khác biệt là mình đã có cà phê hỗ trợ một phần, team đã có luyện tập nên có tí chiến thuật, và đứng sát ranh giới APAC hơn bao giờ hết.
Hôm nay, chúng ta sẽ cùng nhau mổ xẻ diễn biến phòng thi của team Hesll, và phân tích tại sao mình đã tuột tay nắm cửa của ICPC Asia-Pacific Championship *sầm*.
Diễn biến
| Rank 32 | A | B | C | D | E | F | G | H | I | J | K | L | M |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 6 bài | +1 | + | + | -1 | -2 | + | +3 | +13 | |||||
| 1110 phút | 223 | 12 | 19 | 16 | 202 | 98 |
[0:00] Bắt đầu thời gian làm bài. Mình không đọc đề từ đầu, mà dành ra 2p đầu tiên để:
- Đầu tiên là bật chức năng auto-save
- Tiếp theo là chỉnh lại đường dẫn trình biên dịch. Hôm thi Siêu CUP thì mình phát hiện ra ban Tổ chức config nhầm đường dẫn compiler C++ từ
/usr/bin/g++thành/usr/bin/gcc, nên tính năng gợi ý code của IntelliSense hoàn toàn không hoạt động được, hôm nay chỉnh liền. - Cuối cùng là gõ sơ bộ vài dòng template ban đầu.
Cơ bản là đằng nào cũng chỉ có một mình mình code, nên:
- Nếu mình đọc đề trước:
- nếu chưa gặp được bài dễ mà đồng đội ném bài dễ sang thì mình tốn mấy phút đọc đề lãng phí + thời gian setup trước khi code
- nếu mình gặp bài không đủ dễ + mình lag thì toang penalty.
- Thay vào đó, vài phút đầu tiên setup, giao hẳn bộ đề cho đồng đội sẽ không có thời gian thừa
- khalachackeo tới lúc setup xong đã tìm ra bài để code luôn, với độ khó của Regional.
- tầm nửa giai đoạn đầu, solution sẽ được feed liên tục cho mình, mình chỉ cần việc code thôi.
Chiến thuật đấy giúp team mình luôn nằm trong top đầu bảng rank suốt một tiếng đầu tiên, làm bàn đạp cho 4 tiếng tiếp theo. Ở Regional thì đề khó hơn nhưng đoạn đầu feed 3 bài còn mượt hơn cả National.
20 phút đầu
Đức nhìn thấy bài D dễ nhất, nên ném đề cho mình đọc.
Bài D: Cho bảng trống \(n \times n\), điền các số sao cho có nhiều nhóm \(k\) ô liên tiếp theo chiều ngang hoặc dọc có tổng chia hết cho \(k\), với \(k \leq n\).
Mình nghĩ ra ngay chuyện xếp liên tiếp (k số liên tiếp chia hết cho k) nhưng không biết offset như nào, hỏi Nana thì Nana bảo chỉ cần là cấp số cộng, nên làm luôn.
[0:12] AC bài D.
Tiếp theo thì Nana tóm tắt đề bài K, đơn giản là check xem biên bản ván đấu có chuẩn không.
[0:16] AC bài K.
Sau đó Nana vẽ một cái đồ thị và phán chỉ cần lo các cạnh nối giữa nhóm 1-2, 2-3, 3-4, 4-1.
[0:19] FIRST SOLVE bài E.
180 phút kinh hoàng
Đầu tiên bọn mình tính đấm F với thuật tham lam chuyển hết B thành A.
[0:47] WA bài F. Sau một hồi thì cũng tìm được edge cases. Mình quyết định bỏ bài đấy, nhưng có hỏi Nana xem có luôn chuyển xâu về hoặc full xen kẽ ABAB..., hoặc full A (+B đầu/đuôi) hay không.
Sau đó thì có A và L.
Bài AA: Cho \(n\) ụ nước \(a_1, a_2, \dots, a_n\) và hàm \(f(x)\), giá trị của cả hệ thống là \(\sum f(a_i)\). Lần lượt chọn ra hai ụ nước kề nhau tùy ý và gộp lại, hãy tìm cách gộp để mảng \(a\) còn đúng \(k\) ụ nước, sao cho giá trị của hệ thống là lớn nhất.
Bài L – một bài Interactive: Cho một danh sách liên kết đơn độ dài \(n\), nhưng liên kết của node cuối thay vì là
nullthì là một trong các node trước đó, tạo thành một chu trình. Ban đầu bạn đứng ởnode = headvà không biết trước \(n\) hay độ dài của chu trình, nhưng trước mỗi lượt di chuyểnnode = node.nextbạn được phép đánh dấu vĩnh viễn node hiện tại. Xác định độ dài chu trình trong không quá \(3n\) lượt di chuyển.
Không nhớ là làm AA hay làm L trước, nhưng cụ thể là như này:
- L thì nhìn là biết sẽ có một cái marking pattern nào đấy, phase 1 cứ mark, tới khi thăm một ô marked thì sang phase 2 tìm chu trình. Có hai pattern trong đầu: theo 2 mũ, hoặc theo mod 3.
- A thì lúc đấy thấy nhiều đội làm được, mình nghĩ là thuật của AA sẽ dễ thôi – kiểu như tìm chênh lệch sau khi bỏ một cột, rồi sort lại. Đức bảo bài A này tìm kiếm nhị phân, cơ mà mình không tin lắm tại nhìn AA không quy về bài toán kiểm tra được.
Lúc mình viết bài này thì mình không nhớ code AA trước hay L trước, nhưng nếu phải tận phút 135 mới có lần nộp bài tiếp theo thì chắc là code AA trước. Sai test ví dụ, mình nhờ Nana check công thức. Nana đưa ra một công thức khác, mình code theo, lại sai test ví dụ.
- Thực ra lúc vẽ công thức ra đã thấy sai sai, hình như công thức không độc lập với từng cột.
- Cơ mà trong phòng thi mình cũng không tỉnh táo lắm, nên vẫn nghĩ thuật là như vậy.
Thế là mình chuyển qua L. Có vẻ như trong phòng thi mình khá dở – mình không có check kỹ số câu được hỏi của ý tưởng chiến thuật, mà phang đại mod 3.
[2:15] TLE bài L.
[2:16] WA bài L.
Mình không nhớ mình lại tiếp tục đấm A hay tiếp tục cố chấp L, nhưng sau đó Nana đưa bài H và bảo là xóa cạnh lớn nhất.
[2:37] WA bài H.
[2:38] WA bài H sau khi sửa lại gì đấy.
Mình phát hiện ra trường hợp sai là hình thoi siêu dài, khi đó đường đi không nằm trên bao lồi mà sẽ có đi chéo. Bảng điểm lúc đó rất ít đội làm được H, nên mình nghĩ đây là bài khó. Mình ném lại bài H cho Nana và tiếp tục debug bài L, nếu xong hết vẫn chưa có thuật thì mình sẽ nghĩ sau (xem phần Hesll có bỏ lỡ điều gì không?)
Mình quyết định test trâu bài L: đặt \(t = 100\), rồi thử hết các trường hợp \((n, l)\) từ \((1, 1)\) trở đi, vì mình biết nếu có tạch giới hạn \(3n\) thì chỉ tạch trong đống test nhỏ thôi. Đúng là sai thật, đầu tiên mình điều chỉnh về đánh dấu ngay ô đầu tiên – vẫn quá. Sau đó thì phát hiện ra mod 2 vẫn chơi được – mình sợ trường hợp ba ô liên tiếp ở đuôi nhưng có vẻ là không thể xảy ra (lag mà), sửa lại.
55 phút lấy lại bình tĩnh
[3:22] AC bài L.
Lúc này đã có 17 đội AC bài H, nhưng một mớ đội AC bài A rồi. Mình quyết định đề Nana tiếp tục nghĩ thuật tham bẩn bài H, trong khi đó mình chuyển sang nghĩ bài AA vì có quá nhiều đội AC rồi.
Đoán xem tại sao Đức mới đọc đề đã biết A là tìm kiếm nhị phân nào?
Đọc một chặp mới biết là đề yêu cầu một thứ hoàn toàn khác. Mình và Nana hiểu thành:
AA: Giá trị của cả hệ thống là tổng của các hồ chứa. Hãy gộp các hồ chứa để làm tổng này lớn nhất.
Trong khi nó phải là…
A: Giá trị của cả hệ thống là max của các hồ chứa. Hãy gộp các hồ chứa để làm tổng này nhỏ nhất.
Đọc kiểu gì nhìn thấy chữ max mà không thấy chữ min. Tìm min của max thì đúng tìm kiếm nhị phân thật, đúng là Đức rất giỏi nhận diện dạng bài. Sau tầm 1-2 phút ép thuật, mình bắt đầu code.
[3:42] WA bài A. Check lại code thì thấy đặt sai cận trên – đáp án \(\leq 2 \times 10^{17}\) nhưng mình để \(10^{12}\).
[3:43] AC bài A.
Hôm nay đọc lại đề mới nhớ là có một đoạn Nana phân tích bài I nữa, mình nghe thuật thấy cũng gần hợp lý. Tuy nhiên, xử lý DP hoán vị không tường minh bằng DP chữ số, hoán vị lặp như bài này càng khó hơn; cài có vẻ nặng trong khi mình cài yếu, với mình cũng không hiểu tường tận Nana đang nói gì – đang lag, nên mình quyết định bỏ qua luôn. Trong phòng thi có mỗi mình đội 193637 của Dế là AC bài này.
Cuối cùng thì mình quyết định làm M, vì bằng cách nào đó mà mình thấy mô hình của M dễ nghĩ hơn.
Bài M: Cho danh sách \(n\) ma trận. Bạn được phép xóa hai ma trận \(p \times q\) và \(q \times r\) để thêm vào ma trận \(p \times r\). Tìm cách thực hiện một số phép nhân ma trận để tổng số phần tử các ma trận sau cùng lớn hơn tổng số phần tử của \(n\) ma trận ban đầu.
Nhìn vào thì mình thấy ngay phải khử trùng để tránh một mớ bè từ ma trận \(n \times n\), số cạnh cuối cùng mình áng chừng quanh \(\mathcal{O}(n)\). Sau khi nhận ra thêm một chuỗi phép nhân ma trận là một đường đi thì mình tiến hành code… vì nghĩ rằng sẽ xử lý toàn bộ \(10^6\) đỉnh, mà Dijkstra trên \(10^3\) đỉnh ban đầu thì có vẻ hơi khoai, nếu WA tính sau. Trước khi submit thì não mình tỉnh lại tí: “ơ kìa, phải là thà TLE thì sửa lại thuật khác sau, chứ WA \(\rightarrow\) TLE \(\rightarrow\) +2 đấm à?”, thế là sửa lại.
[4:15] WA bài M.
[4:17] WA bài M.
45 phút hoảng loạn cuối cùng
Mình bắt đầu hoảng “ơ đ* m* sao lại WA?” và bắt đầu ném vào một mớ assert để debug.
[4:21] WA bài M.
[4:37] WA bài M.
[4:38] WA bài M.
[4:41] WA bài M.
[4:44] WA bài M.
[4:48] WA bài M.
Đố các bạn lỗi nằm ở đâu?
bool found = false;
for (i = 1 -> n) for (j = 1 -> n) if (satisfied) {
found = true; print the result;
break;
}
Sau khi sửa thành not found and satisfied và spam nhiều phát nữa:
[4:54] TLE bài M.
[4:54] TLE bài M.
[4:56] WA bài M.
[4:57] TLE bài M.
[4:57] TLE bài M.
[4:58] AC bài M.
Một lần nữa, lại là một pha AC phút 298.
Hesll có bỏ lỡ điều gì không?
[1 ngày sau] Mình lên kênh Discord của VNOI tải đề về ngẫm.
Bài H: Cho một bao lồi \(n\) đỉnh, tìm đường đi Hamilton ngắn nhất đi qua \(n\) đỉnh này.
Đây là não mình trong phòng thi, ngay sau khi nghĩ cái edge case hình thoi:
- maybe bài này có thể tham được, có thể là lần lượt thêm cạnh vào rồi xóa bớt gì đấy
- cơ mà nếu như mọi bài chu trình tròn khác, chắc phải nhân đôi số đỉnh trải ra mảng và vì thế khả năng cao là xử lý \((l; r)\) gì đấy.
- \(n \leq 3000\) thì khả năng cao là DP rồi, xử lý \((l; r)\) tức là các đỉnh đấy luôn nằm trên một vòng cung.
- ơ nhưng mà đầu mình lag quá, cái head đường đi ở đâu, \(l\) với \(r\) ở đâu như nào nhỉ?
- giờ còn A với L chưa làm, nghĩ thêm bài H hơi mệt. thôi cứ ném cho Nana, biết đâu lại có thuật tham nào đó.
Sau khi nuối tiếc hơn một ngày trời, trên máy bay, mình bắt đầu đọc lại đề.
- Mình vẫn tin là các đỉnh của đường đi sẽ nằm trên một vòng cung, nhưng nghĩ lại thì chắc gì?
- Đây là não mình của 15s sau:

Hóa ra cái đuôi đường đi có thể là \(l\) hoặc \(r\), và bước tiếp theo bắt buộc phải là \(l-1\) hoặc \(r+1\)! Nếu chọn các điểm khác, các điểm còn lại bị chia thành hai phần, sang trái là không sang phải được nữa và ngược lại.
Mình mới réo lên với Đức (không nhớ nguyên văn đoạn hội thoại lắm):
- H: Mày ơi, hóa ra bài H dễ vl mày ạ. <đọc ra tính chất đường đi + công thức DP>
- Đ: Ơ bạn Nana cũng ra được tính chất này nè
- H: uh… wtf?
- Đ: Nhưng mà lúc đó tao thấy mày đang cặm cụi code rồi.
Ừ cũng đúng. Mấy ngày sau đó mình vẫn ngồi tiếc bài H, tại sao trong phòng thi đã thấy bảng điểm cũng không ít đội làm được nhưng thế đ* nào vẫn nghĩ bài này khó.
Mình có nghĩ “giờ bình tõm lại mày mới nghĩ được vậy chứ chắc gì trong phòng thi đã nghĩ ra?”, cơ mà nếu trên máy bay mình còn nhìn ra được trong 15 giây, thì trong phòng thi vẽ nháp kiểu gì cũng ra thôi, chưa kể là Nana nháp chill chill cũng ra được tính chất đó rồi – áp DP là xong.
Mình chỉ không biết nếu mình code H trước thì đội có lên được 7 bài không, hay là vẫn 6 bài nhưng là H thay vì M… Chưa kể là các đội than bài M ép giới hạn bộ nhớ khá chặt, biết đâu lại hoảng hệt bài M vì MLE?
(update 2025/12/22) Hôm nay mình có thử bấm giờ xem nếu mình làm bài H trong phòng thi thì sẽ như nào. Sau khoảng tầm 30 phút đầu thì về căn bản mình đã cài đặt xong với mảng dp[l][r][head] với bộ nhớ \(10 \times (6000^2 \times 2) \approx\) 686MB, cơ mà vì từ đầu mình quyết định để long double 10 bytes dù sai số cho phép \(10^{-6}\) cũng không quá chặt, nên mình phải khai báo lại dp[l][len][head] – chiều thứ hai giảm còn một nửa để đủ giới hạn 512MB, nên phải tới phút 40 mới nộp bài.

12 phút sau đó mình chật vật với RTE. Đấm đầu tiên thì sai thật, tại mình đổi cách gọi chiều DP nhưng quên sửa lúc truy gốc đáp án. Đấm thứ hai trở đi là thuần MLE, nhưng theo quy chuẩn của ICPC thì sẽ quy về RTE hết. Mình không biết điều đấy, với lại với tính toán ở trên thì mình vẫn qua được giới hạn bộ nhớ, nên mình check trường hợp tràn mảng bằng cách sinh ra hai test \(n = 3000\) mà vẫn thấy code chạy ổn. Mình mới nghi ngờ là thực ra bộ nhớ mình hơi lớn quá, đổi lại thành double thì AC.
Một số bài khác
Phân tích
Vẫn như mọi năm, một tiếng đầu thể hiện khá ổn. Năm nay thậm chí có cả chuyện Nana đọc thuật xong first solve bài E. Mình nghĩ chiến thuật dưới đây khá ổn, năm sau mình sẽ áp dụng tiếp, các đội ở tầm trung có thể tham khảo:
- Một người (A) ngồi máy setup ngay từ đầu, hoàn toàn không động vào đề. Chú ý check kỹ:
- Thiết lập của compiler trong IDE
- Thiết lập của IDE
- Gõ template và các script cần thiết
- Hai người còn lại (B và C) gỡ đinh ghim và chia đôi đề, đọc đề và chọn ra (những) bài dễ nhất, setup xong thì đọc thuật code luôn.
- Thường thì sẽ rất nhanh chóng chọn được 1-2 bài như thế.
- Hết giai đoạn vài chục phút đầu thì tùy, nhưng nhìn chung thì B và C nên xác định cách chia phần đề còn lại cho A, và nhìn bảng điểm để chọn bài tiếp theo (nếu là đội bám đuổi).
Tuy nhiên, sau đó vỡ trận, đến từ mấy lỗi sau:
- Chưa hoàn tất suy nghĩ đã bắt tay vào code.
- Bài L đáng nhẽ phải đảm bảo giới hạn \(3n\) trước khi cài đặt, và test kỹ các trường hợp nhỏ.
- Bài M cũng tương tự, mình bị TLE vì sau khi cài một chặp mình mới phát hiện ra chỉ cần Dijkstra \(n\) lần thay vì ném hết cả \(n\) đỉnh ban đầu vào Dijkstra; chưa kể quả lỗi thiếu break.
- Não đứng, dẫn tới việc:
- Không quản lý được các biến đối với những bài code dài, dẫn tới bug sml
- Rất may là năm nay không bị, nhưng với các năm trước, trong đầu nhìn ra idea nhưng mất rất lâu để case work, hoặc thậm chí không triển khai được thành thuật toán cụ thể. Nhưng năm nay vẫn bị đứng khá lâu ở bài A (một phần do đọc lộn đề).
- Tâm lý phòng thi chưa vững
- Lỗi số 1 có lẽ tới từ việc sợ bị thiếu thời gian.
- Lúc virtual, dù là đánh team hay tự luyện thì luôn trong tình trạng code không kịp nghĩ.
- Nhưng sau này, lúc làm SWERC’25 với tâm thế thoải mái thì có vẻ ổn.
\(\Rightarrow\) Cần tính kỹ lại chiến thuật.
- Không bình tĩnh xử lý bài M khi thấy WA thay vì TLE
- Đúng là bài M khó sinh ra test hai nghiệm để bắt lỗi sai đấy
- Đáng nhẽ nên đọc kỹ code một lượt thay vì một mớ assert.
- Lỗi số 1 có lẽ tới từ việc sợ bị thiếu thời gian.
- Chưa có kinh nghiệm/chiến thuật cho những tình huống đã xảy ra trong phòng thi vừa rồi
- Bị stuck 3 tiếng đồng hồ liền.
- Không dứt khoát làm một việc, bị luân phiên (debug bài L và nghĩ bài A) nên quá tải.
- Underrate bản thân quá đáng, dẫn tới việc không dám dành thời gian suy nghĩ bài H.
Chuyện tránh break thiếu thì có lẽ nên thử hai quả sau:
bool found = false;
for (i = 1 -> n) for (j = 1 -> n) if (satisfied) {
found = true; print the result;
goto abc;
}
abc:
try {
for (i = 1 -> n) for (j = 1 -> n) if (satisfied) {
found = true; print the result;
throw something;
}
} catch (something);
Với việc bài H bị RTE thì hôm thử máy mình nên thử hết các trường hợp sau:
- MLE – có báo lượng bộ nhớ hay không
- OLE – báo ra gì (cơ mà tốt nhất nên xóa hết
cerrrồi code)
Tâm sự
Bà con thấy cấn thì xí xóa hen, sợ là spam hơi nhiều về chuyện trầm cảm.
Hơn bốn năm qua, mình chật vật với mớ vấn đề tâm lý tâm thần mà mình chưa đi chẩn đoán bao giờ. Chưa đi khám đàng hoàng, chưa giải quyết xong, thì lại thấy đồng trang lứa và đàn em dần dần đi lên: không kể tới chuyện Lập trình thi đấu, đứa thì kiếm được báo, đứa thì tốt nghiệp sớm, đứa thì kiếm job ngon lành, gần như đứa nào cũng học được thứ gì đó hay ho và thực chất (đọc blog jalsol mình ghen tị vcl); trong khi mình thì vẫn cứ suốt ngày nằm nhà trầm cảm, rồi procrastinate, và chả học hay làm được gì mới mẻ hay ho2, để rồi chững lại không phát triển được, suốt ngày phải tự hỏi “4 năm qua mình đã làm cái quái gì vậy?”.
Cơ mà năm nay cũng dần xử lý được một phần vấn đề rồi.
Thế là nhẹ người, cải thiện được nhiều thứ:
- Có viết nhiều thứ viết blog hơn, dù lịch vẫn còn tùy hứng.
- Biết nói từ chối nhiều hơn để không đẩy mình vào thế khó, dù đôi khi bằng cách im lặng…
- Nhưng không im lặng khi đã nhận việc nữa (vẫn còn delay)
- Đã có lại sức để tự giác bản thân luyện tập, và thậm chí là cù cả đội đi training.
- Đã bắt đầu có thói quen review tất cả mọi thứ. (học từ ltpq)
Năm nay cũng làm nhiều thứ mới phết:
- Bước đầu nhúng tay vào NCKH nè, có hẳn giải Nhì khoa với giải Ba trường.
- Hoàn thành biên soạn bộ tài liệu chuyên đề nè: trì hoãn ba năm làm tài liệu về Số học và Tổ hợp, thì giờ mới xong… chuyên đề Đồ thị(???)
- Làm chủ tọa cho một hội đồng MUN nè.
- Nghĩ được quả bài Interactive đầu tiên nè, mình ưng ý mô hình đề bài vl nhưng mỗi tội vì sợ đề dễ nên không chia subtask rõ nhưng thành ra không ai giải được không ai giải được trong chung kết LQDOJ Cup 2025 nè.
- Lên kế hoạch tác chiến cho ICPC năm nay nè, có quả First Solve E đỉnh vãi.
- Cài đại Jekyll để có con blog này nè.
Nên mình bắt đầu tin vào năng lực của bản thân hơn, với bây giờ (tính tại thời điểm viết bài) mình còn hai cơ hội3 để vào Championship và thậm chí là World Finals mà, nếu đủ kỷ luật để chăm chỉ luyện tập.
Cơ mà mình vẫn còn dễ bị breakdown (ngay trước khi đi SG bị một phát nè), với lại mình còn nhiều thứ khác phải làm – all-in vào ICPC thế còn dự định học cao học thì sao? Nên mình muốn hoàn thành tâm niệm cuối cùng, dứt điểm chuyện thi đấu này càng sớm càng tốt, để tập trung vào việc kiếm intern và học nghiên cứu khoa học.
Thành ra, kỳ này mình quyết định all-in vào ICPC (tới mức suốt ngày ngồi ở Tiny Cafe Nguyễn Ngọc Vũ chứ không thèm đi học), mặc dù biết với điều kiện hiện tại thì điều đó quá nguy hiểm: mình thừa biết xác suất được đi tiếp không cao vì thời gian luyện tập không đủ, nếu thất bại thì vừa tụt GPA vừa quay về trạng thái breakdown một lần nữa (thành công thì chỉ tụt GPA thôi). Điều duy nhất mình có thể làm ngoài luyện tập thật nhiều là tự kỷ ám thị “mày làm được” thay vì “nhỡ tạch thì sao” như hồi cấp 3.
Kết quả như mọi người đã thấy. Mà thực ra toàn bộ dấu hiệu ngay trước khi mình lên máy bay đều cho thấy team mình sẽ tạch: virtual cả team (Yokohama’24, Seoul’25, Taichung’25) ở các Regional khác trong Asia-Pacific thì luôn đứng ngay dưới cut-off, virtual cá nhân (Bangkok’25 và Jakarta’25) thì luôn bị choke/quá tải nên thọt. Mặc dù đã có cà phê chống đù, nhưng với khối lượng của một Regional, mình vẫn lag và quá tải từ virtual tới lúc thi thật.
Tuy nhiên, mình bất ngờ là sau đợt đi Sài Gòn này thì mình lại không rơi vào trạng thái trầm cảm muốn 0x2C một lần nữa, mình chỉ buồn một chút thôi. Có lẽ là vì mình thua sát nút chứ không đứng quá xa, có thể nói là thua do sai chiến thuật chứ không phải chỉ vì choke nặng như các năm trước, và mình còn năm sau để gỡ, nên mình tràn trề hy vọng chứ không quá suy nữa.
Để xem năm sau như nào, giờ thì training đàng hoàng thôi.
Cuối cùng, mình cảm ơn Nana vì đã là một cánh tay đắc lực trong team, và cảm ơn Đức vì đã support tinh thần tao trong suốt 4 năm qua. Em (và cả đội) cảm ơn cô Yến, thầy Dũng và thầy Minh đã đồng hành và hỗ trợ đội tuyển trong mấy tháng vừa rồi, và chấp thuận cho em xuyên 2 đêm giải sầu sau khi thi ạ ^^
Xàm xí thêm tí
Mình cứ có cảm giác là đề HCMC năm nay dễ hơn so với các regional khác, nhưng có vẻ nó chỉ đơn giản là các bài tầm trung meta hợp với mình hơn thôi:
- Bảng điểm năm ngoái nhiều bài hơn
- Các team đi các regional khác thọt HCMC dù rank khá cao ở nước ngoài: PTIT, FPT thua mình; UIT.KHQ.JobSeekers không biết phải seed 1 không nhưng thua hai team UIT khác.
Năm nay chụp hơi ít ảnh, không tận hưởng được mấy vì hơi tự áp lực bản thân. Cơ mà cũng đi chơi nhiều nơi, có hai hôm xuyên đêm uống cocktail + tám xàm ngoài công viên, chill vãi.
HCMC Metro > Hanoi Metro, cụ thể là HCMC 1 > HN 3 > HN 2A. Nhìn tuyến 2A Cát Linh-Hà Đông với tuyển 3 Nhổn-Ga Hà Nội đã thấy cách biệt về ngôn ngữ thiết kế rồi, đi Sài Gòn xong mới thấy ngán ngẩm với anh Tàu hơn nữa.
Ghi chú
-
Năm lớp 9 có đi ké team LQĐ-ĐN để thi National’18 (tại có một anh nghỉ, quy định là không cho thế người nhma không ai biết hihi), không code nhưng mình nhớ là có một bài góp idea bè 3 đỉnh. ↩
-
Thực ra là cũng làm được nhiều thứ hay ho phết, chạy LQDOJ Cup rồi OLP MTTN rồi H3T, rồi làm chủ tọa MUN nữa. Nhưng đúng là chuyên môn thì không học được gì mới thật, trừ năm ngoái đi NCKH (và vẫn procrastinate, tới giờ vẫn chưa nộp kết quả cho thầy nữa). Thực tế thì ai cũng thấy mình chững mà, ít ra vẫn còn tự tin mình có năng lực mà còn cơ hội phát triển tiềm năng, chứ chưa ngủm dưới đáy sông, là may lắm rồi. ↩
-
“A qualifying contest is one that allows teams to be promoted to a higher level and which is supervised by faculty” – ICPC bảng Không chuyên có vẻ không được tính vào vì nó độc lập với hệ thống chính nên được xem là không có cơ chế promote từ National lên World Finals? ↩