It sounds like you're trying which is encouraging. I'll give you a few tips that I hope help.

> I adapted the traditional whiteboarding exercise

Lots of engineer types freeze when they have to make a presentation. I remember a meeting early in my career with literally three people in a conference room and I almost had a panic attack. No white board. People I already knew. All I had to to do is explain my ideas to three people. I did improve. I've given many public talks sometimes to hundreds of people and today I like public speaking. But I'll never forget where I started and that the person I'm interviewing might be very nervous. Putting them up on a whiteboard and into presentation mode only amplifies that nervousness. Just talk to people. Get them into that flow that comes from talking about something familiar that they are excited about. For most people a whiteboard test is not exciting. But if you give me a paid take home coding exercise, that's exciting. I like code, and I like to get paid for it. So if you really think you need a test, consider a very high signal test that is the exact work they will be doing.

> I make sure to ask for feedback on the exercise and I've gotten all positive feedback from candidates.

In an unequal relationship like that you are going to get a lot of false positives. If I really needed a job my response would be "loved the exercise, looking forward to talking to you more and discussing next steps if I'm the right candidate".

>Lots of engineer types freeze when they have to make a presentation. I remember a meeting early in my career with literally three people in a conference room and I almost had a panic attack.

That's definitely an unfortunate experience, but isn't giving presentations to explain your ideas - sometimes to people you don't really know - actually a significant part of the job? I'm an IC, and I present designs and project plans for feedback to groups of up to a couple dozen people, or to VPs, on a pretty regular basis. If I couldn't do that competently I would be failing at my job, because that kind of communication is just as important as actually writing the code. If I were conducting an interview and discovered that "public" speaking on the order of a few people in a conference room was extremely difficult for you, I'd probably consider that an important red flag.

What is an IC?

> isn't giving presentations to explain your ideas - sometimes to people you don't really know - actually a significant part of the job?

For many engineering positions it is not. There are loads of shops where the developers, even senior developers, mostly just write code. I have hired many of them and put them to work successfully building stuff while I deal with the meetings.

> If I were conducting an interview and discovered that "public" speaking on the order of a few people in a conference room was extremely difficult for you

And yet I worked very successfully as a junior developer for a couple of years before I ever had to attend a meeting like that. Among the other 100 devs in the shop, I was considered a top talent at coding. That's not to brag but to point out that I was adding lots of value to the company without having to attend meetings with people from other departments. My manager did that. My manager did not code, although he could if he wanted to. In fact at that company they created a separate path for highly talented engineers who wanted to continue coding but wanted to avoid management and meetings. That was a couple of decades ago and less common, but I think it's a lot more common now.

And the fact that I can now publicly speak in front of hundreds of people should hopefully encourage you that it's something people can learn if they want to. Some people don't want to. There are roles for them too.

>What is an IC?

Individual Contributor, used to contrast with "Manager". Point being, my main job is to design systems and write code, but I still have to do some of the organizational stuff sometimes.

>There are loads of shops where the developers, even senior developers, mostly just write code.

Okay, so your experience is different from mine. I'm surprised that there are places where this is really not a meaningful job requirement, and I've never worked at one, but I believe you.

>it's something people can learn if they want to

Sure... but so is coding. Part of the point of an interview is to see what skills and traits you already have. If you're missing some, that can be balanced against the ones you do have - it's not a dealbreaker, but it is still a negative.

>Some people don't want to. There are roles for them too.

Again, not where I work. Engineering, even at relatively junior levels, includes collaboration and explaining your work. You can't just say you don't want to do that - or rather, you can, but you'll have no upward mobility and be managed out pretty quickly.

> What is an IC?

Believe op is using it as "individual contributor"

Isn't there just a bit of condescension in that title? It always sounds to me like something invented by a manager to be dismissive of someone who doesn't manage anyone.

I never got the vibe that "IC" was intended to be dismissive, or intended to be a pejorative or anything. I think it's more of an HR thing, because the distinction between IC vs Manager usually affects compensation and blah, etc. Whether or not that should be the case is a separate question.

I always assumed the term just leaked out of the HR world and into the general parlance.

It depends on the culture setting.

If you're in a place where an IC can potentially make half a million or million dollars a year and drive some very interesting project work and be highly respected, no.

If you're in a place where not making it into manager track puts a very low ceiling on earning potential and respect, then yes it can be condescending.

This varies a lot by country, industry, etc.

I think you're projecting

I've never heard of someone not liking the term "Individual Contributor" before

That’s not the same as on the spot coding challenges in a whiteboard though

You’re right. But what are you trying to prove with on the spot coding challenges? That the candidate can implement a hash table from scratch in 15 minutes with O(1) performance?

Is that something they’re going to do on the job? Very unlikely. So why are you not only testing for it but testing for it in a fake time-pressured stressful situation that also rarely exists on the job? (Yes , we all have deadlines but when are they ever 15 minutes on the spot?)

Perhaps you should have entered the education field where you could give such exams day after day to your heart’s content?

People giving on the spot coding exams, or worse whiteboard coding exams are just assholes. They're trying to haze interviewees and make themselves feel better. There's zero actual utility to such tasks in an interview.

> Lots of engineer types freeze when they have to make a presentation.

I've seen one place that wanted developers to do a full presentation with slides and all to a group of people.

The topic of the presentation was completely up to you, didn't even have to be a technical subject. You could do a presentation on baking if you wanted.

Was doing presentations a part of the job of the developer? No. They wouldn't have to do presentations in their day job...

I didn't go for the job and have never understood what they were looking for.

I do something similar: I ask the candidate to take 30 minutes or so to design a system like an online library. What are the objects in the system, how do they relate, can you design a REST or graphQL API for CRUD operations.

Then if it’s a front-end position we can move onto UI components for it; for back-end or full stack I focus on implement a couple of the CRUD operations.

You really get to see how people think and will work on the job with questions like this.

Implementing a sorting algorithm from scratch is a waste of time in many projects: use your libraries and get on with life. That’s why such interview questions are not important to me.

>> You really get to see how people think and will work on the job with questions like this.

Interviewing is hard and I applaud you for trying something newer and more realistic but I'd be cautious in thinking "spend 30 minutes designing a system and be prepared to defend your work with massive risk/reward hanging in the balance. Begin... NOW!!!!" is representative of how someone will work on the job. There are an awful lot of people who will solve the crux problems driving home after the interview or the next morning in the shower vs. on-demand.

Very true.

I certainly don’t say BEGIN NOW! It’s a conversation. I continually ask questions during the design and ask the candidate to speak about the decisions being made.

In all honesty this process can easily last more than 30 minutes.

This is not a hard problem for someone with the experience I want, and there are many different correct answers.

Agree. Its far more valuable to see how a candidate approaches problems than some memorized recital show. I don't expect perfection, but if their reasoning is sound that becomes clear fairly quickly. I usually also include some imperfect questions purposely to see how they handle that. While we wish client projects were nice and clean with orderly data and tight requirements, the truth is that is rarely the case. It's useful to see how the candidate responds to those types of things. I had one gentleman argue with me about one of those questions claiming you would never see primary and foreign keys between tables not perectly match in the real world. Well when you are matching data from entirely disparate systems, you typically do. Anyway I digress.