A resume is a list of claims. Every applicant has one, and most of them say roughly the same things. A working link is a claim someone can check in fifteen seconds, which is why it survives a skim that your bullet points do not. It also answers the only question a hiring manager quietly has about a career switcher: can this person finish something and put it in front of a stranger. One small, finished, clickable thing answers that. Three unfinished repos do not.
Do not pick it yourself. Most people default to whatever project they saw in a tutorial, which is how five hundred applicants end up with the same movie recommender. Give Claude the actual job description and make it reverse-engineer something that maps to it.
I am trying to move into this role: [paste the full job description, or the role title plus the 5 responsibilities you see repeated across postings]. My background so far is [your current job and the two or three skills you genuinely have].
Suggest 5 small portfolio projects I could build in a weekend that would prove I can do the specific things this role asks for. For each one, tell me: the one-sentence pitch, exactly which requirement from the job description it demonstrates, what data or inputs it needs, roughly how many hours it is, and the single most impressive thing about it that a hiring manager would notice in the first ten seconds.
Rule out anything that needs paid APIs, a dataset I would have to buy, or more than a weekend. Then recommend one of the five and explain in three lines why it is the strongest signal for this particular role.Use these as calibration for what "small and finished" looks like. Each one is a weekend, not a semester.
Gradio is a Python library that turns a normal function into a working web interface, so you get a real app without writing any front-end code. That is the whole reason it is the right choice here: your project ends up as something a person can use in a browser rather than a notebook nobody will open. It is open source and free (gradio-app/gradio).
This is the entire shape of a Gradio app, so you know what you are aiming at before Claude writes yours:
import gradio as gr
def greet(name, intensity):
return "Hello, " + name + "!" * int(intensity)
demo = gr.Interface(
fn=greet,
inputs=["text", "slider"],
outputs=["text"]
)
demo.launch()That example is adapted from the Gradio quickstart.
A function, a description of its inputs and outputs, and one line to launch it. Now hand Claude the job:
Build me the project we chose as a single Gradio app in one file called app.py. I am a beginner, so write the complete file, not fragments, and add a short comment above each section explaining what it does in plain English.
Requirements: it must run with only free and open-source dependencies, it must handle bad or empty input without crashing, and the interface needs a clear title, a one-line description of what the app does, and two example inputs pre-loaded so a visitor can try it in one click without thinking. Keep the whole thing under about 120 lines.
After the code, give me three things: the exact requirements.txt contents, the terminal commands to install and run it locally, and a list of the three most likely errors I will hit on my first run with the fix for each.app.py and requirements.txt inside it. Two files is genuinely all this needs.pip install --upgrade gradio. If your project needs anything else, it is already listed in your requirements.txt, so pip install -r requirements.txt covers the lot.python app.py. Gradio starts a local server and your app opens at http://localhost:7860 in your browser. Seeing your own thing running locally is the moment this stops feeling theoretical.demo.launch(share=True) gives you a temporary public link (something like https://07ff8706ab.gradio.live) that runs off your own machine. Useful for showing a friend today. Not your portfolio link: share links expire after one week and die when you close your laptop.Spaces is free hosting for exactly this kind of app, and it gives you a permanent public URL that works whether or not your laptop is on. The free hardware tier is CPU Basic, 2 vCPU and 16 GB of memory, at no cost (Hugging Face pricing), which is comfortably enough for a portfolio demo.
job-description-analyser beats test2), choose Gradio as the SDK, leave the hardware on the free CPU Basic option, and set it to Public.app.py and requirements.txt. Spaces installs your dependencies for you (Gradio Spaces docs).gradio deploy from your project folder pushes the app to Spaces for you (Gradio hosting guide).app.py, because a public Space means public code. Better still, pick a project that needs no keys at all, which is why the six ideas above were chosen the way they were.A live link nobody clicks is the same as no link. These three pieces of writing are what turn it into an interview.
Here is my finished project: [paste your app description and the public link]. I am targeting this role: [role title and the key requirements].
Write me three things. First, a README for the Space: what the tool does in one sentence, who it is for, how to use it in three steps, what I built it with, and one honest paragraph on its limitations. Second, a LinkedIn featured-section blurb under 60 words that leads with what the thing does for the reader, not with the tech stack. Third, a single resume line under 20 words with the link, written so a hiring manager understands the outcome without opening it.
No buzzwords, no "leveraged" or "utilised", no em dashes. Plain sentences only, and never claim the project does more than it actually does.This is a weekend, not a career. It will not by itself get you hired into a senior role, and anyone promising that is selling something. What it does is change the shape of your application from a list of claims to a thing someone can try, which is what gets you the conversation. Build one, ship it, put the link everywhere, then build the second one only if the first one gets used. Two finished projects with real links beat ten repos nobody opens.
gradio deploy route