Hội đồng nghi đồ án đi mua thì trả lời thế nào

"Phần này em tự viết à?" — câu hỏi này làm nhiều người đứng hình, kể cả người tự làm thật. Bài này nói thẳng: vì sao hội đồng nghi, dấu hiệu nào khiến họ nghi, và cách duy nhất trả lời được.

Nói trước cho khỏi mất thời gian: không có câu trả lời khôn khéo nào cứu được người không hiểu code của mình. Hội đồng gồm người dạy lập trình nhiều năm, hỏi tới câu thứ hai là biết. Cách duy nhất là hiểu thật. Phần còn lại của bài là cách hiểu đủ nhanh và cách trình bày cho đúng.

Vì sao hội đồng nghi

Đa số không phải vì ghét ai. Nghi vì có mẫu hình lặp lại: mỗi năm đều có vài bài mà người trình bày không giải thích nổi thứ mình nộp. Nên họ hỏi để phân loại, và câu hỏi thường vô hại với người hiểu bài.

Điều quan trọng: bị hỏi câu này không có nghĩa là bạn đã bị kết luận. Đó là câu kiểm tra, không phải lời buộc tội. Trả lời trôi là qua.

Dấu hiệu khiến hội đồng nghi

Chênh lệch trình độ trong cùng một bài. Phần nghiệp vụ chính viết rất bài bản, có tầng service, có xử lý lỗi tập trung, có ghi nhật ký; còn phần thống kê thì viết cẩu thả. Chênh lệch này lộ hơn cả.

Chú thích và tên biến lẫn lộn phong cách. Chỗ tiếng Anh chuẩn, chỗ tiếng Việt không dấu, chỗ đặt tên kiểu này, chỗ kiểu kia.

Dữ liệu mẫu không dọn. Bảng khách hàng có "Nguyen Van A", "aaa", "test123" và một cái tên lạ hoắc trông như của dự án khác. Tên bảng hoặc chú thích còn dính tên hệ thống khác hẳn với đề của bạn — đây là dấu hiệu rõ nhất, và cũng dễ tránh nhất.

Dùng thư viện hoặc kỹ thuật vượt xa những gì đã học. Không sai, nhưng sẽ bị hỏi vì sao chọn. Không trả lời được thì thành dấu hiệu.

Nhật ký git chỉ có một lần đẩy lên. Một commit tên "init" chứa cả dự án. Ngược lại, lịch sử rải đều nhiều tuần là bằng chứng tốt nhất mà bạn có.

Trả lời bằng thuật ngữ mà không mô tả được việc mình làm. Nói được "em dùng JWT" nhưng không nói được token lưu ở đâu, hết hạn xử lý thế nào.

Câu hỏi họ dùng để kiểm tra, và câu trả lời thật

"Đoạn này em code thế nào?" — Kể lại đường đi, không đọc lại code. "Nút bấm gọi hàm này, gửi lên đường dẫn này, controller nhận vào lớp dữ liệu này, service kiểm tra hai ràng buộc rồi mới ghi xuống bảng kia." Người viết code nhớ đường đi; người không viết chỉ mô tả được màn hình.

"Sao em chọn cách này mà không cách kia?" — Có lý do thật thì nói lý do thật. Không có lý do sâu xa thì cũng nói thật: "em chọn vì đã học môn đó nên làm chắc tay hơn". Câu này được chấp nhận. Bịa ra lý do kỹ thuật rồi bị hỏi tiếp mới là chết.

"Giờ thầy muốn thêm chức năng X thì em sửa ở đâu?" — Câu phân loại mạnh nhất. Trả lời bằng cách kể tên từng tầng phải sửa: thêm cột ở bảng nào, sửa lớp dữ liệu nào, thêm hàm ở service nào, sửa màn hình nào.

"Chỗ nào trong bài này khó nhất với em?" — Câu này thực ra là câu thân thiện. Người làm thật luôn có một chỗ vật vã và kể được rất sinh động: sai ở đâu, thử gì, cuối cùng sửa sao. Người không làm thì trả lời chung chung. Chuẩn bị sẵn một câu chuyện thật về một lỗi bạn từng mất cả buổi để sửa.

"Em tham khảo ở đâu?" — Nói thật. Tham khảo tài liệu, video, dự án mở là chuyện bình thường và được phép. Câu trả lời tốt: "em tham khảo cấu trúc phân tầng từ tài liệu chính thức và một dự án mở, phần nghiệp vụ đặt phòng thì em tự viết theo yêu cầu đề tài." Trung thực về nguồn tham khảo mạnh hơn nhiều so với chối sạch.

Nếu bạn có mua hoặc thuê

Nói thẳng phần này vì đó là tình huống thật của nhiều người.

Trả lời tốt nhất không phải là chối. Chối rồi bị hỏi ba câu về code là mất cả điểm lẫn niềm tin, và mất niềm tin thì hội đồng vặn tiếp mọi thứ còn lại.

Thứ cứu được bạn là hiểu. Hiểu rồi thì "em có tham khảo mã nguồn có sẵn, sau đó sửa phần này, thêm phần kia theo đề của em" là câu trả lời chấp nhận được ở phần lớn hội đồng — vì bạn chứng minh được bằng cách giải thích trôi chảy ngay sau đó. Còn không hiểu thì không có câu nào cứu.

Ba ngày là đủ để đọc hiểu một dự án lạ tới mức trả lời được, nếu đọc đúng thứ tự: cách đọc hiểu mã nguồn của người khác trong ba ngày.

Tối thiểu phải nắm bốn thứ trước khi vào phòng: cấu trúc thư mục, đường đi của một yêu cầu, cách xác thực hoạt động, và chỗ khó nhất của đề.

Việc làm trước để khỏi bị nghi

Đẩy code lên git đều đặn suốt quá trình. Lịch sử rải nhiều tuần là bằng chứng mạnh nhất, và không làm ngược lại được vào phút cuối.

Dọn dữ liệu mẫu. Đổi hết tên "test", "aaa" thành dữ liệu trông như thật. Việc này mất một tiếng và bỏ được nguyên một nhóm nghi ngờ.

Thống nhất phong cách đặt tên và chú thích toàn dự án.

Tự thêm một chức năng nhỏ vào bài. Vừa để hiểu, vừa để có cái kể khi bị hỏi phần nào khó nhất.

Giữ lại bản nháp. Sơ đồ vẽ tay, ảnh chụp lúc còn dở, tin nhắn trao đổi với giảng viên hướng dẫn.

Ranh giới

Bài này không dạy cách qua mặt hội đồng, vì cách đó không tồn tại — người chấm là người dạy lập trình, và họ chỉ cần hai câu hỏi.

Tham khảo mã nguồn có sẵn, đọc hiểu, sửa theo đề của mình rồi trình bày được là cách làm bình thường, giống dùng tài liệu tham khảo. Nộp thứ mình chưa từng mở ra đọc thì rủi ro nằm ở chính buổi bảo vệ, không ai gánh hộ được.

Bên mình bán mã nguồn kèm buổi giải thích cấu trúc chính vì lý do đó — thứ bạn cần mang vào phòng bảo vệ là hiểu biết, không phải file. Xem danh mục đề tài hoặc bảng giá.

Đọc thêm

28 câu hỏi phản biện hội đồng hay hỏi — dùng làm đề tự kiểm tra.

Mua mã nguồn hay tự làm — so sánh theo thời gian, tiền và rủi ro.