All posts

Careers · Getting hired · Portfolio

Portfolios that get interviews are built backwards from the reader.

Most portfolio advice lists project ideas. That’s the wrong starting point. The right one is the person skimming forty portfolios on a Tuesday afternoon: what do they click, what convinces them, what makes them close the tab?This guide is built from that reader’s eye view - the evidence hierarchy, the project shapes that clear it in 2026, and the presentation layer that decides whether your work gets seen at all.

Deric YeeDeric Yee Updated 25 August 2026 10 min read
A laptop showing real code - the raw material of a working portfolio

The evidence hierarchy: what a project is worth

Every project claims something about you, and claims come in grades. At the bottom: “I can follow instructions” - the tutorial clone, the course assignment, the template deploy. Necessary steps in learning; near-zero evidence in hiring, because they demonstrate reproduction, not capability, and hiring managers have seen the same Netflix clone four hundred times. In the middle: “I can build” - an original application that works, is deployed, and shows real technical range (auth, data, state, deployment). This is where interviews start happening. At the top: “I can solve real problems for real people” - the same application, but with a named user whose problem it demonstrably solves: the tuition centre actually books through it, the family business actually tracks inventory in it. This grade is rare enough in junior portfolios that it functions as a cheat code, and it is entirely manufacturable - the process is half of the no-experience playbook.

Notice what the hierarchy implies about effort allocation: upgrading one project a grade beats adding three at the same grade. The month spent finding a real user for your booking app moves you further than the month spent building two more apps nobody uses. This is the exact inversion of how most beginners work - accumulating breadth because each new project feels like progress - and it is why the standard advice to “build lots of projects” produces portfolios that get skipped.

The three-project portfolio for 2026

Project one: the anchor. A substantial full application - accounts, persistent data, a workflow someone completes - deployed at a live URL, ideally with that named real user. This is the project your interview deep-dive will orbit, so build it expecting interrogation: every technical choice is a future interview answer. Project two: the AI-era piece.Something where AI is the engine, not just the builder - a document-answering tool for a niche you know, an agent that drafts quotations from enquiries, an automation that replaces a manual workflow you’ve personally done. This signals you build the way 2026 teams build, and it feeds directly into the AI-collaboration probes that interviews now run (see what interviews test now). Project three: the consistency exhibit. The project that shows time - months of commits, versioned improvements, issues opened and closed. It answers the reliability question that employment history normally answers, which makes it the quiet substitute for the experience you don’t have.

The presentation layer: where good work goes to die

Hiring managers report the same failure constantly: candidates with genuinely decent work packaged so badly it never gets seen. The gates, in the order your reader hits them. The live link works, fast: a cold-starting free-tier app that takes forty seconds to wake is a closed tab - keep the anchor project on infrastructure that responds, and check it the morning you apply. The README sells in ten seconds:what it does, who it’s for, a screenshot, the stack, and - the 2026 addition - your AI-collaboration note: what you directed, what you rejected, what you caught. That paragraph converts the inevitable “how much of this is AI?” suspicion into your best evidence. The code is legible: consistent naming, sensible structure, no commented-out graveyards - reviewers skim for care, not brilliance. And the commit history tells the truth: months of real iteration reads as reliability; one massive “initial commit” the week before applications reads exactly how it sounds. None of this is glamorous; all of it decides whether the work you did gets evaluated at all.

Building it: the honest path

A portfolio of this grade is the output of the same 400–600 focused hours that produce job-readiness - they are not separate workstreams. The sequencing that works: fundamentals through small builds first (understand what you ship, or the deep-dive round will find out), then the anchor project as your capstone, then the real-user upgrade and the AI-era piece as you approach applications. Structured programmes compress this mainly by forcing completion and adding review - our mentors red-line student projects precisely because unreviewed work cements the habits that portfolios then expose - and several of our graduates’ hired-on portfolios were built exactly this way, into roles in the RM 6,000–9,000/month AI-capable band documented in the hiring report. The first six portfolio candidates - real projects, built and reviewed - are free: the free trial, one signup, no card. Start the anchor tonight; the Tuesday-afternoon reader is already skimming.

FAQ

  • How many projects should be in a developer portfolio?

    Two to three deep ones - full stop. The instinct to accumulate ten projects works against you: hiring managers spend a few minutes per portfolio, and ten shallow entries read as tutorial-following while three substantial ones read as capability. The working formula for 2026: one substantial full application (users, accounts, real data, deployed), one AI-era piece (an automation or AI-powered tool showing you work the way modern teams do), and one project with visible history (months of commits, iterations, fixes - the reliability signal). Every project beyond three should replace a weaker one, not join it. Depth wins because interviews are conversations about decisions, and only deep projects contain any.

  • What projects should I avoid putting in my portfolio?

    The skip-list that hiring managers report seeing constantly: tutorial clones (the Netflix/Airbnb/todo apps everyone builds from the same videos - they signal course-following, not capability, and interviewers recognise them on sight); template deployments with cosmetic changes; anything that is not deployed (a repo without a live URL asks a busy person to compile your work to evaluate it - they won’t); anything you cannot defend line by line (AI-generated showpieces collapse in the deep-dive round and take your credibility with them); and group projects where your contribution is unclear. One caveat: a tutorial project EXTENDED well beyond the tutorial - new features, real users, redesigned architecture - stops being a clone and starts being evidence.

  • Do employers actually look at portfolios?

    Yes - with a specific reading pattern worth designing for. First pass (30-60 seconds): they click your top project’s live link; if it loads fast, works, and looks intentional, you survive the pass. Second pass (2-5 minutes, often pre-interview): they skim the README for what it does and why, glance at the code for structure and naming, and check commit history for consistency and honesty. Third pass: the interview deep-dive, where the portfolio becomes the agenda. Two implications: the live URL and README carry disproportionate weight (they gate everything else), and commit history is quietly load-bearing - a project "completed" in one giant commit the night before applications reads exactly how it sounds.

  • Should I mention that I used AI to build my portfolio projects?

    Yes - proactively and precisely, because the alternative interpretations are both worse. Claiming zero AI use reads as either dishonest or outdated (employers know how 2026 software gets built, and they pay premiums for people fluent in it). Hiding it and getting probed - "walk me through why you wrote this function this way" - is the classic vibe-coder collapse. The winning posture is a precise collaboration account, ideally in the README: what you directed AI to draft, what you rejected and why, the bug it introduced that you caught. That story converts AI use from a suspicion into your strongest evidence: it demonstrates exactly the direct-and-judge capability the RM 6,000-9,000 AI-capable band is paid for.

  • What makes a portfolio project impressive to Malaysian employers specifically?

    Local specificity is quietly powerful. A booking system for an actual tuition centre in Klang, an inventory tool for a family kedai, an SST-aware invoicing helper, a duit-raya splitter that went mildly viral in your circle - these outperform generic global clones for three reasons: they prove you can find and solve REAL problems (the rarest junior skill), they are memorable in a stack of lookalike portfolios, and they demonstrate initiative no tutorial can assign. Malaysian hiring managers also weight the practical over the flashy: a boring tool with real users beats a beautiful demo with none. If your network genuinely offers no real users, a well-scoped niche community product (an industry job board, a club management tool) is the next best shape.

Three projects. One reader. Build backwards.
The anchor project starts free.

Six real, reviewed projects in six days - the first entries in the portfolio this guide describes, with a live instructor session included. One signup, no card.