7 EDGE CASES NÊN KIỂM TRA TRƯỚC KHI KẾT THÚC CODING INTERVIEW

Trong Coding Interview tại Big Tech, tìm ra hướng giải đúng mới chỉ là một nửa chặng đường. Bạn còn cần đảm bảo code hoạt động chính xác với những trường hợp đầu vào đặc biệt, không chỉ với ví dụ có sẵn trong đề bài.
Một lời giải có thể chạy đúng với input thông thường nhưng vẫn thất bại khi gặp mảng rỗng, dữ liệu trùng lặp hoặc giá trị nằm ở giới hạn cho phép.
Vì vậy, trước khi kết thúc Coding Interview, hãy dành thời gian kiểm tra 7 nhóm Edge Cases dưới đây.
1. Empty Input – Đầu vào rỗng
Đây là trường hợp cơ bản nhưng dễ bị bỏ qua khi bạn tập trung vào thuật toán chính.
Ví dụ, với bài toán tìm phần tử lớn nhất trong mảng, nếu input là [], code sẽ gặp lỗi nếu truy cập trực tiếp nums[0] mà không kiểm tra trước.
Khi gặp dạng bài này, hãy tự hỏi: Đề bài có cho phép input rỗng không? Nếu không có dữ liệu, hàm cần trả về gì? Có thao tác truy cập phần tử trước khi kiểm tra độ dài mảng không?
Không phải bài toán nào cũng cho phép input rỗng, vì vậy hãy dựa vào constraints để xác định cách xử lý phù hợp.
2. Minimum Input – Đầu vào có kích thước nhỏ nhất
Nếu input rỗng kiểm tra khả năng xử lý trường hợp không có dữ liệu, thì input nhỏ nhất giúp phát hiện những giả định sai về số lượng phần tử.
Chẳng hạn, với bài toán Two Sum, nếu mảng chỉ có một phần tử, thuật toán không được sử dụng cùng một phần tử hai lần khi đề yêu cầu hai index khác nhau.
Hãy thử các trường hợp (n=0), (n=1) hoặc kích thước nhỏ nhất được đề bài cho phép. Đặc biệt chú ý đến điều kiện vòng lặp và các thao tác yêu cầu tối thiểu hai phần tử.

1. Duplicate Values – Phần tử trùng lặp Nhiều thuật toán hoạt động tốt khi các phần tử khác nhau nhưng lại cho kết quả sai khi dữ liệu chứa giá trị trùng lặp. Ví dụ, trong bài toán tìm phần tử phân biệt, mảng [1, 1, 2, 2, 3] cần được xử lý khác với [1, 2, 3, 4, 5]. Với Binary Search, dữ liệu trùng lặp cũng có thể ảnh hưởng đến cách tìm vị trí đầu tiên hoặc cuối cùng của một giá trị. Khi kiểm tra, hãy chú ý xem thuật toán có đếm một phần tử nhiều lần không, các điều kiện so sánh có chính xác không và đề bài yêu cầu một đáp án bất kỳ hay một vị trí cụ thể.
2. Boundary Values – Giá trị ở giới hạn Đây là nhóm Edge Cases quan trọng với Binary Search, Array và các bài toán xử lý số học. Ví dụ, khi tìm kiếm trong mảng đã sắp xếp, nếu target nằm ở phần tử đầu tiên hoặc cuối cùng, thuật toán vẫn phải trả về đúng kết quả. Một lỗi cập nhật left hoặc right không chính xác có thể khiến code bỏ sót đáp án hoặc lặp vô hạn. Ngoài ra, với các phép cộng và nhân trên số nguyên lớn, hãy kiểm tra nguy cơ overflow nếu constraints cho phép giá trị gần giới hạn của kiểu dữ liệu.
3. Already Sorted / Reverse Sorted – Dữ liệu đã được sắp xếp Nếu thuật toán phụ thuộc vào thứ tự dữ liệu, hãy thử cả trường hợp đầu vào đã sắp xếp tăng dần và giảm dần. Chẳng hạn, với bài toán tìm độ dài đoạn con tăng liên tiếp dài nhất, mảng tăng dần có thể tạo ra đáp án tối đa, trong khi mảng giảm dần có thể khiến độ dài đoạn tăng liên tiếp chỉ bằng một. Hai trường hợp đối lập này giúp bạn phát hiện những giả định không được đề bài đảm bảo, đồng thời kiểm tra xem thuật toán có hoạt động đúng với thứ tự đầu vào khác nhau hay không.
4. All Same / All Different – Tất cả giống nhau hoặc tất cả khác nhau Ngoài việc kiểm tra một vài phần tử trùng lặp, hãy thử hai trường hợp cực đoan: toàn bộ phần tử giống nhau và toàn bộ phần tử khác nhau. Ví dụ, với bài toán đếm số lượng phần tử phân biệt, [5, 5, 5, 5] phải cho kết quả 1, trong khi [1, 2, 3, 4] phải cho kết quả 4. Đây là cách đơn giản để kiểm tra logic đếm, cập nhật trạng thái và xử lý phần tử đầu tiên hoặc cuối cùng. Nếu thuật toán dựa vào việc phát hiện sự thay đổi giữa các phần tử, trường hợp không có sự thay đổi đặc biệt đáng chú ý.
5. No Solution / Multiple Solutions – Không có đáp án hoặc có nhiều đáp án Đừng chỉ kiểm tra trường hợp thuật toán tìm thấy đáp án như mong đợi. Hãy xem điều gì xảy ra khi không có đáp án hợp lệ hoặc khi tồn tại nhiều đáp án. Với Two Sum, bạn có thể thử input không có cặp phần tử nào thỏa mãn target, hoặc input có nhiều cặp cùng thỏa mãn điều kiện. Điều quan trọng là xác định rõ đề bài có đảm bảo luôn tồn tại đáp án không, cần trả về gì khi không tìm thấy và có tiêu chí cụ thể nào để chọn giữa nhiều đáp án hay không. Đừng tự giả định rằng mọi bài toán đều chỉ có một kết quả hợp lệ. Kết luận Trước khi kết thúc Coding Interview, hãy dành một chút thời gian tự hỏi: “Trường hợp nào có thể khiến code của mình sai?” thay vì chỉ kiểm tra xem code có chạy được với ví dụ mẫu hay không. Bạn không nhất thiết phải viết thêm code cho mọi Edge Case. Hãy ưu tiên những trường hợp có khả năng phá vỡ giả định cốt lõi của thuật toán, sau đó trace code bằng tay để xác nhận. Đây là một thói quen nhỏ nhưng hữu ích để nâng cao tính chính xác của lời giải và thể hiện tư duy kỹ thuật có hệ thống trong Coding Interview tại Big Tech. See less