Lead Python Backend Engineer (AI-Augmented Development)

Đo trước, tối ưu chỗ tốn nhất trước. Phần lớn trường hợp nút thắt là DB và gọi mạng, không phải tốc độ của Python.

1. Đo: APM hoặc tracing (OpenTelemetry) để biết thời gian nằm ở DB, API ngoài hay code. Profile bằng py-spy (gắn vào process đang chạy) hoặc cProfile.
2. DB: xử lý N+1, thêm index phù hợp, chỉ lấy cột cần (only, values), phân trang.
3. Cache: Redis cho dữ liệu đọc nhiều, ít đổi; nhớ chiến lược invalidate.
4. Việc nặng hoặc không cần trả ngay (gửi email, xuất file): đẩy sang Celery hoặc queue.
5. Gọi nhiều API ngoài: chạy song song, đặt timeout.
6. Cuối cùng mới tới tối ưu thuật toán, hoặc đưa đoạn nặng CPU sang thư viện C hay service khác.

Hay sai: viết lại sang async hoặc đổi ngôn ngữ trước khi biết thời gian thực sự bị tiêu ở đâu.

Python linh hoạt nên dự án lớn dễ rối; cần công cụ để bắt lỗi trước khi chạy.

• Type hints + type checker (mypy hoặc pyright) chạy trong CI. Dùng Protocol cho interface, TypedDict hoặc dataclass thay cho dict tự do.
• Validate dữ liệu ở biên (request, config, message) bằng Pydantic; bên trong tin vào kiểu đã kiểm.
• Dependency: môi trường ảo riêng, file lock để build tái lập được (uv, Poetry hoặc pip-tools). Tách dependency dev và production.
• Lint/format tự động: ruff thay cho nhiều công cụ cũ; chạy qua pre-commit và CI.
• Cấu trúc: chia theo domain, tách logic nghiệp vụ khỏi framework để test không cần DB hay HTTP.
• Test bằng pytest với fixture; test tích hợp cho các luồng chính.

Người phỏng vấn muốn nghe: bạn hiểu type hints không kiểm tra lúc runtime, nên vẫn cần validate dữ liệu đầu vào.

Decorator là hàm nhận một hàm và trả về hàm mới bọc quanh nó. @timer chỉ là cú pháp ngắn của func = timer(func).

import functools, time

def timer(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        try:
            return func(*args, **kwargs)
        finally:
            print(func.__name__, time.perf_counter() - start)
    return wrapper

• functools.wraps giữ lại __name__, docstring của hàm gốc, quan trọng cho log và debug.
• Decorator có tham số (ví dụ @retry(times=3)) cần thêm một lớp hàm bên ngoài.
• Ví dụ thực tế: @app.get của FastAPI, @login_required của Django, @functools.lru_cache.

Hay sai: decorator viết kiểu đồng bộ bọc hàm async def. Kết quả là đo thời gian tạo coroutine chứ không phải thời gian chạy.

Chia thay đổi thành nhiều bước tương thích ngược để phiên bản code cũ và mới chạy song song được (expand rồi contract).

1. Expand: thêm cột mới cho phép NULL hoặc có default; tránh câu lệnh viết lại cả bảng.
2. Code mới ghi vào cả cột cũ và mới.
3. Backfill dữ liệu cũ theo từng lô nhỏ, có nghỉ giữa các lô để không gây lag replica.
4. Chuyển code sang đọc cột mới, kiểm tra kỹ.
5. Contract: bỏ cột cũ ở một lần deploy sau.

Index trên bảng lớn: PostgreSQL dùng CREATE INDEX CONCURRENTLY; MySQL dùng online DDL hoặc công cụ như gh-ost, pt-online-schema-change.

Người phỏng vấn muốn nghe: bạn biết DDL có thể giữ lock khiến mọi query xếp hàng, nên đặt lock_timeout và luôn có kế hoạch rollback.

Có. Composite index sắp xếp theo cột đầu, rồi đến cột thứ hai trong cùng giá trị cột đầu, v.v. Vì vậy nó chỉ dùng hiệu quả khi query dùng các cột từ trái sang (leftmost prefix).

Với INDEX (status, created_at):

• WHERE status = 'paid' AND created_at > ...: dùng tốt.
• WHERE status = 'paid' ORDER BY created_at DESC: dùng cho cả lọc lẫn sắp xếp.
• WHERE created_at > ... (không có status): thường không dùng được.

Nguyên tắc chọn thứ tự: cột so sánh bằng (=) đặt trước, cột so sánh khoảng hoặc sắp xếp đặt sau. Nếu index chứa đủ mọi cột query cần (covering index) thì DB không phải đọc lại bảng.

Hay sai: tạo riêng index cho từng cột rồi nghĩ rằng chúng sẽ kết hợp hiệu quả như một composite index.

RAG (Retrieval-Augmented Generation) tìm các đoạn tài liệu liên quan rồi đưa vào prompt để LLM trả lời dựa trên đó, giúp dùng dữ liệu riêng, cập nhật mà không cần train lại.

Các bước:

1. Nạp và làm sạch tài liệu (PDF, wiki), giữ metadata và quyền truy cập.
2. Chunking theo cấu trúc (tiêu đề, đoạn), có chồng lấp hợp lý.
3. Embedding và lưu vào vector DB.
4. Truy xuất: kết hợp tìm vector và từ khoá (hybrid), rồi rerank.
5. Sinh câu trả lời với prompt yêu cầu bám nguồn và trích dẫn, trả lời "không biết" khi thiếu thông tin.

Hay sai: bỏ qua phân quyền, để người dùng nhận được nội dung từ tài liệu họ không được xem.

GIL (Global Interpreter Lock) trong CPython chỉ cho một thread chạy bytecode Python tại một thời điểm. Vì vậy threading không tăng tốc tác vụ nặng CPU, nhưng vẫn hữu ích cho I/O vì GIL được nhả ra khi chờ mạng, đĩa.

• I/O, số lượng vừa phải, thư viện blocking: threading hoặc ThreadPoolExecutor.
• I/O rất nhiều kết nối đồng thời: asyncio với thư viện async (httpx, asyncpg).
• Nặng CPU: multiprocessing hoặc ProcessPoolExecutor, hoặc dùng thư viện viết bằng C như NumPy (nhả GIL khi tính toán).

Từ Python 3.13 có bản build free-threaded (không GIL) tuỳ chọn, nhưng chưa phải mặc định và còn phụ thuộc thư viện hỗ trợ.

Người phỏng vấn muốn nghe: bạn phân biệt được bài toán I/O-bound và CPU-bound trước khi chọn công cụ.

N+1 là khi lấy danh sách bằng 1 query, rồi mỗi phần tử truy cập quan hệ lại sinh thêm 1 query. Ví dụ duyệt 50 bài viết và in post.author.name sẽ thành 51 query.

• select_related: dùng SQL JOIN, cho quan hệ trỏ tới một object (ForeignKey, OneToOne).
• prefetch_related: chạy query riêng rồi ghép trong Python, cho quan hệ nhiều (ManyToMany, reverse ForeignKey).

posts = (Post.objects
         .select_related("author")
         .prefetch_related("tags"))

Phát hiện bằng Django Debug Toolbar, hoặc assertNumQueries trong test.

Hay sai: gọi .filter() trên quan hệ đã prefetch bên trong vòng lặp. Lệnh đó tạo query mới và bỏ qua dữ liệu prefetch; dùng Prefetch(..., queryset=...) để lọc ngay từ đầu.

"In my last project, we needed to send notifications to users after each order. Instead of calling the notification service directly, I proposed using a message queue. The main reason was reliability: if the notification service was down, messages would wait in the queue instead of being lost. It also made the order API faster. The trade-off was more infrastructure to maintain, but the team agreed it was worth it."

Mẹo: nói theo thứ tự vấn đề, các lựa chọn, lý do chọn, đánh đổi. Các cụm hữu ích: "The main reason was…", "The trade-off was…", "We considered… but…". Người Việt hay quên nói phần đánh đổi, trong khi đó là điểm người phỏng vấn chờ nghe.

Chọn điểm yếu thật, không chí mạng với vị trí, và cho thấy bạn đang cải thiện.

Cấu trúc: điểm yếu, ảnh hưởng đã gặp, việc bạn đang làm để khắc phục, tiến bộ đến nay.

Câu mẫu: "Trước đây em hay ngại hỏi khi bị kẹt, tự loay hoay quá lâu, có lần làm trễ task. Giờ em tự đặt giới hạn: kẹt quá một hai giờ mà không có hướng thì em hỏi đồng đội, kèm những gì đã thử. Từ khi làm vậy em xong việc đúng hạn hơn và học được nhanh hơn từ người khác."

Ví dụ khác có thể dùng: chưa quen nói trước đám đông, tiếng Anh nói chưa trôi chảy, hay ôm việc.

Hay sai: "Điểm yếu của em là quá cầu toàn" (nghe như né câu hỏi), hoặc nêu điểm yếu là kỹ năng cốt lõi của vị trí.