I remember a past job like 5-6y back had a "Clickable" component. We were supposed to wrap all interactive content in it IIRC

Under the hood it as an <a> with a missing href and `onClick` prop enforced 🤦

Hot take #4: still on "clean code" — comments are good + useful when well-written. Many devs don't write nearly enough comments.

Leaving them out doesn't magically make your code clean, but it DOES make it hard to remember what you were thinking when you wrote it.

#softwareengineering #cleancode

Hot take #3: "clean" and "tidy" are poor metaphors for "good" code. Most times "clean" just means "something I like".

Instead of calling code "messy", say what's bad about the code.

#software #code

Ok hot take #2: if you squash commits, it doesn't matter whether you do 56 perfectly named commits or keep force-pushing one that says "fix"

What matters is the commit that lands on main

Have used this approach on my app for $dayjob, and it's super nice

We even do it in lieu of storybook to make dep management easier. Works well if your design system components only need to support one app or are inline with the rest of the codebase

hot take #1: in a lot of cases, global state stores are better than react context.

especially if you only have 1 provider instance at the root of your app.

Congratulations!! 🎉🎉

oooh I might have to try that. has always felt like that valley bw beginner and intermediate/advanced sql is especially tricky to cross.

Oh! One more I used a bunch back last time I was interviewing:

- what does success in this role look like to you in 3mo? In 6mo/1y? What would make you say "wow, what an amazing hire"?

Tells you a lot about what the org actually wants and is a little harder to fake.

Lastly, any questions you have about business model, funding state, and future hiring plans

Good luck! Overall, I'd say bias towards asking things that address your own dealbreakers / concerns about the role. Those will feel the most natural to ask.

A couple that come to mind and that I've used in the past:

- How do you as a company decide what work gets prioritized?
- What problems in your company "keep you up at night"?
- How do your eng org balance technical investment with moving the product forward?

"Also, we don't actually test your CSS or HTML during the interview loop. Yes, you'll be using those a lot more day-to-day, but we really just want someone that can scale our app to Google scale." 🫠