I kinda agree with you that it doesn't make sense much of the time if you have to specifically prepare for the coding interview; stuff you may never use in your job. But its not a lot of stuff: I bit the bullet and spent some time solving those questions and now can make past mostly any screen.
Its really not that hard, especially if you have a CS degree. Probably would take 1 week of dedicated effort to get better at it.
It sounds to me like a way to weed out pesky applicants who have families or who are simply older.
People usually trust their own assessment of a candidate much more than that of others. While your projects might help generate interest in you and get you an interview, the actual interview process is meant to be an assessment by the Company conducting the interview. So you shouldn't automatically assume you have the jobs simply based on your past projects alone. I'm not saying I necessarily agree with how this works; I am simply pointing out why it works that way.
> It sounds to me like a way to weed out pesky applicants who have families or who are simply older.
Perhaps. It seems unlikely since many of the senior developers/hiring managers at most mature companies are older and have families.
That's insane. If you brought me in because you liked what's on my resume, your number one priority should be determining if I really did what I said I did. Your priority shouldn't be arbitrary, unrelated questions or coding challenges pulled off some website.
I'm not aware of any other industry that behaves like this.
There generally is a component where you're asked about your past projects in detail. Its just not the only component.
The last time I had a proper algorithmic problem, I was in an academic institute and we had a guy researching algorithms so I asked him (though he didn't come up with mush). It was basically a variation the stable roommates problem. I came up with a solution - brute force plus a load of optimization and it worked well enough for the purpose.
When I get that crap in interviews some of the time I get the answer, some of the time I don't. Its pot luck. Its says very little about my skill for the jobs I am applying for. Ironically I was way better at answering those things 15 years ago when I was fairly crap at building reliable robust systems.
The success resulted from deep research and much trial & error. It was no magical "algorithmic skillset" that they expect in those type of interviews (I wonder if those are even a good filter for actual production algos).
Here is my simple write-up of SRP: https://medium.com/@rambossa/stable-matching-algorithm-and-h...
"Find all the subsets in a set that add up to sum" -- "Okay for this we will use the sliding window technique and here is how it is done" -- WTF is this. I get that they want to see problem-solving skills, but this is on a different level requiring the interviewee to have studied and knowledge of the technique, otherwise we are basically trying to develop efficient algorithms from scratch and in little time. --This makes sense for college interviewees who have only studied the past 4 years, but for a professional with experience why is this adequate??