I'm a Data Architect at my day job and I have a PhD in CS.
Database jobs are all over the map, and so it probably depends on which part of the industry you end up in. I know some database people who only do Oracle and PLSQL. I know of others who have never touched Oracle, and focus on ETL workflows. Others specialize in NoSQL and would die in a pure RDBMS. Others are experts in graph databases. In my job, I do a lot of contract reading, RTM matching, documentation work, report creation, and am brought in to optimize or design particularly messy SQL or design new solutions.
My high level advice is this: learn the common patterns and then build things. Avoid all blanket advice (self-referential pun intended). There's usually a decent use case for every design, even the "bad" ones.
For example: In a class, you will learn about normalizing your data and the normal forms (BCNF FTW!), why you should use indexes, and the power of all the different types of joins. However, you may never hear about the need for logging databases (such as BigQuery), where joins are expensive ($$$), indexes don't exist (but partitions do), and normalization is thrown out the window for the sake of speed. It's an indispensable use case, and yet most DBAs wouldn't even consider BQ because it breaks all the rules.
Here's some concrete advice: Figure out where you want to work, and study their job postings. That is what you want to tailor yourself towards. You might even be able to reach out to their current devs and get mentorship.
Lastly, build something. Build something big. Write a blog post about it or record a YouTube video about it.
Then, build something else and repeat the process. You will gain more practical experience from that than you realize, and it looks great on a resume.
I'm happy to answer any questions.
Good luck, and enjoy the journey!