Ngày cuối cùng — không học kiến thức mới, chỉ luyện phản xạ nói ra được những gì đã học 6 ngày qua. Mục tiêu: trả lời trôi chảy, tự nhiên, không ấp úng.

---

PHẦN A: CẤU TRÚC 1 BUỔI PHỎNG VẤN WORDPRESS DEV THƯỜNG GẶP

Hiểu trước cấu trúc giúp bạn không bị bất ngờ:

1. Giới thiệu bản thân + kinh nghiệm (5-10 phút) — đây là lúc dùng câu chuyện đã chuẩn bị ở Ngày 6.
2. Câu hỏi kiến thức nền tảng (15-20 phút) — hooks, security, database, template hierarchy.
3. Câu hỏi tình huống/kinh nghiệm thực tế (10-15 phút) — “kể 1 lần bạn debug lỗi khó”, “thiết kế hệ thống X thế nào”.
4. Live coding hoặc review code (nếu có, 20-30 phút).
5. Câu hỏi ngược lại từ bạn — luôn chuẩn bị sẵn 2-3 câu hỏi hay để hỏi lại nhà tuyển dụng (thể hiện sự quan tâm nghiêm túc).

---

PHẦN B: 20 CÂU HỎI PHỎNG VẤN — LUYỆN TRẢ LỜI THÀNH TIẾNG

Nhóm 1: Kiến trúc lõi & Theme (Ngày 1)

1. Hook là gì? Phân biệt Action và Filter, cho ví dụ.

Gợi ý: Action = làm gì đó, không return. Filter = nhận vào, biến đổi, bắt buộc return. Ví dụ: wp_login (action, gửi email chào mừng) vs the_title (filter, thêm emoji vào tiêu đề).

2. Template Hierarchy hoạt động thế nào?

Gợi ý: WP tìm file từ cụ thể nhất đến chung nhất, fallback cuối cùng về index.php. Ví dụ cụ thể với CPT product, slug ao-thun.

3. wp_reset_postdata() dùng để làm gì, quên thì sao?

Gợi ý: Trả $post global về đúng post gốc sau khi dùng WP_Query phụ. Quên → code sau đó lấy nhầm dữ liệu.

4. Tại sao không nên dùng query_posts()?

Gợi ý: Sửa trực tiếp query chính, phá pagination, side-effect toàn cục. Nên dùng pre_get_posts thay thế.

Nhóm 2: Plugin & CPT (Ngày 2)

5. Phân biệt Activation, Deactivation, Uninstall hook.

Gợi ý: Activation/Deactivation giữ nguyên data, Uninstall xoá vĩnh viễn — code xoá data chỉ đặt trong uninstall.php.

6. show_in_rest trong register_post_type để làm gì?

Gợi ý: Bắt buộc true để dùng Gutenberg editor và có REST endpoint tự động.

7. Kể đủ 4 bước xử lý an toàn khi save custom field qua save_post.

Gợi ý: Check nonce → check autosave → check capability → sanitize input. Thiếu bước nào, hậu quả gì (đã học kỹ Ngày 2 & 3).

8. Khi nào dùng ACF, khi nào code tay?

Gợi ý: ACF cho dự án cần triển khai nhanh, nhiều field, khách tự quản trị. Code tay cho hiệu năng cao, logic phức tạp, không muốn phụ thuộc plugin ngoài.

Nhóm 3: Database & Security (Ngày 3 — trọng tâm nhất)

9. Sanitize và Escape khác nhau thế nào?

Gợi ý: Câu thần chú “Sanitize khi lưu, Escape khi in ra”. Nêu ví dụ hàm cụ thể từng loại.

10. Nonce chống được gì, không phải là gì?

Gợi ý: Chống CSRF. KHÔNG PHẢI authentication/authorization — 2 việc đó vẫn cần current_user_can() riêng.

11. Giải thích SQL Injection và cách WordPress phòng chống.

Gợi ý: Demo ví dụ nối chuỗi trực tiếp → $wpdb->prepare().

12. EAV pattern của wp_postmeta có nhược điểm gì?

Gợi ý: Query chậm khi filter/sort nhiều điều kiện meta (nhiều JOIN), không có kiểu dữ liệu thực. Khi nào nên tách custom table.

13. autoload trong wp_options là gì, ảnh hưởng gì nếu sai?

Gợi ý: Option autoload=yes load vào bộ nhớ MỌI request — data lớn với autoload=yes làm chậm toàn site.

Nhóm 4: Performance & API (Ngày 4)

14. Transient và Object Cache khác nhau thế nào?

Gợi ý: Transient đảm bảo tồn tại tới hết hạn (fallback DB), Object cache không đảm bảo, mang tính tạm.

15. Lỗi bảo mật nghiêm trọng nhất khi làm REST API là gì?

Gợi ý: permission_callback để __return_true hoặc bỏ trống cho endpoint có ghi/sửa dữ liệu.

16. Vì sao cần đăng ký cả wp_ajax_ và wp_ajax_nopriv_?

Gợi ý: wp_ajax_ chỉ chạy cho user đã login, nopriv cho khách — thiếu 1 trong 2, nhóm còn lại không gọi được.

Nhóm 5: Kinh nghiệm & Tư duy (Ngày 5, 6)

17. Bạn debug 1 site WordPress chậm như thế nào? Quy trình từ đâu đến đâu?

Gợi ý trả lời có cấu trúc:

1. Cài Query Monitor, xem query nào chậm/lặp nhiều lần.
2. Kiểm tra wp_options có option autoload dung lượng lớn bất thường không.
3. Kiểm tra plugin nào enqueue quá nhiều CSS/JS không cần thiết.
4. Xem có N+1 query thực sự (tự viết $wpdb trong loop) không.
5. Cân nhắc thêm cache (transient/object cache) cho phần tính toán nặng, lặp lại.

18. Khi nào bạn chọn dùng Multisite, khi nào không?

Gợi ý: Nên khi nhiều site cùng tổ chức, cần quản lý tập trung. Không nên khi site thuộc khách hàng khác nhau (single point of failure).

19. Kể 1 lần bạn debug 1 lỗi khó — quy trình tìm nguyên nhân ra sao?

Đây là câu hỏi cần chuẩn bị SẴN 1 câu chuyện thật cụ thể (không trả lời chung chung). Format kể chuyện tốt (STAR):

• Tình huống: Lỗi gì, ảnh hưởng gì (VD: “1 lần site khách bị chậm đột ngột sau khi cài plugin mới”).
• Hành động: Bạn làm gì để tìm ra (VD: “Em dùng Query Monitor phát hiện 1 query lặp lại 200 lần trong 1 trang, hoá ra plugin đó query DB trong loop không cache”).
• Kết quả: Sửa thế nào, học được gì.

Bài tập: Nghĩ lại 1 câu chuyện THẬT từ kinh nghiệm 10 năm của chính bạn, viết ra và luyện kể trong 1-2 phút.

20. Sao dạo này bạn chỉ vibe coding, có ảnh hưởng gì đến chất lượng code không?

Dùng nguyên đoạn đã chuẩn bị ở Ngày 6, Phần E.

---

PHẦN C: DẠNG BÀI TEST CODING THƯỜNG GẶP

1. Dạng 1 — Viết CPT + Meta Box + Hiển thị Frontend (phổ biến nhất)

Đề bài mẫu: “Tạo CPT Event có custom field event_date. Hiển thị danh sách event sắp diễn ra (ngày >= hôm nay) ra trang chủ, sắp xếp theo ngày gần nhất.”

Cách tiếp cận khi làm bài test (nói ra thành tiếng nếu là live coding, để giám khảo thấy tư duy):

1. Đăng ký CPT trong init với show_in_rest => true.
2. Thêm meta box cho event_date, đủ 4 bước bảo mật (nonce, autosave check, capability, sanitize).
3. Query bằng meta_query với compare => '>=', type => 'DATE'.
4. Hiển thị an toàn: esc_html() cho mọi giá trị output.

$query = new WP_Query([
    'post_type'  => 'event',
    'meta_key'   => 'event_date',
    'orderby'    => 'meta_value',
    'order'      => 'ASC',
    'meta_query' => [[
        'key'     => 'event_date',
        'value'   => date('Y-m-d'),
        'compare' => '>=',
        'type'    => 'DATE',
    ]],
]);

2. Dạng 2 — Sửa lỗi bảo mật trong đoạn code có sẵn (rất phổ biến, kiểm tra tư duy security)

Đề bài mẫu: “Đoạn code sau có lỗi, hãy tìm và sửa”:

function save_custom_field( $post_id ) {
    $value = $_POST['my_field'];
    update_post_meta( $post_id, 'my_field', $value );
}
add_action( 'save_post', 'save_custom_field' );

Cách trả lời bài này — liệt kê rõ TỪNG lỗi tìm được (giám khảo chấm theo số lỗi phát hiện):

1. ❌ Thiếu check nonce → dễ bị CSRF.
2. ❌ Thiếu check current_user_can() → không kiểm tra quyền.
3. ❌ Thiếu check DOING_AUTOSAVE → có thể lưu sai lúc autosave.
4. ❌ Không sanitize $_POST['my_field'] trước khi lưu → lưu thẳng dữ liệu thô vào DB, mở đường Stored XSS.
5. ❌ Không check isset($_POST['my_field']) → PHP Notice nếu field không tồn tại.

Code sửa đầy đủ:

function save_custom_field( $post_id ) {
    if ( ! isset( $_POST['my_field_nonce'] ) ||
         ! wp_verify_nonce( $_POST['my_field_nonce'], 'save_my_field' ) ) {
        return;
    }
    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
        return;
    }
    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }
    if ( isset( $_POST['my_field'] ) ) {
        update_post_meta( $post_id, 'my_field', sanitize_text_field( $_POST['my_field'] ) );
    }
}
add_action( 'save_post', 'save_custom_field' );

3. Dạng 3 — Take-home assignment (làm ở nhà, nộp qua Git)

Lưu ý quan trọng nếu gặp dạng này:

• Commit history rõ ràng, chia nhỏ theo từng bước logic — không commit 1 lần “Add feature” (không cho thấy tư duy làm việc).
• Viết README ngắn giải thích quyết định kiến trúc (VD: “Chọn custom table thay vì postmeta vì…”) — đây là cơ hội thể hiện tư duy, đừng bỏ qua.
• Nếu dùng AI hỗ trợ làm bài (nếu không bị cấm), nói rõ trong README — minh bạch tạo ấn tượng tốt hơn giấu diếm rồi bị lộ khi phỏng vấn hỏi chi tiết.

---

PHẦN D: CÂU HỎI NÊN HỎI NGƯỢC LẠI NHÀ TUYỂN DỤNG

Chuẩn bị sẵn 2-3 câu để hỏi cuối buổi — thể hiện sự nghiêm túc và cũng giúp bạn đánh giá công ty có phù hợp không:

1. “Team hiện tại xử lý code review thế nào, đặc biệt với code có AI hỗ trợ?” — câu này khéo léo cho thấy bạn chủ động nghĩ về vấn đề AI-assisted coding một cách chuyên nghiệp.
2. “Stack hiện tại của team có dùng Gutenberg/block theme hay vẫn classic theme?” — giúp bạn biết mình cần chuẩn bị gì thêm nếu nhận việc.
3. “Quy trình deploy/CI-CD của team hiện tại như thế nào?”

---

PHẦN E: CHECKLIST CUỐI CÙNG — MANG THEO TRONG ĐẦU KHI VÀO PHỎNG VẤN

• [ ] Action vs Filter — return hay không return
• [ ] Sanitize khi lưu, Escape khi in ra
• [ ] Nonce chống CSRF, không phải authentication
• [ ] $wpdb->prepare() chống SQL Injection
• [ ] 4 bước bảo mật save_post: nonce → autosave → capability → sanitize
• [ ] Template Hierarchy: cụ thể → chung, fallback index.php
• [ ] show_in_rest => true cho Gutenberg + REST
• [ ] Transient cho cache có hạn, Object cache cho tạm trong request
• [ ] permission_callback — lỗi REST API nghiêm trọng nhất
• [ ] Query Monitor — công cụ debug WordPress-specific
• [ ] 1 câu chuyện debug lỗi khó THẬT, đã luyện kể trong 1-2 phút
• [ ] Đoạn trả lời “vibe coding” đã luyện thành giọng văn tự nhiên của mình

---

PHẦN F: BÀI TẬP CUỐI CÙNG TRƯỚC KHI THI THẬT

1. Nhờ 1 người bạn (hoặc tự quay video) hỏi ngẫu nhiên 5 câu trong 20 câu ở Phần B — trả lời trong 60-90 giây/câu, không nhìn tài liệu.
2. Làm thử đề bài Dạng 2 (tìm lỗi bảo mật) trong 10 phút, tự chấm bằng đáp án — nếu tìm được dưới 4/5 lỗi, quay lại ôn Ngày 3.
3. Đọc to đoạn trả lời “vibe coding” 3 lần liên tiếp cho tới khi nghe tự nhiên như đang trò chuyện, không như học thuộc lòng.

---

TỔNG KẾT CẢ TUẦN

Anh/chị đã đi qua:

• Ngày 1-2: Nền tảng kỹ thuật (Hooks, Template Hierarchy, Loop, Plugin, CPT/Taxonomy, Custom Fields)
• Ngày 3: Database & Security — trụ cột quan trọng nhất
• Ngày 4-5: Performance, AJAX/REST, Gutenberg, WP-CLI, Multisite — mảng hiện đại hoá kiến thức
• Ngày 6: Biến “vibe coding” thành câu chuyện chuyên nghiệp, đáng tin
• Ngày 7: Tổng ôn, luyện phản xạ trả lời

Chúc các bạn một ngày tốt lành!