For Technical Interviewers
Full-Stack Software Engineer
The best code is the code you never write. Every abstraction has a cost, every dependency is a liability, and every feature is a maintenance commitment. I build systems that are simple enough to understand, robust enough to trust, and flexible enough to evolve.
In a previous role, I inherited a codebase with 200k+ lines of legacy code. Instead of building on top, I mapped dependencies and systematically removed 40% of the code. The result: faster builds, fewer bugs, and a team that could actually move quickly again. The hardest part wasn't deleting — it was convincing everyone that less is more.
Building a simple API is harder than building a complex one. On one project, I spent two weeks refactoring a service from 15 endpoints down to 5, each composable and predictable. The team initially pushed back on the time investment. Six months later, onboarding time for new engineers dropped from weeks to days, and the service hadn't needed a single hotfix.
I treat CI/CD pipelines, dev environments, and deployment workflows as products with users (the team). On one team, I built a self-service deployment system that let engineers deploy to staging with a single command. Deployment frequency went from weekly to multiple times per day. When infrastructure is good, nobody notices — and that's the point.
I've seen too many codebases where README files lie and JSDoc comments refer to functions that were renamed months ago. TypeScript strict mode with well-designed types is documentation that the compiler enforces. On every project I lead, I push for strict TypeScript from day one. The upfront cost pays back within the first sprint.
Rather than building features speculatively, I advocate for the smallest possible version that validates assumptions. On one product, we scoped a planned 3-month feature down to a 2-week experiment. The experiment revealed that the original assumptions were wrong, saving months of wasted engineering time. Fast feedback loops beat perfect planning.
React with TypeScript is my primary stack. I prefer Next.js for its file-based routing, server components, and deployment story. For state, I reach for Zustand over Redux — less boilerplate, simpler mental model. Styling is Tailwind CSS — utility-first keeps components self-contained and refactoring safe. I avoid component libraries when possible; custom components are easier to maintain and evolve than fighting library opinions.
Node.js with TypeScript on the backend for full-stack type safety. PostgreSQL is my default database — it handles 90% of use cases without reaching for specialized stores. I design APIs around resources and invariants, not UI screens. Caching strategy is always intentional: Redis for hot paths, HTTP caching for static content, and database query optimization before adding cache layers.
Docker for reproducible environments, AWS for production workloads, Vercel for frontend deployments. I set up CI/CD pipelines early — automated testing, linting, and deployment on every push. Monitoring isn't an afterthought: structured logging, error tracking, and key metrics from day one. I believe in infrastructure as code and gitops workflows.
Biome over ESLint + Prettier — one tool, faster, opinionated. Bun as package manager for speed. Conventional commits for readable git history. Code reviews focused on architecture and correctness, not style (that's what formatters are for). I write tests for behavior, not implementation — integration tests over unit tests for most business logic.
I build side projects to explore ideas and sharpen craft. This site itself is an experiment — a portfolio that adapts to its audience rather than presenting a one-size-fits-all resume.
Open source contributions, personal tools, and technical writing are how I stay curious and give back to the community.