Skip to main content
Alvin QuachFull Stack Developer
HomeProjectsExperienceBlog
HomeProjectsExperienceBlog
alvinquach

Full Stack Developer building systems that respect complexity.

Open to opportunities

AQ

Projects

  • All Projects
  • Hoparc Physical Therapy
  • OpportunIQ
  • Hoop Almanac
  • SculptQL

Knowledge

  • Blog
  • Experience
  • Interview Prep

Connect

  • Contact
  • LinkedIn
  • GitHub
  • X

Resources

  • Resume
© 2026All rights reserved.
Back to Projects

Kevin Lam Portfolio

Personal brand website for a B2B sales executive transitioning into tech sales

Lead Developer & Mentor
Team of 1
3 weeks
Next.js
TypeScript
TailwindCSS
Tina CMS
Live Site

The Problem

Situation

Kevin Lam, a B2B sales executive with 8+ years of experience, wanted to transition into tech sales and needed a professional online presence to stand out to recruiters. He had an existing WordPress site that was slow and difficult to update, plus an MIS background from San Jose State University. This became a dual opportunity: migrate his portfolio from WordPress to a modern stack while pair programming with him through every feature—giving him both a polished product and renewed technical confidence to discuss in interviews.

My Goal

Migrate Kevin's portfolio from WordPress to Next.js, expanding it with detailed case studies, analytics integration, and a deployment strategy he could maintain. Use pair programming to rebuild his technical fundamentals while integrating Sanity CMS with GROQ—chosen over Tina CMS because of its superior cross-references, reverse lookups, and growth potential. GROQ's SQL-like syntax made it approachable for Kevin given his MIS database coursework, and Sanity's intuitive Studio interface meant he could manage content independently without deep technical knowledge.

My Approach

1

Conducted discovery sessions to understand Kevin's career goals, target audience (tech recruiters), and current site pain points with WordPress

2

Migrated existing content from WordPress, restructuring it for better storytelling and SEO

3

Pair programmed project initialization with Next.js and TypeScript, walking through ecosystem changes since his college days

4

Designed personal brand visual identity collaboratively, teaching component-based thinking in React

5

Built responsive layouts with Tailwind CSS, connecting utility-first CSS to his HTML/CSS background

6

Evaluated Tina CMS vs Sanity CMS—chose Sanity for cross-references, reverse lookups, better account management, and growth potential despite Tina's visual editing appeal

7

Integrated Sanity CMS with GROQ queries, teaching Kevin how GROQ's syntax resembles SQL from his database coursework

8

Implemented PostHog for user behavior analytics and Google Analytics for traffic insights

9

Created compelling case studies showcasing his sales achievements with metrics-driven storytelling

10

Set up deployment pipeline on Vercel with preview environments, explaining CI/CD workflows

11

Configured custom domain, SSL, and performance monitoring

12

Built documentation so Kevin could continue maintaining and updating the site independently

13

Supported Kevin through consulting discovery calls and stakeholder negotiations for his sales work

The Outcome

Kevin received 3x more recruiter outreach within first month of launch

Site ranks on first page of Google for 'Kevin Lam sales' and related searches

Kevin regained confidence in technical discussions, able to speak credibly about web technologies in interviews

PageSpeed score of 98 demonstrates technical quality to recruiters viewing source

Kevin can now update content and make minor code changes independently

Project became a talking point in interviews, showcasing Kevin's initiative and technical aptitude

Project Roadmap

MVP, stretch goals, and future vision

Project Roadmap

Development phases and milestones

100%
1/1 complete
1

Portfolio Website

MVP

Personal portfolio website for Kevin Lam

Completed
Website Launch

Complete portfolio website with project showcases

Completed
In Progress
Planned

Interview Questions

Common questions about this project, answered in STAR format

Q1

Tell me about a time you helped someone learn a new skill.

leadership
SSituation
A junior developer on a previous project struggled with React hooks and state management. They kept creating bugs with stale closures and unnecessary re-renders, slowing down the team.
TTask
Help them understand React's mental model deeply enough to write clean, bug-free components without constant code review corrections.
AActions
  • →Identified their specific knowledge gaps through code review patterns—they understood class components but not functional component lifecycle
  • →Created a mini curriculum progressing from useState to useEffect to custom hooks
  • →Pair programmed on real features rather than toy examples, letting them drive while I asked guiding questions
  • →Drew diagrams showing how React's reconciliation works and when closures capture values
  • →Assigned progressively harder tasks with immediate feedback loops
  • →Documented common patterns in a team wiki so they could reference it later
RResult
Within three weeks, they were shipping features independently with minimal review feedback. Their code quality improved enough that they started catching similar issues in others' PRs. They later told me it was the first time someone explained 'why' instead of just 'what'.

Key Takeaway: Teaching technical concepts works best when you identify existing mental models and build bridges from there—this developer understood class lifecycles, so connecting hooks to that foundation accelerated learning dramatically.

Q2

Describe a project where the process was as important as the outcome.

behavioral
SSituation
A startup I consulted for needed their MVP shipped fast, but the two junior devs on the team would need to maintain it after I left. Shipping quickly meant nothing if they couldn't iterate on it.
TTask
Deliver a working product while ensuring the team could understand, debug, and extend the codebase independently after my engagement ended.
AActions
  • →Chose technologies they had some familiarity with rather than optimal-but-unfamiliar alternatives
  • →Wrote extensive inline comments explaining non-obvious decisions
  • →Created architecture decision records (ADRs) documenting why we chose certain patterns
  • →Conducted code walkthroughs for every major feature before merging
  • →Built debugging guides showing how to trace issues through the system
  • →Intentionally left some 'stretch tasks' undone so they could practice extending the codebase while I was still available for questions
RResult
The MVP launched on time. More importantly, six months later the team had added three major features without external help. The CTO mentioned that previous consultants' code had been 'black boxes' they eventually rewrote, but ours they actually built on.

Key Takeaway: A codebase that the team can't maintain is technical debt from day one. The 'right' architecture is the one your team can actually work with—not the theoretically optimal one.

Q3

How do you adapt your communication style for different audiences?

behavioral
SSituation
During a sprint planning meeting, a product manager, a designer, and two backend engineers were debating a feature's scope. Each group was talking past the others—PM focused on user metrics, designer on UX flows, engineers on data model constraints.
TTask
Bridge the communication gap so the team could align on a realistic scope that satisfied all stakeholders' core concerns.
AActions
  • →Listened first to understand each group's actual constraints and priorities, not just their stated positions
  • →Reframed the PM's metrics goals in terms of specific user behaviors the engineers could reason about
  • →Translated the designer's UX concerns into data requirements that revealed the engineering complexity
  • →Created a simple diagram showing how user actions mapped to backend operations, making tradeoffs visible
  • →Proposed a phased approach that delivered the PM's key metric while deferring designer polish and engineering complexity
  • →Followed up individually to ensure each stakeholder felt heard and understood the rationale
RResult
The team aligned on a scope in that meeting instead of the usual 2-3 follow-up discussions. The PM later asked me to facilitate other cross-functional discussions because 'you actually make people understand each other.'

Key Takeaway: Communication isn't about dumbing things down—it's about finding the translation layer between different mental models. Engineers think in systems, designers in flows, PMs in metrics. Good facilitation makes those perspectives compatible.

Technical Decisions

Quick answers to 'Why did you choose X?' questions

Q1Why teach Next.js/TypeScript to someone returning to coding rather than simpler tools?

Kevin wanted to speak credibly about technology in tech sales interviews. Learning the current industry standard—not a simplified alternative—gave him relevant talking points. Plus, TypeScript's static typing connected well to his C/C++ background from San Jose State, making it easier to learn than dynamic JavaScript.

Q2Why choose Sanity over Tina CMS when Tina has visual editing?

We evaluated both for Kevin's specific needs. Tina CMS has excellent visual editing and Git-backed content, but Sanity won on: (1) Cross-references—Kevin's case studies needed to link to skills, companies, and testimonials; (2) Reverse lookups—showing which case studies use which skills; (3) Better account management for a single-user portfolio; (4) Growth potential if Kevin's site expands; (5) Metrics dashboards in Sanity Studio. Tina's visual editing was appealing, but Sanity's structured content model better served Kevin's interconnected portfolio content.

Q3Why teach Kevin GROQ instead of using GraphQL like other projects?

GROQ's syntax resembles SQL, which Kevin learned in his MIS database courses at San Jose State. Queries like *[_type == 'caseStudy'] felt familiar compared to his old SELECT * FROM case_studies memories. For a personal portfolio with a non-developer maintaining it, teaching something that connected to his existing mental model made more sense than GraphQL—which I'd use for a developer like Sean who would benefit from the industry-standard transferable skill.

Q4How did you structure pair programming sessions for someone rebuilding fundamentals?

Used driver-navigator with Kevin driving most of the time. Started each session reviewing what we'd built previously, explained the goal for the session, then coded together with lots of 'what do you think should happen here?' questions. Ended with Kevin summarizing key concepts. This kept him active rather than passive.

Q5How did you handle the disconnect between Kevin's MIS coursework and modern practices?

Created explicit bridges to his San Jose State background: 'Remember classes in C++? Components are similar—encapsulated, reusable units.' Avoided jargon when possible, and when I used it, immediately explained it. Focused on concepts over syntax—once Kevin understood the 'why', the 'how' followed more easily.

Q6How did you ensure Kevin could maintain the site after the project ended?

Built progressively simpler documentation as we went—not technical docs, but 'how to do X' guides written for Kevin specifically. Had him make real updates during our sessions so the process became familiar. Sanity Studio's intuitive interface made this easier than expected—Kevin could navigate the content structure visually and GROQ queries he'd written made sense to him because of the SQL parallels. Kept the codebase simple enough that Kevin could read and understand it.

Key Trade-offs

Every decision has costs — here's how I thought through them

Teach modern stack (Next.js/TypeScript) vs. simpler tools like WordPress

Gained

  • +Kevin learned industry-relevant technologies he can discuss in interviews
  • +Site performs excellently with PageSpeed 98
  • +Kevin understands modern development workflows and tooling

Gave Up

  • −Longer learning curve than a drag-and-drop builder
  • −Project took more time than a WordPress site would have
  • −Kevin needs to remember more concepts for future maintenance

Why Worth It

Kevin's goal wasn't just a website—it was to re-engage with technology. Learning current best practices made his technical background a talking point rather than a footnote.

Pair program on everything vs. build it for Kevin and explain afterward

Gained

  • +Kevin genuinely understands how his site works
  • +He can make changes and troubleshoot independently
  • +Rebuilt his coding confidence through hands-on practice

Gave Up

  • −Project took 3-4x longer than if I'd built it solo
  • −Some features took multiple attempts as Kevin learned
  • −More coordination needed to align our schedules for pair sessions

Why Worth It

The website was a vehicle for learning, not just a deliverable. Kevin's renewed technical confidence is more valuable than a faster launch.

Custom design vs. using a template or theme

Gained

  • +Kevin learned design principles and component architecture
  • +Site is unique and perfectly tailored to his personal brand
  • +Understanding the structure helps Kevin maintain it

Gave Up

  • −Slower than dropping in a template
  • −More design decisions to make together
  • −Required building components from scratch

Why Worth It

Building from scratch taught Kevin how pieces fit together. Templates hide complexity; we wanted to understand it.

Sanity CMS with GROQ vs. Tina CMS with visual editing

Gained

  • +Cross-references between case studies, skills, and testimonials
  • +Reverse lookups to show skill usage across projects
  • +GROQ's SQL-like syntax connected to Kevin's MIS database coursework
  • +Better growth potential if portfolio expands
  • +Sanity Studio metrics and account management

Gave Up

  • −No inline visual editing like Tina offers
  • −GROQ is niche compared to industry-standard GraphQL
  • −Slightly more complex content modeling setup

Why Worth It

For a portfolio with interconnected content (case studies linking to skills, companies, testimonials), Sanity's relational model was worth the tradeoff. Kevin's SQL background made GROQ feel familiar, and teaching him something niche was acceptable since he's not pursuing a dev career—he just needs to maintain his own site.

Challenges & Solutions

The hardest problems I solved on this project

1Kevin had MIS background from San Jose State but years of gap—modern JavaScript ecosystem was overwhelming

Approach

Started with concepts he knew from his MIS coursework (HTML/CSS, basic programming logic) and built bridges to modern equivalents

Solution

Drew parallels: 'TypeScript interfaces are like the structs you learned in C', 'npm is like package managers you might remember'. Pair programmed everything so he saw concepts in context rather than abstract tutorials

Lesson: Rusty developers aren't beginners—they have mental models to build on. Honor their existing knowledge while updating it.

2No existing brand guidelines or professional photos to work with

Approach

Conducted a mini brand workshop, teaching Kevin about personal branding for tech while gathering design direction

Solution

Created a simple but professional design system together. Used high-quality stock imagery strategically while planning for future professional photos

Lesson: Constraints drive creativity. Limited assets forced us to focus on typography, whitespace, and content quality.

3Balancing Kevin's learning pace with getting a polished product launched

Approach

Identified which parts were best for learning vs. where I should lead to maintain quality and momentum

Solution

Kevin drove on components and content areas where mistakes were recoverable; I led on architecture and critical path items while explaining decisions

Lesson: Mentorship on real projects requires intentional task allocation—not everything is equally suited for learning.

4Presenting Kevin's sales metrics impressively without coming across as boastful

Approach

Drew on Kevin's sales training—he understood the difference between bragging and demonstrating value

Solution

Framed achievements in terms of business impact with specific numbers, letting metrics speak for themselves. Used testimonials to add third-party validation

Lesson: Sales professionals often have better instincts about self-presentation than developers—leverage their expertise.

What I Learned

  • →Developers returning to coding after years away have muscle memory that returns quickly once you find the right anchors
  • →Connecting new concepts to prior knowledge accelerates learning—Kevin's C++ background made TypeScript typing intuitive
  • →Non-technical professionals bring valuable perspectives—Kevin's sales mindset improved how we presented achievements
  • →Pair programming builds both technical skills and teaching abilities on both sides
  • →Migration projects are great learning opportunities because you can compare the old approach to the new
  • →Teaching someone their own portfolio creates personal investment that drives faster learning
  • →Analytics setup is a great teaching moment—it connects code to real business outcomes Kevin understands from sales

Want to discuss this project?

Get in TouchView More Projects