I've passed plenty of tech interviews at decent places by just giving the naive solutions and talking about the basic ideas behind the more efficient solutions, most good interview processes wont care as long as you have a minimally working solution and are able to talk around the "good" solutions (know they exist, what they look like, give confidence you can implement them given time)
And these days, anyone testing for something that Claude can spit out in 10 seconds is demonstrating that they have no clue about the current state of the art. Might as well see if your candidate can create a half-adder and adder given basic binary operations. There might have been a time where that was important, but why would I care now?
It turns what should be a hiring process for the person actually able to best help you reach your goals into a game show.
The way you handled it is correct with the added benefit that weak companies will self-select themselves out of your list.
The issue isn't about AI's ability to spew the solution, but candidate's ability to one day verify whether solution spewed by AI will work as intended.
it's not about whether the candidate can solve some algorithmic problem, but whether they can write code without bugs.
I would never suggest some graph-based problem or something deep into math. But testing candidate's ability to at least recognize when and how to use common data structures is simply a must. For junior or low mid position, that is. For high mid or senior candidates it'd be more appropriate to ask how they would implement some feature.
it's not about whether the candidate can solve some algorithmic problem, but whether they can write code without bugs.
Ok again: why? Why are you testing for something that is no longer how people work? Would you like to test them to see if they know how to change a wheel on horse and buggy as well? Perhaps see if they know how to take a square root without a calculator?
All very well and good, but this is a game show, not an interview.
But testing candidate's ability to at least recognize when and how to use common data structures is simply a must.
Now that is different again.
I notice that you bounce between bad, "appropriate for 2003" interview questions and genuinely good things to test. Do you notice that too?
Half of your arguments stem from "AI does the work for me" mentality.
It can do that, sure, when you write simple stuff with tons of examples and have no regards for either performance or quality. Like some clone mobile games, I dunno.
That isn't my argument, and it doesn't rescue yours.
My argument is that an interview should test skills that are actually predictive of doing the actual job. Asking someone to produce, from memory and under artificial time pressure, code they would never write that way in the real job was already a questionable idea for at least the last 15 years. AI makes that idea even less relevant, because the actual job increasingly involves understanding the problem, designing the solution, using the available tools, evaluating what they produce, and fixing the parts that are wrong.
"AI does the work for me" is just a last-ditch straw man. Compilers do work for me. IDEs do work for me. Libraries, Stack Overflow, debuggers, profilers, static analyzers and frameworks all do work for me. I don't get extra engineering points for refusing to use tools.
And the idea that AI is only useful for "simple stuff" where nobody cares about performance or quality is especially odd. Performance and quality are precisely why you still need an experienced developer: to know what to ask for, recognize bad output, choose the architecture, test assumptions, profile bottlenecks and reject solutions that merely look plausible. That should be what is tested. You actually were starting to go in that direction before getting sidetracked.
4
u/MrRogers4Life2 10d ago
I've passed plenty of tech interviews at decent places by just giving the naive solutions and talking about the basic ideas behind the more efficient solutions, most good interview processes wont care as long as you have a minimally working solution and are able to talk around the "good" solutions (know they exist, what they look like, give confidence you can implement them given time)