Projects for your resume: what interviewers actually ask 

Project advice usually arrives in one of two shapes: a list of twenty ideas, or a checklist for making your GitHub profile look good. Neither prepares you for the moment that decides whether a project helps you, which is when an interviewer starts asking about it.

That gap matters more now than it did two years ago, because building something impressive-looking has become trivial and defending it has not.

Your project is an interview subject

Companies that publish their interview processes are explicit about this.

Monzo’s engineering blog describes its backend interview and states the standard plainly: “We’re interviewing you, not your current or past team. We’re really interested in your personal contributions to the projects and work you talk about.” The technical detail they expect is specific: “data structures, language choices, performance/reliability trade-offs and security considerations.” Monzo

Ashby publishes its interview guide too, and runs past-project discussions twice, once in the introductory call and again in the final round for 30 to 45 minutes. Its reasoning is that these discussions reveal “what you would actually do on the job, like how you gather information, make decisions, plan work, and deal with time constraints or setbacks.” Ashby

A hiring practitioner describes the shape these conversations take: open with the project, explore it, then deep-dive one difficult part. His probes are the ones to prepare for. “What was your actual role in building this?”, “What was the thing you found most challenging?”, “How did you overcome it?” The distinction he draws is that a strong candidate is “specific about the things they built and contributed to the project beyond their job description”, while a weak one “is vague and played a one-dimensional role.” Metaview

The pattern across all three is consistent: nobody is scoring the idea. They are establishing what you personally did, what was hard, and whether you understood the decisions you made.

What GitHub’s own docs say

GitHub documents how these features work, and the documentation is more specific than the advice built on top of it.

Pinned repositories give you six slots, and GitHub says they exist so people “can quickly see your best work”. Six is a limit worth reading as a hint about attention span. GitHub Docs

GitHub’s own list of what a README should contain does not mention your tech stack at all. It says a README should cover “What the project does”, “Why the project is useful”, “How users can get started with the project”, “Where users can get help with your project”, and “Who maintains and contributes to the project.” GitHub Docs

The green contribution graph is looser than it looks. By GitHub’s documented rules, creating a repository and forking a repository both always count as contributions, while commits only count under specific conditions, including that they were made on the default branch of a non-fork repository using an email tied to your account. Forking somebody else’s project turns a square green. Treat the graph as decoration, not evidence, because that is what the rules make it. GitHub Docs

The problem AI created for you

Generating a working CRUD application takes minutes. In HackerRank’s 2025 survey of 13,732 developers, AI generated 29% of developers’ code on average, with 15% saying it writes more than half of theirs, and 97% using at least one AI assistant. HackerRank

The consequence is a verification problem on the hiring side. A Robert Half survey of more than 2,000 hiring managers, fielded in November 2025, found 65% reporting that a surge in applications, many AI-enhanced or AI-generated, “has increased the difficulty of verifying candidate skills”, and 38% responding by increasing the number of interviews per candidate. Robert Half

Heavily AI-assisted code also leaves a signature. GitClear analysed 211 million changed lines from repositories including Google, Microsoft and Meta and found duplicated code blocks rising sharply while refactoring fell, reporting that in 2024 copy-pasted lines exceeded moved lines for the first time on record, alongside a 39.9% decrease in moved lines. GitClear sells code-analysis tooling, so weigh that, but the direction is measurable rather than asserted. GitClear DevClass

From the outside, that is what a generated repository tends to look like: duplicated blocks, no refactoring, no reuse, and a commit history that arrives in one enormous drop.

Company policies on AI use diverge

The rule is not “don’t use AI”, and knowing where the lines sit is worth more than a blanket policy of your own.

Google is piloting software engineering interviews where candidates are given an AI assistant and evaluated on how well they use it. Its VP of recruiting said the pilot exists “to be more reflective of how our teams are operating in the AI era”, with interviewers assessing prompt engineering, output validation and debugging. Entrepreneur

Amazon takes the opposite position for interviews, instructing candidates “do not use GenAI tools during your interview unless explicitly permitted” and warning that failure to comply “may result in disqualification”. IT Pro

Even Google’s own description of AI-written code carries the qualifier that matters. When its CEO said more than a quarter of new code at Google was AI-generated, the sentence continued: “then reviewed and accepted by engineers.” Google

Reviewing and accepting is the skill, and it is a skill because the output is frequently almost right. In Stack Overflow’s 2025 survey, the top frustration developers reported with AI tools was “AI solutions that are almost right, but not quite” at 66%, with 45% saying debugging AI-generated code is time-consuming, and more developers actively distrusting AI accuracy (46%) than trusting it (33%). Stack Overflow

The last 10% the tool got wrong is the part an interviewer will ask you about.

What the hiring side says

The following are individual accounts from public forums. They are opinions, not data, and the thread they come from argues with itself, which is the most useful thing about it.

A hiring manager who reviewed 30 fresher resumes for one intern role wrote that “every resume read like the same person wrote it. And I think that person was ChatGPT”, and identified the specific failure: “Every resume had this long list of technologies… but nothing about what they built with any of it. When everybody lists the same 12 technologies it tells me nothing about anyone.”

His most actionable line is about what he wished he saw: “nobody talks about what was hard. Nobody says ‘I spent two weeks trying to connect my app to a database and almost gave up.’ THAT would actually impress me. Because that’s what real work looks like.” Reddit

Another commenter in the same thread, also hiring, described the GitHub version of the problem: “these folks have the same projects on their github as pre-AI, but those projects are completely written using AI. Before AI, everyone had an Amazon clone or Netflix clone on their GitHub, but at least they wrote it so i could judge their code… Now even those are written by AI, I don’t have anything to judge them by.” The original poster’s response is the standard worth internalising: “I’d rather see one small project that someone clearly built themselves, even if the code is messy… Messy code that works tells me you struggled and figured it out.”

The thread also pushes back hard, and fairly. Several commenters pointed out that candidates use AI because automated screening rewards it, one noting that if applicants “put original content in the resume they are less likely to get shortlisted by an ATS software”. Another made a sharper argument: “Why is someone going to write their challenges in a resume? You would write what you achieved, the scale, the impact. The challenge is something that comes out in the interaction.” That is a reasonable objection, and the practical resolution is that impact belongs on the resume while the struggle is what you bring to the conversation.

On whether anyone reads your GitHub at all, a thread on r/cscareerquestions splits cleanly along seniority. “For more junior positions, yes, I do read the GitHub, just to see if the code looks OK… For more senior positions, I want to know what you’ve done professionally”, wrote one. Another: “I read it. It’s ~5 mins of my time.” And the dissent is blunt: “I absolutely do not have time for that.” So it is read inconsistently, and read far more often for candidates without work experience, which means you. Reddit

Students are asking this question themselves. One thread opens: “How do you guys prep to talk about vibe coded projects in interviews? Do you just learn the core flow properly or go through the entire codebase before interviews? Curious how people handle getting grilled on these projects.” The most upvoted answer: “You should definitely understand at least the core flow and a good chunk of the code of any project you’re bringing to an interview.” Reddit

What to do about it

Build three projects you can defend rather than eight you can list. GitHub gives you six pinned slots and reviewers give you about five minutes, so depth is what survives questioning.

Choose projects that generate real decisions. A project only produces good answers to “what was hard” if something was hard. Anything where you picked between two approaches, hit a limit, or had to handle messy data will give you more to say than a cleanly generated clone.

Write the README to GitHub’s list: what it does, why it is useful, how to run it, where to get help, who maintains it. Then add the section nobody writes, which is the decisions you made and what you would change. That section doubles as your interview prep.

Commit as you build. A history that shows iteration is both more honest and more useful than one enormous initial commit, which is the most visible marker of generated work.

Use AI, then close the gap it leaves. Read every line you did not write, change something meaningful, break it deliberately and fix it. If you cannot modify it live in an interview, it is not yours yet, whatever the repository says.

Finally, rehearse four questions out loud: what your actual role was, what was hardest, how you solved it, and what you would do differently. Those come from published interview guides rather than guesswork, and practising them is worth more than another project.

Building something used to be the hard part, so having built it counted as evidence on its own. Now that the building is cheap, what you can say about it is doing that job instead.