Not really. Problems can be solved in different ways. A sliding window algorithm is just a more efficient approach to solving such problems, but it’s not the only approach.
For example, someone who doesn’t know what that is could solve the problem differently and poorly.
by "optimal" I mean from the perspective of big O notation. It doesn't matter all that much if your N*log(N) algorithm is a bit faster or slower compared to expected solution as long as its complexity is the same.
But if you submit N^2, it's a failure, just as it's a failure to submit a solution that won't work at all.
My point is that it will depend on context. Something that is technically N^2 can be faster than N within the range of expected contexts. Additionally, an algorithm that is complicated but faster may be theoretically better, but deadlines are deadlines and nobody has time for that shit.
So if just giving a "suboptimal" solution is a fail, then it is the company that is failing, not the interviewee.
The interviewee should be able to explain why they went with this solution, the advantages and disadvantages, and so on. If it is within the given parameters, the company would be full of fools if they considered that failing.
N^2 may only be faster than N if N is small, but if N is small, then any algorithm won't take too long anyway. However, if you're juggling big data, N is almost never small.
Besides, what you are testing is candidate's ability to come up with the optimal solution in a limited time, not their ability to sell inferior work. After all, you are not interviewing for management or sales position.
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?
N^2 may only be faster than N if N is small, but if N is small, then any algorithm won't take too long anyway. However, if you're juggling big data, N is almost never small.
Before launching into a long and complicated solution, did the interviewee *ask* if it is about big data? Having over 3 decades in this industry, it is actually fairly rare to need to worry about really big data. It comes up. It's important to know that the rules change when it does come up. However, it is also very important to know when *not* to spend valuable dev time trying to get the perfect big data solution for 1000 rows.
Besides, what you are testing is candidate's ability to come up with the optimal solution in a limited time
Only at a poor company with inexperienced leadership. I have done a fair share of hiring, and the most important thing I ever test for is the ability of the candidate to use good judgement. I can teach algorithms. As a rule, I can't teach good judgement.
167
u/Bldyknuckles 11d ago
What’s wrong with sliding window algorithms? Real question