His post picture is misleading. You cannot say farewell to divs. They are necessary to create a structure for CSS styling to enable the HTML to render into a usable UI. But what he is explaining is the ability to avoid creating unnecessary divs. I can't go much deeper without discussing the concepts of React, as it would not make sense. The lesson is that Fragments allow you to meet a particular requirement of code structuring in React. They prevent you from having to create lots of unnecessary divs.

Can you do any more? The interviews are an excellent shake-up for people. You can talk about the importance of fundamentals, but people need see the value themselves. Most will not, as is evident, without this revelation in the interviews. Here is why: The problem is we can get away with using stuff without truly understanding it. Or, being able to explain it. So we can have this perceived concept of our knowledge and that masks the actual knowledge. With coding, we can know enough to use something. But then there's a deeper understanding that leads to practical implementation. Also, we need to advance a certain amount before the fundamentals will be able to be understood. So there's an element of going backwards to move forwards in the learning. I think shiny object syndrome can be at play. We want to advance into more tech so we can look good on paper—I've used this and that and worked with x, y, and z. And we can, we can use them. But inefficiently. It's easy to write bad code that works. There's a combination of personal responsibility and this shiny object syndrome. With personal responsibility, we must start dictating what we need to know to be effective. Avoiding shiny object syndrome so we are not pulled into spreading our knowledge too thinly. Example; I have focused on advanced Javascript techniques and learning React on a deeper level. There's all this other stuff that would be nice to have, e.g., learning Docker, understanding AWS, and CI/CD pipeline. But you can learn a little about this and be able to hash something together but overall the implement is very low level. So, I am focusing on the fundamentals of what I am using now and slowly bringing in a little bit of knowledge of the other things. It's called the T-Shaped Developer. https://thetshaped.dev/p/the-t-shaped-software-developer

@Alexandrea Pettyjohn This here is a valuable lesson in Operator Precedence and Operator Associativity. Operators are special functions that can be used on a single line of code. For example const sum = a + b is a function const sum = function(a, b) { return a + b } that is immediately invoked const sum = (function(a, b) { return a + b })() There have to be rules when using operators so that there is consistency for when each function is invoked. If we have const sum = a + b / c. Do we run the function with a and b and return the added values, then pass that returned value to the function that divides it against c? Or the other way around, b divided by c and this value is then added to a? This is where precedence and associativity comes in. Different operators have a different hierarchy for when they are called. This is their precedence. Their are 18 levels of hierarch in JavaScript Operators. https://www.w3schools.com/js/js_precedence.asp If operators have the same precedence number, then associativity comes in to play. Associativity is whether the functions are called from left-to-right, or right-to-left. As Cristian points out in the video, the operator function returns a value that is then passed to the next operator. So when you read operators you have to think of each return value and the order of the function calls. The function calls as stated here are based on precedence and associativity. A more indepth look is here: https://library.fridoverweij.com/docs/jstutorial/operators3.html

Steady progress 🙌🚀

Welcome to the community @Gisela Henriques