Senior Backend Engineer - Python/Django & AWS

asyncio chạy nhiều coroutine trên một thread. Khi coroutine gặp await một thao tác I/O, nó nhường quyền cho event loop chạy coroutine khác. Đây là đa nhiệm hợp tác: coroutine nào không await thì chiếm luôn cả loop.

Trong FastAPI:

• async def khi mọi thứ bên trong đều async (httpx.AsyncClient, driver DB async).
• def khi dùng thư viện blocking (requests, ORM đồng bộ). FastAPI sẽ chạy hàm này trong threadpool, nên không chặn loop.
• Gọi song song: await asyncio.gather(fetch_a(), fetch_b()).

Hay sai: viết async def rồi gọi requests.get() hoặc time.sleep() bên trong. Cả server đứng hình trong lúc chờ. Nếu buộc phải gọi code blocking, dùng await asyncio.to_thread(func).

Người phỏng vấn muốn nghe: async tăng khả năng xử lý đồng thời cho I/O, không làm code CPU nhanh hơn.

CPython dùng reference counting: object bị giải phóng ngay khi số tham chiếu về 0. Bộ thu gom gc chạy thêm để dọn các vòng tham chiếu (A trỏ B, B trỏ A).

Nguyên nhân leak hay gặp:

• Cache toàn cục (dict, lru_cache không giới hạn) chỉ thêm không xoá.
• Biến ở module hoặc class tích luỹ dữ liệu qua các request.
• Đọc cả file hay cả queryset lớn vào bộ nhớ thay vì xử lý theo lô.
• Extension C giữ bộ nhớ ngoài tầm GC.

Cách điều tra:

• tracemalloc: chụp snapshot hai thời điểm rồi so sánh dòng code cấp phát nhiều nhất.
• Theo dõi RSS theo thời gian, thử tái hiện với một loại request.
• Giải pháp tạm: cấu hình worker tự khởi động lại sau N request (Gunicorn max_requests, Celery max_tasks_per_child).

Người phỏng vấn muốn nghe: bạn đo trước khi đoán, và biết giải pháp tạm không thay cho việc tìm nguyên nhân.

Đ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.

RPO là lượng dữ liệu tối đa chấp nhận mất (tính theo thời gian); RTO là thời gian tối đa để khôi phục dịch vụ. Hai con số này do nghiệp vụ quyết định và định giá chiến lược.

Từ rẻ đến đắt:

• Backup & restore: sao lưu sang region khác, dựng lại khi cần; RTO hàng giờ.
• Pilot light: dữ liệu được replicate liên tục, chỉ phần lõi chạy sẵn.
• Warm standby: bản thu nhỏ chạy sẵn ở region khác, scale lên khi failover.
• Active-active: nhiều region cùng phục vụ; RTO/RPO gần 0, phức tạp nhất.

Hay sai: có backup nhưng chưa bao giờ thử khôi phục. Kế hoạch DR phải được diễn tập định kỳ.

Dùng mô hình landing zone: tách account (AWS), subscription (Azure) hoặc project (GCP) theo môi trường và team để cô lập quyền, chi phí và phạm vi sự cố.

• Quản lý tập trung bằng AWS Organizations, Azure Management Groups, GCP Organization/Folder.
• Áp guardrail ở cấp tổ chức: chặn region không dùng, bắt buộc mã hoá, cấm tắt log audit (SCP, Azure Policy, Organization Policy).
• Đăng nhập tập trung qua SSO, cấp quyền theo nhóm.
• Tài khoản riêng cho log audit và bảo mật, team ứng dụng không xoá được.
• Mạng nối qua hub (Transit Gateway, hub-spoke VNet, Shared VPC).
• Tag bắt buộc để phân bổ chi phí.

Người phỏng vấn muốn nghe: cân bằng giữa tự chủ của team và kiểm soát tập trung.

Mỗi kỹ thuật giải một vấn đề khác nhau, nên cần xác định điểm nghẽn là đọc, ghi hay kích thước dữ liệu.

• Read replica: giảm tải đọc. Phải chấp nhận replication lag; luồng vừa ghi xong đọc lại nên đọc từ primary.
• Partitioning (trong một DB): chia bảng theo khoảng thời gian hoặc theo key. Query có điều kiện trên partition key chỉ quét phần liên quan, xoá dữ liệu cũ bằng DROP PARTITION rất nhanh.
• Sharding (nhiều DB): khi một máy không chịu nổi lượng ghi hoặc dung lượng. Đổi lại phải chọn shard key cẩn thận, query xuyên shard và transaction phân tán rất khó.

Thứ tự hợp lý: tối ưu query và index, archive dữ liệu cũ, thêm replica và cache, partition, cuối cùng mới shard.

Hay sai: chọn shard key gây hot spot, vd. theo ngày tạo khiến mọi lượt ghi dồn vào một shard.

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.

"I'm a backend developer with about three years of experience, mostly working with Java and Spring Boot on payment systems. In my current role, I'm responsible for the reconciliation module and I've worked closely with clients in Japan and Singapore. I enjoy solving performance problems and improving code quality. Now I'm looking for a product-focused team where I can grow into system design, which is why this position caught my attention."

Mẹo: giữ khung hiện tại – quá khứ – tương lai, nói khoảng một phút. Dùng "I'm responsible for…", "I've worked on…" thay vì "I am in charge about…". Đừng mở đầu bằng tên trường hay quê quán.

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í.