this x1000 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 t

this x1000 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.