Should I spend my time on algorithm practice or on talking about my work?
Both, though rarely in the ratio people use. Algorithm practice has a floor you have to clear, and past that the returns fall off quickly. If you have cleared onsite coding rounds before, the next hour is usually worth more on the deep dive and behavioral rounds, which are less rehearsed and often more decisive.
How many examples do I actually need?
Three or four pieces of real work, understood deeply, will cover most of a loop. One incident, one system you designed or substantially changed, and one disagreement is a strong base. Interviewers pull on threads, so depth beats breadth.
What if the hardest work I did was on a team?
That is the normal case, and the fix is precision rather than inflation. Give the team's work a sentence, then spend the rest of the answer on what you decided, wrote, or argued for. Vague ownership interviews worse than modest scope.
How is system design preparation different?
It is the round where you are usually reasoning about something you have not built, so the interviewer is watching how you handle not knowing. Stating your assumptions, naming what you would measure, and revising out loud when they add a constraint is most of the signal.
What if they ask about code I wrote years ago?
Reconstruct the decision, not the syntax. The question is whether you understood why the code looked the way it did. Nobody expects line-level recall of a repository you left behind several jobs ago.
Does this help if I am changing stacks or moving domains?
Yes, and the translation is the work. The assessments do not change; what changes is which of your past decisions demonstrate them in the language the target role uses. Preparing against the actual job description is how that mapping gets made.
