Why shouldn't you commit straight to the main branch? What does a good pull request need?

Committing straight to main means the change becomes shared code immediately, before anyone has read it and before the automated checks (CI) have run. If main is connected to deployment, a small bug goes straight to production. When you work on a separate branch, main always stays in a working state, several people can work in parallel without stepping on each other, and every change has a place for discussion.

For the second part, the interviewer wants to hear you think about the reviewer. A good pull request usually has:

• One single purpose. Fix one bug or add one feature. A PR that mixes a bug fix with a bulk rename and a library upgrade is hard to review, and hard to pull apart when something goes wrong.
• Commits split by meaning, with clear names. For example one commit for the fix and one for the test. Generated files such as package-lock.json go in the same commit as the change that produced them.
• A description that answers four questions: what the problem is, what changed, how you checked it (with the specific commands) and what you deliberately did not do.
• A self-review done first. Read your own diff to remove a forgotten console.log, personal config files and experimental code.
• A reasonable size. A few dozen to a few hundred meaningful lines. A thousand-line PR often gets a single "LGTM" that nobody really read.

It helps to tell an example of your own, such as the time you reread your diff and caught a log line printing a customer's phone number before you opened the PR.

Bonus points: say that many teams turn on branch protection to block direct pushes to main and require green CI before merging, and that small PRs make it faster to find the commit that caused a bug.