As someone who has had to conduct technical interviews I have found the best way to evaluate technical skills is to just chat. No tests, no whiteboard challenges, no list of requirements to tick off.
Just let the candidate talk about their career and what they have done. Ask their opinion of certain things. Ask about how they tackled certain projects and give them the time to answer and go off on tangents. Treat it like you are a few friends having an in-depth discussion over drinks.
Technical interviews focus too much on headline points. They want the candidate to touch on or mention certain things that everyone should know about the subject. I'm not interested in that, I'm more interested about them mentioning less obvious things such as known quirks, bugs or tricks about the subject matter. Stuff that only a regular user would learn about.
The problem with this approach is that for many companies HR insists on structured interviews. I once had do some interviews for a couple of C# roles. The interview format was literally the same as the game show Talk About. The interviewee was given time to talk about a subject and we had to tick off a list whether they mentioned certain keywords and phrases in the allotted time. The same format applied to the HR interview. Whoever scored highest got the job, a very silly way to do recruitment.
A conversation on relevant subjects helps filtering out people with fake or stuffed resumes in a matter of minutes, assuming the interviewer is a technical person. It also helps understanding if it's someone we can work with as a colleague. If all goes well, we would make an offer, but will make it clear that the 3 month probation period _is_ the actual interview.
Had very good results with this approach, but it doesn't really scale or work for larger projects with aggressive hiring plans.
It can scale when the company starts to let go of the notion that only senior devs and managers can do interviews.
I was in a growing company that allowed anyone who had been there six months or more to conduct interviews. It massively increased the speed of recruitment and prevented managers and senior devs being tied up with recruitment stuff.
I've done this and then subsequently given a 30 minute coding test. With the coding test I tried to make it match as closely as possible the kind of activities the candidate would actually engage with (e.g. processing a CSV rather than implementing a merge sort).
There wasn't much of a correlation between how well a candidate chatted and how well they coded, and there was some horrendously bad code and terrible habits exhibited by people who talked the talk pretty well.
Conversely, some of the less verbose people wrote excellent code and were often cheaper - possibly because they didn't interview well.
The downside of this approach is that crafting (and iterating upon) a realistic test that exercises all the necessary skills and can be squeezed into 30 minutes is hard work.
I totally agree with this. The best interviews I've had with candidates have gone like this, and not only do you get a feel for their knowledge in a subject in a more relaxed way it also gives you a bit of a feeling if this person would fit in the team or not.
Being on the other side of the table, interviews done this way has landed me in my most interesting/best jobs, and in the best teams, in my opinion.
I've done maybe 100+ tech interviews, easily. The ones that have been the best have been conversation based. The worst are take home projects that take days to complete. (the worst I had: create a poker game)
A good inbetween can be try-before-you-buy for a day or two, but if the scope of work isn't managed correctly you may not see what you want. I had that happen recently in an interview - i asked what success looked like (being communicative on the work to be done) but at the end was told they didn't see enough front-end work.
If you can't tell within 30 minutes of talking to someone whether they are competent or not, you shouldn't be doing the hiring.
Likewise, if you can't express yourself in a casual setting - what kind of person are you to work with? How will you handle disagreements or feedback? What will you offer the team?
Lastly, if they have OSS work, take a look at it. If they have contributed to an OSS project, take a look at their PR and how they worked with the main devs to get it merged in. That is a much stronger indicator to skill and quality than a random coding exercise.
Not very easy to accomplish, from the company perspective. You have to have contracts, NDAs, and a whole bunch of stuff in place, even if the person is gonna only work for a couple of days, or for a week.
This is a legal problem for large, stupid slow companies. The beauty of tests is they're hard to sue over.
I used to do this for a multi-national tech conglomerate. Everyone else did technical interviews. I gave a laughably easy tech test (few binary operators). If you mentioned a technology I knew well on your resume I asked you a question about that.
After that, "Tell me about your favorite book, author, movie, album, musician, hobby, magazine. Anything. There's no wrong answer." Just to get a conversation going. I had a number of questions like this. The point was to get them talking.
The most memorable was a Bukowski fan. We talked about his novels and the employer happened to be just a mile from where some of the scenes were set. It was cool because the guy lit UP when he got to talk about it.
The guy who made the worst impression said Freebird was the only thing he could think of, and the last album he could remember buying... when it came out... in 1973...
I observed no correlation between test results and whether the person turned out to be a good hire.
There was also an inverse correlation between competency and "gotcha" questions. One of our least competent engineers was vicious and mean-spirited during interviews. In the 100 or so interviews we did together, the only person he ever liked was his friend. Ironically I fought hard against hiring the interviewer himself but was explicitly instructed that we were seeking "moderately competent" individuals for his role.
Then HR found out about it somehow and forbade me from asking "personal questions" because we "might get sued." I had to stick to a script.
So I quit giving interviews, and we hired people who were good test takers from then on.
It requires experienced and technically competent interviewers though. Ideally someone who is more than qualified for the job. In other words, experts.
And sometimes, experts are not available. Either because the only expert is the person you want to hire, or because of a strong divide between HR and technical people.
I am not a chatty person - crippling social anxiety sees to that - and I would much prefer this kind of informal chat to a "real" interview because it removes a lot of the pressure which then helps to alleviate the anxiety enough to show that I know what I'm talking about.
If you can't express your competency during an interview chat I don't see how you could be a good candidate (there are exceptions), nothing more damaging to a team that someone who can't communicate.
How about shy people who have a hard time talking to new people? Who only feel comfortable after a couple of days and then they become very chatty? Aren't most developers like that?
Not significantly more than among the population in general, at least not in my experience.
Being able to simulate extroversion for short periods at need is a useful life skill for any introvert - I've found it invaluable in plenty of situations beyond just job interviews.
No necessarily competent. It could be that they are well read on the subject but have no practical experience in it. So they seem able to converse in the subject's vocabulary but if they were to sit down and try to make something they would fail.
Just let the candidate talk about their career and what they have done. Ask their opinion of certain things. Ask about how they tackled certain projects and give them the time to answer and go off on tangents. Treat it like you are a few friends having an in-depth discussion over drinks.
Technical interviews focus too much on headline points. They want the candidate to touch on or mention certain things that everyone should know about the subject. I'm not interested in that, I'm more interested about them mentioning less obvious things such as known quirks, bugs or tricks about the subject matter. Stuff that only a regular user would learn about.
The problem with this approach is that for many companies HR insists on structured interviews. I once had do some interviews for a couple of C# roles. The interview format was literally the same as the game show Talk About. The interviewee was given time to talk about a subject and we had to tick off a list whether they mentioned certain keywords and phrases in the allotted time. The same format applied to the HR interview. Whoever scored highest got the job, a very silly way to do recruitment.