> i.e. if you wag your tail chasing a bad end for 15 mins, this is a fail in an interview
That’s an assumption. Perhaps following a dead end for a while, realizing it, pivoting, etc is a valuable, positive, signal?
That’s an assumption. Perhaps following a dead end for a while, realizing it, pivoting, etc is a valuable, positive, signal?
In a 2 hour pair programming session on an 'unsolved' problem (like an open issue / minor bug / minor feature in a public repo), yes, it will likely not matter if you tried a bad idea, and would both be more realistic and a positive signal.
If the candidate will communicate with me, I will offer them a LOT of guidance. It is still very, very easy to tell who knows what they are doing and who does not. You give them a basic but domain-specific task, you give them whatever extra context they need to do it, and you watch them hammer out the code.
It should be a task that is sufficiently familiar to the person applying to the role that they do not need to do -much- looking at docs, and as the interviewer you should be prepared to help them quickly find the docs you already know they will need -- you designed the task after all -- so that they don't waste time with that.
What's important is that they ask for docs when they need them, and that they can understand them, quickly, and use them. It will be obvious if they are using AI because of how long things will take. It will be obvious if they don't know when to reach for documentation, and it will be obvious if they cannot understand the documentation.
Then, they should write a test for their solution. This weeds out 95% of candidates. Talk to the other 5% and you'll find someone who can both actually write code and also discuss design.
What is not to say that you are making anything wrong. But watch for bias there.
This sounds like the kind engineer who won't push back or ask for clarification on unclear requirements - and happily spend a month solving a problem the business doesn't have.
So maybe seeing that at interview time is a good thing?
Might not mean the candidate doesn't fit - but can clarify what kind of roles would work?
Perhaps, but an interview is a fundamentally different environment than day to day work.
There's no way to solve the interview/interviewee problem though, the whole thing is impossibly fucked and is going to have false positives/negatives no matter what.