If someone asked me a problem that basically reduced to a textbook case of something in the middle, difficulty wise, like reservoir sampling, and I said "oh, nifty, resevoir sampling, what do you use that for in your stack?" and they said "nothing, I just want to make sure you can code," then depending on how my experience to that point in the process had been going I might challenge them on that to some extent, a la "do you find this more useful than questions that are more representative of the work you're expecting me to do?" If the loop had been going particularly robotically, this might find stronger forms - I've walked out on a mismanaged interview before, though it was way worse than this (and way worse in a very different way - they just weren't at all prepared and the tooling they wanted me to use wasn't actually functional).
Or they might answer something more like "we use it to select test cases from our logs to ensure that we're adequately testing against real behavior with proper weights" (or whatever—it's been a while since I actually did this in a past job :) ) in which case I'd still try to have what I consider a more "real" conversation ("what primary problem are we trying to solve, and what else might be options to consider"), but in that case at least they had a good answer to the question and I'd be happy to write the code too.
But lastly, frankly, as a hiring manager I absolutely want to hire people who are willing to "not focus on the task at hand" and question things. I don't want people who just blindly do what I tell them to, I want people I can trust to disagree with me and be able to make a case for why they disagree. Being a manager doesn't mean my instincts are 100% and theirs are 0%.
Yes, because tasks representative of the work we're expecting you to do are too obvious and simple for an interview 95% of the time, and are too hard and take too long for an interview 5% of the time.
It's kind of like asking someone interviewing to be a cashier at a fast food restaurant multivariable calculus problems, because 95% of the math they're going to have to do at their job is "too obvious and simple".
If these high-priority and hard 5% were easily separable from the tedious 95%, this logic would be correct.
This seems a little too general to me. Many things are not clearly thought out, and I'd rather work with people who can recognize when that is the case and communicate well enough to correct the course. A big part of successful development in my experience is knowing when not to implement things, or having foresight to implement things in a better way. Working with people who just do what they're told is often a huge waste of time.
And those people are what we call “assholes”.
Everyone makes mistakes. If you make a habit of questioning people’s competence because they make mistakes, and didn’t ace your whiteboard coding tests beforehand, you are 100% the source of the problem in this industry.
I only take issue with this. Many things in organizations that have been through explosive growth (and sometimes others) are that way because for no reason in particular and amount to bandaids upon bandaids because nobody's ever had a chance to actually look at the process. It very well might suck. Questioning it is the first step in making it not suck.
That said, as an interviewee is probably not the right time to do so. You're an outsider, you have very little rapport or relatability compared to the people that already work there. Even if you can point to something and unambiguously prove that They're Doing It Wrong, your advice isn't in a position to be heeded.
Moving the bit about the scope of the role (jr vs sr vs lead) up to preface the rest of the comment would've toned it down a bit, but even there I disagree with the "taking a risk" part - a senior candidate shouldn't feel like it's risky to offer alternative perspectives. If I got the impression that the hiring manager thought asking questions would likely be a sign of "cannot focus on the task at hand," that's going to set off my own flags a bit.
If you're married to your interview process I'm worried you'd be even more married to your day-to-day process, and I haven't met a perfect company yet, so I consider being overly adherent to process instead of results a warning sign.
Also, as an interviewee, you stand to learn a lot more from that interaction than by rejecting it. Hell, I welcome coding challenges as an opportunity to size up the interviewer's chops!
If the challenge is conducted in a reasonable way, it should feel like any other design/pair programming session you've had at the office, and it can be quite revealing of the tendencies of your potential colleagues.
> Also, as an interviewee, you stand to learn a lot more
> from that interaction than by rejecting it.
> question things that have clearly been thought out
> ahead of time.