Muhammad Hamdy
Full Stack Developer
JavaScript
SQL
TypeScript
Python
C#
API Design: 4/10
Data Layer & Database: 4/10
System Architecture: 4/10
Active 1 day ago
+20 (10) 69997044
Invite to interview
Message
Download CVCV
Overview
Technical skills
Timeline
Roles
Overview
Backend API engineer (Middle) focused on building small .NET microservices and REST endpoints with solid, conventional implementations. The strongest proven skill is implementing simple .NET microservice APIs and EF Core-backed persistence as seen in PlatformsController, AppDbContext and the EF Core migration files. Public code does not show production-grade resilience, observability, secure authn/authz, or advanced data/transaction design.
Technical skills
JavaScript
SQL
TypeScript
Python• Middle • 3y+
C#• Middle
Python
SQLAlchemy
C#
Blazor
ASP.NET Core
AutoMapper
.NET
Entity Framework Core
AI/ML
Computer Vision
Frontend
Angular
DevOps
Git
DevOps
Nginx
Analytics
Power BI
Mobile
Repository Pattern
Timeline
Software Engineer (SaaS ERP System)
•
Middle
MKProHub
•
Full-Time
Contributed to the development and ongoing maintenance of a scalable multi-tenant SaaS ERP platform. Implemented core business modules for HR, Finance, Inventory, and Procurement using clean architecture and established coding practices. Worked in an Agile/Scrum team with sprint planning, daily stand-ups, and code reviews. Built and consumed RESTful APIs to support communication between services and client applications.
.NET
C#
Entity Framework Core
Angular
British University in Egypt
Bachelor's Degree •
Mechanical Engineering
Middle Backend Developer
Confidence: Medium API Engineer
Backend API engineer (Middle) focused on building small .NET microservices and REST endpoints with solid, conventional implementations. The strongest proven skill is implementing simple .NET microservice APIs and EF Core-backed persistence as seen in PlatformsController, AppDbContext and the EF Core migration files. Public code does not show production-grade resilience, observability, secure authn/authz, or advanced data/transaction design.
API Design
4/10
How well APIs are designed
API design is conventional and functional with clear REST endpoints and use of CreatedAtRoute for resource creation, but lacks versioning, idempotency, pagination and a consistent error contract beyond basic NotFound and simple try/catch.
Evidence
PlatformService/PlatformService/Controllers/PlatformsController.cs: GetPlatforms, GetPlatformById and CreatePlatform using CreatedAtRoute and NotFound
CommandsService/CommandsService/Controllers/PlatformController.cs: simple POST endpoint stub
Data Layer & Database
4/10
Working with databases
Data layer uses Entity Framework Core with migrations, DbContext, repository abstraction and model validation attributes, showing standard schema and data access choices but no visible transaction management, migration chain beyond initial migration, or advanced hand-tuned SQL.
Evidence
PlatformService/PlatformService/Migrations/20260805073249_InitialMigration.cs: Initial EF Core migration creating Platforms table
PlatformService/PlatformService/Models/Data/AppDbContext.cs: EF Core DbContext definition
PlatformService/PlatformService/Models/Platform.cs: model with [Required] annotations and properties
Scalability & Performance
2/10
Handling load and speed
Little evidence of explicit scalability or performance engineering; there is a synchronous HTTP-based sync between services but no caching, queue-based decoupling, retry/backoff strategies or rate-limiting configured.
Evidence
PlatformService/PlatformService/SyncDataServices/CommandDataClient.cs: synchronous HTTP client used to send platform data to command service
CommandsService/CommandsService/Program.cs: basic request logging middleware but no rate limiting or caching layers
System Architecture
4/10
Overall system structure
Project is decomposed into small services with DTOs, mapping and a repo layer, showing conscious microservice/API separation and some module boundaries for data, controllers and sync clients, but decomposition appears educational/demo-level without inter-service contracts, service discovery, or production-grade config/secret management.
Evidence
PlatformService/PlatformService/Dtos and Profiles: use of DTOs and AutoMapper (PlatformProfile.cs)
PlatformService and CommandsService projects: separate services and SyncDataServices/Http client for inter-service communication
Security & Auth
2/10
Protecting data and access
Minimal security controls are visible - model validation attributes present and HTTPS redirection is enabled, but there is no authentication/authorization, token lifecycle, input-sanitization beyond DataAnnotations, or secrets handling.
Evidence
PlatformService/PlatformService/Models/Platform.cs: DataAnnotations [Required] used on properties
CommandsService/CommandsService/Program.cs: app.UseHttpsRedirection() present but no auth middleware
Reliability & Observability
2/10
Stability and monitoring
Basic observability and reliability practices exist such as Console logging and simple try/catch around outgoing calls and migration application, but there is no structured logging, correlation ids, metrics, retry/backoff, circuit breakers or health checks evident.
Evidence
CommandsService/CommandsService/Program.cs: simple request logging middleware using Console.WriteLine
PlatformService/PlatformService/Controllers/PlatformsController.cs: try/catch when calling remote command service and Console.WriteLine logging
PlatformService/PlatformService/Models/Data/PrepDb.cs: migration attempt wrapped in try/catch with Console logging
Expertise
.NET• Middle
Microservices & API Architecture• Middle
Python• Junior
Technologies
.NET
Entity Framework Core
AutoMapper
Recommendations
- Implement resilience patterns for inter-service calls - add retries with exponential backoff, timeouts and a circuit breaker around CommandDataClient calls.
- Add structured logging and correlation ids plus basic metrics and health endpoints to improve observability and incident response.
- Harden API surface - add authentication/authorization, input validation beyond DataAnnotations, and explicit secrets/config management (e.g. use secret store or environment-based configuration).
- Improve data-layer practices - add explicit migration history, transactional boundaries where needed, and integration tests for repository operations and migrations.
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories:
Junior DevOps Engineer
Confidence: Medium Platform SRE
Platform SRE (junior) specializing in basic Linux system configuration and hands-on debugging for server stacks. The strongest proven skill is low-level system configuration automation using Puppet and shell exec resources as shown in 0x0B-ssh/100-puppet_ssh_config.pp and 0x1B-web_stack_debugging_4/*.pp. There is no evidence of CI/CD pipelines, container orchestration, cloud architecture, observability instrumentation, or automated testing in the public code.
CI/CD Pipelines
Automated build and deploy
Not evidenced in public code
Infrastructure as Code
2/10
Managing servers with code
Basic infrastructure-as-code work is present through small Puppet manifests that change SSH and system limits, but there is no evidence of modules, remote state, environment separation, or infra testing.
Evidence
0x0B-ssh/100-puppet_ssh_config.pp
0x1B-web_stack_debugging_4/1-user_limit.pp
Containerization & Orchestration
Working with containers
Not evidenced in public code
Observability & Monitoring
Watching system health
Not evidenced in public code
Reliability & Incident Response
2/10
Keeping systems up
Simple operational fixes and restart workflows are scripted (ulimit edits and nginx restart), indicating hands-on debugging and basic reliability work but no runbooks, postmortems, progressive delivery, or automated rollback logic.
Evidence
0x1B-web_stack_debugging_4/0-the_sky_is_the_limit_not.pp
0x1B-web_stack_debugging_4/1-user_limit.pp
Cloud & Cost Optimization
Smart use of the cloud
Not evidenced in public code
Expertise
Platform Engineering & IDP• Junior
Technologies
DevOps
Nginx
Recommendations
- Build repeatable IaC modules and versioned manifests (eg. move Puppet work into reusable modules and add tests or a small Terratest/serverspec suite).
- Add a minimal CI workflow to validate manifests and Python scripts (linting, unit tests for Python, and a pipeline that runs puppet-lint or equivalent).
- Introduce containerization and simple k8s manifests or Dockerfiles for services to practice deployment and orchestration patterns.
- Instrument services with lightweight observability (Prometheus metrics or log forwarding) and document runbooks and rollback criteria for common failures.
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories:
Junior QA Engineer
Confidence: Medium Generalist
Junior Python-focused developer and generalist with a track record of learning-focused projects and basic unit testing; strongest at small-scale Python OOP and unit tests. Proven skill: unit testing and model serialization demonstrated by 0x0C-python-almost_a_circle/tests/test_base.py together with models/base.py. Limitations: no evidence of CI-driven test orchestration, test infrastructure (fixtures/factories/mocks), integration/contract testing, or performance/load testing.
Test Automation Frameworks
2/10
Building automated tests
Basic unit tests using unittest are present but there is no custom test infrastructure, fixtures, factories, parallelization or mock servers.
Evidence
0x0C-python-almost_a_circle/tests/test_base.py
0x0C-python-almost_a_circle/tests/test_rectangle.py
Test Coverage & Strategy
2/10
What and how to test
Some unit and functional tests exist and check functionality and PEP8/docstrings, but test strategy is limited to happy-path checks and style assertions rather than risk-based, boundary, or property-based testing.
Evidence
0x0C-python-almost_a_circle/tests/test_base.py
0x0C-python-almost_a_circle/tests/test_square.py
API & Integration Testing
1/10
Testing how parts work together
Small scripts interact with databases and ORM (SQLAlchemy/MySQLdb) but there is no evidence of contract testing, schema validation, idempotency checks, or integration testcontainers-based tests.
Evidence
0x0F-python-object_relational_mapping/0-select_states.py
0x0F-python-object_relational_mapping/10-model_state_my_get.py
Performance & Load Testing
Testing speed under load
Not evidenced in public code
Bug Reporting & Analysis
Finding and describing bugs
Not evidenced in public code
CI Test Integration
Running tests automatically
Not evidenced in public code
Expertise
Unit & Component Testing• Junior
Industries
Travel & Tourism• Junior
Technologies
Python• Middle • 3y+
JavaScript
TypeScript
SQL
C#• Middle
SQLAlchemy
Git
ASP.NET Core
Blazor
Recommendations
- Develop isolated test infrastructure: add fixtures, data factories and mocks for API/DB isolation (use unittest fixtures or pytest + fixtures).
- Add integration tests for ORM code using testcontainers or a local disposable DB and validate error paths (409/422/timeout) and schema contracts.
- Introduce CI configuration that runs tests, collects artifacts and enforces style; add per-test retry/quarantine rules for any flaky tests.
- Replace use of eval and insecure patterns in persistence reload paths and add explicit error handling and input validation.
- Practice writing negative-path and boundary tests (exact expected error codes/messages) and a small property-based test or invariants using Hypothesis or similar.
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories: