Salem

Your approach and answer look perfect to me.

> First, I try to understand the problem.
Yes, because solving a different problem won't get you your marks now, and won't get you paid later.

> Second, I look at the examples and see how the program should run.
Also good. It might produce the correct answer, but if all the detail of the program I/O is wrong, then it's still a failure.

> Then, I try solving the problem which data structure would be best or something along those lines.
Also good. The choice of good algorithms + data structures vs. bad ones can turn mere seconds on run-time into days or weeks.

> how I could have solved it better?
What would you consider "better"?
Less lines of code. Doesn't work for me, since I value readability above pretty much everything else. Being a good coder is not about writing the shortest and most cryptic bit of code possible.
Commercially, your code might last for 20 years or more, and be read by hundreds of different programmers in that time. Communicating clearly with all of them is paramount.

__________________
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.