3 ms·
What you describe has echoes of allowing api lookups and such during an interview. Or if it's ide or repl only, or something like whiteboarding. You see the pr
by strict9 2y ago
What you describe has echoes of allowing api lookups and such during an interview. Or if it's ide or repl only, or something like whiteboarding.
You see the process and the questions they ask and evaluate how they distill the responses. The more you let the candidate use sources, the closer it is to day-to-day work.
A somewhat similar equivalent to yesterday's copying and pasting a Stack Overflow or w3 schools solution is blindly copying and pasting a chat response from a quick and vague prompt.
But someone who knows how to precisely prompt or use the correct set of templates is someone with more critical thinking skills that knows when to push back or modify the suggested solution.
Knowing the small % of difference can make a big difference long term in code readability, reliability, and security.
The other big alternative to all of this is strict debugging. A debugging test or chain of thought around quickly identifying and fixing the source of problems. This is a skill whose needs will probably increase over time.
- sepositus 2y agoI suspect a large part of the problem is a lack of experienced engineers with the capacity to do interviews. As someone who often gets stuck with them, I can attest to how draining they can be, especially if you're doing them correctly. The problem is that it's _these_ engineers we need running the interview because they can pretty quickly pick out a fraudulent candidate from an exceptional one while giving both the option to use AI. I generally only need about 30 minutes to confidently assess whether someone is worth pushing further in the process. But while HR would love to make me a full-time interviewer, it rarely makes business sense. So we end up with unqualified people using what they were told are good signals for hiring talent.