And yet, the engineering interviews still typically revolve around Leetcode algorithms instead of the messy but hardly CS-intensive day to day work that engineering typically involves.
I will politely decline any opportunity that requires me to do multiple code and architecture tests and several other lengthy meetings, usually spread out over the course of months, because it’s not worth my time to jump through so many hoops. It signals to me that there is already a tendency to implement process for the sake of process.
What will really sell me on a company is a more in depth conversation with the leadership and the team where we learn more about what we value and how we like to operate. And that’s how I would interview anyone who was referred by someone I trust.
In a productive day as a solo dev, hitting keys on my keyboard is the easiest part, the hardest part is thinking about a problem in front of my notepad, usually staring out my living room window or while taking a shower.
I'm being a little pedantic, but it's a meaningful distinction because marketing yourself to a HR department is a skill to be worked at for some.
That's a lot of money over the span of even a few years to miss out on.
Lots of companies feel they need weed-out questions because they're swamped with applicants. How does applicant approach a problem? Does applicant describe their thought process figuring it out? Can applicant figure it out?
Did that tell anyone how good the applicant is at the job? No. It just provided some gates for the interviewer to say "no hire."
It's hard to differentiate the applicants' skills so early in their careers - not enough work history to go on. I have no idea why these would be used for senior positions except that "senior" is this year's "junior."