>Unfortunately, it is very hard to judge somebody's coding ability in discussion alone. You can sort of get the idea whether they have or don't have experience and whether they have luck being asked about topics they know (although you can help your luck just knowing a lot of stuff).
I disagree with your stated difficulty in judging coding ability by discussion alone. A skilled interviewer is easily able to ascertain breadth and depth of the candidate's experience provided the interviewer is also an expert and curious. And part of being a skilled interviewer is using all of the information at hand in their CV.
>The task is usually ambiguous a bit and this is explicitly stated so that the candidate is actually expected to get stuck, don't know things and have to talk to me to get the problem solved. You would be surprised how many candidates do not listen or can't follow simple advice even when I am almost giving them the solution on a platter.
Would instantly pass on working with you based on this alone. The intentional ambiguity is deceitful. The expected dependence and expected deference is so patronizing and manipulative. I don't need to have an ego measuring contest in an interview. You win, you're the smart, awesome guy. Go enjoy all that success, bro.
I've had too many interviews like this where the dudes on the other side of the table have internalized their superiority at proctoring their simple tasks. These dudes think they are the great gatekeepers of... something. Like, the candidate just wants to cut code so they can pay rent and eat. They don't really care, nor should they, about your product, or your customers. It's an exchange of labor for a pittance of the value produced. And the dudes on the other side of the table are gate keeping it.
> A skilled interviewer is easily able to ascertain breadth and depth of the candidate's experience [without a coding test]
And yet, many interviewers' experience shows that there are people that would pass a discussion-only interview and fail at basic coding tasks. There's plenty such people holding down jobs for a while, so even that may not be a sure indicator of skill.
> The intentional ambiguity is deceitful. The expected dependence and expected deference is so patronizing and manipulative.
I'm ~1.5years into my first job as a Backend Dev so I can't speak much about the industry, but based on my experience and what I hear from others, asking questions and clarifying unclear requirements is part of the job description. I almost never get my tasks in a precisely defined way and a lot of my job is gathering information and asking the right questions to build the right thing, often making my own choices and judgement calls. I assume that these skills are what GP comment is trying to test.
> They don't really care, nor should they, about your product, or your customers.
You can hardly blame a company for preferring someone who does. Or at least, pretends to.
Actually, for the past two years I was using the coding task I got to do when I joined the company. This helps me appreciate how I felt when I have seen it for the first time.
I disagree with your stated difficulty in judging coding ability by discussion alone. A skilled interviewer is easily able to ascertain breadth and depth of the candidate's experience provided the interviewer is also an expert and curious. And part of being a skilled interviewer is using all of the information at hand in their CV.
>The task is usually ambiguous a bit and this is explicitly stated so that the candidate is actually expected to get stuck, don't know things and have to talk to me to get the problem solved. You would be surprised how many candidates do not listen or can't follow simple advice even when I am almost giving them the solution on a platter.
Would instantly pass on working with you based on this alone. The intentional ambiguity is deceitful. The expected dependence and expected deference is so patronizing and manipulative. I don't need to have an ego measuring contest in an interview. You win, you're the smart, awesome guy. Go enjoy all that success, bro.
I've had too many interviews like this where the dudes on the other side of the table have internalized their superiority at proctoring their simple tasks. These dudes think they are the great gatekeepers of... something. Like, the candidate just wants to cut code so they can pay rent and eat. They don't really care, nor should they, about your product, or your customers. It's an exchange of labor for a pittance of the value produced. And the dudes on the other side of the table are gate keeping it.