Senior Software Engineer (Python)

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

React 19 tập trung vào việc xử lý thao tác bất đồng bộ (gửi form, mutation) gọn hơn:

• Actions: truyền hàm async vào <form action={fn}> hoặc chạy trong startTransition. React tự theo dõi trạng thái pending, lỗi, và reset form.
• useActionState: giữ kết quả của action (thông báo lỗi, dữ liệu trả về) và cờ isPending.
• useFormStatus: component con (nút submit) đọc trạng thái pending của form cha mà không cần truyền props.
• useOptimistic: hiện kết quả ngay (like, thêm comment) trong lúc chờ server, tự quay về nếu lỗi.
• use(): đọc Promise hoặc Context, gọi được trong điều kiện.
• ref được truyền như prop thường, ít cần forwardRef.

Người phỏng vấn muốn nghe: những API này bỏ bớt code tự quản lý isLoading, error và rollback, và kết hợp tự nhiên với Server Actions trong Next.js.

Cả ba dùng để tránh tính toán hoặc render lại không cần thiết:

• useMemo: nhớ kết quả của phép tính tốn kém.
• useCallback: nhớ hàm, để tham chiếu không đổi giữa các lần render.
• React.memo: bỏ qua render component con nếu props không đổi (so sánh nông).

Chúng thường phải đi cùng nhau: truyền hàm mới mỗi lần render vào component đã memo thì memo vô tác dụng.

Dùng tràn lan làm code khó đọc, tốn công so sánh dependency, và dễ sai khi thiếu dependency. Chỉ nên dùng khi đã đo bằng React DevTools Profiler và thấy chậm, hoặc khi giá trị đó là dependency của effect.

React Compiler có thể tự thêm memo khi build, giảm nhu cầu viết tay.

Người phỏng vấn muốn nghe: trước khi memo, hãy thử đưa state xuống thấp hơn hoặc truyền component qua children để giảm phạm vi render lại.

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.

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.

Context manager đảm bảo việc "mở" và "dọn dẹp" luôn đi cùng nhau, kể cả khi có exception: đóng file, trả connection, nhả lock, rollback transaction.

Cách nhanh nhất là dùng contextlib.contextmanager:

from contextlib import contextmanager

@contextmanager
def db_transaction(conn):
    try:
        yield conn
        conn.commit()
    except Exception:
        conn.rollback()
        raise

• Cách đầy đủ: viết class có __enter__ và __exit__(self, exc_type, exc, tb). Nếu __exit__ trả về True thì exception bị nuốt.
• Bản async: async with, __aenter__/__aexit__ hoặc asynccontextmanager.

Hay sai: quên raise lại exception trong khối except, khiến lỗi bị che mất và code phía sau tưởng mọi thứ đã thành công.

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.