When the topic of DSA style interviews comes up, I always see very similar opinions. I was surprised when I finally made it past a DSA interview and was calibrated to see what hiring was like on the other side. I want to provide some steelman arguments justifying leetcode style interviews to give some perspective. I'm not specifically condoning or defending it, but at least sharing reasons why it prevails.

1. Data structure and algorithm style interviews are a way of removing business context from technical problems. The algo-based framing relies on the shared context you are assumed to have as a person working in software. This assumption also helps save time so the interviewer doesn't have to burn time explaining a scenario. Additionally, explaining a deep business scenario can bias the interview towards arbitrary knowledge and can result in over-simplified questions. The goal is to provide a vague technical problem, then observe how the interviewee finds the scope of the problem, breaks it down into smaller problems, then builds up a solution. Usually DSA interviews have multiple parts, with the first being straightforward, and second and third being progressively more difficult. The beginning part is usually not the interview question. It's a way of giving an interactive introduction to the problem. The second part is usually the bulk of the interview, and the third part is a way of stretching the engineering resilience of the previous answers.

2. The context of who's being interviewed. These styles of interviews are most prevalent in big tech, faang-y / mag7 type companies. These companies have a lot of candidates who apply, so they need to spend less time talking to more people. Smaller companies have fewer people, so they can spend more time with fewer people. The big tech companies also pay better than small companies, so smaller companies are competing for less competitive candidates who aren't as prepared for the higher paid jobs. This means that their questions have to be calibrated to the interviewing standards of the population who applies to them. On the other hand, DSA algorithms are a well known interview process... there are books and whole websites dedicated to them. Big companies are relying on an external ecosystem of interview prep.

This justification I think also works the other way -- DSA algorithms are unpleasant to prepare for. However, as an interviewer, I know that I can spend a month prepping, then apply to 10 jobs and have a similar interview experience. That one month is amortized over all those interviews. When I interview at companies which don't do DSA questions, I usually get asked a take home question, a pair programming exercise, or have a lot of conversations about my technical history. The total amount of time I spend on these interviews is way higher, and the salary expectations are less. This time crunch is also important to hiring managers who are trying to finish an interview process as soon as possible if a candidate has multiple exploding offers. They know that they only need an hour for a tech screener and 1 day for an onsite.

1. From a company's perspective, filtering weak candidates is more important than missing good candidates. It's difficult to get rid of people at big companies which require going through a PIP process. Shifting roles is also harder because headcount is managed at a high level and requires approval. And engineers generally have very high access abilities into sensitive systems. If you're a big company that gets 1000s of applicants, then if you miss out on a percentage of good candidates, you'll still find somebody.

2. The weight the DSA algorithm has on a total interview score is different between junior and senior level positions. At junior roles, candidates have limited experience so you can't rely on their resume. At this level, there's a high variability between college grads who have the same amount of intern experience, but one worked on hobby projects since age 7. When you add in hobbyist programmers who come from non-technical backgrounds... it's hard to find a fair way to evaluate people. At higher levels, more emphasis gets places on past experience, leadership questions, and the system design interview. The algo portion is an equalizing bar, but when it's evaluated as a "maybe" against "strong" signals in other parts of the interview, the hiring manager can justify weighing the algo part less. I've also seen this used in reverse. When companies have tighter hiring restrictions, I've found harder questions get asked. Being on the asking side, this has been justified to me that there's a hiring freeze, but we wouldn't want to lose someone excellent.

3. DSA questions can be statistically controlled, and interviewers can be calibrated. Google is very well known for their over-scientific style of interviewing which is unpleasant to sit through. To get 1000s of people trained on interviewing, and to have a pool of candidates you trust hired by one org be able to transfer anywhere in a company requires a standard interview format. The alternative is that a company will have departments pick their own hiring criteria, so depending on who interviews you, it's either easy or hard. The trade off to this is that teams can become tribal, or distrusting of people on other teams because the work quality can be inconsistent. From a hiring manager perspective, they can also look at an interview and benchmark whether the interviewer statistically fails or passes people more than others, allowing you to weigh their performance appropriately.

4. Not a justification... I've met many engineers that are excited to write novel interview questions. The questions I've added have usually come from my daily work when I think "huh... this actually used X algorithm. I bet I could turn this into a question".

5. DSA questions do show up at work. I have used or interacted with many of the standard interview algo problems in real life. The most obvious one for me are tree and graph algorithms, which I find get used a lot: dependency build trees, HTML DOMs, service topology just to name a few use cases. I've seen these algo-y type problems pop up a lot in high scale systems, or complicated data structures.

Again, I don't want to be an apologist or defend it. Each of these points I've found has been abused at companies who forget the point, or get so many interviewees that they don't care. I still get mad when I think about the bitshift questions I've gotten. I also don't think all of these points are true in the real world compared to the ideal they strive for.