Does using a constraint solver actually solve the question under the time ... constraints?
If not, how can you claim you have solved the problem?
Many hard LeetCode problems are easy constraint problems
321–330 of 551 posts
Re: Many hard LeetCode problems are easy constraint problems
#322All problems cited are about testing if you can write if's, loops and recursion (or a stack/queue).
They aren't testing if you can write a solver. They are testing if you can use bricks that solvers are built out of because other software when it gets interesting is built out of the same stuff.
Re: Many hard LeetCode problems are easy constraint problems
#323I've never heard of a "dynamic programming algorithm". Read wikipedia and it seems to mean....use a recursive function? The coin problem is an easy recursive problem (I just wrote the code for it to make sure my old brain can still do it).
> Read wikipedia and it seems to mean....use a recursive function? Yes, that's one (common) approach to dynamic programming. The recursive function call are memoized so that previous calculations are remembered for future function calls. Overlapping subproblems become trivial if you can reuse previously computed values. The recursion with memoization is top-down dynamic programming.
So all in all pretty basic stuff. Why would anyone worth their salt should have problem with that?
Re: Many hard LeetCode problems are easy constraint problems
#324Earlier quoted context omitted.
It's the same exact thing - if some company makes you jump through hoops to get hired that you find distasteful just don't apply to company.
No. Certain things just harm basic human dignity and should be outlawed. Judgement comes from our peers, not from machines.
But sometimes also machines. ACLs are enforced by machines, and everyone is fine with that.
Re: Many hard LeetCode problems are easy constraint problems
#325Earlier quoted context omitted.
A surprise live test is absolutely the wrong approach for validating whether someone's done the work. IMO the correct approach is to go through the existing code with the applicant and have them explain how it works. Someone who used AI to build it (or in the past had someone else build it for them) wouldn't be able to do a deep dive into the code.
We did go into the assignment after I gently bowed out of the goofy live test. The CTO seemed uninterested & unfamiliar with it after returning from a 3 week vacation during the whole process. I waited. Was happy to run him through it all. Talked about how to extend this to a real-world scenario and all that, which I did fantastically well at.
I feel your pain. This isn't a question about AI or not. It's about if you can do the work and do it well. This kind of nonsense happened before AI. If you can't win the game of Jeapordy you don't get the job which has nothing to do with being a Jeapordy contestant!
Re: Many hard LeetCode problems are easy constraint problems
#326Terrible question for an interview, and further highlights how our interviews are broken. Greedy algorithms tell you nearly nothing about the candidate's ability to code. What are you going to see? A single loop, some comparison and an equality. Nearly every single solution that can be solved with a greedy algorithm is largely a math problem disguised as programming. The entire question hinges on the candidate findin…
My best interview consisted of: -what projects have you done -what tech you worked with and some questions about decisions -debugging an issue they encountered before -talking about interests and cultural fit Instant green flag for me. Too bad that after receiving my offer covid happened and they had a hiring freeze.
I've seen some cases where someone bragged about projects they participated in but then struggle to write a simple loop.
You can try to sus out smooth talking faker or just tell them to write a thing and then talk only after they demonstrate basic comprehension.
Re: Many hard LeetCode problems are easy constraint problems
#327Great insight. But this is sadly not applicable to interviews. > It's easy to do in O(n^2) time, or if you are clever, you can do it in O(n). Or you could be not clever at all and just write it as a constraint problem This nails it. The point of these problems is to test your cleverness. That's it. Presenting a not-clever solution of using constraint solvers shows that you have experience and your breadth of knowledg…
> The point of these problems is to test your cleverness. Last round I did at Meta it was clearly to test that you grinded their specific set of problems, over and over again, until you could reproduce them without thinking. It's clear because the interviewers are always a bit surprised when you answer with whatever is not the text-book approach on both leetcode and on the interview guide they studied. Cleverness is…
Cheekily using counting sort ended things the one and only time I agreed to interview with Meta. Definitely improved my inbox for a couple years though.
Re: Many hard LeetCode problems are easy constraint problems
#328An interesting meta problem is to determine antagonistic set of denominations, like the [10,9,1] example given in the post, to maximize the number of coins selected by the gradient method.
Re: Many hard LeetCode problems are easy constraint problems
#329Any problem can be solved by a sufficient number of nested for loops. (if you have enough time)
And a stack.
Re: Many hard LeetCode problems are easy constraint problems
#330I implemented the simple greedy algorithm and immediately fell into the trap of the question: the greedy algorithm only works for "well-behaved" denominations. If the coin values were [10, 9, 1], then making 37 cents would take 10 coins in the greedy algorithm but only 4 coins optimally (10+9+9+9). That's a bad algorithm, then, not a greedy algorithm. Wouldn't a properly-implemented greedy algorithm use as many coins…
By the way, ChatGPT was able to solve this problem and give the correct solution.
It's in numerous algorithms textbooks and probably a lot of code repositories, so that's not surprising.