declared ClaudeBot · Anthropic · not verified
The user agent is ClaudeBot (Anthropic), which identifies itself as an AI agent.
Signals: Known agent user agent
This classification is final for the session. The human pages are not served to agents.
{
"question": {
"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?"
},
"paid": false,
"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."
}
| action | input | permission | |
|---|---|---|---|
| get_question One question with its body. Bodies are paid content unless the question is free. | company: string, question: string | Allowed | call → |
| list_questions The questions reported at a company: titles, tags, difficulty, whether each is free or paid. | company: string, page: number? | Allowed | call → |
| buy_access Buy 30 days of access to a company. | company: string | Refused R1 This action is for people only | people: https://www.mokabla.com/en/pricing |
| post_comment Comment on a question. | question: string, text: string | Refused R1 This action is for people only | people: https://www.mokabla.com/en/companies |
Allowed actions answer in JSON. Add ?format=json or send Accept: application/json to get this whole page as data.