>Anecdotally: I've bombed interviews myself! Sometimes due to anxiety
I used to get pulled in on anxious candidates to help make a final decision. Interviews are rarely an environment were a person does its best work. Experienced interviewers know this.
Typically, I didn't make them code. Coding and anxiety don't mix well.
I usually approached the interview with roughly the following structure:
- Reduce anxiety
- Work on a problem (figure out how it is to work together)
- Reverse interview
To reduce anxiety, what has worked for me is basically making them feel in control. I first make them talk about themselves (i.e. something they know), and then I try to find a passion, something they feel strongly about, related to a project they did (hobby, uni, whatever).
Have them walk me through it (still something they know and control the narrative on, and also something they care about).
I hear actively and engage with them. I'm non judgmental and positive about whatever they tell me.
At this point most people feel at ease.
Then I present a simple, open ended design problem, no code required, but I may probe for specific knowledge here on DB, distributed systems, concurrency, probability, security, whatever I'm looking for. Usually as a discussion of some sub-topic in the design.
I make it clear at the beginning, that I don't care much about the solution and more about the process. Picture us working together working on this problem, this is what I'm trying to figure out. How is it to work with you, and hopefully you'll figure out how is it to work with me.
Then I typically close with an interview reversal, I give them a chance to ask me anything and I answer truthfully so they can assess if they would really like to work here.
This has worked well for me, but I'm an extrovert, so the putting you at ease part is relatively easy for me (it's emotionally exhausting sometimes).
>specially if you are interviewing 200 people - you are wasting SO MUCH TIME. I simply can't believe that you're actually getting that 1 in 200 dev. Why?
Most of the 200 don't pass basic screening, 30 will do a simple code screening, maybe 10 will get to an actual interview. Then one or two of those will get hired.
>But there are a lot of devs who are very smart, but very lazy or toxic.
We care a lot about this, we've passed on really smart candidates with lots of experience because we thought:
- they wouldn't be happy working with us
- they were hard to work with
BTW we measure post-interview experience, whether you got hired or not, to improve our interview process and assess interviewer performance, we might pull somebody from the interviewer pool if they perform poorly at it.
>a standardized exam and license
I really don't think it will change anything. You have a CS degree, I will still make you code a bit.
In any case, hiring requires many signals. Coding is just one, there are many others at play that can make or break a hire.
Also, the company moment matters: are we risk averse at this point? A startup usually would rather lose a good candidate than hire a bad one, larger companies can take more risk, and give you time to prove yourself.