Earlier quoted context omitted.
We do a fizzbuzz-like question, but one we created ourselves so it's not easily google-able or memorizable. Anyone with basic coding chops should be able to solve it; it would be equivalent to a CS101 quiz. It is still shocking how many people fail it. Yes, we have to test for it. My wife is in digital marketing, her -boss-, who insists on being involved in every decision, and will override her knowledgeable subordin…
I wonder what would happen if you asked those that failed the fizzbuzz question what they DID know and wanted to demonstrate. The idea that there are flat out imposters who cannot code that have held coding jobs for more than a few months is ridiculous. Right out of college with no experience, I understand. Have you considered that: 1. People have imposter syndrome, all the time. They're stressed out about being able…
You just negated your entire point there.
Yeah, you can have a bad day. I get it. We all fail interviews; I certainly have. Some I feel we really weren't a match (they were looking for a kind of developer that I wasn't, and don't want, to be), others I felt were unfair (for instance, interviewing with Microsoft years back, I had a C/C++ interviewer asking me questions that I had been told I was allowed to write in Java, and then disbelieving me when I told him (String).length is constant time so it didn't affect the Big O complexity that I had 'for (int i=0;iWe first give people a take home. It's at their own convenience, we tell them it will be an hour and a half, coding, simple questions, to do it at a time they're comfortable. We don't stay on the phone, we tell them to use whatever resources they want (except, obviously, please don't try and google for the answers directly, or get help from others; it's simple enough that those who have tried to cheat have ended up with it being hilariously obvious, like leaving source comments that said it was by someone else, or variables for 'cat' when we never asked for anything related to cats, or being caught out during the whiteboard).
The interview is mostly a conversation. It starts with conversation. We talk about the position, the company. We ask about what the candidate is looking for, their resume, that sort of thing. Only after thirty minutes or so do we get to anything technical. We ask a few questions, and they're intended to be placeholders for conversation; plenty of right answers, we mostly want to see that the person is knowledgeable enough to discuss things. Even when we get to questions that have a right answer, it's mostly to gauge knowledge, and for the more complicated, even if a person gets it wrong, we'll tell them what the right answer is, and then ask them for a rational as to why. If they can figure out the rational, that's just as good as having known in the first place. Then we have a whiteboard question. It, too, is not hard. We tell the candidate "If you think there's a library function that will help, but you just don't remember it, you'd need to Google it, that sort of thing, talk it out with us, we'll give it to you". We try to help suggest things to get candidates unstuck. Etc.
Really, it's -not- a particularly antagonistic process. We really, really do want people to succeed (because, frankly, we want the position filled so we can stop interviewing and go back to work). So, yeah, if the interviewer doesn't manage the trivial coding tasks...we're going to pass. We -aren't- saying "this person is a bad developer", we -are- saying "this person could not demonstrate that they passed the bar of our interview process".
But there have also been some who have flat out said, even on the take home "I can't do this". Or those who have admitted when faced with the whiteboard question that they don't know how; that the take home had been done by someone else. Etc. Given those situations, yeah, our candidates are being given a take home, and a whiteboard.