Some of the negative points are ideas I haven't come across - but after thinking make sense. "All technologies are good" for example. Having strong opinions about technology usually do come after having experience trying different technologies and discovering which ones work best.
I think one of the biggest negative indicators are around the idea of programming only happens at your job. I get that some people don't have time outside of work, maybe, to build and learn stuff. That's fine. But the devs who do spend their time outside of work building and learning are usually more passionate and growing in their skills etc.
One issue I've come across is not testing interviewees with the actual "stuff" your business does. Who cares about tree traversal? (unless your company really does need that). Take your actual project and put the interviewee into it. Ask them questions about the real code, maybe review a small PRs to test their knowledge. I've found doing that brings out whether the person is actually knowledgable in the stack you are using etc. or not.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some of the negative points are ideas I haven't come across - but after thinking make sense. "All technologies are good" for example. Having strong opinions about technology usually do come after having experience trying different technologies and discovering which ones work best.
I think one of the biggest negative indicators are around the idea of programming only happens at your job. I get that some people don't have time outside of work, maybe, to build and learn stuff. That's fine. But the devs who do spend their time outside of work building and learning are usually more passionate and growing in their skills etc.
One issue I've come across is not testing interviewees with the actual "stuff" your business does. Who cares about tree traversal? (unless your company really does need that). Take your actual project and put the interviewee into it. Ask them questions about the real code, maybe review a small PRs to test their knowledge. I've found doing that brings out whether the person is actually knowledgable in the stack you are using etc. or not.