PainfullyNormal

I'm also interested in this, but I'm more interested in what you need to say and do to convince other people you're an expert.

> everything else frontend is pretty much resolved

Has it? The technologies will change again. Pretty soon, if I have to guess. What's valuable here are the concepts that are universally applicable and have been since it was called client programming in the 70s: state management, rendering, API integrations, architecture.

What are you talking about?

This happens at the end of every hype cycle. People are dissatisfied, everybody is looking for the next big thing, and a bunch of people and companies throw spaghetti against the wall to see what sticks. A winner will eventually emerge, but it can take some time. A good example from the last generation: who remembers OpenLaszlo or YUI?

> No control freaks - especially in leads & managers

How do you test for that during the interview process?

We had stuff like that all over the place in the last React codebase I worked on. Naming things is hard, especially when you have to name them four times: once for the hook, once for the function that can potentially be called outside of the hook (non-react code), once for the API call, and once again for the graphql query.

Oh, awesome. Thanks!

I doubt that was the deal breaker. I always question the company's business model in the interview. If they can't defend their business model to an applicant, how can they possibly do so to investors, customers, and/or other companies looking to make strategic partnerships? Their due diligence is far more severe than mine (or the author's).

I asked the question because it's not the first time I've heard something similar to "learn to talk like other staff engineers". I've heard it a few times, I've read/heard other people being told some variation of it, and it even shows up in the Staff Engineer book by Will Larson. I was hoping to get more insight from people either hiring Staff engineers or other Staff engineers themselves.

> You will need to run a ARM Linux VM on the Macintosh - even on ARM-based Macs. Why? Apple. That's why.

I'm going to need a better answer than that. The whole reason I want to learn ARM is to get closer to the machine I'm actually using, not to get closer to a linux virtual machine that I will never use again running on the machine I'm actually using.

What you're describing applies to all jobs everywhere, including junior and non-technical positions. Nobody hires strictly on technical expertise.

> She wrote that she assessed that I don't talk like their staff engineers.

I've heard this from other people, too. Is talking the talk really this important to employers looking to hire staff engineers? And if it is, why?

How?

They don't seem to have much in the way of clients. For example, they currently only have 4 active "missions" in web development.

Win the lottery and become a 10x dev and maybe he'll dream about it.