What is a pull request? A plain-English guide for recruiters

Short answer: a pull request (PR) is a developer's proposal to change a project's code. Teammates read it, comment on it, and either approve it or ask for changes. A merged pull request is one that was accepted and is now part of the project. For a recruiter, a merged PR is a small, dated piece of evidence that someone else judged this person's work good enough to ship.

You will see "PR" on CVs, GitHub profiles and in candidate conversations. This guide explains what is inside one, what a merged PR tells you, and what it does not.

How a pull request works

Software projects live in a shared folder of code called a repository. Nobody edits the main version directly. Instead:

1. The developer copies the code into a separate branch and makes their change.
2. They open a pull request, which says: "Here is what I changed and why. Please pull it into the main code."
3. Teammates or the project's maintainers read the change line by line and leave comments. This step is called code review.
4. The developer answers the comments and updates the change.
5. A maintainer merges the PR, or closes it without merging.

A PR page shows a title, a description, the list of changed lines, the discussion, and the final status: open, merged or closed.

Merged, open and closed: what each status means

Status	Meaning	What to read into it
Merged	Reviewers accepted it and it is now in the project	The strongest signal: someone else approved the work
Open	Still under discussion	Neutral. Look at how the author responds to feedback
Closed, not merged	Rejected, abandoned or replaced by another approach	Not a red flag by itself. Good projects reject many PRs

What a merged PR to someone else's project tells you

PRs to a project the candidate does not own are the most useful. A stranger, or a team the candidate does not control, had to be satisfied.

1. Their work met an outside standard. Maintainers of popular open source projects reject sloppy changes. A merged PR means the code fit the project's style, passed its automated tests and made sense to a reviewer.

2. They can work with other people. Open the discussion tab. Did the author respond politely to criticism? Did they revise the change, or argue in circles? Collaboration is hard to test in a 45-minute interview and easy to read in a PR thread.

3. They can explain their own work. A good PR description says what the problem was, why this approach was chosen, and what was left out. A one-word title with no description tells you something too, though less than you might think: many teams use short descriptions on purpose.

4. They kept going. One merged PR from three years ago proves little. Merged PRs spread over months or years show sustained work.

What a merged PR does not tell you

• How hard the change was. Fixing a typo in documentation is a merged PR. So is rewriting a database layer. Open the PR and look at the size and the discussion.
• Who wrote the code. On a team, PRs often carry the work of several people. A PR in a company's private repository is also invisible to you. Public PRs are a partial picture of any developer's career.
• Whether they would fit your team. PRs show how someone works in a project. They say nothing about whether the role suits them.
• Anything about developers who work mostly in private. Many excellent engineers have an empty public profile because their employer owns their code. Treat a missing profile as "unknown", never as "weak".

Red flags and green flags in a pull request

Green flags

• Merged into a project the candidate does not own
• A description that explains the problem and the reasoning
• Replies to reviewer comments with changes or reasoned pushback
• Small, focused changes rather than one giant dump of code
• A history of PRs over many months

Red flags

• Many PRs, all to the candidate's own repositories, all merged by themselves (it is normal for solo projects, but it is not independent approval)
• A profile full of copied tutorial projects with no changes of their own
• Reviewer comments that raise the same problem again and again with no learning visible
• Defensive or dismissive replies to feedback

None of these should decide a hiring outcome alone. They are reasons to ask a better question.

A five-minute PR check for recruiters

1. Open the candidate's GitHub profile and click Pull requests, then filter by Merged.
2. Look for PRs to repositories owned by someone else. The repository name will not start with the candidate's username.
3. Open two or three. Read the description and the comments, not the code.
4. Note the project: is it real software that other people use?
5. Write down one thing you want to ask, for example: "In your pull request to the X project, the reviewer asked you to change how errors were handled. What did you decide and why?"

That last step is the useful one. A developer who wrote the change can answer in two minutes. Someone who cannot explain their own merged PR has told you something worth knowing, and so has someone who lights up while describing it. For more on turning evidence into questions, see how to interview a developer when you're not technical.

Where DevEval fits

DevEval reads a candidate's merged pull requests and the code in them, flags what it could not see (private work, team-written code), and suggests interview questions about the candidate's own changes. It is the same check as above, done in under a minute. See the methodology for what is and is not measured. It is one input to your decision, never a verdict.

Frequently asked questions

Is a pull request the same as a commit? No. A commit is one saved change. A pull request bundles one or more commits into a proposal for review.

Does a developer with few PRs have less experience? Not necessarily. Engineers at companies with private code have few public PRs. Ask about their work directly.

Are PRs to the candidate's own projects worthless? No, but they prove less. They show what the person builds, not whether outsiders approved it.

Should I tell candidates I looked at their PRs? Yes. Public work is fair to read, and telling candidates is courteous and, depending on how you store the data, may be required. Tell them what you looked at and why.

Next: what code review is and why it is a strong hiring signal, and how to evaluate a developer's GitHub profile.