You’re probably aware of the comma separator in CSS selectors. They’re a handy way to have a set of CSS attributes applied via multiple selectors in one go.
You’re probably also aware of pseudo-classes (sometimes referred to as pseudo-selectors). They give your selector some smarts. For example “input:focus” applies only when the input element has focus.
I recently ran into a problem when I used both at the same time. …
Anyone who’s developed front-end applications knows that managing the state is one of the most important, and challenging, aspects. Popular component-based view libraries, like React, include fully functional, if not rudimentary, state management. They enable each component of your application to manage their own state. They work well enough for small applications, but you’ll quickly encounter frustration. It’s a challenge deciding which components have state and how the data from each state gets shared between components. Then there’s figuring out how or why state was changed.
To address the above problems of component-oriented state, libraries like Redux were introduced. They centralize that state into a centralized “store” that every component can read and write to. To maintain order they centralize the logic that changes the state into a central part of the application called the reducer, which is invoked using actions, and causing it to produce a fresh copy of the state. It’s very effective but has a high learning curve, requires a lot of boiler-plate, and forces you to separate code that updates the state from the code that renders the view. …
It’s commonly agreed that engineering interviews are broken, and yet they never change. Why are they broken and how can they be fixed?
The standard software engineering interview often includes the following:
We do these because they supposedly tell us something about the candidate we’re interviewing. They’re supposed to tell us if the candidate is “capable” or “incapable”.
Algorithmic questions as simple as FizzBuzz are supposed to tell us whether a candidate can “even code”or not. This may seem fair since the interviewer can code it standing on their head but it instead filters out people who have either never read about it or never needed to use the modulus operator (I honestly can’t remember the last time I shipped code that used it). The candidates that are good at algorithmic questions are those that like doing them, but those candidates may not be good at implementing a UI, or a scalable API layer. …