You could try code kata (http://codekata.pragprog.com/) or koans, (just search Google for your language + 'koans') but those are really only a fun way to work on a specific, easily-tested skill, that also happens to be the very first a novice learns, that's implementation. By all means, if they help, knock yourself out.
The thing about programming is that to get better at it, you need to expand the way you think about abstraction. You have to think not just in terms of how you will maintain what you wrote, but how the end user will use it and how the domain might change.
Any novice can hack together something that will work for one specific purpose, it takes someone skilled to pull useful abstractions out from that single-use code and turn it into something flexible enough that even years from now another novice will be able to pick it back up and understand it enough to be able to reuse it.
All that is to say is, any purported exercise isn't going to get your brain thinking the way it needs to. They're only going to take you to the end of the very first step of mastery, that's in "getting the computer to do what you want it to".
Exactly. IMO its not just the exercises that help you write great code (though they MIGHT help in competitive coding like for ACM). Truly beautiful code comes from experience and working with those who have spent years getting that experience. In my current company there is a huge focus on the re-usability and extensibility of the code. We are forced to think of future changes and make sure the code allows changing things in the most easy way possible.
One simplest example: All queries to a single DB table have to be done through a single "Data Class". The class will have functions that will allow other classes to use that table. this ensures that if tmrw, we make changes to that table, there is only one place in the code we have to make the changes. Instead of running around in the massive code base, looking for the queries to that table.
That's an application of the Dependency Inversion Principle, part of the SOLID methodology. You always want your code to depend on abstract forms rather than concrete ones. By abstracting database calls into a class, you avoid having to constantly write brittle methods digging deep into concrete implementations.
One way your company's method might evolve is into the Active Record pattern. You define a class around a particular table, implementing domain logic inside that class. You see this pattern used in Rails. If you're using one class per table, I think that's the way it will eventually go.
I like Active Record ORMs for many applications, but only as a persistence layer. Implementing domain logic in a data class is asking for pain, it violates the Single Responsibility Principle. Each class should do only one thing. The thing handling your data persistence should only read/write to the database, it should not also perform calculations or perform actions on anything other than the database.
I refactor domain logic out of models when I see it into Plain Objects with no dependencies, and let the domain have its own abstract world of classes minus ugly database wrappers to play in. I can then write an adapter to the data classes. If it's an existing application in production, then at this point I would start to re-design the database, inevitably it will need work.
I do this by creating another database schema, generating the data classes, simple as pie now without domain logic getting in the way, then create the adapter from examining the existing one. I can then import all the data from the database, represent it as abstract plain objects, then shoot those objects through the other adapter into the new database.
But it only really works if everything does one thing. Your domain objects talk to each other. Your adapter classes go between the domain and the data. The data talks to the database. Achieving this requires hard-won experience with programs that break the principles. You have to feel the pain and recognize where it's coming from. No kata will give you this experience.
Well yes, that's what we do too. The logic implementation is in the Business classes. The data classes just read/write from the tables, and return that data to the business class that performs more meaningful functions on it. This way the data can be used in multiple ways by multiple classes without them depending on each other. A change in domain logic would mean a change in the business class, leaving the data class unaffected
The thing about programming is that to get better at it, you need to expand the way you think about abstraction. You have to think not just in terms of how you will maintain what you wrote, but how the end user will use it and how the domain might change.
Any novice can hack together something that will work for one specific purpose, it takes someone skilled to pull useful abstractions out from that single-use code and turn it into something flexible enough that even years from now another novice will be able to pick it back up and understand it enough to be able to reuse it.
All that is to say is, any purported exercise isn't going to get your brain thinking the way it needs to. They're only going to take you to the end of the very first step of mastery, that's in "getting the computer to do what you want it to".