I am not the GP and I mean no disrespect to you. Your below phrasing seems presumptuous to me -
>>..someone who can answer the leet code questions easily (and has been able to for a decade)...
If you are a CTO chances are you have not been practicing LC. Even if you were able to do LC style questions a decade ago, without practice you are very likely to struggle with them. So don't assume just because you are CTO / architect you can do LC style questions. The questions have been becoming progressively harder each year. It is a sad reality, our industry does not decide compensation based on experience, knowledge and actual skill used on the job. If you want to maximize your compensation you have to do LC style questions. Even non FAANG companies ask LC style questions these days.
I actually agree with you. You have a point. I would probably practice Leet Code or similar before I went back into the interview world just to freshen up.
Though, with that said, I have been on the interviewer side a lot and need to know some of them well enough to know if the candidate knows their stuff. So I'm not completely rusty. And as CTO I would often read through what other companies are asking in interviews to make sure what I'm asking is in line.
My objection was the implication that not crunching Leet Code problems was the sole reason for the low compensation.
But you are right. I should not assume because at one point I knew all those algorithms that I can still explain them under pressure of an interview.
Maybe you didn't mean to use that word but it's not about "explaining" them: you have to be able to write the code to solve a given problem, on the spot. The problem might require a familiar technique such as breadth-first search but it will need to be adapted; the problem is likely to be slightly different from anything you've seen before.
It's true that at the staff interviews i just did, LC was not required but at the staff interviews i'm about to do they will be.
I meant explain. I see explain as a superset of implement. I have met lots of people who can implement but not explain. I didn't mean a simple explanation, I mean actually going into depth about things like algorithmic complexity, memory usage, etc.
As an interviewer (granted not at FAANG) I see no value in you just proving you did an algorithm on Leet Code. You could just be passing it through rote learning. I want to make sure you understand it. Otherwise I'm just wasting your time. But that's just my interview style, I know bigger companies may be different.
> I mean actually going into depth about things like algorithmic complexity, memory usage
OK, I agree that's definitely something the candidate should be able to do. I'm just trying to point out to anyone reading that it won't be sufficient to explain an algorithm. You have to actually write code to solve a given problem. That's not the same as regurgitating code you remember from leetcode, so please don't think that. You have to apply techniques that you've learned. It's not easy, and it's not intellectually shallow.
>>..someone who can answer the leet code questions easily (and has been able to for a decade)...
If you are a CTO chances are you have not been practicing LC. Even if you were able to do LC style questions a decade ago, without practice you are very likely to struggle with them. So don't assume just because you are CTO / architect you can do LC style questions. The questions have been becoming progressively harder each year. It is a sad reality, our industry does not decide compensation based on experience, knowledge and actual skill used on the job. If you want to maximize your compensation you have to do LC style questions. Even non FAANG companies ask LC style questions these days.