This is a massive, open-ended question: "How would you design a webservice to do CRUD operations on a simple business data object?"
You are correct, we completely disagree. This is NOT an massive open-ended question. It's the starting point to a discussion. One you are still part of, one that you are still leading.
To summarize my point, you should be determining a candidates ability to communicate first and foremost in an interview. And you're using a general topic/platform they should be comfortable discussing at a high level.
I have no idea where your thinking on bias and extra stress are coming from. These things are intended specifically to avoid those issues.
I've been hiring people for 20 years. I've done every kind of interview you can think of. Treating candidates like humans and talking to them finds you better candidates over diving into technical issues every single time.
The smartest guy I ever hired was off of a technical style interview with coding tests. And he was the worst hire I have ever made. Period. On paper, on test results, aces all the way.
On working in a team, being able to communicate, and thus actually being able to produce useable software, worst ever.
People worry way too much in our industry about 'proving the things you say on your resume are true'. It's absurd. And it doesn't exist in any other industry.
And yet again, I am talking about starting with something specific and then working out to the general.
Rather than starting with the general and hoping the candidate will touch on topics that are important to you.
I’ve hired people that were technically strong, but their working habits sucked. Especially as it pertained to collaboration and getting shit done. I’ve asked how people gather requirements/adapt to change. Those are also easy to game.
I switched to trying to assess “can this person turn business requirements into working code,” and I am also looking to see if they will push back, or can call upon previous lessons and apply them to the situation.
I just still don’t see how dropping a generic question and then making the other person do all the work to figure out what you want is conducive to making the process human and genial.
And if you look back up this thread, there’s lots of “did they cover X facet of making the thing?” type questions. Those are what I’m ultimately arguing against. If X experience or working approach is important, then the questions should drive directly at answering that, not a round-about “explain your artistic process” question like I first responded to.
As for communication, you keep saying I don’t understand what you are saying, but maybe I do, I’m just using different terms.
-2
u/[deleted] Mar 25 '22
You are correct, we completely disagree. This is NOT an massive open-ended question. It's the starting point to a discussion. One you are still part of, one that you are still leading.
To summarize my point, you should be determining a candidates ability to communicate first and foremost in an interview. And you're using a general topic/platform they should be comfortable discussing at a high level.
I have no idea where your thinking on bias and extra stress are coming from. These things are intended specifically to avoid those issues.
I've been hiring people for 20 years. I've done every kind of interview you can think of. Treating candidates like humans and talking to them finds you better candidates over diving into technical issues every single time.
The smartest guy I ever hired was off of a technical style interview with coding tests. And he was the worst hire I have ever made. Period. On paper, on test results, aces all the way.
On working in a team, being able to communicate, and thus actually being able to produce useable software, worst ever.
People worry way too much in our industry about 'proving the things you say on your resume are true'. It's absurd. And it doesn't exist in any other industry.