Show Me Your Portfolio

When I say “show me your portfolio,” I'm asking for enough detail to understand the work you did and discuss it with you. An AI engineering project becomes useful in that conversation when someone can follow the decisions you made, try the result, and see what happened when it failed. Knowing the tools is part of the preparation, but the project gives you a way to explain how you used them and where you still need help.

That can be difficult for enterprise engineers whose work belongs to their employer. You may have spent years building systems and still have no code you're allowed to publish. The portfolio doesn't need to contain that code. You can describe the part you owned and the constraints you worked under using details you're authorized to share. When even those details are private, a separate example can demonstrate the skill without reproducing the company's system.

Build that example with fictional data and material you have the right to use. Changing the names in a customer export doesn't make it suitable for publication, and the review needs to include screenshots, logs, fixtures, and repository history. GitHub's secret scanning documentation explains why removing a credential from the current file may leave it exposed in earlier commits. Someone should be able to inspect your judgment without gaining access to anyone else's information.

If you haven't shipped anything yet, a practice project is a reasonable place to start. You can demonstrate that you understand a problem well enough to build a small working version, then use a failure to improve it. Describe it as practice so the person reviewing it can assess what you've actually done. You can have a useful technical conversation about that work before you've had the opportunity to operate a customer's system.

Consider the support assistant in our public practice exercise. It finds two current policy documents that disagree, and an answer citing either document could look convincing. Before the assistant can answer responsibly, somebody needs to establish which document has authority. The assignment is to make that conflict visible and refer it to the person who can resolve it. A behavior specification and a test are enough to begin working through the problem, even before you build a chat interface.

To turn that exercise into a portfolio entry, include the request and the two fictional sources with an explanation of the expected behavior. A reviewer needs to know what result would cause you to reject the change and how to run the check themselves. Keep the version and command with the result, including any failed attempt you repaired. That lets another developer investigate the same problem instead of relying on a screenshot to decide whether your implementation works.

The explanation should connect the problem to what you changed in the repository, so a reader can follow your reasoning while trying the code. Be clear about your own contribution, including which decisions belonged to other people. If an AI assistant generated part of the implementation, explain what you inspected or changed and how you checked the result. That distinction matters because the discussion should help establish what you can explain and take responsibility for yourself.

The engineering choices give the reviewer more to discuss. Retrieval may recover relevant passages without establishing which one governs the decision. A model call introduces questions about malformed responses and timeouts, while a deterministic rule may be sufficient for part of the workflow. Explain the drawbacks of the approach you chose and why you decided against an alternative. This is where familiarity with a service starts to become a reasoned implementation decision.

An experienced developer can usually begin in the language and tools they already know, adding the AI behavior and checks around its operating limits. Someone without an IT background can contribute a problem brief or a set of fictional cases while studying programming foundations alongside the project. In either case, keep the scope small enough that you can explain the behavior. You need that understanding to decide what to change when the first version doesn't work.

Ask another person to use the package without your intervention and pay attention to where they stop. A setup step may depend on a file that only exists on your laptop, or a test may pass without making its result understandable. Keep their feedback with the first attempt, then revise the project and ask them to try again. The record shows how you responded when another person found a problem, which is useful evidence for a reviewer and a practical way to improve the project.

You can use the same approach to examine recovery. Make a source unavailable in the practice environment and work through how the system detects the failure, what it stops doing, and how you restore the previous working version. Rehearsing the procedure will tell you more than writing that rollback is supported. If the rehearsal fails, include the correction and the result of trying it again so the reviewer can see whether you resolved the problem.

There are limits to what this can establish. A synthetic exercise doesn't show that someone has handled customer access, live operations, or adoption, and it should be presented accordingly. A reviewer can still learn something by changing the case, perhaps restricting one policy source or making the usual approver unavailable. Discussing how the person adapts their work reveals more about their understanding than the original demonstration alone.

This is the part of training I care about at LockedIn Labs. The platform's public role practice gives you a decision to work through, guidance to compare it with, and a changed scenario to try after revising your answer. You can download the worksheet to keep a record of that work. Enrolled learning adds the lessons and workbenches available to your account, with assignments and recorded feedback. These provide ways to practice, while a staffed review or field qualification would require its own evidence and decision.

A benchmark can help organize the record when it explains what was attempted and how the work was judged. Keep the original attempt together with the review method, feedback, and revision, and make it clear whether the review came from you, automated guidance, or another person. That context lets someone understand what a result means and decide what further evidence they'd need.

If you're putting together your first portfolio, choose one project you can bring to this level of detail. Make it possible for another person to run the difficult case and leave you feedback you can act on. The next project can then address something you struggled with in the first, giving you a reason for what you study next and a record of how your work is developing.