Python в ML: минимум, который должен знать каждый

Main ideas and lessons

• The bar for Python in ML interviews is rising. What used to be mostly basic algorithmic Python knowledge (data structures like hashmaps, tuples, etc.) has expanded into topics resembling backend Python interviews plus ML production realities.
• ML developers are expected to be “end-to-end.” Not only do they build models, they also deploy/serve them and integrate common infrastructure components.
• Interview vs. job needs overlap but differ. The video emphasizes focusing on what’s useful for:
  • passing the interview (common Python questions), and
  • working in production (practical engineering skills to avoid breaking systems).

---

What you need to know for “Sabes” (interview-focused Python essentials)

1) Concurrency in Python (multithreading, multiprocessing, async) — the #1 topic

• Why it’s asked: It appears in ~99% of interviews and can be tested via:
  • scenario/case questions (word problems), or
  • direct conceptual questions (“threads vs processes vs async—differences?”).

Core distinctions

• Processes: separate CPU execution units (needed for CPU-bound parallelism).
• Threads: parallelism within the same process (but constrained by Python behavior).
• Asynchronous execution (async/await): typically runs in one thread, scheduling work when waiting for I/O.

What to choose depending on the task type

• CPU-bound operations (example: parallelizing heavy computation)
  • Use multiprocessing (processes).
• I/O-bound operations (example: downloading files, reading/writing data, network access)
  • Use multithreading and/or async.

GIL concept (critical for avoiding wrong answers)

• Python’s GIL blocks true CPU parallelism via threads, so threads won’t speed up CPU-bound tasks.
• Red flag: if you don’t know GIL / processes / threads differences, the speaker claims you have a very high chance of failing.

How interview cases are typically structured

• You’re given a scenario like:
  • “You have a million URLs; download text files or images; then process them (e.g., text via a ‘quencher’, images via a ‘clips’ mechanism).”
• Expected reasoning:
  • Downloading is I/O-bound → handle with async or threads.
  • Processing/executing the next heavy stage is CPU-bound → handle with processes.
• Expected architecture idea:
  • download many items concurrently (I/O handling),
  • then feed results into multiple running processes for CPU-bound work.

---

2) Turning model solutions into a service (FastAPI/Triton)

• Expected interview answer style: talk about experience at a high level:
  • build model/logic,
  • wrap it in a FastAPI server so it can receive requests and return responses,
  • if the model is expensive/heavy, optionally deploy/serve it via Triton server,
  • mention request handling and integration into a larger system by others (handoff).
• Important claim: interviews usually don’t go deep into FastAPI internals; knowing how the pieces fit is sufficient.
• Optional but recommended component: Triton server’s query batching for efficiency.

---

3) Core Python data-structure and language questions (asked “100% of the time”)

Common topics and example question types:

• Hashmaps / dict-like structures

  • What a hashmap is and how it works.
  • Why lookup/search is fast.
  • When to use it.
  • What collisions are and how they are resolved.
  • Advanced variants:
    • how to check whether an object is hashable,
    • how to define your own hashing behavior.

• Data structures classification

  • List data structures you know.
  • Mutable vs immutable differences.
  • Examples: list vs tuple, strings vs numbers.

• Decorators

  • What a decorator is.
  • Write a simple decorator (example given: measure function execution time and print it).

• Context managers

  • What a context manager is (example: with ... / open).
  • How to implement one, including required methods:
    • __enter__
    • __exit__

• Common “gotchas”

  1. Default mutable argument bug
     • Function defined with an empty list default; each call mutates the same list instance across invocations.
     • Why: default argument objects are created at function definition time, not call time.
  2. Unhashable nested mutable inside tuples
     • Example: a tuple containing a list is not hashable.
     • Reasoning: dictionary keys must be immutable; hashability requires recursive immutability.

---

4) Databases / vector databases for RAG and embeddings

• Why it comes up (especially for NLP/LLM jobs, also CV):
  • many roles involve RAG (retrieval augmented generation),
  • which uses vector search (vector databases).

What to know

• Basic awareness that specialized vector DBs exist and can:
  • store vectors,
  • build indexes,
  • perform fast nearest-neighbor matching (conceptually kNN).

Examples of vector DBs to mention

• Qdrant
• PGVector (vector extension for Postgres)
• Milvus
• (Also mentioned: FAISS-like local options as less suitable for high-load systems.)

“Verification” style question

• If they ask “Why Qdrant instead of PGVector?”
• The speaker claims there’s no single strict logic; a reasonable answer is enough (e.g., easier integration with Postgres in your system).

Redis

• Likely question: use Redis for caching to reduce repeated expensive calls (e.g., caching frequent query results).
• The speaker mentions “dis/dis” as the caching mechanism reference (likely Redis, but the subtitle text is noisy).

---

5) What NOT to waste time learning (topic selection by role)

• SQL

  • For NLP/LLM/CV roles: unlikely to be asked; don’t spend time on SQL.
  • For more general/typical software jobs: SQL is very likely (joins, window functions, etc.).

• Pandas

  • For NLP/CV: not typically required.
  • For classic/general language roles: may be asked more often.

---

6) Docker and Kubernetes basics (common but low depth)

• Docker

  • What Docker image is vs container.
  • Why use Docker instead of a virtual machine.
  • Pros/cons of VMs vs Docker.
  • Docker volumes (what they are; why they matter).
  • Passing large model weights into services (store separately and mount/use volumes).

• Kubernetes

  • The speaker says questions about it are less frequent.
  • If you haven’t used Kubernetes: answer “no experience” and it’s still acceptable.

---

What you need to know to work properly (job-focused engineering skills)

A) Advanced but practical concurrency and scaling skills

• You must understand multiprocessing/multithreading/async to process huge datasets efficiently.
  • Example: processing 5 million images—doing it sequentially will be too slow.
• Avoid a common neural-network mistake
  • Many beginners use threads to run CPU-bound neural work, but due to GIL there is no acceleration.
  • For CPU-bound tasks: use processes.
• Async basics to avoid freezing the event loop
  • Know syntax:
    • async def
    • await / async constructs
  • Don’t insert blocking operations into the async flow, or it will halt the event loop.

---

B) Repository/codebase structure and clean Python practices

• Organize code in a standard project structure:
  • logical modules inside a package/folder (the speaker mentions “SRC”-like structure),
  • a single entry script (example: main.py) that imports and runs logic.
• Use if __name__ == "__main__":
  • to prevent top-level code from running on import.
• Typing
  • Add type hints for readability/maintainability.
  • Important clarification: Python type hints do not automatically enforce runtime type checking by default.
• Packaging/installation
  • Use pip and also tools like uv (subtitle says it imperfectly) for easier dependency management.
• Avoid “spaghetti code” and duplicate logic; split into folders/modules properly.

---

C) Command-line (bash/console) proficiency on remote compute servers

• Why: work often happens on remote high-performance servers; local laptops are often just terminals.

• Skills mentioned:

  • SSH access to servers.
  • Basic terminal navigation and file operations:
    • cd, ls
  • Editing files with Vim (basic navigation).
  • Copying/uploading files:
    • use SCP (and also mention “SCP and AN”, likely rsync; subtitles unclear)
  • Resuming interrupted large transfers:
    • prefer tools that can continue downloads (example given: 100GB zip).
  • Monitoring resources:
    • RAM/process monitoring (top)
    • RAM usage (free -h)
  • Checking disk and file sizes:
    • list sizes and directory sizes (using du and related commands; subtitle text includes df, du -sh-like ideas)
  • Counting files and inspecting folder contents.

---

D) Docker workflow essentials for ML development

• Understand Docker at the level of:
  • basics of what’s in a Dockerfile,
  • being able to run/build containers for development.
• Volume-based development inside containers
  • Problem described:
    • copying files into a container breaks the “live view” between VS Code on the host and the container filesystem.
  • Recommended approach:
    • use Docker Volume / bind mounts so the host folder is visible inside the container,
    • changes locally reflect inside the container in real time.
• Passing code/data efficiently vs copying with docker cp.
• Ability to “enter” a running container / use interactive mode so you can work in the isolated environment.

---

Sources / speakers featured

• The video’s narrator/speaker (host/author of the channel) — no name is given in the subtitles.
• “Nerona” — referenced as a validation system for the speaker’s Python quiz.
• Website / quiz platform (unspecified by name) — referenced as the speaker’s site hosting a free Python quiz.
• Subtitles mention “Sabes” and “Emlchik” — likely the interview platforms/targets, but they are not identified beyond these names.