Why Engineers Need a Failure Portfolio, Not Just a Project Portfolio

Most engineering portfolios are collections of endings. The board that finally booted. The driver that finally probed cleanly. The image that finally built. Everything that happened before the ending — the wrong assumption, the misread log, the fix that changed nothing, the evening spent testing the wrong layer — is edited out, because it looks untidy.

Yet that edited-out part is where the engineering happened. A project portfolio answers one question: what was built? A failure portfolio answers a harder and more valuable one: how does this engineer behave when the system does not match the theory?

The finished artefact only proves that something eventually worked. The investigation behind it is what proves there is an engineer present.

To be clear, this is a complement, not a replacement. A project portfolio still proves you can deliver a finished thing, and for complex work — a real board bring-up, a driver accepted upstream — it remains meaningful. The problem is what has happened to everything below that level.

The market that sells the appearance of experience

The shortcut market is worth describing plainly, because many students meet it before they meet a real employer. Its products are engineered for one purpose: to pass resume screeners and hurried first-round interviews.

An entire industry now exists to dress education as experience. These services do not sell education. They sell the appearance of experience.

The catalogue is familiar to anyone who has reviewed candidates in India: ready-made final-year projects sold with source code, documentation and a recorded demonstration, where the buyer contributes little more than their name; forked GitHub repositories with cosmetic edits, presented as personal work; resume keyword packages and rehearsed interview scripts optimised for screening algorithms; and, most recently, AI-written accounts of debugging work the buyer never performed, generated to be presented as personal experience.

Most students who buy these are driven less by dishonesty than by pressure. They are responding to a system that has often rewarded the look of a finished project over the slower work of learning. The problem is not their intent. The problem is what this evidence does to their next five years.

What cosmetic evidence eventually costs

The cost of faked depth is not one dramatic exposure. It is a series of gates, and each one is harder to pass than the last.

• The technical interview. A script survives a phone screen. It does not survive the second follow-up question. The moment an interviewer asks why this approach and not another, or what happens when the input grows a hundred times, the script ends and the silence is informative.
• Probation. The first real, unscripted bug arrives within weeks of joining. An engineer whose portfolio was purchased has never actually moved from symptom to cause, and colleagues notice the gap between the resume and the person very quickly. Trust, once spent there, is expensive to rebuild.
• Layoff selection. When teams shrink, managers keep the people who can be handed an ambiguous problem. An engineer who needs every task pre-defined is a known quantity by then — in the wrong direction.
• The promotion ceiling. Senior roles are defined almost entirely by the ability to resolve problems nobody has framed yet. That ability is built through years of real investigations. Skip them, and the ceiling arrives regardless of intelligence — a result of missing practice, not missing talent.

AI has made faking the application easier, and faking the job harder.

This is why the arithmetic keeps getting worse. When routine output is generated in seconds, the part of the role that remains — diagnosis, judgement, verification — is precisely the part cosmetic preparation never built. Careers assembled from surface evidence are concentrating themselves in the one segment of work that is disappearing.

The signal that is hard to counterfeit

This is the context in which the failure portfolio matters. A demo shows an output; an investigation record shows a sequence — what was believed, what was measured, what was revised, what was abandoned. Sequence is difficult to fabricate convincingly, because a fabricated account tends to describe a simple, linear progression from problem to solution, and real investigations almost never proceed that way. A disappearing symptom is not the same as a solved cause, and a written investigation shows whether the engineer knows the difference.

An honest concession is needed here: AI can write a plausible account of an investigation that never took place, and it will be asked to. What it cannot generate is the surrounding evidence that a real investigation leaves behind — the commit from six months ago that broke the build and the commit that repaired it, the dated oscilloscope capture, the logic analyser trace, the notes with two crossed-out hypotheses. And it cannot sit in the interview and re-navigate that evidence live.

The portfolio earns the conversation. The ability to defend it earns the job.

The same record serves three readers. A hiring manager can evaluate maturity from the quality of the investigation rather than from the polish of the outcome. A mentor can see where the reasoning went wrong — the premature conclusion, the missing measurement, the untested assumption — instead of only seeing whether the final output exists. And you learn faster yourself, because a written record sharpens recall and makes it harder to repeat the same weak habit twice.

What a failure portfolio is, and how to build one

The name needs a caution. A failure portfolio is not a celebration of mistakes, and it is not a confession. It is a structured record of engineering investigations. The point is not to document embarrassment. The point is to document reasoning.

A useful entry is one page, written within a day of finishing the investigation, while you still remember the details clearly:

Project:
Goal:
Observed failure:            (the observation, not your theory about it)
What was assumed at first:
What evidence changed the direction:
What did not work:
What fixed it:
How the fix was verified:    (the cause confirmed, not just the symptom gone)
What will be done differently next time:

Attach small artefacts where they help: a dmesg or boot log excerpt, a serial console capture, a before/after configuration diff, reproduction steps, a small sketch of the architecture. A clear paragraph on the lesson is more useful than a set of screenshots — but the dated artefacts matter, because they are the part no generator can backfill. Keep entries short and factual. The goal is not drama; the goal is clarity. A folder in a repository, a personal blog, or private notes all work: public entries double as hiring evidence, and private ones still improve your engineering.

What this looks like in embedded and Linux work

The idea becomes concrete with real categories of failure. These are the kinds of entries that carry weight in this domain:

• A board that does not boot. “Board does not boot” is too vague to be evidence of anything. A strong entry reads: serial console silent after the SPL handoff; the regulator enable sequence was suspected first and looked correct; a logic analyser capture showed the reset line released milliseconds earlier than the peripheral’s datasheet required; the fix delayed reset deassertion and revised the device tree init order.
• A driver that worked until it did not. The driver passed every happy-path test and failed under concurrent access. The valuable part of the entry is not the final locking change; it is the path to it — what evidence suggested a race, what test finally reproduced it, and how the fix was verified under the same concurrent load.
• A build that passed locally and failed in CI. A Yocto image that builds on one machine and not another is a lesson in hidden assumptions. The entry that matters records which input was not pinned, how the difference was isolated, and what made the build deterministic.
• A software bug that was not software. A peripheral fault blamed on the driver that turned out to be power sequencing or reset timing. Entries like this show you can question your own strongest assumption: that the fault lives in the layer you know best.

The habits these entries demonstrate — reading the whole error message, testing one belief at a time, refusing to trust a fix you cannot explain — are the same ones we described in The Mindset Behind Hard Debugging. The portfolio is those habits made visible.

Will this not make me look careless?

The most common objection is fear: if I show my failures, I will look weak. This fear is understandable, but it is mistaken about what reviewers actually judge.

What looks weak to an experienced reviewer: a project the candidate cannot explain below the surface. A resume listing twelve tools with no account of a single tradeoff. A repository full of code with no trace of reasoning.

What looks strong: honest limits, stated plainly. A clear debugging path. Evidence of course correction. A second version that is better because the first version failed in an instructive way.

Immaturity hides failure. Maturity turns it into usable evidence.

None of this requires confidence to begin. It only requires the first entry.

For interviewers: how to test for real depth

Everything above also describes a problem for the people doing the hiring, so this section changes audience deliberately. If candidates can present purchased projects and generated experience, the interview has to test the one thing those cannot supply: the ability to move around inside their own claimed experience. Six probes do most of the work in a normal 45–60 minute round.

• Ask for the sequence, not the result. “What did you try first, and why was it wrong?” A real investigation contains wasted days and wrong certainty. A fabricated one is suspiciously efficient.
• Go two levels down on one detail. They added a mutex — why a mutex and not a spinlock in that context? What exactly was the critical section? A generated account has no second level.
• Ask for numbers and instruments. What was the measurement, taken with what — a logic analyser, ftrace, cyclictest, a stopwatch? Real accounts are quantitative and name their tools; cosmetic ones stay qualitative.
• Change one constraint. “Same fault, but you have no logic analyser — only the serial console. Now what?” Understanding transfers to the varied scenario; a script cannot.
• Ask them to teach it. “Explain to me, as if I have never used Yocto, why the build failed only in CI.” Simple explanation is a reliable proxy for real understanding; memorised jargon does not simplify.
• Ask what changed afterwards. “What did you put in place so this class of bug cannot recur?” This separates someone who once closed a ticket from an engineer who improved a system.

The tell-tale signs of a fabricated account are consistent: a linear narrative with no dead ends, no numbers, no named instruments, no time wasted anywhere, and a candidate who cannot vary the scenario without returning to the rehearsed path. None of these probes require hostility. Asked with genuine curiosity, they also give the honest candidate the best interview of their year — because for the first time, the messy real work is what scores.

What it becomes over time

Maintained over time, the portfolio does something a project list cannot: it shows change. Early entries will show scattered attempts, broad hypotheses, and verification that amounts to “it stopped happening”. Later entries will show narrower hypotheses, cleaner experiments, better instrumentation, and verification that confirms the root cause. That visible difference is concrete evidence of growth in judgement — something an interview can rarely assess directly.

It also changes what mentorship can do for you. A mentor who can only see your finished output can only comment on the output. A mentor who can see your recorded reasoning can point to the exact step where the investigation went wrong — a point we made from the other side in Don’t Pay for Information. Pay for Mentorship. This is also the reason TECH VEDA’s live, mentor-led training is built around working through problem scenarios rather than watching explanations: the mentor’s value is in catching the premature conclusion or the missing measurement while it is happening, and a written failure record extends that same feedback to your own work long after any course ends.

A finished project proves that something eventually worked. A failure portfolio proves that you can move from confusion to a verified answer — and can show how you did it, with evidence that carries its own dates. In a market where output is cheap and appearance is for sale, that is the evidence worth keeping.

Key takeaways

• A project portfolio answers “what was built”; a failure portfolio answers “how does this engineer behave when the system does not match the theory”. The second question is now the more valuable one, and the two are complements, not substitutes.
• A market of shortcut services sells the appearance of experience — ready-made projects, forked repositories, interview scripts, and now AI-written claims of debugging work that was never performed. The cost arrives in stages: the second follow-up question in an interview, the first unscripted bug on probation, layoff selection, and a permanent promotion ceiling.
• AI lowers the cost of faking an application while raising the cost of faking the job itself: as routine output becomes generated, diagnosis and verification become a larger share of what engineers are paid for.
• A genuine investigation record resists counterfeiting because it carries sequence and dated artefacts — commit history, instrument captures, crossed-out hypotheses — and because its owner can re-navigate it live under questioning.
• Interviewers can test for real depth with six probes: ask for the sequence, go two levels down, demand numbers and instruments, change one constraint, ask the candidate to teach it, and ask what changed afterwards.

Frequently asked questions

What is a failure portfolio?
A structured record of engineering investigations: for each significant failure, what the system was supposed to do, what was observed, what was suspected first, what evidence was gathered, what did not work, the root cause, the fix, how the fix was verified, and the lesson. It documents reasoning, not embarrassment.

How is a failure portfolio different from a project portfolio?
A project portfolio shows finished outputs — boards brought up, drivers written, images built — and still proves you can deliver. A failure portfolio shows the investigation behind such work: diagnosis, evidence handling and verification. The two together are far stronger than either alone.

Will documenting my failures make me look bad to employers?
Experienced reviewers judge the opposite way. A candidate who cannot explain their own project below the surface looks weak; a candidate who can show a clear debugging path, honest limits and verified fixes looks strong. Documented failure with reasoning is evidence of maturity.

Can AI not fake a failure portfolio too?
AI can generate a plausible account of an investigation, but not the evidence a real investigation leaves behind: dated commit history, instrument captures, and notes with abandoned hypotheses. And it cannot answer live follow-up questions about that evidence. The written record gets a candidate the conversation; defending it in person is the final test.

How can an interviewer detect fabricated debugging experience?
Ask for the sequence including dead ends, go two levels down on one detail, ask for numbers and instrument names, and change one constraint of the scenario. Fabricated accounts are linear, qualitative and rigid; real experience is specific, quantitative and adapts to the varied scenario.