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.
You should be able to offer solutions to problems impromptu. You should be dependeable in a wider-group meeting involving business or other competencies to represent what does the frontend say about it.
This means having knowledge and experience to offer solutions without googling.
Beyond that, you also need to be on top of the latest (not the newest) standards to follow. You need to stay up-to-date and filter through the waterfall of sh*t trends in the industry, to know what's actually relevant.
While doing all of that, you need to maintain your past/fundamental knowledge...nitty gritty details, to help your colleagues.
You need to do all of this while (most likely) being representative spokesperson/front for a frontend project at your day job.
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?
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.
> 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.
No, it can't -- QEMU's usermode emulator translates Linux-to-Linux only, it does not let you run Linux binaries on macos. And since it's an emulator it's arguably taking you even further from the bare metal than running a VM, which (assuming hypervisor.framework or equivalent) is at least executing the guest instructions directly on the real CPU.
I'd say that for senior positions generally companies are looking for qualities that go beyond technical expertise (where in coding or something else). This includes communication skills, poise, etc.
That's true but the more senior the position, the truer it is. If a new grad or candidate for a junior position seems to have the skills for an internally-facing position, I'm more likely to overlook some social awkwardness or so-so communication skills than in someone more senior.
In this particular case I guess questioning the business model of the company by bringing some controversy on the first interaction wasn't very strategic. Maybe the staff engineers they have hired don't do that!
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.
Author here. I do hire staff engineers these days. A few points:
1. Spotify is a Swedish company with a strong brand identity. Conformity culture is a bit strong, so I can totally understand why they would want "someone like us" than someone who would ask the challenging questions. That's my take on that interaction but maybe I didn't write it well. I edited the article a bit.
2. Staff is a leadership position and like other leadership roles, the impact of your personal belief will not stay at the individual level but rather spread. A positive attitude pays dividents. In that particular example, I went in with negative prejudice. The right interaction would be to have an objective argument and share their view as someone who bought into it and is working at the company. The least they could do is to use that as an opportunity to set the record straight. At least that is what I do if a candidate asks the hard questions. I don't have to convince them, but I'll do my best to honestly answer it and quite frankly maybe I learn something about the company I'm presenting that I didn't know.
> 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.