Hi, data engineer here. Other comments have a lot of good suggestions. I especially agree with ideas like avoiding high powered frameworks in the beginning, and

Hi, data engineer here. Other comments have a lot of good suggestions. I especially agree with ideas like avoiding high powered frameworks in the beginning, and learning to write effective transform wrappers for different kinds of weird input data. One thing you'll find is that (for enterprise situations at least) your source data is going to come from extremely odd, old fashioned, or very poorly documented sources. Be prepared to find twenty and thirty year old manuals on formats you've never heard of at times. That aside, the other side of the coin that is very important is to get very familiar with how folks talk about their data problems. Managers, analysts, etc. will often request a specific solution that they've heard of or seems popular--sometimes it is what they need, often times it isn't. To get a solid footing in this space (not that it isn't for all types of SE) it is critical to have very strong understanding of business requirements, understanding the work of many other roles in your org, and being able to communicate with business folks in ways that allow you to develop a rational plan for a solution while getting them to realize what their needs really are. Best of luck!