The worst part about learning software engineering is not knowing what you don't know. I started my programming journey back in college, I took the self-teaching route and it was pretty hard to maneuver alone. I learned Python, and started making web apps with Flask before understanding OOP, I even had my first applications deployed before even knowing what a client-server architecture is.

While this obsession of pushing products to free cloud hosting services kept my enthusiasm alive, I had no clue what or where OOP is applied, my code was spaghetti except the spaghetti was rotten, things worked but I knew they felt hacky. All my flask apps were just 200 line functions thrown together, I questioned where are the classes that CS-180 (Purdue Intro to CS) lectures spoke about? 

I was also working on an application that needed to send notifications, so I would loop inside of the route handler holding the request, response, sending notifications.

 It wasn't for a while till I learned the answers to my questions from asking embarrassingly stupid questions to Senior Engineers at Root (my first job). I maintained a list of concepts that didn't make sense and eventually ticked them off. In this article I would like to share these with you as must haves before your first job as an SDE, that I didn't have.

The lifecycle of a request on the web when you ask for something on your browser.

Sounds like a surprisingly straightforward question but there's a lot we take for granted until we look under the hood. Here is the stack overflow answer that helped bring clarity https://stackoverflow.com/a/4814789 for me. I would also suggest learning about the lifecycle of a request in terms of how html, css, JS is fetched, along with how data is fetched. You may not care about DNS servers and you can take it as an abstraction but I think it is worth the effort to have a better understanding even if you do not interact with the concepts day to day. I once mentioned something about TCP connection to a domain name, and the interviewer started digging upon it, it's painful to think about that interview conversation even now.

What is server side rendering? How does it differ from client side rendering?

I knew of a difference but the entire journey and fetching of data was unclear for client side rendering. As a bonus I would encourage readers to look into when which one is viable when? What really blew my mind was the hybrid model of server side and client side rendering. Something I encourage others to explore.

Here is an article that describeds SSR vs CSR that helped me https://www.toptal.com/front-end/client-side-vs-server-side-pre-rendering

Task Queues

This has been my favorite discovery by far. When I discovered you could run actions outside of your request response cycles, I started putting everything a task queue (even things that shouldn't have been in a task queue). The way to learning the function of a task queue for me was, finding a painful slow api in my personal project that was clearly something that could be done "at a later time" or "not needed immediately", for me this was notifications. The general concept of a task queue, to defer tasks to be handled outside of the context of a request response cycle made the most sense to me when I implemented it. The language, framework, and specific technology does not really matter, although certain frameworks will make handling task queues much easier than others, as long as you can visualize the idea, I think you're at a good spot. Julian Nash is a YouTuber who has a pretty good video for an intro to task queue (https://www.youtube.com/watch?v=3muR5g

B8x2o&t=929s). However, I encourage you to build something slightly more complex, to get a realistic feeling.

Websockets

I made a chat app with polling every 1 second and it was not pretty, it led me to question how do live chats and apps like WhatsApp and Facebook messenger work. I came across websockets and I cowered away. It was all too intimidating. It took me around 2 years from the very beginning of my programming journey to finally gather to courage to learn websocket programming. Pre-programming a web socket based application I just knew of websockets as a "bi-directional" protocol, but I had never programmed it a day in my life. Although your immediate job may only require http requests, I think websockets go a long way in having the right tool for when the need to use them arises. Hussain Nasser has a really good course on YouTube that just absolutely blew my mind in how clearly everything was being explained. https://www.youtube.com/watch?v=XgFzHXOk8IQ&t=18914s

Going beyond MVC and MVT

This is the one that has really helped me. Before becoming a full time engineer, I was convinced that code in prod was just MVC, I knew nothing of different architectural and design patterns outside of MVC or MVT which dominated most of YouTube tutorials, and documentation. It wasn't till I started working that I came across patterns like Service Objects, Repositories, and DAO. These concepts were made really clear by reading Object Oriented Design by Matthias Noback. I try to revise this book often and It was the most practical book that I read on software design. I highly encourage readers to read this.

I hope this article helps you discover just a few more things and bring you one step closer to knowing what what you didn't know :)