techcheck / mint tech check / 01_prep_map.md

MINT S.p.A (ARM / AdTech) — prep map

6 min read source

MINT S.p.A (ARM / AdTech) — prep map

Preparation map for the MINT interview, built from 00_interview_debrief.md. Same format as links.md and links_2.md: tick the box once reviewed, bold is the primary note.

Domain: Advertising Resource Management — a marketing platform where advertisers top up a balance, run campaigns, and track spend and results. Expect examples to be framed in that language: campaigns, budgets, spend, attribution.

Weighting from the debrief. The AI half carries the most weight — one note-taker says they asked almost only about AI. But DDD and dependency-injector came up independently twice, so those are the non-AI items to drill hardest. Everything else is table stakes you should be able to discuss but probably won’t be grilled on.

Tier 1 — near-certain, drill these

AI: RAG, token optimization, caching, MCP, tool-call optimization

Explicitly listed as what they mostly asked about.

The answer they’re probing for on hundreds of tools: you don’t put them all in context. Tool selection accuracy degrades past roughly 20-40 tools. Options: retrieve a relevant tool subset per request (RAG over tool descriptions), group tools behind fewer coarse tools with a mode parameter, split across MCP servers the client loads per task, or route to a specialised agent with its own narrow tool set. Then note that tool descriptions are prompt tokens on every call, so their length is a cost line.

DDD: Repository and Unit of Work

Called “a must”, raised twice.

Have ready: SQLAlchemy’s Session is a Unit of Work with an identity map — so “we use SQLAlchemy” already means you have one, and an explicit UnitOfWork class is about controlling the transaction boundary and making it testable, not about adding a missing capability. In ARM terms: debiting a campaign budget and writing a spend record must commit or roll back together.

dependency-injector

“The whole project uses it — what it is, what it’s for, what it does.”

Know concretely: Singleton vs Factory vs Resource (the one with teardown, for pools), Configuration, Selector for config-driven implementation choice, container.wire(modules=[...]) and why forgetting a module silently breaks injection, and .override() for tests. The strongest argument for a container over FastAPI Depends(): Depends() can’t wire a Celery task or a Kafka consumer, and this project has both.

AI agents, LangChain, testing agents

Testing agents, condensed: mock the tools so runs are deterministic; assert on the trajectory (which tools were called, in what order) not the exact text; keep a curated regression set scored on outcome; add adversarial cases; and put cost and step-count budgets in CI so a regression that doubles spend fails the build.

Multi-agent, knowledge graph, orchestration

Tier 2 — explicitly named, expect a question each

Microservices, Saga, retries

Saga + retries together: at-least-once delivery means every step must be idempotent, and a saga step that fails after side effects needs a compensating transaction. In ARM terms: reserving budget, charging, and recording spend across services — if the charge fails, the reservation must be released.

Celery, Kafka

Partitioning is the likely question. The partition key determines ordering and parallelism: same key means same partition means ordered. For ARM, keying by campaign_id keeps a campaign’s spend events ordered while allowing parallelism across campaigns. Note that ZooKeeper was removed in Kafka 4.0 — KRaft is the only mode — and that consumer count above partition count leaves consumers idle.

Async, threading, multiprocessing

AI in your own work

Books to be able to name and say one real thing about: Evans or Vernon on DDD, Cosmic Python (Percival & Gregory) — which is the Python Repository/UoW/DDD book and directly relevant here, Fowler’s Patterns of Enterprise Application Architecture for Repository and UoW, Kleppmann’s Designing Data-Intensive Applications. Naming Cosmic Python specifically will land well given the stack.

Tier 3 — on the list, be conversational

Not covered in these notes

Be honest if asked rather than bluffing:

Item Note
Go listed in the stack; no notes here. Likely secondary for a Python role — say you’d pick it up, and that you understand goroutines/channels conceptually if you do.
Scala same; almost certainly legacy or data-platform adjacent.
AdTech domain specifics auctions, RTB, attribution windows, viewability. Worth 30 minutes of reading — knowing the vocabulary (impression, CPM, attribution, pacing) helps you frame answers in their language.

Suggested order

If time is short, spend it in this order — it follows the debrief’s weighting:

  1. RAG + hybrid search + reranking, then tool-call optimization at scale and caching/token cost. This is where they concentrated.
  2. MCP, including the stateless-core change.
  3. dependency-injector — provider types, wiring, override for tests.
  4. Repository + Unit of Work, framed with SQLAlchemy’s session.
  5. Testing agents — trajectory assertions, mocked tools, regression sets.
  6. Saga + retries + idempotency as one connected answer.
  7. Kafka partitioning, Celery retries, async vs threads vs processes.
  8. How you use AI — rehearse it; they will ask, and a vague answer costs you.
Previous
interview debrief