Allowed R6 · Within policy
{
"slug": "clean-architecture-and-mediator",
"title": "Clean Architecture and MediatR",
"difficulty": "medium",
"tags": [
"system-design",
"oop-design",
"technical",
"backend"
],
"is_free": true,
"locked": false,
"frequency": 0.5,
"last_reported_at": "2025-10-14T14:13:31.822028Z",
"url": "https://www.mokabla.com/en/c/moneyfellows/clean-architecture-and-mediator",
"agent": {
"page": "https://www.mokabla.com/agent/en/c/moneyfellows/clean-architecture-and-mediator",
"question": "https://www.mokabla.com/agent/_call/get_question?company=moneyfellows&question=clean-architecture-and-mediator"
},
"company": {
"slug": "moneyfellows",
"name_en": "MoneyFellows"
},
"body_md": "## What they ask\nThe on-site technical round is long, one to two hours, and most of it is a design conversation rather than live coding. The backend is .NET, and the recurring theme is Clean Architecture and the Mediator pattern: how you have used them, where they helped, and where they got in the way.\n\nExpect a prompt along these lines:\n\n> Design the backend module for a savings circle (gam3eya): members join a circle, pay monthly, and one member receives the payout each cycle. Show me the layers, the use cases, and how a `PayInstallment` request flows through the system.\n\nThey then go deep on specifics:\n\n- Which layer owns the rule \"a member cannot receive the payout before completing their payments\", and why.\n- How a MediatR request handler, a pipeline behavior for validation, and the domain entities relate.\n- What happens when two handlers must touch the same aggregate in one transaction.\n- What you would not put behind the mediator.\n\nThey also ask about the technical work at your current company in real detail: what you built, what you would change, and how you made architectural decisions.\n\n## What they look for\n- The dependency rule stated correctly: domain at the centre, application use cases around it, infrastructure and web on the outside.\n- Pragmatism. Saying \"for a small CRUD module this is overkill\" is a good sign, not a bad one.\n- Concrete experience with CQRS-style handlers, validation behaviors, and unit-testing a handler in isolation.\n- Money handling instincts: idempotent payment commands, decimal types, an audit trail.\n\nThe interviewers are described as friendly and the round conversational, so ask questions back.",
"follow_ups_md": "- Where do you put a cross-cutting concern like logging or retries in this design?\n- How do you version a use case when the mobile app cannot update immediately?\n- Would you use domain events here, and who handles them?",
"access": "Question bodies are paid content: a person buys 30 days of access per company (200 EGP or 200 points) in the human app. Agents get titles, tags and difficulty; bodies only for free questions."
}