I already know I'll never get into a FAANG, so I don't bother looking there. Also, I look at the team photos on startup websites, and if no one looks over 40, I don't bother with that either. Otherwise, it's just down to finding a place that has problems to solve that are hard enough to be interesting.
I've got close to a 100% success rate at take home coding challenges. I usually get pulled in because I'm an Architect that codes, so I ask for an end to end thing to solve.
I'm sorry if I made it sound like I was born perfect. That wasn't what I was trying to convey. Yes, we learn by making mistakes, and I've sure made at least my fair share of them. My point is that horking out algorithms on demand is definitely not the same thing as being a competent software engineer, nor is it particularly predictive of the likelihood of developing those skills. Also, I measure my success by the people I've helped and the impact I have on the business. For instance, figuring out how to eliminate 500,000+ lines of code from a codebase strikes me as way more valuable than hopping about at a whiteboard like a trained monkey. Ask better questions, get more impactful employees.
That sounds way better than stressing people out with inane whiteboard questions. It wouldn't work for me since I won't take a gig that doesn't lock down cash flow for at least six months. I do love take home tests that are directly applicable to the stack I'll be working in. Following up with a code review style interview is great, too. This way more closely emulates the actual engineering workflow of pulling a ticket, cranking, then submitting a PR.
As someone who's worked in over 20 companies as a technical consultant, I mostly agree. However, some companies are better than others at onboarding new engineers. My rule of thumb is to make a meaningful PR within the first week, and do whatever is necessary to make that happen. That sometimes involves bugging the crap out of people with questions, but I try to make up for it with a fast ramp and prodigious output.
Let's also not forget the bias of Indians only hiring other Indians. There's entire product development teams in the Bay area that are close to 100% Indian. Sorry, I don't buy the excuse that's the only people available to hire. How does this relate to competence and the quality of the engineering work product? Race, gender, age, do NOT matter. So, why the pro-Indian bias?
Given HN's demographics, I'm probably older than most here. I've worked with and personally invented quite a few great products, usually spanning Product, UX, and Engineering work. It's a joke to pretend ageism isn't a thing, and asking questions that only a recent CS grad is going to remember is not a tacit form of filtering for age. There's not many technical questions a fairly smart, non-lazy person with some experience can't either find with a Google search, a conversation with a peer, or a bit of hacking to figure it out. It's been a LONG time since I had to write the code to invert a binary tree, but I've done stuff orders of magnitude more tricky and valuable than that countless times, as have many others. What makes a great engineer? I've lost count of how many times I've had to rewrite the code of many engineers who aced the 'whiteboard shuffle', then wrote hopelessly over-complex and unmaintainable garbage. Most of software engineering is not that hard from a 'learn the things or look them up to get stuff done' perspective. What's hard is working well with others and consistently emitting tight, semantic, legible code that's fun to look at and extend.