Expertise
.NET performance, production and observability
The most expensive problems often sit between components: an API waits for a service, which waits for a database or another engine. Diagnosis has to follow the real request path.
Diagnose before optimizing
I first locate the latency or anomaly before proposing a fix. Low CPU does not rule out a performance issue in a distributed application: the root cause can be sequential network calls, a slow dependency, SQL, locking or cascading waits between services.
SQL Server and execution plans
My experience includes SQL query optimization, execution-plan analysis and moving some workloads into stored procedures when that gives a measurable or operational benefit. The choice depends on the observed bottleneck.
Observability
Application logs, Splunk, Kibana and Application Insights are tools I have used. The goal is to make a user-visible symptom traceable to the dependency or backend operation that produced it.
Production support
On trading systems, level-3 support is part of the engineering role. Design decisions should therefore include diagnostics and recovery: useful logs, correlation, partial-failure behavior and operational procedures. At ENGIE GEMS, automation through CI/CD and improved logging helped make support more autonomous outside European hours.
I treat performance as a property of the whole system: application, dependencies, data, infrastructure and observability.