§ 01Snapshot
- Levelmid-level backend engineer, around five years of experience. Not a lead or architect. Best for reviewing mid-level backend PRs, with a senior lead owning the architecture.
- Roles heldmid-level software development engineer at a global e-commerce and cloud company. They also report earlier engineering work in financial services; that part is unverified.
- Scaleindividual contributor; no people-management scope
- Industriese-commerce / cloud · financial services (by their account)
- Company typesbig tech (very large enterprise) · large financial institution (by their account)
- Specialtiesbackend correctness, the scalability of individual services, and code quality held to a big-tech interview bar
- Best forsolo founders and seed startups that need a disciplined second pair of eyes on backend PRs · teams preparing engineers for a big-tech code-quality bar
- Core stackbackend services and distributed systems at big-tech scale; we check the match with your stack before a review starts.
- Time zonesAsia
§ 02Services
| ✓ | PR/MR code review | mid-level backend |
| — | Architecture review | Not offered by this expert |
| — | Architecture design | Not offered by this expert |
| — | Audit / due diligence | Not offered by this expert |
| — | Vibe-code rescue | Not offered by this expert |
| ✓ | Team mentoring | code-quality coaching for junior engineers |
§ 03Track record
Building and running backend services at big-tech scale
One of our engineers works as a mid-level backend engineer at a global e-commerce and cloud company. They build and run services held to that company's engineering bar for reliability and code quality. The work is internal, so no project details or numbers are shared.
§ 04What you can book
How we'd review a mid-level backend PR
A small team ships backend features without a second reviewer. This engineer would review each PR for correctness, readability, test coverage and failure handling.
Inline comments, each sorted as must-fix or suggestion.
Scalability check of a single service
A service works in testing but nobody has asked how it behaves at ten times the load. This engineer would look for N+1 queries, unbounded result sets, missing pagination, missing timeouts and blocking calls on hot paths.
A short list of risks, each with a suggested fix. Anything that changes the architecture goes to a senior lead.
Correctness review for retries and concurrency
An endpoint creates orders or records payments, and clients retry on timeouts. This engineer would check idempotency, race conditions, transaction boundaries and duplicate handling.
Review comments plus the test cases that would prove each fix.
Raising a junior team to a big-tech code-quality bar
A founder hired junior engineers and wants their code held to a higher standard without heavy process. This engineer would review a sample of their PRs and write a short code-quality guide drawn from patterns that keep repeating. The engineer would then keep reviewing against that guide.
The guide plus a few weeks of coached reviews.
Interview-grade review of a hiring take-home
A startup without senior backend people needs to judge candidates' take-home code. This engineer would review submissions for problem decomposition, correctness, complexity and tests, the way a big-tech interviewer would.
A structured written assessment per candidate. The hiring decision stays with the founder.
Hot-path complexity review
A feature got slow as data grew. This engineer would review the code on the hot path for algorithmic complexity, data-structure choice and needless repeated work.
Annotated findings with simpler alternatives.
API contract and error-handling review
A team is publishing an API for its own frontend or for partners. This engineer would review naming, status codes, error payloads, validation and backward compatibility.
A review with a short list of contract fixes to make before clients depend on the API.
Money-handling check in backend code
A product starts handling prices, balances or fees. This engineer has formal finance training as well as backend experience. They would check for floating-point money, inconsistent rounding, missing currency fields and totals that can drift.
Review comments with the safer pattern for each case.
Production-readiness check before launch
A founder is about to launch a backend service. This engineer would check logging, basic metrics, health checks, timeouts and what happens when a dependency is down.
A checklist of gaps, ordered by risk.