I reply to a profile with one real project explained well: what it does, who used it, what broke. I skip a list of twenty certificates and the same RAG chatbot tutorial that everyone builds.
That is the whole answer. The rest of this note is why, and how to turn what you already have into the first kind of profile.
The first look is short
Nobody reads your profile the way you wrote it. In 2018, a study by the job site Ladders tracked recruiters' eyes and found the first screen of a resume took about 7.4 seconds on average. The same study found that resumes with simple layouts and clear headings did better.
Seven seconds is enough to see one thing. If that one thing is a block of course logos, the reader learns that you took courses. If it is a project with a user and a number, the reader learns that you built something and someone used it. Only the second one makes them read on.
Why certificates don't do the job
Paul Graham has a plain way of putting what credentials are for: they predict how someone will perform. When you can see the performance itself, the prediction matters much less.
A certificate is a prediction. A project that ran in front of real users is the performance. AI engineering makes this sharper, because the hard part of the work only shows up once real people use the system. A course can teach you to call a model, chunk documents and store vectors. It cannot show you what happens when users ask questions the course never imagined.
That is also why the tutorial RAG chatbot gets skipped. It is not a bad project. The reviewer has just seen it many times, and it answers none of the questions they actually have.
What a shipped project looks like on paper
When I read a project, three things tell me someone has shipped AI work:
- Users other than the author. Classmates, a team at work, a small group of friends. It doesn't need to be thousands. It needs to be someone who isn't you.
- A number. How many people used it, how many questions it answered, how often it was right on a set you checked by hand.
- A decision explained. Why this design and not the other one. Why you stored the data this way, or why you didn't use an agent.
Laszlo Bock, who ran hiring at Google, gave a well-known formula for resume lines: accomplished X, as measured by Y, by doing Z. It works well for AI projects, because it forces the number and the method into the same line.
Here is the difference on a real case. My first AI feature that fell flat was a policy chatbot for an employee engagement platform. Employees asked about company policies, and the answer had to come from the policies their seniors had published.
The tutorial version of that line says:
Built a RAG chatbot over company policies using a vector database.
The version a reviewer replies to says something closer to:
Rebuilt a policy Q&A assistant for [who used it] after users said "it just does not work as expected". Found it was answering from old versions of policies, because retrieval picked the top matches with no regard for which version was current. Checked on [N] real employee questions.
Fill the brackets with your own facts. If you don't have a number, don't make one up. Write what you checked and how.
The question behind every interview: what broke?
Sooner or later someone asks: "What broke in production?" Many people answer "nothing broke". That is the worst answer, because every system that met real users broke somewhere. "Nothing broke" tells the interviewer either that nobody used it, or that you didn't look.
The answer that works has three parts:
- This is what broke. One specific failure, not a category.
- This is how I found out. A user complaint, a log, a check you ran.
- This is what I changed so it doesn't happen again. The fix, and the check that now catches it.
This is the same shape Google's engineers use when they write up incidents. Their postmortem guidance asks what happened, why, and which actions will stop it coming back. You don't need an outage at scale to use it. You need one honest story.
From the policy chatbot: what broke was answers coming from the old version of a policy. We found out because the client never accepted what we shipped, and when we read the responses one by one, the matching ignored recency. What we changed was how we wrote requirements: detailed input and output expectations for every request. The team was reluctant to change how it worked. That belongs in the story too. It is the kind of detail a made-up story never has.
Add a number if you have one. "This happened on about one question in ten" is stronger than "sometimes".
If you haven't shipped anything yet
Then the job is to get one project in front of people other than you. It can be small. A tool for your batch, your team or your housing society counts, if they really use it. When I was preparing for my own course exams, four of us built a question bot for our course and thousands of students used it. That story is in the QuizzaHut note.
A small project with real users gives you all three things at once: someone other than you, a number, and something that broke. A big project nobody used gives you none of them.
This week
Pick your one best project. Write three lines about it, and put them at the top of your profile:
- What it does and who used it.
- One number you can stand behind.
- What broke, and what you changed.
If you can't write line 3, you have found your next piece of work: put the project in front of a few real users and watch where it fails.
Twenty certificates say you studied. One project, told honestly, says you can be trusted with a system.