Two things. First: > If you were the one doing the interview, would you be strict and request more things so as to filter out candidates? It’s understandable

Two things. First: > If you were the one doing the interview, would you be strict and request more things so as to filter out candidates? It’s understandable because somehow you need to find the best ones for a given position, but there are some soft skills that C/Java/Python interview problems can’t identify. I have interviewed many candidates. I generally gave three rankings to the hiring manager - pass, minimally acceptable and very good should follow up. Candidates tend to be a Gaussian curve with a normal distribution - if their resume looks good and they have been doing the job for at least two years and they pass a simple phone screen, the bulk (two thirds) follow into the minimally acceptable category. They know the basics and obviously have been doing it, but their knowledge can be spotty, and probing in depth almost never has results. Maybe one in six slip through the initial filters of resume and phone screen and show up at an interview knowing next to nothing. On the other end is the other side of the standard deviation - someone whose knowledge has few if any blank spots, and who can answer questions in depth. I've found I can usually tell if they don't fit into the successful group in the first three questions. I have never had someone who flubbed the first three questions come back and answer subsequent questions correctly and in depth. Of course having a recommendation internally helps. People I have deemed minimally acceptable who have been vouched for by a teammate have been hired. If they're coming in cold, they have to be in that one in six, one standard deviation above group who have some grasp of almost every subject you should know, and can go into depth on a lot of things. So from your view being interviewed, it is pass/fail. From my view, I am looking at six people, one obviously bad, four interchangeable who have slightly spotty and not in-depth knowledge, and one who shoots the lights out and can go in-depth on a number of subjects. The last one I pass I bring to the attention of the hiring manager, the others I say they're minimally OK, with the occasional pass. Sometimes they're doing great technically but I know the manager will pass on them because they won't like they're attitude, but I pass on them anyway. Once me and someone else interviewed someone who passed the tech interview, but their behavior in the interview was odd and we both agreed to not pass them on. Secondly: > Is it my idea or are interviews more harder nowadays? Interviewing can be hard. I've been asked to show Github projects (as my IP assignment agreement might assign copyright of off-hours work to the company, I don't have a lot of motivation to do these), do work samples over a few nights, do 30-60 minutes Leetcode interviews in different languages, with a framework or without, to look at code, fix bugs, and check the code in to git, to whiteboard high level class design, to answer programming questions, language questions, framework questions, popular 3rd party framework extension questions, questions about how I deal with product managers etc. I hear FAANG grills you on graph theory depth first search and things like that which I haven't implemented from scratch since college (at work I'm usually doing CRUD or sometimes UI stuff, anything more complicated I am usually doing on my own time). It's a lot to work a job and keep on top of these things. I have been diving into learning some language-specific things in the past two years, and things which you can find across languages to some extent. I have done a little bit in learning the newer framework things coming out, or going more into depth on things I needed to know. If I was gearing up to interview I would probably put these things aside and learn how to Leetcode better and that sort of thing. Most of what I study can probably help me find work, but if I shifted what I was doing into learning how to do Leetcode quickly, correctly and compactly, that would probably help more. Things like that.