Comment by cl0wnshoes | Hacker News Reader

Comment by cl0wnshoes | Hacker News Reader

I've performed interviews and phone screens for years and out of all the techniques I've tried all of them typically end up with me thinking I'm doing it wrong. Basic domain questions, problem solving, white boarding, white boarding along side the person helping them out, coding in an IDE, take home projects. As of today, in Kansas City, I'm looking at around 4% pass rate, and close to 90% utter face palming failures.

I check my ego at the door, I try to make the person as comfortable as possible, small talk, help them out as much as I can, provide them with answers or explanations when they get something wrong. I've never asked an algorithm or data structure question, I've rarely asked a patterns question. Most people can't answer basic every day questions.

Overtime my goal in interviews turned into making sure the interviewee left with more domain knowledge than when they came in hoping it will help them do better somewhere else.

Ended up creating a pre-screening service that asks the same basic questions and in the end provides the user with a study guide based on how they answered. Currently piloting with two local recruiting companies and I'm finding the same similar statistics of failure/success. Maybe that makes me the issue :)

My numbers were about the same when I was interviewing for JavaScript developers years ago at Travelocity. The only 1 skill I absolutely could not bend on was the ability to walk the DOM. Only 4 out of the 22 people I interviewed could do this and only two of them could do it well.

Strangely enough I warned candidates days before the interview of what I was looking for and still almost nobody bothered to brush up on the couple of basic methods needed to do this 1 task.

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.

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.

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.

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).

Reply on news.ycombinator.com