Talk to the candidate. If you (and the candidate) cannot communicate well enough in 30 minutes to discover that then either (a) you don't know enough to work well with a really good developer or (b) the developer doesn't know enough to work with you or (c) both are true.
I have never been let down by this rule, either as a candidate or an interviewer. In my experience coding exercises as part of an interview process are a big red flag to me indicating the company is trying to compensate for lack of in-house talent with process or they are trying to replace someone with a certain hard-to-find skillset because they have an immediate fire they are trying to put out. Neither situation is a good one to get into.
Trust me when I say I've talked to plenty of candidates who I thought were great only to learn they couldn't actually code fizzbuzz. Talking to candidates doesn't work.
You want programmers to do tricks and silly initiation dances which is your whole problem. If you actually asked real questions about their experience then you’d get a good grounding. I might do silly problems for a high profile employer but that’s likely not you. In which case if I tell you to stop wasting my time and walk out of your attempted initiation ritual then you won’t like it.
You might not be good at judging candidates. A good cto uses their gut and experience. An inexperienced or someone who doesn't have the gut uses tricks. Where do you fit?
Have you taken any courses or worked with professionals to help you with this?
There are people who genuinely believe they are good at their job, when they're not. They're not bullshitting and the conversation is genuine.
Just 10 minutes of coding (or attempting to), tells you they can't code. A little longer can tell you roughly how good they are.
Experienced developers who can code have had the misfortune of working with people who couldn't pass this, and may appreciate that the members of their new team can.
My favorite because of how realistic it is, is have me/the candidate do a code review. It's a real world thing that will be a part of most jobs that doesn't require artificial nonsense like coding in a browser, memorizable hacker rank crap, or some throw away time wasting coding challenge. As for if I can code, I have seven public github repos, 3 of which are previous take home challenges of varying degrees of absurdity.
I said this elsewhere but reviewing previous projects or doing a code review does help somewhat, but it leaves out my ability to see your actual coding skill re: speed. I need to get a sense of that in order to feel comfortable hiring you. The only way I can do that is if you do some live coding one way or another. How you do it at our company is entirely up to you.
With our salaries, we have yet to have anyone turn us down when we get to that stage of the interview, but maybe someday it'll happen.
Sorry, but neither of those things show me that you know how to code. I don't know how long it took you to write your projects so you may be very slow and a terrible coder. Technical questions you may have prepped from a book. I need to see active coding, either live, in person, over zoom, or time boxed in a take home. We'll even compensate you for your time. But I need to see you actually working and review your work. Sorry.
Quite frankly, relying upon such things is a sure-fire way to make sure some bad developers get through the cracks.
No need to be sorry, I wouldn't apply to your company, and you would be lucky to even get a reply from me if contacting me on the typical social networks for developers.
What red flags did you see? That we pay top of market? That we work to have a low stress environment? That we put life before work instead of work before life? That we prioritize having the best benefits on the market, including platinum health care with $0 employee contribution and full mental health coverage for therapy and medication not covered through insurance? That we don't overload our top performers by giving them more work when they overperform but instead let them take the extra time off? Which of those is a red flag? Everyone at our company is very happy. Apparently some people don't like coding exercises. That's fine. We require people to demonstrate they can code. Everyone at the company has to go through that. We'll miss out on some candidates because of that, but I'd much rather miss a few candidates than have some false positives. I'm sorry that ruffles some feathers. We honestly strive to have the best work environment possible for engineers based upon my many years of being abused, overworked, and having to go through absolutely horrible, long, miserable interview processes. We do 1-2 interviews and ask you to code a little. I don't think that's unreasonable, especially considering all of the benefits on the other side.
All of these are policies I've worked hard to implement to create the absolute best environment in the world for my engineers to thrive. I've had to fight for them since they aren't cheap. It hurts me when someone says taking an hour out of their week to do a coding interview isn't worth it when I've taken dozens to hundreds out of mine to make their job as easy and enjoyable when they get accepted into our culture. It's insulting to me to say that asking for an hour of your time is not worth everything above and much more that I've strived for to make our company a fantastic place to work at.
So, like I said, what red flags did you see exactly?
Tell us who you are and what your company is. You truly sound like a terrible employer based on your shocking responses. You came here to ask for feedback and then when you got it you didn't like it. You are clearly the issue of why you can't hire developers. I'd wish you good luck but I won't.
If someone asks for it, we pay for their time. And we offer to get a sense of how they can code however they want. Take home, virtual pair coding, in-officce pair coding or coding exercises, whatever you want. We just need to see you code in a timeboxed way so we can see how you solve problems and see the results to make sure you write readable, maintainable code.
Almost everyone picks take home. Like, over 95%. I'm not sure why people here are complaining about it except that the accounts that are were made 2021+ so maybe it's a generational thing.
I have never been let down by this rule, either as a candidate or an interviewer. In my experience coding exercises as part of an interview process are a big red flag to me indicating the company is trying to compensate for lack of in-house talent with process or they are trying to replace someone with a certain hard-to-find skillset because they have an immediate fire they are trying to put out. Neither situation is a good one to get into.