The recruiter's email is explicit: "è molto probabile che approfondiscano le esperienze e le
tecnologie che hai indicato nel tuo CV [...] preparati a fornire esempi pratici dei progetti su cui
hai lavorato." Don't treat this as a formality — concrete, specific answers (numbers, actual
decisions you made, actual tradeoffs) read as far more senior than generic pattern-recitation, and
they're checking that the CV isn't inflated.
Use the STAR structure for each: Situation, Task, Action, Result. Practice saying
each one out loud, not just reading it — the goal is fluency under a follow-up question, not a
memorized script.
Below are prompts built directly from your CV entries. For each, actually write (or say out loud) a
2–3 sentence answer before moving on — the flashcards on this topic are the prompts themselves,
review = making yourself answer again from a blank state.
Walk through the Azure AI Document Intelligence project: what was the business problem, and what did YOU specifically build?
tap to reveal answer
Structure your answer: the business need (automating document processing that was previously manual), your role (training custom extraction models on 500+ documents, pairing with Azure OpenAI for recognition/categorization/data extraction), and the stack (.NET 8, Azure, MS SQL, CosmosDB, Minimal APIs, Redis). Be ready for a follow-up on HOW you trained/validated a custom extraction model, and what accuracy or edge cases you handled.
You implemented JWT-based authentication and custom role/permission-based authorization, including Azure AD (Entra ID) app registrations. Be ready to explain: what's actually IN a JWT, and how did your authorization logic use it?
tap to reveal answer
A JWT has three parts: header (algorithm), payload/claims (e.g. user ID, roles, permissions, expiry — base64-encoded, NOT encrypted, so never put secrets in it), and signature (verifies it wasn't tampered with, using the issuer's key). Be ready to explain how your custom role/permission system read claims from the token to make authorization decisions, and how Entra ID app registrations fit into issuing/validating those tokens.
The Bank Authorization Flow Manager involved amount-based, multi-approval authorization across 15+ offices. What made this technically interesting, and what would you highlight as the hardest part?
tap to reveal answer
Think about: modeling the approval rules (likely a Strategy or rules-engine-shaped problem — similar reasoning to the discount example, different approval thresholds/paths depending on amount/office), data consistency across offices, and audit/traceability requirements for financial approvals (this is a great moment to mention 'managed sensitive and legally-binding data, building audit tools' from your CV — have a specific example of what the audit trail captured).
You built multiple microservices for third-party integrations, data extraction/manipulation/syncing (Docker, RabbitMQ, MS SQL). Be ready for: how did you handle a message that failed processing?
tap to reveal answer
This is your chance to connect real experience to the Messaging topics above — describe your ACTUAL retry/error handling approach for these RabbitMQ-based services (even if it wasn't formalized with those exact terms at the time), and be honest about gaps: 'at the time we did X, if I rebuilt it today knowing what I know about DLQs/idempotency I'd add Y' is a strong, senior-sounding answer.
The Delivery Management System integrates a customer's ERP with a SaaS delivery platform, live in 3 countries. What's the 'why' behind that integration, and what synchronization challenges came up?
tap to reveal answer
Focus on: why an integration (vs. one of them just using the other's system directly) — likely each system needed to stay the source of truth for its own domain (ERP owns orders/inventory, SaaS owns delivery logistics) — which is a live Bounded Context example from your own work. Be ready to describe an actual sync failure/edge case (e.g. a delivery sheet generated before an ERP update landed) and how it was handled.
You onboarded new engineers and explained the domain/internal systems as the team grew. What's one thing you changed about HOW you explained the domain after doing it more than once?
tap to reveal answer
This is a behavioral/soft-skill question in disguise — have one concrete, specific improvement ready (e.g. 'I started with the domain vocabulary/ubiquitous language before touching code, because jumping straight to code without shared vocabulary caused more re-explaining later'), not a generic 'communication is important' answer.
As one of the first two engineers on the product team working directly with the founding shareholder, what's an example of you proposing/pushing back on a technical decision, and what happened?
tap to reveal answer
Prepare ONE real, specific story: what you proposed, why, what the alternative/pushback was, and the actual outcome (even if it wasn't fully adopted — 'I proposed X, we ended up doing a modified version because of Y constraint' is a completely fine and honest answer, and shows judgment, not just technical opinions in a vacuum).