TL;DR: Git finds the common ancestor and applies both sets of changes; where both touched the same lines it stops and asks. Resolve by understanding both intents rather than picking a side, then run the tests, because the dangerous conflicts are the ones that merge cleanly and are still wrong.
How to approach it
Explain the three-way comparison, because that is what makes conflicts predictable rather than arbitrary. Then spend the second half on the semantic conflict, since anyone can describe removing the markers and the interesting failure is a merge that Git resolved happily and that broke the build.
A strong answer
A merge is a three-way operation: your branch, their branch, and the commit both descend from. Git compares each side against that ancestor. A change only one side made is applied. A change both sides made to the same region is a conflict, and Git refuses to guess.
The markers:
<<<<<<< HEAD
timeout = 30
=======
timeout = 60
>>>>>>> feature/slow-upstream
Above the ======= is the branch you are on, below it is the branch coming in. Resolving means editing that region into what should be there and removing all three marker lines. It is not a choice between two options: often the right answer is neither, or both combined.
The commands worth knowing:
git status # which files conflict
git diff # the conflicting regions
git merge --abort # back out entirely and think again
git checkout --ours <file> # take our version wholesale
git checkout --theirs <file> # take theirs wholesale
git add <file> # mark resolved
--abort deserves emphasis. A conflicted working tree is a reversible state, and backing out to talk to the other author is frequently faster than reasoning about intent from a diff.
The useful setting for anything non-trivial:
git config --global merge.conflictstyle zdiff3
That adds the common ancestor into the markers, so you see what the line was before either side touched it. Knowing the original turns "which of these two do I want" into "what was each person trying to change", which is a question you can actually answer.
Then the part that matters most. A semantic conflict is when both sides change different lines, Git merges without complaint, and the result is broken. One branch renames a function, another adds a new call to the old name. One changes a config key, another adds a reader for the old key. Git sees two edits to different regions and merges them, and nothing warns you. This is the reason "the merge was clean" is not the same as "the merge is correct", and it is why the build and tests have to run on the merge result rather than on either branch. The artifact you ship is built from the merge, so that is the only combination worth testing. A merge queue exists precisely for this: it tests the combination before it lands on the main branch.
On prevention, the honest answer is that conflicts are mostly a function of branch lifetime. A branch open for three weeks against a busy main branch will conflict; one open for a day usually will not. Merging main into your branch regularly, or rebasing onto it, keeps the divergence small and turns one large painful conflict into several trivial ones. Smaller, more frequent changes do more to reduce conflicts than any tooling.
What interviewers probe next
"Does rebasing cause more conflicts than merging?" Potentially the same conflict repeated, once per commit being replayed, because each commit is applied in turn. git rerere records resolutions and replays them, which makes repeated rebases far less painful.
"What if you resolve it wrongly and push?" Revert the merge commit, which needs -m 1 to say which parent is the mainline. Worth knowing before you need it, because the plain revert fails on a merge commit with a confusing message.
"How do you handle conflicts in a lockfile?" Do not hand-edit it. Take one side, then re-run the package manager to regenerate from the manifest, because a hand-merged lockfile produces a dependency tree nobody has ever installed.
Common mistakes
Picking a side to make the conflict go away, without reading what the other side was trying to do.
Leaving a marker line in the file, which usually produces a syntax error and occasionally does not.
Treating a clean merge as a correct one, when semantic conflicts merge silently.
Keeping a branch open for weeks and then resolving forty conflicts at once, which is where the wrong resolutions happen.