We spend a lot of time on the other side of this conversation, reading portfolios to decide who gets an interview, and the pattern is remarkably consistent: candidates over-invest in breadth (another model, another framework, another tutorial clone) and under-invest in the two or three things that actually move a hiring manager. Here's what to put in your portfolio if the goal is getting hired, not collecting GitHub stars.
Depth over breadth: what hiring managers actually spend time on
A resume that lists ten projects, each a variation on a tutorial (a chatbot, a RAG demo, a classifier), signals that you can follow instructions, which is real but limited information. A resume with two projects, one of them taken all the way to something that ran for real users and had to survive real input, signals something much rarer: that you can own a system through the messy part, not just the build. When we screen candidates, we spend the vast majority of our attention on your best project, not your list of technologies. Cut the shallow ones if it makes room to go deeper on the good one.
What counts as evidence of production experience
You don't need a company-scale deployment to show this. You need evidence that the project met reality: real input it wasn't designed for, a real user who used it more than once, a moment where it was wrong and you noticed.
- It ran somewhere other than your own machine, even a small deployed app a handful of people actually use.
- You measured whether it worked, a test set, a scoring method, a before/after comparison, not just 'it seemed to work in testing.'
- You can describe a specific moment it failed, what the failure looked like, and what you changed because of it.
- You made at least one deliberate tradeoff (a smaller model for latency, a simpler retrieval approach for cost) and can explain why.
Document your failures, not just your wins
This is the single most counterintuitive and highest-leverage thing you can do to your portfolio: write down what broke. A project page that says 'this worked great' tells a hiring manager nothing they can verify. A project page that says 'this failed on inputs longer than X, here's what I changed, here's the before/after on my eval set' tells them you understand the system deeply enough to know its edges, which is exactly what the job actually requires. Candidates instinctively hide failures because it feels like admitting weakness; on the hiring side, it reads as the opposite.
How to present your real work when it's confidential
Most experienced candidates have their best, most production-hardened project locked behind an employer's NDA, and that's completely normal, not a gap you need to apologize for. The fix isn't inventing a public substitute, it's presenting the confidential project verbally with the same depth you'd want from a code review: what the system did, what you measured, what broke, what you'd do differently now. Interviewers who know what they're looking for will get more signal from a well-explained confidential project than from a shallow public one, depth of explanation is the actual signal, not a link they can click.
- Describe the problem and constraints generally without naming the employer or exposing proprietary detail.
- Be specific about your own decisions and reasoning, not just what the team built collectively.
- Have a concrete failure story ready for this project too. 'It worked perfectly' about something real is rarely believed and rarely true.
What to leave out
Long lists of frameworks and model names you've merely used once read as noise, not signal, and can actually work against you if they crowd out the two things that matter. Skip model-name-dropping as a substitute for explanation; 'I used GPT-4 and a vector database' says nothing an interviewer can evaluate, while 'I chose a smaller model here because latency mattered more than marginal accuracy on this task, and here's the eval that confirmed it was fine' says everything. Cut anything you can't speak to in depth for ten minutes without notes.
Getting your portfolio in front of the right eyes
A strong portfolio still needs to reach someone who evaluates it the way this guide describes, and not every application does. Referrals help. So does a curated network built around actual evaluation rather than keyword matching: Aiporate's talent network reviews AI engineers on exactly this kind of signal, real projects, real production experience, and matches them with companies already looking to hire for it, rather than leaving a good portfolio to sit in a general applicant pool.
