TBH only the third tells me anything useful about a dev in the "heat" of the moment of an interview (very heavy emphasis on the quotes, I'll get to that in a moment). I do not do live code or whiteboarding exercises, nor terminology quizzing, period.
Why? Because here's what I've learned from them: That devs fresh out of CS degree programs and boot camps - and job hoppers - tend to do much better than those who actually solve real world problems every day.
Perhaps even worse is what I'm conveying to the candidate about myself and the company, no matter how unintentionally or inaccurately, by putting them in such situations: That they are expected to work under undue, on-the-spot pressure, caused by me or someone else above them in the company, and that they're "free" to solve the problem in their own way... But we're watching at all times.
That's bunk, and it stifles creative ingenuity from the very start.
So what works?
Conversational, experiential interview, with as little initial Q (as in Q&A) from my side, waiting until what they said merits a question. The more experienced they are, the more it becomes about trading war stories. Give them the lay of the land, and make them feel comfortable with speaking to it and offering suggestions. And of course answer their questions readily.
Take-home challenge, with ample time to finish it in their spare time, an hour here and there (and obviously, I hope, not spending too many hours on it - but not in a timed sense).
Second technical interview, code review format. Make them justify their decisions, even if they lifted parts from GitHub, SO, etc. Don't nitpick, save (constructive) critiques for the end.
Why does this work for me, and why do I think companies should adopt it themselves and finally get rid of the live code interview? I already covered why pressure doesn't work (no matter how many times you say "no pressure"). The key to this is letting them relax. Not only do they feel more comfortable to create, to take chances, and more importantly to reason about solutions in their own way... It's also a lot easier to detect BS when a person is relaxed, while even the best candidates can crumble under pressure when they know it's their only shot.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
TBH only the third tells me anything useful about a dev in the "heat" of the moment of an interview (very heavy emphasis on the quotes, I'll get to that in a moment). I do not do live code or whiteboarding exercises, nor terminology quizzing, period.
Why? Because here's what I've learned from them: That devs fresh out of CS degree programs and boot camps - and job hoppers - tend to do much better than those who actually solve real world problems every day.
Perhaps even worse is what I'm conveying to the candidate about myself and the company, no matter how unintentionally or inaccurately, by putting them in such situations: That they are expected to work under undue, on-the-spot pressure, caused by me or someone else above them in the company, and that they're "free" to solve the problem in their own way... But we're watching at all times.
That's bunk, and it stifles creative ingenuity from the very start.
So what works?
Why does this work for me, and why do I think companies should adopt it themselves and finally get rid of the live code interview? I already covered why pressure doesn't work (no matter how many times you say "no pressure"). The key to this is letting them relax. Not only do they feel more comfortable to create, to take chances, and more importantly to reason about solutions in their own way... It's also a lot easier to detect BS when a person is relaxed, while even the best candidates can crumble under pressure when they know it's their only shot.