[ubernostrum]

You know the quote: if you encounter an asshole first thing in the morning, you encountered an asshole. If you encounter assholes constantly all day long, it's probable you're the one who's the asshole.

If you have a 90% rate of "utter face palming failures", the problem isn't with the people you're interviewing, it's with the interviewer and/or the interviewing process.

[cl0wnshoes]

That's what I keep questioning and why I've tried various methods. After screening resumes along with coworkers, at various companies I've worked at, we'll pre-screen or not, bring them in and ask them questions from their resume.

Resume says 'I'm an expert in SQL'. Great, lets start some every day foundational questions. What is the difference between an inner join and an outer join. Why might we use a varchar instead of a char data type? Why do we use indexes? What is the purpose of a foreign key? A good majority of the candidates can only answer the join question.

'10 years experience, senior dev in <main language>' can you write a function that returns the largest number in an unsorted array? Most struggle to even pseudo code it. Tell me something, anything about interfaces. Basic security question on SQL injection/xss/csrf/hashing/encryption. Without a doubt most have only heard of SQL injection and then they get that wrong. Most say hashing and encryption are the same thing.

I do blame myself, the failure rates are incredibly high. But when resumes looks great and onsite can't pseudo code a simple loop, or answer basic questions about something they claim expertise in, what can you do? Require and call references to make sure the the lead dev with 12 years experience and decent companies isn't lying? Because the result of most of my interviews appears that people inflate their resumes and flat out lie.

[ubernostrum]

So let me ask you an "easy" question: for your interview questions, are you consistent in what you ask, and do you have a consistent approach to evaluating a candidate's response?

I ask this because some of your "foundational" questions are not as simple as you might think (I could talk for literally hours about XSS and the only conclusion I could give you would be "there's no sure-fire way to prevent it", for example), and others border on pop-quiz material, which is not really a great way to evaluate someone.

Another question that's important to ask: you say you're working with recruiting companies. Have you tried not doing that? Recruiting companies don't exist to find you qualified people, they exist to spam you with résumés. Recruiting companies have been known to flat-out alter résumés to make them better match the set of keywords you said you wanted. And my own experience is that recruiting companies are the source of a huge percentage of headaches in hiring. Cutting out the middlemen can and likely will drastically increase your success rate.

[cl0wnshoes]

I try to be consistent with my questions, but it depends on how well the candidate is answering them as to the depth I go into a subject. Generally I ask the candidates about previous projects and work my questions into the conversations. It usually isn't a rapid fire pop-quiz type interview.

Tell me about a project you had the most fun working on. You tell me you started working on a SPA in Angular 2 and I ask if you've heard of some common attacks like XSS or CSRF. You say yes to both and I ask if you had any preventive measures in place or how you would go about trying to prevent them (I'd stop you if you kept going on and on). We'll work our way through the projects stack best we can in the same manner.

We generally used recruiters at all the companies I worked at due to lack of applications. I agree they're part of the issue. I also phone screen for recruiters so at least some of them are doing their due diligence (no idea how they act on my reviews though).