>I see this argument all the time, but I can't find any other place that it comes from other than disappointment from those that didn't or can't pass those interviews.
I have passed these interviews. Had offers from multiple FAANGs, worked at G. The algorithms interview is idiotic. It is a way for them to gate the jobs to people who have CS degrees while being able to say they do not require CS degrees.
I rarely come to the to the optimal solution on my own for a leetcode problem. It is about learning the techniques so you know how to speak about the solutions, then basically learning (by reading) the right answers to different problem types.
This isn't from being hurt, I pass these interviews. I've worked there. It is a horrible selection criteria for what you actually do at the jobs - design docs, meetings, tickets, tests, and code reviews. It creates a ton of false expectations too, you do not need to know advanced algorithms to work on some internal user interface, close maintenance tickets, or to write 10 lines of test code for a 2 line change. You get in there and realize none of the work you are doing is as clever as the interview.
The tasks described above are the reality of working in a large organization. They shouldn't be, but they are. The interview should more closely match that.
That's a great perspective, thanks for sharing that. What would you like to see as the best interview questions then? I'll probably adapt my future interviews based on your ideas (not that I ask any real algorithm questions anyway).
Use them to measure how well people will perform in the tasks that you need them to do. For coding interviews, Square's is really good. [1] I am not sure if they have sample questions written anywhere in the linked blog posts, but very simple things with added complexity.
Example - Write a rate limiter that takes in a timestamp (integer) and returns true if it hasn't hit a rate limit. Ok, now what if we make the rate limiter per user. Just simple things to see how you represent data, store it, create interfaces to it, and how you refactor to deal with change.
Most likely, you want to be having someone write tests for some code and review some code. Then speak to them about their experience. Depends on your organization though, maybe you are small and people need to produce a lot more than the large tech companies.
I have passed these interviews. Had offers from multiple FAANGs, worked at G. The algorithms interview is idiotic. It is a way for them to gate the jobs to people who have CS degrees while being able to say they do not require CS degrees.
I rarely come to the to the optimal solution on my own for a leetcode problem. It is about learning the techniques so you know how to speak about the solutions, then basically learning (by reading) the right answers to different problem types.
This isn't from being hurt, I pass these interviews. I've worked there. It is a horrible selection criteria for what you actually do at the jobs - design docs, meetings, tickets, tests, and code reviews. It creates a ton of false expectations too, you do not need to know advanced algorithms to work on some internal user interface, close maintenance tickets, or to write 10 lines of test code for a 2 line change. You get in there and realize none of the work you are doing is as clever as the interview.
The tasks described above are the reality of working in a large organization. They shouldn't be, but they are. The interview should more closely match that.