I spent March rebuilding a fintech API that a "senior NestJS developer" had shipped two months earlier. The code worked—until you needed to add a second microservice, handle file uploads over 10MB, or debug why every request was hitting the database twice. The CTO who hired him had asked about decorators and dependency injection. He hadn't asked about module boundaries or TypeORM query performance.
That project cost them $18k to fix. It's not an outlier. Here's what I now tell founders and technical leads before they hire a NestJS consultant—whether that's me or someone else.
Ask About Module Design, Not Just Decorators
Most NestJS interviews focus on framework mechanics: "Explain @Injectable()." "What's the difference between a guard and an interceptor?" A mid-level developer who's read the docs can answer these. What separates a senior from someone who's memorised the API?
Module boundaries under pressure. I ask candidates: "You're building a multi-tenant SaaS. Where does tenant-scoping logic live—in a guard, a custom decorator, or request-scoped providers?" There's no single right answer, but the reasoning matters. I've seen codebases where every controller imported a TenantService directly, making it impossible to test routes in isolation or swap tenancy strategies later.
In one e-commerce rebuild I did last year, the previous team had put all business logic inside controllers—2,000-line files with database calls, Stripe webhooks, and email templates mixed together. Refactoring that into domain services took three weeks because nothing had clear ownership. A good NestJS developer knows that @Controller is for HTTP, not for business rules.
TypeORM Isn't Magic: Validate Query Patterns
NestJS defaults to TypeORM, and that's where I see the most production fires. The framework makes it trivial to write code that works in development (10 users, local Postgres) and falls apart under load (1,000 concurrent requests, managed database with connection limits).
What to ask:
- "How do you prevent N+1 queries in a relationship-heavy schema?"
- "When would you use
QueryBuilderinstead of the repository pattern?" - "How do you handle database migrations in a zero-downtime deployment?"
I inherited a SaaS dashboard in January where every page load triggered 40+ SELECT queries because the developer had used @ManyToOne eager loading everywhere. The fix was a 12-line leftJoinAndSelect chain, but it required understanding what TypeORM was actually doing. If a candidate can't explain query execution, they'll ship slow endpoints and blame Postgres.
One red flag: if they say "I just use findOne() and let the ORM handle it," they haven't worked on anything past the tutorial phase.
Exception Filters Are Where Experience Shows
Anyone can throw BadRequestException. Senior developers know how to centralise error handling so your logs are parseable and your API clients get consistent responses.
I use this question: "A Stripe webhook fails because the request signature is invalid. Where does that error surface, and how does your monitoring catch it?" The answer should involve custom exception filters, structured logging (not console.log), and probably a dead-letter queue or alert webhook.
In a recent healthcare API project, the previous developer had scattered try/catch blocks across 30 endpoints, each returning different error shapes. Frontend developers were doing string matching on error messages. We replaced it with a global exception filter and three custom exceptions (BusinessRuleError, IntegrationError, ValidationError). Bug triage time dropped by half.
Configuration and Secrets: The Unglamorous Essentials
This is boring, and that's why it's revealing. Ask: "How do you manage environment-specific config and API keys across local, staging, and production?"
Good answer: @nestjs/config with schema validation (using Joi or Zod), secrets in environment variables or a vault, and a startup check that kills the process if required vars are missing.
Bad answer: Hardcoded strings, .env files committed to Git, or "we just change it manually before deploy."
I once took over a project where Stripe keys were in a constants.ts file. The previous developer had used the test key in production for two weeks because "the live key wasn't working." That's not a NestJS skill gap—it's a production maturity gap, and it's a filter you need.
Testing Strategy Reveals Real-World Constraints
Every developer says they write tests. What kind of tests? I care about two things:
- Do they test business logic in isolation? Services should have unit tests that don't boot the framework. If every test imports
Test.createTestingModule(), they're testing integration points, not logic. - Do they know when NOT to test? Over-mocking is as bad as under-testing. If you're mocking six layers to test a repository method, you're testing TypeScript's type system, not your code.
I ask: "Show me how you'd test a service that calls an external API, stores the result, and sends a notification." If they immediately say "mock everything," they've never maintained a test suite that breaks on every refactor. A better answer involves testing the core transform logic as a pure function and writing a smoke test for the integrated flow.
Decision Table: When to Hire a NestJS Specialist
| Your situation | Hire a generalist Node.js dev | Hire a NestJS specialist |
|---|---|---|
| Greenfield MVP, <3 months | ✓ (framework overhead might slow you down) | Use if you know you'll scale to microservices |
| Existing NestJS codebase | Only if it's small and well-structured | ✓ (refactoring poor NestJS is harder than starting fresh) |
| Multi-tenant SaaS, RBAC, audit logs | Maybe—depends on their architecture experience | ✓ (NestJS's DI and metadata make this much cleaner) |
| Tight budget, fixed scope | ✓ (less abstraction = faster for small teams) | ✓ if you're hiring for ongoing work, not a one-off |
| Microservices or event-driven | ✗ (you need distributed systems experience first) | ✓ IF they have Kafka/RabbitMQ/Redis production experience |
The Questions I Actually Ask
Here's my standard 20-minute technical screen for NestJS roles:
- "Walk me through how a request flows from route to database and back. Where would you add caching?"
- "You have a
UserServicethat needsEmailServiceandPaymentService. How do you structure that without circular dependencies?" - "Your API is getting 500 req/sec and Postgres connections are maxing out. What's your first move?"
- "How do you handle file uploads in NestJS, and what size limit makes you switch strategies?"
- "Explain a time you had to debug a memory leak in production. What did you use?"
If they stumble on #3 (connection pooling, read replicas, Redis) or #5 (heap snapshots, clinic.js, APM tools), they haven't run production systems at scale. That's fine for some roles—just price accordingly.
What This Costs You When You Get It Wrong
That fintech API I mentioned at the start? Here's the damage:
- 6 weeks of rebuild time at $140/hour = $33,600
- Original developer cost: $18,000
- Opportunity cost of delayed feature launch: unquantifiable, but the CEO missed a Q2 partnership deadline
The expensive part wasn't the bad code—it was the technical debt that looked fine in demos but couldn't scale past beta. If you're hiring a freelance full-stack developer or NestJS consultant, the goal isn't to find the cheapest rate. It's to find someone who's already made the mistakes so you don't have to.
If you're evaluating developers right now and want a second pair of eyes on architecture, API design, or just someone to translate technical answers into business risk—I do fractional CTO consulting and code audits. Happy to jump on a call and walk through your specific stack.
