Bagrat Antonyan

• .NET

  Partial

  Bagrat demonstrated a strong grasp of dependency injection and a solid, practically grounded understanding of FinTech domain nuances, including appropriate use of Redis and RabbitMQ to address performance and throughput concerns. He correctly distinguished IEnumerable from IQueryable, though his explanation stopped at the surface level and would benefit from a deeper understanding of how queries are composed and translated to SQL. Similarly, he knows where a CancellationToken should be applied but could not explain the underlying mechanism. On design patterns, he applies established best practices competently but tends to adopt them as received solutions rather than reasoning from first principles about why a given pattern fits the problem at hand; his account of CQRS followed the same shape — familiar with the concept, less clear on the justification for choosing it. Overall: dependable applied knowledge with a consistent gap in depth of underlying mechanics and design rationale.

• API design

  Partial

  Bagrat discussed REST API design confidently, covering controllers and actions in .NET, HTTP method semantics — where and how each should be used, which he handled well — and content negotiation across JSON and XML. He explained how authentication and authorization middleware operate within the request pipeline at a level consistent with a mid-level engineer: sufficient to work effectively with the framework and to build and maintain APIs independently, without extending into deeper architectural or edge-case considerations. Overall: solid, working command of API design fundamentals appropriate to his current level.

Advised Bagrat to go deeper on solutions: understand the real problem, research alternatives, and present two or three of his own options to the team with trade-offs, rather than defaulting to an established best practice. Also recommended strengthening theory to match his practical experience — the gaps observed (query translation, CancellationToken mechanics, CQRS and pattern rationale) all reflect knowing how to use something without knowing how it works.

1. 1

   Own one design decision end-to-end. On the next non-trivial task, define the actual problem first, then prepare two or three of his own solution options with trade-offs and present them to the team before implementation. Target: one per sprint or per major task.

2. 2

   Close the mechanics gaps. Go one level below current usage on the topics identified: EF Core query translation (expression trees → SQL), how CancellationToken propagation actually works, and the reasoning behind CQRS and the patterns he already applies. Suggested cadence: one topic per month, with a short write-up or team share to confirm understanding.

3. 3

   Shift the theory/practice balance. Add structured reading alongside hands-on work — .NET internals, distributed systems fundamentals, and architecture rationale rather than how-to material. Roughly 2–3 hours per week.

4. 4

   Take initiative visibly. Volunteer for one task per sprint that is unfamiliar or under-specified, where the solution isn't dictated by an existing best practice — this is where the gap between Mid+ and Senior actually closes.