> My resume is filled with the latest trendy words like Docker, Scala, Kafka, Spark, Hive, react, K8s or any new framework that seems to make a buzz. This grab

> My resume is filled with the latest trendy words like Docker, Scala, Kafka, Spark, Hive, react, K8s or any new framework that seems to make a buzz. This grab-bag of technologies is kind of all over the place. I see two possible paths forward (these aren't exclusive): First path: everything you've listed is open source. Pick something, and start digging into the code to figure out what makes it tick. Try to fix a bug from the issue tracker, or review a PR. At some point you'll dig down far enough to encounter a tool or technology (also open source) you're unfamiliar with, and you can learn that and keep digging. Lather, rinse, repeat. I've found that most recommendations are to study things bottom up (eg. NAND to Tetris), but for many people it is very difficult to see the point of the lower levels, they are just too many layers of abstraction removed from anything they might find interesting. Top down learning tends to be self-directed, less formal, and ad-hoc, but the motivation for learning is much clearer (ie. you're digging down from the interesting thing made possible by the layer you're digging into), which tends to help a lot. Sure, you're always finding out that the abstractions you know are arbitrary, illusory, or even false in important ways, and in any case always hiding nasty messy truths underneath, but TBH that's how most real learning in our field happens anyway. Second path, those technologies all have use-cases where they are (supposedly) useful. Start with a CRUD app, and try to figure out when one of those technologies makes sense to incorporate, and explore the edges of those use-cases, their failure modes, when it stops making sense to use them. Most CRUD apps in the wild are, well, pretty cruddy, which means that there is a ready market for skills to get them working again after they've broken down for some reason: too many concurrent users, too high volume of transactions, too large volume of data, too many monitoring alerts, backups take too long, transactions fail, specific queries always time out, inconsistent state, search autocomplete has started freezing the page, newly entered data takes 10m to become visible to users or to another app, hosting costs have started increasing non-linearly, a password reminder takes an hour to arrive in the user's inbox, and on and on. When it comes right down to it, Twitter is basically a CRUD app. So are ebay, Wikipedia, Amazon, AirBnB, Yelp, Facebook, Reddit, LinkedIn, and so on. And yet not, as a Rails clone of these sites can quickly reveal once you start getting a few thousand users (real, or simulated). Sometimes solving a bottleneck can be done by swapping out a component or scaling horizontally or vertically, other scenarios require more extensive changes. Learning how to recognize and mitigate these inevitable growing pains can lead to some interesting places, and more interesting solutions and work. Sure, CRUD apps as initially deployed, are boring. But they don't have to (and arguably can't) stay that way, especially as they evolve to encompass more users and data, not to mention functionality (eg. geodata, full-text search, stream processing, notifications, workflow, auditing, PII, security, etc.). I hope this helps. Good luck on your journey!