When is cherry-pick a bad idea?
Overusing it creates duplicate commits with different hashes, which later cause confusing conflicts when the branches are merged. Prefer merging or rebasing when you want the whole branch.
Explain it simply
Photocopying a page is fine once. If you photocopy a dozen pages and later also staple the original book in, you have repeats everywhere.
A cherry-picked commit is a copy, so when the source branch is eventually merged, Git may see the same change twice. Often it detects the match and moves on, but when surrounding code changed it raises conflicts that are hard to read. Good uses are hotfix backports and rescuing one commit from an abandoned branch. If you find yourself picking many commits, a merge or rebase is the better tool.
Example
git log --oneline --cherry-mark main...feature
# = same change on both sides, + only in featureWhat to say in the interview
"Cherry-pick makes duplicate commits with different hashes, which can cause confusing conflicts later. I limit it to backports and one-off rescues, and use merge or rebase for whole branches."