1. Depends what you want to do and where. For example, there's relatively few companies doing any stored procedures at all, but there are also companies that en

1. Depends what you want to do and where. For example, there's relatively few companies doing any stored procedures at all, but there are also companies that enforce them religiously. Same for kubernetes - are you trying to get in somewhere that uses it? 2. Many points are a lot of huge things really. All the security things for example. Should you know basics like understanding Owasp top 10 - sure. Should you know about ebpf used for line speed matching against known/hypothetical issues - eh, probably not yet. Same with data structures: Knowing about hashes vs lists and something about indexes - sure; writing your own b+tree - meh (unless you want to apply to a company that may want to include it in the interview). Basically what I'm trying to say is: find out what is actually going to be likely useful, split those things into many levels, get some really basic understanding of each, then see what's useful for you next. Also keep in mind that "regular expressions" is a week of fun to learn, but "kubernetes" or "Web security defense" is a full career.